Mark, Peter:

Isn't it true that the "single wire" approach *requires* standardized interception, in the sense that messages for A must pass through X? (Doesn't require boxcarring, I agree).

Isn't it also true that the network optimization described as one-shot *requires* boxcarring, otherwise you do end up with 6 instead of 2? (Or a worse ratio if number of participants > 1)?

And lastly, isn't it true that implicit propagation *requires* some kind of bundling of messages (qualification is one view)?

If you combine these requirements (and this is first and foremost a requirements discussion, not a "how do we do this in the protocol" discussion) then I think you end up with one approach, that I favour (mandatory interoperable boxcarring and message forwarding). If you chip away at these requirements you may end up with something much more minimal.

The most general view that spans all three is that the BTP protocol should permit the creation of compound messages, directed to A(X) -- address of X -- where each element is a message (let us say, {1, 2, 3}) with an address, e.g. A(1).

In this case an app request + CONTEXT going to A would be, using a convention that {1,2,3 ...n} = compound message, and -- = "destined for address":

{*REQ* -- A, CONTEXT -- A}-- A

A forwarded message (for one-wire) would look like:

{ENROLL -- A} -- X

A boxcarred message (for optimization) might look like:

{ENROLL(Pa) -- A, VOTE(Pa) -- A, ENROLL(Pb) -- A, VOTE (Pb) -- A) -- A

and a natural optimization in the first and last cases might be to allow the internal addresses to be omitted if they were the same as the first receiver, e.g.

{ENROLL(Pa), VOTE(Pa), ENROLL(Pb), VOTE (Pb)) -- A

{*REQ*, CONTEXT}-- A

This last example is probably what one would reduce to if you thought only implicit context propagation was a requirement.

If you thought none of the three requirements was important then you would chuck out the whole notion of "compoundness", make checking an application requirement, and one message would travel to one endpoint, and there would be no implicit or explicit need for interception.

Just trying to sift out what we're debating here.

Alastair

PS There was a bit of a clash over "in scope, out of scope" on the one-wire example, which flows (in part) from internet security impositions (how many holes do you tolerate in the firewall? all traffic over one authenticated pipe). We have decided to take security into account to the extent that we seek to avoid roadblocks to an upward compatible secure V1.0+. I think this should colour our thinking on one-wire topologies. I also happen to believe that inter-org BTP will very often be infeasible without the one-wire approach.

PPS There is no assumption of collocation in the sense of the same address space. The receiver must be capable of forwarding, by any (unspecified means) to the ultimate address. There are some subtleties around this, but I believe the combination of a two-part address and distinct IDs for atoms and participants actually makes this quite reasonable. A BTP-aware proxy is one way of looking at this.

Mark Little wrote:

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:alas...@choreology.com title:Managing Director adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX; fn:Alastair Green end:vcard