Resource Acquisition over Broadcast Channels (Geek Factor: 9/10)

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