Re: Diagrams (Was RFCs should be distributed in XML)
For true archival storage, nothing can beat the elegance and simplicity of engravings on stone. I believe that this site in Georgia has plenty of room for even the most complicated RFC's : http://www.cviog.uga.edu/Projects/gainfo/statues/guidestones.htm I had occasion to discuss this thread recently with some participants, and we agreed that this seems to be the direction it's heading. I suspect it would also help to keep protocols simple. (Financial disclosure : I have relatives who own quarries in this area.) Regards Marshall Eubanks On Nov 17, 2005, at 8:30 AM, Masataka Ohta wrote: Yaakov Stein wrote: It's good that protocols needing more than 72 ASCII characters are forbidden. Just imagine what elegantly simple protocols we would have if we required the descriptions to be in Morse code. Good idea. It's a better approach to enforce much simpler protocols. Masataka Ohta ___ 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
Re: Diagrams (Was RFCs should be distributed in XML)
Have any RFC protocols been specified using formal tools for their message interaction? I know a few use ASN.1, such as SNMP and LDAP, which have come from the ITU-T, but that's only for specifying the syntax (abstract or transfer), not the interaction of messages. From what I've been able to tell, the only mention to SDL in the RFCs is in relation to Simple Data Link. I'm currently just learning about ASN.1, so I don't know much about this space at the moment. On 18/11/2005, at 5:28 AM, Steve Crocker wrote: Phillip, I spent a large fraction of my professional life in pursuit of this alluring and seemingly simple goal. Here's a small challenge: Take *any* IETF protocol and write down the formal specification. Never mind the proof of correctness; that can come later. (And with it an extended discussion of the underlying logical system, the formal system for representing the protocol specification, and the proof system you have in mind for carrying out the proof.) Of course, the formal specification will have to be readable and understandable to the general population, and there will have to ready agreement that it does embody the desired properties. Pick something simple. Perhaps IP? Feel free to leave out messy details like performance issues if you wish. Just something simple and instructive to make your point. And in light of the other issues being discussed, don't feel constrained to use ASCII. Use any notation and tools you like. Steve Steve Crocker [EMAIL PROTECTED] On Nov 17, 2005, at 10:09 AM, Hallam-Baker, Phillip wrote: If we want to enforce simpler, more accurate design the best way to do this would be to require a formal proof of correctness before accepting a specification. Requiring people to use 1960s technology is not a way to achieve simplicity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masataka Ohta Sent: Thursday, November 17, 2005 8:30 AM To: Yaakov Stein Cc: ietf@ietf.org; Stewart Bryant Subject: Re: Diagrams (Was RFCs should be distributed in XML) Yaakov Stein wrote: It's good that protocols needing more than 72 ASCII characters are forbidden. Just imagine what elegantly simple protocols we would have if we required the descriptions to be in Morse code. Good idea. It's a better approach to enforce much simpler protocols. Masataka Ohta ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- • Cameron Kerr • ✉ [EMAIL PROTECTED] • • • Telecommunications Teaching Fellow SysAdmin • • ✎ http://humbledown.org/blog/ • ✆ 021 4117 644 • ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Gray, Eric wrote: 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). Indeed - where there is a person, the audience can ask questions of clarification, but an document must stand by itself. Clarity is therefore more important in a document, and we should therefore use the best tools available. 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? Occam's razor seems to be the best criteria for such a dilemma. Using a primitive presentation mechanism as a substitute for peer review on the appropriateness of the solution seems something of a cop-out that harms our ability to produce the most appropriate solution described in the clearest possible way. 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. I don't much care what technology we use, that is not a key issue for me. The key issue is to be able to describe a protocol using the most appropriate mixture of clear English, clear diagrams and if necessary pseudo-code. We can do the first and the last but seem reluctant to recognize the need for the middle. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Yaakov Stein wrote: It's good that protocols needing more than 72 ASCII characters are forbidden. Just imagine what elegantly simple protocols we would have if we required the descriptions to be in Morse code. Good idea. It's a better approach to enforce much simpler protocols. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Process for Process Change (Was Diagrams ((Was RFCs should be distributed in XML))
This is the nth time we've had this discussion RE ASCII art in IETF, but without a process for process change, no change could be made even if we all agreed, which we never do of course. While the discussion may be enlightening and entertaining, in the end it does nothing but waste cycles, there can be no forward motion without a way to change the process. IMO the ASCII art issue is an important case in point where it would be good to actually resolve the issue. Can we develop a process for process change where a proposal like 'allow I-Ds/RFCs to be posted in Word' can be resolved? Here's a possible approach: 1. submit a proposal to the IESG for a process change (in the form of an I-D) 2. the IESG decides by majority vote whether or not to take up the proposal 3. if #2 is yes, arguments are made for and against by anyone (in the form of an I-D) 4. after a specified period, IESG votes on the proposal 5. the majority decision of the IESG is binding But how do we implement *any* such proposal for a process change process, do we need a process for that?? Jerry P.S. Some good arguments have already been made on both sides of the ASCII art issue. I, like many others, use Word, etc. editors capable of sophisticated graphics, and have to struggle to convert to ASCII art in I-Ds. IMO this is a ridiculous waste of time and loss of information! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lars-Erik Jonsson (LU/EAB) Sent: Tuesday, November 15, 2005 9:19 AM To: Gray, Eric; Stewart Bryant Cc: ietf@ietf.org Subject: RE: Diagrams (Was RFCs should be distributed in XML) Very well stated!!! The ASCII-requirement is (apart from being a compact, generic, free, non-complex, document format) indirectly forcing people to really make diagrams simple, i.e. not put too much crap (complexity) in one single figure. After having had to read documents from other organisations people often cite as SDO's, I am personally convinced that the good sides of using ASCII completely outweights the potential negative aspects. /L-E Stewart, I suspect most people prefer reading documents that contain diagrams, but anything that limits the complexity of a diagram - especially for documents most often read on a computer screen - is a feature, rather than a bug. If a diagram is included to communicate (rather than obscure) an idea, then readers should be able to correlate descriptive text to the diagram - either because the diagram is simple enough that it is not necessary to keep referring to it, or because the entire description can be viewed while looking at the diagram. Sometimes language limitations are a good thing, when they are tied to specific ways of presenting information. -- Eric ___ 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
RE: Diagrams (Was RFCs should be distributed in XML)
If we want to enforce simpler, more accurate design the best way to do this would be to require a formal proof of correctness before accepting a specification. Requiring people to use 1960s technology is not a way to achieve simplicity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masataka Ohta Sent: Thursday, November 17, 2005 8:30 AM To: Yaakov Stein Cc: ietf@ietf.org; Stewart Bryant Subject: Re: Diagrams (Was RFCs should be distributed in XML) Yaakov Stein wrote: It's good that protocols needing more than 72 ASCII characters are forbidden. Just imagine what elegantly simple protocols we would have if we required the descriptions to be in Morse code. Good idea. It's a better approach to enforce much simpler protocols. Masataka Ohta ___ 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
RE: Diagrams (Was RFCs should be distributed in XML)
Yaakov, Funny. Ha ha. The big distinction is that very few people can read Morse code. Can you? -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Yaakov Stein -- Sent: Thursday, November 17, 2005 1:48 AM -- To: Stewart Bryant; Masataka Ohta; ietf@ietf.org -- Subject: RE: Diagrams (Was RFCs should be distributed in XML) -- -- -- It's good that protocols needing more than 72 ASCII characters are -- forbidden. -- -- Just imagine what elegantly simple protocols we would have -- if we required the descriptions to be in Morse code. -- -- Y(J)S -- -- ___ -- 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
RE: Diagrams (Was RFCs should be distributed in XML)
-- -Original Message- -- From: Stewart Bryant [mailto:[EMAIL PROTECTED] -- Sent: Thursday, November 17, 2005 5:01 AM -- To: Gray, Eric -- Cc: ietf@ietf.org; Lars-Erik Jonsson (LU/EAB) -- Subject: Re: Diagrams (Was RFCs should be distributed in XML) -- --- [SNIP] --- -- -- I don't much care what technology we use, that is not a key -- issue for me. The key issue is to be able to describe a -- protocol using the most appropriate mixture of clear -- English, clear diagrams and if necessary pseudo-code. We -- can do the first and the last but seem reluctant to -- recognize the need for the middle. -- -- - Stewart -- Fair enough. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Phillip, I spent a large fraction of my professional life in pursuit of this alluring and seemingly simple goal. Here's a small challenge: Take *any* IETF protocol and write down the formal specification. Never mind the proof of correctness; that can come later. (And with it an extended discussion of the underlying logical system, the formal system for representing the protocol specification, and the proof system you have in mind for carrying out the proof.) Of course, the formal specification will have to be readable and understandable to the general population, and there will have to ready agreement that it does embody the desired properties. Pick something simple. Perhaps IP? Feel free to leave out messy details like performance issues if you wish. Just something simple and instructive to make your point. And in light of the other issues being discussed, don't feel constrained to use ASCII. Use any notation and tools you like. Steve Steve Crocker [EMAIL PROTECTED] On Nov 17, 2005, at 10:09 AM, Hallam-Baker, Phillip wrote: If we want to enforce simpler, more accurate design the best way to do this would be to require a formal proof of correctness before accepting a specification. Requiring people to use 1960s technology is not a way to achieve simplicity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masataka Ohta Sent: Thursday, November 17, 2005 8:30 AM To: Yaakov Stein Cc: ietf@ietf.org; Stewart Bryant Subject: Re: Diagrams (Was RFCs should be distributed in XML) Yaakov Stein wrote: It's good that protocols needing more than 72 ASCII characters are forbidden. Just imagine what elegantly simple protocols we would have if we required the descriptions to be in Morse code. Good idea. It's a better approach to enforce much simpler protocols. Masataka Ohta ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
There is a way, develop a highly targetted formalism for the specific problem. This is hard to apply to existing specs because they tend to be inconsistent. If you are required to apply a formalism you have to be much more consistent in your design approach. I did this for the finite state portions of FTP, NNTP and SMTP in 1993 when I was working on HTTP. With HTTP at the time there was not a lot of state. -Original Message- From: Steve Crocker [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 11:28 AM To: Hallam-Baker, Phillip Cc: Steve Crocker; Masataka Ohta; Yaakov Stein; ietf@ietf.org; Stewart Bryant Subject: Re: Diagrams (Was RFCs should be distributed in XML) Phillip, I spent a large fraction of my professional life in pursuit of this alluring and seemingly simple goal. Here's a small challenge: Take *any* IETF protocol and write down the formal specification. Never mind the proof of correctness; that can come later. (And with it an extended discussion of the underlying logical system, the formal system for representing the protocol specification, and the proof system you have in mind for carrying out the proof.) Of course, the formal specification will have to be readable and understandable to the general population, and there will have to ready agreement that it does embody the desired properties. Pick something simple. Perhaps IP? Feel free to leave out messy details like performance issues if you wish. Just something simple and instructive to make your point. And in light of the other issues being discussed, don't feel constrained to use ASCII. Use any notation and tools you like. Steve Steve Crocker [EMAIL PROTECTED] On Nov 17, 2005, at 10:09 AM, Hallam-Baker, Phillip wrote: If we want to enforce simpler, more accurate design the best way to do this would be to require a formal proof of correctness before accepting a specification. Requiring people to use 1960s technology is not a way to achieve simplicity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masataka Ohta Sent: Thursday, November 17, 2005 8:30 AM To: Yaakov Stein Cc: ietf@ietf.org; Stewart Bryant Subject: Re: Diagrams (Was RFCs should be distributed in XML) Yaakov Stein wrote: It's good that protocols needing more than 72 ASCII characters are forbidden. Just imagine what elegantly simple protocols we would have if we required the descriptions to be in Morse code. Good idea. It's a better approach to enforce much simpler protocols. Masataka Ohta ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Well, even if you choose your formalism first and then use that to guide the development and specification of the protocols, the challenge still stands. The operative word in your description is portions. Does the technique cover enough of the protocol to be useful and does it wind up adding or saving time, work, errors, etc? Steve Steve Crocker [EMAIL PROTECTED] On Nov 17, 2005, at 11:56 AM, Hallam-Baker, Phillip wrote: There is a way, develop a highly targetted formalism for the specific problem. This is hard to apply to existing specs because they tend to be inconsistent. If you are required to apply a formalism you have to be much more consistent in your design approach. I did this for the finite state portions of FTP, NNTP and SMTP in 1993 when I was working on HTTP. With HTTP at the time there was not a lot of state. -Original Message- From: Steve Crocker [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 11:28 AM To: Hallam-Baker, Phillip Cc: Steve Crocker; Masataka Ohta; Yaakov Stein; ietf@ietf.org; Stewart Bryant Subject: Re: Diagrams (Was RFCs should be distributed in XML) Phillip, I spent a large fraction of my professional life in pursuit of this alluring and seemingly simple goal. Here's a small challenge: Take *any* IETF protocol and write down the formal specification. Never mind the proof of correctness; that can come later. (And with it an extended discussion of the underlying logical system, the formal system for representing the protocol specification, and the proof system you have in mind for carrying out the proof.) Of course, the formal specification will have to be readable and understandable to the general population, and there will have to ready agreement that it does embody the desired properties. Pick something simple. Perhaps IP? Feel free to leave out messy details like performance issues if you wish. Just something simple and instructive to make your point. And in light of the other issues being discussed, don't feel constrained to use ASCII. Use any notation and tools you like. Steve Steve Crocker [EMAIL PROTECTED] On Nov 17, 2005, at 10:09 AM, Hallam-Baker, Phillip wrote: If we want to enforce simpler, more accurate design the best way to do this would be to require a formal proof of correctness before accepting a specification. Requiring people to use 1960s technology is not a way to achieve simplicity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masataka Ohta Sent: Thursday, November 17, 2005 8:30 AM To: Yaakov Stein Cc: ietf@ietf.org; Stewart Bryant Subject: Re: Diagrams (Was RFCs should be distributed in XML) Yaakov Stein wrote: It's good that protocols needing more than 72 ASCII characters are forbidden. Just imagine what elegantly simple protocols we would have if we required the descriptions to be in Morse code. Good idea. It's a better approach to enforce much simpler protocols. Masataka Ohta ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
The description was sufficiently complete to allow running code to be compiled from the formal specification. It certainly does save time when used by someone who has the necessary experience to work at a very high level of abstraction. The problem is that it is very hard to persuade others to then maintain the generated code as this is not a mainstream coding technique. We can get people to use Lex and Yacc for specific projects but the idea of developing a tool for the project is something that is not very popular outside MIT and the like. If you read Kernighan and Plaugher's book on software tools you will see that this approach did play an important role in the early development of Unix. But what has tended to happen since is that people have taken the specific tools developed rather than adopt the approach. -Original Message- From: Steve Crocker [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 12:00 PM To: Hallam-Baker, Phillip Cc: Steve Crocker; Masataka Ohta; Yaakov Stein; ietf@ietf.org; Stewart Bryant Subject: Re: Diagrams (Was RFCs should be distributed in XML) Well, even if you choose your formalism first and then use that to guide the development and specification of the protocols, the challenge still stands. The operative word in your description is portions. Does the technique cover enough of the protocol to be useful and does it wind up adding or saving time, work, errors, etc? Steve Steve Crocker [EMAIL PROTECTED] On Nov 17, 2005, at 11:56 AM, Hallam-Baker, Phillip wrote: There is a way, develop a highly targetted formalism for the specific problem. This is hard to apply to existing specs because they tend to be inconsistent. If you are required to apply a formalism you have to be much more consistent in your design approach. I did this for the finite state portions of FTP, NNTP and SMTP in 1993 when I was working on HTTP. With HTTP at the time there was not a lot of state. -Original Message- From: Steve Crocker [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 11:28 AM To: Hallam-Baker, Phillip Cc: Steve Crocker; Masataka Ohta; Yaakov Stein; ietf@ietf.org; Stewart Bryant Subject: Re: Diagrams (Was RFCs should be distributed in XML) Phillip, I spent a large fraction of my professional life in pursuit of this alluring and seemingly simple goal. Here's a small challenge: Take *any* IETF protocol and write down the formal specification. Never mind the proof of correctness; that can come later. (And with it an extended discussion of the underlying logical system, the formal system for representing the protocol specification, and the proof system you have in mind for carrying out the proof.) Of course, the formal specification will have to be readable and understandable to the general population, and there will have to ready agreement that it does embody the desired properties. Pick something simple. Perhaps IP? Feel free to leave out messy details like performance issues if you wish. Just something simple and instructive to make your point. And in light of the other issues being discussed, don't feel constrained to use ASCII. Use any notation and tools you like. Steve Steve Crocker [EMAIL PROTECTED] On Nov 17, 2005, at 10:09 AM, Hallam-Baker, Phillip wrote: If we want to enforce simpler, more accurate design the best way to do this would be to require a formal proof of correctness before accepting a specification. Requiring people to use 1960s technology is not a way to achieve simplicity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masataka Ohta Sent: Thursday, November 17, 2005 8:30 AM To: Yaakov Stein Cc: ietf@ietf.org; Stewart Bryant Subject: Re: Diagrams (Was RFCs should be distributed in XML) Yaakov Stein wrote: It's good that protocols needing more than 72 ASCII characters are forbidden. Just imagine what elegantly simple protocols we would have if we required the descriptions to be in Morse code. Good idea. It's a better approach to enforce much simpler protocols. Masataka Ohta ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Process for Process Change (Was Diagrams ((Was RFCs should be distributed in XML))
* * P.S. Some good arguments have already been made on both sides of the * ASCII art issue. I, like many others, use Word, etc. editors capable of * sophisticated graphics, and have to struggle to convert to ASCII art in * I-Ds. IMO this is a ridiculous waste of time and loss of information! * Ease for the author of a document has to be balanced against convenience and universal access for its readers. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Process for Process Change (Was Diagrams ((Was RFCs should be distributed in XML))
Sam, I agree with you on the fact that text should stand alone. People who think that it is not possible to describe a figure sufficiently well enough for it to be accurately understood without seeing it should try attending more conference calls where they are at the wrong (as in remote) end. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Sam Hartman -- Sent: Thursday, November 17, 2005 4:51 PM -- To: Hallam-Baker, Phillip -- Cc: [EMAIL PROTECTED]; Bob Braden; ietf@ietf.org -- Subject: Re: Process for Process Change (Was Diagrams ((Was -- RFCs should bedistributed in XML)) -- -- Hallam-Baker, == Hallam-Baker, Phillip -- [EMAIL PROTECTED] writes: -- -- -- Hallam-Baker, I do not think that you really care about -- Hallam-Baker, accessibility. If you did you would -- understand why -- Hallam-Baker, the idea of putting ASCII art through a text to -- Hallam-Baker, speech interface is utterly ridiculous. -- At least in -- Hallam-Baker, HTML the voice synthesizer knows that it has come -- Hallam-Baker, to a diagram that it should not attempt to -- Hallam-Baker, interpret. -- -- -- I actually can get some content out of ascii art diagrams. -- Certainly more than I could out of a gif or png and more -- than I would in practice out of an svg. -- -- I wouldn't mind though if the IETF went away from ascii -- diagrams provided that they commit to guaranteeing that the -- normative text is complete without the diagrams. No, doing -- that is not as hard as some people seem to think. -- -- ___ -- 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
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-martini-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 mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Stewart Bryant wrote: 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. It merely promote complex protocols to disallow the reader to grasp even with the maximum 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. It's good that protocols needing more than 72 ASCII characters are forbidden. For examples, see NGN diagrams. For further improvement to forbid the work round, it is good if RFCs more than 20 pages long are disallowed. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Masataka Ohta wrote: Stewart Bryant wrote: 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. It merely promote complex protocols to disallow the reader to grasp even with the maximum effort. Limiting the documentation mechanism is not an appropriate way to limit the complexity of protocols. That is the function of the WG/IETF/IESG review process. 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. It's good that protocols needing more than 72 ASCII characters are forbidden. For examples, see NGN diagrams. They are not forbidden - they are just harder to describe and are hence more likely to have bugs that no one notices until we have a problem. For further improvement to forbid the work round, it is good if RFCs more than 20 pages long are disallowed. Which results in protocol definitions that are choped up into so many parts that no one can see how to put then back together. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Stewart Bryant wrote: Which results in protocol definitions that are choped up into so many parts that no one can see how to put then back together. That's fine. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
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:[EMAIL PROTECTED] -- Sent: Wednesday, November 16, 2005 7:30 AM -- To: Lars-Erik Jonsson (LU/EAB) -- Cc: Gray, Eric; ietf@ietf.org -- 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 mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
Marshall, That may be true, but it has long been the case that a state-machine may completely and accurately be defined as a (relatively) simple symbolic expression - requiring no figure at all. Assuming that such an expression is included in the normative text, then reference to an illustrative figure would be an appropriate non-normative reference. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Marshall Eubanks -- Sent: Wednesday, November 16, 2005 11:00 AM -- To: Stewart Bryant -- Cc: Lars-Erik Jonsson (LU/EAB); ietf@ietf.org -- Subject: Re: Diagrams (Was RFCs should be distributed in XML) -- -- Hello; -- -- I suspect that there is a lot more reliance of non-ASCII -- art out there than is officially admitted. -- -- I do not know how, for example, you can understand the -- PIMv2 state machine without reference to the (non-ASCII) -- diagrams provided in the -- (non-ASCII) version of the draft. -- -- Regards -- Marshall Eubanks -- -- On Nov 16, 2005, at 7:29 AM, Stewart Bryant wrote: -- -- 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-martini-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 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 -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
At 11:00 AM 11/16/2005 -0500, Marshall Eubanks wrote: Hello; I suspect that there is a lot more reliance of non-ASCII art out there than is officially admitted. I do not know how, for example, you can understand the PIMv2 state machine without reference to the (non-ASCII) diagrams provided in the (non-ASCII) version of the draft. Some might wonder whether it is possible to understand the PIMv2 state machine under ANY circumstances. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
It's good that protocols needing more than 72 ASCII characters are forbidden. Just imagine what elegantly simple protocols we would have if we required the descriptions to be in Morse code. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
Very well stated!!! The ASCII-requirement is (apart from being a compact, generic, free, non-complex, document format) indirectly forcing people to really make diagrams simple, i.e. not put too much crap (complexity) in one single figure. After having had to read documents from other organisations people often cite as SDO's, I am personally convinced that the good sides of using ASCII completely outweights the potential negative aspects. /L-E Stewart, I suspect most people prefer reading documents that contain diagrams, but anything that limits the complexity of a diagram - especially for documents most often read on a computer screen - is a feature, rather than a bug. If a diagram is included to communicate (rather than obscure) an idea, then readers should be able to correlate descriptive text to the diagram - either because the diagram is simple enough that it is not necessary to keep referring to it, or because the entire description can be viewed while looking at the diagram. Sometimes language limitations are a good thing, when they are tied to specific ways of presenting information. -- Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
Watching engineers implement specs as code I note that most use secondary sources such as O'Rielly in preference to the supposedly authoritative IETF specs. The lack of readability is a major reason. This is not the case with W3C specs. There is very little point spending time perfecting text that is only ever going to be read by the author of the O'Rielly nutshell book. The real standard is the bits on the real wire. If those are coded from O'Rielly then O'Rielly, not the IETF is the standards setter. I don't recall seeing ASCII art in O'Rielly books. Leave the ASCII art for recreational use. If you want to be regarded as a professional organization then make sure that every communication looks professional. ASCII art screams 'amateur'. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lars-Erik Jonsson (LU/EAB) Sent: Tuesday, November 15, 2005 9:19 AM To: Gray, Eric; Stewart Bryant Cc: ietf@ietf.org Subject: RE: Diagrams (Was RFCs should be distributed in XML) Very well stated!!! The ASCII-requirement is (apart from being a compact, generic, free, non-complex, document format) indirectly forcing people to really make diagrams simple, i.e. not put too much crap (complexity) in one single figure. After having had to read documents from other organisations people often cite as SDO's, I am personally convinced that the good sides of using ASCII completely outweights the potential negative aspects. /L-E Stewart, I suspect most people prefer reading documents that contain diagrams, but anything that limits the complexity of a diagram - especially for documents most often read on a computer screen - is a feature, rather than a bug. If a diagram is included to communicate (rather than obscure) an idea, then readers should be able to correlate descriptive text to the diagram - either because the diagram is simple enough that it is not necessary to keep referring to it, or because the entire description can be viewed while looking at the diagram. Sometimes language limitations are a good thing, when they are tied to specific ways of presenting information. -- Eric ___ 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
RE: Diagrams (Was RFCs should be distributed in XML)
* * Watching engineers implement specs as code I note that most use * secondary sources such as O'Rielly in preference to the supposedly * authoritative IETF specs. The lack of readability is a major reason. * * This is not the case with W3C specs. * * There is very little point spending time perfecting text that is only * ever going to be read by the author of the O'Rielly nutshell book. * * The real standard is the bits on the real wire. If those are coded from * O'Rielly then O'Rielly, not the IETF is the standards setter. * * I don't recall seeing ASCII art in O'Rielly books. * I am certainly not going to claim that ASCII art is God's Gift to Implementers, but I have a hard time believing that the alleged superiority of the O'Reilly specs is due to the artistic quality of their diagrams, as opposed, say, to the quality of their prose. * * Leave the ASCII art for recreational use. If you want to be regarded as * a professional organization then make sure that every communication * looks professional. ASCII art screams 'amateur'. I'm sorry, that is nonsense. Was Jon Postel an amateur? Fancy pictures CAN be a help for some explanatory purposes, but they can also distract from a poorly written description. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
From: Bob Braden [mailto:[EMAIL PROTECTED] * * Leave the ASCII art for recreational use. If you want to be regarded as * a professional organization then make sure that every communication * looks professional. ASCII art screams 'amateur'. I'm sorry, that is nonsense. Was Jon Postel an amateur? Fancy pictures CAN be a help for some explanatory purposes, but they can also distract from a poorly written description. I think that it is ridiculous for you to assert that you know what Jon would be doing now if he were alive today. The worst possible tribute you could make to Jon would be to freeze the IETF in its state on October 16 1998. In 1998 you could just about get away with plaintext, laserprinters were common but had only become ubiquitous recently. I discussed HTML RFCs with Jon a few months before he died. He expressed concerns but not the ones that have been expressed here. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Diagrams (Was RFCs should be distributed in XML)
On Nov 14, 2005, at 8:56 AM, Stewart Bryant wrote: snip BTW - one carrot that would tempt me away would be if the result allowed the normative text to incorprate proper diagrams - like ITU and IEEE - two name but two - have use in their specifications for the last 20 or so years. The issue of diagrams is entangled in the long-standing discussion of proprietary formats. There is a huge benefit in having a format that *everyone* can access without difficulty or cost. I can't begin to tell you the impact I felt when I walked into a university half way around the world in an underdeveloped country and had a graduate student show me some pretty sophisticated stuff he had done based on RFCs he had downloaded from the net. ASCII is an enormous advantage from that respect. At the same time, we have clearly hobbled ourselves in not moving forward with more advanced technology. In a way, we have made ourselves a parody of our own success, staying locked into 1960s technology while we have created the technology for the twenty-first century. The ITU and IEEE have progressed to PDF and other formats, partly because they still view paper as the primary medium. I don't know whether this issue was covered in the TechSpec BoF (http://www3.ietf.org/proceedings/05nov/agenda/techspec.txt) but it definitely needs attention. Perhaps this should be a separate thread in the discussions about publications. Steve Steve Crocker [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
IMHO, standardizing on _validated_ SVG with a library of well understood images that represented architectural components with attached semantics could be used to even start validating diagrams the same way we validate BNFs now. There are even UML to SVG tools for turning SVG drawings directly into code. And there are lots of free SVG tools -MM Steve Crocker wrote: The issue of diagrams is entangled in the long-standing discussion of proprietary formats. There is a huge benefit in having a format that *everyone* can access without difficulty or cost. I can't begin to tell you the impact I felt when I walked into a university half way around the world in an underdeveloped country and had a graduate student show me some pretty sophisticated stuff he had done based on RFCs he had downloaded from the net. ASCII is an enormous advantage from that respect. -- Michael Mealling Masten Space Systems, Inc. VP Business Development 473 Sapena Ct. Office: +1-678-581-9656Suite 23 Cell: +1-678-640-6884 Santa Clara, CA 95054 http://masten-space.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
On Mon, Nov 14, 2005 at 09:37:41AM -0500, Steve Crocker wrote: The issue of diagrams is entangled in the long-standing discussion of proprietary formats. There is a huge benefit in having a format that *everyone* can access without difficulty or cost. I can't begin to tell you the impact I felt when I walked into a university half way around the world in an underdeveloped country and had a graduate student show me some pretty sophisticated stuff he had done based on RFCs he had downloaded from the net. ASCII is an enormous advantage from that respect. What I find strange about this, though, is the reluctance to adopt PDF. It's a well-known open standard. There are plenty of free software interpreters and writers around, and Ghostscript passed the threshold for good output 2 or 3 versions ago. I understand the difficulty of machine parsing, but wouldn't an XML format with human oriented output in PDF be nice? (I suppose I'm asking whether there's some historical flamewar over this that I managed never to look at, in which case I'll just keep my mouth shut.) Of course, even if that was solved, the features of Word that other like are not really available in most of the XML tools, AFAIK. A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x4110 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Andrew Sullivan wrote: What I find strange about this, though, is the reluctance to adopt PDF. It's a well-known open standard. There are plenty of free software interpreters and writers around, and Ghostscript passed the threshold for good output 2 or 3 versions ago. I understand the difficulty of machine parsing, but wouldn't an XML format with human oriented output in PDF be nice? (I suppose I'm asking whether there's some historical flamewar over this that I managed never to look at, in which case I'll just keep my mouth shut.) There is. Lets not reopen the format flame war. However, just for the record we DO have .pdf as a format that you can submit Internet Drafts and as something that you also get from the RFC Editor. It is required that a text format be also provided, which I think is natural and useful. Some of the PDF documents that people have used have contained illustrations such as state machines. See for instance this RFC ftp://ftp.rfc-editor.org/in-notes/rfc4137.pdf and for some tool support take a look at http://www.arkko.com/tools/xml2pdfrfc.html Of course, even if that was solved, the features of Word that other like are not really available in most of the XML tools, AFAIK. I kind of like the rfcdiff feature in text format more than the word features. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
On Mon, Nov 14, 2005 at 06:03:07PM +0200, Jari Arkko wrote: There is. Lets not reopen the format flame war. However, just for the record we DO have .pdf as a format that you can submit Internet Drafts and as something that you Ok, consider it not re-opened. (And yes, I knew about the pdfs. It just struck me as odd that people were grousing about ASCII's appearance when PDF is available. But I'm keeping the worm-can closed.) A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x4110 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
I understand the difficulty of machine parsing, but wouldn't an XML format with human oriented output in PDF be nice? (I suppose I'm asking whether there's some historical flamewar over this that I managed never to look at, in which case I'll just keep my mouth shut.) There is. Lets not reopen the format flame war. However, just for the record we DO have .pdf as a format that you can submit Internet Drafts and as something that you also get from the RFC Editor. Folks might want to take a look at the latest xml2rfc capabilities. See http://xml.resource.org/. Besides making it far easier to include the correct boilerplate, it has the option of including pretty graphics for the PDF version, while using the ASCII form for the ASCII version. This seems like a rather good transition mechanism, to see whether we really want/need to move away from ASCII. (After all, the dual-stack model for transition is a time-honored methodology...) d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
It just struck me as odd that people were grousing about ASCII's appearance when PDF is available. People will stop complaining when the ASCII version is allowed to say see diagram in the PDF version. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Andrew Sullivan wrote: On Mon, Nov 14, 2005 at 06:03:07PM +0200, Jari Arkko wrote: There is. Lets not reopen the format flame war. However, just for the record we DO have .pdf as a format that you can submit Internet Drafts and as something that you However these are not taken as normative, so you have to produce an ASCII equivalent, which fundamentally limits the complexity of any normative diagram. My view is this is a serious restriction in the power of the language that we are allowed to use to describe our protocols, but then I am a person that finds it much easier to understand diagrams than text. - Stewart - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Yaakov Stein wrote: It just struck me as odd that people were grousing about ASCII's appearance when PDF is available. People will stop complaining when the ASCII version is allowed to say see diagram in the PDF version. Right on the nail - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
Stewart, I suspect most people prefer reading documents that contain diagrams, but anything that limits the complexity of a diagram - especially for documents most often read on a computer screen - is a feature, rather than a bug. If a diagram is included to communicate (rather than obscure) an idea, then readers should be able to correlate descriptive text to the diagram - either because the diagram is simple enough that it is not necessary to keep referring to it, or because the entire description can be viewed while looking at the diagram. Sometimes language limitations are a good thing, when they are tied to specific ways of presenting information. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Stewart Bryant -- Sent: Monday, November 14, 2005 2:09 PM -- To: Andrew Sullivan -- Cc: ietf@ietf.org -- Subject: Re: Diagrams (Was RFCs should be distributed in XML) -- -- -- -- Andrew Sullivan wrote: -- -- On Mon, Nov 14, 2005 at 06:03:07PM +0200, Jari Arkko wrote: -- -- There is. Lets not reopen the format flame war. However, just for the -- record we DO have .pdf as a format that you can submit Internet Drafts -- and as something that you -- -- -- However these are not taken as normative, so you have to -- produce an ASCII equivalent, which fundamentally limits the -- complexity of any normative diagram. -- -- My view is this is a serious restriction in the power of -- the language that we are allowed to use to describe our -- protocols, but then I am a person that finds it much easier -- to understand diagrams than text. -- -- - Stewart -- -- -- - Stewart -- -- -- ___ -- 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
Re: Diagrams (Was RFCs should be distributed in XML)
Dave Crocker wrote: Folks might want to take a look at the latest xml2rfc capabilities. See http://xml.resource.org/. Besides making it far easier to include the correct boilerplate, it has the option of including pretty graphics for the PDF version, while using the ASCII form for the ASCII version. XML2RFC has improved in this regard, e.g., it allows inclusion of pictures for the HTML version. But I do not think even the latest version generates .pdf nor does it appear to produce very pretty output from xml-html-pdf. Though your favorite XML editing tool may provide some solution for that. Nevertheless, I've had good success in running xml-nr-pdf, but that requires some tuning of the nroff output -- this is what the tool link that I posted earlier does, without requiring the user to do any extra steps or having any software beyond what regular unix systems do by default. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
People will stop complaining when ... Right on the nail I suspect you underestimate our ability to keep complaining. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Diagrams (Was RFCs should be distributed in XML)
* * It just struck me as odd that people were grousing about ASCII's * appearance when PDF is available. * * People will stop complaining when the ASCII version is allowed to say * see diagram in the PDF version. * * Y(J)S * Huh? That has always been allowed. What am I missing? Bob Braden for the RFC Editor * ___ * 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
Re: Diagrams (Was RFCs should be distributed in XML)
Jari Arkko wrote: Dave Crocker wrote: Folks might want to take a look at the latest xml2rfc capabilities. See http://xml.resource.org/. Besides making it far easier to include the correct boilerplate, it has the option of including pretty graphics for the PDF version, while using the ASCII form for the ASCII version. XML2RFC has improved in this regard, e.g., it allows inclusion of pictures for the HTML version. But I do not think even the latest version generates .pdf nor does it appear to produce very pretty output from xml-html-pdf. Though your favorite You can get fairly good PDF using rfc2629toFo.xslt (available from http://greenbytes.de/tech/webdav/rfc2629xslt.zip) and Apache-Fop. See for instance http://greenbytes.de/tech/webdav/rfc3986.pdf. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Bob Braden wrote: * * It just struck me as odd that people were grousing about ASCII's * appearance when PDF is available. * * People will stop complaining when the ASCII version is allowed to say * see diagram in the PDF version. * * Y(J)S * Huh? That has always been allowed. What am I missing? Please can we be quite clear on this - for the record: I can include a normative diagram in the .pdf version of an RFC (that is too complex to produce in ASCII art), and say in the normative text of the ASCII version the diagram you need to implement this protocol is in the .pdf version of this RFC? If that is the case, I withdraw my concern and will use this process, however I was told by a member of the IESG a few months back that such a document would not be passed for publication as an RFC by him. - Stewart Bob Braden for the RFC Editor * ___ * 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
* * Bob Braden wrote: * ** ** It just struck me as odd that people were grousing about ASCII's ** appearance when PDF is available. ** ** People will stop complaining when the ASCII version is allowed to sa ** see diagram in the PDF version. ** ** Y(J)S ** * * Huh? That has always been allowed. What am I missing? * * Please can we be quite clear on this - for the record: * * I can include a normative diagram in the .pdf version of an RFC * (that is too complex to produce in ASCII art), and say in the * normative text of the ASCII version the diagram you need to * implement this protocol is in the .pdf version of this RFC? No, the .ps/.pdf is not allowed to be normative. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Bob Braden wrote: * * Bob Braden wrote: * ** ** It just struck me as odd that people were grousing about ASCII's ** appearance when PDF is available. ** ** People will stop complaining when the ASCII version is allowed to sa ** see diagram in the PDF version. ** ** Y(J)S ** * * Huh? That has always been allowed. What am I missing? * * Please can we be quite clear on this - for the record: * * I can include a normative diagram in the .pdf version of an RFC * (that is too complex to produce in ASCII art), and say in the * normative text of the ASCII version the diagram you need to * implement this protocol is in the .pdf version of this RFC? No, the .ps/.pdf is not allowed to be normative. Which is the point that I was making and Yaakov summarized so succinctly. We need to change the publication process so that we can move away from 1960's improvisations to clear diagrams using modern techniques. Anything less leaves us without the ability to describe protocols using the clearest methods currently available. - Stewart Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
On Mon, Nov 14, 2005 at 09:27:46PM +, Stewart Bryant wrote: We need to change the publication process so that we can move away from 1960's improvisations to clear diagrams using modern techniques. Anything less leaves us without the ability to describe protocols using the clearest methods currently available. The clearest methods currently available might include visio diagrams or powerpoint slides -- at least according to some people. -- Kent Crispin [EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649 [EMAIL PROTECTED] SIP: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Joe! On Mon, 14 Nov 2005, Joe Touch wrote: XML is modern? Where's the modern, WYSIWYG, outline-mode capable editor? And does one exist that's free? OpenOffice, XXE, etc. Google is your friend. RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDeRnm8KZibdeR3qURAvinAJwN3Tf2d6qRB/A8VLExE43vlCJogACg6J3w lejE6UfZ2/tz5w91dOy0x/o= =kn4h -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
On 11/14/05, Joe Touch [EMAIL PROTECTED] wrote: Where's the modern, WYSIWYG, outline-mode capable editor? And does one exist that's free? Still a work in progress, but see http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ . Outline mode is high on my todo list (I have one working that only does top-level sections, but haven't gotten it working showing all sections yet.) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Randy.Dunlap writes: SVG was mentioned (as spec'd by w3.org IIRC). So check out Inkscape: using the W3C standard Scalable Vector Graphics (SVG) file format. Available for multiple platforms. http://www.inkscape.org/ Using an open format that requires people to install special free software is no different than using a proprietary format that requires people to install special free software. And if that is to be the case, PDF is much more widespread than SVG. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Joe Touch writes: XML is modern? Where's the modern, WYSIWYG, outline-mode capable editor? And does one exist that's free? XML is fashionable, not necessarily functional. There's a difference. (I'd love to work in XML, but it seems like a 20-yr step backwards to manually edit the source code of a document) A lot of people don't remember that far back. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
Stewart Bryant writes: However these are not taken as normative, so you have to produce an ASCII equivalent, which fundamentally limits the complexity of any normative diagram. Depends. If the ASCII document is large enough, in theory you can represent any monochrome image with an arbitrary degree of accuracy. If line lengths or number are limited, though, this isn't possible. Essentially you just make some non-blank ASCII character represent a dark pixel, and use a blank for a white pixel. So with 768 lines of 1024 characters each, you can represent a typical video display. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
