Re: Format for type attribute value

On Nov 19, 2007, at 16:00, Julian Reschke wrote:

> 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 rather clear that it is not useful for the attribute to take the  
same value as an email Content-Type header. It appears that the  
attribute is supposed to take a single value that matches the media- 
type production from RFC 2616. I'm not quite sure if this is exactly  
the same thing as the value of the Content-Type HTTP header. I checked  
Necko source code, and it seems to treat Content-Type as a header that  
can take multiple comma-separated values matching media-type.

Moreover, document conformance needs to define if leading and trailing  
whitespace is OK in the attribute value. (For consistency with other  
single-valued attributes, I suggest no.) Also, the HTTP definition of  
LWS doesn't make sense for HTML5 attribute values, so the attribute  
values should probably allow zero or more HTML5 space characters  
around the semicolon.

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

The way I see it is that if unregistered types are routinely deployed,  
the registration mechanism has failed.

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

Good point. All the examples I have in mind are data formats that have  
existed before RFC 4288 was published.

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

Offtopic for this list, but RFC 4288 still says: "Registrations in the  
standards tree MUST be approved by the IESG and MUST correspond to a  
formal publication by a recognized standards body.  In the case of  
registration for the IETF itself, the registration proposal MUST be  
published as an RFC." And that's a problem in case a format is  
initiated by a vendor but the format is later approved by a standards  
body.

>> 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 can't but that doesn't mean there aren't types that could have  
undergone registration under an easier system. My point is that Apple  
asked much less information for a code from a finite space than IANA  
asks for a code from an infinite space. Under the old Apple policies,  
the HTML5 manifest format should have a type code registered already...

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

Thanks. I didn't realize that.

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

Received on Monday, 19 November 2007 19:38:09 UTC