Anomaly in upcoming registry

[Mark Davis ⌛]

I agree.

Mark


On Sun, Jul 12, 2009 at 14:29, Peter Constable <petercon at microsoft.com>wrote:

> From: ietf-languages-bounces at alvestrand.no [mailto:
> ietf-languages-bounces at alvestrand.no] 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.
>
>
>
> Peter
> _______________________________________________
> 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/20090712/9a0bff94/attachment.htm