[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