[rfc-i] Format for STDs, BCPs, FIYs
paul.hoffman at vpnc.org
Fri Aug 17 07:46:12 PDT 2012
On Aug 17, 2012, at 12:08 AM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
> On 17/08/2012 01:10, Paul Hoffman wrote:
>> On Aug 16, 2012, at 2:37 PM, Heather Flanagan (RFC Series Editor) <rse at rfc-editor.org> wrote:
>>> My first thought is that this is feature request for the RFC Ed website
>>> on how we might logically link associated RFC together, not a request to
>>> consider something new in how individual RFC are formatted. Is that
>> Nope, it affects the references in RFCs as well. For example, RFC 6648 says:
>> Use of this naming convention is not mandated by the Internet
>> Standards Process [BCP9] or IANA registration rules [BCP26].
>> [BCP9] Bradner, S., "The Internet Standards Process -- Revision
>> 3", BCP 9, RFC 2026, October 1996.
>> That reference is wrong. BCP 9 consists of both RFC 2026 *and* RFC 56576, but the latter RFC is not listed. The same problem exists for multi-RFC documents in the BCP and STD series. The Production Center sometimes comes up with creative solutions to this (such as we saw in RFC 6698), but they are sometimes awkward.
> That problem is surely one of maintaining a citation library that contains
> the appropriate concatenation of RFC references for each compound document.
We fully disagree about "surely". If I am reading RFC 6648 and I see a reference to BCP9, I want to be able to read each RFC in BCP9. Some of those RFCs may have been updated by other RFCs. Some of those RFCs may have errata. Pointing to an "appropriate concatenation" solves the problem of some people, but certainly not all.
The problem is also one of format: references to multi-document STDs and BCPs should point to all of the documents in those STDs and BCPs.
> The text concatenations, as at http://www.rfc-editor.org/rfc/bcp/bcp9.txt,
> were created as a pragmatic fix some years ago but are clearly not ideal.
"Not ideal" is correct. It would be better if the BCP "landing page" was simply a list of pointers to the component parts of the BCP, hopefully with pointers to errata as well.
> It is of course for each stream, not the RFC Editor, to decide what types
> of compound document exist in each stream. FYI is now a closed series, and
> the status of STD is dubious since RFC 6410 (which you missed - it is also
> part of BCP9). RFC 1311 really doesn't help matters, either.
At this point, "each stream" is a bit irrelevant because Informational and Experimental RFCs (the two types allowed for non-IETF streams) are always single-part documents.
More information about the rfc-interest