W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2001

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

From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Date: Thu, 25 Jan 2001 14:09:03 -0800
Message-ID: <00ed01c0871b$6db52a30$308f3b9d@redmond.corp.microsoft.com>
To: "Mark Baker - Ottawa Consumer and Embedded Div." <Mark.A.Baker@canada.sun.com>, <xml-dist-app@w3.org>
Cc: "Frank DeRose" <frankd@tibco.com>, <rayw@netscape.com>
> >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

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

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.


Received on Thursday, 25 January 2001 17:09:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:30 UTC