--On Monday, 03 January, 2005 16:43 +0100 "JFC (Jefsey) Morfin"
<jefsey@xxxxxxxxxx> wrote:
> 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.
No, I really meant "pick one", since doing any combination I of
the three that I have been able to think about would just
produce more confusion. What is needed here is, IMO, less
confusion, not more.
>> (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.
To follow up slightly on Ned Freed's comments, I don't really
see any procedural way to do this, since it would require
synchronizing things that would likely defy synchronization.
That is especially true because we can't guarantee knowing about
all of them. But, since it is theoretically possible, I thought
it deserved mention. But one cannot both publish something as an
informational document and as a standards-track/BCP one, which
is what the second option calls for.
>> (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.
See above
>> (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.
And, while possibilities I haven't foreseen are certainly
possible, it is generally the case that one cannot throw
something over a wall and hold onto it as well.
> 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.
I have no idea what you are talking about. If you have a
specific proposal, might I suggest that you generate an
Internet-Draft and indicate whether it should be taken as an
alternative or supplemental to the draft-phillips-langtag
document? If you do so, _please_ precisely identify what
problem of the actual Internet --rather than some fantasy
replacement-- you are proposing to solve.
> ISO provides lists. Internet is about networking and needs
> internetworked lists. This internetworking calls for
> additional ad hoc descriptors.
Which is what 3066 does. So the questions remain as to what
real problems we have in internetworking that 3066 does not
solve and, if there are such problems, whether they can be fixed
by a less radical and complex change to the 3066 framework.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf