I think you may have gotten the numbering wrong. You say:<br><br><div style="margin-left: 40px;">5) Under option #2, we just add 'rkn' as a new language subtag, end<br>of story. This leaves users to figure out when and whether to use it
<br>as opposed to any of the 11 existing language subtags. This is the<br>situation with "no" vs. "nb" and "nn" today.<br></div><br>Under #2, all of a sudden 'ams', 'kzg', 'ryn', 'tkn', 'okn', 'ryu', 'xug', 'yox', 'mvi', 'rys', 'and' 'yoi' and everything using as the language subtag would be deprecated; a big change.
<br><br>Under #1, we just add 'rkn' as a code. We would add information to the registry that it has become a macro language for 'ams', 'kzg', 'ryn', 'tkn', 'okn', 'ryu', 'xug', 'yox', 'mvi', 'rys', 'and' 'yoi'; it is then up to people implementing fallback algorithms to add that information, but it doesn't cause any subtags to be deprecated.
<br><br>I still don't understand something. Why should the existence of a macrolanguage that contains X make the difference between whether "X-...." is valid or not? As I understand it, the difference between cmn and hak, for example, is no less than the difference between de and nl; why should we say that cmn-CN and hak-CN must have the prefix zh-, where we don't require a prefix for de and nl?
<br><br><div><span class="gmail_quote">On 8/24/06, <b class="gmail_sendername">John Cowan</b> <<a href="mailto:cowan@ccil.org">cowan@ccil.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Frank Ellermann scripsit:<br><br>> Who's that "we" in this statement, the subtag list ? I'd hope<br>> that the business of introducing new macrolanguages or not is<br>> the job of ISO 639, and not a side-effect of 639-2 doing this,
<br>> and 639-3 doing that (= nothing, for the part after the "or" in<br>> your scenario).<br><br>Let me spell things out more clearly with a hypothetical case, set after<br>ISO 639/3 and RFC 3066ter are up and running:
<br><br>1) A group approaches 639-2/RA (the Library of Congress) asking for<br>a language tag for the Ryukyuan language (closely related to, but<br>distinct from, Japanese) and presents the usual sort of evidence for<br>its registration.
<br><br>2) 639-2/RA grants this, assigning it the available 3-letter code element<br>'rkn'.<br><br>3) 639-3/RA (SIL) notices that this "Ryukyuan language" corresponds to 11<br>different languages in its list, with codes 'ams', 'kzg', 'ryn', 'tkn',
<br>'okn', 'ryu', 'xug', 'yox', 'mvi', 'rys', 'and' 'yoi'. Therefore, it adds<br>'rkn' to its list of macrolanguages and specifies that it encompasses<br>those 11 languages.<br><br>4) We, ietf-languages, must react to the creation of this code. It may
<br>be that LTRU has spelled out what to do in 3066ter, or it may be that we<br>have been delegated the responsibility of deciding what actions to take.<br>In either case, the considerations below are the same.<br><br>5) Under option #2, we just add 'rkn' as a new language subtag, end
<br>of story. This leaves users to figure out when and whether to use it<br>as opposed to any of the 11 existing language subtags. This is the<br>situation with "no" vs. "nb" and "nn" today.
<br><br>6) Under option #1, we have two choices (again, the choice may have been<br>made in advance by LTRU, but that doesn't affect the argument):<br><br>6a) Add 'rkn' as a language subtag and immediately deprecate it, thus
<br>encouraging people to use the other tags instead. This is what we do<br>when ISO 3166/MA changes a country code element.<br><br>6b) Add the 11 existing 639-3 code elements as extlang subtags, add 'rkn'<br>as a language tag, and deprecate the 11 code elements as language subtags,
<br>specifying "rkn-XXX" as the preferred form. This provides the cleanest<br>long-term results.<br><br>> Unless 639-3 is bound to create this macrolanguage anyway, then<br>> getting it right before it's "official" might be an option.
<br>><br>> It never occured to me that 639-2 and 639-3 could get into some<br>> conflicts, Peter always said that such issues will be fixed in<br>> the final version. And I thought it couldn't happen after that
<br>> "date-C" in 2007.<br><br>Well, hopefully the 639 RA/JAC, whose job it is to keep the various RAs<br>consistent, will stop the above process at step 1. But if they do not,<br>then we need a resolution scheme, however unlikely it is to be used.
<br><br>--<br>They tried to pierce your heart John Cowan<br>with a Morgul-knife that remains in the <a href="http://www.ccil.org/~cowan">http://www.ccil.org/~cowan</a><br>wound. If they had succeeded, you would
<br>become a wraith under the domination of the Dark Lord. --Gandalf<br>_______________________________________________<br>Ietf-languages mailing list<br><a href="mailto:Ietf-languages@alvestrand.no">Ietf-languages@alvestrand.no
</a><br><a href="http://www.alvestrand.no/mailman/listinfo/ietf-languages">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br></blockquote></div><br>