RE: Anomaly in upcoming registry

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

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-
> bounces@alvestrand.no] On Behalf Of Doug Ewell
> Sent: Monday, June 29, 2009 6:05 AM
> To: ietf-languages@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@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages