<div dir="ltr">Mandarin text has been validly tagged as &#39;zh&#39;, and will continue to be validly tagged as &#39;zh&#39;. So what Addision is saying is that it would be absurd not to permit zh with the variant subtag, especially as it is the only currently possible construction. In the future, hopefully by the end of this year (or at least the next -- I&#39;ve been wrong about predicting schedule before!), it will also be possible to use the narrower subtag sequences cmn or zh-cmn, which many people will prefer. And at that point we&#39;ll add them as prefixes.<br>
<br>However, that doesn&#39;t change the fact that zh-Latn-pinyin (or zh-Latn-hpinyin or zh-Latn-hanyu, however we end up with a name) is a perfectly reasonable, unproblematic variant subtag that meets a current requirement.<br>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Mon, Aug 4, 2008 at 10:33 AM, Tracey, Niall <span dir="ltr">&lt;<a href="mailto:niall.tracey@logica.com">niall.tracey@logica.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
From: Phillips, Addison<br>
<div class="Ih2E3d"><br>
&gt; It would be absurd not to permit the use of the &#39;zh&#39; subtag with<br>
&gt; the subtag for the Romanization scheme, IMO. Yes, &#39;cmn&#39; is more<br>
&gt; accurate. But we allow all sorts of inaccurate tagging.<br>
<br>
</div>Absurd? How so?<br>
<br>
&quot;zh&quot; on its own is logically no different from &quot;zh_cmn&quot;, I&#39;ll grant you that. I&#39;ll also grant you that it leads to the majority of technical staff to make the mistake that they are logically identical.<br>

<br>
It would be certainly a logical choice for systems designers to interpret the logically incomplete tag zh_Latn_hanyu to mean zh_cmn_Latn_hanyu.<br>
<br>
However, while it would be nice if the specification itself could encode the handling of erroneous cases, as far as I can see it is not designed that way -- if you put something in the registry, it is considered correct.<br>

<br>
So I feel it&#39;s best not to compromise at the spec level, and leave error-handling to the systems level.<br>
<div class="Ih2E3d"><br>
NĂ­all.<br>
<br>
<br>
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.<br>

<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="Wj3C7c">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" target="_blank">http://www.alvestrand.no/mailman/listinfo/ietf-languages</a><br>
</div></div></blockquote></div><br></div>