Network Working Group J. Ash Internet Draft AT&T Labs Category: Experimental S. Bryant Cisco Systems Expiration Date: November 2006 Y(J) Stein RAD Data Communications May, 2000 Proposed Experiment: Normative Format 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 November 24, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Following RFC 3933, the authors propose an experiment allowing, in addition to ASCII text as a normative input/output format, PDF as an additional normative output format. Table of Contents 1. Conventions Used in This Document . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Ash, et. al. [Page 1] Internet Draft Formats in Addition to ASCII Text May 2006 3. Proposed Experiment . . . . . . . . . . . . . . . . . . . . . . 3 4. Problem to be Solved . . . . . . . . . . . . . . . . . . . . . 4 5. Measures to Determine Experiment Success . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . . 8 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property Statement . . . . . . . . . . . . . . . . . 8 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . 9 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . 9 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 Currently, ASCII text is the only allowed normative input and output format for Internet Drafts and RFCs. While PDF and Postscript are permitted as output formats, only the ASCII text documents can be normative, and must be available. Problems with using ASCII text as the only normative format have been pointed out and discussed innumerable times. The most prominent among the identified problems are use of 'ASCII art' instead of clearer diagrams, and difficulty in expressing mathematical equations. The problem of providing better illustrations and mathematical equations has been faced in the past, and responded with a PDF and/or PS version, but in every case except one, [RFC1119], the PDF/PS versions must accompany the ASCII version of the RFC. The one exception to this rule, [RFC1119], which is only available in PDF and Postscript, and not ASCII text, owing to the complexity of the equations contained therein. However, this is generally not allowed for RFCs. The most recent discussion on ASCII art took place on the IETF discussion list starting in November 2005 and beginning at http://www1.ietf.org/mail-archive/web/ietf/current/msg38881.html. A considerable number of opinions were expressed ranging from those who found ASCII art was too difficult to use to show anything other than a non-trivial diagram, through to those who thought that the restrictions of ASCII performed a useful purpose in requiring that authors simplify their work. There was also considerable debate on the relative merits and costs of tools, archive formats, etc., ranging from support for ASCII as a lowest common denominator to support for moving to the more modern tool suits used by other SDOs. Ash, et. al. [Page 2] Internet Draft Formats in Addition to ASCII Text May 2006 Good arguments were made on both sides of the ASCII art issue. This topic, has been discussed many times in the past on the IETF discussion list, and, while the discussion may have been enlightening and entertaining, it achieved little and resulted in no change from status quo. That is, the quite thoughtful, extended, and detailed discussion on the IETF discussion list resulted in no change. It was suggested by several contributors to the thread that formats in addition to ASCII text be permitted as normative text in the IETF for RFCs and BCPs. The authors believe that this is an important IETF issue that should be formally addressed by the IETF as a process change. Regarding how such a process change should be pursued, it was stated that we could try to approve a BCP using the procedure outlined in [RFC2026]. Another suggestion was that RFC 3933 [RFC3933] could be used for process change experiments. Accordingly, the authors propose to do an experiment following RFC 3933 as a gateway to process change. 3. Proposed Experiment Following RFC 3933, the authors propose an experiment allowing, in addition to ASCII text as a normative input/output format, PDF as an additional normative output format. The "sunset" timeout for the experiment is one year after adoption. The Network Time Protocol (NTP) working group and the Routing Working Group (RTGWG) have been identified to conduct the experiment. The following working group documents are to be progressed in PDF format and also in ASCII format: NTP Working Group: [NTP-ALGORITHM] Routing Working Group: [U-TURN] ASCII format version may be limited to text only and not include figures, diagrams, or equations. These documents will be progressed through WG review, IESG review, and RFC Editor review and approval. The method to progress the PDF format version is as specified in [RFC2223bis]: When the .pdf version is submitted with the .txt version, the RFC Editor will first edit the .txt version. The final form of the .txt version (or, when feasible, the diffs) will be returned to the author. The author must then update the .pdf files to match, as closely as possible, the content and format of the ASCII .txt file. Ash, et. al. [Page 3] Internet Draft Formats in Addition to ASCII Text May 2006 When the RFC Editor agrees that the .pdf version is acceptable, it is published simultaneously with the .txt version. We propose that a 'phase 2' process experiment be undertaken where, in addition to allowing the basic ASCII text as a normative input/output format, and PDF as a normative output format, that the I-D editor and RFC editor support other normative input formats, for example: a) XML (input only) b) OpenOffice Writer (input only) If necessary, other formats can be considered in the phase 2 process experiment. 4. Problem to be Solved The rationale in support of this proposed experiment as a gateway to process change 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 design, catching bugs and as the final word when English language descriptions differ. Some argue that ASCII art diagrams are sufficient, for example [U-TURN]: Ash, et. al. [Page 4] Internet Draft Formats in Addition to ASCII Text May 2006 +-----+ --> | N_4 |------ <--- +-----+ +-----+ | |-----| R_3 | | 15 | | 5 +-----+ |50 | | | +-----+ ---> | +-----+ | 70 | N_2 |------ | | N_3 | | +-----+ | | +-----+ | | 15 | | | 30 | | 10 | +-----+ <--- | | @ | ----| S |--------| | @ | <@@@ +-----+ | V | | | | | 10 | | | +-----+ | V | | R_2 | +-----+ | +-----+ | E | | | | +-----+ | | | 40 | | | V | 10 | | | | +-----+ | V | -----| R_1 |-----| | +-----+ | | ---> +-----+ | |------------------| D |--------- 10 +-----+ E is primary next-hop of S N_2 and N_3 are U-Turn Neighbors of S N_4 is a Looping Neighbor of S Regarding such diagrams, Bob Braden (RFC Editor) commented http://www1.ietf.org/mail-archive/web/ietf/current/msg39909.html: "the ASCII art diagrams could really use a cleanup. They are unnecessarily ugly, kind of dyslexic." For those who are able to read the .pdf version of this draft we provide a line graphic version for comparison: (see .pdf version for this figure) 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. Ash, et. al. [Page 5] Internet Draft Formats in Addition to ASCII Text May 2006 b) fixes equations issue: Complex equations are sometimes difficult to express in ASCII text. This issue has been recognized for a long time, see for example [RFC1003]. Allowing PDF as a normative format allows complex equations to be clearly expressed. Some argue that reading 'linearized formulas' in ASCII is sufficient, for example [U-TURN]: D_opt(N_i, D) < D_opt(N_i, S) + D_opt(S, D) min_for all j in J (D_!N_i(R_i,j, D) - D_opt(R_i_j, S)) A shortest path from R_i_j to D is via N_i and thus S. Therefore, D_!N_i(R_i_j, D) >= D_opt(R_i_j, D). A shortest path from R_i_j to D is not via N_i. Therefore, D_!N_i(R_i_j, D) = D_opt(R_i_j, D). However, if linearized formulas were sufficient, mathematicians would generally use them, but they do not. Another format for equations, which is essentially ASCII art, is illustrated here: 2 3 2 2 3 3 w w x (w k + w ) x (3 w k + w ) x (D7)/T/ -- + --- - -------------- - ---------------- + . . . 4 3 4 3 k k 6 k 6 k Such a format would be difficult to use in general, and lacks generality. Common mathematical symbols, such as summation and integral signs, are unavailable in ASCII. For those who are able to read the .pdf version of this draft, we provide an example for comparison: (see .pdf version for these figures) Translation of complex mathematical formulas to ASCII representation should surely be the final step in implementation, not something imposed during the understanding and description phase. In one instance, mathematical formulas were sufficiently complex [RFC1119] that an exception was made, and the document is only available in PDF/Postscript, and not in the usual ASCII format. c) commercially available tools are not optimized for ASCII format: Ash, et. al. [Page 6] Internet Draft Formats in Addition to ASCII Text May 2006 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 can 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 do not use PDF in the first place. 5. Measures to Determine Experiment Success Success will be judged as follows: a) consensus of the selected WGs as to the effectiveness of progressing documents in PDF and ASCII formats through these working groups. b) consensus of the IESG as to the effectiveness of progressing documents in PDF and ASCII formats through the IESG. c) consensus of the RFC Editor as to the effectiveness of progressing documents in PDF and ASCII formats through the RFC publication process. d) consensus of the IETF as to the effectiveness of progressing documents in PDF and ASCII formats through the entire ID to RFC publication process. Particular criteria to be applied in judging 'effectiveness' could include, but are not limited to: a) clarity of documents, particularly with respect to figures, diagrams, and equations, b) ease of drafting, editing, and modifying documents, c) ease of reading documents, d) ... 6. Security Considerations No new security considerations. 7. Acknowledgements The authors sincerely appreciate the guidance and constructive suggestions from Jari Arkko, Brian Carpenter, Spencer Dawkins, Bill Fenner, Brian Haberman, Sam Hartman, and John Klensin. 8. Normative References [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3," RFC 2026, October 1996. Ash, et. al. [Page 7] Internet Draft Formats in Addition to ASCII Text May 2006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3933] Klensin, J., Dawkins, S., "A Model for IETF Process Experiments," RFC 3933, November 2004. 9. Informative References [NTP-ALGORITHM] Kasch, W., et. al., "The Network Time Protocol Version 4 Algorithm Specification," work in progress. [RFC1119] "Network Time Protocol (Version 2) Specification and Implementation," only available in PostScript in file RFC1119.PS. [RFC1003] Katz, A., "Issues in Defining an Equations Representation Standard," March 1987. [RFC2223bis] Reynolds, J., Braden, R., "Instructions to Request for Comments (RFC) Authors, work in progress. [U-TURN] Atlas, A., et. al., "U-turn Alternates for IP/LDP Fast-Reroute," work in progress. 10. 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 Ash, et. al. [Page 8] Internet Draft Formats in Addition to ASCII Text May 2006 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 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 (2006). 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 9]