Leif Halvard Silli <lhs at malform dot no> wrote"
It is interesting to compare the prefixes allowed for "1996", Prefix: deNot *allowed*, but *recommended*. The first means that we say you SHOULD use 'de' (and implicitly, SHOULD NOT use any other primary language subtag) with '1996'.But the question still is why the registry does not say which regions tags "1996" is recommended used for.
The Registry doesn't currently include region subtags as part of any Prefix field. In fact, 'wadegile', which will be submitted to IANA today, is the first variant whose Prefix will comprise anything other than a language subtag and (optionally) one or more variant subtags.
The big danger with variants is using two or more that are mutually exclusive. '1901' and '1996' are mutually exclusive; there is no logical way in which both could ever be used in the same tag. To steer people away from this, when a tag with two variants does make sense, we explicitly indicate variant A as part of the Prefix for variant B. The sub-dialects and '1994' sub-sub-dialect of Resian are examples of this.
There is usually less of a problem using region or script subtags together with a variant. This does not mean the resulting tag necessarily corresponds to a real-world language variation, such as "en-IN-boont", but that it is not logically impossible in the sense that "de-1901-1996" would be.
In many cases, trying to enumerate the possible region subtags which would make sense with a given variant would be a huge researching challenge, and might become the subject of perpetual complaints of incompleteness even more than Suppress-Script already is.
For Wade-Giles and (maybe someday) Hanyu Pinyin, we will specify a Prefix consisting of 'zh' with a script subtag (and not without one) as a fairly explicit indication that the variant really should be used with that script subtag.
This is inherently open to debate for each proposed variant, and I am sure ietf-languages will hold such debates whether we add a rule or not, so I do not support adding a new rule to attempt to regulate this behavior, especially not if we are trying to get through a Last Call.
-- 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.