Re: Specifying a state machine: ASCII-based languages
On Thu, Sep 14, 2006 at 05:00:20PM +0100, Stewart Bryant [EMAIL PROTECTED] wrote a message of 56 lines which said: Isn't there a suitable text based state description language published by the CCITT that we can use Pointers are welcome but you probably mean SDL, aka Z.100 (http://www.itu.int/ITU-T/studygroups/com17/languages/Z100.pdf and http://www.sdl-forum.org/). There are already existing languages for state machines and all those I know are displayed at http://www.cosmogol.fr/related.html. rather than invent our own from scratch? There are several reasons why none of them seemed useful for the IETF, in the specific context of state machine description in the RFCs. * several are not published as a stable standard (such as Graphviz or SMC), so they cannot be normative references, * those who are published as a standard are not always available (Z.100 is an ITU standard and they do not publish everything freely, the SDL forum publishes a non-authoritative version and even tutorials are not freely available, see http://www.iec.org/acrobat.asp?filecode=125). * some are extremely complex, intended for a much more general use (such as UML and SDL). Ask yourself why no state machine in the RFC is described with these languages. And why RFC 2360 does not mention them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Specifying a state machine: ASCII-based languages
Stephane Bortzmeyer wrote: On Thu, Sep 14, 2006 at 05:00:20PM +0100, Stewart Bryant [EMAIL PROTECTED] wrote a message of 56 lines which said: Isn't there a suitable text based state description language published by the CCITT that we can use Pointers are welcome but you probably mean SDL, aka Z.100 (http://www.itu.int/ITU-T/studygroups/com17/languages/Z100.pdf and http://www.sdl-forum.org/). Yes - SDL / Z.100 was the one that I was thinking of. There are already existing languages for state machines and all those I know are displayed at http://www.cosmogol.fr/related.html. rather than invent our own from scratch? There are several reasons why none of them seemed useful for the IETF, in the specific context of state machine description in the RFCs. * several are not published as a stable standard (such as Graphviz or SMC), so they cannot be normative references, * those who are published as a standard are not always available (Z.100 is an ITU standard and they do not publish everything freely, the SDL forum publishes a non-authoritative version and even tutorials are not freely available, see http://www.iec.org/acrobat.asp?filecode=125). Perhaps we can fix this with a liaison to the ITU saying that in the interests of co-operation and a desire to use a common state machine language to ensure the interoperation and uniform interpretation of our protocols would they make Z.100 available to all who are designing and implementing IETF protocols. * some are extremely complex, intended for a much more general use (such as UML and SDL). Do we mean more complex or more complete? Ask yourself why no state machine in the RFC is described with these languages. And why RFC 2360 does not mention them. I have no idea. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Specifying a state machine: ASCII-based languages
Stewart Bryant wrote: invent our own from scratch? Stephane's draft has 22 pages, including two non-trivial examples. SDL has abstract data types and other features. For something that's better than ASCII art or some ad-hoc table formats squeezed into RFCs his format is okay. It should be fairly simple to tranform this into whatever you like better (because you have tools for it). Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Specifying a state machine: ASCII-based languages
On Wed, Jun 28, 2006 at 10:04:54AM -0400, Henning Schulzrinne [EMAIL PROTECTED] wrote a message of 48 lines which said: Having a more formal description of state machines is a natural next step from having, say, a good syntax description in ABNF. Unfortunately, unlike ABNF, none of these (except SDL) have a long- term stable reference. If we worry about PDF not being around for future RFC readers, I am a bit more worried about the authors of a SourceForge volunteer project finding other things to do. Thus, I think the first step would have to be to define a (subset) of a suitable language as an IETF-stable document, You are absolutely right and here is my first attempt: http://www.ietf.org/internet-drafts/draft-bortzmeyer-language-state-machines-00.txt See also http://www.cosmogol.fr/ if you want the HTML version. Comments, flames, criticisms, patches, suggestions and running code are highly appreciated. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Specifying a state machine: ASCII-based languages
There have been a lot of talk here recently about 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 the need to specify state machines. This is often done by a drawing (sometimes in ASCII-art or may be in Unicode-art in the future). I want to argue that it is not the only way and not even the best way and to suggest that ASCII-based languages are better. Drawings (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. Informal natural language text is not perfect either: * impossible to analyze automatically (for instance to check if they are complete). Tables are a possible solution (if the machine is finite). But most people find them too low-level. The best solution, IMHO, seems to be formal languages. There are several candidates (I'm confident that the readers of this list will suggest many others but I limited myself to languages implemented in free software, list compiled with the help of Phil Regnauld and Olivier Ricou): * Graphviz (http://www.graphviz.org/). See an example for TCP state machine at http://www.linux.com/article.pl?sid=05/11/08/2018216. Graphviz is more presentation-oriented. There is no way to separate the specification of the state machine from its presentation (colors, fonts, etc). I know no tool to analyze Graphviz files for state machine check (of course, because Graphviz is used for much more than state machines). If people want the nice diagrams of Graphviz, do note that many other tools can produce Graphviz files from specifications. Should one of these tools used in an RFC, it would be easy to generate a pretty (non-normative) picture through Graphviz. * State Machine Compiler, SMC (http://smc.sourceforge.net/). As its name suggests, its main aim is to generate executable code from the state machine description. But it can be used, it seems so, for pure specification. A nice exemple is a telephone at http://smc.sourceforge.net/TelephoneSrc.htm. (The FAQ has an excellent entry Why write state machines in text and then compile them? Why not create a GUI to draw state machines? which is quite relevant here.) * Ragel (http://www.cs.queensu.ca/home/thurston/ragel/). Quite close from SMC. * FSMLang (http://fsmlang.sourceforge.net/). Same concept again. * eXtensible Abstract State Machines, xASM (http://www.xasm.org/). I must confess that this one is less clear in my mind. * SDL (http://www.sdl-forum.org/). It is further from our aim, I mention it for completeness. Therefore, as a conclusion, I would like people to notice that specifying state machines may not always involve a picture. Unfortunately, there is no clear winner among these applications and some of them are not ideal for specification (Ragel is sold more as a replacement for lex than as a specification tool.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Specifying a state machine: ASCII-based languages
Having a more formal description of state machines is a natural next step from having, say, a good syntax description in ABNF. Unfortunately, unlike ABNF, none of these (except SDL) have a long- term stable reference. If we worry about PDF not being around for future RFC readers, I am a bit more worried about the authors of a SourceForge volunteer project finding other things to do. Thus, I think the first step would have to be to define a (subset) of a suitable language as an IETF-stable document, presumably after a few people try out various basic designs. On Jun 28, 2006, at 6:55 AM, Stephane Bortzmeyer wrote: * State Machine Compiler, SMC (http://smc.sourceforge.net/). As its name suggests, its main aim is to generate executable code from the state machine description. But it can be used, it seems so, for pure specification. A nice exemple is a telephone at http://smc.sourceforge.net/TelephoneSrc.htm. (The FAQ has an excellent entry Why write state machines in text and then compile them? Why not create a GUI to draw state machines? which is quite relevant here.) * Ragel (http://www.cs.queensu.ca/home/thurston/ragel/). Quite close from SMC. * FSMLang (http://fsmlang.sourceforge.net/). Same concept again. * eXtensible Abstract State Machines, xASM (http://www.xasm.org/). I must confess that this one is less clear in my mind. * SDL (http://www.sdl-forum.org/). It is further from our aim, I mention it for completeness. Therefore, as a conclusion, I would like people to notice that specifying state machines may not always involve a picture. Unfortunately, there is no clear winner among these applications and some of them are not ideal for specification (Ragel is sold more as a replacement for lex than as a specification tool.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
