[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] Uniqueness of variant subtags



I tried to go through and account for Addisons comments, and have the following. (Also at http://docs.google.com/Doc?id=dfqr8rd5_216dbfzfkf5, so that it is easier to update.) I left in place two options for how to deal with years. I'd prefer A, but could live with B.



<t>Records MUST be unique by Type and Subtag. Thus requests to assign an additional record of a given Type with an existing Subtag value MUST be rejected. For example, the variant subtag 'rozaj' already exists in the registry, so adding a <i>second<i> record of type 'variant' with the subtag 'rozaj' is prohibited.</t> 

<t>Variant subtags that are used with multiple prefixes MUST have a single core meaning across those prefixes. Such a core meaning may be narrow, or may be broad. For example, it could refer to an organization (including governments), and mean a variant as specified by that organization for relevant prefixes. Thus 'ungegn' could be defined as referring to a romanization for any given prefix as specified by the United Nations Group of Experts on Geographical Names (UNGEGN), and be thus productively used with 'ru-Latn', 'hi-Latn', 'zh-Latn', and others.</t> 

Option A. 

<t>Four digit subtags are specially reserved for indicating a year. Their meaning is in reference to some significant specification or other work associated with that year. It may have multiple prefixes: the particular specification for a given prefix MUST be clearly indicated in one of the Descriptions. For example, the '1994' subtag variant record could have the prefix 'fr-CA' added together with a description of usage for a French Canadian spelling reform associated with the year 1994.</t> 


Option B.

<t>Additional four digit variant subtags MUST NOT be registered.</t>
_______________________________________________
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.