XMLP WG Issue 338 Resolution


The XML Protocol (XMLP) WG discussed and decided to close issue 338 [1],
which you originated, with the following resolutions:

Section 6.2.3 State Machine Description, Table 6, Transition Condition, Init

If the Transition Condition is "Unconditional", then the boundary
between Init state and the Requesting state is indistinguishable.
Shouldn't the two states be one state?

You are right. This is a bug. WG unanimously decided to change the
transition condition, from 'Init' STATE to 'Requesting' STATE, to
'Transmission of request message initiated'.

And, this change is in-sync with HTTP Binding. Where, 'Init' and
'Requesting' are distinct states and 'Transmission of request message
initiated' is the transition condition.

Section 6.2.3 State Machine Description, last bullet before 6.2.4
      "A requesting SOAP node MAY enter the Fail state, and thus
      abort transmission of the outbound SOAP request, based on
      information contained in an incoming streamed SOAP

In this case, should the responding SOAP node switch from generating
a SOAP response to a SOAP fault ?  Should the requesting SOAP node also
generate a SOAP fault since it initated the transmission abortion?

Close this issue with no action. Because, spec is correct and it outlines
the following,

* Requesting SOAP node does not issue a fault, just aborts and goes to fail
* Responding SOAP node goes to fail state, and sets context:FailureReason to
* If context:FailureReason == fail:receptionFailure, then the responding
node does not have to transmit any fault

In general, responding SOAP node generates a SOAP fault if and only if the
'normal' soap rules say generate a fault. If it is a binding level fault,
then the responding SOAP node generates a binding fault. If it is HTTP
binding, Table 20 contains a list of HTTP Binding generated faults.

We trust that this resolution satisfies your concern. If not, please contact
the WG asap.

[1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x338


Asir S Vedamuthu

webMethods, Inc.
703-460-2513 or asirv@webmethods.com

Received on Wednesday, 9 October 2002 08:10:58 UTC