Re: Format for type attribute value

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

Yeah, but the attribute in question takes the same value as the 
Content-Type header, doesn't it?

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

But that doesn't mean that the registry is dysfunctional; it just means 
people either haven't tried, or have tried and failed to register. In 
the latter case, it may be because the registration information was 
insufficient, in which case I would consider it a feature if the 
registration was rejected.

Also note that the registry procedure was revised not so long ago, so 
what may have been true about the old one may not be true anymore.

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

That's fine -- so do I and thus I went through the standards process to 
register the format.

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

I think all that needs to be supplied is sufficient registration 
information. Can you point to a recent example where a registration was 
denied although that information was there?

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

Well, that's to true anymore, as RFC2048 has been obsoleted by RFC4288, 
and the latter one defines many methods to register types without a 
standards-track RFC (it may have been incorrect even for RFC2048).

Best regards,

Julian

Received on Monday, 19 November 2007 14:01:15 UTC