[rfc-i] headers and boilerplates last minute proposal
touch at ISI.EDU
Thu Apr 9 09:40:46 PDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Some minor suggestions below.
Leslie Daigle wrote:
> 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:
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the rfc-interest