> 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