Subject: [Ltru] Re: [psg.com #1026] what to do about Guernsey and Jersey

From: "Doug Ewell" <[email-masked]>
Date: Sat, 11 Jun 2005 15:00:57 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> The presence of both 830 *and* 831 and 832, none of which was
>> permissible under RFC 3066, is not likely to cause any great
>> difficulty in the real world.
>
> If they deprecate 830 too late we also deprecate it => ready.

True.

>> But it SHOULD be noted that if we do allow 831 and 832 (and
>> 833), and if Addison is correct, we CANNOT subsequently
>> register GG and JE (and IM) if those codes are added to ISO
>> 3166/MA, and make them the Preferred-Values for the numeric
>> codes.  I think there is a common assumption that we (or
>> ietf-languages) would do that.
>
> Not my assumption.  I got the idea that 3066bis is a one-way
> street to UN numbers in slow motion.

I did not get that idea, unless by "slow motion" you mean hundreds and
hundreds of years.

<soapbox>
The great pace of national change, fueled by the national
self-determination of colonial holdings during the 20th century and the
rise of nationalism during the 19th and 18th, has essentially concluded.
Most nations on Earth -- probably 75% or more -- have attained more or
less the same status they will continue to have for many, many years to
come.  Even the great changes of the 1990s -- the breakup of the Soviet
Union and Yugoslavia, the reunification of Germany and Yemen -- affected
fewer than 10% of the currently recognized nations.  Minor changes in
governmental structure will not materially affect the relevancy of ISO
3166; changes in name or other major changes are not likely to occur at
the pace necessary to render ISO 3166 worthless for our purposes.  I
expect to be around in 50 years to see how well these predictions have
held up.  :-)
</soapbox>

> You (all here) didn't
> like my plan to do this fast (at date-B) and for all regions.

I did not.  We have to stay backward compatible with RFC 3066, and that
means sticking with alpha-2 region subtags.  I will not argue this
further.

> As long as GG, IM, and JE still _can_ be listed a.s.a.p. it's
> no real problem if their Preferred-Value sticks to 831...833.

I don't believe they can be added if 831 through 833 already exist.
Addison and Mark can confirm or deny this.

>> they cannot be superseded by ISO codes that are added later.
>
> Is there a "normal" procedure that the UN numbers are "always"
> changed first, and that 3166-1 follows suite later ?  We could
> add some text to the draft allowing for this delay, avoiding
> premature registrations of unnecessary / redudant UN numbers.

ISO 3166/MA states that they do not add a code for a country unless it
appears in the UN list.  This allows them to avoid the controversy of
"defining" what is a country, while giving them authority to assign
codes to the things the UN has defined as countries.  This is as it
should be.  So yes, there is a procedure that UN coding comes before
ISO.

What ISO does not promise is that UN coding *will automatically* lead to
ISO coding.  So far it seems to have happened 100% of the time, even for
Åland, which is why I suggested waiting until ISO made a decision before
adding subtags for these entities.  But many people have pointed out
that we can't delay the draft indefinitely, waiting for ISO to make a
decision.  (They're not known for adhering to published schedules in
doing so.)

Later:

> In the hypothetical case TP -> TL, and TL changing its name
> again, we get TP -> TL and TL -> XX.  Is that really necessary,
> why not just update TP -> XX in this case ?  A very minor nit.

I would greatly prefer this, but it seems not to have met with much
approval.

> | 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.
>
> That's apparently an error, let's say "ISO 3166, and UN M.49"
> instead of (only) "and ISO 3166".

No, that's on purpose.  ISO alpha-2 codes are considered the standard
form for region subtags, while UN M.49 numeric codes are considered a
fallback in case the ISO approach causes problems (as with CS) or for
the macrogeographical regions that are outside the scope of ISO 3166.
UN codes and ISO 3166 codes do not supersede one another.

> And where's the rule about a new code that does _not_ conflict
> with an existing code, but whose meaning _is_ the same as an
> existing subtag ?  The TL -> XX in my example ?  We should
> simply delete this part resulting in:
>
>   Codes assigned by ISO 639, ISO 15924, ISO 3166, and UN M.49
>   that do not conflict with existing subtags of the associated
>   type are entered into the IANA registry as new records and
>   their value is canonical for the meaning assigned to them.

If an ISO code does not conflict with an existing subtag, and has the
same meaning as an existing subtag, aren't they the same code?  I must
be missing something here.  Give me a example of what you mean.

> Adding a statement about the "same meaning" case:
>
>   If existing codes have the same meaning a Preferred-Value is
>   added or updated to show the new code.  UN M.49 codes are
>   only added if no ISO 3166 code with the same meaning exists.
>
> In this form GG, IM, and JE would replace 831..833.

I think I understand what you mean.  It would have to be up to the WG to
decide, at this very late stage, whether to change the policy in this
way.

> This isn't
> what we think how it should work, something with my proposal is
> still wrong.  But something in draft -04 is also still wrong.

Understandably, Randy will want something more concrete than this.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 12 Jun 2005 03:31:22 +0200

> <soapbox>
[...]
> </soapbox>

Nice.  But I don't believe it.  That Somaliland example is a
real example.  We saw it for Eritrea, we'll see it for Sudan,
and I've no idea how many real countries might develop from
the former Zaire.  Or Nigeria.  Or other mainly artificial
conglomerats on this continent.  Or elsewhere e.g. Indonesia.

>> As long as GG, IM, and JE still _can_ be listed a.s.a.p.
>> it's no real problem if their Preferred-Value sticks to
>> 831...833.
 
> I don't believe they can be added if 831 through 833 already
> exist.  Addison and Mark can confirm or deny this.

No, they can fix their draft until it works for the real #1026
example before date-B and after date-B in any possible order
of events.

> ISO 3166/MA states that they do not add a code for a country
> unless it appears in the UN list.  This allows them to avoid
> the controversy of "defining" what is a country

Okay, so it is the normal procedure.  Maybe that's why draft
-04 is at it is, there's no "delay", UN numbers are just never
listed unless it's a conflict.

And why did we think that 830, 831. 832, 833 are listed ?  Is
the draft -04 correct, and we were just a bit dense ?  Or do
we only need a special rule for an ignorant Duke refusing to
register Her private possessions with ISO 3166-1 ?

> that's on purpose.  ISO alpha-2 codes are considered the
> standard form for region subtags, while UN M.49 numeric
> codes are considered a fallback in case the ISO approach
> causes problems (as with CS)

Here we have a new problem, the igorant Duke, or ISO 3166-1 
refusing to sanction their own provisional codes.  This can't
be true... :-(

I don't trust them.  Let's pick ccTLDs as source, or Mark's
list, after he decided what to do with BDT, GMT, BST, etc. ;-)

> UN codes and ISO 3166 codes do not supersede one another.

Then ticket #1026 is *O* *P* *E* *N*   I'd refuse to accept a
draft where regions are lost because ISO and the UN play games.
I don't trust them.

> If an ISO code does not conflict with an existing subtag,
> and has the same meaning as an existing subtag, aren't they
> the same code?

TL changing its name to XX.  Of course XX != TL, so I'd expect
that they are so decent to deprecate TL at the same time, OTOH
I don't trust them.

> Understandably, Randy will want something more concrete than

He will wait until it works in the worst cases ISO and the UN
are in theory able to create.  Fortunately they are willing to
create these worst cases in practice while we are still at it,
thanks to 831 and 832.
                         Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Jun 2005 20:19:17 -0700

Hi -

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, June 11, 2005 6:31 PM
> Subject: [Ltru] Re: [psg.com #1026] what to do about Guernsey and Jersey
...
> create these worst cases in practice while we are still at it,
...

No, I will only wait until we get a rough consensus.
Engineering means making tradeoffs.  Perfection may
be possible, but it's usually too expensive (in time, money
or other resources) so I'll be happy once the WG gets its
act together and gets rough agreement on something.
If you guys can't come to a workable compromise quickly,
the co-chairs could conceivably declare victory with whatever
is in the draft.

Let's finish this thing.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 12 Jun 2005 06:12:01 +0200

> Let's finish this thing.

What do you _expect_ if the 831 + 832 problem showed up after
date-B ?  Or the hypothetical new 888 ?  Wait for ISO 3166-1
codes how long, forever ?  That's what the draft -04 says now.

Or just list 831 + 832 because they came before date-B, and in
the case of 833 we're absolutely sure that it's old.  Does it
block a possible future GG + JE ?  Does it also block a future
IM ?  Apparently that's what the draft -04 says.

We really should get this right, and IMHO we can get it right
today (2005-06-12 GMT).  And I really like to hear what you'd
_expect_ in these cases.

On the new (private) "IETF golden rules" list they have it as
the principle of the least surprise.  I know it as "is there a
high astonishment factor ?" plus "then don't implement it".

                            Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 11 Jun 2005 22:55:37 -0700

Hi -

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?

> Sent: Saturday, June 11, 2005 9:12 PM

> today (2005-06-12 GMT).  And I really like to hear what you'd

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.

> high astonishment factor ?" plus "then don't implement it".

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.  :-)
Seriously, if it did, I still wouldn't care whether the resulting tags
were alpha, numeric, or mixed.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 12 Jun 2005 11:08:55 +0200

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.

> 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.