RE: [DR008] - passing arbitrary content

The statement in [1]

"The methods described here treat the multipart MIME structure as 
essentially a part of the transfer protocol binding, i.e., on par with the 
transfer protocol headers as far as the SOAP message is concerned. "

So, how about adding the following new DR6xx in section 3.6 to address 
normative XP processing:

[DR6xx] Arbitrary content (to include binary data) outside the XP message 
shall be accomodated by the protocol binding.


At 11:27 AM 2000-12-05, Henrik Frystyk Nielsen wrote:
>It is important to point out that there are already ways for dealing
>with so-called binary data without XP having to invent anything:
>   * Data can be carried as hex encoded data within the envelope
>   * Data can be referenced using a URI from within the envelope
>Note also that from an XP perspective there is no difference between
>"true" binary data or just some data that we don't want to express as
>"active" content in the XP envelope.
>One example of how to carry "binary" data is the MIME multipart/related
>protocol binding that has been proposed for SOAP [1]. It supports all
>data types that can be carried within a MIME body.
>The mechanisms above are sufficiently flexible to support a vast set of
>scenarios. However, one might put forward the argument that neither of
>these solutions are particularly efficient. The part that I would say is
>"out-of-scope" is that we will not in this WG define new mechanisms
>(specific to XP or otherwise) for carrying "binary" data.
>I would therefore suggest the wording:
>As expressed in R700, XP will support carrying application specific data
>within the envelope and to refer to application specific data outside
>the envelope. Application specific data may be encoded as binary data.
>The WG will use existing mechanisms for handling binary data such as XSD
>support for binary data and the use of URIs for referening data. The WG
>will not define new mechanisms for handling binary data.

Received on Wednesday, 6 December 2000 13:13:59 UTC