W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Is MHTML only for e-mail?

From: Einar Stefferud <Stef@nma.com>
Date: Sun, 05 Oct 1997 12:05:28 -0700
To: mhtml@segate.sunet.se, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <2165.876078328@nma.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4519
I agree with Larry's analysis and conclusions (though so agreeing may
surprise almost everyone;-)...  Our agreeing may actually be shocking!

Larry and I have not discussed what I am going to say here, but I hope
he will find that it agrees with his statements included below.  We
did not discuss his message before he mailed it either;-)...

I think that we have been slowly converging on our positions over
time, to the point of understanding that HTTP and SMTP/RFC822 and
other different application transports must be kept separate from MIME

Perhaps part of what we are recognizing is that there are two classes
of "TRANSPORT" protocols.  One just above the IP level that deals with
data streams and user datagrams that deal with interoperability, and
another class just below MIME that deals with transport of Application
Information Objects to provide what I like to call "interworkability".

The whole idea of MIME Content-typing is to achieve transport
independence from this application transport level, and our new
Multipart/Related specs (et al) must fully support this idea.

That "web browsing" and "mail" are very different user paradigms for
exchanging end user application information should be now be a well
established fact, and the need to be able to use both to exchange the
same information objects in different situations should also be well
established.  Neither of our two primary application transports (HTTP
and SMTP/RFC822) will ever replace the other and we should expect that
many new variations will be invented between these two extremes to add
lots more variety to the ways that we transport MIME wrapped entities.

So, MIME looks to me to be a higher level second "neck" for the
Internet "hourglass" model, with IP at one neck and MIME at the other.
Looking at things this way seems to be very helpful to me.

The main thing is to step "out of the box" and see that the Internet
Protocol Suite need not be limited to having only one "neck".


rom your message Sun, 5 Oct 1997 11:03:52 PDT:
}1) HTTP vs. "web browsing"
}It would be useful to consider separating "HTTP" out from the
}application of "web browsing", in the same way that "SMTP" is
}separate from the application of "mail". Currently, the world
}commonly uses "HTTP" and "HTML" and "URL" and various other
}common components to deploy the "web browsing" application.
}HTTP is also used for many other applications, and the "web
}browsing" application can be supported using many other protocols,
}as indicated by the URL scheme employed.
}HTTP places no restrictions on what media types it transports.
}MHTML defines a new media type, "multipart/related". The
}definition of "multipart/related" must be independent of
}the protocols which are used to transport it.
}I would urge that the definition of "multipart/related" be separated
}from the application of "mailing someone a web page" (MHTML).
}The definition of "multipart/related" should make clear that it
}is a general extension to MIME multipart, and applies to *all*
}applications that use MIME (including web browsing).
}I would object to having the MHTML say that it 'applies to HTTP'
}since such a statement would contribute to the existing confusion
}between the transport protocol (HTTP), the media types it is used
}to transport, and the applications that are being supported by
}such a combination.
Received on Sunday, 5 October 1997 13:44:15 UTC

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