Re: [Ltru] Last open item

["Phillips, Addison" <addison at amazon.com>]

"Canonical" != "valid"

We are not proposing to ever make a tag invalid. We are proposing to allow the canonical form of the tag to change reflecting changes in the world. There is even a warning in 4647 about being overly aggressive in canonicalizing tags.

Addison

Addison Phillips
Globalization Architect -- Lab126 (Amazon)
Chair -- W3C Internationalization Core WG

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of
> Randy Presuhn
> Sent: mardi 15 avril 2008 09:42
> To: LTRU Working Group
> Subject: Re: [Ltru] Last open item
>
> Hi -
>
> As a technical contributor...
>
> > From: "John Cowan" <cowan at ccil.org>
> > To: "Randy Presuhn" <randy_presuhn at mindspring.com>
> > Cc: "LTRU Working Group" <ltru at ietf.org>
> > Sent: Tuesday, April 15, 2008 11:04 AM
> > Subject: Re: [Ltru] Last open item
> ...
> > Stability in the preferred value isn't the sort of stability that we
> > can either expect or preserve, particularly in ISO 3166 code elements.
> > What we can and do stabilize is the meaning of subtags: if a source
> > standard attempts to assign a code element to a different meaning
> than
> > it once had, we provide a replacement subtag instead of reusing that
> > code element.
> >
> > Countries will go on changing their names, and 3166/MA (in accordance
> > with its mandate) will change their codes accordingly;
>
> Strongly agree, but....
>
> > in order not to
> > get out of sync with the rest of the code-using world, we need to
> track
> > those changes insofar as possible.
> ...
>
> Strongly disagree.
>
> One of the motivations for the formation of this working group was to
> provide
> a way to insulate language tags from what was perceived as excessive
> instability
> in some of the code sources.  As I see it, stability, particularly the
> stability of
> the canonical form of a language tag, is dramatically more important
> than
> staying in sync with other uses of codes coming from the standards we
> used
> to initially populate our registry.  After all, if we're just going to
> blindly track
> the ISO code du jour for every little piece of dirt, there's really
> little point
> to even bothering to put these things in our registry.  If consistency
> with
> other uses of those source specifications trumps stability as a
> consideration,
> then we should throw out our current procedures and registry, just say
> "see
> ISO registry mumble for these codes", and limit our registry and
> procedures
> exclusively to codes for things that ISO hasn't coded.
>
> Otherwise, we will find ourselves in the situation that a tag found to
> be OK
> be a validating processor will suddenly become not OK.  That's simply
> not acceptable.
>
> Randy
>
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru