On Jun 29, 2009, at 16:22, Phillip Hallam-Baker wrote:
It is not the height of the barrier, it is the perception that
people are making nit-picking objections for the sake of rubbing
people's noses in the fact that they can decide where to put the bar.
In the more traditional publishing milieus of which I'm aware, that
sort of perception is the shibboleth that separates the serious
writers from the unpublishable wankers. Prospective authors who
express a sense of entitlement to the submission of their manuscripts
in formats that don't meet the requirements of the editors who review
them are usually encouraged to start their own publishing outfits and
see if they can do it all better by themselves.
Occasionally, this encouragement is even delivered without the use of
coarse language.
We participants are our own acquisitions editors here, of course, so
the height of the barrier is what we should be thinking about. It
makes sense to me that we should be automating the mechanical
screening of manuscripts coming into the slushpile so that they meet
the machine-scriptable subset of the requirements of the RFC Editor as
closely as possible.
Are there any nitpicks the draft submission service enforces that
aren't really RFC Editor requirements? What are they? Let's fix
those. What I don't want to see is a lot of drafts start piling up
without even coming close to meeting the *mechanical* requirements of
the RFC Editor, much less the more difficult syntax requirements of
the working natural language we've chosen. It won't help anyone if we
allow authors to defer the process of cleaning up the formatting and
boilerplate of a draft until late enough in the review cycle that
major reformatting deltas look to the differencing tools like all-new
content.
If this was about really about quality or readability I would be a
lot more sympathetic. But when a draft is rejected because xml2rfc
produces a txt file that is rejected because some nit-picker does
not quite like the exact TXT format then the whole process is bogus.
For my part, I haven't any serious complaints about the status quo
(plenty of unserious ones, but no serious ones). The process works
well enough for me-- modulo the limitations imposed by our choice of
archival format, and my general complaints about the open usability
issues of XML2RFC on which I mostly agree with EKR, and on which I'm
no more prepared to do anything about than either he or Iljitsch seems
to be.
So long as we are not discussing any proposals to *change* the set of
approved archival formats, I'll continue to be happy-- nay, very
impressed, actually-- with how well XML2RFC meets our needs, despite
the its obvious warts.
If we decide to open another discussion about new archival formats,
then I'll be interested to follow along, but archival formats aren't
on the table here-- at least, I hope not.
-----
Shorter james: I'm far from convinced that changing the draft
submission server to be more lenient is the best way to address the
deficiencies in the software we're using, and I also think that
opening a new discussion about archival formats will mean unleashing a
yet another force-ten maelstrom of controversy that I'd prefer to
observe from a very, very safe distance, i.e. one measured in parsecs.
--
james woodyatt <jhw@xxxxxxxxx>
member of technical staff, communications engineering
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf