RE: [bt-spec] addresses and identification

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

Yes, as Alastair pointed out, given a btp-specific URI scheme, you can put
any information you like in it.

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

It isn't a matter of practicality and fitting to different carrier protocols
and environments, but of definition. We deem that the name shall be globally
unambiguous and within this use, unique (i.e. no other name shall be used as
the btp identifier for this object accessed in this role).  If the name were
also to carry addressing information, that would be hard to achieve. But if
the name is devoid of meaning, and is an opaque label, it isn't that
difficult.

So, in your example, I would consider the two urls both just addresses.  The
identifier could be
   http://mynewmachine.co.uk/ids/1234
which would give a 404 if you put in your browser, but that doesn't matter
because it is only being used as a name for the thing. If I'm sender, I
don't care whether your machine cracks the identifier uri (which, alone in
the world, it understands) or uses the argument from the cgi to determine
which object it should manipulate. But on the occasions when *I* have to
match the identification of *your* object, I just use that as an opaque
string, and don't have to worry about how it got here or where it might go.

(you could also use the first address form of course, but by putting it in
the identifier field, you declare that it is the one to be used as
identifier in all cases, regardless of how the messages are sent)

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

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

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 ?

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.

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.

and these are all for the same carrier.

But see next too


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

Do you mean should or could.

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
?

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.

Peter