Re: Format for type attribute value

On Nov 19, 2007, at 14:32, Julian Reschke wrote:

> Henri Sivonen wrote:
>> 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?

To find definitions for quoted strings, whitespace placement and  
comments.

>> 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?

No, HTML5 has nothing to do with Internet email headers. In fact,  
after the experience this morning of reading the referenced RFC  
instead of the more useful RFC (2616), I'm inclined to presumptively  
consider any normative references to the email stack RFCs spec bugs in  
HTML 5.

>> 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"?

It is dysfunctional, because there are well-known formats that are or  
have been without a MIME type for extended periods of time during  
which either an x- type got entrenched or an unregistered type was  
deployed. Also the vendor tree concept is broken in *practice*,  
because formats outlive their organizational affiliations and people  
instinctively want their types to look like simple main tree types.

As for why that has happened, I think it's because IANA registration  
isn't a fast first-come-first-serve system without value judgments.  
Instead, anyone wanting to register an identifier has to show the  
worthiness of the format for which the identifier is being registered  
and has to deal with more red tape than absolutely necessary to mint  
an identifier. The process is a total overkill compared to how HFS  
type and creator codes were registered from Apple in the old days. And  
the HFS codes were even from a finite value space and the process  
still worked.

>> 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.

At the moment, I am not doing warnings for attribute data types,  
because the infrastructure does not allow 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".

The ietf-token production in RFC 2045 is defined as "An extension  
token defined by a standards-track RFC and registered with IANA."

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 19 November 2007 13:16:30 UTC