[rfc-i] Allowing RFC numbers in abstracts

[Eastlake III Donald-LDE008]

Although I make some effort to avoid references in abstracts, trying to make them a self contained summary, I would second continuing to allow RFC numbers in abstracts. I believe such a policy to eliminate them could lose information.

There are many instances of more than one RFC with the identical title, with later versions obsoleting earlier versions, for example RFC 2065 and RFC 2535. While I don't know if there are any examples, it is easy to imagine an RFC that wishes to explicitly refer to an older obsolete version of another RFC, perhaps because it wishes to discuss a bad practice which is exemplified by the obsoleted RFC. Therefore such an apparent new policy could in some cases be confusing and lose information.

Thanks,
Donald

PS: While I'm writing, I'll mention that I have thought for a long time that the current references format is wrong. I'm sure it follows standard guidelines and has been consistent for a long time. But in the IETF context, the prominence it gives to author names is misplaced. Until recently I always put the title first in references because, in the normal case, the title is the single most important and informative thing about the reference. In the IETF, who is the author/editor or authors/editors of a document is not supposed to be a big deal and there are usually many contributors who are, at best, merely listed in an acknowledgements section. The custom of giving prominence to the authors seems likely to have come from academia where credit for documents can be career critical and abuses, such as those having only management oversight being listed with those who did the real work, abound. I don't think it is very likely to happen but I think the IETF references format sho!
 uld be changed to give prominence to the substance of title rather the giving prominence to who happened to be listed as an author.

-----Original Message-----
From: rfc-interest-bounces at rfc-editor.org [mailto:rfc-interest-bounces at rfc-editor.org] On Behalf Of Paul Hoffman
Sent: Tuesday, October 25, 2005 11:00 AM
To: rfc-interest at rfc-editor.org
Subject: [rfc-i] Allowing RFC numbers in abstracts

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