Re: misconceptions about MIME [long]

Nathaniel Borenstein (nsb@thumper.bellcore.com)
Wed, 28 Oct 1992 09:42:16 -0500 (EST) 

Message-Id: <MeveP8m0M2YtJRnHtQ@thumper.bellcore.com>
Date: Wed, 28 Oct 1992 09:42:16 -0500 (EST)
From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
To: NED@sigurd.innosoft.com, masinter@parc.xerox.com,
Subject: Re: misconceptions about MIME [long]
Cc: connolly@pixel.convex.com, wais-talk@quake.think.com,
In-Reply-To: <199210280746.AA11955@pegase.inria.fr>

I think there's something that people are missing in this discussion
that is basic to the MIME philosophy, so here comes my two cents:

MIME is a standard with a very different philosophy from many other
standards (ODA, etc.).  It has been said, not entirely incorrectly, that
MIME isn't a format standard at all, but rather a standard for labeling
and safely encoding data whose format is described by other standards. 
(Indeed, I think a major reason that text/richtext is the most
controversial content-type is that it almost is the ONLY MIME type of
which this is not true.)  The basic idea of putting the minimum possible
information in the header field is a natural outgrowth of this
philosophy, hence the argument that if the information is in the body,
it should not be duplicated in the headers.  

Larry Masinter has pointed out -- quite correctly -- that there are
situations in which this is undesirable.  I find his anonymous ftp
example quite compelling:  I would prefer not to ftp a 50 megabyte file
only to find out that it is the wrong kind of postscript.  I don't
think, however, that requiring a "full" description of the detailed
format information is necessarily the right solution, largely because
defining "full" for any given format is so problematic, and runs the
danger of being inconsistent with the internal information.

Another part of the MIME philosophy is openness and extensibility.  This
openness, I believe, points the way to a more appropriate resolution of
the problem.  It is worth noting that the MIME standard does not close
the book on additional parameters in the content-type line.  That is,
MIME says that a PostScript body part should be labelled as

Content-type: application/postscript

It also says, I believe, that unrecognized parameters should be ignored.
 This means that a MIME-conformant implementation will treat the above
content-type and the following one as equivalent:

Content-type: application/postscript; foo=bar; FavoriteCheese=muenster

Not a very useful example, I'll admit.  But this opens the door for
communities to experiment with what additional parameters might be
useful.  If the wais, gopher, or www communities decided to use MIME as
the base data representation standard, they could easily specify a few
additional parameters for situations of concern to those communities. 
Indeed, as has been pointed out, if the transport system is other than
mail, there are likely to be some diffferent concerns.  (Larry's
anonymous ftp problem, for example, is arguably central to wais and
relatively peripheral to email.)   So it might simply prove to be more
important to the wais community to have the Postscript Level labeled in
the header data than it was to the mail community.  No big deal.  The
consensus in the mail community (at least as reflected on the ietf-822
mailing list, which devised MIME) was that such a parameter was not
particularly necessary or desirable for email use.  The WAIS community
might reach a diametrically opposite conclusion, and can accordingly
extend MIME to include a few extra parameters, content-types, etc.  The
most useful of these, I conjecture, will eventually find their way back
into the email world.  This kind of evolution is precisely the reason I
always felt so strongly that MIME needed a path for graceful evolution,
including the IANA process for registering new content-types, character
sets, and parameters.

So the bottom line for me is that Larry's concerns have definite merit,
but I think that they can easily be accomodated as minor extensions to
MIME.  My suggested path for making those extensions is to first try to
reach a consensus on what extensions are needed for the wais/www/gopher
communities, and then register those extensions with IANA.  If any of
them prove to be problematic in the sense that they need to be
universally implemented -- as opposed to only being implemented among
cooperating software -- the documents defining them can be submitted to
the IAB standardization process.  However, I suspect that official
standard status will not be necessary in most cases.

I hope that sheds some light on muddy waters...   -- Nathaniel