Re: [Ltru] Last open item

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

As a technical contributor...

> From: "Mark Davis" <mark.davis at icu-project.org>
> To: "LTRU Working Group" <ltru at ietf.org>
> Sent: Thursday, April 10, 2008 1:52 PM
> Subject: [Ltru] Last open item
>
> I went through all the pending comments to see which didn't have objections
> raised on the list. The only open substantive issue I think we have left is
> about whether to change the following lines:
> 
> The field 'Preferred-Value' MUST NOT be modified once created in the
> registry. The field MAY be added to records according to the rules in
> Section 3.3 (Maintenance of the
> Registry)<http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-13.html#maintreg>
> .
> 
> *(note: we don't have a similar phrase for Deprecated)*
> 
> Values in the fields 'Type', 'Subtag', 'Tag', 'Added', 'Deprecated' and
> 'Preferred-Value' MUST NOT be changed and are guaranteed to be stable over
> time.
> 
> Here is my reasoning. We can't guarantee complete stability over time.
> Whenever Deprecated or Preferred-Value are added, it changes the canonical
> form; or if the target of a Preferred-Value is itself deprecated. Currently
> if a subtag is deprecated in a source standard in favor of another, nothing
> special needs to be done unless:
> 
>    1. there is a collision - the same subtag with a different meaning
>    (like CS), OR
>    2. the preferred subtag is an older deprecated code (eg BU => MM =>
>    BU), OR
>    3. the target of the Preferred-Value itself becomes deprecated (we
>    want to resolve it so that users don't have to).
> 
> In the first 2 cases, we are forced to use a "special" code, eg change MM to
> 104. That's perfectly fine in the case of collisions (#1). However, it is
> completely unnecessary in the case of older deprecated codes. So my proposal
> is to change the above lines to drop the first one, and change the second
> to:
> 
> Values in the fields 'Type', 'Subtag', 'Tag', and 'Added' MUST NOT be
> changed and are guaranteed to be stable over time. Values in the
> 'Deprecated' and 'Preferred-Value' MUST NOT be changed unless the tag or
> subtag in the Preferred-Value field is itself deprecated, or if a
> deprecation is reversed in one of the source standards.
> 
> -- 
> Mark

I object to making this change.  Case (1) is already prohibited in sections
3.4(10) and 3.6 of RFC 4646.  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 (3) is a non-problem.  The "deprecated"
in the record only refers to the status in the source standard, not the
validity of the string as a language tag, as should be very clear from the
first sentence of 3.4(0)

Adopting this change would add instability without providing any value,
and the cases cited as motivations are already covered by the RFC 4646
rules.

Randy


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