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