RE: [DR008] - passing arbitrary content

> There are some practical issues with both of these options. Hex encoding
> effectively
> doubles the size of content. If the group consensus is to NOT
> support native
> binary
> payloads then I would suggest using base64 encoding, it's more efficient
> than hex encoding.

The XML Schema binary datatype has an encoding facet that supports either
hex or base64. Therefore, both cases are covered.

> Accessing binary data thru a URI (pass be reference semantics) requires
> binary data to be accessible
> from the Internet (in e-commerce scenarios), for example on a web (or FTP)
> server. This opens the door to
> security issues, especially access control issues. For example,
> suppose the
> binary
> data is a medical X-ray. It's very likely this data would be protected by
> access
> control (username/password or similar).

Not necessarily. I'm sure you are familiar with the Soap with Attachments
paper Henrik and others authored. The URI reference can refer to other MIME
parts in the document directly, and will probably be the way it is used
mostly.

> IMHO, this additional level of redirection makes the XP protocol more
> complicated, pass by reference access procedures need to be
> documented/defined and error handling/reporting must be addressed.

I agree, which is why I objected to doing this in a non-normative fashion.

> Also related to "arbitrary content", I believe XP needs to specify how
> complete XML documents are encapsulated in an XP PDU. Here again,
> conventional practice is to base64 encode complete XML documents for
> transport in a SOAP PDU.

Conventional practice assumes the use of DTDs, which have issues with
validating XML content from multiple vocabularies within a single document.
XML Schemas does not suffer from this limitation, so encoding an XML
document for use within an XP PDU is not required.

> Energy companies frequently exchange geographic images and other
> binary data
> types. Several people on the SOAP list have indicated their
> desire for SOAP
> to support native binary data, the ebXML folks have also identified this
> need. I believe XP would be considered, by many, to be disadvantaged if it
> didn't contain direct support for binary and XML payloads.

This depends on what your definition of direct is. In previous messages, I
used direct to mean putting binary data directly in an XP envelope, which
requires a change to XML itself. I use the term indirect to mean referencing
binary data contained outside of the XP envelope, and feel that without this
functionality, I can not support XP moving forward. So are we agreeing?

Received on Wednesday, 6 December 2000 10:02:48 UTC