- From: Dick Brooks <dick@8760.com>
- Date: Tue, 5 Dec 2000 16:57:43 -0600
- To: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>, "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "Kevin Mitchell" <kevin.mitchell@xmls.com>
- Cc: <xml-dist-app@w3.org>
Henrik, > * Data can be carried as hex encoded data within the envelope > * Data can be referenced using a URI from within the envelope 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. 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). 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. 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. 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. Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions > -----Original Message----- > From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On > Behalf Of Henrik Frystyk Nielsen > Sent: Tuesday, December 05, 2000 10:28 AM > To: Jean-Jacques Moreau; Kevin Mitchell > Cc: xml-dist-app@w3.org > Subject: RE: [DR008] - passing arbitrary content > > > 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. > > Henrik > > [1] > http://www.hpl.hp.com/personal/John_Barton/HTTP-A/SOAPAttachments1 6OCT00.htm
Received on Tuesday, 5 December 2000 18:01:48 UTC