If we have firm stability rules, then I'm ok with #2 also. But these rules have to be very explicit and strong, something like: Once added to the registry:<br><ul><li>a language subtag may be deprecated, but never becomes an extlang subtag
</li><li>an extlang subtag may be deprecated, but never becomes a language subtag</li><li>the relationship of an extlang to a language tag (its macro language) may be deprecated, but is never removed.<br></li></ul>Mark<br>
<br><div><span class="gmail_quote">On 8/25/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;">
Addison Phillips scripsit:<br><br>> The thing that bothers me about #1 is that, heretofore, nearly all<br>> language tag processing required only the information in the language<br>> tag(s), without reference to informative fields in the registry... that
<br>> is, one can match language tags "at a glance".<br><br>I agree with this entire posting.<br><br>--<br>Overhead, without any fuss, the stars were going out.<br> --Arthur C. Clarke, "The Nine Billion Names of God"
<br> John Cowan <<a href="mailto:cowan@ccil.org">cowan@ccil.org</a>><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>