Re: Format for type attribute value

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