--On Wednesday, 13 March, 2013 03:57 +0000 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
...
Nonetheless I think that John K's suggestion has considerable
merit for I-Ds whose authors are not fluent in written English
(a situation that I agree has surprisingly little to do with
whether the author is a native English speaker.) The reason
is that often it is hard to tell what a document is supposed
to be saying, and the only way to find out is to go back to
the author and ask. This is very slow and time consuming if
each iteration has to go from the editor to the author and
back, If the document has a co-author who's working on it all
along, the rewriting could happen as the document was
developed, leaving only a final check for the copy editor.
To be fair, that wasn't my suggestion. I can't remember who
made it; might have been Hannes. I expressed some skepticism
about it because, as I think I've said then, I've seen it work
sometimes and not others. Put differently, I think it is a very
good idea to have in our kit of tools for dealing with the
problem, but it should not be assumed to always be the best tool
or approach, nor should we assume that the idea of assigned
co-editors will always solve the problem.
--On Tuesday, 12 March, 2013 17:48 -0400 "Carlos M. Martinez"
<carlosm3011(_at_)gmail(_dot_)com> wrote:
Whether the original authors were native English speakers or
not would be immaterial, the document would be flagged when an
otherwise sound document suffers from language issues that
could hinder implementation.
I agree with John L that what needs to be done can usually be
done by a good technical editor (or maybe even a good copy
editor). Linguists not required and possibly not a good idea.
One idea I've started to explore with the RFC Editor is whether
they should be doing document reviews during IETF Last Call (or,
on special request, earlier) in much the same way that IANA
reviews documents for actions they might need to take and
whether those or well-specified. The idea would not be to try
to edit the documents but simply to be able to report back to
the community whether they thought they would be likely to have
trouble editing them (or need extra time and resources). If the
conclusion was "document needs significant work", then the IESG
and WG could figure out how to get that sorted out before
approving the draft.
It is still very much a half- (or quarter-) baked idea. Finding
out during Last Call that a document is in trouble and needs
extra attention is better than finding out at AUTH48, but still
later than one might like. But something like it might be
another tool in the collection.
It would, however, cost resources and might lengthen overall RFC
publication times. I think that is a worthwhile tradeoff in an
increasingly international (even if not yet interplanetary)
community, but others may certainly disagree.
john
john