W3C home > Mailing lists > Public > public-html@w3.org > February 2011

Re: ISSUE-125: charset-vs-quotes - Straw Poll for Objections

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 26 Feb 2011 20:08:29 +0100
Message-ID: <4D694FAD.8090806@gmx.de>
To: Philip J├Ągenstedt <philipj@opera.com>
CC: public-html@w3.org
On 26.02.2011 19:46, Philip J├Ągenstedt wrote:
> On Sat, 26 Feb 2011 18:50:21 +0100, Julian Reschke
> <julian.reschke@gmx.de> wrote:
>
>> a comment on Philip's objection in
>> <http://www.w3.org/2002/09/wbs/40318/issue-125-objection-poll/results>:
>>
>>> ...
>>> More importantly, the suggested change does not appear to actually
>>> align the spec with RFC2616, which was the whole point. Here's my
>>> reading:
>>>
>>> 1. Start at Content-Type
>>> <http://tools.ietf.org/html/rfc2616#section-14.17>
>>> 2. Follow reference to Media Types
>>> <http://tools.ietf.org/html/rfc2616#section-3.7>
>>> 3. Find "Parameters MAY follow the type/subtype in the form of
>>> attribute/value pairs (as defined in section 3.6)" It says MAY, so I
>>> would really stop here, saying that HTTP doesn't define how to parse
>>> parameters of Content-Type.
>>
>> How so? You seem to have a strange understanding about what
>> MAY/OPTIONAL means.
>
> Yes, RFC 2119 is not my mother tongue. It seems like MAY here means that
> it's optional for implementations to handle the parameter syntax, not
> that specs or implementations could ever allow some other syntax here.
> I've removed the nitpick from my objection.

Ah, I see. We can clarify that in httpbis.

>>> 4. Ignore the MAY and follow the reference to Transfer Codings
>>> <http://tools.ietf.org/html/rfc2616#section-3.6>
>>> 5. Follow the reference to quoted-string in
>>> <http://tools.ietf.org/html/rfc2616#section-2.2>
>>>
>>> We've arrived at:
>>>
>>> quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
>>> qdtext = <any TEXT except <">>
>>> quoted-pair = "\" CHAR
>>>
>>> Since the suggested change doesn't handle the backslash-escaping
>>> mechanism, it is failing to 'parse quotes in Content-Type headers in
>>> "meta" elements in a HTTP compliant manner', so it would not be
>>> appropriate remove the willful violation note based on the reasoning
>>> in this CP.
>>
>> Implementing backslash-escaping is a separate issue (ISSUE-126). I
>> have tried to treat these as orthogonal issues, and the CP is pretty
>> clear about that.
>
> If ISSUE-125 depends on the outcome of ISSUE-126 then they should have
> been considered together, but that's up to you and the chairs. As things
> stand, if just your CP for ISSUE-125 is accepted then the resulting
> algorithm will not 'parse quotes in Content-Type headers in "meta"
> elements in a HTTP compliant manner', and so the willful violation
> cannot be removed.

Well, they have been raised together. The timing of the polls is 
something outside my control.

BR, Julian
Received on Saturday, 26 February 2011 19:09:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:22 GMT