*>
*> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf