Re: [ws-rx] [NEW ISSUE] When to piggy-back RM headers

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

Yes - anything not mentioned is not
considered part of the comparison.  So, its just the address + ref-p's.
-Doug

"Mark Little" <mark.little@jboss.com>

05/15/2006 06:32 PM

To	Doug Davis/Raleigh/IBM@IBMUS
cc	<ws-rx@lists.oasis-open.org>
Subject	Re: [ws-rx] [NEW ISSUE] When to piggy-back RM headers

Doug, I just want to clarify the lack of reference to
wsa:Metadata. It's much harder to quantify the relevance of the metadata
to the EPR comparison because it can change (become out-of-date, for example),
whilst the rest of the endpoint is still valid. So I'm not advocating adding
that to the equality definition you've got; I'd just like to make sure
its absence is for the same reasons I'm thinking.

Mark.


Doug Davis wrote:
>
> Based on some additional feedback I'd like to modify the proposal
slightly:
>
> Proposal:
>
> Add after the first paragraph in section 3:
>
> Some RM header blocks may be added (or 'piggy-backed') to messages
that happen to be targeted to the same endpoint to which those headers
are to be sent, thus saving the overhead of an additional message exchange.
 For the purpose of determining whether these soap header blocks may
be added to a message, two Endpoint References are considered to be equal
if the following are true:
> - The [address] properties of two endpoint references are equal when
compared according to Section 6 of [RFC 2396]
> - They contain the same number of reference parameters
> - For each reference parameter in one endpoint reference there exists
an equivalent reference parameter in the other.  One [reference parameter]
is equivalent to another [reference parameter] if their byte streams per
Exclusive XML canonicalization (with an empty "inclusives" list)
are equal.  Note that this may result in incorrect answers if there
are qnames in attribute or element content.
>
> (the 3rd bullet changed)
>
> Marc - when you update the issue list can you please update the proposal?
>
> thanks
> -Doug
>
>
>
>
>
> Doug Davis/Raleigh/IBM@IBMUS
>
> 05/04/2006 12:18 AM
>      
> To
>       ws-rx@lists.oasis-open.org
> cc
>      
> Subject
>       [ws-rx] [NEW ISSUE] When to piggy-back RM headers
>
>
>      
>
>
>
>
>
> Description:
> It is not clear when an implementation is allowed to piggy-back RM
headers (acks, ackReq) in a message.  I suspect that most implementations
will simply compare the wsa:Address of the EPRs - however, since ref-p's
are an integral part of EPRs they should really be included in the comparison.
>
> The latest WSA spec says:
>
> 2.3 Endpoint Reference Comparison
> This specification provides no concept of endpoint identity and therefore
does not provide any mechanism to determine equality or inequality of EPRs
and does not specify the consequences of their equality or inequality.
However, note that it is possible for other specifications to provide a
comparison function that is applicable within a limited scope.
>
> This proposal does just that - it proposes a comparison function for
use just by RM for a very specific purpose.
>
> Target: core
>
> Type: design
>
> Proposal:
>
> Add after the first paragraph in section 3:
>
> Some RM header blocks may be added (or 'piggy-backed') to messages
that happen to be targeted to the same endpoint to which those headers
are to be sent, thus saving the overhead of an additional message exchange.
 For the purpose of determining whether these soap header blocks may
be added to a message, two Endpoint References are considered to be equal
if the following are true:
> - The [address] properties of two endpoint references are equal when
compared according to Section 6 of [RFC 2396]
> - They contain the same number of reference parameters
> - For each reference parameter in one endpoint reference there exists
an equivalent reference parameter in the other.  One [reference parameter]
is equivalent to another [reference parameter] if their byte streams per
Exclusive XML cononicalization are equal.
>
> (some should recognize this from the submitted WSA spec)
>
> thanks
> -Doug