[Ltru] Last open item

["Mark Davis" <mark.davis at icu-project.org>]

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

(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
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru