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

Re: Multiple Content-Location headers

From: Jacob Palme <jpalme@dsv.su.se>
Date: Thu, 15 Jan 1998 03:34:33 +0100
Message-Id: <v0311071bb0e322e6874e@[130.237.150.138]>
To: Jim Gettys <jg@pa.dec.com>, Stef@nma.com
Cc: 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
At 08.09 -0800 98-01-14, Jim Gettys wrote:
> 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.

Why is that an inverse to what the MHTML group is proposing? If mail gets
more integrated with the web, that is only more reason that aggregate
MIME objects have the same format whatever transport method is used
to deliver them! We are also working on a web-based e-mail system, and
the very popular HOTMAIL service has the same basis.

> 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).

The sender of a message can choose to indicate that s/he is sending the
full content as it looks like at send time (by including them in the
aggregate MIME object sent) or to indicate that the content of the body
parts are to retrieved from the web at read time (by only including
references to them in the MIME object sent).

> 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.

Yes, but a single "document" in HTML very often consists of multiple
parts. There was no equivalence between "document" and "file" until
we got the MHTML standard.
>
> 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.

To me it seems much cleaner to archive each document in a single file.
Retrieving a document from a backup storage will be much easier
if you need only retrieve one single file. The risk that parts
get mislaid is also smaller.
>
> Note since such collections can have URI's of their own, it fits
> well into the model of the Web.

Of course a composite MIME object can also have a URI of its own.
It is *not* the same as the URI of its start object, since the URI
of its start object will display today's weather map, while the
composite MIME object will display the weather map of the day
when it was generated.

> 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...

They are already mixed. We are for example using many headers with
identical names, like "Content-Base" and "Content-Location", and in that
case, of course, we should try to define their syntax and semantics
in the same way. If HTTP strongly needs a header field which is not
suitable for SMTP or the reverse, these header fields should not
be given the same name in HTTP as in objects sent by SMTP.

Note also that these objects can be sent through other protocols
than HTTP or SMTP. We have NNTP, FTP, remote file access protocols,
POP and IMAP. Many people believe that IMAP is going to become a
general format for access to archived document data bases, i.e.
not only a mail retrieval protocol. So a format for compound
documents should be independent of the protocol used to transport
these documents.

------------------------------------------------------------------------
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Received on Wednesday, 14 January 1998 19:24:10 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:10 EDT