usefor-article-03 February 2000
[< 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) 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 will 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
--- ../s-o-1036/cancel.out June 1994
+++ ../usefor-article-03/cancel.out February 2000
@@ -1,187 +1,72 @@
-7.1. cancel
+7.5. Cancel
-The cancel message requests that one or more previous arti-
-cles be "cancelled":
-
- cancel-arguments = message-id *( space message-id )
- cancel-body = body
-
-The argument(s) identify the articles to be cancelled, by
-message ID. The body is a comment, which software MUST
-ignore, and SHOULD contain an indication of why the cancel-
-lation was requested. The cancel message SHOULD be posted
-to the same newsgroup(s), with the same distribution(s), as
-the article(s) it is attempting to cancel.
-
- NOTE: Using the same newsgroups and distributions
- maximizes the chances of the cancel message propa-
- gating everywhere the target articles went.
-
- NOTE: RFC 1036 permitted only a single message-id
- in a cancel message. Support for cancelling mul-
- tiple articles is highly desirable, especially for
- use with Supersedes (see section 6.14). If sev-
- eral revisions of an article appear in fast suc-
- cession, each using Supersedes to cancel the pre-
- vious one, it is possible for a middle revision to
-
-INTERNET DRAFT to be NEWS sec. 7.1
-
-
- be destroyed by cancellation before it is propa-
- gated onward to cancel its predecessor. Allowing
- each article to cancel several predecessors
- greatly alleviates this problem. (Posting agents
- preparing a cancel of an article which itself can-
- cels other articles might wish to add those arti-
- cles to the cancel-arguments.) However, posters
- should be aware that much old software does not
- implement multiple cancellation properly, and
- should avoid using it when reliable cancellation
- is vitally important.
-
-When an article (the "target article") is to be cancelled,
-there are four cases of interest: the article hasn't arrived
-yet, it has arrived and been filed and is available for
-reading, it has expired and been archived on some less-
-accessible storage medium, or it has expired and been
-deleted. The next few paragraphs discuss each case in turn
-(in reverse order, which is convenient for the explanation).
-
-EXPIRED AND DELETED. Take no action.
-
-EXPIRED AND ARCHIVED. If the article is readily accessible
-and can be deleted or made unreadable easily, treat as under
-AVAILABLE below. Otherwise treat as under EXPIRED AND
-DELETED.
-
- NOTE: While it is desirable for archived articles
- to be cancellable, this can easily involve rewrit-
- ing an entire archive volume just to get rid of
- one article, perhaps with manual actions required
- to arrange it. It is difficult to envision a sit-
- uation so dire as to require such measures from
- hundreds or thousands of administrators, or for
- that matter one in which widespread compliance
- with such a request is likely.
-
-AVAILABLE. Compare the mailing addresses from the From
-lines of the cancel message and the target article, bearing
-in mind that local parts (except for "postmaster") are case-
-sensitive and domains are case-insensitive. If they do not
-match, either refer the issue to an administrator for a
-case-by-case decision, or treat as if they matched.
-
- NOTE: It is generally trivial to forge articles,
- so nothing short of cryptographic authentication
- is really adequate to ensure that a cancel came
- from the original article's author. Moreover, it
- is highly desirable to permit authorities other
- than the author to cancel articles, to allow for
- cases in which the author is unavailable, uncoop-
- erative, or malicious, and in which damage and/or
- legal problems may be minimized by prompt cancel-
- lation. Reliable authentication that would permit
-
-INTERNET DRAFT to be NEWS sec. 7.1
-
-
- such administrative cancels would be a worthwhile
- extension to this Draft, and experimental work in
- this area is encouraged.
-
- NOTE: Meanwhile, a simple check of addresses is
- useful accident prevention and catches at least
- the most simple-minded forgers. Since the intent
- is accident prevention rather than ironclad secu-
- rity, use of the From address is appropriate, all
- the more so because in the presence of gateways
- (especially redundant multiple gateways), the
- author may not have full control over Sender head-
- ers.
-
- NOTE: The "refer... or treat as if they matched"
- rule is intended to specifically forbid quietly
- ignoring cancels with mismatched addresses.
-
-If the addresses match, then if technically possible, the
-relayer MUST delete the target article completely and imme-
-diately. Failing that, it MUST make the target article
-unreadable (preferably to everyone, minimally to everyone
-but the administrator) and either arrange for it to be
-deleted as soon as possible or notify an administrator at
-once.
-
- NOTE: To allow for events such as criminal
- actions, malicious forgeries, and copyright
- infringements, where damage and/or legal problems
- may be minimized by prompt cancellation, complete
- removal is strongly preferred over merely making
- the target article unreadable. The potential for
- malice is outweighed by the importance of really
- getting rid of the target article in some legiti-
- mate cases. (In cases of inadvertent copyright
- violation in particular, the ability to quickly
- remedy the violation is of considerable legal
- importance.) Failing that, making it unreadable
- is better than nothing.
-
- NOTE: Merely annotating the article so that read-
- ers see an indication that the author wanted it
- cancelled is not acceptable. Making the article
- unreadable is the minimum action.
-
- NOTE: There have been experiments with making can-
- celled articles unreadable, so that local news
- administrators could reverse cancellations. In
- practice, administrators almost never find cause
- to do so. Removal appears to be clearly prefer-
- able where technically feasible.
-
-NOT ARRIVED YET. If practical, retain the cancel message
-until the target article does arrive, or until there is no
-
-INTERNET DRAFT to be NEWS sec. 7.1
-
-
-further possibility of it arriving and being accepted (see
-section 9.2), and then treat as under AVAILABLE. Failing
-that, arrange for the target article to be rejected and dis-
-carded if it does arrive.
-
- NOTE: It may well be impractical to retain the
- control message, given uncertainty about whether
- the target article will ever arrive. Existing
- practice in such cases is to assume that addresses
- would match and arrange the equivalent of dele-
- tion. This is often done by making a spurious
- entry in a database of already-seen message IDs
- (see section 9.3), so that if the article does
- arrive, it will be rejected as a duplicate.
-
-The cancel message MUST be propagated onward in the usual
-fashion, regardless of which of the four cases applied, so
-that the target article will be cancelled everywhere even if
-cancellation and target article follow different routes.
-
- NOTE: RFC 1036 appeared to require stopping cancel
- propagation in the NOT ARRIVED YET case, although
- the wording was somewhat unclear. This appears to
- have been an unwise decision; there are known
- cases of important cancellations (in situations
- of, e.g., inadvertent copyright violation) achiev-
- ing rather poorer propagation than the target
- article. News propagation is often a much less
- orderly process than the authors of RFC 1036
- apparently envisioned. Modern implementations
- generally propagate the cancellation regardless.
-
-Posting agents meant for use by ordinary posters SHOULD
-reject an attempt to post a cancel message if the target
-article is available and the mailing address in its From
-header does not match the one in the cancel message's From
-header.
-
- NOTE: This, again, is primarily accident preven-
- tion.
+ 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) 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 will 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.