Randy Presuhn wrote:
> Instead of a bunch of rhetorical questions, how about
> fleshing out a specific counter-proposal, if you think
> the current proposal is so intolerably bad?
When I wrote "I really like to hear what you'd _expect_ in
these cases" it was't meant as rhetorical question. Not
one of them.
I've already posted one proposal along the line of "just
treat new UN numbers like new alpha-2 regions codes".
But I'm not convinced that it really does what we'd want.
Especially if it's normal that new numbers come first with
an unclear delay before the corresponding new alpha-2
codes are assigned.
> As long as the algorithms and registry data produce a
> single result for the question "how do I tag language X
> in its Jersey variety", I really don't care whether the
> resulting string contains dashes and digits or letters
> and in what proportion.
Okay, in other words waiting forever for an alpha-2 code
isn't what you want. We agree about this. And it's not
how draft -04 works.
> Prior to this WG I thought Guernsey was a kind of cow, and
> Jersey was near New York City. I'd still be astonished if
> my web browsey offered either for a language preference. :-)
The 888 is not necessarily Somaliland. It could be Quebec,
Kosovo, Montenegro, Basque, Tibet, California, or what else.
And the reasons why it doesn't show up in ISO 3166-1 are not
necessarily related to a Duke and her cows. Let's assume that
my original proposal was a horrible idea, then we only need an
emergency exit to list UN numbers without alpha-2 code after
some time.
So let's add a new clause D to 2.2.4 point 3:
D. New UN numeric codes for countries without ISO 3166 alpha-2
codes can be added to the registry following the procedure
specified in Section 3.3.
The former clause D will be clause E after this insertion.
It is really difficult to discuss 3.3 in any useful way with
its very long bullet- and star-lists. I'm lost in this maze.
| o Values in the fields 'Type', 'Subtag', 'Tag', 'Added',
| 'Deprecated' and 'Preferred-Value' MUST NOT be changed and
| are guaranteed to be stable over time.
s /'Deprecated' and 'Preferred-Value'/and 'Deprecated'/
Add a new section:
o Values in the field 'Preferred-Value' MUST be updated to
reflect the most recent preferred value. Typically this
would be the at least second change of a region code.
[...]
| o Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do
| not conflict with existing subtags of the associated type
| and whose meaning is not the same as an existing subtag of
| the same type are entered into the IANA registry as new
| records and their value is canonical for the meaning
| assigned to them.
Remove "and their value is canonical for the meaning assigned
to them". If there's no conflict and no alias it makes no
sense to talk about "canonical" in this case. New section:
Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do
not conflict with existing subtags of the associated type
and whose meaning is the same as an existing subtag of the
same type are entered into the registry as new records and
their value is added or updated as Preferred-Value in the
corresponding old records.
New section:
Region codes assigned by UN M.49 that do not conflict with
existing region subtags and whose meaning is not the same
as an existing region subtag SHOULD NOT be entered into
the registry as new records until ISO 3166-1 assigned a
corresponding region code. In that case and if there's
no conflict (see above) the ISO 3166-1 code will be added.
In the case of a conflict (see below) the UN M.49 number
will be added. If ISO 3166-1 does not assign a code for
a region with an UN M.49 number over at least one year the
tag reviewer MAY add the UN M.49 number following the
procedures outlined in section 3.4.
Or in other words 831 + 832 + 833 one year after date-B. Bye.
_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.