One document matched: draft-ash-alt-formats-01.txt
Differences from draft-ash-alt-formats-00.txt
Network Working Group J. Ash
Internet Draft AT&T Labs
Category: Experimental S. Bryant
<draft-ash-alt-formats-01.txt> Cisco Systems
Expiration Date: July 2006 Y(J) Stein
RAD Data Communications
January 2006
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 July 30, 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.00.txt> [Page 1]
Internet Draft Formats in Addition to ASCII Text January 2006
3. Proposed Experiment . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem to be Solved . . . . . . . . . . . . . . . . . . . . . 4
5. Measures to Determine Experiment Success . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . . 7
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property Statement . . . . . . . . . . . . . . . . . 8
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . 8
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . 8
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, RFC 1119, the
PDF/PS versions must accompany the ASCII version of the RFC.
The one exception to this rule, RFC 1119, 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.00.txt> [Page 2]
Internet Draft Formats in Addition to ASCII Text January 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
RFC 2026. 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.
It is proposed that two suitable working groups be identified as
candidates for the experiment, and the agreement of the ADs and WG
chairs sought. This is work in progress. It is proposed that current
and new working group documents, selected by the working group
chairs, be progressed in PDF format and also in ASCII format. The
ASCII format version may be limited to text only and not include
figures, diagrams, or equations.
It is further proposed that a subset of the selected WG documents, as
agreed to by the IESG, be progressed through IESG review and approval
in PDF format and also in ASCII format. The ASCII format version may
be limited to text only and not include figures, diagrams, or
equations.
Finally, it is proposed that a subset of the selected IESG documents,
as agreed to by the RFC Editor, be progressed through the RFC
publication process in PDF format and also in ASCII format. The
ASCII format version may be limited to text only and not include
figures, diagrams, or equations.
Ash, et. al. <draft-ash-alt-formats.00.txt> [Page 3]
Internet Draft Formats in Addition to ASCII Text January 2006
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]:
+-----+ -->
| 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
Ash, et. al. <draft-ash-alt-formats.00.txt> [Page 4]
Internet Draft Formats in Addition to ASCII Text January 2006
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.
b) fixes equations issue:
Complex equations are sometimes difficult to express in ASCII text.
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 don't.
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
Ash, et. al. <draft-ash-alt-formats.00.txt> [Page 5]
Internet Draft Formats in Addition to ASCII Text January 2006
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:
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 don't 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,
Ash, et. al. <draft-ash-alt-formats.00.txt> [Page 6]
Internet Draft Formats in Addition to ASCII Text January 2006
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 Brian Carpenter, Spencer Dawkins, Sam Hartman, and
John Klensin.
8. 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.
[RFC3933] Klensin, J., Dawkins, S., " A Model for IETF Process
Experiments," RFC 3933, November 2004.
9. Informative References
[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
Ash, et. al. <draft-ash-alt-formats.00.txt> [Page 7]
Internet Draft Formats in Addition to ASCII Text January 2006
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
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.00.txt> [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 06:01:37 |