- From: Prasad Yendluri <pyendluri@webmethods.com>
- Date: Tue, 05 Apr 2005 17:11:13 -0700
- To: public-ws-addressing-comments@w3.org
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 Wednesday, 6 April 2005 00:13:44 UTC