It's trivial for a human, but not for a computer.
Many things trivial for humans are not trivial for computers.
The kind of harvesting you are talking about is trivial for a human from any
format as long as your editor can paste while losing formatting.
What we are seeing is increasing use of fully automated tools that don't
have humans identifying which octets are MIB and which are code. You can't
do that with plain ASCII.
Your statement that the IETF is getting populated with people who don't code
is true. It's a fact, and we need to adapt. Most (but not all) of the
people who design protocols these days don't code; they have people who work
with them who do. Part of that is unavoidable. The part I regret, which
could be avoided, is the loss of "running code" that we used to care about.
From: Theodore Ts'o [mailto:tytso(_at_)mit(_dot_)edu]
Sent: Monday, January 09, 2006 11:37 PM
To: Brian Rosen
Cc: ietfdbh(_at_)comcast(_dot_)net; 'John C Klensin'; 'Marshall Eubanks';
Subject: Re: Alternative formats for IDs
On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote:
Any format can be used for any purpose, but it might be time to fully
up to requirements to harvest data, and to recognize (as I did on another
side thread), that reading is getting harder and harder for ASCII. It may
be a decent archive format still, but I'm not sure it's going to stay that
Huh? "Harvesting data" from ASCII, in terms of pulling out MIB's to
be fed into MIB compiler, or reference C code for algorithms like MD5
(RFC 1321) is *trivial* under ASCII. Last I checked, C compilers and
MIB compilers still use ASCII text as input, and not Word documents or
XML documents. Maybe part of what is going on is that IETF is getting
populated with people who aren't close to coding as much as before?
You can get perfectly decent text editors for all operating systems,
And even Word can import text (i.e., plain ASCII) documents Just Fine.
Ietf mailing list