Stewart, While an interesting turn of phrase, "hair shirt approach" is hardly an accurate analogy, nor is it particularly apt to compare presentation materials (where there's a real live person in front of you to answer questions) with specifications (where there usually is not). One dilemma associated with unlimited scope for complex drawing is the fact that group-thinking rarely ever results in simplification (for pictures in particular, especially when those pictures are meant to be normative). While an author, editor or working group may want to keep figures/pictures simple, what are the criteria we should use to determine when an appropriate level of complexity is achieved? I would argue that those criteria would be along the lines of what I suggested earlier - irrespective of the editing technology we might use. And that would go along with the notion of using the simplest common document format sufficient for the task. -- Eric --> -----Original Message----- --> From: Stewart Bryant [mailto:stbryant@xxxxxxxxx] --> Sent: Wednesday, November 16, 2005 7:30 AM --> To: Lars-Erik Jonsson (LU/EAB) --> Cc: Gray, Eric; ietf@xxxxxxxx --> Subject: Re: Diagrams (Was RFCs should be distributed in XML) --> --> It's interesting that when authors turn up at IETF to --> explain their work/resolve issues etc they use colored --> diagrams to do so - not ASCII art. --> --> Some of this is fashionable, but in many cases it is to --> clearly articulate a point in the very little time made available. --> I don't see why such powerful techniques shouldn't be --> applied to the specifications themselves to allow the --> reader to most grasp what is being said with the minimum effort. --> --> I am afraid that I don't subscribe to the hair shirt --> approach to drawings. I think that they should be exactly --> fit for purpose neither too complex, nor too simple, and --> that the need to work round the limits of 72 ASCII --> characters should not be a constraint that limits the --> clarity of expression. --> --> For example look at slides 5 and 6 in --> http://www3.ietf.org/proceedings/05nov/slides/pwe3-2.ppt --> --> and compare to figure1 in --> http://www.ietf.org/internet-drafts/draft-balus-bocci-martin i-dyn-ms-pwe3-00.txt --> --> The latter shows the components of the system, but it is --> impossible to put the detail shown in the slides into the --> diagrams in the specification itself with our current tools. --> --> Look at the figures in --> http://www.ietf.org/internet-drafts/draft-bocci-bryant-pwe3- --> ms-pw-arch-01.txt --> particularly figure 8. We are at the limit of what we can --> describe in these diagrams. --> --> I can also find examples in the IP Fast Re-route work where --> we struggle to show network snippets in ASCII with the --> associated addressing and subsequent tunneling, and yet the --> operation is simple to show in ppt, pdf, etc etc, --> particularly with colour. --> --> Another example - many of the ideas that we talk about in --> the IETF start life as a few coloured lines on a large --> whiteboard - because that is the simplest way to visualise --> these ideas and to express them for the first time to our --> peers. That style of expression therefore seems to the --> specifications themselves and for exactly the same reason - clarity. --> --> Perhaps it is because the work that I do is mainly on --> overlay network techniques where it is necessary to --> describe how the virtual network maps onto the physical --> network that I find difficulty producing clear ASCII art, --> but I would be surprised if I were alone in that view. --> --> If we think that ASCII art is all that is needed, perhaps - --> as an experiment - we should forbid the use of anything --> other than ASCII art in presentations at the next IETF? --> --> - Stewart --> --> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf