- From: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>
- Date: Mon, 10 Dec 2001 17:27:47 -0500
- To: dorchard@bea.com
- Cc: "andrewl" <andrewl@microsoft.com>, "jacek" <jacek@systinet.com>, "xml-dist-app" <xml-dist-app@w3.org>
SOAP + Attachements provides just the sort of rules I am talking about [1]. Some of the pertinent text is: "The resolution process for URI references (including references used in href attributes) in the primary SOAP 1.1 message in a SOAP message package is based on the rules specified in RFC2557 for multipart MIME messages with text/html root documents. We adapt these rules from the HTML and rendering context and apply them to the SOAP 1.1 messaging context. In addition, we base the relative URI syntax and absolutization rules on RFC2396 rather than on the now obsolete RFC1808 used in RFC2557." Why shouldn't we say that transport bindings supporting a feature such as SOAP + Attachments (or DIME, or whatever) SHOULD provide resolution rules of this sort, indicating the means used to reference information carried with the message? I think this is an important part of the contract when sending messages. If I send a SOAP message to an occasionally connected device (e.g. PDA), I know that the entire envelope is accessible when processing the message. If the transport binding I use gives rules such as above, then I similarly know that the binary attachment that came with the message is accessible, and the application sending me the message also knows it will be. Other URI's are presumed to be out there somewhere, but when an application puts one in a message, it has a much lower guarantee of availability to the recipient than I would prefer. [1] http://www.w3.org/TR/SOAP-attachments#SOAPReferenceToAttachements ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
Received on Monday, 10 December 2001 17:51:39 UTC