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

["Jonathan Marsh" <jmarsh@microsoft.com>]

That sounds workable to me.  My preference, having been involved in
enough over-engineered standards work that was subsequently punished by
the industry, remains for the minimum necessary to declare victory.  A
new mechanism that optionally facilitates the use of an optional
optimization still seems like overkill to me.

And FWIW, I consider bit-for-bit (more precisely, char-for-char) as a
respectable choice for a comparison algorithm.  It will generate a fair
amount of false negatives but is dead simple to implement.

> -----Original Message-----
> From: Alastair Green [mailto:alastair.green@choreology.com]
> Sent: Tuesday, May 23, 2006 10:00 PM
> To: Jonathan Marsh
> Cc: Anish Karmarkar; ws-rx@lists.oasis-open.org
> 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
> define
> 
> 
> 	an
> 
> 
> 		EPR comparison algorithm.
> 
> 		1) WRT to false negatives: I don't think false negatives
are
> 
> 
> 	themselves
> 
> 
> 		a problem -- they result in one not being able to
utilize the
> 		optimization. I would hope that if we define a
comparison
> algorithm,
> 
> 
> 	it
> 
> 
> 		would 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
> the
> 
> 
> 	same.
> 
> 
> 		If they are not (in absence of an equivalence
algorithm), then
> one
> 		cannot make any statement about the equivalence (they
may be
> 
> 
> 	equivalent
> 
> 
> 		or 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), 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.
> 
> 
> 
> 
> 
>