[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] [i061] Anonymous AcksTo
> -----Original Message----- > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] > Sent: Tuesday, Dec 06, 2005 11:29 AM > To: Doug Davis > Cc: ws-rx@lists.oasis-open.org > Subject: Re: [ws-rx] [i061] Anonymous AcksTo > > Doug, > > I will try to send my suggested changes (editorial) by EOB today. > > But, I think this issue is a little premature to decide on. > This issue was discussed on the WS-A WG call yesterday (as it was > brought up by bunch of folks who are on both WSRX and WS-A). > WS-A WG, at > this point is discussing how the anon/non-anon replyTo works (in the > context of async request-response) when using SOAP 1.1/WSDL 1.1 over > HTTP. I would like to wait to resolve this issue (and see > where WS-A WG > ends up on this). > I agree with Anish. We should delay this a bit. We in WS-A wg in the middle of discussing the support for anon/non-anon addresses from the perspective of SOAP/HTTP binding. There was even a discussion in the wg with regards to using the specific marker to indicate levels of support for Anonymous addresses (required/prohibited) in the context of WS-RX ;-). This may also provide a fruitful avenue to help us in this direction, but it is a bit early to say. > Comments? > > -Anish > -- > --umit > Doug Davis wrote: > > > > 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/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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]