RE: [bt-spec] addresses and identification

[Peter Furniss <peter.furniss@choreology.com>]

As agreed in one of the other sub-threads, the crunch question (subissue 2)
is whether the name can change over a migration. This thread has a couple of
related points on that:

<pruning otherwise>

> > On our scheme the binding-address takes you to
> > however detailed a carrier endpoint you want, and then, if it's needed,
> the
> > additional-information can take you further to somehting that does
> recognise
> > the identifier.  And also, while BTP only requires the identifier to be
> > unambiguous and everyone treats it as opaque, that doesn't mean
> you can't
> > put detail information in it, using an internal syntax of your
> own design
> > (so http://acme.com/not-a-real-url?fred/alias=joe would be fine)
>
> And in which case why have the address separate?

because of who has to understand the structure - see next

> > (this freedom to put locally-understood stuff in the identifier
> URI isn't
> > the same in your scheme, because the URI will need to be
> understood by the
> > far-end that is trying to use it as an address)
>
> Not true. Both the sender and receiver need to agree on the format of the
> URI in order to parse it, but I can put anything I want there.

this links to the crunch question, because by making different assumptions
about what a "name" can be used for, it means different things to say "can
the name change".

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. 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.  So, since there are no external contraints
on the name, making a globally unambiguous one that will never need changing
is not that difficult.

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

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

Peter