[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [bt-spec] addresses and identification
> > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC