Subject: Re: [Ltru] Proposed edit MD12 (davis)

From: "Doug Ewell" <[email-masked]>
Date: Fri, 15 Feb 2008 22:10:43 -0800

John Cowan <cowan at ccil dot org> wrote:

>> It sounds like it's time to start a different thread.  The change 
>> proposed in *this* thread was to recommend adding a comment regarding 
>> the canonical form under certain circumstances. Do we or do we not 
>> have agreement regarding *that* proposal?
>
> I am opposed to the idea of adding such a comment, as I do not believe 
> the contents of Comment fields should be part of the algorithms of BCP 
> 47.

Actually, the proposed comment would not form part of the algorithm. 
Rather, it would help remind implementers and tourists alike that the 
correct algorithm is to follow the chain of Preferred-Values, instead of 
stopping after the first one.

That said, I too am concerned about specifying algorithmic behavior in 
Comments fields.  Remember that the current Registry has a group of 
rather inane Comments fields like this:

Type: grandfathered
Tag: i-navajo
Description: Navajo
Added: 1997-09-19
Preferred-Value: nv
Deprecated: 2000-02-18
Comments: replaced by ISO code nv

Some people who don't understand that the Comments field in this case 
simply mirrors the Preferred-Value field might think the Comments field 
is normative.

I would be leery about adding comments that people might *think* form 
part of the algorithm, as John did, even if they don't really.

In any case, any proposal in 4646bis that imposes a change on the 
updated Registry in 4645bis should be considered technical, not 
editorial.

--
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: Thu, 21 Feb 2008 20:16:16 -0800

I have followed this thread down to here, which is apparently the 
current end. With regard to inclusion of the Comment, I note that it 
would not just be a one-time event, but also potentially require 
maintenance, which is a pain and might be overlooked.

I *also* note a couple reasons why we didn't allow a change to the 
Preferred-Value but instead noted many times in RFC 4646 that you have 
to follow the chain. First, region codes in particular change with some 
regularity. The LSR would have to recognize that one change affected 
several subtags and update each one. Second, the transitive nature 
allows one to reconstruct canonicality of a language tag as at a 
particular date, a feature that is not possible if you remove the chain.

However, I agree with Mark's Burma case. We should, in my opinion, relax 
the stability of Preferred-Value to allow removal or modification. This 
would allow modifications to remove transitive links (killing the second 
case above). It would also require some more modifications to stability 
rules and maintenance requirements.

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: Fri, 22 Feb 2008 07:55:21 -0800

If we can get consensus on that, I can help you track down the points in the
text that need changing.
Mark

-- 
Mark

---

From: Addison Phillips <[email-masked]>
Date: Fri, 22 Feb 2008 08:20:57 -0800

I think there are two things here:

1. Are we willing to forego the "reconstruct as at date" feature?

2. How should Preferred-Value be stabilized?

For the latter, I think the question is whether we should allow 
registration requests for Preferred-Value removal independent of outside 
standard activity (i.e. for cases other than an action by one of the ISO 
groups). For the former, I don't know that anybody has implemented this 
capability to date---I certainly have not.

Addison

Mark Davis wrote:
> If we can get consensus on that, I can help you track down the points in 
> the text that need changing.
> 
> Mark
> 
> On Thu, Feb 21, 2008 at 8:16 PM, Addison Phillips <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 22 Feb 2008 08:50:42 -0800

> 1. Are we willing to forego the "reconstruct as at date" feature?

I think someone (John?) pointed out to me on the list that we don't
currently guarantee that in the spec, and that it is currently not possible
-- one cannot reliably reconstruct the complete status of the registry as of
a given date from the information currently there. (And I don't know that
anyone especially needs that feature, even if it is possible.)

> groups).

What I think we want to do is mirror the language for Deprecated: "Usually,
the addition of a 'Deprecated' field is due to the action of one of the
standards bodies, such as ISO 3166, withdrawing a code."

So we could say

"Usually the addition, removal, or change in a Preferred-Value field for a
subtag is to reflect changes in one of the source standard, such as ISO
3166. For example, if an ISO 3166 region code is deprecated in favor of
another code, that SHOULD result in changes in the Preferred-Value field.
The changes MAY affect other subtags as well.

   - Suppose that subtag X has a Preferred-Value of Y. If Y changes to
   have a Preferred-Value of Z, then the Preferred-Value for X MUST also change
   to be Z.
   - Suppose that a variant subtag 'foobar' represents a language not yet
   available in ISO 639-3. The later addition of the corresponding language
   code in ISO SHOULD result in the addition of a Preferred-Value for
   'foobar'."

Add also in 3.1.6:

"Every subtag with a Preferred-Value field MUST also have a Deprecated
field."

...

"Usually the addition or removal of a Deprecated field is to reflect changes
in one of the source standard, such as ISO 3166.  ..."

====

We also need a fix for "These values form three groups:". This needs to be
changed into: "Some examples of this are:"

The reason for this change is that we clearly want to allow a registered
language subtags (and variants) to be Deprecated and Preferred-Valued: if
there is a registration for 'foobar' that later ends up having a new ISO 639
code, we want to be able to deprecate it and point to the new value.

So really any subtag has the potential of having Deprecated and
Preferred-Value attached to it.

> For the former, I don't know that anybody has implemented this