Subject: [Ltru] Re: zh-hakka

From: "Doug Ewell" <[email-masked]>
Date: Tue, 19 Sep 2006 07:18:41 -0700

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

>> This would avoid the need for repetition when calculating the 
>> preferred value.
>
> It also simplifies pointer checks, there's never a danger of A -> B -> 
> C -> A, if A *_must_* point to something that has no further pointer.

I think we are again trying to legislate against the unthinkable.  Once 
the Registry has been created, only newly formed subtags (and tags 
composed from them) get to be Preferred-Values.  There is no reasonable 
chance that ietf-languages will ever make an older (sub)tag the 
Preferred-Value for a newer one.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/
RFC 4645  *  UTN #14

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

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 19 Sep 2006 07:15:45 -0700

Stephane Bortzmeyer <bortzmeyer at nic dot fr> wrote:

> xE-Lxs-qu is indicated as well-formed but I do not think so. Because 
> of "Lxs", it can only be and extension and therefore, "qu" is 
> forbidden (xE-Lxs is well-formed, as well as xE-Lxs-quT).

Be careful not to confuse "extended language" or "extlang" subtags, 
which are 3 letters, with "extension" subtags, which cannot appear 
before a region.

---

From: Addison Phillips <[email-masked]>
Date: Tue, 19 Sep 2006 08:03:30 -0700

Doug Ewell wrote:
>  There is no reasonable

That might not turn out to be true. For example, sometimes countries 
merge together.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 19 Sep 2006 17:04:50 +0200

Doug Ewell wrote:

>> there's never a danger of A -> B -> C -> A, if A *_must_*
>> point to something that has no further pointer.
 
> I think we are again trying to legislate against the
> unthinkable.
[...]
> There is no reasonable chance that ietf-languages will ever
> make an older (sub)tag the Preferred-Value for a newer one.

Not intentionally, but with a valid A -> B and a new subtag C
deprecating B you get A -> B -> C, and a simple typo could
twist this into A -> B -> A.  Admittedly I like graph theory.

Frank

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 19 Sep 2006 21:32:11 -0700

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

>> There is no reasonable chance that ietf-languages will ever make an 
>> older (sub)tag the Preferred-Value for a newer one.
>
> deprecating B you get A -> B -> C, and a simple typo could twist this 
> into A -> B -> A.  Admittedly I like graph theory.

Typos in any of the the normative parts of the Registry could cause any 
number of problems.  That's why some of us are watching diligently every 
time IANA releases a new version, and scrutinizing the registration 
forms with a magnifying glass before they are submitted to IANA.

IANA is not perfect.  Already since the "RFC 3066bis" era began, they 
have released one with a duplicated record, one with a missing Type 
field, and one with a multi-line Comments field that was missing the 
critical leading spaces on the second line.  Because we are watching 
carefully for typos such as these, they were fixed quickly and the 
number of users that were affected is most likely zero.

> That might not turn out to be true. For example, sometimes countries 

That's a good point.  I take back the overly broad statement.

Let's consider the case of countries merging.  Since Serbia and 
Montenegro has been such a commonly cited example in LTRU, let's stay 
with it.

In the next few weeks, or months or something, ISO 3166/MA will decide 
on new alpha-2 code elements for Serbia and for Montenegro, now that 
they have agreed to break up.  I don't have any inside knowledge on what 
the code elements will be, but two widely reported possibilities are SP 
and ME, so let's assume that for now.

Naturally, these code elements will be transformed into RFC 4646 region 
subtags, but the existing subtag CS will *not* be given a 
Preferred-Value of either SP or ME.  If the two countries --  
hypothetically speaking -- should decide to reunite at a later date, the 
subtags SP and ME would probably be assigned a Preferred-Value of CS, 
but there would be no circularity problem.  I'd be interested if 
somebody could come up with a plausible scenario that would result in 
circular P-V assignments.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 20 Sep 2006 09:14:03 +0200

Doug Ewell wrote:

> That's why some of us are watching diligently every time IANA
> releases a new version, and scrutinizing the registration

My (now two) magnifying glasses don't catch unintended cycles.
With a rule "pointers only to non-deprecated (sub)tags" they
could easily catch such typos.

> I'd be interested if somebody could come up with a plausible
> scenario that would result in circular P-V assignments.

MY reverting to BU, or C? reverting to ZR, that might not work
as expected with 4646 rules (too lazy to check).  With Martin's
proposal it works, the BU -> MY pointer would be replaced by a
BU -> BU pointer, and the fine print would say that this should
be reduced to no pointer at all.  Adding MY -> BU as expected.

Frank

---

From: John Cowan <[email-masked]>
Date: Wed, 20 Sep 2006 08:35:14 -0400

Doug Ewell scripsit:

> I'd be interested if somebody could come up with a plausible scenario
> that would result in circular P-V assignments.

What about a country reverting to an earlier name?  We have two historical
examples I can think of offhand, Central African Republic -> Central
African Empire -> Central African Republic (which probably didn't affect
the code) and Dem. Rep. of Congo -> Zaire -> Dem. Rep. of Congo (which
did, fortunately before Date A).

We might have another someday in Burma -> Myanmar -> Burma, since the
dissidents (I believe this is correct) object to the process by which
the (Latin-script) name of the country was changed.  We already have BU
deprecated in favor of MM; if the name is changed back and the old code
is revived, we might end up with MM deprecated in favor of BU.

-- 
                Si hoc legere scis, nimium eruditionis habes.

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 20 Sep 2006 06:14:34 -0700

John Cowan <cowan at ccil dot org> wrote:

> the (Latin-script) name of the country was changed.  We already have 
> BU deprecated in favor of MM; if the name is changed back and the old 
> code is revived, we might end up with MM deprecated in favor of BU.

That could only happen if we had a provision to un-deprecate a record, 
which I don't think we do.

It might not hurt to add a sentence to (what is now) Section 3.1.3.3 to 
state that deprecation is forever, assuming we want that.

---

From: John Cowan <[email-masked]>
Date: Wed, 20 Sep 2006 09:28:58 -0400

> which I don't think we do.

In that case, I guess we'd have to go for the UNSD numeric code,
namely 104.

> state that deprecation is forever, assuming we want that.

Good idea.

-- 
John Cowan   <[email-masked]>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 20 Sep 2006 06:42:09 -0700

John Cowan <cowan at ccil dot org> wrote:

>>> ... We already have BU deprecated in favor of MM; if the name is 
>>> changed back and the old code is revived, we might end up with MM 
>>> deprecated in favor of BU.
>>
>> That could only happen if we had a provision to un-deprecate a 
>> record, which I don't think we do.
>

Would we do that, or would we simply add a Description field for the new 
name?  See the "Burkina Faso" example in Section 3.4 (although that 
refers to changing a Description, something that is now discouraged).

This assumes that the entity in question remains the same, as judged by 
its UN code element, and only the name has changed.

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Sep 2006 11:11:08 -0700

Hi,

On Sep 19, 2006, at 9:32 PM, Doug Ewell wrote:
> IANA is not perfect.

Indeed.  We apologize for any errors that might have cropped up  
during IANA processing of registry modification requests and we'd be  
very interested in working with interested parties in improving our  
processes such that those errors aren't repeated (this is one of the  
reasons why we're doing the internal XMLization -- it enables simpler  
automation the registry modifications).

> In the next few weeks, or months or something, ISO 3166/MA will  
> decide on new alpha-2 code elements for Serbia and for Montenegro,  
> now that they have agreed to break up.  I don't have any inside  
> knowledge on what the code elements will be, but two widely  
> reported possibilities are SP and ME, so let's assume that for now.

Actually, I believe they're planning on proposing RS for Serbia...

Rgds,
-drc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Sep 2006 22:19:45 +0200

On Wed, Sep 20, 2006 at 11:11:08AM -0700,
 David Conrad <[email-masked]> wrote 
 a message of 28 lines which said:

> We apologize for any errors that might have cropped up during IANA
> processing of registry modification requests and we'd be very
> interested in working with interested parties in improving our
> reasons why we're doing the internal XMLization -- it enables
> simpler automation the registry modifications).

Automatically testing the registry to catch syntax errors or
inconsistencies is so obvious that I'm surprised it is not done yet
:-} It's the equivalent of integrity rules in DBMS.

To do it, there are several possibilities: using XML + a schema
language like RelaxNG + a rule language like Schematron is certainly a
possible way. Using a custom program is possible, too. Does anyone
have one for LTRU (I might write it myself otherwise)?

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 21 Sep 2006 00:49:24 +0200

Stephane Bortzmeyer wrote:

> Using a custom program is possible, too. Does anyone

Doug has one (I think), and I've a REXX script for the
4646 format (= no extlang), mainly to create a table of
Suppress-Scripts, but also doing case-insensitive XREFs,
and listing the known "deprecated before added" cases.

I plan to improve the DTD-based ID + IDREF(S) check to
use a format that might also work for Debbie's purpose,
apparently that needs your "elements for everything"
approach (<added>, <subtag>, <tag>)

Frank

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 20 Sep 2006 22:20:13 -0700

David Conrad <david dot conrad at icann dot org> wrote:

>> IANA is not perfect.
>
> Indeed.  We apologize for any errors that might have cropped up during 
> IANA processing of registry modification requests and we'd be very 

No problem.  I'm sure you won't mind some extra pairs of eyes to help 
maintain a high standard of quality.  (BTW, the new 2006-09-20 version 
of the Registry looks great.)

>> knowledge on what the code elements will be, but two widely reported 
>> possibilities are SP and ME, so let's assume that for now.
>

I know the Serbian government proposed RS (for "Republic of Serbia"), 
and I've heard alternatively that ISO (a) supports it or (b) opposes it 
because of their policy against using words like "Republic" to make the 
code element.  I guess we won't know for sure until the formal 
announcement.  In any case, I was just using it for illustration.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 21 Sep 2006 08:09:24 +0200

Doug Ewell wrote:

> the new 2006-09-20 version of the Registry looks great.

validator.w3.org agrees with that:
http://validator.w3.org/check?uri=http%3A%2F%2Fxyzzy.webhop.info%2Fhome%2Fltru%2Flstreg9.xml

Ignore the US-ASCII blurb, my other provider would send the
missing charset=us-ascii parameter for Content-Type: text/xml

Frank

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Sep 2006 13:49:32 -0700

Doug,

On Sep 20, 2006, at 10:20 PM, Doug Ewell wrote:
> I'm sure you won't mind some extra pairs of eyes to help maintain a  
> high standard of quality.

Not at all.  On the contrary, the more the merrier...

Rgds,
-drc

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 21 Sep 2006 23:37:22 +0100

Doug wrote:

> I know the Serbian government proposed RS (for "Republic of 
> Serbia"), and I've heard alternatively that ISO (a) supports 
> it or (b) opposes it because of their policy against using 
> words like "Republic" to make the code element.  I guess we 
> won't know for sure until the formal announcement.  In any 
> case, I was just using it for illustration.

Unofficial Country Code Info:

 RS/SRB for Serbia
 ME/MNE for Montenegro

I would expect a newsletter to be published within the next 4-5 weeks
displaying the official results.  I don't expect there to be any changes but
it isn't official until the voting is over and the Newsletter published!  

Best regards

Debbie

> -----Original Message-----
> From: Doug Ewell [mailto:[email-masked]] 
> Sent: 21 September 2006 06:20
> To: LTRU Working Group
> Cc: Frank Ellermann
> Subject: Re: [Ltru] Re: zh-hakka
> 
> No problem.  I'm sure you won't mind some extra pairs of eyes 
> to help maintain a high standard of quality.  (BTW, the new 
> 2006-09-20 version of the Registry looks great.)
> 
> I know the Serbian government proposed RS (for "Republic of 
> Serbia"), and I've heard alternatively that ISO (a) supports 
> it or (b) opposes it because of their policy against using 
> words like "Republic" to make the code element.  I guess we 
> won't know for sure until the formal announcement.  In any 
> case, I was just using it for illustration.
> 
> --
> Doug Ewell

---

From: John Cowan <[email-masked]>
Date: Thu, 21 Sep 2006 23:23:13 -0400

>  RS/SRB for Serbia

Well, let's hope that Republika Srpska (currently part of Bosnia)
never becomes a separate country.

-- 
Real FORTRAN programmers can program FORTRAN    John Cowan
in any language.  --Allen Brown                 [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 22 Sep 2006 14:21:16 +0200

Debbie Garside wrote:
 
> Frank wrote:
>>> Actually, I believe they're planning on proposing RS for >>> Serbia...

s/Frank/David/

> I would expect a newsletter to be published within the next
> 4-5 weeks displaying the official results.  I don't expect
> there to be any changes but it isn't official

Thanks for info, I got to update my rxwhois client for this.

Frank