The Operations

These are the "messages" that one inter-vat connection handler
(shown as large grey rounded rectanges in The Four
Tables) sends to another. The terminology is all from the receiver's
point of view, trying to make it clear how the receiver is supposed to
react. Unfortunately, we also need to understand why the sender would
be sending these messages, but we can't have our terminology both ways.

If you think of these like instructions, it will be clear why we can
more clearly define the semantics by taking the receiver's point of view.
Contrast defining the semantics of instructions by defining what the machine
(the receiver) must do in response vs defining the instructions by stating
when some idealized compiler (the sender) must emit which. The latter
would be a nightmare. Also, as with instructions, the sending side properly
has wiggle room that the receiver does not in deciding how to use the
protocol while staying within the semantics.

An index or position parameter in italics below indicates a place that
is assumed or required to be unoccupied before this operation is received,
in which case this operation should cause it to become occupied. An index
or position parameter not in italics is assumed or required to be occupied
unless stated otherwise in the text.

The Descriptors

The descriptors serialized as the encoding of various other objects that
are not to be passed by copy (or by construction). Once again, the names
are purely from the point of view the the unserializing side.

Helper Messages

These are messages that are sent inter-vat as part of the protocol. With
the exception of whenMoreResolved and whenBroken, these messages are conveyed
by the above mechanisms just as are any user-defined messages.