OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


It seems to me that a simple comparison to the ref-ps ought to suffice.
After all, it got to the right place due to the address(assuming that it
was correct in the first place), and the ref-ps ought to be unchanged
from what the epr minter issued.  I think that even cannonicalization is
probably unnecessary.
-bob

> -----Original Message-----
> From: Marc Goodner [mailto:mgoodner@microsoft.com]
> Sent: Tuesday, May 23, 2006 4:54 AM
> To: Jonathan Marsh; Doug Davis; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i119: EPR comparisons overly restrictive
> 
> Exactly. +1
> 
> -----Original Message-----
> From: "Jonathan Marsh" <jmarsh@microsoft.com>
> To: "Doug Davis" <dug@us.ibm.com>; "ws-rx@lists.oasis-open.org" <ws-
> rx@lists.oasis-open.org>
> Sent: 5/22/06 6:04 PM
> Subject: RE: [ws-rx] i119: EPR comparisons overly restrictive
> 
> 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  ]
> >


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]