usefor-usepro-03 February 2005

6.3.  Cancel

   The "cancel" message requests that a target article be "canceled",
   i.e. be withdrawn from circulation or access.


      control-command     =/ Cancel-command
      Cancel-command      = "cancel" Cancel-arguments
      Cancel-arguments    = CFWS msg-id [CFWS]

   The argument identifies the article to be cancelled by its message
   identifier.  The body SHOULD contain an indication of why the
   cancellation was requested. The "cancel" message SHOULD be posted to
   the same newsgroup(s), with the same distribution(s), as the article
   it is attempting to cancel.

   A serving agent that elects to honour a "cancel" message SHOULD make
   the article unavailable for relaying or serving (perhaps by deleting
   it completely). If the target article is unavailable, and the
   acceptability of the "cancel" message cannot be established without
   it, activation of the "cancel" message SHOULD be delayed until the
   target article has been seen.  See also sections 7.3 and 7.4.

        NOTE: It is expected that the security extension envisaged in
        section 6.1 will make more detailed provisions for establishing
        whether honouring a particular "cancel" message is in order. In
        particular, it is likely that there will be provision for the
        digital signature of 3rd party cancels (i.e. those issued other
        than by the sender, the moderator, or the injector).

        NOTE: A cancel submitted by the poster for an article in a
        moderated group will be forwarded to the moderator of that
        group, and it is up to that moderator to act upon it (7.8).

        NOTE: The former requirement [RFC 1036] that the From and/or
        Sender headers of the "cancel" message should match those of the
        original article has been removed from this standard, since it
        only encouraged cancel issuers to conceal their true identity,
        and it was not usually checked or enforced by canceling
        software.  Therefore, both the From and/or Sender headers and
        any Approved header should now relate to the entity responsible
        for issuing the "cancel" message.

--- ../usefor-usepro-02/Cancel.out          December 2004
+++ ../usefor-usepro-03/Cancel.out          February 2005
@@ -1,29 +1,29 @@
 6.3.  Cancel
 
-   The cancel message requests that a target article be "canceled", i.e.
-   be withdrawn from circulation or access.
+   The "cancel" message requests that a target article be "canceled",
+   i.e. be withdrawn from circulation or access.
 
 
-      control-message     =/ Cancel-message
-      Cancel-message      = "cancel" Cancel-arguments
+      control-command     =/ Cancel-command
+      Cancel-command      = "cancel" Cancel-arguments
       Cancel-arguments    = CFWS msg-id [CFWS]
 
    The argument identifies the article to be cancelled by its message
    identifier.  The body SHOULD contain an indication of why the
-   cancellation was requested. The cancel message SHOULD be posted to
-   the same newsgroup, with the same distribution, as the article it is
-   attempting to cancel.
+   cancellation was requested. The "cancel" message SHOULD be posted to
+   the same newsgroup(s), with the same distribution(s), as the article
+   it is attempting to cancel.
 
-   A serving agent that elects to honour a cancel message SHOULD make
+   A serving agent that elects to honour a "cancel" message SHOULD make
    the article unavailable for relaying or serving (perhaps by deleting
    it completely). If the target article is unavailable, and the
-   acceptability of the cancel message cannot be established without it,
-   activation of the cancel message SHOULD be delayed until the target
-   article has been seen.  See also sections 7.3 and 7.4.
+   acceptability of the "cancel" message cannot be established without
+   it, activation of the "cancel" message SHOULD be delayed until the
+   target article has been seen.  See also sections 7.3 and 7.4.
 
         NOTE: It is expected that the security extension envisaged in
         section 6.1 will make more detailed provisions for establishing
-        whether honouring a particular cancel message is in order. In
+        whether honouring a particular "cancel" message is in order. In
         particular, it is likely that there will be provision for the
         digital signature of 3rd party cancels (i.e. those issued other
         than by the sender, the moderator, or the injector).
@@ -33,11 +33,11 @@
         group, and it is up to that moderator to act upon it (7.8).
 
         NOTE: The former requirement [RFC 1036] that the From and/or
-        Sender-headers of the cancel message should match those of the
+        Sender headers of the "cancel" message should match those of the
         original article has been removed from this standard, since it
         only encouraged cancel issuers to conceal their true identity,
         and it was not usually checked or enforced by canceling
-        software.  Therefore, both the From and/or Sender-headers and
-        any Approved-header should now relate to the entity responsible
-        for issuing the cancel message.
+        software.  Therefore, both the From and/or Sender headers and
+        any Approved header should now relate to the entity responsible
+        for issuing the "cancel" message.