Sample IANA language subtag registry

[Mark Davis]

comments below with *

‎Mark

----- Original Message ----- 
From: "Peter Constable" <petercon at microsoft.com>
To: <ietf-languages at iana.org>
Sent: Monday, July 12, 2004 07:37
Subject: RE: Sample IANA language subtag registry


> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> bounces at alvestrand.no] On Behalf Of Mark Davis


> The reviewer's workload would not change much, I believe, once we had
the
> initial list set up

And after ISO 639-3 is published and we want to incorporate that?

* That is the other blip I was referring to. If ISO 639-3 is published and
it has a good versioning and stability policy, then it is purely mechanical
to keep it up to date. If it does not have good versioning and stability,
then there will need to be some work -- but that is work that would need to
be done.


I will repeat that I am very concerned with this process. You guys
published an initial draft, which I guess could have been seen as the
plan of action -- i.e., "in this revision of RFC 3066, the issues that
we aim to deal with are reflected in this draft". But the scope of
changes is shifting when the thing should be stabilizing, and the design
change was made without any advance warning or discussion. And
discussion *is* needed.

For instance, as I pointed out earlier, draft 4 leaves things very
unclear as to which sources can be referenced: the code table provided
as a TXT, or the source standards themselves.

* The only way to validate the tags would be by using the IANA list, which
would look like the TXT file. Sorry if that is not clear; we can make it
clearer in the next version.


Also, the change is being made to address instability issues, but these
are almost entirely limited to ISO 3166.

* It is more than just stability. It is the ability, for any point in time,
to say whether or not a particular string is a valid tag. That is very
difficult to do right now, since people have to pick up the files from the
respective standards and do some modifications. The unified text file allows
anyone, right out of the box, to perform validation and have the confidence
that other people will be doing it the same way.


If we are going to change the
reference to ISO 639 from direct to indirect, then there are other
issues that should have been considered. For instance, there's the
concern of an ISO 639-1 ID being added where one previously existed in
ISO 639-2 -- that could easily be resolved for good, but is not. Also,
we could be asking whether some of the IDs in ISO 639-2 are best not
used in this context, e.g. the IDs collections of languages (it is *not*
useful to declare of content that it is in "South American Indian
(Other)").

* For backwards compatibility, we have to accept everything that was
previously valid, so whether or not it is useful to declare content that was
"South American Indian (Other)", if RFC 3066 accepted it then we have to.


Then there's the question I raised above: is the language tag reviewer
prepared to scale up processes when the day comes that we add reference
to ISO 639-3? The change in the draft appears to have been made without
any consultation with the language tag reviewer. That should not have
happened.

* That is the whole reason for producing a new draft, is to gather comments
from all concerned, including the current language tag reviewer.


Peter Constable

_______________________________________________
Ietf-languages mailing list
Ietf-languages at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages