Re: [Ltru] Last open item

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

Ok, not completely the last. Addison and I are trying to wrap this all up, and ran across one other.

Before forwarding a new registration to IANA, the Language Subtag Reviewer MUST ensure that values in the 'Subtag' field match case according to the description in Section 3.1.

=>

Before forwarding a new registration to IANA, the Language Subtag Reviewer MUST ensure that values in the 'Subtag' field match case according to the description in Section 3.1, and that all other requirements of this specification are followed.

Rationale. It has been implicit in all of our discussions and in the document that the LSR must follow all of the policies in the document are followed, not just casing. However, it isn't really explicit in the document, and should be. This is a minimal change to that end (although other wording would be possible).

Mark

On Thu, Apr 10, 2008 at 12:52 PM, Mark Davis <mark.davis at icu-project.org> wrote:

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

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