Hi, I agree equations should be written in ASCII pseudocode so it is easier to convert it to code. Pretty pictures, provided for the mathematicians, can be done as non-normative additions to the spec. Diagrams can be done as non-normative additions to the spec, which may help people think through various aspects of the design, but the spec should contain a normative ascii representation of the logic, and/or pseudocode, so people can actually implement the spec. If it is too difficult for the authors to convert from the complex diagram to an ascii text or ascii art representation of the logic, then maybe this is not a good choice for a spec. Even though I have been inconvenienced by having to develop ascii art, and spell out difficlut logic in text, I am not convinced we actually **need** normative pictures or equations. To quote from draft-ash-alt-formats-02.txt, in many, many, previous discussions on the IETF meiling lists trying to justify the need for additional normative formats, "quite thoughtful, extended, and detailed discussion on the IETF discussion list resulted in no change." Apparently, a large number of readers of and contributors to the IETF discussion list are also unconvinced such a change is needed. Experience with other SDOs' publication processes does not make me want to adopt them for the IETF - just the opposite. Having been a MIB Doctor for IEEE 802.1, I needed to deal with the fact I could not extract portions of the normative PDF files to include in my comments. The 802.1 WG produced ASCII versions of the MIB specifications so we IETFers could access them more easily, and the existing MIB processing tools could work with the specs more easily, but often the non-normative ascii version was not kept up-to-date with the PDF version by the authors. This made it difficult to do IETF-style reviews on a timely basis, to automate the syntax validation of the specification, or to use the normative PDF as input to tools that generated code from the MIB specification. The PDF definitely got in the way of providing industry reviews, generating valid specifications, and implementing the specs. But this last call is about a specific document proposing a specific experiment. I think a proposed experiment that "fixes diagram issue" and "fixes equations issue" really would need to prove there is a need for normative diagrams and equations to produce an IETF technology specification. That is, it would need to prove it is not possible to specify a particular technology using pseudocode, ascii text, and ascii diagrams. I think the only thing such an experiment would be likely to prove is that the proposed technology that requires complex graphics and equations to describe the involved logic is really not ready to be specified in an IETF specificiation. I think that proving complex diagrams and equations MIGHT be used with implementable specs, and may help understanding of the design, is not adequate; we already have the ability to include non-normative diagrams and equations to aid understanding. I don't think the proposed experiment as designed is useful. I do not see consensus on the IETF discussion list that the "problems to be solved" are actually problems to be solved. I do not feel the particular criteria chosen to determine experiment success are appropriate to IETF documents. Could PDF and other formats produce documents that are clearer, easier for authors to write, and easier to read? Sure. And if the difference is adequate, the authors should consider providing non-normative PDF to improve clarity, and ease of writing and reading. But that doesn't prove it should be normative. But the job of the IETF is not to publish pretty documents that are easy to write and read; it is to produce specifications of useful implementable standards for use in the Internet on a timely basis. I do not see those listed as "particular criteria" for measuring effectiveness. The criteria seem to miss the whole point of our working on standards. I do not believe it would be a worthwhile use of community resources to run this experiment as designed. David Harrington dharrington@xxxxxxxxxx dbharrington@xxxxxxxxxxx ietfdbh@xxxxxxxxxxx > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@xxxxxxxxx] > Sent: Sunday, June 25, 2006 4:16 PM > To: Stephen Sprunk > Cc: IETF-Discussion Discussion > Subject: Re: Last Call: 'Proposed Experiment: Normative > Format in AdditiontoASCII Text' to Experimental RFC > (draft-ash-alt-formats) > > On 25-jun-2006, at 21:55, Stephen Sprunk wrote: > > > IMHO, this would be a very good rule; the IETF is supposedly about > > running code, and complex equations that the average programmer > > cannot understand without digging up a college math book are > > unimplementable in the real world. Pseudocode is far, far more > > valuable than pretty equations. > > I agree one hundred percent. (Or 100%.) > > > IMHO, a direct result of the above is that any math that cannot be > > described adequately in ASCII text does not belong in an > RFC. This > > is similar to the view that diagrams that cannot be represented in > > ASCII art are too complex to be meaningful to the reader. > > I'm not sure if I fully agree with that, maybe there are useful > diagrams that can't be preserved in ASCII. But nobody has > presented a > convincing example so far. > > The fact that other standards organizations and/or engineering > disciplines make extensive use of diagrams doesn't mean we should do > the same. It makes a lot of sense to describe a building with a > blueprint, because meaningful aspects of a building easily translate > into a graphical representation. This is not the case with a > protocol > = software design. Traditionally, many kinds of diagrams have been > used here, but in my experience, with the exception of header format > diagrams, they rarely clarify as much as they seem to on first glance. > > > Every time this debate comes around, I am struck by the > notion that > > normative formats other than ASCII are a solution in search of a > > problem. About the only argument I've read to date that > makes sense > > is to allow UTF-8 to access characters that do not exist in ASCII, > > such as for authors' names or better line-drawing characters. > > Everything else seems to fall into the "our specs aren't as pretty > > as other SDOs' specs" category. > > My conclusion, having participated in this discussion the past week > or so, is that there is that limiting ourselves to ASCII does indeed > cause inconvenience, but changing to a new format would cause MANY > more problems than it solves. > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf