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:04:44 -0800
Message-ID: <00ca01c0871a$d30762f0$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>
Indentation:

    ">>>" = Henrik
     ">>" = Mark
      ">" = Henrik
       "" = Mark

***

>> [XML has its own problems as an envelope]
>
>XML is really good at nesting within the same XML document but no argument
>that nesting of documents is less so. However, I would note that although
>MIME can contain nested MIME messages then it is not possible to do so in
>a way that allows the semantics to be nested as in XML and nested MIME
>multipart plainly is not simple. This is actually the reason why the SOAP
>attachment spec doesn't go any further but more about this later in this
>mail...
>
>A more fundamental problem that I have eluded to and several have asked
>what I mean by is the problem of referring to MIME multipart entities.
>Let me illustrate it with an example:
>
>    I send you an insurance claim with two photos of my broken car.
>    I include the photos in the MIME multipart message and refer
>    to them using "mid:" URIs.
>
>However, "mid:" URIs are generally only resolvable within the context of that
>MIME multipart message. That is, the insurance company cannot send me back a
>message saying photo A was good but photo B didn't show any marks unless it
>actually sends me back the two photos. But even then I have no way to see
>that those two photos actually are the same as the ones I send in the
>first place.
>
>Why? Because MIME message id's are not intended to be "resolvable" - they
>are only intended as identifiers.
>
>Now, you can say that of course I should keep track of all my message
>id's that I have generated over time so that I know what you are
>referring to - somewhat like an NNTP server but that suddenly makes it
>much more complicated to make an implementation.
>
>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?

>>> That is certainly one reason but even more importantly, caching,
>>
>> If the Content-location header were used properly on the parts, is
>> caching still a problem?  i.e. is it the mechanism that's at fault,
>> common use, or existing implementations?
>
>Well, as soon as you actually include the document in the MIME multipart
>then caching is immaterial - the whole purpose of caching is that you
>*don't* have to send the data.

Hehe, obviously. 8-)  I meant that a part could be cached with its
Content-location so that if later some other non-multipart document arrived
with a reference to that document, that it could be retrieved from cache.

>But you touch on one of the main issues - it is exactly correct that one
>can use Content-Location and this brings me to the crux of my point -
>the fundamental concept that we absolutely have to have is links -
>without it we can't refer to anything outside the XML envelope.
>
>Once we have links, they can of course refer to anything and has been
>mentioned MIME multipart bodies is one such example--you mention
>carrying SOAP data within a MIME multipart which is definitely a
>possibility. However, they can refer to http://my.com/foo and
>mailto:frystyk@my.com as well.
>
>The important thing to realize about having links is that at this point,
>using MIME multipart becomes an optimization choice that applies to
>certain scenarios but not all.
>
>This is exactly why SOAP made the decision to provide links but keep the
>door open for what these links can point to AND to keep the door open
>for providing multiple underlying protocol bindings that may support
>different types of links.

But to my knowledge, nothing in MIME prevents us from using URLs and
Content-location to solve this problem.

>> I think I'd need some examples to convince me.
>
>Thank you!

Thanks for that response.  We're getting somewhere now.

MB
--
Mark Baker, Sun Microsystems
Ottawa, Ontario, CANADA
Received on Thursday, 25 January 2001 17:05:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:58 GMT