Re: Multiple Content-Location headers

>  From: Jacob Palme <jpalme@dsv.su.se>
>  Date: Tue, 13 Jan 1998 16:46:11 +0100
>  To: Scott Lawrence <lawrence@agranat.com>
>  Cc: IETF working group on HTML in e-mail <mhtml@SEGATE.SUNET.SE>,
>          http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>  Subject: Re: Multiple Content-Location headers
>  
>  At 08.52 -0500 98-01-13, Scott Lawrence wrote:
>  > I don't believe that this should
>  > be changed at this late date, so I'd be carefull about assuming that
>  > changes proposed by MHTML will apply to HTTP usage.
>  
>  The next MHTML draft will say that MHTML applies to the formatting
>  of MIME composite objects for sending through e-mail, netnews or
>  HTTP. I think it is obvious that the format of MIME composite
>  objects should be the same, independent of how they are sent.
>  

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.

	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. 

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

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

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

			Your paranoid HTTP/1.1 editor who'd like
			to get to draft standard Real Soon Now...
				- Jim Gettys
 
--
Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
http://www.w3.org/People/Gettys/
jg@w3.org, jg@pa.dec.com

Received on Tuesday, 13 January 1998 14:23:01 UTC