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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Paul
Hoffman
Sent: Tuesday, January 10, 2006 11:15 AM
To: ietf(_at_)ietf(_dot_)org
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf