Two different threads (was: More liberal draft formatting standards required)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]