Formal Objection to resolution of Action Property Issue

Firstly, when the issue was discussed within the June 4^th teleconference, it was argued that the action property ‘is for message in, not for message out.’ There are several places within the ws-addressing specification, however, that conflict with this assertion:

1. The wsa:Action header is included within message instances where message direction is ‘Out’ (see core specification section 3.2).
2. An explicit association for wsam:action property is defined for WSDL 2.0 interface operation output element (see section 4.4.1).
3. A [direction token] placeholder is defined for the default WSDL 2.0 action pattern (see section 4.4.2).
4. An explicit association and default WSDL 2.0 action pattern is defined for faults, which within the context of supported message patterns, is always message direction out (see section 4.4.2).
5. An explicit association and default WSLD 1.1 action pattern is defined for outputs (see section 4.4.4). Please note the WSDL 1.1 default action pattern has no ambiguity, i.e. the value is unique within context of a port type.

Based upon language within the specification, the reader would therefore conclude that the wsa:Action property is used to dispatch all messages, not just messages with direction ‘In’. This is consistent with the definition provided by the core specification.

“[the action property] uniquely identifies the semantics implied by [the] message.”

When measured against this definition, the default WSDL 2.0 action pattern for faults does NOT generate an IRI that uniquely identifies the semantics of the message, i.e. a fault message has no meaning when considered outside the context of the targeted operation.

Secondly, when the issue was discussed within the teleconference, several members appeared to agree that a ‘fix’ was warranted. But, because the ‘fix’ would break existing implementations, the issue was closed with no action. I believe this is dangerous for two reasons:

1. Little, if any, weight should be given to existing implementations within the context of a Working Draft. It is my understanding that a call for implementations does not occur until after a document becomes a Candidate Recommendation. The intent of a Working Draft is, after all, to work out the issues before the specification is implemented.
2. By deferring to existing implementations, the group places an undue burden upon future implementations. Allow me to explain. As a work around, it was suggested that instead of using the wsa:Action property to dispatch a fault message, that the message should instead be correlated with the initial message using the wsa:RelatesTo property. This would essentially require that all future implementations manage message instances within the Binding layer, i.e. as opposed to the Application layer, where, in my opinion, this behavior belongs. A Binding should be able to identify the abstract action and retrieve relevant policy without having to inspect a specific message instance. In any case, this is a design choice that should made by the implementer, i.e. not something implicitly mandated by the specification.

In light of the arguments presented above, I respectfully request that the group reconsider their decision to close this issue with no action and instead consider making the following changes:

1. Move the wsam:Action attribute from the interface fault element to the WSDL 2.0 interface operation infault/outfault element.
2. Change the default WSDL 2.0 action pattern for faults to: [tns] [delimiter] [interface name] [delimiter] [operation name] [delimiter] [direction] [delimiter] [fault name]