John Cowan <cowan at ccil dot org> wrote: >> I should add the one where we add ISO 3166 exceptionally reserved >> codes except 'UK', which is actually an exception to an exception. >> At least that one is based on a rule we already have about not adding >> exact duplicates at registration time; it applies the rule to RFC >> 4645bis publication time as well. Still, it is yet another exception >> from the ISO standards. > > What would be the point of having a separate standard from ISO if we > didn't deviate from it from time to time? :-) Smiley noted, but to me this is the difference: We can cherry-pick from ISO standards all we like (ISO 3166-1 even says this; the 639 family may too) but we must not assign different meanings to existing codes, and we must not assign new codes in a non-private-use space, and -- the important part here -- we SHOULD be able to justify why we have chosen the subset we have chosen. (By "we", I mean not only that the WG can justify it to IETF, but also that ietf-languages can justify it to users on an ongoing basis.) In the case of ISO 3166-1, we include exceptionally reserved code elements in our application because we perceive a need to encode those entities. That is something we need to be able to justify (and I trust others on this list will make their case for 'EU'), and we are also supposed to notify ISO 3166/MA of our intent (I assume someone has already done that). But, we have a rule that prohibits exact duplicates, and so we can use that to justify sub-exclusion of 'UK'. Fine: we can defend this when people ask us to. In the case of language subtags, whether it has to do with extlangs or excluding certain ISO code elements or deprecating things in the Registry that aren't withdrawn from the standard (as was suggested for 'mis' et al.), we should similarly be able to defend our decisions when people ask. I'm concerned that when we exclude certain ISO codes, and reviewers ask us to explain why we did so, and our response is that we can't point to a rule but that "they don't make sense in language tags" or "they don't work well," that might not sit well. We will be asked why we know better than the ISO TC and SC that developed the standard. If we want to exclude things, I would rather create a rule that says, for example, "collection codes are excluded if they have only one member which is already encoded as an individual language," as opposed to just excluding it ad hoc. That way people can debate the rule, not the expertise of the WG members. -- Doug Ewell * Arvada, 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.