- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 19 Nov 2007 13:32:23 +0100
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: "public-html@w3.org List" <public-html@w3.org>
Henri Sivonen wrote: > Quoting the spec: >> The type attribute gives the MIME type of the linked resource. It is >> purely advisory. The value must be a valid MIME type, optionally with >> parameters. [RFC2046] > > For attributes that take "a valid MIME type, optionally with > parameters", the spec references RFC 2046. I think this normative > reference doesn't meet the level of quality expected of HTML5. Agreed. As far as I can tell, right now most references are work-in-progress. IMHO they really should cite concrete sections, so that a reader has a real chance to find out what's being referenced without having to scan the full text. > First, the syntax spec is awfully fragmented. First one has to follow a > normative reference to RFC 2045. Then one has to look up additional > rules from the future from RFC 2822. Moreover, the syntax doesn't define Q: why is RFC2822 needed? > the syntax for MIME types as such. Instead, it defines the entire > Content-Type header for Internet email. But that's exactly what HTML5 want, or did I miss something? > The syntax for the entire header is gratuitously complex: white space is > allowed between tokens in surprising places and there's even syntax for > comments hidden in the specs! Preliminary evidence from #whatwg suggests > that the full syntax is not interoperably implemented in the browser > context. > > Also, the requirement for the MIME type to be "valid" is problematic, > because the registration mechanism is dysfunctional. Requiring Last time I wanted to register a MIME type it worked for me. Could you elaborate exactly how it is "dysfunctional"? > conformance checkers to know about the IANA registry for e.g. language > tags is feasible (and implemented :-). However, it would be unhelpful to > flag unregistered MIME types as HTML5 conformance errors, since > unregistered types are commonly used interoperably on the Web. IMHO it should be a warning. > It seems to me that the spec should refer to section 3.7 of RFC 2616 > instead. I also suggest not implying that HTML5 conformance depended on That's definitively a better way to define it. > the IANA media type registry. I'm not even sure it currently depends on the registry. Does RFC2045/6 define "valid" anywhere? I would agree if it said "registered". Best regards, Julian
Received on Monday, 19 November 2007 12:32:51 UTC