- From: <bugzilla@jessica.w3.org>
- Date: Sat, 10 Mar 2012 19:16:05 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16302 --- Comment #2 from Glenn Adams <glenn@skynav.com> 2012-03-10 19:16:02 UTC --- (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: (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"; 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:16:07 UTC