RFC -9831: Boss Communication Protocol
Masochism Working
Group H.P. Monkey Socks
Request for Abuse -9831
Category: Insanity Track
BCP: Boss Communication Protocol
Status of this Memo
This document specifies a Workplace Insanity track protocol for those trapped in a workplace and requests small grains of hope that the world really isn’t like this. Distribution of this memo is unlimited and encouraged. Perhaps others feel the same way.
Copyright Notice
Copyright Hot-Pink Monkey Socks (2007). All Rights Reserved. May Contain Nuts. Surgeon General’s Warning. Do Not Ingest. Choking Hazard. For Ages 5-8. Why Me? Not To Be Used As A Lifesaving Device. See Your Doctor If Pain Persists.
Abstract
The Boss Communication Protocol (BCP) is an “industry standard” (i.e. we didn’t have a choice in the matter) protocol for transmission, garblation, mangulation and dissemination of vague concepts, ideas and action statements. You can’t get more abstract than that!
1. Introduction
1.1 Overview of BCP
The Boss Communication Protocol (BCP) is an “industry standard” (i.e. we didn’t have a choice in the matter) protocol for transmission, garblation, mangulation and dissemination of vague concepts, ideas and action statements. You can’t get more abstract than that!
(Of course this is a cut and paste. We’re busy research type people. Do you expect us to type it all out again?)
1.2 Terminology
In this document, the key words:
“MUST”, “REQUIRED” and “SHALL” mean that we have a choice of three words to use when saying “It would be nice if…”
“MUST NOT” (actually two words) and “SHALL NOT” (two words again) mean things you shouldn’t do, but probably will because you think that will make life easier.
“RECOMMENDED”, “MAY” and “OPTIONAL” mean things that you might want to put in, and that most implementors will either ignore totally, or expect will be there in other implementations. You will not win.
1.3 Definitions
This specification uses a number of terms to refer to the roles played by participants, onlookers and guilty passers-by. These are merely here to confuse and muddy the waters and should not be taken to mean anything. Except when they do.
Boss: The ultimate controller entity of a session. No matter what you think.
Data: Something purportedly passed within a Session.
Element: A quantum of interchange. Note that due to the vagaries of the Protocol environment the size of a quantum is indeterminate, but is likely to be larger than you expect.
Employee: Subordinate entity in a session. Exists only so that there can be a Session and not just a Boss “going blind”.
Entity: One of two or more entities (q.v.) that participate in a Session.
Session: A vague term to describe interchange of elements in the vain hope that something will be achieved or information will be transmitted. Sessions usually consist of a Boss and two or more Employees. Note that if the Session consists of two or more Bosses then Session is doomed.
1.5 Overview of BCP Operation (oops, 1.4 got lost)
This section explains the basic protocol non-functionality and mis-operation. Bosses and Employees are identified by Offices and Contracts respectively.
When beginning a Session a Handshake is Initiated. Or perhaps not. It depends.
1.5.1 Session Elements
There are three element types:
- Query (Sent by either side)
- Data (Sent by either side, but reception by Boss is not guaranteed)
- No-op – No Operation (Sent only by Boss)
- (oops I said three, didn’t I?)(N)ACK – (or not)Acknowledgement
of a Query, Data or No-op element. These contain no data.
1.5.2 Session Initiation
In most cases a Session is initiated by Boss.
Sessions may be initiated by Employee but Session may be lost without warning, or never fully established in this case.
Initial Handshake when initiated by Boss is optional and may consist of a series of Query and/or Data elements, intermixed or interspersed as required/desired. Transmission may begin partway through a Data stream. Employee is required to interpolate any missed data.
Alternatively Boss Initiated Handshake may consist of many No-op elements. Be aware the end of a No-op element may contain data relating to the first Query or Data element.
The initial elements are then either ACKnowledged or NACK…erm…Not ACKnowledged.
ACK from Employee is optional, and assumed even if NACK is sent.
ACK from Boss is optional, but cannot be assumed even if received.
NACK may be recieved from Boss but may be overriden by further ACK, NACK, Data, No-op or Query elements. Possibly.
1.5.2 Expansion of Element Descriptions Now That You Have Some Context
- Query is a query for either Action (external process) or Data (Information)
- Data contains information. If sent by Employee it must be related to the Query packet. If sent by Boss then Employee must search previous Sessions to relate it to earlier Query or Data packets.
- No-op does contain data, but data may be unrelated to the Session. The protocol requires that all data sent by No-op be retained indefinitely. Note that data sent in No-ops may be duplicated across Sessions, or within a single session. Contradictory data is also a possibility.
- ACK is an acknowledgement of a previous element, including an ACK or a NACK
- NACK is a rejection of a previous element. We’re not sure why this is here as it’s pretty much useless in this protocol.
Also note that data contained within any element type (Query, Data, No-op , ACK, NACK – yes, I know we said that ACK and NACK don’t contain data. But they might.) may invalidate any previous data from previous sessions, or even within the current session.
1.5.3 Session Termination
Session is always terminated by Boss. There is no specific element to do this, but often a Query or string of No-op elements may indicate termination. Or not.
1.5.4 Session Suspension
Any Session may be suspended. Again there is no specific element (or sequence of elements) to do this and it may occur without warning. Session may be resumed (again without warning). There are no elements to indicate this. Employee must determine from context.
Note that while a Session is Suspended another may be Initiated. The original may, or may not be, terminated when this happens. The Employee is required to remember the state of all ‘half open’ Sessions, Just in Case.
2. Implementation notes
2.1 Good Luck.
4 Caveats
This will all be different tomorrow.
APPENDICES
X Bibliography
[1] Possibly Adams, S., “Dilbert Principle”
