Message-Id: <6.1.2.0.2.20050103162858.02f82020@mail.jefsey.com>
Date: Mon, 03 Jan 2005 16:43:58 +0100
To: John C Klensin <john-ietf@jck.com>, iesg@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <679CF63012919E2E8FE59C83@scan.jck.com>
References: <679CF63012919E2E8FE59C83@scan.jck.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed;
	x-avg-checked=avg-ok-E797048
Cc: ietf@ietf.org
Subject: Re: Last Call on Language Tags (RE: draft-phillips-langtags-08)
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 13:56 03/01/2005, John C Klensin wrote:
>I hope these are mutually exclusive.

Yes, if this means that the three of them should be aggregated into the 
final strategy.

>         (i) Since we have no "Next-Best Current Practices"
>         category, publish this as an Informational Document,
>         moving it to BCP (and to "obsoletes 3066") only when
>         revisions of all documents that reference the 3066
>         registry (that includes not only IETF standards-track
>         and BCP documents, but also the ICANN IDN registration
>         procedures document and perhaps others) have been
>         written and have achieved community consensus.

100% in agreement.

>         (ii) Revise the introductory material in this document
>         to indicate that it is an alternative to 3066 that may
>         be more appropriate for some purposes and identify at
>         least some of those purposes.  Revise the "registry
>         conversion" material to provide a way to seed the new
>         registry and, if appropriate, providing for simultaneous
>         registration in both registries for new submissions.
>         Based on those changes, indicate that it modifies
>         ("updates") 3066, rather than obsoleting it.   Most of
>         my important concerns, although not some of those that
>         have been raised on the IETF list about details, would
>         disappear if this document paralleled, rather than
>         superceding, 3066.

idem.

>         (iii) One way to read this document, and 3066 itself for
>         that matter, is that they constitute a critique of IS
>         639 in terms of its adequacy for Internet use.   From
>         that perspective, the difference between the two is that
>         3066 was prepared specifically to meet known and
>         identifiable Internet protocol requirements that were
>         not in the scope of IS 639.  The new proposal is more
>         general and seems to have much the same scope as ISO
>         639-2 has, or should have.  It is not in the IETF's
>         interest to second-guess the established standards of
>         other standards bodies when that can be avoided and,
>         despite the good efforts of an excellent and qualified
>         choice or tag reviewer, this is not an area in which the
>         IETF (and still less the IANA) are deeply expert.  So
>         there is a case to be made that this draft should be
>         handed off to ISO TC 37 for processing, either for
>         integration into IS 639-2 or, perhaps, as the basis of a
>         new document that integrates the language coding of
>         639-2 with the script coding of IS 15924.

Full agreement to refer to stabilized ISO 639-2 and 15924 (and to a more 
geographically/politically precise list that 3166 only), but through 
documents adapting them to the Internet multiple orthogonal and/or related 
demands and permitting to generalize them to the Internet usage for global 
application consistency.

Otherwise we would have two (or more) geopoliticalinguistic grids in use. 
IMHO the correct solution are dedicated RFCs (compatible with RFC 1591 for 
country codes) encapsulating ISO 639-3 and 15924 into a more global 
information container including application destination and sources 
descriptors.

ISO provides lists. Internet is about networking and needs internetworked 
lists. This internetworking calls for additional ad hoc descriptors.
Thank you.
jfc 


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf