Re: HTTP MIme content-type parameters
Timothy Berners-Lee <timbl@dxcern.cern.ch>
Date: Mon, 6 Dec 1993 20:24:25 +0100 (MET)
From: Timothy Berners-Lee <timbl@dxcern.cern.ch>
Subject: Re: HTTP MIme content-type parameters
To: Marc Andreessen <marca@ncsa.uiuc.edu>
Cc: Jim Davis <davis@dri.cornell.edu>, www-talk@nxoc01.cern.ch
In-reply-to: <9312050948.AA16357@wintermute.ncsa.uiuc.edu>
Message-id: <Pine.3.07.9312062019.A19717-b100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 5 Dec 1993, Marc Andreessen wrote:
> Jim Davis writes:
> > The HTTP draft RFC violates the MIME RFC 1341 specification for the
> > use of parameters in content types. There are two problems.
> >
> > 1) The MIME RFC states that parameters are separated from the subtype
> > by a semi-colon, e.g.
> >
> > text/plain; charset=us-ascii
> >
> > But the HTTP draft says uses semi-colon to separate alternative
> > content-types, and uses comma to separate parameters.
> >
> > HTTP should change to conform to MIME, e.g. the example on p 8 should
> > be:
> >
> > Accept: text/x-dvi; q=.8;mxb=10000;xmt=5.0, text/x-c
No problems with that -- I should have checked more thoroughly
that we were using it in the same way. It feels kinda
strange to have, unlike in English, commas having higher
precedence than semicolons; I guess I will get used to it though.
> > 2) The MIME spec considers period to be a tspecial, which means it is
> > forbidden to use it within a token. It must instead be quoted. So
> > the example on page 8 should be:
> >
> > Accept: text/x-dvi; q=".8";mxb=10000;xmt="5.0", text/x-c
> >
> > Can we agree to bring the HTTP spec in line with MIME standard?
>
> I think this is essential. Anyone have a problem with the proposed
> changes? Tim?
Definitely. I want in the end to be able to use the same
parser for mailed MIME as well as HTTP MIME -- with as
few flags as possible! (like 0)
I'll make the changes when I'm back at my desk.
Thanks for pointing them out.
Tim