If the primary issue is that some
implementers might incorrectly piggyback messages because they only look at
Address instead of Ref Params (I agree that is insufficient), we can get by
with a much simpler proposal. Your proposal defines a lot of things
people must do instead of warning them what they should avoid. I argue
you don’t need to tread through the fire-swamp of EPR comparison to do
that. The result, after a lot of discussion about what the majority
considers a reasonable EPR comparison algorithm, is disenfranchising a minority
of implementations which could benefit from better (smarter, faster) ways to achieve
the desired optimization.
I also think you misconstrue the structure
of my argument below. Points 1, 2, and 3 lead up to the conclusion, which
is where I believe the spec would be harmed by overly proscribing EPR
comparison. The points individually don’t prove harm. And I
think the current proposal is already over-engineered, brainstorming on ways to
make it even more complex isn’t too appealing!
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 ]
>