Internet DRAFT - draft-ash-alt-formats


Network Working Group                                            J. Ash
Internet Draft                                                AT&T Labs
Category: Experimental                                        S. Bryant
<draft-ash-alt-formats-02.txt>                            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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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.          <draft-ash-alt-formats-02.txt>            [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",
   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

   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.          <draft-ash-alt-formats-02.txt>            [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

   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

   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.          <draft-ash-alt-formats-02.txt>            [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

   a) XML (input only)
   b) OpenOffice Writer (input only)

   If necessary, other formats can be considered in the phase 2 process

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

Ash, et. al.          <draft-ash-alt-formats-02.txt>            [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
   "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.          <draft-ash-alt-formats-02.txt>            [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

   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.          <draft-ash-alt-formats-02.txt>            [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
   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.          <draft-ash-alt-formats-02.txt>            [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
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1-(732)-420-4578
   Fax:   +1-(732)-368-8659

   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

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any

Ash, et. al.          <draft-ash-alt-formats-02.txt>            [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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.          <draft-ash-alt-formats-02.txt>            [Page 9]