[rfc-i] Why should the RFC Style Guide be an RFC?
Heather Flanagan (RFC Series Editor)
rse at rfc-editor.org
Mon Mar 24 07:58:40 PDT 2014
(Sorry for the delay in response; comments below.
On 3/11/14, 5:05 PM, Paul Hoffman wrote:
> Greetings again. The RFC Style Guide is in IETF Last Call, and this is a very good time to ask: why should this be an RFC at all? In the introduction to the current draft, it says:
> The RFC Editor also maintains a web portion of the Style Guide (see
> Appendix A) that describes issues as they are raised and indicates
> how the RFC Editor intends to address them. As new style issues
> arise, the RFC Editor will first address them on the web portion of
> the Style Guide [StyleWeb]. These may become part of the RFC Style
> Guide when it is revised.
> There is much more in Appendix A.3 about the likelihood that the RFC will become outdated and then updated on the web page.
> Thus this is meant to be an RFC that we *know* will be modified on a web page.
> - Finish IETF Last Call on draft-iab-styleguide-01.
> - The RSE creates a web page that is the contents of draft-iab-styleguide-01 at an easy-to-find URL. The page can be formatted like an real web page, without fixed-width lines. It should probably keep the references at the end. It's fine to either include the abbreviation list in the same page or on a linked page. It is also fine to include or just link to the "Publication Process" document.
> - The RSE creates a very short document along the lines of RFC 6722 that points to the new web site. This gets published as an RFC.
> There is no good reason to have a split-brain style guide as an RFC and a web page, and there is not good reason not to use the web for letting RFC authors know what will happen to their document during RFC publishing.
Actually, I think there are very good reasons to split things this way,
with an RFC capturing the stable rules and a web page to capture
guidance that needs to be tested against the reality of more than one
RFC. Reasons including eating our own dog food, the community review
process, and a certain mindfulness for making changes. I do not see
this type of split any more difficult than reading an RFC and then
looking at errata for more detail on how to implement the RFC properly.
More information about the rfc-interest