W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

REPOSTED: Re: Issue 61: external payload reference/S+A

From: David Fallside <fallside@us.ibm.com>
Date: Thu, 21 Mar 2002 13:20:22 -0800
To: xml-dist-app@w3.org
Message-ID: <OF8032251F.7FBCFB05-ON88256B83.00753307@boulder.ibm.com>
---- Forwarded by David Fallside/Santa Teresa/IBM on 03/21/2002 01:20 PM
-----
|---------+---------------------------------->
|         |           Noah                   |
|         |           Mendelsohn/Cambridge/IB|
|         |           M@Lotus                |
|         |           Sent by:               |
|         |           w3c-xml-protocol-wg-req|
|         |           uest@w3.org            |
|         |                                  |
|         |                                  |
|         |           03/20/2002 11:52 AM    |
|         |                                  |
|---------+---------------------------------->
  >---------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                           |
  |       To:       Christopher Ferris <chris.ferris@sun.com>                                                                 |
  |       cc:       w3c-xml-protocol-wg@w3.org                                                                                |
  |       Subject:  Re: Issue 61: external payload reference/S+A                                                              |
  |                                                                                                                           |
  |                                                                                                                           |
  >---------------------------------------------------------------------------------------------------------------------------|



I agree that we would do well to include in SOAP 1.2 the generic hooks
necessary to enable a variety of attachment mechanisms.  There are a
number of aspects of your proposal that I like, but I think it omits one
essential feature: it describes the means for encoding attachments, but
not the means for encoding references to attachments, and the need for
bindings to preserve and resolve such references following receipt of a
message.

In fact, I have on a number of occasions proposed a generic hook that I
believe to be quite complementary to your proposal.  For example, see [1].
 Quoting from that note, which was sent last December:
"I've proposed that the core SOAP architecture anticipate SOAP +
Attachements, DIME, etc. by including a statement that transport binding
specifications SHOULD indicate which URLs (generally which schemes, but
not necesarily) are used to reference data that is carried with a message,
as distinct from all the other data on the Web. We use URI's for both, but
I think it's useful to have a strong notion of "this data is a reference
within the message, though not necessarily within the SOAP envelope." Note
that these rules would apply to URI's anywhere in the message, not just
where SOAP can find them. If the application finds a URI pointing to an
attachement, we should specify the general characteristics of a
dereference of that URI, I think."
This would be realized in roughly the following manner (this is a bit of a
rough job, but I think the general idea is correct):
=============================================
Section X.X: Attachments and References to Attachments
SOAP provides a means by which information can be carried with a message
without including that information in the envelope Infoset.  These
additional parts of the message are known as "attachments".  Thus, when
attachments are used, a SOAP message consists of the envelope Infoset plus
zero or more attachments.
The presence or absence of attachments has no effect on the SOAP
processing model as described in part one chapter 2.
SOAP allows for the particular representation of attachments to be defined
as a feature.  Each such feature MUST specify the nature of attachments
supported (e.g. binary, text, etc.), and the means used to reference
attachments when processing the message.  Such references SHOULD be in the
form of URI's. Bindings that implement such features MUST provide for the
transmission of attachments along with the message, and receiving nodes
implementing such bindings MUST ensure that properly encoded references to
attachments successfully resolve.
============================================
In practice, I would expect that binding specifications would meet this
obligation by referring to architectures such as SOAP + Attachments and/or
DIME, each of which provides the on the wire representation as well as
conventions for URIs that reference attachments traveling with the
message.
A few other comments on your proposal:
* I agree that our current formulation of transport:currentMessage allows
for attachments, but I also agree that we could do a better job of calling
out the particular case of attachments, as distinct from other data
accompanying the message.
* At one point you suggest that all encapsulation schemes should be
identified by a MIME type.  That's probably reasonable for encapsulation
schemes that are to be supported in conjunction with the HTTP binding, but
we can certainly anticipate the other transports might use other
techniques.  I think the hook I've proposed above applies in all cases.  I
suggest that the use of MIME types be normative only in the case of HTTP,
but the offered as just one option for use with other transport bindings.
Thanks very much.  I share your optimism that we can relatively rapidly
agree on a formulation that will enable a variety of attachment mechanisms
with SOAP 1.2.


[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0146.html

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------
Received on Thursday, 21 March 2002 16:21:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT