Anomaly in upcoming registry

Peter Constable petercon at
Sun Jul 12 23:29:05 CEST 2009

From: ietf-languages-bounces at [mailto:ietf-languages-bounces at] On Behalf Of Doug Ewell

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

I see nothing in 3.1.6 "Deprecated Field" or in 3.3 "Maintenance of the Registry" or in 3.5 "Registration Procedure..." that prevents us from deprecating a language, script or region record not deprecated in the source ISO standard, or doing the opposite. These sections tell us that things can be deprecated without imposing exclusions or making it mandatory under certain conditions. So, nothing tells use can't, and we don't need text explicitly telling us we can.

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

I wasn't suggesting that it was. I was merely pointing out that we have explicitly called out cases in which we do not strictly follow source ISO standards, and that those are similarly in cases in which doing so is not what we consider to be in the best interest of the consumers of _this_ specification.

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

Of course; I never suggested otherwise.

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

I never meant to suggest that we could disregard any arbitrary split/merger decisions. In particular, we should *not* go deciding things such as (hypothetical) that Bosnian should be completely separate and not encompassed by sh. The *only* kind of decision I was discussing was whether everything deprecated by ISO 639 should be deprecated by us, or whether we could deprecate things not deprecated in ISO 639, and whether it matters which part of ISO 639 does what: I'm suggesting that we can make our own independent (non-)deprecation decisions without needing a precedent from one or another part of ISO 639. 


More information about the Ietf-languages mailing list