OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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