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

Proposal for dealing with issue 187

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Mon, 25 Mar 2002 15:27:25 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D06DEE2B9@red-msg-07.redmond.corp.microsoft.com>
To: <xml-dist-app@w3.org>
Cc: <noah_mendelsohn@us.ibm.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>

On behalf of the TBTF [0] I took an action item to propose a resolution
for issue 187 [1] titled "Handling badly formed SOAP Messages" based on
recent discussion [2]. As usual, if I have left things out or
misrepresented them then please fill in!

The high-level description of the proposal is as follows: In general
there are a lot of things that can go wrong due to communication
failures of all kinds. Such failures have to be described by binding
specifications as well as anticipated by features like message exchange
patterns that may be affected by such failures.

The particularities of communication failures depend on the details of
the mechanism used for exchanging a particular SOAP message. Therefore
the burden falls on the binding specification author to identify the
possible error cases. Furthermore, as communication failures often have
an impact on features such as message exchange patterns, routing,
security, etc. feature specifications should anticipate communication
failures identified by binding specifications.

The proposed resolution involves two parts:

1) Verify that the state machines describing the message exchange
pattern feature defined in SOAP 1.2 part 2 [3] (as an adjunct)
anticipate potential failure at all relevant states. The TBTF did this
and found that this is indeed the case (it is possible to transition to
an error state from all relevant states that might be affected).

2) Add a paragraph in part 1, section "SOAP Protocol Binding Framework"
adding the following text (in >>...<<) to the paragraph in section [6]:

* * * * *

...The specification of each such feature MUST include the following:

* The information (state) required at each node to implement the
feature.

* The processing required at each node in order to fulfill the
obligations of the feature >>including any handling of communication
failures that might occur in the underlying protocol (see also section
7.3 Underlying Protocol Bindings)<<.

* The information to be transmitted from node to node, and in the case
of MEPs, any requirements to generate additional messages (such as
responses to requests in a request/response MEP) and rules for the
delivery or other disposition of SOAP faults generated during the
operation of the MEP.

* * * * *

Comments?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[0] http://www.w3.org/2000/xp/Group/tbtf
[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x187
[2]
http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/thread.html#74
[3]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.xml#bindformdesc
[4]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#transpbindfram
ew
[5] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#IDAVQWZ
[6] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#bindfw
Received on Monday, 25 March 2002 18:28:01 GMT

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