RE: [bt-spec] addresses and identification

[Peter Furniss <peter.furniss@choreology.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.

Umm - still confusing. Can you state the algorithm an Inferior must use to
select the identifying URI (for the Supeiror) to put in the ENROL from among
the multiple URIs there were in the CONTEXT, given that the URI for
addressing has (had to be) one of the URIs that was not used for
identification on the CONTEXT.

from your answer above it is not "put the URI used for the addressing in the
payload for identification"

at one point, we thought it was "use the URI that was used in the CONTEXT
for identification", but some of your other answers appeared to contradict
that

it could be "use any of the URIs, at senders choice"

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

We are talking about specification. The TC has the design choice to be
complicated. If the specification is complicated, the understanding or the
implementation are complicated too (not necessarily both). If the
specification is less complicated, implementation is easier (though could
still be baroque if one wanted )

> > 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(!),

so now we must have REDIRECT-acks ?

>         b) the URIs do not contain sufficient
> information to allow determination of past identity,

Surely explicitly disallowed by some of your previous statements -
non-creator of phone:234355?fred may not assume it is related to
phone:2366334?MrSmith/fred

 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 isn't trying to solve the world's, only its own. It hadn't out addresses
saying "this BTP entity will be accessible using these
address(es)+identifier(s)", and that information has been invalidated.

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

At abstact or model level, the statement is "BTP requires functionality Y,
and models this requirement with features P.", and then that P may be mapped
to facilities of the carrier (constraining the choice of carriers), is
always provided by BTP,  may be provided by BTP in the case that the carrier
does not, or may be provided by a shim protocol that adds the feature to the
carrier (this last is actually a redefinition of the carrier; the previous
option could be viewed as merging the shim protocol into BTP). But Y and P
have to be stated at abstract level in some way.

For some Y, we do state them as requirements on the carrier (e.g. messages
shall be delivered uncorrupted or not at all). For others, the overall
representation and binding rules would allow them to be mapped to carrier
facilities if such are available, or to be handled by BTP. So a binding to
carrier that did have the requisite redirection itself would map REDIRECT to
that, and the BTP REDIRECT message itself would not be used for addresses
with that binding.

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

So a message from a relocated entity must put all (one ?) of its obsolete
URIs on every message it sends in future, as well as the one it is using now
?   Why is this different from having a separate identification-only URI ?

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

Not exactly a "problem". On our scheme the binding-address takes you to
however detailed a carrier endpoint you want, and then, if it's needed, the
additional-information can take you further to somehting that does recognise
the identifier.  And also, while BTP only requires the identifier to be
unambiguous and everyone treats it as opaque, that doesn't mean you can't
put detail information in it, using an internal syntax of your own design
(so http://acme.com/not-a-real-url?fred/alias=joe would be fine)

(this freedom to put locally-understood stuff in the identifier URI isn't
the same in your scheme, because the URI will need to be understood by the
far-end that is trying to use it as an address)

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

yes they are addresses.  I'm still the same person, and I have the same full
name (and national insurance number) at all of them.  If the NI people sent
email, they'ed always quote the NI number in all the messages, you can be
sure.

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

BEGUN, CONTEXT and ENROL - the messages that are exchanged so parties in a
relationship know where the other one is.  As far as I can make out, the
byte-saving virtues of your approach apply only to the set of URIs on these
messages, where one of the addressing ones can be dropped if the
identification URI is also an address.  So all this is about saving 100
bytes on 3 messages per transaction ?

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

What - you'ed put a suffix on a URI from the http scheme, and say this isn't
part of the http use ?

> > 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://

Exactly.

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

For the soap-http-1 style, you could state rules about where the http url
inside it stops and the non-carrier information begins, so something trying
to use it to send to you would know. But all you've really done then is
squeeze the three fields of the current btp address structure into a URI
with an ad-hoc format, that has to be specified for the URI scheme.   What
was the point of this again ?

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

Yes, your scheme could work. It needs quite a lot of extra specification in
various places, some of it equivalent to what is already there (i.e. moved
or copied), some of it additional. But it doesn't seem to give any gain
worth the candle.

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

I'm trying to understand precisely what you are proposing.

By "defined by the carrier-binding", do you mean the "carrier-binding used
to bring the messsage that brought the URI here from the place it refers
to", or the "carrier-binding that the URI, by its format and content,
indicates should be used when the URI is used an address".

And "in any message you cannot mix and match" ? that all URIs in a message
must be for the same carrier-binding ? that the identifier URI must match
the carrier being used for the transmission ?

Peter