Re: Multiple Content-Location headers

>  Sender: stef@nma.com
>  From: Einar Stefferud <Stef@nma.com>
>  Date: Tue, 13 Jan 1998 15:26:31 -0800
>  To: Jim Gettys <jg@pa.dec.com>
>  Cc: Jacob Palme <jpalme@dsv.su.se>, Scott Lawrence <lawrence@agranat.com>,
>          IETF working group on HTML in e-mail <mhtml@segate.sunet.se>,
>          http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>  Subject: Re: Multiple Content-Location headers 
>  
>  Hi Jim -- Speaking as MHTML Chair, I must observe that you sound a lot
>  like I sounded when I first looked at a lot of the stuff going on in
>  HTTP;-)...  Just ask Larry Masinter;-)...  He bore the brunt;-)...
>  
>  Since then MHTML and HTTP have been cooperating at least at the Chair
>  & Editor levels.  I expect that more of the MHTML participants have
>  been aware of this inter-WG negotiation because most of it was
>  broadcast to the MHTML list.  Larry Masinter and Roy Fielding were the
>  primary negotiators on the HTTP side.  I expect that most of the
>  issues seemed to be minor adjustments not needing broad HTTP WG
>  efforts, but they were more important to MHTML at the time.
>  
>  So, welcome to the club;-)...  Some of us have been waiting a long
>  time to get this MHTML/HTTP discussion under way;-)...  We really do
>  need to sort this out among us and try to find Rough Consensus across
>  both WGs, if not more WGs.
>  
>  Now then, a detail:
>  
>  How are you going to handle HTTP retrieval of archived ever-changing
>  weather maps (that normally change within a given URI which stands for
>  "the current weather") that have been archived as compound MHTML "MIME
>  Objects"?  If you don't retrieve each of them with all of their
>  archived parts, how are you ever going to reconstruct what the weather
>  was at any time in the past?
>  

There is a presumption you have made here: that the archiving is being done 
via compount MHTML documents.  A case has yet to be made that this will 
happen.  It certainly doesn't happen today.  

You can try to make a case that it might happen if the facilities were there, 
of course).  Equally likely in my opinion though is the inverse, that mail 
as we know it becomes pretty integrated to the Web, rather than the inverse.  
This message is being composed on a prototype mail system which has many 
of these properties already, for example.  All mail messages I get end up 
with a URL, the mail user agent only uses HTTP (it is written in Java), 
and I can say from first hand experience that this has much to commend it.
(The mail is delivered to the web server via SMTP, but that
could be fixed :-).)

But back to the present: Mail archives in the Web are typically handled 
by a program that takes mail messages as input and generates HTML as a set 
of Web documents. An equally plausible extension to handle mhtml is to retrieve 
the attached documents at the time the HTML is generated from the mail message, 
rather than presuming the data is inline.  This requires no protocol
support beyond what exists today (though arguably is not as atomic in nature).

>  So, having found at least one case that is clearly going to make good
>  use of MHTML for archiving and transfering compound web objects, how
>  are we going to enable this across the whole spectrum of transports
>  (HTTP, RFC822, FTP, SneakerNet, CDROM, EtcNet) for such compound WEB
>  objects whose parts need to be bound to each other?
>  
>  Best...\Stef

Fundamentally, HTTP talks about a single document at a time; this
is inherent throughout the protocol; in the caching sections, and
all over.  All methods take a single URI as an argument; not a list
of URI's.  This presumption is inherent throughout the design.

There is alot of work on what are called "collections" going on in Webdav.
While I have my reservations on details of what they are proposing, the
concept is cleaner, in my humble opinion: it should be possible to
define a document which is a collection of related documents.
This would fill the scenario you outline, as I understand it,
along with many others.

Note since such collections can have URI's of their own, it fits
well into the model of the Web.

The transport of MHTML message as a mime type over the HTTP protocol, is 
perfectly possible and a solution everyone would happy with.  It is perfectly 
reasonable in this model that your MHTML document will be retrieved via 
HTTP (as the HTTP entity), passed to an MHTML viewer, and everything will 
work fine. ("Any problem in computer science can be solved by an extra level 
of indirection" - Roger Needham).  In this scenario, there is no issue at 
all that I can see.  And it has the appropriate "atomic" properties you 
would like to have for that applications, which would be difficult in any 
design in which the component pieces are mixed.

But to try to introduce the idea that an object is compound by its very 
nature to the web at this date, and trying to mix the MHTML metadata with 
HTTP metadata, even if possible, does not seem feasible or desirable to 
me. My complexity alarm is going off...			 			
			- Jim Gettys



--
Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
http://www.w3.org/People/Gettys/
jg@w3.org, jg@pa.dec.com

Received on Wednesday, 14 January 1998 08:13:57 UTC