usefor-article-07 May 2002
[< Prev]
[TOC] [ Next >]
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 '%' delimiter 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.
control-message =/ Cancel-message
Cancel-message = "cancel" Cancel-arguments
Cancel-arguments = CFWS msg-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.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../usefor-article-06/Cancel.out November 2001
+++ ../usefor-article-07/Cancel.out May 2002
@@ -5,7 +5,7 @@
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
+ 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
@@ -13,24 +13,25 @@
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)
+ of the leftmost '%' delimiter 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
+ 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
+ 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
+ control-message =/ Cancel-message
+ Cancel-message = "cancel" Cancel-arguments
+ Cancel-arguments = CFWS msg-id
The argument identifies the article to be cancelled by its message
identifier. The body SHOULD contain an indication of why the
@@ -52,13 +53,11 @@
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
+ 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
+ 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?]