Re: SOAP Binding & Core: Interaction between Faults and [message id] and [reply endpoint] etc.

Thank you for your comment [1].  The WG decided to drop the Editorial
Note in the next publication.

Please let us know if this resolution is acceptable.  Absent a response
within two weeks, we will presume the resolution is acceptable to you.

[1] http://www.w3.org/2002/ws/addr/lc-issues/#lc1

> Ref:  [1] WS-Addressing 1.0 Core 
> (http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/)
>         [2] WS-Addressing 1.0 SOAP Binding 
> (http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331)
> 
> The Core specification require [message id] property in a message only

> if expects a reply, as indicated by presence of [reply endpoint] or 
> [fault endpoint] properties. Accordingly  [reply endpoint] is required

> only if a reply is expected. Same goes for [fault endpoint] which is 
> also optional.
> 
> Also messages that are replies do not need to have a [message id] 
> property.
> 
> Given the above, how the faults described in section 5 of the WS-A
> SOAP Binding specification [2] could be received by the sender of 
> the message if these properties are not supplied? I understand that
> the spec says faults are "generated" (and not necessarily 
> transmitted) but, for faults like "5.5  Endpoint Unavailable" that
> also supply a <wsa:RetryAfter>, the intent is to send it so that 
> the receiver can retry the message. These are faults outside of 
> what the service defines in its WSDL.
> 
> So, it seems we are saying that WS-A SOAP binding users SHOULD be 
> prepared to receive such faults even when the underlying service 
> (WSDL) does not define any but we make it difficult for that to happen
> by not requiring the needed properties.
>
> IMO to enable this, the core spec should highly encourage the use of 
> (SHOULD) [message id] and [fault endpoint] / [reply endpoint] 
> properties?, so that the WS-A defined faults have a chance of reaching

> the sender of the message (including when it is a reply)? Ideally I 
> would make them required properties always.
> 
> Prasad Yendluri

Received on Tuesday, 19 April 2005 18:30:20 UTC