--On Monday, 03 January, 2005 16:43 +0100 "JFC (Jefsey) Morfin"
<jefsey(_at_)jefsey(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf