[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] i119: EPR comparisons overly restrictive
+1 Bob Freund-Hitachi wrote: > 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]