Re: [GETF] okay, here's an updated draft with Henrik's option B

[moving to dist-app]

Henrik,

I have some comments on your proposed changes.

> Note that because no SOAP message is present in the request, the receiving
> SOAP node may not know whether it is talking to a SOAP node or not.

Whilst I agree, I think this applies in general to any SOAP message. For
example, the sender may be sending a pre-constructed SOAP message and may
not be a SOAP node. The receiver has no way to tell the difference.

> If a SOAP fault is generated by the responding SOAP node while it is in
> the Receiving state, the SOAP fault is made available in
> reqres:OutboundMessage and the state machine transitions to the
> Receiving+Sending state.

Doesn't this apply to the request-response MEP as well?

Shouldn't this be described in Table 12 "Responding SOAP Node State
Transitions" instead, rather than in plain text, to comply with this
section's style.

Jean-Jacques.

Henrik Frystyk Nielsen wrote:

> I took an action item to write up a bit about SOAP faults in Chris'
> proposal. You can find the edits in [1] (with change bars) In addition I
> have two proposed changes that I incorporated into [2].
>
> * We don't have to say SHOULD or MUST in the MEP description - we define
> what it is: In the absence of faults, there is no SOAP in the request,
> and SOAP in the response. Anything else, it ain't this MEP :)
>
> * We can't force a SOAP node to process a message. However, what we can
> say is that *if* a SOAP message is processed it MUST be processed
> according to the SOAP processing rules. I realize that it is slightly
> different from what GETF talked about this morning but I think we have
> to be careful about how we formulate MUST requirements.
>
> Btw, should this not happen on dist-app?
>
> Comments?
>
> Henrik Frystyk Nielsen
> mailto:henrikn@microsoft.com
>
> [1]
> http://www.w3.org/2000/xp/Group/2/5/31/soap12-part2-cbf-hfn-01.xml#bindi
> nfdesc2
> [2]
> http://www.w3.org/2000/xp/Group/2/5/31/soap12-part2-cbf-hfn-01.xml#bindf
> aulthdn2

Received on Monday, 3 June 2002 04:05:42 UTC