Re: Binary attachments to XP: or unipart vs. multipart

Frank;
"The unipart
approach nests naturally inside the multipart approach: the SOAP
envelope,
for example, could become the root entity in the MIME message and serve
as
its "header" (details, of course, tbd). That is, it could point to other
entities in the MIME message."

is that different from Soap Attachments?
Thanks
Marwan

Frank DeRose wrote:
> 
> David,
> 
> Thanks for your clarifications on binary data. I might put things a bit
> differently. In particular, I think the issue of binary data is only one of
> several issues.
> 
> Some participants want a unipart approach. This approach is based on SOAP,
> it seems to be the approach mandated by the XP charter (although I haven't
> yet read the responses to reviews you cite below), and it is, in fact, the
> approach the XP WG has taken up until this point. In the unipart approach,
> the payload is a single XML document (SOAP envelope) containing a header and
> body.
> 
> Other participants want a multipart approach. This approach is similar to
> the more B2B-oriented protocols, like RosettaNet, BizTalk, ebXML, and SOAP
> with Attachments. In the multipart approach, the payload is a MIME
> multipart/related message with (possibly) multiple entities. The unipart
> approach nests naturally inside the multipart approach: the SOAP envelope,
> for example, could become the root entity in the MIME message and serve as
> its "header" (details, of course, tbd). That is, it could point to other
> entities in the MIME message. IMHO, convergence between the various
> B2B-oriented protocols could be achieved on the basis of the multipart
> approach.
> 
> The advantages of the multipart approach are:
> 
> 1.) It can accomodate binary data without requiring that it be encoded.
> 2.) It can accomodate multiple XML documents.
> 3.) It allows standard S/MIME encryption and digital signatures techniques
> to be used.
> 4.) It makes it easier to parse/process different parts of the payload
> independently of each other through standard mechanisms.
> 
> The disadvantages of the multipart approach (quoting Henrik) are:
> 
> 1.) It makes it impossible to refer to entities with reasonable URIs.
> 2.) It makes caching impossible.
> 3.) It complicates access authentication.
> 
> [Henrik said these were "a few" of the disadvantages of the multipart
> approach. I wish  he would explain his meaning more fully and also list any
> other disadvantages of which he is aware.]
> 
> I am not suggesting that the multipart approach should replace the unipart
> approach in the XP WG. I do, however, think standardization of BOTH
> approaches is desirable. The standardization of the unipart approach is what
> the XP WG is currently working on and it should continue working on this
> problem with all speed. But, the question of how to standardize the
> multipart approach must be addressed. I don't know whether such a project
> would fall within the scope of the XP WG. Perhaps, the XP WG could join
> together with other bodies that are working on the various other B2B
> protocols. At any rate, to judge from the messages on the mailing lists over
> the last week, I would think that there are going to be a lot of vendors who
> aren't satisfied until some standard for the multipart approach emerges.
> 
> Frank DeRose
> TIBCO Software Inc.
> 3165 Porter Dr
> Palo Alto, CA 94303
> 650-846-5570 (vox)
> 650-846-1267 (fax)
> frankd@tibco.com
> www.tibco.com

Received on Wednesday, 24 January 2001 16:23:49 UTC