[rfc-i] Decisions about non-technical content of RFCs
dhc2 at dcrocker.net
Sat Nov 13 14:42:01 PST 2010
On 11/13/2010 9:51 PM, Tony Hansen wrote:
> I can see where the RFC Editor could make recommendations in each and everyone
> of these cases, but they would need to be vetted by the authors/editors of the
> documents in questions. But I don't see a case for the RFC Editor ever doing any
> one of these arbitrarily and without verification.
Or perhaps not at all.
The reference to "technical content" was almost certainly meant to make a
distinction from "editorial" issues, such as grammar and writing style (passive
versus active). Note that the latter is something that the RFC Editor is always
in the middle of, with advice but not authority. Authors retain authority over
the details, but the RFC Editor does an... editing... pass. (I think the actual
authority issue is fuzzier here, since some of the writing style issues get
'advised' rather forcefully...)
We need to find some specific terms that draw a simple line of scope, or perhaps
several lines, for what the RFC Editor does and does not do with a document,
possibly also distinguishing between what the RFC Editor "decides" versus what
it "advises". It decides format. It advises fixes to awkward wording.
I'll test the waters and suggest something simple like "content" versus "style".
The RFC Editor worries about style, not content. Authors control content, with
document attributes like the author list being strictly under their control (or
perhaps the control of the stream approver. But that's a different topic.)
The RFC Editor offers advice about writing style, but has authority over the
format and encoding 'style' of RFCs.
More information about the rfc-interest