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

> >What would be just as reasonable would be to have the scenario
> >play out this way:
> >
> >    I send you an insurance claim with references to two photos of
> >    my broken car. I include the references to the photos using
> >    something like "http://my.com/brokencar..." URIs.
> >
> >Of all things that HTTP is being used for this is actually a 
> >good one :) HTTP is really good at GET!
> 
> 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.

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.

Thanks!

Henrik