Being overly prescriptive
seems good, in fact it is limiting in that some implementations could provide
additional value and differentiate themselves in this area, in either being
liberal or strict. I think Jonathan’s 3.a and 3.b perfectly
illustrate this. Do we really need to get so specific just to remind
implementers of the spec that EPRs can have ref params?
I’m not understanding your thoughts on the debugging
thing. Do you now see a problem where you didn’t before? Your response
directly to Gil seemed to support the idea that arbitrary headers like this
aren’t harmful in and of themselves. The scenario you describe below
sounds like a product that shouldn’t have been shipped.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Monday, May 22, 2006 4:52 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i119: EPR comparisons overly restrictive
By the
ack going to the wrong place it could cause the RMS to resend messages that
should have
been acked. That could be quite a large performance issue if we're talking
about large
messages or a large number of message. And, going back to Gil's comment
about
debugging... imagine the RMD trying to figure out why the RMS is still
resending
even though it
"thought" it acked the messages.
If
piggy-backing of Acks didn't change whether or not an RMD sent a stand-alone
Ack then I
would agree that there's no harm. But if the RMD assumes that the sending
of the ack by
any means is enough for it to never send another one (until a new message
arrives) then I
think we have a potential interop problem.
thanks,
-Doug
"Marc Goodner" <mgoodner@microsoft.com> wrote on 05/22/2006 07:35:19 PM:
> 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 ]
> >