Anomaly in upcoming registry

[Doug Ewell]

Peter Constable <petercon at microsoft dot com> wrote:

> On the other hand, I'm not completely in agreement with your premise 
> that this is solely ISO 639's call and that we have no say. We could 
> choose to collapse these even if ISO 639 doesn't if we think that is 
> the right thing to do for consumers of the LST registry. If ISO 639 
> chose to collapse these, we could choose to leave them as is if we 
> think that is the right thing to do for consumers of the LST registry.

I actually don't see anything in RFC 4646 or draft-4646bis that says we 
can do this.  Can you point to some text?  I may be overlooking 
something.

> There are times when we simply want to follow what ISO does and not 
> "second guess"; there are also times when we don't want to be subject 
> to everything ISO may do -- such provisions are even baked into BCP 
> 47.

The provisions we've baked in are that if ISO reuses a code element or 
does something else that is incompatible with the way the Registry 
works, we can override it.  That is different from choosing to deprecate 
or not deprecate things independently of what ISO does.  "Collapsing" 
one or more languages, the way it is being described here, is not a 
matter of overriding an incompatible decision.

> IMO, if we think that sh not be deprecated for consumers of the LST 
> registry, then we should go ahead and make that decision, regardless 
> of whatever ISO 639-1 or ISO 639-3 may do.

I accept that un-deprecating 'sh' is a border case, since the parts of 
ISO 639 disagree with each other and we can rightly say that we are 
still following "ISO 639" even by choosing to follow a different part. 
It's still a change, so I think it needs to be publicly justified, but 
it can be done.  However, this should not IMHO be seen as a precedent to 
go off and start disregarding any arbitrary split/merge decisions made 
by ISO 639.  In this regard I agree with Gerard Meijssen.

--
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  ˆ