Re: charset / Content-Type BNF flaw in RFC2616

Andreas Maier wrote:
> 
> ... resending after getting subscribed to the list ...
> ...

Interesting. Looking at <http://tools.ietf.org/html/rfc2045#section-5.1>:

" Note that the value of a quoted string parameter does not include the
   quotes.  That is, the quotation marks in a quoted-string are not a
   part of the value of the parameter, but are merely used to delimit
   that parameter value.  In addition, comments are allowed in
   accordance with RFC 822 rules for structured header fields.  Thus the
   following two forms

    Content-type: text/plain; charset=us-ascii (Plain text)

    Content-type: text/plain; charset="us-ascii"

   are completely equivalent."

 > ...
> Back to the flaw in RFC2616. The flaw is that the BNF definition of the
> "Content-Type" production does not utiilize the "charset" production
> defined in section 3.4, and therefore an occasional reader of RFC2616 who
> follows the BNF dependencies, does not necessarily notice section 3.4 and
> hence arrives at the conclusion that the quoted and unquoted form are both
> equally ok. Which is what happened to me ;-)

I think the intent indeed was to make them equivalent.

> I suggest to fix this by utilizing the "charset" production somewhere in
> the "Content-Type" production. Maybe at the level of "media-type". In
> addition, an explicit reference to section 3.4 could be added to the
> description of Content-Type in section 14.17.
> 
> I believe that specs like RFC2616 are not always read top to bottom in one
> flow, but are often used as a reference to answer particular questions, and
> this change would improve the capability of RFC2616 to allow for that.
> ...

Best regards, Julian

Received on Wednesday, 23 May 2007 12:04:52 UTC