Network Working Group J. Ash Internet Draft AT&T Labs Category: Best Current Practice S. Bryant Cisco Systems Expiration Date: June 2006 Y(J) Stein RAD Data Communications December 2005 Proposal for Alternative Formats in Addition to ASCII Text Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 21, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In addition to allowing the basic ASCII text as a normative format, the authors propose that the I-D editor and RFC editor support three other normative input/output formats: a) MS word (input/output), b) XML (input only), and c) PDF (output only). If necessary, other formats can be considered. The IETF tools team will be tasked with producing any format conversion tools needed. Ash, et. al. [Page 1] Internet Draft Formats in Addition to ASCII Text December 2005 Table of Contents 1. Conventions Used in This Document . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Proposal for Process Change . . . . . . . . . . . . . . . . . . 3 4. Justification for Proposal . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . . 6 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property Statement . . . . . . . . . . . . . . . . . 6 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . 7 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . 7 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Background A long discussion took place on the IETF discussion list regarding 'ASCII Art,' starting in November 2005 and beginning at http://www1.ietf.org/mail-archive/web/ietf/current/msg38881.html. A range of opinions were expressed, including these at the one extreme (http://www1.ietf.org/mail-archive/web/ietf/current/msg38875.html): "I find ASCII art diagrams utterly useless and never waste my time on them." http://www1.ietf.org/mail-archive/web/ietf/current/msg38861.html): "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!" and this one at the other extreme (http://www1.ietf.org/mail-archive/web/ietf/current/msg38777.html): "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." Ash, et. al. [Page 2] Internet Draft Formats in Addition to ASCII Text December 2005 It was suggested by many contributors to the thread that formats in addition to ASCII text, such as Word, XML, and others, be permitted as normative text in the IETF for RFCs and BCPs. As usual, some good arguments were made on both sides of the ASCII art issue. This topic, of course, has been discussed many times in the past on the IETF discussion list, and, while the discussion may have been enlightening and entertaining, in the end it did nothing but waste cycles for contributors to the thread. That is, the quite thoughtful, extended, and detailed discussion on the IETF discussion list resulted in no change. On the other hand, this is an important IETF issue that the authors believe should be formally addressed by the IETF as a process change. Regarding how such a process change should be pursued, Sam Hartman stated that (http://www1.ietf.org/mail-archive/web/ietf/current/msg38873.html): "We do have a process for process change. We can approve a BCP using the procedure outlined in RFC 2026. When we can get a strong consensus behind a process change, that procedure works reasonably well. There are other cases where it doesn't work well. Some of us think that's OK; some of us don't." Spencer Dawkins added (http://www1.ietf.org/mail-archive/web/ietf/current/msg38879.html): "And, in addition - the intention for ftp://ftp.rfc-editor.org/in-notes/rfc3933.txt (at least from one of the authors) was that it could be used for process change experiments, so we don't have to debate process change suggestions endlessly as thought exercises before we can try something new." Accordingly, the authors would like to submit this BCP as a proposal for a process change. 3. Proposal for Process Change In addition to allowing the basic ASCII text as a normative format, the authors propose that the I-D editor and RFC editor support three other normative input/output formats: a) MS word (input/output) b) XML (input only) c) PDF (output only) Ash, et. al. [Page 3] Internet Draft Formats in Addition to ASCII Text December 2005 If necessary, other formats can be considered. The IETF tools team will be tasked with producing any format conversion tools needed. When writing in MS word care must be taken to produce text that can be edited by others. In particular, no linked external files are to be used, and no objects created by other programs are to be embedded. If diagrams are inserted that are produced by other programs, they must have originated in gif or jpg format; any changes needed to diagrams are the responsibility of the authors. When submitting a PDF file that was not produced from an ASCII file, MS word, or XML through the standard XML2RFC utility, editable text must be submitted in one of the above formats. The RFC editor will make required changes to this text, but it will be the responsibility of the authors to produce the final PDF copy. Furthermore, the authors propose that the IESG carefully consider declaring consensus in support of the change even if a large number of 'nays' are posted to the IESG discussion list. In that regard, Henrik Levkowetz posted the following comment (http://www1.ietf.org/mail-archive/web/ietf/current/msg39170.html): "Following the debate from the sideline till now, it's clear to me that there are at least a few people who are adamantly against change. I'm not at all convinced that a large majority feels this way. A poll might reveal more than the relative proportions of highly engaged people voicing their views here." Judging consensus through a poll is sometimes difficult. There is a vast "silent majority" that would support the proposed additional formats, or at least not oppose them, but will not express their opinion on the list. It is much more likely to hear from the very vocal people who are opposed to the change. That is, assuming 1000s of participants on the IETF discussion list, perhaps 20 expressed 'nays', even strong nays, could be considered a clear consensus in favor of change. 4. Justification for Proposal The rationale in support of this proposal is as follows: a) fixes diagram issue: Figures are not just "nice to have" additions to text. There are good reasons to include diagrams that would be impossible to use in the ASCII text input environment. For example, the ITU-T has come up with a diagrammatic technique for describing transport networks [G.805, G.809]. Its use is now required in all new work there, and the technique is not just descriptive, it is genuinely useful for catching bugs and as the final word when English language Ash, et. al. [Page 4] Internet Draft Formats in Addition to ASCII Text December 2005 descriptions differ. Graphics provide a language that allows us to abstract and describe concepts in a way that is much clearer (to reader and writer) than is possible in words or crude diagrams. A document must stand by itself and clarity is paramount, which requires the use of the best tools available. Such a technique could not be adopted at the IETF under the present system of ASCII text as the only allowed input format, as there would be no normative method of distributing the diagrams. b) commercially available tools are not optimized for ASCII format When using pure ASCII files, for example, sometimes one cannot print an I-D directly from a browser without lines becoming broken due to the default font being too large, and as a result the text becomes hard to read. Also, printing an ASCII file directly from a word processor sometimes adds a blank page between every two pages and occasionally places the footer on a page by itself. If one attempts to cut and paste an ASCII text into Word, margins can come out wrong, and ASCII tables containing +-+-+- strings become augmented with unprintable characters. Although tools are available to convert ASCII to PDF for printing, these tools raise the question as to why we don't use PDF in the first place. c) other SDOs ahead of IETF on this: The diagrammatic technique discussed under item a), for example, is important to the clarity of the work that the ITU-T is now producing. Also, ITU-T is a major competitor for mind share in many areas of importance to IETF, for example, MPLS, Pseudowire, VoIP etc. d) 'universal' editing format on the Internet: Even though proprietary, Word is probably the most universally used of all document editors. In all likelihood it is the most 'standard' document exchange language on the Internet, and that is probably why most other SDOs use it as their standard format (except IETF). Also, it is likely that the vast majority of IETFers have the ability to read Word and other proprietary format documents, since it is vital that they be able to do that to function well in today's world. In addition, one only need look at the number of PowerPoint presentations at IETF meetings to know that proprietary formats are widely used by IETF participants. In the authors' view, it is also not well justified to reject 'proprietary' formats out of hand: this is not a problem in any other SDO. e) standard format for virtually all other SDOs: Ash, et. al. [Page 5] Internet Draft Formats in Addition to ASCII Text December 2005 The ITU-T, MFA, and many other SDOs all use Word as their standard input and output format for all their official documents. 5. Security Considerations No new security considerations. 6. Acknowledgements 7. Normative References [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3," RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8. Informative References 9. Authors' Addresses Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 Fax: +1-(732)-368-8659 Email: gash@att.com Stewart Bryant Cisco Systems 250, Longwater Green Park Reading, RG2 6GB, United Kingdom Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719, Israel Email: yaakov_s@rad.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information Ash, et. al. [Page 6] Internet Draft Formats in Addition to ASCII Text December 2005 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Ash, et. al. [Page 7]