- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 8 Apr 2008 10:38:19 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Henrik Nordstrom <henrik@henriknordstrom.net>
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 UTC