Re: Multiple Content-Location headers

Thanks Jacob and Jim for digging into this issue.

At a meta level, the basic problem is that putting HTML into Mail
objects leads inevitibly to composing composite objects which then
causes us to rrun up against all the little shortcuts that developers
(of both standards and products) and that makes our separate WGs rub
up against each other in abrasive ways, but that is the nature of
rubbing each other smooth so our users can interwork with our tools.

More directly, after all the work on how to do MHTML for MAIL, we also
discovered interesting uses for composite objects that no one had
thought of, like creating archive objects that record the state of an
every changing composite object (e.g., a weathermap) at a point in
time, and it is very easy to see the value of such use.

And, we can esily see that one might want to ship that archive object
via HTTP, or EMAIL, or even FTP, or SneakerNet, and always get the
same result.

So, back at the meta level, we have discovered that we areally do have
to very seriousl consider our sister protocols and arrange for them to
interwork.

Cheers...\Stef



>From your message Tue, 13 Jan 1998 01:04:24 +0100:
}
}At 08.59 -0800 98-01-12, Jim Gettys wrote:
}> Could you enlighten us as to why you would want to specify multiple names
}> for the same object?
}
}Because in real life, there are often different URLs referring to the
}same file. And if a message contains several HTML documents, one of
}them may use on of the names, the other may use the other name.
}If we do not allow multiple Content-Location headers in the heading
}of an object with more than one URL, one would either have to:
}
}- Include the differently labelled object twice in the composite
}  message, which might increase transfer and download time.
}
}or
}
}- Rewrite the HTML, which we have decide to try to avoid in order
}  not to break digital seals.
}
}> It would help us understand if this is applicable to HTTP as well.
}
}The next version of the MHTML standard will specify that it is
}applicable to composite MIME objects when such objects are sent
}through SMTP, NNTP or HTTP. There are obvious reasons why the
}same format for composite objects should as much as possible be
}used in all three standards. The next version of the URL standard
}(draft-fielding-uri-syntax-01.txt) has omitted most of the text
}about composite MIME objects in order to avoid unintended conflict
}with MHTML.
}
}Since the next MHTML standard will apply to composite MIME objects,
}also when these are sent via HTTP, it is of course of importance
}that you in the HTTP group review it, too. Do not download the
}latest IETF draft version of the MHTML standard now, however,
}because that version was before the Washington IETF meeting.
}I will notify your mailing list when a new MHTML Internet draft
}is ready.
}
}------------------------------------------------------------------------
}Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
}for more info see URL: http://www.dsv.su.se/~jpalme

Received on Tuesday, 13 January 1998 07:06:29 UTC