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