[rfc-i] Format for STDs, BCPs, FIYs

Phillip Hallam-Baker hallam at gmail.com
Mon Aug 20 10:44:05 PDT 2012

STDs are also tracking documents. Which means that as the document set
that they refer to changes, references within the docs are going to be
made invalid unless there is a disambiguation rule.

For example Digest Auth was originally a separate doc from HTTP/1.0
then the content was merged into the whole. The reverse is even more
common with documents being split when protocols are revised.

This problem regularly crops up in the print world. I have all the
manuals for my car printed in a single volume even though they were
originally four separate publications. In that case the individual
docs retain their original numbering. It works fine.

I don't see a problem with STD42.txt being a cover page followed by a
concatenation of the other files as I have zero intention of reading

STD42.html would in my view be most useful if it was a cover page
giving the history of the specification so that it is not simply links
to the current documents (though those should be listed first). I
would like to see a revision history tracking the dates the STD was
updated so that someone can read the doc and determine what the
standard was at a particular moment in time. That would be easy to
produce from the database and more useful.

On Mon, Aug 20, 2012 at 12:47 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
> On Aug 20, 2012, at 9:38 AM, SM <sm at resistor.net> wrote:
>> At 08:56 20-08-2012, Phillip Hallam-Baker wrote:
>>> I know what RFC 822 Section 1 is, what is STD 42 Section 1? Is there
>> I don't recall that question coming up.
> I brought it up on this list last week. If the RFC Editor provides a single document called std42.txt and it has two sections that are labelled Section 1, there is confusion. Thus, my proposal for the document called std42.txt to not contain the RFCs, just pointers to them.
>>> even a canonical ordering of the individual drafts within an STD? Is
>>> this even possible when a STD revision might legitimately split one
>>> document into two or merge two into one.
>> STD 42 is at http://www.rfc-editor.org/std/std42.txt  There isn't any link to it.
> Ummm, you just gave one to it.
>> I assume that it is an official publication but it is not that official as a RFC is.  A STD is a set of documents.  It does not split one document into two.  It doesn't merge two documents into one unless we go by the concatenation rule.
> Exactly the point.
> --Paul Hoffman
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

Website: http://hallambaker.com/

More information about the rfc-interest mailing list