[rfc-i] Format for STDs, BCPs, FIYs
Brian E Carpenter
brian.e.carpenter at gmail.com
Fri Aug 17 09:43:31 PDT 2012
On 17/08/2012 15:46, Paul Hoffman wrote:
> 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.
I think my text is ambiguous. What I mean is that I would like to see this
in the References:
[BCP9] Bradner ... RFC2026, October 1996;
Dusseault ... RFC 5657, September 2009;
Housley ... RFC 6410, October 2011.
> 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.
That works nicely in HTML space but not so much in plain text space,
and the current fix was invented for the plain text world.
I don't know when it started; the line of text stating that the file
is a concatenation was added at my request in August 2006.
>> 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.
True, but the nature and purpose of the compound documents that we have
> --Paul Hoffman
More information about the rfc-interest