RE: Alternative formats for IDs

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

 



I'd mostly agree if this was a one off, but it's not; it requires continuous
effort to maintain.  My experience that manual is usually cheapest if it
only has to be done once, and automation is cheapest if it has to be
continuously maintained.  YMMV.

Most of the harvesting of sections of things that are now text that could be
harvested apply to RFCs and not IDs, but things like ABNF checking and even
MIB checking could be part of ID nits.  Hyperlinks apply to both.

There are many ways to put meta-data in files, but I'd rather not invent a
new one.  xml is just fine, thank you.  And we have a nice tool that puts
out text and html, and with a small amount of effort, PDF from xml.  Our
reluctance to use it is mostly:
	The RFC editor has some problems which have not, to my knowledge,
been	enumerated.

	There are currently other ways to produce ASCII output that people
are
	reluctant to give up on.

I suspect we can fix the former.  The question is whether the usefulness of
the harvesting and alternative outputs outweighs the latter, assuming we
accept ASCII output as required and normative.

Brian


-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Paul
Hoffman
Sent: Tuesday, January 10, 2006 11:15 AM
To: ietf@xxxxxxxx
Subject: RE: Alternative formats for IDs

At 9:45 AM -0500 1/10/06, Brian Rosen wrote:
>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.

Why does this need to be done in the RFCs or Internet Drafts 
themselves? Why, for example, can't a human with a bit of training 
extract all the MIBs from the current RFCs and put them into a 
repository that is machine-accessible? Doing so would probably take 
less time than writing the tool to make human-readable RFCs also 
machine-readable.

As for Internet Drafts (if we really want people implementing from 
Internet Drafts), it is trivial to create a convention that says "if 
you want the MIB in your draft to be machine-readable, copy the MIB 
to a public web server and, in the draft, put on a line by itself: 
THE-MIB-IS-AT <url>". No changes are needed to any input or output 
tools, yet the problem of finding MIBs is solved.

>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.

Sure. If any of those features came free or very cheap, that would be 
great. None of them do, particularly when you factor in the 
design-by-entire-IETF-mailing-list work factor. Instead, a bit of 
human interaction is much less expensive.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________

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



_______________________________________________

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]