[rfc-i] Decisions about non-technical content of RFCs
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
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.
> Dave Crocker
> Brandenburg InternetWorking
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest