(iso639.2708) RE: ISO 639-2 decision: "mis"
debbie at ictmarketing.co.uk
Tue Jun 19 11:51:30 CEST 2007
From: ietf-languages-bounces at alvestrand.no
[mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Peter Constable
Sent: 18 June 2007 18:17
To: LTRU Working Group
Cc: ietf-languages at iana.org; iso639-2 at loc.gov; isojac at loc.gov;
iso639 at dkuug.dk
Subject: RE: (iso639.2708) RE: ISO 639-2 decision: "mis"
As far as the JAC is concerned, the intentional semantic of "mis" 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'd want to use "mis" differ if you'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 "mis" in a 639-2 application, for instance, are the
same as they were before.
When it comes to BCP 47, the change of reference name for "mis" 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 "mis" in applications of BCP 47: Under RFC 4646,
Burushaski content would be tagged "mis"; under RFC 4646bis, one would
expect new Burushaski content to be tagged "bsk". There's no basis for
matching: that's an interop problem. And note that it has nothing to do with
stability of "mis" supposedly introduced with the name change: with or
without that change, Burushaski content would be tagged differently before
And note that this issue exists whether one considers "old mis" to have the
semantic that Keld is stuck on, 'all languages', 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 "mis" under BCP 47, not the name change.
And even without the addition of 639-3, "mis" 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 'all languages' semantic,
one could end up with comparable content tagged in non-comparable ways,
"mis" and something else.
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 "mis", it should never have
permitted its use in language tags, starting back in RFC 1766, because "mis"
has always had stability / interop issues. But that horse is long out of the
barn: "mis" *can* 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's a job for IETF; we don't need to continue bothering JAC members with
From: mark.edward.davis at gmail.com [mailto:mark.edward.davis at gmail.com] On
Behalf Of Mark Davis
Sent: Monday, June 18, 2007 9:23 AM
To: Peter Constable
Cc: Kent Karlsson; Milicent K Wewerka; John Cowan; iso639 at dkuug.dk;
ietf-languages at iana.org; iso639-2 at loc.gov; isojac at loc.gov; HHj at standard.no;
LTRU Working Group
Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis"
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 "clarification" or not, we have really only two
1. Keep the broader semantic, which encompasses the new ISO narrow one, or
2. Deprecate the code (in one way or another).
Unlike many other codes, "mis" is one that we can do without, so #2 was a
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 'mis'. It
sounds like we are ok on the suggested language on the other thread, so I'm
hoping that we can put "mis" to bed.
On 6/16/07, Peter Constable <petercon at microsoft.com
<mailto:petercon at microsoft.com> > wrote:
From: Kent Karlsson [mailto: <mailto:kent.karlsson14 at comhem.se>
kent.karlsson14 at comhem.se]
> With the "old mis" one could correctly apply 'mis' as a language
> code for any language
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 "new mis" is exactly the
same "mis" as the "old mis".
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ietf-languages