[rfc-i] Allowing RFC numbers in abstracts

[Paul Hoffman]

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