Anomaly in upcoming registry

Mark Davis ⌛ mark at macchiato.com
Mon Jun 29 21:54:33 CEST 2009


I think what you are saying is that "hbs" has been carefully considered and
*knowingly* been marked as not-deprecated in ISO 639-3. I have no issue at
all with that; I think that was the right thing to do.

However, that still leaves us with an issue in the iana registry
(*after*the new version comes into force).

hbs = sh, yet
hbs is not Deprecated, and
sh is Deprecated

We could take ISO 639-3 as superseding 639-1 on the issue of deprecation,
and I think that would be the right thing to do. However, it would be
cleaner yet if ISO 639-1 were to un-deprecate sh, so that it was consistent
with ISO 639-3.

Mark


On Mon, Jun 29, 2009 at 08:59, <ISO639-3 at sil.org> wrote:

>
> Hello All,
>
> I do not think that there is anything requiring correction. There are other
> instances of macrolanguages in ISO 639-3 that do not exist in Part 2 (much
> less, Part 1). See [luy<http://www.sil.org/iso639-3/documentation.asp?id=luy>]
> and [kln <http://www.sil.org/iso639-3/documentation.asp?id=kln>]. The
> deprecation of [sh] in Part 1, and the retirement of [hbs] from the
> predecesor of Part 2 with the split into three individual languages were
> actions taken before the notion of "macrolanguage" was in existence in the
> 639 standards group. The decision to include [hbs] as a macrolanguage in
> Part 3 was a separate decision, taken in 2005 and reiterated in 2007 with
> the adoption of ISO 639-3.
>
> Best regards,
>
> Joan Spanne
> ISO 639-3/RA
> SIL International
> 7500 W Camp Wisdom Rd
> Dallas, TX 75236
> ISO639-3 at sil.org
>
>
>
>  *"Doug Ewell" <doug at ewellic.org>*
> Sent by: ietf-languages-bounces at alvestrand.no
>
> 2009-06-29 08:04 AM
>   To
> <ietf-languages at iana.org>  cc
>   Subject
> Re: Anomaly in upcoming registry
>
>
>
>
> Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:
>
> >> ... It certainly isn't patently obvious to me that this is a bug in
> >> the draft-4645bis Registry that needs to be fixed.
> >
> > I think no one is suggesting that anything be done to draft-4645bis. I
> > think re-opening 4645bis to make a change of this nature would be
> > inappropriate.
>
> No, I agree that Mark was not calling to change anything in
> draft-4645bis, but rather in the "draft-4645bis Registry" -- the
> Registry to be supplied to IANA by draft-4645bis, whose method of
> construction is described in draft-4645bis.
>
> My position is that the change Mark suggests may not be appropriate, and
> is certainly not a <span lang="en-US">slam dunk</span>.  It depends on
> our interpretation of draft-4646bis and any priorities it does or
> doesn't give to ISO 639-3 over other parts of ISO 639, and it depends on
> whether the relevant RA or JAC decides to correct the inconsistency in
> 639 by either (a) reviving "sh" in 639-1 and adding "hbs" to 639-2, or
> (b) withdrawing "hbs" from 639-3.
>
> I don't see why the philosophical discussion necessarily must wait until
> the new Registry is in force, but if others want to wait, that's fine
> with me.
>
> --
> Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
> http://www.ewellic.org
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20090629/aa6995a1/attachment.htm 


More information about the Ietf-languages mailing list