usefor-article-04 April 2001
[< Prev]
[TOC] [ Next >]
7.5. 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.
[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
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.
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.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../usefor-article-03/Cancel.out February 2000
+++ ../usefor-article-04/Cancel.out April 2001
@@ -3,6 +3,7 @@
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
@@ -12,11 +13,11 @@
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) 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.
+ 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
@@ -35,7 +36,7 @@
otherwise. So far so good, but we now need authentication methods on top
of all that.]
-[A future draft of this standard will contain provisions for a Cancel-
+[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.]
@@ -55,6 +56,7 @@
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