[rfc-i] Allowing RFC numbers in abstracts

Allison Mankin mankin at psg.com
Tue Oct 25 08:53:56 PDT 2005


Paul,

In the past we (IESG/plus document shepherds) have always been able to
fix citations of RFCs in the abstract by just removing the brackets.
It seems that anyone who is reading an RFC knows how to find other
RFCs.  Searching a reference by the title rather than by RFC number is
more inconvenient and the titles make the abstract rather verbose.

I agree with your request to go back.

Allison


> 
> Greetings again. There is a new document in the AUTH48 queue that has 
> a significant change from the Internet Draft. In the abstract (but 
> not the rest of the document), the RFC Editor is proposing to remove 
> all RFC numbers and replace them with just the title of the RFC. See 
> the original and proposed changes below.
> 
> There is merit in not having references in the abstract, but removing 
> RFC numbers, particularly those that would be recognized by typical 
> readers of the new RFC, is a loss of useful information. It is fine 
> to have an RFC number that is not a reference (that is, an RFC number 
> that is not in square brackets).
> 
> This appears to be a very new policy; recent RFCs such as RFC 4178 
> have RFC numbers in the abstract. If we want to have RFC titles in 
> the abstract, we should include both the RFC number and the title 
> instead of dropping the RFC number altogether. The new proposed 
> wording below feels both awkward and uninformative.
> 
> Could we go back to allowing RFC numbers in the abstracts?
> 
> 
> The abstract in the Internet Draft:
> 
>     This document describes a mechanism that can be used by FTP clients
>     and servers to implement security and authentication using the TLS
>     protocol defined by [RFC-2246] and the extensions to the FTP protocol
>     defined by [RFC-2228].  It describes the subset of the extensions
>     which are required and the parameters to be used; discusses some of
>     the policy issues that clients and servers will need to take;
>     considers some of the implications of those policies and discusses
>     some expected behaviours of implementations to allow interoperation.
>     This document is intended to provide TLS support for FTP in a similar
>     way to that provided for SMTP in [RFC-2487] and HTTP in [RFC-2817].
> 
>     That this specification is in accordance with the FTP RFC [RFC-959]
>     and relies on the TLS protocol [RFC-2246] and the FTP security
>     extensions [RFC-2228].
> 
> 
> The abstract in the AUTH48 RFC:
> 
>     This document describes a mechanism that can be used by FTP clients
>     and servers to implement security and authentication using the TLS
>     protocol defined by the RFC, "The TLS Protocol Version 1.0.", and the
>     extensions to the FTP protocol defined by the RFC, "FTP Security
>     Extensions".  It describes the subset of the extensions that are
>     required and the parameters to be used, discusses some of the policy
>     issues that clients and servers will need to take, considers some of
>     the implications of those policies, and discusses some expected
>     behaviours of implementations to allow interoperation.  This document
>     is intended to provide TLS support for FTP in a similar way to that
>     provided for SMTP in the RFC, "SMTP Service Extension for Secure SMTP
>     over Transport Layer Security", and the HTTP RFC, "Upgrading to TLS
>     Within HTTP/1.1.".
> 
>     This specification is in accordance with the RFC, "File Transfer
>     Protocol".  It relies on the RFC, "The TLS Protocol Version 1.0.",
>     and the RFC, "FTP Security Extensions".
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://www.rfc-editor.org/mailman/listinfo/rfc-interest


More information about the rfc-interest mailing list