W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: Proposed resolution for Issue 13 (language tags)

From: Felix Sasaki <fsasaki@w3.org>
Date: Wed, 30 Jul 2008 15:48:30 +0900
Message-ID: <48900EBE.6090005@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>
CC: ietf-http-wg@w3.org

Julian Reschke さんは書きました:
>
> Martin Dürst wrote in 
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2008AprJun/0202.html>:
>
>> Also, with RFC 4646, any further (currently being worked on by the 
>> LTRU WG)
>> extensions (not in syntax, but in the number of languages covered) might
>> be excluded. People have been wondering e.g. whether they can use
>> RFC 3066 or RFC 4646 language tags with RFC 2616, we don't want that
>> to happen again. RFC 4646 (and RFC 4647, which defines matching) can
>> be referenced as BCP 47, which doesn't have to be updated even if
>> a new RFC makes more language tags available. The basic syntax
>> is still the same. So I strongly suggest you reference BCP 47
>> rather than a specific RFC.
>
> We've just been looking at it, and we are a bit concerned delegating 
> the matching function to RFC4647. The matching defined in RFC2616 is 
> very simple (prefix based), while RFC4647 seems to be more complex.

RFC 4647 defines a basic language range in sec. 2.1 which is the same as 
the language range of sec. 14.4 of RFC 2616. Note also the information 
in sec. 2.1 of RFC 4647:
"Note that
the ABNF [RFC4234] in [RFC2616] is incorrect, since it disallows the
use of digits anywhere in the 'language-range' (see [RFC2616errata])."
So you could just refer to basic language ranges of RFC 4647 and be fine.

Felix

>
> Do we have any evidence that HTTP/1.1 implementations implement 
> RFC4647? Otherwise this seems to belong into the "future work" basket...
>
> BR, Julian
>
>
Received on Wednesday, 30 July 2008 07:01:21 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:17 UTC