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 at ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.