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

Proposal: i67 - quoting charsets

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 8 Apr 2008 10:38:19 +1000
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>
Message-Id: <D4475606-0D20-4DA9-B2CE-743DBBBF2D2D@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>

so, the proposal is:

- leave accept-charset as-is.
- explicitly allow all media-type parameters defined as a token to  
occur as a quoted-string, and make them equivalent (p2 section 3.3).

Thoughts?


On 06/04/2008, at 9:59 AM, Henrik Nordstrom wrote:

>
> fre 2008-04-04 klockan 16:55 +1100 skrev Mark Nottingham:
>> At any rate, the interesting thing to me here is that the argument  
>> for
>> allowing quoted charset content-type parameters seems to be that the
>> BNF for params is
>> token | quoted-string
>> i.e., all parameters inherit the ability to be quoted from the  
>> generic
>> BNF.
>
> Yes. Simplifiers parsers consiredably if they don't need to know the
> parameter token to tell if it's value is allowed to be quoted or not.
>
>> However, as part of the discussion of our favourite issue, #74, we've
>> come to the place where saying that field-content is *not* subject to
>> RFC2047 encoding generically, even though its BNF refers to TEXT
>> (albeit in comments).
>
> Not entirely sure what you refer to.
>
> RFC2047 is very strict on when it may be applied.
>
> The 2616 BNF very often uses constructs where 2047 can not be applied,
> either from the BNF only allowing ASCII (not TEXT) or from being  
> outside
> the scope where RFC2047 may be applied.
>
>> As far as accept-charset goes, I'm fine with leaving it just a token,
>> and don't think we need any change there.
>
> +1
>
> Regards
> Henrik
>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 8 April 2008 00:38:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:47 GMT