> > >>What problem is being fixed here? (I don't know that we have an > existing > problem.) > > > It is a matter of clarity. If we do not state that a requester > MUST first > > apply to the ISO 639 JAC there will always be the awkward cuss > who comes > > along and causes a huge rumpus - we have had our fair share of > these and > > sometimes it is better to dot the i's and cross the t's. It > could save us a > > lot of time in the future. > > You say, "we have had our fair share of these", but in over ten > years participating in IETF-languages I don't recall any serious > problems having arisen of the type we're discussing. > We do have some examples. For example, 'no-nyn' and 'no-bok' -> nn/nb Note that ALL of these predate 4646, when the rules were changed. It is a benefit of subtag (vs whole-tag) registration that we're more likely to deprecate a variant (not really that painful) than come into conflict with ISO 639. Our current text effectively says that we won't register any of these special primary language subtags, while preserving an escape hatch "just in case" we turn out to be wrong to prohibit it. There is certainly an intention that requesters should go to ISO 639 first and part of making the LSR "king of all subtags" is that s/he can effectively reject such requests on the basis that the requester doesn't have any evidence of a rejection slip from 639... without getting into the question of whether the request has merit. If 639 rejected it, the LSR would then have to consider the merit issue. Like Peter, I don't see that we're actually fixing anything broken here. Addison
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.