Re: [Ltru] Last open item

> we will find ourselves in the situation that a tag found to be OK
> be a validating processor will suddenly become not OK

That is a red herring. There appears to be a fundamental misperception here.
The key issue is that canonical form is NOT the same as is valid, and never
has been. Moreover:

1. The canonical form is not, and never has been "stable" in the sense you
mean. Any time a subtag is deprecated in favor of another, we make the
change, which will change the canonical form. True of our process before,
and still true in the latest draft.

2. However, the key notion of stability that we have striven for is that
once a tag is valid, it will always stay valid. *That is true even if the
canonical form changes.*

3. This drives the main stabilizing principle in BCP 47, which is that once
in the registry, we never change the meaning of a subtag in a way that would
narrow the denotation of a tag (or change it completely, like CS was handled
by ISO). THAT is the area where we stabilize the ISO codes, and where we do
not accept changes from ISO.

If you have a math bent, think of it this way. The domain of valid tags is
partitioned into equivalence classes. Each equivalence class has one
distinguished member, the canonical form. Over time, only certain changes
are allowed:

   - Tags never disappear (each of the tags, once valid, will always
   remain valid).
   - New tags and equivalence classes may be added.
   - The canonical form for a given class may change, but the old
   canonical form remains valid and remains the same in meaning as the new one.
   - Equivalence classes may grow, and may merge (unlikly but possible),
   but will never split.

Mark

On Tue, Apr 15, 2008 at 9:42 AM, Randy Presuhn <randy_presuhn@mindspring.com>
wrote:

> Hi -
>
> As a technical contributor...
>
> > From: "John Cowan" <cowan@ccil.org>
> > To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> > Cc: "LTRU Working Group" <ltru@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@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>

-- 
Mark