Media type registration in HTTP

Marc VanHeyningen (mvanheyn@cs.indiana.edu)
Tue, 24 May 1994 23:33:19 -0500


The current hypertext version of the HTTP spec, as well as the
(expired) Internet-Draft, reads as follows with regard to the
registration of content-types:

# EXTRA NON-MIME TYPES
#
# It is reasonable to put strict limits on transfer formats for mail,
# where there is no guarantee that the receiver will understand a weird
# format. However, in HTTP one knows that the receiver will be able to
# receive it because it will have been sent in the Accept: field. There
# is therefore a lot to be gained from a very complete registry of
# well-defined types for HTTP which may nevertheless not be recommended
# for mail. In this case, the content-type list for HTTP may be a
# superset of the MIME list.

It seems to me this paragraph can be eliminated entirely, along with
the concept of a separate registry for HTTP types, in light of the
generalization of media type registration procedures detailed in RFC
1590.

The current document suggests an HTTP registration authority for
content-types; obviously there needs to be some kind of agreement on
what application/foo means so that people can effectively exchange
many types of information with confidence. No registration procedure
is defined, however, for how this authority would accept and maintain
this information. I suggest that, if we were to sit down and and
attempt to write such a specification, the results would bear a
striking resemblance to 1590.

Quoting from that document provides precisely the reason why the
concerns expressed about the strict limits on content type
registration no longer apply and establishing a separate authority
would be a Bad Thing:

#3.1 MIME Requirements for a Limited Number of Content-Types
#
# Issue: In the asynchronous mail environment, where information on
# the capabilities of the remote mail agent is not available to the
# sender, maximum interoperability is attained by restricting the
# number of content-types used to those "common" content-types expected
# to be widely implemented. This was asserted as a reason to limit the
# number of possible content-types and resulted in a registration
# process with a significant hurdle and delay for those registering
# content-types.
#
# Comment: The need for "common" content-types formats does not
# require limiting the registration of new content-types. This
# restriction may, in fact, hinder interoperability by causing separate
# registration authorities for specific applications which may register
# values in conflict with or otherwise incompatible with each other.
# If a limited set of content-types recommended for a particular
# application, that should be asserted by a separate applicability
# statement specific for the application and/or environment.

Anyway, I'd like to see the proposed HTTP content registration folded
into the existing one (for that matter, I wish content encoding could
also be folded into the existing structure, but that's a little
harder) and a note that HTTP exchanges "media types."

--
<A HREF="http://www.cs.indiana.edu/hyplan/mvanheyn.html">Marc VanHeyningen</A>