OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hey Doug,

Could you elaborate on what you mean by "... WS-Addressing does give 
some guidance on EPR comparison?"

WS-Addressing [1] specifically says that it does not provide any 
mechanism or guidance on EPR comparison. This was because of 
ramifications of this on using EPRs as identifiers, which was very 
controversial within the WG.

Thx!

-Anish
--

[1] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/#eprcomp

Doug Davis wrote:
> 
> 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 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]