Target addresses

[Alastair Green <alastair.green@choreology.com>]

From our experience in implementing the draft spec, we've come up with
the conclusion that the current notion of "target-address" in the BTP messages
is wrong (and can easily confuse).

At the moment each message contains an initial element called target-address. This contains binding, binding-address and optional-addressing-info. The purpose, as discussed at London, was to return to the target address routing or processing information which was meaningful to it, but opaque to the sender.

It was considered that an address, if a URL, might contain "post-slash" information that could be deemed to be part of this opaque, receiver-generated data.

The optional addressing information was intended, unambiguously, to hold such opaque data.

Given the assumption that either element might carry opaque data, it was decided that we might as well chuck in the whole address, even if the binding element was always strictly irrelevant, and even though the binding-address might be irrelevant.

In tussling with this in our implementation, we see the following problems:

1) The value of the binding string is either set to empty, or to the original published binding, or to some private transmutation that reflects some resolution process by the recipient of the published address/sender of the message. In all three cases it is either redundant or misleading. Empty tells us nothing (why have we bothered at all); the original string is already known to the recipient, and any kind of private variant on the original string is meaningless to the recipient.

2) The binding-address is the wrong place to put opaque target-meaningful data. The "post-slash" data is very likely being used by the recipient for other "protocols". Example. A Servlet or CGI script in a web-server is already using the action/parameters of the URL to say which code to execute/interpret, and what parameters there are. This type of suffix info may or may not (speaking generally) get through to the ultimate recipient. To use this information for our purposes seems to us to run the danger of mixing protocol layers.

So, if we just pass the optional-addressing-info then we a) reduce the confusion (we don't bill something as an address when it isn't really), and b) we ensure that the additional info is in one place only.

We'd like to propose that target-address be replaced by optional-addressing-info in all BTP messages, therefore.

Alastair

begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard