From: Doug Ewell (dewell@adelphia.net)
Date: Tue Sep 12 2006 - 23:40:31 CDT
Because RFC 4646 and 4647 and the IANA Language Subtag Registry are so
new and many people will be unfamiliar with the changes, I'm going to
try again to clear up some misunderstandings.
Philippe Verdy <verdy underscore p at wanadoo dot fr> wrote:
>> Technically this is a moot point for users, because they will be
>> using subtags from the IANA Language Subtag Registry, not code
>> elements from ISO standards. The subtags are based on the ISO
>> standards. It is the responsibility of the Language Subtag Reviewer
>> and the ietf-languages@iana.org list to make sure any possible
>> conflicts in the standards don't find their way into the Registry.
>
> That's a good argumentation that is not clear in RFC 4645 (although
> this RFC just describes the content of the initial registry), but more
> importantly in RFC 4646 (given that it gives explicit references to
> ISO 639 as the source, without making it clear that this is the IANA
> registry that will prevail in all cases).
From RFC 4646, Section 2.2:
"The Language Subtag Registry maintained by IANA is the source for valid
subtags: other standards referenced in this section provide the source
material for that registry."
> So there are probably too strong rules in RFC 4646, and RFC 639 should
> only be considered as an informative, but not mandatory, source
> (except for RFC 4645 for the initial content of the IANA registry).
See above.
> What you seem to say is that the ISO 639 maintenance agency should
> request additions according to the ISO 4646 rules, and that IANA will
> update its registry only if it does not violates the ISO 4646 rules.
I didn't say anything about what the ISO 639 RA/JAC should do. They add
and change and withdraw code elements; the ietf-languages list and
Language Subtag Reviewer make changes to the Registry in response to the
ISO 639 changes (among other things). The list and Reviewer may decline
to follow the ISO changes if doing so would result in a conflict, so the
second part of your sentence is true.
> This means that all ISO 639-3 additions as well as any updates to ISO
> 639-2 or even ISO 639-1 or any part of ISO 3166 or UN M.49 (what about
> the recent case of Serbia and of Montenegro which are now independant
> UN members and so will get, or already have, their own numeric code
> for the next edition of UN statistic reports... even if ISO 3166 is
> still not updated: who will use YU and CS now?) will not qualify as
> valid updates in the IANA registry for usage in language tags (if this
> conflicts with the RFC 4646 stability rules).
IF they conflict with the stability rules. So far there are 7,000
additional language codes that ISO 639-3 will add to the picture, plus
at least two new ISO 3166 country codes, and I can't think of a single
one that will not be added to the Registry due to conflict.
> So why was it needed to give these sources in the text of RFC 4646?
> Wouldn't have it been better to keep them outside, or only as
> informative references, making them normative only with the current
> version of RFC 4645 that defines the current allocation priority
> policy?
There are IETF process experts who have forgotten more about normative
vs. informative references than I'll ever learn. I completely defer to
their expertise when it comes to classifying references.
> That's where a part of the confusion comes. ISO 4646 would have been
> better if it just consisted in describing the IANA registry, and the
> rules for composing and parsing the language tags. And then adding a
> reference to RFC 4645 or its successor regarding the current rules
> allowing inclusions in the IANA registry, rules that will need to be
> updated later when ISO 639-3 will be released
The process of updating RFC 3066 began well over than two years ago and
involved a lot of people, a lot of discussion and use cases and
negotiation. It was not simple, even if you think it should have been.
> (RFC 4648? if that number is already reserved for such expected
> update).
Dozens of RFCs are issued every month. "RFC 4648" is most assured long
gone by now; the updates will almost certainly be in the 5000 range.
N.B. For those who may be confused by the numbers, the documents we are
discussing are:
* ISO 639, 3166, and 15924
* RFC 4645, 4646, and 4647
ISO 4645, 4646, and 4647 were issued in the early 1980s, and have to do
with rubber products.
-- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ RFC 4645 * UTN #14
This archive was generated by hypermail 2.1.5 : Wed Sep 13 2006 - 02:31:51 CDT