Re: Multiple Content-Location headers

At 14.20 -0800 98-01-13, Jim Gettys wrote:
> I don't really want to stir up a firestorm here, but there are several
> issues (mostly procedural), I'd like to raise with your statement about
> your next draft applying to HTTP...
>
> 	1) the HTTP working group tries not to lay constraints on the
> 	MHTML group.  In particular, not without negotiation with the
> 	MHTML group.  I suspect we'd like a similar attitude from
> 	the MHTML group.  Hopefully, this discussion is that negotiation...
> 	Our specs certainly makes no statement about HTTP messages
> 	being the format that mail messages must conform to.

Yes, of course. I think there are many cases where mail and http people
should communicate better in order to avoid unnecessary differences
between the standards they produce. Especially since combined or
integrated mail and web browsers are so common, it would seem very
silly if a module for the display of HTML should be forced to use
different algorithms if the HTML arrived via HTTP than via SMTP.
>
> 	2) HTTP is NOT a MIME prototol; it is really a "MIME-like"
> 	protocol, where we've tried not to be gratuitously different.
> 	(not always successfully).  HTTP != mail.

Here is the charter of the MHTML group
--- --- --- --- --- --- start charter --- --- --- --- --- ---
MIME Encapsulation of Aggregate HTML Documents (mhtml)
------------------------------------------------------

 Current Status: Active Working Group

 Chair(s):
     Einar Stefferud <stef@nma.com>

 Applications Area Director(s):
     Keith Moore  <moore@cs.utk.edu>
     Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>

 Applications Area Advisor:
     Keith Moore  <moore@cs.utk.edu>

 Mailing Lists:
     General Discussion:mhtml@segate.sunet.se
     To Subscribe:      listserv@segate.sunet.se
         In Body:       subscribe mhtml <full name>
     Archive:           ftp://segate.sunet.se/lists/mhtml/

Description of Working Group:

World Wide Web documents are most often written using Hyper Text Markup
Language (HTML). HTML is notable in that it contains "embedded
content"; that is, HTML documents often contain pointers or links to
other objects (images, external references) which are to be presented
to the recipient. Currently, these compound structured Web documents
are transported almost exclusively via the interactive HTTP protocol.
The MHTML working group has developed three Proposed Standards (RFCs
2110, 2111 and 2112) which permit the transport of such compound
structured Web documents via Internet mail in MIME multipart/related
body parts.

The Proposed Standards are intended to support interoperability between
separate HTTP-based systems and Internet mail systems, as well as being
suitable for combined mail/HTTP browser systems.

It is beyond the scope of this working group to come up with standards
for document formats other than HTML Web documents.  However, the
Proposed Standards so far produced by the working group have been
designed to allow other such formats to use similar strategies.
--- --- --- --- --- --- end charter --- --- --- --- --- ---

There is nothing in the charter which says that MTHML is only for
mail. It talks about MIME, and MIME is certainly common to both
SMTP and HTTP, even if there may be minor differences in usage.

> 	But thanks for raising the topic, in any case, as this is how
> 	we can avoid being gratuitously different.
>
> 	3) there is NO requirement that HTTP implementations support
>  	composite objects (e.g. multipart is NOT a requirement of HTTP).
>	>       It was settled
> 	The HTTP working group long ago that for HTTP, such a
> 	requirement was both unneeded, and actually
> 	unwise (for example, the caching consequences), though transmitting
> 	multipart as the payload of an HTTP message is certainly not
> 	forbidden in HTTP (and used in a very small number of optional
> 	places).
>
> 	So the Content-Location discussion (on the HTTP mailing list, I think,
> 	should be framed in the context of HTTP requests for single objects,
> 	not the transmission of composite objects (which HTTP really
> 	doesn't know about at all).

I believe this will soon change, whether you say it in your standard
or not. Major browsers already accept or will soon accept receipt
of multipart/mime, and senders will want to use them in order to
ensure that a recipient gets a full object, with all its parts, in
one single file and not as a multiple of separately retrieved files.

In some cases, this is a security issue. Suppose I send a HTML resource
which contains a link to another message, and suppose both message
change exactly at 0:00 every day. Suppose now that the recipient
gets the first HTML resource at 23:59:59 and the second at 0:00:01
the day after. They will then not be related, which might cause
serious problems in some cases.
>
> Note that the security issues that attempting to deal with problems
> of caching composite objects (as independent, named objects)
> are far from trivial for HTTP; you'd have to worry about what
> happens if a composite object claims the name of some part
> of the namespace not under the origin server's control, for
> example.  This is a problem that Mail does not have, but that
> would make HTTP's life difficult...  I get headaches just thinking
> about the spoofing problems possible, and the problems caching
> proxy servers would have implementing such a model....

In the case of composite objects, MHTML very clearly says that
if you send a composite object, then you can only cache them
together. An object labelled Content-Location: foo in a multipart
MIME object, may not at a later time be identical to the object
you might be able to retrieve using the URL in the Content-
Location. The composite object reflects the state of the resource
at the single time it is sent, and later changes in the parts
does not change what the recipient has already received. This
is very important, because this allows MHTML to be used as
an archiving format for full, complete HTML resources in one
single archiving file, showing the status at one particular
point in time.
>
> I therefore question how much the MHTML specification should say about
> what goes over HTTP, and am reacting to the the statement in
> your paragraph above (possibly not justifiably, since I haven't seen
> your not yet released draft or previews of the language).

The MHTML specification is a specification for using MIME multipart
to construct composite objects. It is not directly connected to any
particular protocol (SMTP, HTTP, NNTP, FTP, or whatever) used to
transport the MHTML object.

------------------------------------------------------------------------
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 12:49:02 UTC