- From: <bugzilla@jessica.w3.org>
- Date: Sat, 10 Mar 2012 19:31:42 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16302 --- Comment #3 from Julian Reschke <julian.reschke@gmx.de> 2012-03-10 19:31:42 UTC --- (In reply to comment #2) > (In reply to comment #1) > > RFC 2616's ABNF has "implied Linear Whitespace", see > > <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.1>. > > > > Compare the media type definition with: > > <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-18.html#media.types> > > thanks for reminding me of that; i had looked for this but didn't find it; > > in any case, I wonder why it is necessary to require the use of *optional* > whitespace in this case where it is not specified in the two cases immediately > above the one cited here: It's not. It's a case of over-specification. > (1) Let mime type be "application/xml" or "text/html" if Document is an HTML > document, followed by ";charset=", followed by encoding. > > (2) Let mime type be "text/plain;charset=UTF-8". > > on the surface, this behavior appears to be inconsistent; > > further, since this is effectively defining a serialization rule, i wonder how > this relates to the "canonical form" of an "Internet media type"; That is about a canonical form of the *payload*, not the Content-Type header field. > unfortunately, the language about canonicalization in RFC2616 [1] and httpbis > [2] does address this point adequately (nor does it address the case of > multiple same-named parameters); > > [1] > http://greenbytes.de/tech/webdav/rfc2616.html#canonicalization.and.text.defaults > [2] > http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-18.html#canonicalization.and.text.defaults -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Saturday, 10 March 2012 19:31:45 UTC