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: i119: EPR comparisons overly restrictive


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.

 

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).

 

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.

  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.

 

 [  Jonathan Marsh  ][  jmarsh@microsoft.com  ][  http://spaces.msn.com/auburnmarshes  ]

 



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