]> AFNIC

Immeuble International78181Saint-Quentin-en-YvelinesFrance +33 1 39 30 83 46bortzmeyer+ietf@nic.frhttp://www.afnic.fr/

Several RFCs contain a state machine to describe a protocol. There is no standard way of describing such a machine, the most common way being an ASCII-art diagram. This document specifies an other solution: a domain-specific language for finite state machines. It allows state machine descriptions to be automatically checked and may be translated into other formats. Its purpose is to provide a stable reference for RFCs which use this mini-language.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

One can find finite state machines, for instance, in RFC 793 or RFC 4340 . The Guide for Internet Standards Writers , in 2.12 "Notational conventions" and 3.3 "State machines description", lists several ways to describe them but does not recommend one. Unlike grammars, which are typically specified with ABNF, state machines have no standard description language. RFCs typically use figures, list of transitions or tables. Figures (wether in ASCII-art, in Unicode-art, in SVG, in GIF or whatever) are: impossible to analyze automatically (for instance to check if they are deterministic), not readable if the state machine is large. Another issue, and one which created a lot of discussions, is the "need" to allow something more than US-ASCII (and some people require even more than raw text) in the RFCs. A common "use case" is this need to specify state machines through drawings. That it is not the only way and not even the best way and the choice here is to use an ASCII-based languages, thus requiring no change in the format of the RFC. Informal natural language text is not perfect either, because it impossible to analyze automatically (for instance to check if they are complete). Tables are also a possible solution (if the machine is finite). They are fine for automatic processing but very bad for presentation to humans, specially if they are large. Most people find them too low-level. To conclude, let us note that RFC 4006 uses a list of tuples, each tuple being a transition. Although the (informal) syntax it uses is not parsable by a program, the idea behind it is close from the Cosmogol language. Cosmogol does not intend to be a protocol specification language: it focus on the structural description of the state machine. Many dynamic aspects of the protocol, such as timing, are therefore out of scope for this specification.

TODO: because of the state of this document, some choices are not final. Every time you see the word ALTERNATIVE in uppercase, it means several possible choices are listed. The terminology of state machines is not perfectly standard. We use here the words: state, message, the condition of a transition, action, performed after the transition. TODO: timers. David MENTRE <mentre@tcl.ite.mee.com> suggests to make timers explicit by separating them from normal messages, with the timeout value as a parameter. He quotes RFC 3261, p. 128. The introduction explains why Cosmogol focus on the structure of the state machine, not a complete specification of the protocol. The Cosmogol language contains declarations, assignments and transitions. A declaration announces that a name will be used for either a message, a state or an action. An assignment binds a value to a variable. A transition is described by the name of the message, the names of the current and next state and an optional action. They are the heart of the Cosmogol language: in Cosmogol, a state machine is a list of transitions. A processor is a program that processes Cosmogol files. It can be validating or not. Any processor MUST check the syntax of the file. A validating processor MUST perform the checks described in . In addition to the checks, a processor MAY perform other tasks such as translating to another format, for instance Graphviz. TODO: some way to modularize state machines? For instance, X509 checking is described by several SM.

Here is the grammar of Cosmogol, using ABNF. The use of definitions of appendix B of the RFC ("core") is assumed.

&grammar;

TODO: Julian Reschke suggests to have also an alternative XML syntax, with the same terminology and model.

A validating processor MUST perform all these checks. Every message, state and action MUST be declared. The possible values for the right side of a declaration are: MESSAGE STATE ACTION The order between statements (transitions, declarations and assignments) has no meaning. For instance, the declaration of a message can takes place after its use in a transition. All names are case-sensitive. ALTERNATIVE: make them case-insensitive, which is possible since everything is in US-ASCII. TODO: should we document naming *conventions*, such as "States in uppercase, messages in capitalized"? Another good convention would be for Timers (see RFC 3261.) Assignments are only possible to pre-defined variables. No assignment is mandatory. The variables are: Title (used for some displays) Initial (to indicate the initial state; if this variable is assigned, every state MUST be reachable - may be indirectly - from the initial state) Final (to indicate the final state; if this variable is assigned, this final state MUST be reachable - may be indirectly - from every state) ALTERNATIVE: allow non pre-defined variables ? Or force them to be prefixed by "x-" ? Or allow a "simpler than RFC" way to add more pre-defined variables ? An IANA registry ? Examples of variables which may be useful soon: revision number, date, author and other typical meta-data. When there are several current states indicated, they must be interpreted as a set. For every member of the set, the message yield to the next state. Same thing when there are several messages. This allows some grouping of similar transitions. So, the following state machine:

Waiting, End: timeout, user-cancel, atomic-war -> Start;

is to be interpreted as completely equivalent to:

Waiting: timeout -> Start; End: timeout -> Start; Waiting: user-cancel -> Start; End: user-cancel -> Start; Waiting: atomic-war -> Start; End: atomic-war -> Start;

The state machine MUST be deterministic, that is for every couple (current state, message), there must be only one output (next state and optional action). Besides the "Initial" variable mentioned above, a processor may provide a mean to the user to declare (may be on the command line) a state as the start of the machine and the processor may check that every other state is reachable from this state, as if it were declared as "Initial". Same thing for the "Final" state. A processor may provide a flag to require that the state machine is complete, that is every transition must be explicitely listed.

The character set of the language is US-ASCII only, for conformance with , section 2.1. This reflects the fact that RFC must be written in english (TODO: something which does not seem to be documented anywhere). ALTERNATIVE: Julian Reschke would prefer UTF-8 partly because the IETF may lift the current restrictions at some point of time.

None. TODO: Julian Reschke suggests registering a MIME type

Implementors of state machines are warned to pay attention to the default case, the one for which there is no explicitely listed transition. ALTERNATIVE: force every transition to be declared. This is believed to be too demanding for large SM.

&norm-references; &info-references; AT&T Research Rapp

rapp@acm.org

Queen's University

thurston@cs.queensu.cahttp://www.cs.queensu.ca/home/thurston/

ringwinner@sourceforge.net

nospam-abuse@bloodgate.com

The TCP state machine, from RFC 793 .

&tcpSM;

The EPP state machine, from RFC 3730 .

&eppSM;

The DCCP state machine, from RFC 4340 .

&dccpSM;

The first implementation of the Cosmogol language can be found at . It is a processor which is able to check state machines specified in Cosmogol and to translate them into Graphviz.

All of them are interesting back-ends for a Cosmogol processor: Graphviz is a widely-used language to describe graphs. It has been used for state machines such as TCP. But it is more presentation-oriented, you cannot restrict it to just the description. Consequently, there are currently no tools to check, for instance the determinism. The Perl module Graph::Easy shares most of the aims of Graphviz. It is also oriented towards presentation. SMC , Ragel and FSMlang are more oriented towards code-generation.

TODO

The syntax of a transition is different: the current-state is now the first item, and not the message. There was a clear consensus among the reviewers on this change. Several messages are now allowed in a transition, to indicate a set of messages. Same thing for the current state. Several bug fixes in the grammar.

Significant contributions have been made by Pierre Beyssac, Emmanuel Chantreau, Frank Ellermann, Kim Minh Kaplan, Thomas Quinot, Bertrand Petit, Phil Regnauld, Mohsen Souissi and Olivier Ricou.