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:21:11 -0800
To: xml-dist-app@w3.org
Message-ID: <OFDED81E1D.31DE752C-ON88256B83.00754701@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 02:33 PM    |
|         |                                  |
  |                                                                                                                           |
  |       To:       Christopher Ferris <chris.ferris@sun.com>                                                                 |
  |       cc:       w3c-xml-protocol-wg@w3.org                                                                                |
  |       Subject:  Re: Issue 61: external payload reference/S+A                                                              |
  |                                                                                                                           |
  |                                                                                                                           |

Good, looks like we're converging.  I do think Henrik had a good point on
the phone:  it's one thing for the overall spec to be generic and have
hooks.  The HTTP binding needs to really interop.  It shouldn't be too
generic.  We'll have to figure out how to draw the line between making it
generic vs. guaranteeing interop.

One other thing: as I signal'd on the phone, I think my proposed section
X.X could be a "feature" as opposed to core.

BTW:  Who is going to move the discussion to distApp?  I certainly have no
problems with my comments on this thread being copied for public review.

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Christopher Ferris <chris.ferris@sun.com>
03/20/2002 04:12 PM

        To:     noah_mendelsohn@us.ibm.com
        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
> 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
> 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
> but the offered as just one option for use with other transport
> 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:29 UTC

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