Re: [Ltru] Last open item

Hi -

> From: "Mark Davis" <mark.davis@icu-project.org>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "LTRU Working Group" <ltru@ietf.org>
> Sent: Monday, April 14, 2008 9:15 AM
> Subject: Re: [Ltru] Last open item
...
> > Case (2) is already covered by 3.4(9) - but
> > perhaps we should emphasize the optionality implied by the "MAY" in that
> > clause, because generally, in the interest of stability, one would not
> > want
> > to put in a new preferred value.
> 
> 
> Case 2 is not covered by 3.4(9), and the fix that I am recommending would
> change current text.
> 
> 3.4(9) is: "Codes assigned by ISO 639-1 that do not conflict with existing
> two-letter primary language subtags and which have no corresponding
> three-letter primary defined in the registry are entered into the IANA
> registry as new records of type 'language'." I'm not sure how it applies to
> the cases I'm discussing, and it certainly doesn't apply to region codes.

Read the rest of 3.4(9).  Important part says:
|       If a new record of the same type is added that represents a
|       replacement value, then a 'Preferred-Value' field MAY also be
|        added.  The registration process MAY be used to add comments
|        about the withdrawal of the code by the respective standard.

In other words, the registry is *NOT* required to put in a new preferred-value.
Indeed, if the code is just a replacement, I'd think the normal course of
action would for the Preferred-Value in the NEW subtag to refer to the
ORIGINAL code.  This is simpler and better-behaved from a stability perspective.

> Let me start again. I'll apologize for being a bit long-winded, but I think
> it's important to have some specific examples. The situation I discuss in #2
> is where there is a case like:
> 
> *Initial State
> *
> Subtag: X
> Preferred-Value: Y
> Deprecated: 1989-01-01
> ...
> Subtag: Y
> 
> X and Y could be 'in' and 'id', OR 'BU' and 'MM', OR some script tag (no
> instances yet). Note that both X and Y are valid, both with the same
> meaning, and Y is preferred.

MM should have had a Preferred-Value of "BU" according to the procedure,
rather than the other way around, but that's too late to fix now.

> *The change.*
> 
> ISO restores X to being the correct tag, and deprecates Y.
> 
> *Our response.
> *
> There are three courses of action we could take. B2 is in the current text
> (although not clearly -- see below).

Disagree.  The current procedure would require us to add a "deprecated" to
the newly deprecated tag.  Since the old (new) tag is already in the registry,
and means the same thing, no further action is needed.

...
> Because both codes X and Y are valid before and after any of these
> alternatives, the only instability that I think you might be referring to is
> the canonical form. But the canonical form is changing *all* of these cases:
> A, B1, and B2; Y is no longer the canonical form in any of them. I don't see
> why B2 is any "more" stable than A, not in any way that matters.
...

That is precisely why the original RFC 4646 text is better.  If followed carefully,
MM would have a Preferred-value of BU, and the canonical form would never
have changed.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru