Re: Binary (and XHTML, and *ML ...) attachments to XP

Henrik,

I think I follow what you're suggesting here, but perhaps we are using
different interpretations of "MIME".  I'm talking about RFC 1521, and
using Content-Location instead of Content-ID, so that we can use HTTP
URLs, whereas you appear to be bringing RFC 2111 into the picture.

Additional comments below.

Henrik Frystyk Nielsen wrote:
> > You're preaching to the choir! 8-)  But I don't see why using MIME
> > necessarily means using a mid: schemes to identify parts.  Why not use
> > the true URLs and Content-location rather than locally-scoped names?
> 
> You have to be able to bind the two together somehow - otherwise you
> don't know that they are related. MIME doesn't have the concept of links
> other than the "Reference" header field which can only point to message
> id's - it is not a general linking capability so assuming that the links
> have to be listed in XML somehow, we can make the bindings like follows:
> 
>     XML document --> message id --> content-location URI
>     XML document --> content-location URI --> message id
>
> In the first mapping the XML contains a mid: URI and the MIME entity
> with that message id has a content-location header field. In the second,
> the content-location URI is used directly in the XML *and* in the MIME
> entity.
>
> Both have the problem of establishing trust that the MIME entity really
> *is* an entity generated by the URI of the content-location but in
> addition the latter has the problem that the receiver has to parse every
> MIME entity to see if there is a Content-Location match for that URI.
> Especially when using nested MIME messages, this search can be quite
> elaborate.
> 
> Say for example that in the car insurance example that photo B was of
> your car but that I sent a version of it that showed no marks "proving"
> that even if I hit you, your car didn't get a dent.

Sure, but this is easily reduced to the same proxy trust issue.

To use your example, if that picture had a Content-Location of
http://www.markbaker.ca/2000/01/car_accident_picture, but it was
received via a GET from www.henrikfrystyk.dk, then henrikfrystyk.dk *is*
a proxy, and I can decide whether to trust it or not (of course, I trust
you Henrik 8-).

> One can say that this is the same problem that one has with HTTP caches
> - why should I trust that a cached response really comes from the origin
> server? The difference is that I as a client *choose* to trust the cache
> - I don't have to trust an arbitrary origin server that it does the
> right thing.

MB

Received on Tuesday, 30 January 2001 15:37:16 UTC