Anomaly in upcoming registry
Mark Davis ⌛
mark at macchiato.com
Mon Jun 29 18:32:26 CEST 2009
I agree, except for the sentence:
> since the RFC already deprecates the use of most macrolanguages (including
'sh') in favor of encompassed language subtags.
Macrolanguages are *not* deprecated; only 'sh' is; that's why it is an
I think what you meant to say is that the RFC *favors* the use of
encompassed languages over the use of their macrolanguages.
On Mon, Jun 29, 2009 at 08:59, Phillips, Addison <addison at amazon.com> wrote:
> I think my opinion on what should happen would depend on the record Mark
> wants to register.
> One change that the new RFC makes to record 'sh' is that it will include
> the field "Macrolanguage". There is specific guidance about macrolanguage
> usage in the RFC, notably in section 4.1.1---where the encompassed languages
> of 'sh' appear in an example. It shouldn't, in theory, be necessary to
> deprecate 'sh', since the RFC already deprecates the use of most
> macrolanguages (including 'sh') in favor of encompassed language subtags.
> One problem with deprecating 'sh' is that we do not include a "Deprecated"
> field in the other macrolanguage subtag records. Presumably one would
> deprecate a macrolanguage if it were withdrawn or replaced with another code
> by ISO 639-3 or if the macrolanguage relationship were dissolved... that is,
> deprecation happens when something happens to the status of 'sh' as a
> macrolanguage or happens to other peer subtags.
> On the other hand, Mark has a point. Language tagging in the Balkans is
> freighted with enough different socio-political and historical nuances as it
> is. 'sh' and its encompassed languages serve mainly as an exception to the
> normal rules of tag meaning and stability. Although "macrolanguage-hood" is
> a different form of deprecation, I think preserving the current explicit
> deprecation of the subtag might benefit everyone more than strictly hewing
> to the RFC's apparent intentions.
> So right now I think I'd wait for Mark's request, since the nuances are
> likely to be what matters.
> Addison Phillips
> Globalization Architect -- Lab126
> Internationalization is not a feature.
> It is an architecture.
> > -----Original Message-----
> > From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> > bounces at alvestrand.no] On Behalf Of Doug Ewell
> > Sent: Monday, June 29, 2009 6:05 AM
> > To: ietf-languages at iana.org
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ietf-languages