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

Re: MHTML/HTTP 1.1 Conflicts

From: <stef@nma.com>
Date: Wed, 28 Jan 1998 15:17:51 -0800 (PST)
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: IETF working group on HTML in e-mail <mhtml@segate.sunet.se>, http-wg@cuckoo.hpl.hp.com
Message-Id: <RM:c0d83d13.0019cc66.0>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5303
Thanks Roy for punctuating our discussons with very clear marks.

Until we have a very clear conclsion that MHTML and HTTP do not collide, it
continued to make me very nervous about havig to recycles again at
none of us want that to happen, and none of us want to later be found to
have ignored any collision that should hav been found at this stage.

Per your suggestions that MHTML might be further simplified, I suggest that
our editing team lok very carfully at your suggestions to see if we can use
them as you predict.


At 14:52 28/1/98 -0800, Roy T. Fielding wrote:
>>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.
Received on Wednesday, 28 January 1998 15:21:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC