[Ltru] Re: Remove extlang from ABNF?

Martin Duerst wrote:

>> The current tendency within the XML Schema Working Group is
>> that they might go for 3) and replace the reference to 3066
>> with a reference to BCP 47.
>> However, the pattern for validation of the language data type
>> will probably not be changed, it will stay as RFC 3066 like
>>
>> [a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*

> This is very much the right way to go.

+1, that could be also a plan for 2616bis (their 2616 pattern
    is definitely wrong).

> There is no point for a using spec to be too detailled in
> terms of the syntax. And for the semantics, pointing to BCP 47
> is the best thing to do.

+1 (however a validator should go to the trouble to check what
    it can check, the 4646bis ABNF is no exercise in futility)

 [end of the +1, now for the details:] 
> But I don't think this solves the problems for us.

> In RFC 4646, we defined some tags as well-formed. In RFC 
> 4646bis, we suddenly say that some of these tags are not 
> well-formed.

Some of these well-formed tags were _reserved_ for 4646bis.

They were never _valid_ tags.  Similar example, after some
fights and flamewars 2822upd will admit that there never was
a domain literal using NO-WS-CTL.  It's not yet clear if that
goes straight to /dev/null, or gets an <obs-domain-literal>.

Lately I think the promotion or revision of a standard should
never be done by the original authors, they tend to "know"
too many things that were never spelled out in their document.

> I'm really not sure it is a good thing to do for well-formed
> tags.

Let's ask our ADs, they know the similar issue with 2822upd.

Our <obs-extlang> is a border case, not a simple "MUST NOT
generate, MUST accept", it's "MUST NOT generate, MUST NOT
accept as valid, MUST accept as well-formed" (and the third
MUST could degenerate into a MAY or a SHOULD in practice,
and end up as security issue)

 Frank

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