One document matched: draft-ash-alt-formats-00.txt

Network Working Group                                            J. Ash
Internet Draft                                                AT&T Labs
Category: Best Current Practice                               S. Bryant
<draft-ash-alt-formats-00.txt>                            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.          <draft-ash-alt-formats.00.txt>            [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.          <draft-ash-alt-formats.00.txt>            [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.          <draft-ash-alt-formats.00.txt>            [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.          <draft-ash-alt-formats.00.txt>            [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.          <draft-ash-alt-formats.00.txt>            [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.          <draft-ash-alt-formats.00.txt>            [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.          <draft-ash-alt-formats.00.txt>            [Page 7]