Stephane Bortzmeyer <bortzmeyer at nic dot fr> wrote:
Future versions of this document might add additional fields to the registry; implementations SHOULD ignore fields found in the registry that are not defined in this document.While it is not explicit, it may indicate that a "once only" field could become a "several occurrences" field later.
Technically true, but in most of the "once only" cases, it would make no logical sense to have several occurrences. A single subtag (or tag) could not possibly have more than one Type, Subtag or Tag value, Preferred-Value, Suppress-Script, or Scope. That would be like saying a person can have two different heights.
In 4646bis we are changing our previous rule about the permanence of deprecation, so that it will become possible to re-add (and presumably re-deprecate) a subtag that was once deprecated. However, since we no longer have the goal of being able to trace back through the dates in the Registry to see when a tag became valid, it would no longer make any sense to keep multiple Added or Deprecated fields in such a record.
As for Macrolanguage, this field is wholly determined by ISO 639-3, so it would always be possible in theory for that RA to change their rules and assign an individual language to two or more macrolanguages. Someone would have to make the case that Language A is not only *derived from* two or more languages or families, which is not completely absurd (think Ladino), but that it is actually *identified as* both Language B and Language C in some contexts, which still retaining its own identity in others. That seems far-fetched, and so the restriction against multiple Macrolanguage fields in the Registry seems safe.
-- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.