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