Subject: Re: [Ltru] Editorial Comments Only--RFC4646bis-11

From: "Doug Ewell" <[email-masked]>
Date: Sat, 23 Feb 2008 11:50:59 -0800

Addison Phillips <addison at yahoo dash inc dot com> wrote:

>> What still remains open is what should happen when 3166/MA reassigns 
>> a code formerly used for one country to that same country.
>
> Yes, the Burma->Myanmar->Burma conjecture. Care was used not to 
> prohibit it here.

So, bottom line, is there:

(a) consensus to
(b) consensus not to
(c) no decision yet whether to

change the rule about Preferred-Value to allow the value to be modified? 
This has a direct impact on draft-4645bis, since the purpose of changing 
the rule is to get rid of the need to "chase pointers" to find the true 
preferred value.  I need to know whether the draft Registry needs to be 
changed for cases like Hakka.  Needless to say, this is anything but 
"editorial only."

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

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

---

From: Addison Phillips <[email-masked]>
Date: Sat, 23 Feb 2008 12:46:29 -0800

> So, bottom line, is there:

I support this one.

> changed for cases like Hakka.  Needless to say, this is anything but 

It depends on how we change it as to whether you have to change the 
"chase pointers". Allowing something is not the same as requiring it. 
But that said, I think it likely that you'd want to make the change.

I agree that this is a technical change. We are "destabilizing" 
something (although I suspect that many of us thought it wasn't intended 
to be stable).

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Sat, 23 Feb 2008 13:49:16 -0800

Also in favor of (a).

While it is a technical change, it is not in practice destabilizing
anything, since the canonical form was always already "unstable", because of
the possibility (and reality) of adding Preferred-Value to any subtag.

Mark

-- 
Mark

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 23 Feb 2008 13:57:32 -0800

> But that said, I think it likely that you'd want to make the change.

I think it would be regarded as a mistake on our part not to change 
them.

Very well, then: upon Randy's confirmation of this change, I will edit 
draft-4645bis so that the Preferred-Values for "i-hak" and "zh-guoyu" 
will be "hak" and "cmn" respectively.  (Any others?)

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 23 Feb 2008 17:12:07 -0800

Hi -

(Please note, I've put this discussion back into the correct thread!)

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Saturday, February 23, 2008 11:50 AM
> Subject: Re: [Ltru] Editorial Comments Only--RFC4646bis-11
>

As a technical contributor...
I still think this is trumped (at least in spirit) by 3.4 (10) (D):

     D.  For ISO 3166 codes, if the newly assigned code's meaning is
         associated with the same UN M.49 code as another 'region'
         subtag, then the existing region subtag remains as the
         preferred value for that region and no new entry is created.
         A comment MAY be added to the existing region subtag
         indicating the relationship to the new ISO 3166 code.

> (c) no decision yet whether to

As co-chair...
Since part of the discussion appears to be in a thread labeled
"editorial", it'll take me a while to chase it down.  Hint for
the future: good subject lines result in quicker decisions.

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Sat, 23 Feb 2008 17:35:39 -0800

Let's suppose we have in 2008 the following in the registry, where =>
indicates a Preferred-Value.

BU
MM => BU
US

Let's suppose that ISO in 2010 changes US to UX and MM to BU. We will
clearly make the change of US to UX. For BU/MM we have three choices:

A. Switch back to BU.
Result:

BU => MM
MM
US => UX
UX

B. Keep MM.
Result:

BU
MM => BU
US => UX
UX

C. Use the UN M.49 code (say, 666).
Result:

666
BU => 666
MM => 666
US => UX
UX

I find any choice but A to be bizarre. Why should the preexistance of BU --
with the same meaning! -- cause us to do something different with MM than we
do with US?

We need to make the appropriate changes to do the expected, reasonable
thing.

Mark

---

From: Addison Phillips <[email-masked]>
Date: Sat, 23 Feb 2008 19:03:33 -0800

Did you make a typo, Mark?

Today we have:

BU => MM
MM

Your text suggest that in your hypothetical you would support doing "B":

MM => BU (point MM to BU)
BU (remove the p-v)

But your text *says* doing A, which is:

MM (no change)
BU => MM (and no change)

Addison

Mark Davis wrote:
> I find any choice but A to be bizarre. Why should the preexistance of BU 
> -- with the same meaning! -- cause us to do something different with MM 
> than we do with US?
> 
> On Sat, Feb 23, 2008 at 5:12 PM, Randy Presuhn 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi -
> 
>      > From: "Doug Ewell" <[email-masked]
>     <mailto:[email-masked]>>
>      > To: "LTRU Working Group" <[email-masked] <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 23 Feb 2008 20:59:14 -0800

Hi -

> From: "Mark Davis" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Saturday, February 23, 2008 5:35 PM
> Subject: Re: [Ltru] Updating Preferred-Value: field
>
> clearly make the change of US to UX. 

No, we shouldn't.  Section 3.4 (10) (D):

> For BU/MM we have three choices:
>
> A. Switch back to BU.

No, we shouldn't.  Section 3.4 (10) (D):

...
> B. Keep MM.

This is correct.

> C. Use the UN M.49 code (say, 666).

No, see section  2.2.4 (3) D:
       D.  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
...
> with the same meaning! -- cause us to do something different with MM than we
...

The premise, that US -> UX would be possible, is incorrect.

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Sat, 23 Feb 2008 21:17:13 -0800

Those are good points. Let me look the text over in more detail.

Mark