Subject: [Ltru] Updating Preferred-Value: field

From: John Cowan <[email-masked]>
Date: Fri, 15 Feb 2008 19:39:03 -0500

I propose the following change to the penultimate paragraph of 4646bis,
Editor's Draft, Section 3.1.6:

Original text:

The field 'Preferred-Value' MUST NOT be modified once created in the
registry. The field MAY be added to records according to the rules in
Section 3.3 (Maintenance of the Registry).

Proposed revised text:

The field 'Preferred-Value' MUST not be removed from a record.  If the
subtag described by the record becomes deprecated, this field MAY be
added according to the rules in Section 3.3.  In that case, any records
which refer to this one through their own 'Preferred-Value' fields are
updated to refer to the new preferred value, so that it is not necessary
to navigate from a deprecated subtag via another deprecated subtag to
reach a preferred subtag.

Discussion:

This is a substantive change which bites the bullet directly and allows
update of the 'Preferred-Value' field so that it at all times refers to
the value which is in fact preferred.

-- 
A rose by any other name                            John Cowan
may smell as sweet,                                 http://www.ccil.org/~cowan
but if you called it an onion                       [email-masked]
you'd get cooks very confused.          --RMS
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Fri, 15 Feb 2008 19:45:58 -0500

> reach a preferred subtag.

Oops.

s/are updated/MUST be updated

-- 
Even a refrigerator can conform to the XML      John Cowan
Infoset, as long as it has a door sticker       [email-masked]
saying "No information items inside".           http://www.ccil.org/~cowan
        --Eve Maler
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 15 Feb 2008 16:53:56 -0800

I agree with the intent, or at least some of it. However,

   1. It doesn't fix the case I cited, of BU -> MM -> BU. So I would not
   be in agreement with the text as given. If we were going to do this, we
   should do it completely.
   2. The instructions as to what to do to the registry to *other *tags
   when a given Preferred-Value is added or changed probably belong in
   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-11.html#registrationProc
   3. Other parts of the text would need to be touched for consistency,
   like
   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-11.html#ianastability

Mark

On Feb 15, 2008 4:39 PM, John Cowan <[email-masked]> wrote:

> may smell as sweet,
> http://www.ccil.org/~cowan <http://www.ccil.org/%7Ecowan>

-- 
Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 16:57:08 -0800

Hi -

> From: "John Cowan" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, February 15, 2008 4:39 PM
> Subject: [Ltru] Updating Preferred-Value: field
>

> the value which is in fact preferred.
...

As a technical contributor, I have no objection to this proposal.

(Though some might trip over the optionality implied by "MAY" -
more robust would be "If the subtag described by the record
becomes deprecated and there is a replacement mapping, this
field MUST be added according to the rules in Section 3.3. ")
 
An existing application which recursively follows "Preferred-Value"
fields through the registry would still work correctly if this change
is made.  The additional effort impacts only the registry
maintainers (i.e., [email-masked]).  Consequently, the
technical impact of this change is minimal.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 17:02:35 -0800

Hi -

As a technical contributor...

> From: "Mark Davis" <[email-masked]>
> To: "John Cowan" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, February 15, 2008 4:53 PM
> Subject: Re: [Ltru] Updating Preferred-Value: field
>

...

I disagree.  I think changing the preferred form from BU to MM to BU would
be a very bad thing to do if BU and MM and BU refer to essentially the same
thing for purposes of tagging.

Randy

---

From: John Cowan <[email-masked]>
Date: Fri, 15 Feb 2008 20:10:07 -0500

>    be in agreement with the text as given. If we were going to do this, we

That would be the time, IMHO, to use the 3-digit M.49 code.

>    http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-11.html#ianastability

Can you propose text?

-- 
Is a chair finely made tragic or comic? Is the          John Cowan
portrait of Mona Lisa good if I desire to see           [email-masked]
it? Is the bust of Sir Philip Crampton lyrical,         http://ccil.org/~cowan
epical or dramatic?  If a man hacking in fury
at a block of wood make there an image of a cow,
is that image a work of art? If not, why not?               --Stephen Dedalus
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 15 Feb 2008 19:05:26 -0800

Let me spell this out more.

The same country (UN code = 100) has already had two ISO names: BU already
changed name to MM. That is already done, in the past. So UN:100 corresponds
to two ISO names: BU and MM, with BU deprecated, and MM preferred.

So we have two tags for the same thing: my-BU and *my-MM* (with the
preferred one bold).

Now suppose that in 2011, ISO changes the name of UN:100 back to BU. That is
certainly a possibility. At that point we are obliged to deprecate MM. We
have two choices.

   1. Use the UN number, so we now have *three* tags that mean the same
   thing: my-BU, my-MM, and *my-100*
   2. Use the former BU, so we still have only two valid tags: *my-BU*and my-MM.

Option #2 is, in my opinion, much cleaner and more understandable. It is
bizarre in #1 to add yet another code, when BU is exactly the same country,
*and* the preferred ISO code. We should only use the UN code if we have to,
to avoid a collision. But this is *not* a collision -- they are different
codes for the same entity.

Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 21:38:37 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, February 15, 2008 7:05 PM
...
...

WHY would we be *obliged* to deprecate MM in this scenario?

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 15 Feb 2008 22:28:21 -0800

>WHY would we be *obliged* to deprecate MM in this scenario?Because that is
required by BCP 47:
3.3.  Maintenance of the Registry Maintenance of the registry requires that
as codes are assigned or withdrawn by ISO 639, ISO 15924, ISO 3166, and UN
M.49, the Language Subtag Reviewer MUST evaluate each change and determine
the appropriate course of action according to the rules in this document.
Such updates follow the registration process described in Section 3.5
(Registration
Procedure for Subtags)<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-11.html#registrationProc>.

...

3.4.  Stability of IANA Registry Entries...
Codes assigned by ISO 639, ISO 15924, or ISO 3166 that are withdrawn by
their respective maintenance or registration authority remain valid in
language tags. A 'Deprecated' field containing the date of withdrawal MUST
be added to the record. If a new record of the same type is added that
represents a replacement value, then a 'Preferred-Value' field MAY also be
added. The registration process MAY be used to add comments about the
withdrawal of the code by the respective standard.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 22:47:40 -0800

Hi -

> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Friday, February 15, 2008 10:28 PM

> Because that is
...

I thought this was all 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.

Randy

---

From: "Kent Karlsson" <[email-masked]>
Date: Sat, 16 Feb 2008 11:56:25 +0100

...
> field MUST be added according to the rules in Section 3.3. ")

No, because it may be the case that there is no preferred value.
See e.g. sh and zh-min in draft-ietf-ltru-4645bis-04.txt.

> technical impact of this change is minimal.

That agrees with my intention. (I will not propose any alternate change
of text for 4646bis, though I think the BU->MM->BU case that Mark mentioned
would be unproblematic per se. I think the rules were intended to prevent
ambiguities to arise, but in such an example there would be no ambiguity,
so the rules even if amended as above are still a bit too strict. But
maybe this is as far as we can get at this point.)

	/kent k