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

Re: MHTML/HTTP 1.1 Conflicts

From: Jim Gettys <jg@pa.dec.com>
Date: Mon, 26 Jan 1998 11:08:23 -0800
Message-Id: <9801261908.AA22571@pachyderm.pa.dec.com>
To: Stef@nma.com
Cc: IETF working group on HTML in e-mail <mhtml@segate.sunet.se>, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5279

>  Sender: stef@nma.com
>  From: Einar Stefferud <Stef@nma.com>
>  Date: Sun, 25 Jan 1998 00:13:37 -0800
>  To: IETF working group on HTML in e-mail <mhtml@segate.sunet.se>,
>          http-wg@cuckoo.hpl.hp.com
>  Subject: Re: MHTML/HTTP 1.1 Conflicts 
>  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? 

By its MIME type.  HTTP has adopted the HTTP type registry, lock stock and 
barrel.  There is one place, where HTTP has relaxed this: text types, 
reflecting the reality of the Web, where you don't (necessarily) get CRLF's 
for line delimiters, and don't have line length restrictions. This is 
acknowleging existing practice, not something we believe is necessarily 
desirable (though it is pretty clear that one of the reasons the Web succeeded 
was that pretty well arbitrary plaintext documents could be served up without 
modification, early in the Web).  This reflects the reality of the text 
content on the Web, and how it was prepared, and that HTTP servers treat 
all datatypes the same, as bags of bits (possibly with some metadata).

Note that any fully conformant (i.e. email) text body and/or message is, 
however, a valid HTTP text entity.  This is one saving grace for interoperability.

> Are we supposed to
>  sniff it to see if there is any trace of HTTP smell to it?
>  I raise this issue now because we need a reading on this situation
>  from our APP Area Directors, and perhaps from the APP Area
>  Directorate.
>  I do not see how we can ever sort things out when any IETF standard
>  claims to be MIME, but not quite, while it references the MIME
>  standard, and uses MIME standard headers that do not conform to the
>  MIME standard.

I don't think HTTP claims to be MIME.  It certainly borrows both
syntax and lots of usage, and the type registry from MIME.

>  This is a sure recipe for a long term (like continuing forever) series
>  of interworking problems.

Yup.  Best we can do is try to avoid new ones.

>  It seems to me that if any standard claims to be MIME-like, that it
>  should have been required to choose new names for its headers and to
>  strcitly conform to the MIME standard in its use of any MIME headers.

You won't get any argument out of us; we certainly agree.  But it is water under
the dam, in some cases.

>  I have no idea what to do about this situation, but I am having great
>  difficulty trying to figure out how we are ever going to be able to
>  close on our MHTML standard and hope for consistent interworking with
>  MIME objects created for HTTP tansport, without our adopting the HTTP
>  MIME-like standard for our MIME standard.
>  Are we supposed to just give up because of some serious mistakes made
>  by HTTP in the distant past?

I don't think things are quite a bad as you make out.

You are still trying to think of HTTP as MIME; it isn't...

Note that the HTTP standard has been trying as best it can to mitigate the
damage for a long time.
>  Will someone please explain how this is supposed to work?

Think of HTTP as a generic "bag of bits transport" protocol, using
MIME types to type the bags of bits, and you'll get the general idea.
(FTP with types on steroids).

MHTML and MIME as far as HTTP is concerned is just one more datatype, one that
happens to strongly resemble HTTP in syntax.

That it looks like MIME is pretty much an accident of history, in my
humble opinion; the confusion this has caused has haunted HTTP and now will
haunt MIME and MHTML for years.

HTTP is enough like MIME to confuse even the non-innocent (or maybe
particularly the non-innocent) into believing it is MIME.  So people who
don't know MIME, just find HTTP a baroque and wierd transport protocol, while
those who come to HTTP from MIME get all confused.  So, in our experience,
it is the MIME experts who have the biggest trouble getting their
heads around HTTP.

I wish there were a magic wand to "fix" this, and the resulting confusion; 
there isn't one I can find.  If I had been the one to design HTTP, it wouldn't 
have looked like RFC 822...

					- Jim Gettys

Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
jg@w3.org, jg@pa.dec.com
Received on Monday, 26 January 1998 11:10:44 UTC

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