- From: David Fallside <fallside@us.ibm.com>
- Date: Thu, 21 Mar 2002 13:19:53 -0800
- To: xml-dist-app@w3.org
----- Forwarded by David Fallside/Santa Teresa/IBM on 03/21/2002 01:19 PM
-----
|---------+---------------------------------->
| | Christopher Ferris |
| | <chris.ferris@sun.com> |
| | Sent by: |
| | w3c-xml-protocol-wg-req|
| | uest@w3.org |
| | |
| | |
| | 03/18/2002 07:08 AM |
| | |
|---------+---------------------------------->
>---------------------------------------------------------------------------------------------------------------------------|
| |
| To: w3c-xml-protocol-wg@w3.org |
| cc: |
| Subject: Re: Issue 61: external payload reference/S+A |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------|
All,
Stuart, Marc, Jean-Jacques and I have been working on a
proposal for Jean-Jacques' option B approach for resolution
of issue #61[1]:
"b) Introduce today an abstract attachment 'binding feature', but
defer 'implementation' of this feature to other specifications/notes,
such as, for example SOAP+Attachment or DIME."
We would therefor like to ask that the TBTF to review and consider
this proposal (attached) as an option to put before the WG in
resolution to issue #61.
Cheers,
Stuart, Marc, Jean-Jacques & Chris
[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x61
Jean-Jacques Moreau wrote:
> Issue 61[1] concerns the inability for SOAP to carry and reference
> payloads outsite the envelope and to carry non-XML formatted information.
>
>
>
> During the October the 17th, 2001 teleconference[2], it was suggested to
> add to the specification a non-normative, 'for-instance', reference to
> SOAP+Attachment. This was deemed insufficient by some parties. During
> the November the 7th, 2001 teleconference[3], it was suggested to write
> a new charter for the next revision of the XMLP WG that includes an
> 'Attachments' section. The text[4] for this new section was received on
> January the 31st, 2002.
>
>
>
> Although this text was received positively (see e.g. [5]), it has not
> been officially approved, and so it is still unclear whether the next
> revision for SOAP will provide a mechanism, or mechanisms, to carry
> payload outside the envelope and/or non-XML information.
>
>
>
> The following options are available:
>
> a) Adopt the proposed charter amendment and wait for the next version
> of SOAP to fully support attachments.
>
>
>
> b) Introduce today an abstract attachment 'binding feature', but defer
> 'implementation' of this feature to other specifications/notes, such as,
> for example SOAP+Attachment or DIME.
>
>
>
> c) Introduce both an abstract attachment feature and its concrete
> specification.
>
>
>
>
>
> Give our schedule, option c) is probably ouf of scope.
>
>
>
> Jean-Jacques.
>
>
>
> [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x61
> [2] http://www.w3.org/2000/xp/Group/1/10/17-minutes.html
> [3] http://www.w3.org/2000/xp/Group/1/11/07-pminutes.html
> [4]
> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Jan/0118.html
> [5]
> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Feb/0007.html
>
>
>
What follows is a first cut at what you would have to do to add an
attachments hook to the HTTP binding. This was written in a style
of editorial changes, so you will need Part 2 alongside as you
review it.
I make the assumption throughout that different attachment
mechanisms are distinguished by different media-types.
I think our current definition of the property
"transport:CurrentMessage" in Pt2 Section 6 Message Exchange
Patterns [2] alreay covers the case of attachements with the phrase
".....any other information structures that are transferred along
with the envelope due to the action of the message exchange." We
may want to state it less obliquely, but I would argue that it is
set up to think of attachments as part of the messsage.
Given this, there is absolutely nothing that then need to be done
in the MEP description (or any future MEP description) to
specifically handle attachments. Attachments needs to be handled in
the binding specifications themselves, which takes us to the HTTP
binding specification. This gives four places to touch:
At the Requesting SOAP Node
---------------------------
Formulation of a request message [3]
Detection by requester that request format
is unsupported by responder. [4]
Reception of a response message [5]
At the Responding SOAP Node
---------------------------
Reception of a request message [6]
Formulation of a response message [7]
So dealing with each of these in turn...
Stuart
--
With reference to SOAP 1.2 Part 2 "Editors' copy $Date: 2002/02/27 11:12:07
$ @@ @@ 2001" [1]
The following is written in a style of editorial changes so you
will need Part 2 alongside as you review.
Formulation of the request message. [3]
-----------------------------------
Replace the text describing "Content-type:" header with:
<replacement>
If there are no additional information structures present in
"transport:CurrentMessage" then the value of this header is
"application/soap+xml".
Otherwise, the value of this header is set according to the
specification of an attachment mechanism supported by the local
binding instance, eg. SOAP-with-Attachments [non-normative-ref] or
DIME [non-normative-ref]. If the local binding instance does not
support an attachment mechanism, a local failure arises and the
message cannot be sent.
</replacement>
Add a line to the table with for an HTTP "Accept:" header with the
following description:
<description>
A comma separated list in accordance with RFC 2616 which specifies
which media types are acceptable as a response to the requesting
node. This SHOULD include "application/soap+xml" and the media-
types associated with any attachment options supported by the local
binding instance.
</description>
Replace the text describing the HTTP entity body with:
<replacement>
If there are no additional information structures present in the
"transport:CurrentMessage" then provide an XML 1.0 serialisation of
the SOAP message envelope XML Infoset carried in the
"transport:CurrentMessage" property of the message exchange
context.
Otherwise, serialise the SOAP message envelope XML infoset and
additional information structures in accordance with the
specification of an attachment mechanism supported by the local
binding instance, eg. SOAP-with-Attachments [non-normative- ref] or
DIME [non-normative-ref].
</replacement>
Detection by requester that request format
is unsupported by responder. [4]
-----------------------------------------
This is already handled in 7.4.1.1.2 by the use of the 415 Status
code. The description could call out that a possible cause of this
status codes is that the responding SOAP Node does not support the
attachment packaging mechanism selected by the requesting SOAP
Node.
Reception of a response message [5]
-----------------------------------
Replace "Description" in receiving state table of 7.4.1.1.3 [5]
with:
<replacement>
Receive HTTP response entity body, which is assumed to be either a
SOAP envelope serialized according the XML 1.0 + Namespaces
specification or a serialisation of a SOAP message envelope and
accompanying information structures conforming to an attachment
mechanism supported by the requesting SOAP Node, eg. SOAP-with-
Attachments [non-normative-ref] or DIME [non-normative-ref] (as
indicated in the HTTP "Accept:" header of the corresponding HTTP
request).
</replacement>
Replace "Actions on Leaving the State" in receiving state table of
7.4.1.1.3 [5] with:
<replacement>
On transitions to Success, instantiate or replace the property
"transport:CurrentMessage" with an XML Infoset representation of
the serialized SOAP message envelope and any information structures
that accompanied the message.
</replacement>
Reception of a request message [6]
-----------------------------------
In the two transitions in the receiving state table in section
7.4.1.2.1 include "unsupported Content-Type" and
"attachmentFailure", eg bad MIME wrapping to the list of
malformities. Also, in the second bullet of the upper transition
(to Processing) include mention of any accompanying information
structures.
The status code table which follows makes provision of generating a
415 status in the case that the inbound content-type (and hence
attachment mechanism) is not supported.
Formulation of a response message [7]
-------------------------------------
Basically clone the words from the formulation of the request
message. Take care to consider the case that the available
attachment mechanisms at the responding node do not match any
requested by the requesting node. May want to define a fault for
this purpose (but the responding node has processed the message and
thinks it has been successful!) or may want to just 500 internal
server error (no fault), or do the check during inbound processing
and inform the SOAP node (via property) that it will not be
possible to sent attachments with any response (ie only bare
"application/soap+xml") supported.
Remaining work
--------------
It would probably also be worthwhile to say something explicit
about attachements in the introduction to the binding (section 7).
It might also be worthwhile to say something about the use of
content-negotiation ("Accept:" header) to signal what the
requesting node is capable of accepting in responses and the use of
415 status codes to indicate that the responding node cannot handle
the inbound content-type.
Another thing that I have left unsaid is the magic by which cid: or
ids get assigned to attachments. My own view is that from a
conceptual POV we can regard them as part of the abstract
information structure that gets serialised and we don't have to be
to explicit/constraing in the way we specify them.
[1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html
[2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#soapmep
[3]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#http-reqbindreqstate
[4]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#http-reqbindwaitstate
[5]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#http-reqbindrecstate
[6]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#http-respbindreceive
[7]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#http-respbindrespond
Received on Thursday, 21 March 2002 16:21:34 UTC