usefor-article-06 November 2001

7.3.  Cancel

   The cancel message requests that a target article be "canceled" i.e.
   be withdrawn from circulation or access. A cancel message may be
   issued in the following circumstances.

   1. The poster of an article (or, more specifically, any entity
      mentioned in the From header or the Sender header, whether or not
      that entity was the actual poster) is always entitled to issue a
      cancel message for that article, and serving agents SHOULD honour
      such requests. Posting agents SHOULD facilitate the issuing of
      cancel messages by posters fulfilling these criteria.

   2. The agent which injected the article onto the network (more
      specifically, the entity identified by the path-identity in front
      of the leftmost '%' delimeter in the Path header (5.6) or in the
      Injector-Info header (6.19) and, where appropriate, the moderator
      (more specifically, any entity mentioned in the Approved header)
      is always entitled to issue a cancel message for that article, and
      serving agents SHOULD honour such requests.

   3. Other entities MAY be entitled to issue a cancel message for that
      article, in circumstances where established policy for any
      hierarchy or group in the Newsgroup header, or established custom
      within Usenet, so allows (such policies and customs are not
      defined by this standard). Such cancel messages MUST include an
      Approved header identifying the responsible entity. Serving agents
      MAY honour such requests, but SHOULD first take steps to verify
      their appropriateness.


      cancel-verb         = "cancel"
      cancel-arguments    = CFWS message-id

   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.

   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 8.3 and 8.4.

        NOTE: It is expected that the security extension envisaged in
        section 7.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.

        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.
[Do we want to review that now in the light of what the Security
Extension may contain?]

--- ../usefor-article-05/Cancel.out          July 2001
+++ ../usefor-article-06/Cancel.out          November 2001
@@ -1,8 +1,9 @@
-7.5.  Cancel
+7.3.  Cancel
 
    The cancel message requests that a target article be "canceled" i.e.
    be withdrawn from circulation or access. A cancel message may be
    issued in the following circumstances.
+
    1. The poster of an article (or, more specifically, any entity
       mentioned in the From header or the Sender header, whether or not
       that entity was the actual poster) is always entitled to issue a
@@ -26,26 +27,7 @@
       Approved header identifying the responsible entity. Serving agents
       MAY honour such requests, but SHOULD first take steps to verify
       their appropriateness.
-[I think that accords with the accepted norms for 1st, 2nd and 3rd party
-cancels (or is a moderator a 1st party?). Observe the use of an Approved
-header in place of the present X-Cancelled-By (I cannot see that we need
-a new header for that when Approved is available). The definitions given
-are sufficient to establish which category a cancel was in, assuming
-that nobody told any lies, and to establish who had committed abuse
-otherwise. So far so good, but we now need authentication methods on top
-of all that.]
-
-[A future draft of this standard may contain provisions for a Cancel-
-Lock header to enable verification of the authenticity of 1st (and even
-2nd) party cancels, and means for digital signatures to establish the
-authenticity of 3rd party cancels.]
-
-[A future draft of this standard may also contain provision for a "block
-cancel" message, with a list of messages to be canceled contained in its
-body rather than in the headers. Whether this needs to have a Control
-header at all, and whether the existing "nocem-on-spool" is adequate for
-this purpose, and indeed whether NOCEM as such should be part of this,
-or some other, standard are issues that are yet to be addressed.]
+
 
       cancel-verb         = "cancel"
       cancel-arguments    = CFWS message-id
@@ -53,13 +35,21 @@
    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 delete
-   the target article completely and immediately (or at the minimum make
-   the article unavailable for relaying or serving) and also SHOULD
-   reject any copies of this article that appear subsequently. See also
-   sections 8.3 and 8.4.
+   the same newsgroup, with the same distribution, 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 8.3 and 8.4.
+
+        NOTE: It is expected that the security extension envisaged in
+        section 7.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.
 
         NOTE: The former requirement [RFC 1036] that the From and/or
         Sender headers of the cancel message should match those of the
@@ -69,4 +59,6 @@
         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.
+[Do we want to review that now in the light of what the Security
+Extension may contain?]