OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [bt-spec] addresses and identification


> That is an accurate statement of our proposal. By virtue of its use
("remain
> globally unique and persistent even when the resource ceases to exist or
> becomes unavailable") it is a URN.

Glad we have that tied down.

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

> In your proposal, quoting your summary above
>
>    Multiple additional (and optional) URIs are also used to locate the
> "same" entity.
>
> is "locate" equivalent to "identify and contact" (as the primary URI does)
> or only to "contact" ?

Both.

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

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

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

Mark.

----------------------------------------------
Dr. Mark Little (mark_little@hp.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2606216
Fax   +44 191 2606250





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC