I've converted most of my workplace to my RABC protocol when requesting favours / equipment. Here it is:
A PROTOCOL FOR RESOURCE ACQUISITION OVER BROADCAST CHANNELS
v0.3
ABSTRACT
This document provides a message-exchange pattern (MEP) for
requesting and attributing resources over a shared broadcast
channel (RABC), such as an electronic mailing list (see
RFC822, RFC2919).
STATUS
This section describes the status of this document at the time
of its publication.
This document is the second public Working Draft of this spec-
ification.
CONVENTIONS
The following nomenclature is defined:
Alice Requester
Bob Responder to Alice's request
Charlie Responder to Alice's request
Dave Responder to Alice's request
L Broadcast destination [email list or message board]
R Resource being requested
Note that R need not be a physical resource, it may also be a
service. Examples of common resource requests include a ride
to a place of business, a piece of networking equipment, a
driver to pick up a food order, etc.
ANTI-PATTERNS
A common anti-pattern this protocol addresses is the lack of
notification provided to non-selected responders informing
them of which offer was selected:
(1) Alice -> L Request(R)
(2) Bob -> Alice Offer(R)
(3) Charlie -> Alice Offer(R)
(4) Dave -> Alice Offer(R)
(5) Alice -> L "Thanks!"
In the above example, before MESSAGE 5, Alice may or may not
have sent the private message:
(6) Alice -> Bob "Thanks, I'm using yours"
Charlie and Dave are now left wondering if the thanks was di-
rected to them, and if not, which offer was accepted. From
their point of view, MESSAGE 5 was ambiguous.
IMPLEMENTATION OF RABC
The only change required to the above pathological scenario is
for MESSAGE 5 to include an extra identifier. Requesters using
RABC to request a resource MUST include the identifier of the
party whose offer was accepted in their broadcast thanks mes-
sage. Any thanks expressed in this message is implicitly di-
rected at ALL offering responders, even if they are not named.
Sample exchange:
(1) Alice -> L Request(R)
(2) Bob -> Alice Offer(R)
(3) Charlie -> Alice Offer(R)
(4) Dave -> Alice Offer(R)
(5) Alice -> L "Thanks BOB, received R"
ANONYMOUS THANKS
In some situations, a responder may wish to offer a resource,
but not have that fact rebroadcast in the thanks message. A
typical case for this would be if the responder is concerned
that him offering a resource he's holding, albeit temporarily
(such as a piece of equipment), might publicly imply he didn't
really need that resource in the first place.
This is solved by including a unique anonymous key in the Of-
fer message. There are no format restrictions on this key, it
can be any string the responder reasonably believes will be
unique given the size of L:
(1) Alice -> L Request(R)
(2) Bob -> Alice Offer(R, ANON_12345)
(3) Charlie -> Alice Offer(R)
(4) Dave -> Alice Offer(R)
(5) Alice -> L "Thanks ANON_12345, received R"
RETRANSMISSION
It is allowable for a requester with an outstanding request to
repeat this request after a personally-defined timeout. When
repeating an unsatisfied request, a requester MUST reply to
his original request keeping intact its subject field. This
allows members of the broadcast channel L to use message
threading features in their mail clients to easily collapse
request retransmissions into the original request's thread.
The retransmitted request thus replaces the original. Members
of L consider MESSAGE 1, MESSAGE 2 and MESSAGE 3 a single re-
quest.
(1) Alice -> L Request(R)
(2) Alice -> L RE: Request(R)
(3) Alice -> L RE: Request(R)
(4) Dave -> Alice Offer(R)
(5) Alice -> L "Thanks DAVE, received R"
VERSION HISTORY
v0.1 jpdaigle 2008-05-20
Initial revision
v0.2 jpdaigle 2008-06-05
Added STATUS section, implicit thanks to IMPLEMENTATION
v0.3 jpdaigle 2009-03-10
Added anonymous thanks
