usefor-usepro-03 February 2005

6.  Control Messages

   The following sections document the control messages.  "Message" is
   used herein as a synonym for "article" unless context indicates
   otherwise.

   Each <control-command> comprises a <verb>, which indicates the action
   to be taken, and <argument>(s), which supply the details (see F-
   3.2.4).  The following sections contain syntactic definitions for the
   <verb>, <argument>s, and possibly the body, for each type of control
   message.
[The term <control-command> is now used to denote the syntactic object
within the Control header, to distinguish it from "control message",
which refers to the whole article.]

   The Newsgroups header of each control message SHOULD include the
   <newsgroup-name>(s) for the group(s) affected (i.e. groups to be
   created, modified or removed, or containing articles to be canceled).
   This is to ensure that the message propagates to all sites which
   receive (or would receive) that group(s). It MAY include other
   <newsgroup-name>s so as to improve propagation (but this practice may
   cause the control message to propagate also to places where it is
   unwanted, or even cause it not to propagate where it should, so it
   should not be used without good reason).

        NOTE: Propagation is controlled by relaying agents, and it may
        be necessary for relaying agents to take special steps to ensure
        that control messages such as newgroup messages for not-yet-
        existent newsgroups are propagated correctly (see 7.3).

   The presence of a Subject header whose content starts with the string
   "cmsg " followed by a <control-command> was construed under [RFC
   1036] as a request to perform that control action (even if no genuine
   Control header was present). Indeed, some implementations went
   further and added the implied Control header before injecting.
   Likewise, the presence of a <newsgroup-name> ending in ".ctl" in the
   Newsgroups header caused the Subject header content (not starting
   with "cmsg" in this case) to be interpreted as a <control-command>.

   All these practices are now declared to be Obsolete, and Subject
   headers MUST NOT now be interpreted as <control-command>s under any
   circumstances.

   The descriptions below set out REQUIREMENTS to be followed by sites
   that receive control messages and choose to honour them. However,
   nothing in these descriptions should be taken as overriding the right
   of any such site, in accordance with its local policy, to refuse to
   honour any particular control message, or to refer it to an
   administrator for approval (either as a class or on a case-by-case
   basis).

--- ../usefor-usepro-02/Control_Messages.out          December 2004
+++ ../usefor-usepro-03/Control_Messages.out          February 2005
@@ -4,18 +4,21 @@
    used herein as a synonym for "article" unless context indicates
    otherwise.
 
-   Each control message comprises a verb, which indicates the action to
-   be taken, and argument(s), which supply the details. In some cases
-   the body of the article may also supply details. The following
-   sections contain syntactic definitions for the verb, arguments, and
-   possibly the body, for each type of control message.
+   Each <control-command> comprises a <verb>, which indicates the action
+   to be taken, and <argument>(s), which supply the details (see F-
+   3.2.4).  The following sections contain syntactic definitions for the
+   <verb>, <argument>s, and possibly the body, for each type of control
+   message.
+[The term <control-command> is now used to denote the syntactic object
+within the Control header, to distinguish it from "control message",
+which refers to the whole article.]
 
-   The Newsgroups-header of each control message SHOULD include the
-   newsgroup-name(s) for the group(s) affected (i.e. groups to be
+   The Newsgroups header of each control message SHOULD include the
+   <newsgroup-name>(s) for the group(s) affected (i.e. groups to be
    created, modified or removed, or containing articles to be canceled).
    This is to ensure that the message propagates to all sites which
    receive (or would receive) that group(s). It MAY include other
-   newsgroup-names so as to improve propagation (but this practice may
+   <newsgroup-name>s so as to improve propagation (but this practice may
    cause the control message to propagate also to places where it is
    unwanted, or even cause it not to propagate where it should, so it
    should not be used without good reason).
@@ -24,21 +27,18 @@
         be necessary for relaying agents to take special steps to ensure
         that control messages such as newgroup messages for not-yet-
         existent newsgroups are propagated correctly (see 7.3).
-[The first of those paragraphs was originally scheduled to be moved to
-USEFOR (and it may yet be so moved). It has been reinstated here (at
-least temporarily) to make sure that it does not get overlooked.]
 
-   The presence of a Subject-content starting with the string "cmsg "
-   and followed by a <control-message> was construed under [RFC 1036] as
-   a request to perform that control action (even if no genuine Control
-   header was present). Indeed, some implementations went further and
-   added the implied Control header before injecting. Likewise, the
-   presence of a newsgroup-name ending in ".ctl" in the Newsgroups
-   header caused the Subject header content (not starting with "cmsg" in
-   this case) to be interpreted as a <control-message>.
+   The presence of a Subject header whose content starts with the string
+   "cmsg " followed by a <control-command> was construed under [RFC
+   1036] as a request to perform that control action (even if no genuine
+   Control header was present). Indeed, some implementations went
+   further and added the implied Control header before injecting.
+   Likewise, the presence of a <newsgroup-name> ending in ".ctl" in the
+   Newsgroups header caused the Subject header content (not starting
+   with "cmsg" in this case) to be interpreted as a <control-command>.
 
    All these practices are now declared to be Obsolete, and Subject
-   headers MUST NOT now be interpreted as <control-message>s under any
+   headers MUST NOT now be interpreted as <control-command>s under any
    circumstances.
 
    The descriptions below set out REQUIREMENTS to be followed by sites