Re: Multiple Content-Location headers

I want to strongly endorse Jacob's positions on why HTTP and SMTP
transport of MIME should not require different MIME headers for the
same purposes, and add the point that not all users are going to
always have full IP access to the whole Internet so they can at all
times just reach out and grab any web page that is wished.

This is going to be especially true for archived information which by
definition is a recording of what existed at the time of the archiving
action, and MUST NOT be subject to version changes whether such
changes be intentional or accidental.

I also want to add that WEB technology is analogous to Libraries,
where the User Goes to the Materials, while Mail is orthogonal where
the Materials go from a sender to a receiver by means of transport by
a third party.  If the EMail SENDER will not let go of the sent
object, the EMail Transfer Agent Promises to not DELIVER it to the

I note that both Postal Systems and Libraries have existed for many
centuries, and that neither has yet replaced the other.  Further, I
note that it has been a very important aspect of both libraries and
postal systems that most objects in libraries may easily be
transferred via postal services, and the objects sent through postal
systems can also most often be retrieved from libraries.

Would that Internet Mail and Internet WEB services could work together
so well.  I do not look forward to the day when EMail (the ultimate
Push Technology) is replaced by the need to always go OUT to the
library to fetch my mail.  Using the web for mail reminds me of the
concept of agreeing on which rock in a field, under which to leave
messages for each other.  I call it RockMail.  Primitive at best...

So, back to our objectives.  They is simple: To agree on MIME headers
and their definitions between WEB, and MAIL, and any other related
transport technologies so that we may go forward with the knowledge
that when we create MIME objects, the composer need not know by what
transport they will be moved.  This of course includes the notion of
not having to rewrite or restructure objects because they are about to
be transported via a different transport than the one in which they

I also wish to note that this kind of separation to achieve
indepenence between protocol layers is the great value of the IP/TCP.
Almost all protocols above IP do not need to know what underlying
media will be used to move the bits.  And. the more the merrier!


>From your message Thu, 15 Jan 1998 03:34:33 +0100:
}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
}> 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
}> 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 a lot 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 <> (Stockholm University and KTH)
}for more info see URL:

Received on Wednesday, 14 January 1998 21:52:12 UTC