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

Ole Jacobsen ole at cisco.com
Sat Nov 13 16:06:41 PST 2010

That makes sense to me. I would of course hope that the process is a 
collaborative one, wehre the editor gets to suggest improvements, 
pointers to other work and general "scene setting" which makes the
overall result much more user friendly. That's what I try to do in
my dayjob which is not entirely dissimilar to the subject at hand.

You could call that "style changes" I suppose, even if it involves
content. Im my case I often add more references ("For further 
reading") without (or sometimes with) the author's consent or 
consultation, I've never had a case where the author wasn't happy
with this, but of course the RFC process is more strict and formal
so I could imagine a different tact.

Of course, this all begs the question of what exactly the RSE is
supposed to get engaged in, it's probably naive to expect him/her
to get down to this level of detail, at least on a per document


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: ole at cisco.com  URL: http://www.cisco.com/ipj

On Sun, 14 Nov 2010, Dave CROCKER wrote:

> 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
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list