> *> > *> I don't know what needs to be done to make xml2rfc better, but I sure wish the > *> RFC Editor would spend whatever time it takes with the folks who work on > *> xml2rfc to accomplish this. > > As we have announced at several plenary reports (does anyone ever pay > attention??), the RFC Editor has been trying to work with the xml2rfc > fraternity to make xml2rfc into an effective document formatting tool. > It has not been quick or easy. I just checked with one of our editors, > Alice Hagens, who uses xml2rfc regularly. She tells me that she > entered several issues into the xml2rfc tracker, but she does not think > "anyone is looking at it any more." There is unfortunately a > fundamental disconnect: philosophically, the xml2rfc folks don't WANT > it to be an effective markup language, which is essentially what is > needed. Aw, Bob ... that just isn't right. I don't know about the xml2rfc tracker, because I've never seen the beast. But, if you post a note to the mailing list, you get pretty much instant service. Sorry to sound annoyed ... there's been quite a bit of xml2rfc bashing, and much of it has been sadly misinformed. First, this has always been a non-sanctioned, non-approved, volunteer effort. Volunteer 1 was /mtr, but quite a few others joined in. And, as was previously said, the main reason this tool was built was to make our own lives much easier. That said, there has always been a desire to get this stuff to enter the mainstream, and because of that a whole bunch of little tweaks have been entered based on user needs or perceived needs and a fairly robust infrastructure is in place to support authors (e.g., a citation database, a mailing list, interoperable implementations). May I make a suggestion to both the office of the RFC Editor and to the IESG? This sounds like a classic case for leadership. How about starting up a working group? Give it a capable chair, support from the AD (Brian), and twist some arms to get good people to participate. I know this is a radical suggestion, but it just might work. Charter might be: 1. Read the perpetual traffic on this list, look at the w3c method, xml2rfc, word, and others, and see if there is any consensus on a workable track (or tracks) to go forward. Pick the most likely candidate or candidates and work through the functionality issues. 2. Have that track (or tracks) generate a full spec (e.g., in the case of xml2rfc, a revision of the basic RFC) and working code. If there is more than 1 track, ask for comment on the options on the table (no fair comparing an option on the table to a theoretical one that doesn't have with full specs and running code) and then pick one. 3. Additionally, revise 2223bis and turn it into an rfc so our document production process has a normative reference to cite. If we don't trust a working group to come to closure, then have the IESG/IAB name a committee to study the problem and report back a workable path. At least we'd have a real option on the table. This isn't working as a committee-of-the-whole and I'd be perfectly happy to defer to a subset of my colleagues to "solve" the problem. Carl _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf