Issues 6425 and 6436 State Tables comments

1. Each actor requires its own table
2. Each actor is presented with full set of messages defined under the protocol and the next state is indicated as well as actions performed and reference to spec
3. Where spec is silent, no entry is made so that the table reflects current state of the spec
4. In the case of eventing, the subscription seems not to be an actor, but represents state storage for all actors

consequently as an example of server-side states for eventing, the existing proposal can be corrected by dividing it into two sets of columns, one set representing the event source, and one set representing the subscription manager.
as for the entity we describe as a subscription, since it represents state storage, it can be thought of as being created when a valid subscribe request is processed and destroyed when a subscription ends.  It seems that there are two states for each of these actors.
a) subscription exists, and
b) subscription does not exist