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

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 UTC