Changes to the combinations of wsaw:Anonymous / ReplyTo / FaultTo

I had an action to propose changes to the table. Below you'll find all of my proposed changes (I couldn't remember if the action was limited to particular changes :-) ).
 
CHANGE 1
 
Rule 3 reads:
  "None" URI is a special address whose semantics are defined in WS-Addressing Core <http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#predefaddr> . 
 
I suggest we change this to read:
  "None" URI is a special address whose semantics are defined in WS-Addressing Core <http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#predefaddr> . The "None" URI is acceptable as an address no matter what value of wsaw:Anonymous is specified.
 
 
CHANGE 2
 
I suggest we add a Rule 5 (the Tony rule), which reads:
  Until all of the WS-Addressing headers have been parsed and accepted, the implementation MAY choose to return a fault on the transport back-channel, even when wsaw:Anonymous=Prohibited. 
 
The rationale for this rule is, put simply: the implementation is not required to honour any of the WS-Addressing semantics until all of the WS-Addressing headers are accepted as valid. Note that once we have accepted the WS-Addressing headers, we are obliged to honour them, including FaultTo.
 
 
CHANGE 3
 
I suggest we add a Rule 6 (the Jonathan rule), which reads:
  An implementation MAY choose to defer checking an address against wsaw:Anonymous until required to use the address. For example, if the FaultTo address conflicts with wsaw:Anonymous, but the message is processed normally and the response can be sent to the ReplyTo address, then the implementation is not required to generate a fault for the invalid FaultTo address.
 
The rationale for this rule is that we'd like to be able to process a message and respond normally if we can, even if the FaultTo is faulty. Note that this could cause a minor nuisance: if we have a non-anon FaultTo, and wsaw:Anonymous=required, and the message causes a fault to be generated, then we can't send a fault (neither the fault in response to the message, nor the faulty FaultTo fault) - can we?
 
 
I could go through and suggest new language for all the cells, but I'd like to see agreement on the principles above first - if we accept one but not another, the language will change, so let's tackle these first.
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com
co-chair UDDI TC at OASIS
co-chair WS-Desc WG at W3C