Subject: [Ltru] Two questions on draft-4646bis-13

From: "Doug Ewell" <[email-masked]>
Date: Sun, 4 May 2008 23:51:43 -0600

1.  Preferred-Value of mismatched type

Section 3.1.6, "Preferred-Value Field" says this:

"Suppose that a variant subtag 'dialect' represents a language not yet 
available in any part of ISO 639.  The later addition of a corresponding 
language code in ISO 639 SHOULD result in the addition of a 
Preferred-Value for 'dialect'."

We've never allowed a variant subtag to have a Preferred-Value that is a 
language subtag.  In fact, Section 3.1.2 forbids this:  "For fields of 
type 'script', 'region', and 'variant', 'Preferred-Value'
contains the subtag of the same 'Type' that is preferred for forming the 
language tag."  I understand the problem this passage is trying to 
solve, but unfortunately the solution is not syntactically legal and we 
need to think this through a bit more.

2.  Chained Preferred-Values

Section 4.4, "Canonicalization of Language Tags" says this:

"Subtags of type 'Region' that have a Preferred-Value mapping in the 
IANA registry (see Section 3.1) MUST be replaced with their mapped 
value.  Note: In rare cases, the mapped value will also have a 
Preferred-Value."

Section 3.1.6 starts out merely recommending (not mandating) that 
Preferred-Values be updated to remove chains such as i-hak -> 
zh-hakka -> hak:  "The field MAY be added, changed, or removed..." 
However, the wording becomes more forceful later in the section: 
"Suppose that subtag 'XX' has a Preferred-Value of 'YY'.  If 'YY' later 
changes to have a Preferred-Value of 'ZZ', then the Preferred-Value for 
'XX' MUST also change to be 'ZZ'."  Since all of the existing chains are 
being removed in 4645bis, we need to decide whether future removal of 
chains is going to be mandatory or optional; the current wording leaves 
it up in the air.

--
Doug Ewell  *  Arvada, Colorado, 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]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Mon, 5 May 2008 13:20:57 -0700

> need to think this through a bit more.

You're right. This should read:

<t>Suppose that a registered language subtag 'dialect' represents a language not
yet available in any part of ISO 639. The later addition of a corresponding language
code in ISO 639 SHOULD result in the addition of a Preferred-Value for
'dialect'.</t>

For the variant case, we can't use Preferred-Value (by rule), but we can use Deprecated with a comment to indicate the new value.

The only solution to this would be to convert Preferred-Value from subtags to extended language ranges. This would require a change in the form of a number of P-V fields, not to mention having an impact on some implementations.

> However, the wording becomes more forceful later in the section:

That's not actually "more forceful". The ability to mutate or remove the field is one thing. The direction to specifically mutate it in certain cases is a separate issue.

> chains is going to be mandatory or optional; the current wording leaves

The real problem is the "note" in the first bit you quoted, allowing for chaining of P-V values. I can't think of any instances in which it makes sense to preserve a chain once we've decided to remove all chains. Thus, I've removed the "In rare cases..." note.

Addison

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 5 May 2008 13:26:38 -0700

Those changes look good to me.

On Mon, May 5, 2008 at 1:20 PM, Phillips, Addison <[email-masked]>
wrote:

> For the variant case, we can't use Preferred-Value (by rule), but we can
> use Deprecated with a comment to indicate the new value.
>
> The only solution to this would be to convert Preferred-Value from subtags
> to extended language ranges. This would require a change in the form of a
> number of P-V fields, not to mention having an impact on some
> implementations.
>
> >
> That's not actually "more forceful". The ability to mutate or remove the
> field is one thing. The direction to specifically mutate it in certain cases
> is a separate issue.
>
> The real problem is the "note" in the first bit you quoted, allowing for
> chaining of P-V values. I can't think of any instances in which it makes
> sense to preserve a chain once we've decided to remove all chains. Thus,
> I've removed the "In rare cases..." note.
>
> Addison
>
>

-- 
Mark