Re: Imcompatible HTTP/1.0 on different severs
Keith Moore <moore@cs.utk.edu>
Message-id: <9307150538.AA12297@thud.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: sanders@bsdi.com
Cc: www-talk@nxoc01.cern.ch, moore@cs.utk.edu
Subject: Re: Imcompatible HTTP/1.0 on different severs
In-reply-to: Your message of "Wed, 14 Jul 1993 21:38:30 CDT."
<9307150238.AA05620@austin.BSDI.COM>
Date: Thu, 15 Jul 1993 01:38:13 -0400
Sender: moore@cs.utk.edu
Status: RO
Date: Wed, 14 Jul 1993 21:38:30 -0500
From: Tony Sanders <sanders@bsdi.com>
> Note that application/binary isn't a valid MIME type, it's supposed to be
> application/octet-stream.
>
> The MIME people are partially to blame for this mess, a) they should have
> defined more common types up front and b) it seems to be a pain to get
> new types accepted (I haven't tried but the fact is that not many types
> are registered so something must be wrong).
Keep in mind that the MIME documents that define the initial content-types
have to pass the Internet standardization process; this implies certain
constraints, including : having a precise specification for each
content-type that permits independently developed implementations to
interoperate, and consideration of security issues.
The registration process for nonstandard MIME types is somewhat less stringent.
Part of the reason that "not many types are registered" is that it
does take some time to discover what the registration process is.
There's also some unwritten "MIME culture" that has to be learned if
newly defined types are to fit within the MIME framework. The various
parties are becoming familiar with the issues and trying to address
them.
> See below for my list of types in case anyone wishes to "standardize" on
> what I've dug up (aka seen other people use) OR tell me I'm full of it
> and need to fix ones that are "wrong". I just dug these up (mostly from
> NCSA Mosaic and TkWWW plus various postings I've seen) so many may be
> wrong and I'm happy to fix them if someone will just tell the most common
> usage.
The following types are not registered:
> $ext{'dmp'} = $ext{'DMP'} = 'image/x11-dump';
> $ext{'etx'} = $ext{'ETX'} = 'text/setext';
> $ext{'pbm'} = $ext{'PBM'} = 'image/portable-bitmap';
> $ext{'pgm'} = $ext{'PGM'} = 'image/portable-graymap';
> $ext{'pnm'} = $ext{'PNM'} = 'image/portable-anymap';
> $ext{'ppm'} = $ext{'PPM'} = 'image/portable-pixmap';
> $ext{'ras'} = $ext{'RAS'} = 'image/cmu-raster';
> $ext{'texi'} = $ext{'TEXI'} = 'application/texinfo';
> $ext{'x11'} = $ext{'X11'} = 'image/x11-dump';
> $ext{'xbm'} = $ext{'XBM'} = 'image/xbitmap';
> $ext{'xwd'} = $ext{'XWD'} = 'image/xwindowdump';
The following types are not registered, and have security concerns.
The rfc822 extensions working group considered proposals along these
lines and rejected them for this reason. This does not mean that such
types cannot be registered (registration itself does not imply
endorsement), but an analysis of the security risks is needed.
> $ext{'dvi'} = $ext{'DVI'} = 'application/dvi';
> $ext{'latex'} = $ext{'LATEX'} = 'application/latex';
> $ext{'tex'} = $ext{'TEX'} = 'application/tex';
Other stuff:
> $ext{'html'} = $ext{'HTML'} = 'text/html';
Not registered yet; I think the proposed name is for application/html.
> $ext{'rtf'} = $ext{'RTF'} = 'application/x-rtf';
There is actually an application/rtf type registered; so you don't need the X-.
> $ext{'mime'} = $ext{'MIME'} = 'www/mime';
This should probably be "message/rfc822".
> $ext{'shar'} = $ext{'SHAR'} = 'archive/shar';
> $ext{'tar'} = $ext{'TAR'} = 'archive/tar';
New top-level types are harder to register. There are also security
concerns that need to be addressed.
> $encoding{'uu'} = $encoding{'UU'} = 'x-uuencode';
X-types don't require any agreement, of course, but some MIME mail
readers do support the "x-uue" encoding. The filename within the
uuencoded file is likely to be ignored by these mail readers.
Keith Moore