W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: MHTML/HTTP 1.1 Conflicts

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Wed, 28 Jan 1998 14:52:36 -0800
To: Stef@nma.com
Cc: IETF working group on HTML in e-mail <mhtml@segate.sunet.se>, http-wg@cuckoo.hpl.hp.com
Message-Id: <9801281453.aa16445@paris.ics.uci.edu>
>I am fast losing confidence that we can ever resolve our MHTML/HTTP
>interworking problems, as long as the IETF allows HTTP to claim to
>only be MIME-like, while using MIME headers, but with differences from
>the MIME standard?  
>
>Without the surrounding HTTP wrapper, how are we supposed to know
>which kind of MIME object we are dealing with?  Are we supposed to
>sniff it to see if there is any trace of HTTP smell to it?

Stef, I have explained this before.  HTTP is not MIME compliant.
This was not an accident, or a "misunderstanding" of what the IETF
allows -- it was a deliberate and well-considered design decision
in order to maximize the advantages of shared protocol mechanisms
and registries without sacrificing the distinct performance and
adaptability considerations of a directly-connected transfer protocol.
We made that decision not just because it was the way almost all
HTTP servers were implemented, but because it is the right way to
implement an HTTP service.  Most of the work put into RFC 1945 was
to make HTTP/1.x as MIME-friendly as possible, but it is unreasonable
to force bad design decisions onto HTTP just because they were
necessary design decisions for E-mail.

All of the questions you have asked are answered in section 19.4 of
RFC 2068.  In particular, the presence of a MIME-Version header field
indicates that the message content is in complete compliance with the
MIME protocol.  Likewise, the absence of a MIME-Version header field
indicates that a gateway from HTTP to any MIME-compliant protocol
(including e-mail) must provide the necessary conversion.  That solves
all of the interworking problems between HTTP and MIME, and does so
at the most appropriate access point.

Meanwhile, please keep in mind that both Content-Base and Content-Location
were originally designed for HTTP, before the MHTML working group began.
I believe they are the best possible mechanism for doing what MHTML
wants to do, and further that all of MHTML's decisions prior to the
notion of allowing multiple Content-Location header fields (now gone)
have matched those made by HTTP.

I have yet to see any case where the MHTML specifications and HTTP
specifications collide.  I have seen cases where MHTML has deliberately
specified limitations in the transfer syntax in order to satisfy
nonexistent gateway limitations in e-mail, which I believe to be a poor
design.  If MHTML is to be truly independent of differences between
protocols, then it should only require line-length and encoding
when they are necessary for safe transfer.

....Roy
Received on Wednesday, 28 January 1998 15:04:40 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:11 EDT