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

Re: MHTML/HTTP 1.1 Conflicts

From: Jacob Palme <jpalme@dsv.su.se>
Date: Fri, 23 Jan 1998 21:12:53 +0100
Message-Id: <v03110703b0eea7ca2c26@[]>
To: Jim Gettys <jg@pa.dec.com>, Nick Shelness <shelness@lotus.com>
Cc: IETF working group on HTML in e-mail <mhtml@segate.sunet.se>, http-wg@cuckoo.hpl.hp.com, Nick_Shelness/SSW/Lotus@lotus.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5271
At 08.37 -0800 98-01-23, Jim Gettys wrote:
> Content-Location in HTTP is used when resources have multiple
> representations (i.e. you can get the same document back in multiple
> or datatypes, depending on Accept headers, for example); it isn't clear
> that the definitions for Content-Location should match in the two uses.
> (e.g. you do a GET on an object, and the Content-Location gives you the
> hint about where to find the version that you actually got, possibly for
> editing purposes). We can either accept the differing definitions, or you
> can change the name in MHTML to confuse the innocent....

Do I understand you rightly, that Content-Location for this purpose can
only occur on the outermost header of a HTTP message (or possibly
it could occur on a subobject of Content-Type: message/http?).

The MHTML usage of Content-Location only occurs inside Content-Type:
Multipart/related. Thus, there is in reality no conflict. We could
even say that Content-Location can have multiple values inside
Multipart/related but that only single values are allowed in HTTP headers!
> 1.4 MIME Line Length Considerations
> HTTP, being a binary 8-bit clean transport, does not have the same line
> length limitations that are forced on E-mail systems for gateway operations
> (which is where the line length limitation for mail comes from), that force
> you into URL wrapping (ugh, shudder; my condolences to you....).
> I don't think that it is wise (or even possible) to force this complexity on
> HTTP implementations at this late date (and I think it would have been
> a hard sell, even 4-5 years ago). I do think that it would be wise to
> have a note or editorial cross reference to the MIME spec, so that HTTP
> implementations that expect to support and share code between HTTP and MIME
> will be aware of the issue.  My opinion is that a sentence or three should
> be drafted and added to the HTTP spec to point this out to people.
> Suggested words to make this cross reference gratefully accepted...

In the MHTML group, we believe that more and more the same objects will be
transported by different protocols. For example, you get a resource through
HTTP from your intranet, and post it via e-mail to someone outside the
intranet who could not otherwise get it because of the firewall.

In these cases, it would be an advantage if the resource need not be
modified to different format in e-mail than in http. Such format changes
might invalidate digital seals and signatures. Thus, we think it would
be nice to recommend (even if not to require) that also in http the following
rules are followed:

(1) Header lines are kept shorter than 76 characters
(2) Header lines can be split into multiple lines
(3) In the special case of long URLs, such can be split into
    multiple lines, and the receiving software should concatenate
    the parts (removing entirely all whitespace) before using the
(4) Line breaks should be CRLF, not bare CR or bare LF

At 09.44 -0800 98-01-23, Jim Gettys wrote:
> Removing Content-Base does require referencing 2068, if only to say that
> it isn't in the draft standard.  It may be that we should also call
> out a reference to the MHTML spec that it uses it in interpreting content.

I think it would be very nice if the HTTP spec referenced the MHTML
spec saying something like this:

   When aggregates of linked objects (for example HTML plus in-line images)
   are transported, they should be formatted using the MHTML standard.

Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Received on Friday, 23 January 1998 12:47:53 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC