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