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:48 -0800
To: xml-dist-app@w3.org
Message-ID: <OF3621AB93.FDBC3120-ON88256B83.00753B5F@boulder.ibm.com>
----- Forwarded by David Fallside/Santa Teresa/IBM on 03/21/2002 01:20 PM
|         |           Christopher Ferris     |
|         |           <chris.ferris@sun.com> |
|         |           Sent by:               |
|         |           w3c-xml-protocol-wg-req|
|         |           uest@w3.org            |
|         |                                  |
|         |                                  |
|         |           03/20/2002 01:12 PM    |
|         |                                  |
  |                                                                                                                           |
  |       To:       Noah Mendelsohn/Cambridge/IBM@Lotus                                                                       |
  |       cc:       w3c-xml-protocol-wg@w3.org                                                                                |
  |       Subject:  Re: Issue 61: external payload reference/S+A                                                              |
  |                                                                                                                           |
  |                                                                                                                           |


Some comments below.



noah_mendelsohn@us.ibm.com wrote:

> 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.

Yes, we realize this. Weren't sure what to do about it.

> 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
>  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
> as distinct from all the other data on the Web. We use URI's for both,
> 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."
> 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
> 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
> 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
> 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
> 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
> attachments successfully resolve.
> ============================================

In general, I like this. I also agree that this is somewhat complementary.

> In practice, I would expect that binding specifications would meet this
> obligation by referring to architectures such as SOAP + Attachments
> 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
> out the particular case of attachments, as distinct from other data
> accompanying the message.

Agreed. We could also do a better job of describing the sub-properties
of 'transport:CurrentMessage' that a binding or feature specification
could make use of directly.

> * 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,
> we can certainly anticipate the other transports might use other
> techniques.  I think the hook I've proposed above applies in all cases.
> 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
> 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:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:48 UTC