I just clicked "reply to all" to Peter's message on IETF-languages with a
"+1" indicating my support. I don't think there is anything wrong with the
account as I received it via the JAC too.
> -----Original Message-----
> From: ISO 639 Joint Advisory Committee
> [mailto:[log in to unmask]] On Behalf Of Rebecca S. Guenther
> Sent: 19 June 2007 14:09
> To: [log in to unmask]
> Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis"
> I guess Peter wrote this message, although forwarded from
> Debbie (is there a problem with your account on the list?)
> Thank you for writing this message-- very well stated and I
> hope that will put an end to the discussion in terms of what
> the JAC has to see.
> On Tue, 19 Jun 2007, Debbie Garside wrote:
> > From: [log in to unmask]
> > [mailto:[log in to unmask]] On Behalf Of Peter
> > Constable
> > Sent: 18 June 2007 18:17
> > To: LTRU Working Group
> > Cc: [log in to unmask]; [log in to unmask]; [log in to unmask];
> > [log in to unmask]
> > 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 after.
> > 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 IETF issues.
> > Peter
> > From: [log in to unmask]
> [mailto:[log in to unmask]]
> > On Behalf Of Mark Davis
> > Sent: Monday, June 18, 2007 9:23 AM
> > To: Peter Constable
> > Cc: Kent Karlsson; Milicent K Wewerka; John Cowan; [log in to unmask];
> > [log in to unmask]; [log in to unmask]; [log in to unmask];
> > [log in to unmask]; 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
> > choices:
> > 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 reasonable choice.
> > 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.
> > Mark
> > On 6/16/07, Peter Constable <[log in to unmask]
> > <mailto:[log in to unmask]> > wrote:
> > From: Kent Karlsson [mailto: <mailto:[log in to unmask]>
> > [log in to unmask]]
> > > 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".
> > Peter
> > --
> > Mark