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

From: "Doug Ewell" <[email-masked]>
Date: Thu, 14 Feb 2008 22:12:29 -0800

Mark Davis <mark dot davis at icu dash project dot org> wrote:

> I think the goal of that was to have the canonical form not vary over 
> time, but of course that can't be achieved. If "US" changes to "UX", 
> then the formerly canonical form "en-US" would change under 
> canonicalization once someone updated to the registry. So logically 
> speaking (see below though), I agree that it would be better to change 
> the Preferred-Value to be the recursive result. That would prevent 
> mistakes in using the registry.

At last, someone has made an effort to figure out why this rule exists. 
Sometimes I get the feeling some of these old issues are being revisited 
as if they had been added to 4646 purely by chance.

If Mark and others understand the original rationale for trying to 
achieve stability here, and still feel that it would be OK to reverse 
this rule and allow Preferred-Value to change, I don't have any 
objection.  it certainly simplifies the job of implementers, including 
me.

> Moreover, I don't even think that we should have a prohibition on 
> removing the Preferred-Value or Deprecated fields. Suppose that on 
> 2011-11-11, Myanmar changes its name back to Burma, and ISO changes 
> the country code back to BU. In that case, the correct course of 
> action would be for us to do the following, which is not currently 
> permitted by the spec.

Likewise, I have no problem with this, as long as we understand what we 
were thinking in the first place and feel we now have better 
perspective.

--
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: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Feb 2008 09:47:31 -0800

Hi -

As a technical contributor...

One of the reasons for the subtag registry was to provide a measure
of insulation from possible instabilities in the sources of the codes.
I think the example makes the wrong suppositions.  If a "UX" (referring
to and effectively synonymous with the former "US") shows up, "en-US"
should remain the canonical form.  To have a formerly canonical tag
change over time sounds like a very bad thing.  I'm also concerned
that if the WG is willing to make such a radical change in its attitude
toward language tag stability during working group last call, that we
may be sent back to square one.

In short, I oppose removing the prohibition on removing Preferred-Value or
Deprecated fields if that is going to be understood as permitting changes
to the canonical form of a tag.

Randy

> From: "Doug Ewell" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Thursday, February 14, 2008 10:12 PM
> Subject: Re: [Ltru] Proposed edit MD12 (davis)
>

---

From: "Kent Karlsson" <[email-masked]>
Date: Fri, 15 Feb 2008 20:02:16 +0100

> to the canonical form of a tag.

But currently there is no requirement that the canonical form
of a language tag is stable in it's canonicalness. There is just
a requirement that Preferred-value cannot be removed or changed,
which does not guarantee stability of the "canonical" language
tag as canonical (it is stable per se, but it's status as canonical
is not), since a "Preferred-Value" can be added to a registry
entry after the entry per se is added (which is why we are
having this whole discussion on this issue).

	/kent k

---

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

There may be a bit of misunderstanding here. The canonical form is not
currently, in the current spec, stable over time -- nor do we want it to be.

"en-US" *will* change to "en-UX" when canonicalized, if "US" ever becomes
deprecated in favor of "UX". That's the way it currently works, and it is by
design.

Mark

-- 
Mark

---

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

Hi -

Let's get back to the actual text proposed in this thread:

>    If the value of a Preferred-Value is not canonical (such as when it is
>    a tag or contains a subtag that itself has a Preferred-Value), then
>    a Comment SHOULD be added to the record to that effect. For example:
> 
>    Preferred-Value: zh-hakka
>    Comment: The canonical form of "zh-hakka" is "hak".

The technical change is to recommend the inclusion of a comment
in the registry under specific circumstances.  As a technical
contributor, I find this perfectly reasonable, and that it has
no adverse interoperability consequences for users of the registry.

As co-chair:
If the other messages in this thread are intended to suggest that we
do something else, then please start new threads with appropriate
subject lines and with the exact text for whatever is being proposed.

Randy

---

From: "Kent Karlsson" <[email-masked]>
Date: Fri, 15 Feb 2008 21:20:44 +0100

> no adverse interoperability consequences for users of the registry.

I think that NOT short-circuiting:

to (if there actually is a preferred value line 'hak' for 'zh-hakka')

 Preferred-Value: hak

DOES have interoperability consequences for users of the registry.

Reason: that short-circuiting is unlikely, at least for now, to be
done by implementations ("users of the registry"). And it would
surely be a service to users of the registry for the *maintainers*
to do that short-circuiting, rather than require all users of the
registry to do it.

> subject lines and with the exact text for whatever is being proposed.

I will look into that over the weekend.

	/kent k

---

From: Peter Constable <[email-masked]>
Date: Fri, 15 Feb 2008 15:27:34 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Presuhn

> to the canonical form of a tag.

Might it be better to specify requirements on the desired result -- don't change canonical form of tag -- rather than on what might be secondary issues -- the content of Preferred-Value and Deprecated fields?

Peter

---

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

You may have missed a previous message.

The purpose of canonicalization is to put the language tag into the
latest-and-greatest form. *It is not restricted by stability, nor has it
ever been. *The implications of your proposed change would be that one MUST
NOT ever add a Preferred-Value once a subtag has been added. So we couldn't
reflect any change of any 3166 code, for example.

This would be a major, breaking technical change, with many unforeseen
consequences. And I'm firmly opposed to it.

If people really want an additional "stablized canonical form", that is a
different beast. But it is too late in the process to add that either -- it
would require data and apparatus that we don't have.

Mark

On Feb 15, 2008 3:27 PM, Peter Constable <[email-masked]> wrote:

> Might it be better to specify requirements on the desired result -- don't
> change canonical form of tag -- rather than on what might be secondary
> issues -- the content of Preferred-Value and Deprecated fields?
>
>
> Peter

---

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

Hi -

> From: "Mark Davis" <[email-masked]>
> To: "Peter Constable" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Friday, February 15, 2008 4:05 PM

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?

If someone seriously wants to make other changes, please start
new threads with appropriate subject lines and specific text.

Randy
as ltru co-chair

---

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

> 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.

> new threads with appropriate subject lines and specific text.

I have just proposed actual text for the update option.

-- 
It was impossible to inveigle           John Cowan <[email-masked]>
Georg Wilhelm Friedrich Hegel           http://www.ccil.org/~cowan
Into offering the slightest apology
For his Phenomenology.                      --W. H. Auden, from "People" (1953)
_______________________________________________
Ltru mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ltru