Dear colleagues, Before the substantive points of the original post get buried under counter-arguments against some _other_ point, I just want to make sure we're all talking about the same things. There are, in my reading, two completely different points in Iljitsch's original post: 1. The recent boilerplate/process-change events have resulted in a situation where the most-recommended tool for preparing IETF documents does not work at all in its stable version. If you want to prepare IETF documents you have to use a tool explicitly labelled as bleeding-edge software. That it works at all is a testament to those working on the tool, but the facts are that the tool isn't well-documented at the best of times and that this beta version produces completely cryptic error messages that wouldn't help most users unless they are perverse enough to keep their TCL skills sharp. Some argument in this thread has been about the preparation tools and whether we are creating needless barriers here. This point was not reflected in the original Subject: line, alas, but was an important component of its argument. 2. The current format of IETF documents appears to be designed to accommodate the vagaries of a peculiar historical line printer arrangement, and it is not flexible enough to be a useful format in several perfectly normal contexts for readers today. The formatting conventions are also basically page-oriented, and in an age when a large number of readers do not print the documents out on paper that seems to be a serious missing feature -- particularly when page sizes are not universal within the community of document producers and consumers we claim to be trying to serve. Some argument has been about the output format and whether it is the right one for the IETF. This topic has indeed been debated before (and I think those suggesting that the previous inconclusive results might be relevant to the discussion have a point). You could easily think that there's nothing wrong with the current archival format, and still object to the primary recommended tool being in the state it is in the period leading up to a -00 deadline (please note that this is not an attack on the tool makers, but rather an observation about how the process and the supporting infrastructure may have diverged); by the same token, you might think xml2rfc is the bees' knees and have managed to get it working bug-free on your jailbroken iphone, and still think that the document format as such is the wrong way to be working. Let us not conflate these two issues, please. Best regards, A -- Andrew Sullivan ajs@xxxxxxxxxxxx Shinkuro, Inc. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf