Okay, I misinterpreted who was writing what, but I just wanted to say that
I appreciated your clear analysis of the situation.
On Tue, 19 Jun 2007, Peter Constable wrote:
> I don't think there's a problem with my account. Thanks.
>
> Peter
>
> -----Original Message-----
> From: ISO 639 Joint Advisory Committee [mailto:[log in to unmask]] On Behalf Of Debbie Garside
> Sent: Tuesday, June 19, 2007 8:03 AM
> To: [log in to unmask]
> Subject: Re: (iso639.2708) RE: ISO 639-2 decision: "mis"
>
> Hi Rebecca
>
> 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.
>
> Best regards
>
> Debbie
>
> > -----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.
> >
> > Rebecca
> >
> >
> > 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
> > >
> > >
> >
> >
>
|