"root" would be just as useful as "mis", if you stipulation that people should tag with as much information as they have. The practical effect would be little different except that "root" would remain valid.
<br><br>But the fundamental problem with &quot;mis&quot; is that it is unstable, and ill-defined. If I get &quot;mis&quot; in a year from now I have no idea whether the original item was tagged when &quot;mis&quot; first came out (1998?), or in 4646, or in 4646bis; I just don&#39;t know and can&#39;t know. If you had defined &quot;mis&quot; to be &quot;whatever didn&#39;t have a code in 1998&quot;, that would at least be stable, and allow valid tags to remain valid.
<br><br>And frankly, if you are going to the trouble to tag content that you&#39;re going to later revisit, you&#39;d be far better off to use a unique private use code for each missing item. That way you don&#39;t have to re-analyse each piece of content having &quot;mis&quot; on it.
<br><br>Anyway, it sounds like the last language proposed for &quot;mis&quot; is ok with everyone, so this discussion is really moot. Sorry to have raised your hackles with my original message.<br><br>Mark<br><br><div><span class="gmail_quote">
On 6/18/07, <b class="gmail_sendername">Peter Constable</b> &lt;<a href="mailto:petercon@microsoft.com">petercon@microsoft.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">









<div link="blue" vlink="purple" lang="EN-US">

<div>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">Suggesting that 'root' avoids problems is, IMO, rather
a bit of false economy. Sure, if a tag means 'some language', then
content so tagged never becomes *<b>incorrectly</b>* tagged when an ID for the
given language is added. But let's consider whether it is *<b>usefully</b>*
tagged: changing things so that it could continue to be *<b>correctly</b>*
tagged wouldn't make it more *<b>usefully</b>* tagged, and arguably makes
it less so. </span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">To suggest that users needn't worry about their content
tagged 'root' after a new language is coded is IMO bad advice. They
certainly *<b>should</b>* worry if they want their data to be useful: they'll
want to re-tag the relevant content with the newly-coded ID, else they end up
with data that won't compare. At least if they know that the addition
will narrow the extension and potentially invalidate tagging on some of their
content, they're more likely to pay attention; what you suggest can give
the impression that they don't have any particular worry, which is not
the case. </span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">A tag with the 'root' semantic can always mean
anything – which means it's nearly void of meaning and is about as
useful as not having tagged it at all in the first place. (The 'root'
semantic would be equivalent to 'not zxx'.) That's not *<b>usefully</b>*
tagged, but it's vacuously always going to be validly tagged – big deal.
At least with the 'uncoded' semantic they can use change history for
the code table and the record date to derive a short list of what languages "mis"
content might be in – a pain, but that's actually more useful that 'some
language'.</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">Peter</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<div style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;">

<p><b><span style="font-size: 10pt;">From:</span></b><span style="font-size: 10pt;">
<a href="mailto:mark.edward.davis@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mark.edward.davis@gmail.com</a> [mailto:<a href="mailto:mark.edward.davis@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
mark.edward.davis@gmail.com</a>] <b>On Behalf
Of </b>Mark Davis<br>
<b>Sent:</b> Monday, June 18, 2007 1:49 PM<br>
<b>To:</b> Peter Constable<br>
<b>Cc:</b> LTRU Working Group; <a href="mailto:ietf-languages@iana.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ietf-languages@iana.org</a>; <a href="mailto:iso639-2@loc.gov" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
iso639-2@loc.gov</a>;
<a href="mailto:isojac@loc.gov" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">isojac@loc.gov</a>; <a href="mailto:iso639@dkuug.dk" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
iso639@dkuug.dk</a><br>
<b>Subject:</b> Re: [Ltru] RE: (iso639.2708) RE: ISO 639-2 decision:
&quot;mis&quot;</span></p>

</div><div><span class="e" id="q_11341778ee08879e_1">

<p>&nbsp;</p>

<p><span style="font-size: 10pt;">I really didn&#39;t want to start
a flame about this; I&#39;m sorry if what I said was be considered incendiary.<br>
<br>
This whole issue is not really connected with the change from part 2 to part 3,
at all. Take your example: it is a problem with your definition of
&quot;mis&quot; in BCP 47 whether &quot;brk&quot; were added because of 639-3
OR just because it were added to ISO 639-2! It is an issue whenever new codes
could be added that would invalidate previous usage of &quot;mis&quot;. <br>
<br>
And the sad thing is that this instability in ISO codes is completely
avoidable. There is a perfectly good way to have the same functionality
*without* being unstable. </span></p>

<ul type="disc">
 <li><span style="font-size: 10pt;">Have a code I&#39;ll
     call here &quot;root&quot; (to avoid any misunderstanding about the
     meaning of &quot;mis&quot;.) </span></li>
 <li><span style="font-size: 10pt;">Have it be valid
     to tag any language content with &quot;root&quot;.</span></li>
 <li><span style="font-size: 10pt;">State that one
     SHOULD tag as narrowly as possible, thus avoid &quot;root&quot; if there
     is a more specific language code. </span></li>
</ul>

<p style="margin-bottom: 12pt;"><span style="font-size: 10pt;">This
completely takes the place of the need you see for &quot;mis&quot;, *without
being unstable*. If I have some </span>Burushaski <span style="font-size: 10pt;">content,
where a code doesn&#39;t exist, I tag it with &quot;root&quot;. That is valid now,
and remains valid forever, even once &quot;brk&quot; is added -- whether
&quot;brk&quot; were added because of 639-3 or just because it were added to
ISO 639-2. <br>
<br>
Mark</span></p>

<div>

<p><span><span style="font-size: 10pt;">On
6/18/07, <b>Peter Constable</b> &lt;<a href="mailto:petercon@microsoft.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">petercon@microsoft.com</a>&gt;
wrote:</span></span><span style="font-size: 10pt;"> </span></p>

<div>

<div>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">As far as the JAC is concerned,
the intentional semantic of &quot;mis&quot; is what it has always been. As for
the extension, when 639-2 was the only alpha-3 code, there was only one context
to evaluate the extension that would be derived by that intention; 639-2 did
not document the extension, though at least one application of 639-2 –
MARC – did. With the introduction of 639-3 and the pending introduction
of 639-5 as additions to the alpha-3 space, it becomes clear that the extension
must be determined within a context: the cases where you&#39;d want to use
&quot;mis&quot; differ if you&#39;re using 639-3 rather than 639-2. But for an
application of a given part of 639, the change of reference name has had no
effect on the extension for that context: the languages encompassed by
&quot;mis&quot; in a 639-2 application, for instance, are the same as they were
before.</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">When it comes to BCP 47, the
change of reference name for &quot;mis&quot; is basically irrelevant because
there is a much bigger issue: in RFC4646bis, BCP 47 will change from being an
application of 639-1 and -2 to being an application of 639-1, -2 and -3. That
change of context is what creates the issue wrt interoperability of
&quot;mis&quot; in applications of BCP 47: Under RFC 4646, Burushaski content
would be tagged &quot;mis&quot;; under RFC 4646bis, one would expect new
Burushaski content to be tagged &quot;bsk&quot;. There&#39;s no basis for matching:
that&#39;s an interop problem. And note that it has nothing to do with stability of
&quot;mis&quot; supposedly introduced with the name change: with or without
that change, Burushaski content would be tagged differently before and after. </span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">And note that this issue exists
whether one considers &quot;old mis&quot; to have the semantic that Keld is
stuck on, &#39;all languages&#39;, or the semantic that the JAC has always intended:
either way, it is the addition of 639-3 to BCP 47 that creates an issue for
uses of &quot;mis&quot; under BCP 47, not the name change. </span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">And even without the addition
of 639-3, &quot;mis&quot; would have interop issues: assuming the semantic the
JAC has always assumed, the extension in the context of 639-2 could narrow
– inherently by the nature of the semantic – any time a new entry
was added; but assuming the &#39;all languages&#39; semantic, one could end up with
comparable content tagged in non-comparable ways, &quot;mis&quot; and something
else.</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">Therefore, I suggest that
beating up ISO as not being in tune with the needs of the IT community is both
fruitless and baseless, and is ignoring the fact that IETF has problems all of
its own making. If IETF really wanted to avoid any stability or interop
problems related to &quot;mis&quot;, it should never have permitted its use in
language tags, starting back in RFC 1766, because &quot;mis&quot; has always
had stability / interop issues. But that horse is long out of the barn:
&quot;mis&quot; *<b>can</b>* be used in language tags under RFCs from 1766 to
4646. The LTRU WG within IETF needs to decide what to do about that in RFC
4646bis. That&#39;s a job for IETF; we don&#39;t need to continue bothering JAC members
with IETF issues.</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">Peter</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">&nbsp;</span></p>

<div style="border-style: solid none none; border-color: -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;">

<p><b><span style="font-size: 10pt;">From:</span></b><span style="font-size: 10pt;"> <a href="mailto:mark.edward.davis@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mark.edward.davis@gmail.com
</a>
[mailto:<a href="mailto:mark.edward.davis@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
mark.edward.davis@gmail.com</a>] <b>On Behalf Of </b>Mark Davis<br>
<b>Sent:</b> Monday, June 18, 2007 9:23 AM<br>
<b>To:</b> Peter Constable<br>
<b>Cc:</b> Kent Karlsson; Milicent K Wewerka; John Cowan; <a href="mailto:iso639@dkuug.dk" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">iso639@dkuug.dk</a>; <a href="mailto:ietf-languages@iana.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
ietf-languages@iana.org</a>;
<a href="mailto:iso639-2@loc.gov" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">iso639-2@loc.gov</a>; <a href="mailto:isojac@loc.gov" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
isojac@loc.gov</a>; <a href="mailto:HHj@standard.no" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">HHj@standard.no</a>; LTRU Working
Group<br>
<b>Subject:</b> Re: (iso639.2708) RE: ISO 639-2 decision: &quot;mis&quot;</span></p>

</div>

<div>

<p><span style="font-size: 10pt;">&nbsp;</span></p>

<p style="margin-bottom: 12pt;"><span style="font-size: 10pt;">Unfortunately,
ISO codes have somewhat of an impedance mismatch with the needs of the IT
community; in particular, stability. Thus BCP 47 has to stabilize those codes;
one of the main reasons for the existence of RFC 4646. What that means is that
if ISO tries to narrow the meaning of *any* code, whether it is a
&quot;clarification&quot; or not, we have really only two choices: <br>
<br>
1. Keep the broader semantic, which encompasses the new ISO narrow one, or<br>
2. Deprecate the code (in one way or another).<br>
<br>
Unlike many other codes, &quot;mis&quot; is one that we can do without, so #2
was a reasonable choice. <br>
<br>
What I was trying to come up with language that we could agree on even though
we have very different views on the utility and meaning of &#39;mis&#39;. It sounds
like we are ok on the suggested language on the other thread, so I&#39;m hoping
that we can put &quot;mis&quot; to bed.<br>
<br>
Mark</span></p>

<div>

<p><span style="font-size: 10pt;">On 6/16/07, <b>Peter Constable</b> &lt;<a href="mailto:petercon@microsoft.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">petercon@microsoft.com </a>&gt;
wrote:</span></p>

<p style="margin-bottom: 12pt;"><span style="font-size: 10pt;">From: Kent
Karlsson [mailto:<a href="mailto:kent.karlsson14@comhem.se" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
kent.karlsson14@comhem.se</a>]<br>
<br>
&gt; With the &quot;old mis&quot; one could correctly apply &#39;mis&#39; as a language<br>
&gt; code for any language<br>
<br>
That has *never* been the intent of ISO 639. It is an external interpretation,
admittedly possible because ISO 639 was not fully explicit up to now. But from
the perspective of the JAC, the &quot;new mis&quot; is exactly the same
&quot;mis&quot; as the &quot;old mis&quot;. <br>
<br>
<br>
Peter</span></p>

</div>

<p><span style="font-size: 10pt;"><br>
<br clear="all">
<br>
-- <br>
Mark </span></p>

</div>

</div>

</div>

<p style="margin-bottom: 12pt;"><span style="font-size: 10pt;"><br>
_______________________________________________<br>
Ltru mailing list<br>
<a href="mailto:Ltru@ietf.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Ltru@ietf.org</a><br>
<a href="https://www1.ietf.org/mailman/listinfo/ltru" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://www1.ietf.org/mailman/listinfo/ltru</a></span></p>

</div>

<p><span style="font-size: 10pt;"><br>
<br clear="all">
<br>
-- <br>
Mark </span></p>

</span></div></div>

</div>


</blockquote></div><br><br clear="all"><br>-- <br>Mark