Re: Multiple Content-Location headers

Hi Jim -- Speaking as MHTML Chair, I must observe that you sound a lot
like I sounded when I first looked at a lot of the stuff going on in
HTTP;-)...  Just ask Larry Masinter;-)...  He bore the brunt;-)...

Since then MHTML and HTTP have been cooperating at least at the Chair
& Editor levels.  I expect that more of the MHTML participants have
been aware of this inter-WG negotiation because most of it was
broadcast to the MHTML list.  Larry Masinter and Roy Fielding were the
primary negotiators on the HTTP side.  I expect that most of the
issues seemed to be minor adjustments not needing broad HTTP WG
efforts, but they were more important to MHTML at the time.

So, welcome to the club;-)...  Some of us have been waiting a long
time to get this MHTML/HTTP discussion under way;-)...  We really do
need to sort this out among us and try to find Rough Consensus across
both WGs, if not more WGs.

Now then, a detail:

How are you going to handle HTTP retrieval of archived ever-changing
weather maps (that normally change within a given URI which stands for
"the current weather") that have been archived as compound MHTML "MIME
Objects"?  If you don't retrieve each of them with all of their
archived parts, how are you ever going to reconstruct what the weather
was at any time in the past?

So, having found at least one case that is clearly going to make good
use of MHTML for archiving and transfering compound web objects, how
are we going to enable this across the whole spectrum of transports
(HTTP, RFC822, FTP, SneakerNet, CDROM, EtcNet) for such compound WEB
objects whose parts need to be bound to each other?

Best...\Stef


>From your message Tue, 13 Jan 1998 14:20:21 -0800:
}
}>  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 se
} ttled
}        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 16:38:40 UTC