RE: Alternative formats for IDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ted

You are arguing that we have been producing documents for a long time with
only primitive tools and we don't need to make any new tools.  You are
losing that argument.   We are increasing the number, and usefulness of
tools, and most of us appreciate these tools and want more of them.  The
range of useful tools we can produce is related to how much meta-data we put
in the source files.  The more meta-data we put in, the more usefulness we
can get out of the data.  There is very little downside to adding meta-data
as long as it's easy to put in.  For most of these things, we have to do
special formatting, so we are already marking the octets in some way.  

Do you have any idea how painful it is to build any kind of product that has
good management simply because there is no library of MIBs, with references
to documents?  There isn't even a LIST of IETF MIBs.  You can't figure out
if a document has a MIB unless you actually look at the text (although many
have a big hint in the title of the document).  So yes, I believe better MIB
tools would lead to better products, although it would be hard to prove it.

I would like to enable automated testing of ABNF.  I'd like to be able to
cross check the ABNF from one document against its normative references to
see what changes or conflicts.  I'd like to be able to generate a complete
list of SIP error messages a UA may be expected to encounter.  I'd like to
see a lot more hyperlinking of things.  All of these are much easier with
meta-data.

Brian


-----Original Message-----
From: Theodore Ts'o [mailto:tytso@xxxxxxx] 
Sent: Tuesday, January 10, 2006 8:58 AM
To: Brian Rosen
Cc: ietfdbh@xxxxxxxxxxx; 'John C Klensin'; 'Marshall Eubanks'; ietf@xxxxxxxx
Subject: Re: Alternative formats for IDs

On Tue, Jan 10, 2006 at 08:09:10AM -0500, Brian Rosen wrote:
> 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.

True.  So what?  Do you think that it is possible, or even a good
idea, that tools be able to rip out a MIB without reading the rest of
the text?  If so, why the heck do we spend so much time working on a
the human-readable sections, like Security Considerations?

And how much time does it really save to have an automated tool pull
out the MIB, instead of having a human do it?  And what percentage of
the effort does that represent out of the effort to create a product,
anyway?  0.0001%   0.00001%?   

I can usually do it in under a minute with some emacs macros, but I'm
willing to admit that I may be a bit better at it than others.  Other
people could probably do it in a few minutes using sed and awk, or
even (gasp) perl.

						- Ted



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]