Bob, State Diagrams is a bad example. State machines can, and should always be, described definitively in text. State machine diagrams must be derived from textual description. Consequently, if we want to create a document with a pictorial representation, that document could contain normative references to a document containing a textual description and not the other way around. Being able to put both in the same document and have that document be authoritative would be a plus, provided we could be sure that everyone could read that document. Perhaps a better example might be complex functional block diagrams. Or mathematical expressions as someone else pointed out earlier. If your point is that there are things that are painfully hard to represent in text, obviously that is true - although we have had several people argue that this is a good thing, most of the time. -- Eric --> -----Original Message----- --> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] --> On Behalf Of Bob Braden --> Sent: Friday, January 06, 2006 1:57 PM --> To: sandy@xxxxxxxxxx --> Cc: ietf@xxxxxxxx --> Subject: RE: objection to proposed change to "consensus" --> --> --> *> --> *> --> --> *> --> "I think we have reached substantial agreement --> on the following --> *> --> statement: ASCII text was good enough for my --> Grandfather, and it's --> *> --> going to be good enough for my grandchildren. --> Please reply to this --> *> --> CfC if you object." --> *> --> --> *> --> --> "Are we all in favor of Motherhood and Apple Pie?" "Well, mostly." --> --> No one (well, the IETF is a big tent, so that's probably --> too strong... --> almost no one) questions the desirability of a better format for --> publishing RFCs than pure ASCII text. This has been the subject of --> repeated discussions over the last 20 years. Will the same --> discussion --> be taking place 20 years from now? I, for one, certainly hope not. --> --> However, simply wishing we had a better solution is not enough. We --> need to have such a reasonable solution in hand before we agree to --> adopt it. We believe we want vendor neutrality, ubiquity, --> convenience, --> searchability, editability, etc.. The obvious, simple --> suggestions have --> all failed on one criterion or another, and ASCII has --> continued to be --> the best (if flawed) compromise. --> --> For many years, PS and PDF files have been allowed as --> secondary formats --> for RFCs. (You can find them by searching rfc-index.txt for the --> strings 'PS=' and 'PDF=', respectively). This provision does not --> handle things like state diagrams, which are presumably --> normative. In --> practice, creating the PS/PDF forms has been a major pain, --> because the --> documentswere created by the authors using a wide variety of --> different editors and tools. --> --> On the other hand, it does appear that the availability of ASCII --> support as a common denominator is decreasing over time. --> As has been --> observed, some software vendors seem to go out of their way to make --> simple ASCII hard to use. So there is increasing pressure to find --> a (truly) better solution. --> --> Bob Braden --> --> _______________________________________________ --> Ietf mailing list --> Ietf@xxxxxxxx --> https://www1.ietf.org/mailman/listinfo/ietf --> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf