Re: [bt-spec] addresses and identification

[Mark Little <mark_little@hp.com>]

> I think we probably have covered this ground though.
> (in the above 3 paragraphs, i'm describing our scheme only)

Yes we have, but I would re-iterate that by compounding the identifier into
the URI and agreeing on the format of that URI such that the identity can
always be obtained from it, we don't lose anything. In our proposal, the URI
is basically a concatenation of the id and address.

> I'm not sure it will:
>
> When I send a message to you, identifying one of your objects, I'm going
to
> use the identifier that was in the original identifier (payload) position,
> even if I use one of the alternative addresses, because, to me, the
> identifier is unchanging.  Will you recognise it ?

Yes, because at some point I know what my identity is within the URI that I
publish, i.e., I know how to break apart one of our compound URIs to get at
the id component, so why shouldn't I be able to work if you just send me the
id in the first place.

> When you send a message to me, identifying one of my objects, but sending
it
> not by the primary path, you will be liable to use the particular address
as
> the identifier, which I won't recognise.

You would if you recognised that a) this is a compound URI, and b) that you
can parse it to obtain the id.

> If your object migrates, then your messages will use its new identifier,
but
> I'll still be looking only for the old one, one - I know you've changed
> address, but I still think your name is unchanged.

But I send a REDIRECT giving my old URI and the new one(s).

>
> and these are all for the same carrier.
> > *All* of the information in your identifier and address
> > separation should be
> > available in a URI, unless I have misunderstood URI formats. So we don't
> > lose anything.
>
> Do you mean should or could.

"Could" in tha we "could" support both, and "should" in that if you use
compound format X then it "should" contain all of the information.

>
> We are unpersuaded of the virtues of making the entire address construct
> into URIs.
>
> It is true that the information
> binding-name+binding-address+additional-information+identifyingspecifics
> could be merged into a URI of an appropriate scheme.  (you might need to
do
> some double-escaping to get the end of the binding-address well-defined,
but
> it will be possible).  Alastair's message went through this. But why
bother
> ?

To support renaming. However, (and here's another alternative proposal), if
REDIRECT allowed a name change as well as an address change we could
accomplish the same thing (or at least a limited version).

> You could leave the address structure the same, and just make it the
> binding-address (which is an http URL already for the soap binding) which
> corresponded to the identifier. That would get round this problem, and
avoid
> all the overload of putting the binding-identification and the
> additional-information in the  URI.  But you'ed still have the different
> pattern of use of the identifiers.

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250