Re: More liberal draft formatting standards required

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(_at_)apple(_dot_)com>
member of technical staff, communications engineering

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf