[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] i119: EPR comparisons overly restrictive
Jonathan, Looking over the wall from my usual habitat in TX, I've been following all of this for a while, because of related issues dealt with in TX. A quick thought follows. Apologies in advance if it duplicates or misunderstands. Perhaps you could walk right round this by defining an RX WS-A extension element, which is of a clearly comparable type, and globally unambiguous, e.g. absolute URI. "Interlocutor identity", "endpoint equivalence marker" or some such. If EPR A and EPR B (or EPR A') have such an element, both with value of "foo" then you can send ack to EPR A on a message to EPR B. You could re-use this same id for the client identification issue for MakeConnection too: reply EPR = anon/polling + interlocutor id. I think you're right, that in this particular context where false negatives are just deoptimizations of the attempted optimization, "guessing the EPR equivalence" will work, and will, by evolution, chuck out the bad guessers ( in reality, push most implementations to the conservative case of EPR comparison, e.g. bit-for-bit for [address] and [ref params], or indeed to abandon the optimization). In the client id case for GetMessage/MakeConnection I think you have the problem that false negatives are dangerous. If you misidentify a request to respond as coming from e.g. an unknown client then the two sides will freeze up. Overall, there seems to be a latent concept of "party to a conversation", which might usefully be surfaced. Alastair Jonathan Marsh wrote: I think you and I are pretty close on this. We seem to agree that it is desirable to allow a range of options from no optimization, to a simple bit-for-bit comparison (though there may even be flavors of this), through a canonicalized approach, through to what I'll call semantic equivalence. An implementation should be free to choose the level it wishes to invest in, with the understanding that the more you invest, the more optimization dividends you receive. We don't seem to agree on the value of providing a non-normative snapshot of a comparison algorithm in this spec. IMO, such an algorithm is likely to miss the sweet spot, provide an illusion of interoperability when in fact it's just documentation of an implementation detail, and consume a lot of TC time to work out details, consume a lot of reader time to, and increase the burden of ongoing maintenance of the spec. I don't have a problem addressing the specific issue raised during interop that reference parameters should be considered when determining EPR equivalence. I think the simplest way to address this issue is by adding a simple warning to implementers along the lines of: "Note that reference parameters should be considered when determining EPR equivalence." In this case the "very least" is perfectly sufficient.-----Original Message----- From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] Sent: Monday, May 22, 2006 7:25 PM To: Jonathan Marsh Cc: ws-rx@lists.oasis-open.org Subject: Re: [ws-rx] i119: EPR comparisons overly restrictive These are all very good point. But from them I don't necessarily conclude that we should not defineanEPR comparison algorithm. 1) WRT to false negatives: I don't think false negatives arethemselvesa problem -- they result in one not being able to utilize the optimization. I would hope that if we define a comparison algorithm,itwould be stated in a way that would *not* prevent anyone from defining additional mechanisms to figure out equivalence. For example, if 2 EPRs are bit for bit the same then they are thesame.If they are not (in absence of an equivalence algorithm), then one cannot make any statement about the equivalence (they may beequivalentor not, one just doesn't know). There may be additional metadata that tells me that they are (or not). For example, I may know that http://www.w3.org and http://www.w3c.org are the same. One should be able to add additional criterion (than the one that we define in WSRX, if we do at all) to figure out equivalence. 2) WRT to 3a and 3b: if we define a comparison algorithm, an implementation is not (or should not be) forced to use them. It may choose to ignore it (and only use, say, bit-for-bit comparison) at the cost of extra messages and a saving on processing. OR if it is willing to put additional resources to prevent extra messages, it may use additional criterion on top of what we define. One of the feedbacks that I got from the interop was that some implementations ignore refps when figuring out equivalence -- this is quite bad for interop. If we don't define an equivalence algorithm, at the very lease we should include a warning about EPR comparisons and pitfalls. -Anish -- Jonathan Marsh wrote:I don't have any religious objection to defining EPR comparison mechanisms in specific circumstances (as WS-Addressing allows), butinthis case I fail to see why defining such a mechanism is a goodthing.In fact it seems harmful. 1) Piggybacking is an optimization, although an important one.Failureto correctly determine that two EPRs are equivalent for the purposesofpiggybacking eliminates the possibility to benefit from the optimization. The nature of the optimization is in reducing thenumberof messages sent on the wire. 2) EPR comparison is tricky: a) URI comparison is notoriously difficult, unless the URI issimplyan identifier (e.g. namespace URI) and not primarily intended to be dereferenced, in which case simple string comparison suffices. Idon'tbelieve this will suffice for [address] property values. Thecurrentreference to 2396 is confusing and inadequate to describe how URIsareto be compared. See http://www.ietf.org/rfc/rfc3987.txt section 5for amore thoughtful (and applicable) explanation of why there isn't asingleright mechanism. b) Comparing canonicalized representations of reference parametersisalso difficult. There might be a broad set of allowablemanipulationsto reference parameters that result in false positives, e.g.annotatinga ref param with an extension attribute (even WS-A does that). 3) Despite the choices made above, both components of the proposedEPRcomparison can result in false negatives. Trading off complexity ofthecomparison algorithm versus the amount of optimization is a choicethatshould be left to implementations. a) Canonicalization and full IRI normalization are fairlyexpensive.Some implementations may prefer a simpler mechanism, with correspondingly higher false negative rates. b) Network messaging is fairly expensive. An implementationwishingto expend extra computational resources to minimize the networktrafficshould be free to implement as comprehensive a comparison mechanismasthey 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 theirperspective)complex, and others to dumb-down and miss opportunities for better optimizations. Some seem to fear incorrectly piggybacking messagesnotdestined to the message recipient, which is again an implementation issue (a bug) which the market will easily sort out. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]