IETF Logo Mail Archive

Re: Why the normative form of IETF Standards is ASCII

Martin Rex <mrex@sap.com> Thu, 11 March 2010 17:02 UTC

Return-Path: <mrex@sap.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E9F3A6CAD for <ietf@core3.amsl.com>; Thu, 11 Mar 2010 09:02:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KYs80LHGhkt for <ietf@core3.amsl.com>; Thu, 11 Mar 2010 09:02:23 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D674F3A6C90 for <ietf@ietf.org>; Thu, 11 Mar 2010 08:54:18 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o2BGsM9q006558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Mar 2010 17:54:22 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003111654.o2BGsLPs022287@fs4113.wdf.sap.corp>
Subject: Re: Why the normative form of IETF Standards is ASCII
To: richard@shockey.us
Date: Thu, 11 Mar 2010 17:54:21 +0100
In-Reply-To: <000001cac135$c89bc680$59d35380$@us> from "Richard Shockey" at Mar 11, 10 11:13:26 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2010 17:02:24 -0000

Richard Shockey wrote:
> 
> I do get the arguments in favour of ASCII, though I think there are
> some pretty serious countervailing arguments (like, for instance, that
> we can't spell many contributors' names, to take an easy one).  But
> the RFC format _is not_ plain ASCII.  Just ask anyone whose draft has
> failed the increasingly stringent and lengthy list of IDNits tests due
> to bad pagination in their I-D.


The difficulty to spell contributors' names is a completely ridiculous
reason.  If there is anyone competent to specify how to spell his name
in plain ASCII, then it is the authors and contributors themselves
-- and if they are available at all, then it is during the process
of their contribution and the document creation.


The existing plaintext ASCII format is easy and univerval.  Any more
fancy document formats come with plenty of problems and infinitesimal
close to zero benefit.

Creating, displaying and printing, processing and updating the I-D and RFCs
in the current form was possible 30 years ago, is possible and quite easy 
today (just try NRoffEdit once), and will be possible and easy in
30 years from now.  All other formats will come with a varying number
of problems.

Taking an existing formatted ASCII RFC or I-D (which you did not author
yourself) and putting it back into authoring format is round 1 hour of
work with Nroffedit.

Diffing various revisions of documents is fairly easy with existing tools
e.g.  http://tools.ietf.org/rfcdiff


The problem with basically all of the fancy format is, that none of
your existing tools can cope with it, the possibility to create that
format is often limited to specific platforms, environments or tools.
Diffing with previoius versions of documents is difficult, converting
a "published" document back into authoring format is EXTREMELY diffcult,
the size of the document often grows by factors, and searching and
displaying such documents may require specific new tools and platforms
and be therefore impossible for a number of platforms and environments
where RFCs and I-Ds are currently displayed, searched and processed.


And searching for and comparing characteristics of graphics or
graphical drawings instead of text is a field that needs another
two decades of reasearch. 

It is much better to force an author to spend an hour to express himself
clearly in ASCII text, than forcing several thousands of consumers of
the document to spend several minutes to many hours trying to
understand, process, compare and put into re-authoring some fancy
creations available in a fancy document format.


When I'm implementing a spec, I often quote the relevant spec in
code comments.  Quoting ASCII text is easy.  Having to describe
a fancy drawing of a spec is a lot of work, for each and every
implementor.  Force the document author to come up with that
textual description, and it'll be a big overall saving.


-Martin

v2.23.0 | Report a Bug | By Email