[bt-spec] BTP Issue 101 : Identifiers and addresses in receivedmessages

[BTP issues maintainer <peter.furniss@choreology.com>]

This issue has been added to the BTP issue list

BTP Issue 101 : Identifiers and addresses in received messages

Submitter: Doug Bunting, Sun
Category: minor technical
History:
This issue summarises an issue discussed at the 30 January 
conference call - the discussion was under the agenda item of issue 78 : Addresses used for identification , but has been distinguished because it seemed it built on the proposed solution to 78, rather than being an alternative. It may also relate to issue 100 : Separation of delivery information from payload  . (PRF)
Description:
We discussed issues about locating actors with particular names at significant length during 30 January meeting.  The issue is basically "How does an actor receiving a message from a previously unknown source associate the provided identifier with an address (such as for a response message)?"  The three proposals were:

1. Keep things as they are, including a list of addresses in each "initial" messages. Any changes to the list of addresses are handled using the REDIRECT message, either as a response to a message or pro-actively sent by the actor in question. Least changes required but mixes additional semantics with messages such as CONTEXT, BEGIN and ENROL. This also requires all of the query messages either include an optional address list or come from previously identified actors.
2. Separate the name to address binding from existing messages, putting DIRECT (or some such) into a class with REDIRECT and recognizing them as special. Some changes to the specification required but simplifies many of the existing messages and centralizes discussion of these bindings. Initial message bundle between two actors MUST include a DIRECT message (unless option 3 below is adopted).
3. As part of transport bindings, recognize particular URI schemes as usable for both names and locations. The particular example is HTTP. Actors receiving messages from new senders would implicitly bind such names to an address comprised of the identical location and the binding on which the message was received. Second part is necessary because a location such as those in the HTTP scheme carries no information about the binding used to reach that location, it isn't enough to form a usable address. Unfortunately, application / actor layers above the transport are commonly unaware of the binding used by received messages.

Submitter's comment:
I'd say approach 3 is really orthogonal to the choice between 1 and 2.  Either way to provide an explicit name to address binding could be extended by a binding specific implicit list.

---

To comment on this issue, please follow-up to this announcement on the bt-spec@lists.oasis-open.org (replying to this message should automatically send your message to that list).

The current draft, with line numbers is available in pdf format and word format.

To add a new issue, please email to Peter Furniss peter.furniss@choreology.com. It helps if you propose a category (technical, minor technical, editorial, minor editorial).