[rfc-i] headers and boilerplates last minute proposal

Joe Touch touch at ISI.EDU
Thu Apr 9 10:00:54 PDT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Leslie Daigle wrote:
> 
> Hi Joe,
> 
> Thanks for the comments, and a question in return:
> 
> My focus with the "upon approval" text below was to get the emphasis off
> "forever" in the -07 text.  That is, the -07 text had words like "from
> now on".
> 
> To get off "forever", we have to talk about the here and now.
> 
> If not "upon approval", or "upon publication", what's a better way to
> capture that?

All RFCs are implicitly "when published, and forever until overridden by
subsequent publications", so restating that repeatedly seems needless.

In standards, we use the present tense (MUST), or imperatives (e.g.,
SHALL). There's no need for that particular language in this doc because
it isn't a standard; the equivalent is just stating the fact or using
lower-case "shall".

IMO, just say "The following text is included" or "shall be included".

Joe



> Joe Touch wrote:
> Some minor suggestions below.
> 
> Joe
> 
> Leslie Daigle wrote:
>>>> Hi,
>>>>
>>>> Coming back to this issue -- consider the following changes (not yet
>>>> implemented in the XML -- apologies for the length of this file, but
>>>> it seemed clearest to keep all context here, and I have in-lined the
>>>> proposed edits using "OLD" and "NEW"):
> ...
>>>>> 3.  RFC Structural Elements
>>>> OLD (-07) TEXT:
>>>> <empty>
>>>>
>>>> NEW TEXT:
>>>>
>>>> This section describes the elements that are commonly found in RFCs
>>>> published today.  For the sake of clarity, this document specifies
>>>> the elements precisely as a specification.  However, this is not
>>>> intended to cast the current format in stone.
> 
> However, this is not intended to specify a single, static format.
> 
>>>> Details of formatting are decided by
>>>> the RFC Editor.  Substantive changes to the header and boilerplate
>>>> structure and content may be undertaken in the future, and are
>>>> subject to general oversight and review by the IAB.
> ...
>>>>> 3.2.  The Status of this Memo
>>>>>
>>>>>    The "Status of This Memo" describes the category of the RFC,
>>>>>    including the distribution statement.  This text is included
>>>>>    irrespective of the source stream of the RFC.
>>>>>
>>>> OLD (-07) text:
>>>>
>>>>>    From now on, the "Status of This Memo" will start with a single
>>>> NEW text:
>>>>
>>>> Upon approval of this document, the "Status of This Memo" will start
>>>> with a single
> 
> The "Status of This Memo" will start...
> 
> (why put in "upon approval"? if not approved, it won't be published as
> an RFC, and the recommendation has no effect unless published anyway.
> Shouldn't 'effect upon publication' be taken as implied in all RFCs?
> 
> This applies throughout, regarding "upon publication", "from now on"
> (which is worse -- when is 'now'?), etc.
> 
> Joe
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkneKcYACgkQE5f5cImnZrt+QwCgvlNUG9ULzeIrERMY4nPo7MKj
d5QAoMfNMdncAn2+uaqR0xfg3/+tOwXy
=TZfY
-----END PGP SIGNATURE-----


More information about the rfc-interest mailing list