bt-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [bt-spec] Issue 78: Addresses used for Identification
- From: Doug Bunting <dougb62@yahoo.com>
- To: BT - spec <bt-spec@lists.oasis-open.org>
- Date: Wed, 30 Jan 2002 12:46:51 -0800
Separating out the follow on issues from today's discussion and proposing
a minor change to the proposed resolution:
Resolution to 78
I propose we amend the resolution by replacing the current final parenthetical
comment of the words for the model discussion, substituting "that is, a
URN value" for "e.g. URI's using UUID".
New issue
We discussed issues about locating actors with particular names at significant
length during today's 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:
-
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.
-
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).
-
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.
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.
thanx,
doug
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC