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

Re: MHTML/HTTP 1.1 Conflicts

From: Jim Gettys <jg@pa.dec.com>
Date: Fri, 23 Jan 1998 08:37:43 -0800
Message-Id: <9801231637.AA10941@pachyderm.pa.dec.com>
To: 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/5268
1. Content-Base

Note that Content-Base is being removed from the HTTP/1.1 specification,
per the minutes of our last editorial meeting.  I think that closes
out any conflict between the specifications for Content-Base.

1.1 Content-Location

Content-Location in HTTP is used when resources have multiple 
representations (i.e. you can get the same document back in multiple languages 
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....

Note that Roy is going to try to draft language for the HTTP spec to
clarify the distinction between HTTP message headers and MIME content
headers.  As far as HTTP is (mostly) concerned, multipart mime
is just more content.

So I'm not sure I have a strong feeling on which of the
three approaches is best.  Might be best to see Roy's words first
(won't happen before sometime next week.

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

				- Jim
Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
jg@w3.org, jg@pa.dec.com
Received on Friday, 23 January 1998 08:41:37 UTC

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