Subject: RE: [Ltru] Re: Proposed changes to region subtags

From: "Addison Phillips" <[email-masked]>
Date: Fri, 1 Apr 2005 12:45:58 -0800

Some comments below.

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: vendredi 1 avril 2005 12:03
> To: [email-masked]
> Subject: [Ltru] Re: Proposed changes to region subtags
> 
> Doug Ewell wrote:
> 
> > Last Call for the registry draft is scheduled for May
> 
> I really don't care about timetables decreed by somebody
> else, they are free to fix it when necessary.
> 
> > I think we need to figure out the rules now, rather
> > than saving things for an unspecified "later."
> 
> Too many changes at once would be confusing.  One draft
> per month would be fine for me, let's see an April draft
> soon, and then a draft registry based on whatever it says.
[Addison Phillips] 

Documents that are "somewhere in the middle" of a change are confusing. We should make all of the necessary changes to the draft to make it coherent, i.e. a plausible candidate for RFC-hood. This doesn't rule out make more additions or emendations later.

> 
> Depending on our editors this could already specify the
> record-jar or similar format, so that you have a chance
> to create a proper first I-D in this format.
[Addison Phillips] 

(editor hat on)

It doesn't because that debate seems to have fallen off without a genuine consensus being reached. I *think* the consensus is record-jar. And maybe also XML. 

At present I intend that when I next sit down to update the editor's copy (that usually being my job in our editing duopoly) I'll incorporate the changes necessary to make record-jar the format with no mention of XML. Any objections?

(removing editor hat)

> > Can you think of a use case for 200?
> 
> As an optional replacement for old cs-CS / sk-CS / rom-CS
> tags.  We want backwards compatibility with BU / DD / YD,
> therefore we should also offer it for the old CS.
[Addison Phillips] 

More to the point: what is the rule for registry conversion to include 200 and not some other codes? (more below)
> 
> > It's not needed for current tagging needs, nor for
> > backward compatibility.
> 
> So what is the correct replacement for rom-CS if you're
> very sure that the CS is the old CS ?  Just rom ?  I've
> no idea which other languages might be relevant in the
> old CS.  Maybe hu-CS, what is this, hu-SK, or is hu-CZ
> also possible ?
[Addison Phillips] 

Rule 0: tag content wisely.

No matter what we pick as the meaning for 'CS', some existing content could have its meaning invalidated and need to be "retagged". That choice will be done in the here-and-now. For 'YU'/'CS', appropriate choices exist in the registry which "mean the right thing", so I think 200 may not be useful to codify after all.

This keeps the rules for M49 numbers simple:

1. Create an M49-based registration for any number that 3166 doesn't encode (with certain exceptions, i.e. the economic codes---sorry, no "English as spoken in the 10 currently poorest countries").
2. Create an M49-based registration for any 3166 code that collides with an existing registry region entry.

The additional rule you suggest would be, btw:

3. Create an M49-based registration for any 3166 code that was withdrawn after Date A and subsequently assigned a new value before Date B (in Cowan's terms).

> 
> If both are possible somebody trying to fix it could need
> a 200 created by a better "split" rule.  Or he needs an
> info to use hu-SK if hu-CS was the old CS.  It's messy,
> minority languages in the old CS could be also minority
> languages in the new CS (rom, hu, yi, de, what else ?).
> 

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

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 02 Apr 2005 00:36:35 +0200

Addison Phillips wrote:

> Documents that are "somewhere in the middle" of a change are
> confusing. We should make all of the necessary changes to
> the draft to make it coherent, i.e. a plausible candidate for
> RFC-hood.

Yes.  And Doug's proposal was coherent, it defines 1988 as the
first of the two "start dates" (the 2nd date is just the day of
the publication of his future I-Ds).

> This doesn't rule out make more additions or emendations
> later.

The current rules handle some splits.  But we don't apply them
in the past for the old CS, that's why the old CS 200 is lost.

The current rules don't handle unions where the union inherits
the CC of one of its former parts, that's why we lost the old
DE and the old YE.  In practice probably irrelevant for these
two cases (for DE I'm almost sure).

But there's no guarantee that it's always irrelevant.  Today
something like ru-RU and ru-BY is allowed (I don't check this,
please adjust it if necessary).  If BY + RU form a union with
the new CC RU, and if the difference between ru-RU and ru-BY
was important, then a tagger willing to update old ru-RU tags
has a problem, the old region RU is lost.

IMHO Doug is wrong, we can delay this one minor point to draft
-02 without problem.  And if the "last call" is in June instead
of May then it won't be a side-effect of a simple "union" rule.

> I *think* the consensus is record-jar. And maybe also XML.

Me too, and for draft -01 the former is good enough.

> More to the point: what is the rule for registry conversion
> to include 200 and not some other codes? (more below)

It's trapped between date A and B, a hopeless case.  We could
create an ad hoc exception (ugly), and explain why that's never
again necessary (fine).  If we fix the problem for all future
splits and unions, where an alpha-2 CC changes its meaning as
defined by the corresponding UN numbers (old vs. new).

The current -00 rules preserve YU as code, but only the new
meaning.  Somebody trying to update old ??-YU tags would need
the old UN number for unclear cases.

> Rule 0: tag content wisely.

Also known as "pray that 639-3 comes a.s.a.p., and all these
funny region codes will be less important".

> For 'YU'/'CS', appropriate choices exist in the registry
> which "mean the right thing"

If you can identify "the right thing".  Otherwise all you know
is that the old tag "inherited" a new meaning, and the 3066bis
registry doesn't offer the UN number for the old meaning.

> 3. Create an M49-based registration for any 3166 code that
> was withdrawn after Date A and subsequently assigned a new
> value before Date B (in Cowan's terms).

No, I'd add the old UN number always as soon as new UN numbers
are assigned, and an old region is lost without this trick.  A
case like the old CS cannot happen again under the current
rules (the old CS would be frozen, the new CS gets a number).

But a case like the old YU is always possible, e.g. if the US
splits into a new smaller US + other parts.  One or two unclear
en-US pages would then need the old UN number.  Otherwise they
are automagically a (linguistical) part of the new smaller US.

                                   Bye, Frank