[rfc-i] Decisions about non-technical content of RFCs

[Dave CROCKER]

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.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net