[rfc-i] Re: request to deprecate numeric citations in ...

Bruce Lilly blilly at erols.com
Mon Jan 17 11:42:08 PST 2005


In rfc-interest Digest, Vol 11, Issue 4:
>  Date: 2005-01-12 23:05
>  From: John C Klensin <john+rfc at jck.com>
>  To: rfc-interest at rfc-editor.org

> Although I've used numeric citations, I favor this change.
> However, I would encourage folks to think through two
> potentially unintended consequences:
> 
> (1) What converted me to numeric citations was the realization
> that there was no way to alphabetize mnemonic/text references if
> the references section itself was divided into two parts.

Indeed. From another perspective (writing nroff macros to
handle references),  it's easy, almost trivial, to be able
to automatically generate numerical reference numbers, even
if they're divided into N.1, N.2..., I.1, I.2... groupings.

Given the following three types of references:

1. numeric, possibly divided into groups, numbered per
   order of appearance in the text body
2. generic, presented in the index per order of
   appearance in the text body
3. generic, presented in the reference lists collated (i.e.
   without regard to order of appearance in the text body)

references of types 1 & 2 are fairly easy to generate automatically,
with #1 being somewhat easier (the length of the reference can
be guessed, and that affects hanging indents in the reference
section; with arbitrary strings, either they have to be collected
and measured to obtain a uniform hanging indent, or it requires
some manual massaging). References of type 3 definitely require
manual massaging or rather complicated processing.  So there's
something to be said in favor of numeric references.

> Now, one might use
>     Normative references
>     [N.Bozo95] ...
>     [N.Clar97] ...
>     Informative references
>     [I.Rudo04]...
> but I don't think I've ever seen it in an RFC [...]

See Keith Moore's RFC 3834.

> (2) More generally, the names that are needed to make public
> entities unique are fairly nasty for symbolic references.
> [RFC9999] is fine, but [I-D.ietf-bozo-foo-bar-content] is fairly
> unpleasant.

Two editorial issues regarding non-numeric references:
1. [RFC9999] is OK as such, but some RFCs are also BCP, STD or FYI
   documents. For consistency, it would help authors to know how
   the RFC Editor prefers these to be indicated.  E.g. [BCP18]
   vs. [RFC2277].  This also relates to John's draft regarding
   BCP etc., draft-klensin-newtrk-std-repurposing-00.
2. For internet drafts, I would use something like an Author-Date
   reference, e.g. [Crocker04] to refer to draft-crocker-email-arch-01.

Regarding drafts in particular, while URL references are discouraged
because they might not be stable, in theory at least the RFC Editor
maintains I-D files, substituting a "tombstone" file when a draft is
published as an RFC or is abandoned. So reference to the detailed
file name might be possible via a URI pointing to the draft file
name in the reference text as opposed to trying to wedge it into
the reference string itself.  For such purposes, though, a symbolic
link from a name w/o the version number to the latest version would
be a convenience (the tombstone file usually has a version suffix
greater than the highest draft version).


More information about the rfc-interest mailing list