RE: [ws-rx] i119: EPR comparisons overly restrictive

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

  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  ] 
> >