[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