Subject: [Ltru] ABNF guidance

From: Addison Phillips <[email-masked]>
Date: Thu, 17 Jan 2008 13:55:39 -0800

All,

(This note is being sent on behalf of the W3C Internationalization Core 
Working Group, which I happen to chair. Note that this also means that 
it is as a technical contributor and not as editor of 4646bis)

During our most recent teleconference [1], the I18N Core WG discussed 
the changes proposed for the ABNF by LTRU (to remove the extlang 
production).

I was tasked with reporting some concerns about how to address this with 
Spec writers at W3C and elsewhere. The concern is that the I18N Core WG 
has been recommending that references to RFC 3066 be changed to 
reference BCP 47 (rather than a specific RFC number). In one particular 
case (XML Schema 1.1) we requested that their language production be 
derived from the ABNF in BCP 47, that is, from the ABNF in RFC 4646.

The problem is that productions included into XML DTDs are then relied 
upon by implementations and difficult to change. There is naturally some 
resistance to changing the production in XML Schema and some concern 
that the grammar isn't fully stabilized. There is thus concern about the 
future stability of the ABNF. The I18N Core WG would therefore like to know:

- if LTRU can make a stability statement about the ABNF in 4646bis (e.g. 
what may change in the future and what is unlikely to change)
- if LTRU could include text about compatibility between 4646 ABNF and 
4646bis ABNF in 4646bis
- if LTRU would recommend a particular reference to an RFC or continue 
to recommend the BCP reference for this purpose

Best Regards,

Addison

[1] http://www.w3.org/2008/01/16-core-minutes#item06
-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 18 Jan 2008 10:04:14 +0100

Addison Phillips wrote:

> I was tasked with reporting some concerns

Note it as *done*.

> In one particular case (XML Schema 1.1) we requested that their
> language production be derived from the ABNF in BCP 47, that is,
> from the ABNF in RFC 4646.

Is that about <http://www.w3.org/TR/xmlschema11-2/#language> ?

That says [a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})* based on RFC 3066,
perfectly compatible with 4646 or 4646bis.

For <http://www.w3.org/Bugs/Public/show_bug.cgi?id=2439> I'm not
sure what it means, but it's no "help, the IETF screwed up".

And in <http://www.w3.org/Bugs/Public/show_bug.cgi?id=3079> the
second comment did not yet hardwire any soon obsolete 4646 ABNF. 

> There is naturally some resistance to changing the production
> in XML Schema and some concern that the grammar isn't fully
> stabilized. There is thus concern about the future stability
> of the ABNF.

"Stablity" can mean lots of things.  A future extension could
introduce a limit "6" for its own hyphen-separated "items".  It
can't introduce "9" without breaking the old RFC 3066 limits,
of course RFC 4646 and likely I-D.4646bis also don't allow "9".

> - if LTRU can make a stability statement about the ABNF in
>   4646bis (e.g. what may change in the future and what is
>   unlikely to change)
   
I certainly expect 4646bis to be backwards compatible with 4646
and 3066.  I'd have some reservations about 4646bis stability
statements.  The proposed "fantasy island" codes are not funny,
at the moment it's not clear that 4646bis survives a Last Call.

> - if LTRU could include text about compatibility between 4646
>   ABNF and 4646bis ABNF in 4646bis

LTRU could, but it's completely beside the point, the *reserved*
<extlang> contruct was removed.  4646 parsers accepting it will
continue to work for 4646bis tags, that was precisely the point
of the reservation.  The opposite case, 4646bis introduces a new
<extlang> contruct breaking 4646 parsers, would be bad, and 4646
saw to it that it won't happen.  If that doesn't talk for itself
then more text about this historical curiosity also won't help. 

> - if LTRU would recommend a particular reference to an RFC or
>   continue to recommend the BCP reference for this purpose

That's up to the specification using it, e.g. an implementation
expecting US-ASCII with hex. NCRs in the "BCP 47 registry" will
fail miserably when 4646bis introduces UTF-8 without NCRs.  So
in that case referencing RFC 4646 would have been clearer, even
if it doesn't help to fix the implementation.  

OTOH HTTPbis can pick whatever it likes, BCP 47 or RFC 4646, it
does not depend on the version, it has to fix the RFC 2616 ABNF
for language tags.

 Frank