Re: [bt-spec] addresses and identification

[Mark Little <mark_little@hp.com>]

> Is this how your proposal works:
>   in a relationhsip where there were multiple URIs on the CONTEXT, the URI
> on (in the payload of) PREPARE (for example) *must* be the one used for
> sending the PREPARE.

Not necessarily. As long as it identifies the specific transaction then it
could be something entirely different looking.

> > Complicated but not impossible. It's a standard issue in distributed
> > systems. I can pass you lots of references to how it can be
accomplished.
>
> I and my colleagues know perfectly well how to implement it.

Glad to hear that.

> Baroque
> specification, with the effort involved in specifying, and then
> understanding and building a baroque implementation is worth it if there
is
> significant benefit.

Sorry, but it need not be baroque. That would have to be a design choice you
make.

> The multiple matching was one of the main vices of the old approach, but
it
> could be done. And if it has to be done, it can be. But if you start
> redirecting, things can get next to impossible - entity starts out with
URIs
> A and B; then migrates so new URIs are C and D. Sends a "pro-active"
> REDIRECT, announcing this, but that gets lost. Then it sends a message,
> identifying itself as C. That arrives where it is still known as only A
and
> B. The message is thought to be junk (protocol error) and discarded. This
> gets even worse if the second message is another REDIRECT - it's now at E
> and F !

True, but that is assuming a) you do not ensure the migration protocol is
complete and avoids this(!), b) the URIs do not contain sufficient
information to allow determination of past identity, and c) that BTP should
be responsible for this. The latter one is probably the most important: just
as BTP should not be a protocol bridge it should not be attempting to solve
all of the worlds distributed system woes! It's a transaction protocol that
lives in a distributed environment and works with (hopefully) other services
and functionality provided by other components in that distributed system.
It is *not* THE distributed system. Being protocol agnostic does not mean
that we should be incorporating support for the lowest common denominator
(e.g., "I know that protocol X doesn't support functionality Y that we may
need Z% of the time so we must provide support for it in BTP.) If we go that
route then we will be building our own distributed system architecture
around BTP and eventually the only recourse would be to start at the bottom
up.

>
> (analogy: you get a Christmas card from "Tom and Lucy Smith", names you
have
> never heard of. This is because when you knew her, she was Miss Lucy
Jones,
> and she's got married (low-key wedding :-). If she doesn't identify
herself
> by some unchanging identifier, you're not going to be able to sort it out.
> (obviously lots of ways humans do that).

Yes, but if she'd written her maiden name on the card too I'd have known
immediately.

> Surely, this is the same in both cases (and a security matter anyway) -
it's
> completely irrelevant to the issue. We have assumed we aren't dealing with
> malicious parties.

No it is not irrelevant. What I'm saying is that if an entity has three
addresses (URIs) that it wants to publish so that it can be contacted for
transaction 1234 then it had better be able to match up the incoming URI
with the transaction. This then becomes an end-point resolution problem and
nothing to do with BTP or the binding protocol.

> At least if there is a separate unchanging identifier, one can say "this
is
> a message for the person whose National Insurance number is BG 63 59 K",
> regardless of what address or "local name" the person is using.

However, in some environments/applications I may not be able to guarantee
that I can get the same id in multiple places. Have you ever tried to get
email addresses on yahoo, AOL and freeserve, for example? It's an iterative
process to get something you can live with - you'll probably never get the
name you want on all three. But they do point to you.

> (just to check: we are both talking about having the multiples only on
what
> Doug called the "initial"  messages, aren't we?  )

Sorry, can't remember what the "initial" messages meant.

> of course the identifier must be known at the addresses given for it -
> that's why they were given with it, on the initial message (or a
subsequent
> redirect)

Correct.

> The apparent gain from your approach seems very slight, especially because
> of the lock-step needed between the URI scheme and the carrier binding.
> Given the possibility of multiple bindings (may be just versions of the
same
> protocol, may be alternatives), under either scheme, inspection of each of
> the <whatever holds the addressing information> held for a remote entity
> must distinguish which protocol it belongs to.

And it could certainly do so with a URI. I know the difference between
ftp:// and http:// for example.

> So, for any specified binding
> (whether standard or proprietary), there must a specified characteristic
of
> the <whatever> that means, when such a <whatever> is used to get the btp
> addressing, that is the binding to be used.   The existing scheme (not
> altered by our proposal) handles that with the binding name, which for
> non-standard bindings is a URN (and an unambiguous string for standard
> bindings).
>
> On your scheme, it has to be in the URI itself. It could be a new scheme
> specific to each binding - e.g.
>    btp-soap-http-1:...
> (
> or the registration of new ones could be delegated:
>    btp:soap-http-1:...
>
> but I'm not sure how well that would go down generally.

This is correct.

>
> My discussion with Jim towards the end of the meeting yesterday included
> that if you want it to be
>    http:// ...
> then that can be used only one BTP binding in all of history.

That is true if no additional information were present in the URI.

> So if we say
> that BTP URIs for soap-http-1 binding are http:, then soap-http-2 has got
to
> use something different.

Correct, which means you wouldn't do it that way, i.e., I'd expect something
like soap-http-1:// and soap-http-2://

> As was said yesterday, using pre-existing URI
> schemes also can be problematic if there are bits of identifying
information
> that are not going to used by the carrier protocol (i.e. must be ignored
in
> the addressing use).

Don't see why it's problematic. If I don't need it I'll just ignore it.

> I can see that it might seem rather tiresome to send, as an address field
> something that is in fact a globally unambiguous name for the entity in
> question, and this is also being sent as the identifier. But trying to
> overload the identifier field with all the addressing implications doesn't
> seem to work in the generality. A BTP address can't neatly be just a URI
> that is a URL for the carrier. You need the binding name and the
additional
> information  as well.

Again correct, but as I have shown above that is not an insurmountable
problem. Any information that is available in your proposed scheme can be
made available in our scheme. We are not arguing about losing information or
making it harder to understand.

Going back to our last proposal, which I don't think you've actually
addressed: what is wrong with allowing both such that if the
address-identifier URI is not of a specific format (defined by the
carrier-binding) then it must only be interpreted as an identifier and
additional addressing information must be present? And in any message you
cannot mix and match.

Mark.

-----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 206 4538, FAX : +44 191 206 4203
EMAIL  : mark@arjuna.com | mark_little@hp.com