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

From: "Doug Ewell" <[email-masked]>
Date: Sat, 11 Jun 2005 23:04:54 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

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

I am fine with either of these two choices:

(a) include 831, 832, and 833 (all three)
(b) exclude 831, 832, and 833 (all three)

The only thing I am not fine with is treating 833 differently from 831
and 832 in some way.

These three regions have a combined population of less than 240,000, and
I have not seen any evidence that the use of any language in these
places differs markedly from the use of the same language anywhere else.
I don't think the draft should be held up due to disagreement on how to
code these regions.

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

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

---

From: "Peter Constable" <[email-masked]>
Date: Sun, 12 Jun 2005 23:27:56 -0700

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Frank Ellermann

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

I agree with the suggestion that a new M.49 numeric ID should not be
registered immediately, but that some time be given to permit the ISO
3166-MA to add a corresponding entry, if they're going to take such
action within a reasonable time. I'm not sure what that reasonable time
should be; one year seems like a long time, but I don't know how much
time they typically require.

Peter Constable

---

From: "Peter Constable" <[email-masked]>
Date: Tue, 14 Jun 2005 07:08:38 -0700

On
> Behalf Of Mark Davis

> I like that approach.
> 
> >We register NO M.49 subtags that are not macro-geographic regions
> => We initially register NO M.49 subtags that are not macro-geographic
> regions

+1

Peter Constable

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 14 Jun 2005 09:12:06 -0700

+1

I'm updating the editor's copy with some proposed text to handle this and will point out the textual additions on the list for discussion when that is posted.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Constable
> Sent: 2005?6?14? 8:27
> To: LTRU Working Group
> Subject: RE: [Ltru] Re: [psg.com #1026] what to do about Guernsey and
> Jersey
> 
> > Behalf Of Doug Ewell
> > > Okay, ready to go for date-B.  And afterwards, if somebody
> > > wants them ?  The tag reviewer needs a way to delay UN M.49
> > > registration requests for some time (mabye ISO 3166-1 just
> > > needs some time to find a new alpha-2 code), but not until
> > > doomesday.
> >
> > That's what I was saying; there needs to be a rule, or at least a
> really
> > strong guideline, as to how long the Subtag Reviewer (more properly,
> the
> > process) waits after the UN code is assigned.  Otherwise, one person
> > will end up thinking they have to wait a year, while another will
> think
> > a week is good enough.  That will attract too much controversy.
> 
> Is this something that can be worked out by consensus on the
> IETF-languages list? I'm disinclined to specify a timeline in *this*
> document for something that's dependent on processes not under our
> control and that may change. We may specify three months, but then the
> 3166MA may establish a process that takes only two weeks, in which case
> people will be forced to wait unnecessarily; or we may specify four
> weeks and then the 3166MA may later establish a process that takes six
> weeks, in which case we'd be forced to do what we regret. (Just as right
> now we can't register "gsw" just due to technicalities even though it's
> what we'd want.)
> 
> What we *can* do without concern is specify the kind of result we
> consider best. Saying that we do not automatically register M.49
> non-region codes is one example of this, and saying that people are
> expected to submit a request for inclusion in ISO 639 before we register
> a lang subtag is another. We can say that, for M.49 non-region codes, it
> is expected that a reasonable effort must be made to determine whether a
> corresponding 2alpha ID will be assigned by the 3166MA before an M.49
> non-region code can be registered.
> 
> 
> 
> Peter Constable
>

---

From: "Addison Phillips" <[email-masked]>
Date: Tue, 14 Jun 2005 10:37:25 -0700

Responses below.

Addison

Addison P. Phillips

> Sent: 2005?6?14? 9:11
> To: [email-masked]
> Subject: [Ltru] Re: [psg.com #1026] what to do about Guernsey and Jersey
> 
> Addison Phillips wrote:
> 
> > we mirror ISO 3166 except for
> 
> > (a) miscellaneous regions individually registered for which
> > no ISO 3166 code is assigned
> 
> Okay, cases like 831..833 or the hypothetical "888 Somaliland".
[Addison Phillips] 

Right.
> 
> > (b) reassignments on the part of ISO 3166 (covered by the
> > rules on that).
> 
> The hypothetical TE" replacing TL ?  No, that would be simply
> mirrored (I hope).   A hypothetical "BU" conflicting with our
> old BU, yes, that's covered by the rules.
[Addison Phillips] 

"Reassignments" means the BU case, not the TL->TE case. The latter is handled by the daisy chain.
> 
> > Simple, I think.
> 
> Probably, but I'm more dense than usual today.  We still need
> a rule delaying your case (a) for the hypothetical "888" if it
> gets SX later.
[Addison Phillips] 

The first delay is built in: we don't take automatic action on UN M.49 codes. This is now spelled out in the draft. Only if someone tries to register "888" will any timing come into effect.

Mirroring of ISO 3166, by contrast, *is* automatic. If SX is assigned, then it appears in the registry and "888" is no longer valid to register. I added this text to spell it out:

<t>UN numeric codes for countries or areas with ambiguous ISO 3166 alpha-2 codes as defined in <xref target="ianastability"/> MUST be entered into the registry according to the rules in that section and MUST be used to form language tags that represent the country or region for which they are defined.</t>

<t>UN numeric codes for countries or areas for which there is an associated ISO 3166 alpha-2 code in the registry MUST NOT be entered into the registry and MUST NOT be used to form language tags. Note that the ISO 3166-based subtag in the registry MUST actually be associated with the UN M.49 code in question.</t>

> 
> Peter said a fixed delay is bad, e.g. 3 months makes no sense
> if SX is available after 2 weeks.  I don't see the problem with
> ISO 3166-1 being faster than we fear.
[Addison Phillips] 

The problem would be if ISO 3166 were taking a long time and the UN M.49 code were requested in an attempt to get around them.
> 
> We only need a delay for the registration of UN numbers without
> alpha-2 code.  Otherwise - conflict or not - the case is clear,
> either add alpha-2 (no conflict) or number (conflict, e.g. BU).
[Addison Phillips] 

Yes, exactly so.
> 
> Peter's idea "consensus by the language tag list" might work.
[Addison Phillips] 

Actually, I think that was the heart of my idea :-).
> 
> And what do we expect if somebody wants 831..833 one day after
> date-B, while others prefer to wait for a "nicer" GG, IM, JE ?
[Addison Phillips] 

That's the question.
> 
> Are they allowed to fix it if they get it "wrong" ?  In other
> words if they first give up waiting and register 831..833, but
> later GG, IM, JE are available.  Can they then register these
> alpha-2 codes in addition to 831..833 ?  I certainly hope so.
> 
Currently, no. I suppose that (since nothing forbids it) the UN M.49 record could get a Preferred-Value that points to the ISO 3166 code. 

This issue would be: consider an area that gets an UN M.49 code. This code gets registered via the process. Sometime later the ISO 3166 code gets registered and the UN M.49 code gets deprecated and mapped. Then the place changes its name and gets assigned the alpha2 code 'BU' as a result. Now what happens? Our escape hatch is effectively blocked.

The alternative is to forbid registration of UN M.49 codes "on a whim" via the registration process altogether. The escape hatch can never get blocked in this way. Given that we're talking about the Channel Islands as the *sole* representative of this, it doesn't break my heart to do this.

Addison

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 14 Jun 2005 20:18:01 -0700

Addison Phillips <addison dot phillips at quest dot com> wrote:

> This issue would be: consider an area that gets an UN M.49 code. This
> code gets registered via the process. Sometime later the ISO 3166 code
> gets registered and the UN M.49 code gets deprecated and mapped. Then
> the place changes its name and gets assigned the alpha2 code 'BU' as a
> result. Now what happens? Our escape hatch is effectively blocked.
>
> The alternative is to forbid registration of UN M.49 codes "on a whim"
> via the registration process altogether. The escape hatch can never
> get blocked in this way. Given that we're talking about the Channel
> Islands as the *sole* representative of this, it doesn't break my
> heart to do this.

I think this is a very important issue, especially if (like Frank) one
believes that countries will continue along a brisk pace of merging and
splitting and name-changing.  There should definitely be a clear path to
the "emergency exit," as Frank has called it.

Manual registration of UN M.49 codes as region subtags, if not outright
forbidden, ought to be like registering 8-letter primary language
subtags -- we'd better be doggoned good and sure the entity in question
isn't going to get an ISO code any time soon.

---

From: "Addison Phillips" <[email-masked]>
Date: Wed, 15 Jun 2005 09:18:16 -0700

Yes, at least in theory they could. A pointer to ISO 3166 MA is probably the response such a request would get.

Addison

Addison P. Phillips

> Sent: 2005?6?15? 7:56
> > But forbidding all such registrations might be a better move
> > (see response to Frank for why). UN M.49 codes are the escape
> > hatch for ISO 3166 reassignments, not an alternate scheme.
> 
> Based on KISS and from an editorial POV it's a good plan, so I
> could live with it.  And if they want 831..833 despite of this
> obscure "proces failure" between ISO 3166 and their Duke, are
> they free to register variants for some affected languages ?
> 
>                       Bye, Frank
> 
> 
>