Doug, how does an ack going
where it shouldn’t “hurt”? I mean other than embarrassing the implementation
that did it. ;-)
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Monday, May 22, 2006 4:34 PM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] i119: EPR comparisons overly restrictive
"Jonathan Marsh" <jmarsh@microsoft.com>
wrote on 05/22/2006 05:59:48 PM:
> I don’t have any religious objection to defining EPR comparison
> mechanisms in specific circumstances (as WS-Addressing allows), but
> in this case I fail to see why defining such a mechanism is a good
> thing. In fact it seems harmful.
>
> 1) Piggybacking is an optimization,
although an important one.
> Failure to correctly determine that two EPRs are equivalent for the
> purposes of piggybacking eliminates the possibility to benefit from
> the optimization. The nature of the optimization is in reducing
the
> number of messages sent on the wire.
I'm really lost by this one. How does
correctly knowing when a message
is going to the right place hurt?
Correctly sending an Ack to the right
place can never hurt - however, sending an
Ack to an endpoint that
doesn't know what to do with it can.
Your argument seems backwards
to me.
If you're concerned that you won't be able
to piggy-back an Ack in
cases where the wsa:Address is the same but
the ref-p's are different
and therefore lose the optimization then
that's an argument for
the text to say "SHOULD" instead
of "MUST". This allows for an
implementation that "just knows"
to make smarter decisions. But in
general I don't believe you can make that
kind of assumption.
> 2) EPR comparison is tricky:
> a) URI comparison is notoriously
difficult, unless the URI is
> simply an identifier (e.g. namespace URI) and not primarily intended
> to be dereferenced, in which case simple string comparison suffices.
> I don't believe this will suffice for [address] property values.
> The current reference to 2396 is confusing and inadequate to
> describe how URIs are to be compared. See http://www.ietf.org/rfc/rfc3987.txt
> section 5 for a more thoughtful (and applicable) explanation of why
> there isn't a single right mechanism.
> b) Comparing canonicalized
representations of reference parameters
> is also difficult. There might be a broad set of allowable
> manipulations to reference parameters that result in false
> positives, e.g. annotating a ref param with an extension attribute
> (even WS-A does that).
I dunno - sounds a bit like you may have a
religious objection to it
since you're basically saying its not
realistic to expect people to
be able to do it. Can't compare URIs,
can't compare ref-p's - can't
really compare EPRs then. Some may
wonder if this is the beginning
of a push to get people to encode their
ref-p data into the URI
since while comparing it may be tricky its
more do-able than
comparing ref-p's. Sure hope not.
> 3) Despite the choices made above, both
components of the proposed
> EPR comparison can result in false negatives. Trading off
> complexity of the comparison algorithm versus the amount of
> optimization is a choice that should be left to implementations.
And what can each side expect of the other
then?
> a) Canonicalization and full IRI
normalization are fairly
> expensive. Some implementations may prefer a simpler mechanism,
> with correspondingly higher false negative rates.
> b) Network messaging is fairly
expensive. An implementation
> wishing to expend extra computational resources to minimize the
> network traffic should be free to implement as comprehensive a
> comparison mechanism as they like.
>
> A standardized EPR comparison mechanism
writes into the standard
> optimization choices that should be left to implementers, and would
> force some implementations to become needlessly (from their
> perspective) complex, and others to dumb-down and miss opportunities
> for better optimizations. Some seem to fear incorrectly
> piggybacking messages not destined to the message recipient, which
> is again an implementation issue (a bug) which the market will
> easily sort out.
Again - sounds like a "SHOULD" to
me.
As for it being a "bug" - I
disagree. It will force everyone
to do only the bare minimum (wsa:Address
comparing) and eliminate the
possiblity of certain scenarios from being
supported (like the
clustered case) by constraining their impl
choices.
I wonder if there's a way to leverage the
wsa:Metadata section to
help here. Could there be something in
there that tells the user
of it what kind of comparison algorithm it
should use. Or, using
a variant of Sanjay's idea, place some
unique RM ID in there and
have them compare that. Wouldn't want
it to be a seqID since the
same EPR can be used for lots of sequences.
Just brainstorming...
> [ Jonathan Marsh ][
jmarsh@microsoft.com ][ http://spaces.msn.
> com/auburnmarshes ]
>