Re: [Ltru] Re: Remove extlang from ABNF?

Frank Ellermann wrote:
> Felix Sasaki wrote:
>
>   
>> Maybe you are not aware of the situation that language tags are nearly 
>> the only IETF spec where W3C uses a BCP reference, or before that an 
>> "RFC XXX or its successor" reference - in difference to IRI, btw .
>>     
>
> Yes, some including me proposed standards track for 4646, but the
> rough consensus was BCP :-(  You use 2119 (BCP 14) quite often in W3C
> spec.s, but that's no moving target.  Unlike RFC 4646, were "moving
> target" was predictable at least for extlang:
>
> | reserved for future standardization, anticipating work that is
> | currently under way on ISO 639.
> [...]
> | Their syntax is described here so that implementations can be
> | compatible with any future revision of this document that does
> | provide for their registration.
> [...]
> | "zh-gan" (registered under RFC 3066) might become a valid non-
> | grandfathered (that is, redundant) tag in which the subtag 
> | 'gan' might represent the Chinese dialect 'Gan'.
>
> Note "might", it's not "shall".  We weren't sure, and the reasons
> to drop "extlang" are rather complex (e.g. 639-3 is more volatile
> than expected with its macrolanguages at the moment, not good for
> a "stable forver" registry).
>
> I still don't see the harm if an implementation based on RFC 4646
> identifies a bogus (non-existing) tag as "well-formed", where a 
> 4646bis implementation would see "not well-formed" with the clean
> ABNF proposal.  And both editors would apparently prefer "clean".
>
>   
>> You might say you don't care about this status
>>     
>
> And I did, see above, 4646bis could be a nice "draft standard"
> soon.  Dropping unused features in a DS is perfectly okay.  It's
> also okay in a BCP, but apparently you tjink it's not.
>   

exactly - or rather specs citing BCP 47. That's my whole point - the 
danger that specs writers might look at the dropped extlang and say 
"they are dropping features between versions of  BCP 47, so we better 
refer to an RFC *only* and even leave 'or its successor' out". If they 
would have done that already, we would have many "dead references" to 
RFC 4646 .

Felix

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru