RE: Multiple Addresses in an EPR

Hi Conor:

My quick take on this -

I like things in a spec to be crystal-clear, semantically speaking.
This is why, for instance, I really liked the idea of making the
"anonymous" URI have the specific meaning "the transport back-channel"
instead of leaving it as "whatever you want".  The <address> property is
already unclear enough in terms of how it is supposed to be used (should
I just hand that URI down to my HTTP binding, or do I need to do some
kind of directory lookup first, etc), IMHO adding the ability to have
multiple <address>es without crisply defining HOW those addresses are to
be used would just be confusing matters further.

Consider this - if we *could* put in multiple addresses, you would still
(ideally) need some form of specific markup to indicate just how you
were using them.  For instance you might find an <aol:failoverSet/>
marker in the metadata bucket of the EPR which tells the other guy that
the multiple addresses are in fact an ordered set of addresses which may
be used interchangeably in the case of transport-level failures.  It's
true you could do this via out-of-band agreement, but in general I
prefer things to be as clear as possible within the message itself.

So I agree with Dave Orchard here, if I've followed the conversation
correctly.  Why wouldn't you just define your own <aol:failoverAddress>
element and put N of them in parallel with the <wsa:Address>?  As I see
it, you wouldn't lose any interoperability because a) the people who
understand your particular spec for doing failover will understand that
element and how to use it, b) the folks who don't will simply and safely
use the EPR the old way, and c) if you had done it with multiple
<wsa:Address>es, you would still need some kind of markup or out-of-band
agreement to ensure that information would be used correctly.

Seems like a slam-dunk use case for EPR extensibility to me.

--Glen

Received on Tuesday, 18 October 2005 12:46:03 UTC