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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf