[i061] Anonymous AcksTo

[Doug Davis <dug@us.ibm.com>]

Anish - did you want to offer up some
suggested changes?
thanks
-Doug

Doug Davis/Raleigh/IBM@IBMUS

10/27/2005 12:43 PM

To	ws-rx@lists.oasis-open.org
cc
Subject	[ws-rx] [NEW ISSUE] Anonymous AcksTo  and my AI

Per my AI[1] and after reading the changes to WS-Addressing w.r.t. the
anonymous URI[2] I think it might be good for the RM spec to add some additional
text to help readers understand exactly how the sending of Acks can greatly
impact their soap stack implementations.  In particular I think the
text needs to make it clear that:

• An anonymous AcksTo means SeqAcks need to flow back on the appropriate protocol binding-specific channel - e.g. on HTTP its the HTTP response
• However, this doesn't mean any HTTP response flow, rather just ones that are in some way related to the sequence.  For example, the HTTP request included an AckRequested or a Sequence header referring to the sequence in question.
• In cases when there is no message flowing on the HTTP response then using an anonymous AcksTo could change current transport processing logic.  In particular, a single HTTP request message with a non-anonymous wsa:ReplyTo could still cause a message (an Ack) to flow back on the HTTP response flow.

to that end....a new issue: 

Title: Anonymous AcksTo 

Descripton: Add text, similar to above, to the spec.  It should be
placed in the Sequence Ack section. 

Justification: see above 

Target: core 

Proposal: 
After the first paragraph in the SeqAck section (currently section 3.2)
add something like: 
---- 
Sending Sequence Acknowledgement Header blocks back to the AcksTo EPR could
have an impact on current SOAP implementations.  While this specification
discusses the ability to add, or piggy-back, a Sequence Acknowledgement
Header block to a message that is targetted to the AcksTo EPR, the precise
mechanism for determining when any particular message is targetted, or
not, to the AcksTo EPR is out of scope for this specification.  However,
WS-Addressing does give some guidance on EPR comparision.

Using the WS-Addressing's anonymous IRI in the AcksTo EPR may further impact
implementations. When the AcksTo EPR uses the anonymous IRI, Sequence Acknowledgements
MUST be sent on the appropriate protocol binding-specific channel.  For
example, in the HTTP case, Sequence Acknowledgements would be expected
to flow on the HTTP response flow.  It is worth noting that this may
result in new SOAP messages being generated and sent in certain situations.
 For example, if on an HTTP request flow the SOAP message contained
a wsa:ReplyTo that didn't use the anonymous IRI, then it is possible to
a new SOAP message may need to flow back on the HTTP response flow for
the sole purpose of carrying a Sequence Acknowledgement.  Because
the anonymous IRI is a general purpose IRI that can be used by many concurrent
RM Sequences, Sequence Acknowledgements that are sent to the AcksTo EPR
using these protocol binding-specific channels SHOULD only be sent when
it can be determined that the channel is related to the RM Sequence.  For
example, Sequence Acknowledgements should only be piggy-backed on HTTP
response flows where the message that was sent on the HTTP request flow
referenced the Sequence in question through the use of a Sequence or AckRequested
Header block. 

----- 
Maybe we should say that they should compare EPRs per WSA's rules?  thoughts?
Another option for the anon AcksTo is to encourage people to use ref-p's
to disamiguate anonymous EPRs - but I still like the idea of restricting
back-channel flows. 

thanks 
-Doug 

[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1049
[2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00169.html