RE: [bt-spec] addresses and identification

[Peter Furniss <peter.furniss@choreology.com>]

>
> > This pattern seems to contradict :
> >
> > PRF: > Questions:
> >      > are your "optional URIs for addressing" used for identification
in
> > any
> >      > circumstances ?  (i.e. are they specified as being URNs for the
> > (same)
> >      > identified thing as payload-id identifies, as well as URLs)
> >
> > ML:  No, they are used purely for addressing.
>
> Definitely my mistake there for mis-communicating.

glad that's clear now. It makes rather a difference

(added later)  In fact, it may undermine some of the email discussion just
before the meeting.

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.


> > We deliberately wanted to make the identifiers single, regardless of how
> you
> > get there. Otherwise the testing to see if is the same thing becomes
> > complicated - for specification, for the matching, and for the
> carrying of
> > the identifiers in CONTEXTs etc.
>
> 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. Baroque
specification, with the effort involved in specifying, and then
understanding and building a baroque implementation is worth it if there is
significant benefit.

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 !

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


> However, before we go down that other route (!) let's first consider the
> subtext of what you say: that BTP should be responsible for ensuring all
> endpoints for the same "entity" do actually refer to the same thing.
> (Apologies if that's wrong.) We do that with an identifier and an address.
>
> But the identifier doesn't guarantee us that the "thing" at each end that
> understands the id isn't actually lying in the first place. You could pick
> up Jim's phone and pretend to be him, for example. If I didn't know Jim I
> would probably not be able to tell without asking some specific questions
> (c.f. what banks do to verify you are who you say you are).
>
> What we propose doesn't solve this, but neither does it make it
> any harder.

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.

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.

> If I pack multiple URIs into a payload which are meant to point
> to the same
> thing but just via different routes/protocols (for example) then
> I'd better
> make sure they are valid. It's just the same as saying that if I pack a
> single identifier into the payload and multiple addresses I'd better make
> sure that a) the identifier is known about at each address, and b) the
> "thing" at that address isn't lying.

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

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)

> So, I don't see what we lose by going this route (or more specifically the
> alternative proposal we made yesterday, whereby we allow both).

The alternative proposal is considerably less desirable given your corrected
answer as to whether the additional URIs are used for identification forcing
the multiple matching stuff.

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

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. So if we say
that BTP URIs for soap-http-1 binding are http:, then soap-http-2 has got to
use something different.  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).


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.

Peter