Re: [bt-spec] addresses and identification

[Mark Little <mark_little@hp.com>]

> If, in the specification, the only requirement on the name is that is
> globally unambiguous, then it is opaque to all but the "owner" - those
> endpoints that are or might become the access path for the entity so
> identified.

However, I can maintain a globally unambiguous name *and* address within the
same structure (URI). This is down to the carrier-binding to specify and
it's entirely possible that some bindings simply would not support this, but
others would.

> But, and this was the point of my example above, at the "owner",
> it is not necessary that it be opaque - it can contain structure that is
> meaningful to the owner - allowing it to contain "local" aliasing
> information. But no-one else, especially another implementation sending a
> message containing this need understand the structure, let alone the
values
> extracted from the subelements.

And our example of the compounded URI would function in exactly the same
way. The sender has a compound URI which contains addressing information for
the carrier and the receiver. For example, going back to the good old cgi
days:

http://mymachine.co.uk/cgi-bin/dboperation?lookup+homepage+1234

where the http://mymachine.co.uk is used at one level to get to the machine,
the cgi-bin/dboperation is used to locate the script/program, the lookup is
used to invoke a specific method supported by that script/program and
homepage+1234 are interpreted in some other manner.

If I move the "object" and rename it (say to "oldhomepage") then the URI
becomes:

http://mynewmachine.co.uk/cgi-bin/dboperation?lookup+oldhomepage+1234

> So, since there are no external contraints
> on the name, making a globally unambiguous one that will never need
changing
> is not that difficult.

"never need" is again a subjective statement. As I said earlier, can we
really say that is true over all time and all carrier-protocols and all
deployment environments? You would say "yes", presumably, and we'd say "no".
So, if the protocol can be extended in such a manner as to allow both
mechanisms in a way that does not break either (and may well be carrier
specific), where is the problem. As long as it remains interoperable I don't
see the issue (e.g., if you use your addressing scheme in outgoing messages
and we use ours in replies it should still work).

> if the name is also used as an address, then there is less flexibility on
> its construction - it is constrained by the need to be understood
elsewhere,
> when it it will be used as an address.

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

> Those constraints may be more or less
> flexibile, but any flexibility must be specified either as part of
> addressing scheme, or as part of the btp use of the addressing scheme.

Agreed.

> ( there is also the possibility that the name is not used as an address
but
> is unambiguous only within the scope of a particular address (or set of
> addresses). But this is the status quo ante, which I thought we agreed we
> didn't want, and which required all the disambiguating addresses. )

Mark.

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