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

Phillip Hallam-Baker hallam at gmail.com
Mon Aug 20 08:56:43 PDT 2012


I don't see any problem here except wrt subsection identification
which has to be rethunk for section numbers and for page numbers.

There are plenty of other reasons to object to page numbers. They are
not even that useful for printed books as page numbers change from
print edition to print edition. Merging errata into the document
itself should not cause subsection identification to change.

But even section numbers raise an issue as we end up with multiple
section 1s, 2s etc.

I know what RFC 822 Section 1 is, what is STD 42 Section 1? Is there
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.


At least part of the confusion here seems to stem from the (wrong)
notion that there is only one output of the STD series on the Web
site. The whole point of moving away from nroff processing is that the
tools can produce multiple output streams as easily as one. So Martin
can have his plaintext version RFC and the rest of us can read it in
HTML and the lawyers can have PDF/A

As far as the STD series goes, I would suggest a slight modification
to current practice so that the STD items have a standards number and
a standards version associated. That allows people to reference
STD42-03 or STD-02 in the case that it makes a difference. Which it
very often does because a contract or an RFP has to refer to a fixed
document, not a movable feast.


Lawyers are going to Bates number the documents and refer by page
number but that is different as they have a whole infrastructure
already developed to help them identify stuff with precision even when
the parties are less than fully cooperative.




On Mon, Aug 20, 2012 at 10:37 AM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
> On Aug 19, 2012, at 12:01 PM, Michael Richardson <mcr+ietf at sandelman.ca> wrote:
>
>> So, the first part of a BCP would look like a change log (most recent
>> things first), with dates, and then a list of references.
>> (The second part of the BCP would be the concatenation of files, if
>> that was what we wanted to do)
>>
>> (I'm asking for clarification)
>
> My preference would be the first part would be the change log (although more friendly and accessible than most change logs we are familiar with), and the second part be links to the component RFCs. If Heather really is wedded to concatenating raw files instead of linking to them, the second part would be the concatenation.
>
> --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