Media type registration in HTTP

Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 25 May 1994 06:34:51 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <26610.769840399@hound.cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: mvanheyn@cs.indiana.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Media type registration in HTTP
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
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>