[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.
> 
> Proposal:
> 
> - 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.

-Heather








More information about the rfc-interest mailing list