RE: [ws-rx] i061 proposal / directions

> All of this still begs the question of how someone implementing an > RMS or an RMD "knows" that the use of the anonymous URI in the > AcksTo EPR might be problematic? The only thing we say about the > AcksTo EPR in the current spec is (lines 262-264 of wsrm-1.1-spec-cd-02) is:

> Implementations MUST NOT use an endpoint reference in the AcksTo > element that would prevent the sending of Sequence Acknowledgements > back to the RM Source. For example, using the WS-Addressing "none" > IRI would make it impossible for the RM Destination to ever send > Sequence Acknowledgements.

> The proposal listed here (http://docs.oasis-open.org/ws- > rx/issues/ReliableMessagingIssues.xml#i061) does not mention the > possibility that there may not be a SOAP backchannel for the > acknowledgements to flow back on. I'm wondering how we expect a > developer to know precisely when and where the use of the anonymous > URI in the AcksTo EPR might be problematic when our spec says > nothing about the subject?

Didn't you answer your own question? You said that anonymous acksTo
might only be an issue when there isn't a soap envelope flowing
back on the http response flow. So, in those cases the developer
should not use anonymous for AcksTo.

I'm confused about which "developer" you mean. I am specifically thinking about the developer of the RMS and the RMD. How does she or he know when the use of anon AcksTo is problematic and what to do about it? There are obviously cases where it depends upon the "intentions" of the application. How should the RMS go about figuring out what/how the application intends to do its messaging?

I would be comfortable in saying that the RMS should never use the anon AcksTo unless it can ascertain that the application will be operating synchronously. How it does this (static configuration, the AS tells it somehow?) should remain unspecified. We should also explicitly state that the RMD should return the CreateSequenceRefused in response to a CreateSequence that contains an anon AcksTo unless it could ascertain that the application will be operating synchronously (method again unspecified (one can almost hear the pitter-patter of policy mice in the walls)).

I don't think our spec says "nothing" about the subject - it says that
people MUST NOT use an EPR for AcksTo that makes it impossible to
send back Acks. There are many reasons there could be for this so
I think its ok to leave it a bit open-ended - and I think no-backchannel
with the anon URI would be covered by the section of the spec you
quoted.

Hmmm . . . I think its a pretty far reach between the obviousness of "none" and the juxtaposition of MEPs, SOAP versions, and HTTP binding implementations that make up this issue. I agree that we can't specify every possible EPR and situation that might cause problems, but it seems likely that many implementations will encounter this situation (perhaps I should say "it seems enormously likely that all but an insignificant handful of implementations will encounter this yawning chasm in our specification"?)

Basically, we can provide guidance that covers these cases but I doubt
we can enumerate all of them. The text I proposed for i061 [1] actually
goes one step further and makes it clear that the use of RM may
result in some behavior that people have not seen before - again
providing guidance but not necessarily enumerating all of the possibilities.

ws-rx message