Re: [bt-spec] addresses and identification

[Mark Little <mark_little@hp.com>]

> it could be "use any of the URIs, at senders choice"

Since all URIs reference the same entity it could be any of them. However,
we would assume it would be the first (payload) entry since the others are
intended primarily for fail-over/migration. I have two telephone numbers for
you but if you said "use the first as I'm more likely to be there" then
that's what I'd do. We simply state this rule as part of the algorithm.

> We are talking about specification. The TC has the design choice to be
> complicated. If the specification is complicated, the understanding or the
> implementation are complicated too (not necessarily both). If the
> specification is less complicated, implementation is easier (though could
> still be baroque if one wanted )

And a baroque specification would again be down to individuals. It need not
be. And please remember - it is a subjective statement to say that the
specification is (or may become) baroque: some people have said this in the
past and I would disagree with them, but it doesn't necessarily mean that
any one side is right or wrong.

> so now we must have REDIRECT-acks ?

No, that again would be only one specific design choice. If I move house,
for example, I could inform everyone I know and wait until they have
acknowledged the new address before I move. An alternative (and definitely
not the only one) would be to leave a forwarder at my old address. There are
many different migration mechanisms that could be employed going all the way
back to the Emerald system and up to SSP chains and beyond. However, we
would not mandate any specific implementation since it is best left up to
the parties involved to determine which one to use. Since we have the
capability to enhance messages in a dynamic manner (qualifiers) the type of
migration via redirect could be specified (e.g., "send me an ack") and
interpreted by the receiver. Just a thought.

> Surely explicitly disallowed by some of your previous statements -
> non-creator of phone:234355?fred may not assume it is related to
> phone:2366334?MrSmith/fred

Unless I ensure there is sufficient information to disambiguate.

> It isn't trying to solve the world's, only its own. It hadn't out
addresses
> saying "this BTP entity will be accessible using these
> address(es)+identifier(s)", and that information has been invalidated.

It has said "I have moved to here" and then seems to need to ensure that the
underlying protocol copes with this regardless of what carrier-binding we
are using.

[stuff deleted - to try to short-cut discussion!]

> So a message from a relocated entity must put all (one ?) of its obsolete
> URIs on every message it sends in future, as well as the one it is using
now
> ?   Why is this different from having a separate identification-only URI ?

Because a single URI and list of addresses does not cope with name changes.
It's as simple as that.

> Not exactly a "problem".

Not "problem" as in "difficult to do", but more as in "to figure out".

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

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

> BEGUN, CONTEXT and ENROL - the messages that are exchanged so parties in a
> relationship know where the other one is.  As far as I can make out, the
> byte-saving virtues of your approach apply only to the set of URIs on
these
> messages, where one of the addressing ones can be dropped if the
> identification URI is also an address.  So all this is about saving 100
> bytes on 3 messages per transaction ?

No it is not about saving space it is about allowing entities to migrate and
change name.

> For the soap-http-1 style, you could state rules about where the http url
> inside it stops and the non-carrier information begins, so something
trying
> to use it to send to you would know. But all you've really done then is
> squeeze the three fields of the current btp address structure into a URI
> with an ad-hoc format, that has to be specified for the URI scheme.   What
> was the point of this again ?

The point is to allow migration and name change, or haven't we been clear on
this?!

> Yes, your scheme could work. It needs quite a lot of extra specification
in
> various places, some of it equivalent to what is already there (i.e. moved
> or copied), some of it additional. But it doesn't seem to give any gain
> worth the candle.

Definitely a subjective statement that you are entitled to make. We, on the
other hand, would make a different subjective statement! And round we go
again.

> I'm trying to understand precisely what you are proposing.
>
> By "defined by the carrier-binding", do you mean the "carrier-binding used
> to bring the messsage that brought the URI here from the place it refers
> to", or the "carrier-binding that the URI, by its format and content,
> indicates should be used when the URI is used an address".

The latter.

> And "in any message you cannot mix and match" ? that all URIs in a message
> must be for the same carrier-binding ? that the identifier URI must match
> the carrier being used for the transmission ?

No, that in any message all URIs must contain id+address or id and address
are separate.

Mark.

P.S. Rather than continue to flood the mailing list with subjective
statements (from both sides) and discussions about how things could be done
(and let's face it, we both know that what we propose could be specified
precisely), let's concentrate on the subissues. As I said in the ealier
email, if we vote on these then we'll know whether it is worth persuing. As
a committee we all agreed to a democratic system and as I said several days
ago, HP will certainly agree to abide by the majority vote and I'd assume
Choreology will too, though I don't want to put words in your mouths. (Note,
our implementation of BTP does not in any way hinge on this decision so
let's not assume that we are arguing purely from an implementation point of
view.)

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