Subject: RE: [Ltru] Re: "Obsolete" region subtags

From: "Addison Phillips" <[email-masked]>
Date: Tue, 15 Mar 2005 09:14:45 -0800

We chose the UN M.49 numbers as the backup for ISO 3166 codes precisely because they are stable.

Allowing multiple subtags to mean the same thing, as Frank suggests below, would be a problem. Many language tag processors that I know of are implemented based solely on the values of the tags themselves, with no external knowledge baked into them. The existence of a registry might change that to some degree, but you'll still have many of what the draft calls "well-formed" processors for which "GB" is just a token.

To take the step you suggest, while an improvement in clarity and stability, would require additional "smarts" in tag processors in order to do simple matching of tags. 

I think that the draft as it sits embodies most of your suggestion anyway. The relationship between ISO 3166 codes and UN M.49 codes is spelled out in Section 3.2. One of the side effects of the text in that section is that it demonstrates the UN M.49 code's cardinality in deciding what to do.

Your example of the CS/YU registry entries below is very clear and perhaps the UN M.49 codes should be notes in the registry to assist with clarity in the future. I note, however, that it is an example of changes before the adoption of the draft. If these changes were to take place under the draft (tomorrow instead of a few years ago), then the results would be very different:

> region |  BA | ... |
> region |  CS | Czechoslovakia | 
> region |  CZ | ... | 
> region |  HR | ... | 
> region |  MK | ... | 
> region |  SI | ... | 
> region |  SK | ... | 
> region |  YU | ... | deprecated, use 891
> region | 891 | Serbia and Montenegro | 

In other words, if ISO 3166 doesn't stick to 50-year reservations of withdrawn codes, we will see sporadic creation of numeric UN M.49 codes. Countries will probably take notice of this and try to avoid obtaining problematic codes when they change their names.

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 Frank Ellermann
> Sent: Monday, March 14, 2005 8:04 PM
> To: [email-masked]
> Subject: [Ltru] Re: "Obsolete" region subtags
> 
> John Cowan wrote:
> 
> > We don't want to allow both en-GB and en-826 at the same
> > time.  That would be very bad for interoperability.
> 
> There's no problem with interoperability, if all CCs have a
> canonical and stable UN number as long as the CC exists.
> 
> The draft already has many deprecated entries with pointers
> to new and stable canonical entries.
> 
> For the big CS mess the registry would have been:
> 
> region | CS | ... | 200
> region | YU | ... | 890
> 
> Snapshot after the split of CS:
> 
> region |  CS | ... | 200 | deprecated
> region |  CZ | ... | 203
> region |  SK | ... | 703
> region |  YU | ... | 890
> region | 200 | ... | | deprecated, use 203 or 703
> 
> Snapshot after the split of YU:
> 
> region |  BA | ... | 070
> region |  CS | ... | 200 | deprecated
> region |  CZ | ... | 203
> region |  HR | ... | 191
> region |  MK | ... | 807
> region |  SI | ... | 705
> region |  SK | ... | 703
> region |  YU | ... | 891 | note change from 890
> region | 200 | ... | | deprecated, use 203 or 703
> region | 890 | ... | | deprecated, use 070, 191, 705, 807, 891
> 
> Snapshot after the premature recycling of CS:
> 
> region |  BA | ... | 070
> region |  CS | ... | 891
> region |  CZ | ... | 203
> region |  HR | ... | 191
> region |  MK | ... | 807
> region |  SI | ... | 705
> region |  SK | ... | 703
> region |  YU | ... | 891 | deprecated
> region | 200 | ... | | deprecated, use 203 or 703
> region | 890 | ... | | deprecated, use 070, 191, 705, 807, 891
> 
> As you see the canonical UN number never changes, even if it's
> deprecated.  And the CC is only an alias of a canonical value,
> always reflecting the official ISO 3166 meaning, where it
> exists.  Kept as deprecated alias like e.g. CS until ISO 3166
> assigned a new official value.
> 
> All the tag reviewer has to do, is to figure out the UN number.
> 
>  [GB]
> > the latter would never become valid, even if the ISO 3166 MA
> > were to reassign "GB".
> 
> You're talking about the draft as it is, but I claim that it's
> broken, and propose a fix.  With this fix GB could be assigned
> to a new region when necessary (after a long transition period
> like at least 50 years).
>                             Bye, Frank
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 15 Mar 2005 21:47:22 +0100

At 18:14 15/03/2005, Addison Phillips wrote:
>Allowing multiple subtags to mean the same thing, as Frank suggests below, 
>would be a problem. Many language tag processors that I know of are 
>implemented based solely on the values of the tags themselves, with no 
>external knowledge baked into them. The existence of a registry might 
>change that to some degree, but you'll still have many of what the draft 
>calls "well-formed" processors for which "GB" is just a token.

I question myself on this. The DNS is 22 years old, the mail older. I 
understand that one wants to be careful at not changing them too much - yet 
the market will change them if it solved the spam. IDNs are one year and a 
half old and several consider that one can still change or even kill them. 
As far as I understand, you refer to applications resulting from RFC 3066, 
and may be from its predecessor? So they are 3 to 7 years old? They most 
probably are browsers/aplications which have anyway to be updated to 
support IDNs (applications needing to check languages are likely to also 
use IDNs)?

We are going to have a lot of changes in the DNS in the coming month to 
support the local TLDs which are to be a must. The support of the Tables 
will probably be required at users level, for 3+LD consistency checks,etc. 
(even if not planned yet). Many other applications would probably want 
then  to use functions using country codes if they were available.

Microsoft always said they wanted to watch the market reaction before 
implementing the IDN support in the OS. This WG could consider user located 
functions to get and integrate the IANA cc table and updates . It could 
then use them. Would it not be better to start anew while there is still a 
"small" base (RFC 3066 is still here for them) rather than to continue for 
ever with an old system?

BTW I personally think the IDN Tables and other TLD infos (such as the 
lingual aliases of the TLDs) are part of the Locale,
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 16 Mar 2005 13:10:52 +0100

Addison Phillips wrote:

> I think that the draft as it sits embodies most of your
> suggestion anyway.

For a "clean" start date like 1995 (RfC 1766) they'd be almost
identical, maybe minus the five notorious ccTLDs.  And they'd
stay that way for at least 5 years + 1 day.   Or at least 50
years if ISO 3166 adopts this transition period for old CCs.

The earliest differences could then creep into the registry
after 1995 +50 = 2045, if ISO 3166 is forced to recycle an old
country code.  With your startegy 3066bis would then stick to
the old 1995 CC, my strategy would allow to follow ISO 3166.

Both strategies are compatible with RfC 3066, arguably my idea
is "more compatible", because it lets ISO 3166 do whatever it
wants, like RfC 3066 does at the moment.

>> region | 891 | Serbia and Montenegro |

Yes, that's what you'd get for a 3066bis start date before the
split of CS.  Of course you won't pick this date, it would be
incompatible with today's RfC 3066.  IIRC Bruce found some Web
pages with a lang= or xml:lang= using the new CS in a 3066 tag.

> if ISO 3166 doesn't stick to 50-year reservations of
> withdrawn codes, we will see sporadic creation of numeric
> UN M.49 codes.

The "we" in Internet community would see it for any transition
period.  5 years or 50 years doesn't change the necessity to
find a good mnemonic in ISO 3166-1.  The "we" in you and me
would probably manage to never see this strange effect, if you
pick 1995 as start date, and if they don't invent immortality.

> Countries will probably take notice of this and try to avoid
> obtaining problematic codes when they change their names.

New countries won't pick their names only to avoid a frozen CC
in the 3066bis registry.  If FQ makes sense for say Quebec they
would go for it, and don't care about any FQ = Terre Adelaide.

                     Bye, Frank

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Mar 2005 14:17:31 +0900

[chairs hat mostly on]

This WG is not about IDNS or TLDs or similar things.

If you think that some insight may be gained from looking at
parallels, talking about other technology than language tags
may make sense, but we first would need some concrete
proposal. Just arguing that we can change anything because
browsers will have to change anyway doesn't help if we don't
have a concrete proposal of how to change it.

The best way for you to make a concrete proposal is to write
it up and submit it as a (personal) internet-draft, which
may or may not then be adopted by the WG. This is the
traditional style of working in the IETF.The second
best way is to send it to this list; this is okay in
particular if the proposal is concise.

If you have already made a concrete proposal, a pointer
may be okay, although if it hasn't been made on this
list, a copy would probably be better.

But please make very sure that you have a concrete
proposal, not only some general thoughts or oppinions.

Many thanks in advance.

Regards,    Martin.

At 05:47 05/03/16, JFC (Jefsey) Morfin wrote:
 >>Allowing multiple subtags to mean the same thing, as Frank suggests 
below, would be a problem. Many language tag processors that I know of are 
support the local TLDs which are to be a must. The support of the Tables 
will probably be required at users level, for 3+LD consistency checks,etc. 
(even if not planned yet). Many other applications would probably want then 
to use functions using country codes if they were available.

---

From: Martin Duerst <[email-masked]>
Date: Wed, 16 Mar 2005 18:27:01 +0900

[chairs hat off, mostly off topic]

You are right that technology sometimes changes very quickly.
But it is usually difficult to predict when that happens.

 >As far as I understand, you refer to applications resulting from RFC 
3066, and may be from its predecessor? So they are 3 to 7 years old? They 
most probably are browsers/aplications which have anyway to be updated to 
support IDNs (applications needing to check languages are likely to also 
use IDNs)?

Updating browsers for IDN is already happening. But this doesn't
guarantee that the update for language tagging can be piggybacked.
Browser makers tend to concentrate on the big issues.

 >We are going to have a lot of changes in the DNS in the coming month to 
support the local TLDs which are to be a must.

I sincerely hope non-ASCII TLDs will happen. But I think they will
first happen for ccTLDs.

 >The support of the Tables will probably be required at users level, for 
3+LD consistency checks,etc. (even if not planned yet).

I'd clearly disagree here. If any organization messes up their 3+LDs,
that's their own fault. The client side doesn't have to bother.

 >Many other applications would probably want then  to use functions using 
country codes if they were available.

I don't really see that. Maybe examples could help.

implementing the IDN support in the OS. This WG could consider user located 
functions to get and integrate the IANA cc table and updates. It could then 
use them.

What exactly are IANA cc tables? (pointers appreciated).
How are they related to language tags?

 >Would it not be better to start anew while there is still a "small" base 
(RFC 3066 is still here for them) rather than to continue for ever with an 
old system?

Only if the benefit of changing covers the costs of changing.
As I don't really have an idea what the new system you are
thinking of is looking like, I cant' really evaluate these
benefits and costs.

I very strongly think that there should be no lingual aliases
for TLDs. For many TLDs, I think there should be script equivalents,
but that's a different thing on two counts. Also, I don't think that
IDN tables should be part of a locale. A locale is essentially a
collection of preferences for a group of users. IDN tables simply
describe constraints on some particular kind of data (a domain
name label in a certain domain).

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Wed, 16 Mar 2005 18:06:19 +0900

At 02:14 05/03/16, Addison Phillips wrote:
 >would be a problem.

[chairs hat off]

I fully agree. The fewer alternatives for the same thing, the better.
We worked hard on RFC 3066 to make sure that only one of potentially
three codes for the same language (2-letter code, 3-letter bibliographic
code, 3-letter terminology code) was used, and that the solution was
compatible with RFC 1766.

Regards,   Martin.