- 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
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 Content-Typing. 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". Cheers...\Stef >From your message Sun, 5 Oct 1997 11:03:52 PDT: } }Jacob, } }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. } }Regards, } }Larry }-- }http://www.parc.xerox.com/masinter
Received on Sunday, 5 October 1997 13:44:15 UTC