Re: [apps-discuss] Possible IESG statement on IESG processing of MIME type registrations from other SDOs

[Larry Masinter <[e-mail]>]

This proposed IESG statement fails to address any of the significant difficulties:

Registering MIME types is an activity that has high cost and little benefit.  Cost in terms of learning the process (poorly documented, inconsistent, hard to follow) and following it (responding to reviewer comments). Little benefit, in that the registry plays little or no role in the actual implementation and deployment cycle for new values. 

This issue applies also to URI schemes, and to some degree to other (web-) and perhaps (application-level) parameters.

The high cost and low benefit holds in general for any organization deploying a new or updated content type. While it is also true for other SDOs, the proposed statement does not address the general problem, and might even make the situation worse, by making the SDO process even more different from the non-SDO problem.  

(It does not address the cost/benefit tradeoff for SDOs either, except perhaps to trade off one cost -- cost of learning a cumbersome and poorly documented process -- with another.)

With MIME types and charset values, there are additional consequences:

Because some organizations and implementations originally did not supply the correct registered values, many implementations override the provided MIME types and character encoding assertions (use of registered values) by "sniffing" https://tools.ietf.org/html/draft-ietf-websec-mime-sniff  see also
 http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mime-types
http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding .

More problematic is when the "ownership" of a MIME registration is in dispute, for example when there are multiple, different specifications which claim to be the authority on a registered value, e.g., the two registries for the same MIME value http://www.whatwg.org/specs/web-apps/current-work/multipage/iana.html vs. http://dev.w3.org/html5/spec/iana.html  pointing to substantially different specifications. 

The proposed IESG statement does not address this issue, and, in fact might exacerbate it, by making the registration process for SDOs more difficult than the non-registration-process for non-SDOs.

 (Too bad the IAB document on "Design Considerations for Protocol Extensions" http://tools.ietf.org/html/draft-iab-extension-recs#section-3.6   doesn't take on these issues). 

Larry