RE: [ws-rx] [NEW ISSUE] Anonymous AcksTo and my AI

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

Sanjay,
  I did a quick scan of the spec
and I think the current spec only uses it when
talking about adding it to an existing
message.  In the text I proposed I think
the following should be changed:

> 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.

to

> For example, Sequence Acknowledgements should
only be 
> sent
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.

To your other questions:

> Is it ok for the AcksTo header to contain anonIRI
in case when the
> CreateSequence does not include an Offer?

yes, offer is orthogonal to this issue.

> What is the intended behavior in this case? 

Don't see why you think it would change anything.

> Would the RMD be required to either immediately
send back
> an Ack upon getting an incoming message or wait for the next incoming
> message for sending back an Ack for the past message(s)?

W/o an AckRequested its up to the RMD to decide.  It
could ack each
message or it could wait a bit - but its risking that
another message
will be sent later.

> What if there
> is no next message or the next message comes after a much longer time
> period (say greater than the InactivityTimeout value).

Yup - if the RMD waits, its hosed  :-)

-Doug

"Patil, Sanjay" <sanjay.patil@sap.com>

10/27/2005 01:43 PM

To	Doug Davis/Raleigh/IBM@IBMUS
cc	<ws-rx@lists.oasis-open.org>
Subject	RE: [ws-rx] [NEW ISSUE] Anonymous AcksTo  and my AI

Hi Doug,

An observation: Currently we are using the term "piggybacking"
in
multiple contexts - a> send an Ack along with a message that also
happens to be destined to the same RMS, and b> send an Ack on an HTTP
response that happens to be connected to the same RMS. We may have to
use this term a bit carefully, or with a specific context to avoid
creating confusion.

A clarificatoin question:
Is it ok for the AcksTo header to contain anonIRI in case when the
CreateSequence does not include an Offer? What is the intended behavior
in this case? Would the RMD be required to either immediately send back
an Ack upon getting an incoming message or wait for the next incoming
message for sending back an Ack for the past message(s)? What if there
is no next message or the next message comes after a much longer time
period (say greater than the InactivityTimeout value).

Thanks,
Sanjay


> -----Original Message-----
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Thursday, Oct 27, 2005 9:44 AM
> To: ws-rx@lists.oasis-open.org
> 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/act
> ion_item.php?action_item_id=1049 
> [2] 
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archi
> ves/200510/msg00169.html
>