WSRM from a WSA perspective

WSRM is of interest to both WSN and WSA.  I've been reading through the 
February edition with both hats on.  Here's what my WSA hat points out 
to me (my hats are generally more perceptive than I am).  If your 
immediate reaction is "Why are you bringing this up here?  These are 
WSRM issues," I can understand the sentiment, but as far as I can see 
the issues I'm discussing /are/ WSA issues.  They all have to do with 
referencing endpoints and directing messages, and nothing in particular 
to do with the meat of WSRM, which is acknowledging and retrying and 
distinguishing sending and delivery from transmission.

On the one hand, these are use cases we need to understand, at least as 
far as their addressing implications go.  On the other hand, if there is 
vagueness or inconsistency in the handling of addressing in some other 
spec, we're in at least as good a position to spot it and comment on it 
than someone focusing purely on the core functionality of the spec.  
Further, examining these usages closely will help us understand the 
dependence of other specs on ours and this in turn will help us 
determine whether we got the design right.  So without further ado:

Section 3.4 (Sequence Creation) says that if the party requesting a 
sequence creation offers to create an inbound sequence, "the RM 
Destination of the inbound sequence is the WS-Addressing <wsa:ReplyTo> 
/[sic]/ of the <CreateSequence>."  This seems quite strange.  Rather 
than just explicitly give a destination EPR, I have to imply it by 
directing the reply to the CreateSequence operation to that destination 
and then be ready to deal with that reply there.  As described, I cannot 
use a plain vanilla SOAP/HTTP request/reply to create a bidirectional 
reliable channel, because the [reply endpoint] in such a case, if 
defined at all, is the anonymous endpoint and will presumably be invalid 
as soon as the operation completes.  Given that all we're doing here is 
hooking up two endpoints, it seems strange not only to require WSA, but 
to require a particular pattern of request/reply.  Request/reply already 
works fine without WSA.  What doesn't work fine without WSA is 
specifying endpoints.

Section 4 (Faults) begins

"The fault definitions defined in this section reference certain 
abstract properties, such as [fault endpoint], that are defined in 
section 3 of the WS-Addressing specification /[I don't see where, but 
maybe I just missed it].  /Endpoints compliant with this specification 
MUST include required message information headers /[sic] /on all fault 
messages

Sequence creation uses a CreateSequence, CreateSequenceResponse request 
reply.  Faults for this operation are treated as defined in 
WS-Addressing /[ ... list of faults this operation may produce ... ]/ 
All other faults /[...]/ SHOULD be sent to the same [destination] as 
<SequenceAcknowledgement> messages.

WS-ReliableMessaging faults MUST include as the [action] property the 
default fault action URI defined in the version of WS-Addressing used in 
the message./ [...] [where is this value defined these days?]/"

As far as I can tell, all this really says is "CreateSequence is a bog 
standard request reply.  Sequence faults SHOULD go to the <AcksTo> 
endpoint established for their sequence.  Faults must include their 
destination as a <wsa:To> header and give a particular value for 
<wsa:Action>"

I've now looked at at least four specs that reference WSA (WSRM, 
WS-Transfer, WS-Enumeration and WSN).  There is a common thread through 
all of them: If EPRs are mentioned, the case for them is airtight.  We 
need to reference destinations for messages, and EPRs do that.  When 
MAPs are mentioned, on the other hand, it's not clear what value they're 
adding (with the possible exception of <Action>, which is built on 
current practice).  In cases like the endpoint for the <Offer> element, 
they may actually be making things harder than they need to be.

As far as I can tell, we shouldn't be too concerned with precedents set 
by MAPs being mentioned in the specs I listed above.  For example, 
changing the spelling of <ReplyTo> is a non-issue.  There's no good 
reason for mentioning <ReplyTo> directly outside WSA, there's probably 
very little real call for mentioning [reply endpoint] directly outside 
WSA, WSDL and a few specialized binding documents, and in any case both 
WSA and the specs referring to <ReplyTo> are in draft.