[rfc-i] Style Guide and Abstract guidance
"Heather Flanagan (RFC Series Editor)" <rse@rfc-editor.org> Fri, 08 September 2017 15:57 UTC
Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F242A132EF7 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Fri, 8 Sep 2017 08:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfvY7C4AB4vI for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Fri, 8 Sep 2017 08:57:31 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A5F13202D for <rfc-interest-archive-eekabaiReiB1@ietf.org>; Fri, 8 Sep 2017 08:57:31 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id A624AB80C30; Fri, 8 Sep 2017 08:57:23 -0700 (PDT)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id A24A6B80C30 for <rfc-interest@rfc-editor.org>; Fri, 8 Sep 2017 08:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jfkDmrP4Ics for <rfc-interest@rfc-editor.org>; Fri, 8 Sep 2017 08:57:21 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) by rfc-editor.org (Postfix) with ESMTPS id CA03FB80C27 for <rfc-interest@rfc-editor.org>; Fri, 8 Sep 2017 08:57:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 154C51C4A30 for <rfc-interest@rfc-editor.org>; Fri, 8 Sep 2017 08:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-uASR5i263Q for <rfc-interest@rfc-editor.org>; Fri, 8 Sep 2017 08:57:17 -0700 (PDT)
Received: from Heathers-MacBook-Pro.local (c-73-181-135-61.hsd1.wa.comcast.net [73.181.135.61]) by c8a.amsl.com (Postfix) with ESMTPSA id E09781C3F55 for <rfc-interest@rfc-editor.org>; Fri, 8 Sep 2017 08:57:17 -0700 (PDT)
To: rfc-interest@rfc-editor.org
From: "Heather Flanagan (RFC Series Editor)" <rse@rfc-editor.org>
Message-ID: <f029948a-f83a-0fae-8153-f53d7828068f@rfc-editor.org>
Date: Fri, 08 Sep 2017 08:57:28 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Language: en-US
Subject: [rfc-i] Style Guide and Abstract guidance
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: rfc-interest <rfc-interest-bounces@rfc-editor.org>
Hello all, After some discussion with the IESG, I'm proposing a substantive change to the guidance around Abstracts. The goal is to make the Abstract more clear in setting the context of the document. I'd like community feedback before I update the draft. Thoughts? CURRENT: 4.3. Abstract Section Every RFC must have an Abstract that provides a concise and comprehensive overview of the purpose and contents of the entire document, to give a technically knowledgeable reader a general overview of the function of the document. Composing a useful Abstract generally requires thought and care. Usually, an Abstract should begin with a phrase like "This memo ..." or "This document ..." A satisfactory Abstract can often be constructed in part from material within the Introduction section, but an effective Abstract may be shorter, less detailed, and perhaps broader in scope than the Introduction. Simply copying and pasting the first few paragraphs of the Introduction is allowed, but it may result in an Abstract that is both incomplete and redundant. Note also that an Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract. Similarly, the Abstract should be complete in itself. It will appear in isolation in publication announcements and in the online index of RFCs. Therefore, the Abstract must not contain citations. PROPOSED: 4.3. Abstract Section Every RFC must have an Abstract that provides a concise and comprehensive overview of the purpose and contents of the entire document, to give a technically knowledgeable reader a general overview of the function of the document and some context with regards to its relationship (in particular, whether it updates or obsoletes) any other RFCs. In addition to its function in the RFC itself, the Abstract section text will appear in publication announcements and in the online index of RFCs. Composing a useful Abstract generally requires thought and care. Usually, an Abstract should begin with a phrase like "This memo ..." or "This document ..." A satisfactory Abstract can often be constructed in part from material within the Introduction section, but an effective Abstract may be shorter, less detailed, and perhaps broader in scope than the Introduction. Simply copying and pasting the first few paragraphs of the Introduction is allowed, but it may result in an Abstract that is overly long, incomplete, and redundant. An Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract. Similarly, the Abstract should be complete in itself. Given that the Abstract will appear independently in announcements and indices, mentions of other RFCs within the Abstract should include both an RFC number and title. If a short description is clearer than the literal title, it may be included in addition or instead. Any documents that are Updated or Obsoleted by the RFC must be mentioned in the Abstract. These may be presented in a list format if that improves readability _______________________________________________ rfc-interest mailing list rfc-interest@rfc-editor.org https://www.rfc-editor.org/mailman/listinfo/rfc-interest
- [rfc-i] Style Guide and Abstract guidance Heather Flanagan (RFC Series Editor)
- Re: [rfc-i] Style Guide and Abstract guidance Bob Hinden
- Re: [rfc-i] Style Guide and Abstract guidance Carsten Bormann
- Re: [rfc-i] Style Guide and Abstract guidance Brian E Carpenter
- Re: [rfc-i] Style Guide and Abstract guidance Adam Roach
- Re: [rfc-i] Style Guide and Abstract guidance Martin Thomson
- Re: [rfc-i] Style Guide and Abstract guidance Martin J. Dürst
- Re: [rfc-i] Style Guide and Abstract guidance Heather Flanagan (RFC Series Editor)