usefor-article-03 February 2000

6.13.1.  Syntax and Semantics

   The  Replaces and Supersedes headers specify articles to be cancelled
   on arrival of this one. The content syntax makes use of syntax
   defined in [MESSFOR].

      Replaces-content    = msg-id *( CFWS msg-id )
      Replaces-header-parameter
                = Usage-token "=" Usage-value
                  ; for USENET-header-parameters see 4.1
      Usage-token         = [CFWS] "usage" [CFWS]
      Usage-value         = [CFWS] ("replace" / "revise" / "repost" )
                     [CFWS]
      Supersedes-content  = msg-id

        NOTE: There is no "c" in "Supersedes".
[I could be persuaded of a better token than "usage". I did wonder about
"disposition". Observe that "usage" is also now used also in
message/news-transmission.]

   If an article contains a Replaces header, then the old articles
   mentioned SHOULD simply be deleted by the serving agent, as in a
   cancel message (7.5), and the new article inserted into the system as
   any other new article would be.

   A Replaces-header-parameter is only meaningful when it occurs within
   a Replaces-content. If its Usage-value is "revise" or "repost" (or if
   the Replaces-header-parameter is absent, then by default) reading
   agents SHOULD NOT show the article as an "unread" article unless the
   replaced article(s) were themselves all unread, except when the
   reader has configured his reading agent otherwise.

   Moreover, if a Usage-value is "revise" or "repost", serving agents
   that generate a local Xref header MUST then include additional
   "revise" or "repost" information as set out in section 6.14.

        NOTE: A replacement with "usage=replace" is intended to be used
        in the case of an article that is sufficiently different from
        its predecessors that it is advisable for readers to see it
        again.  A replacement with "usage=revise" is intended to be used
        in the case of a minor change, unworthy of being brought to the
        attention of a reader who has already read one of its
        predecessors. A replacement with "usage=repost" is intended to
        be used in the case of an article identical to the one replaced
        (but possibly being reposted because the earlier one had likely
        expired).

        NOTE: A reader who elects to ignore all the articles available
        in a newsgroup (perhaps on the occasion of accessing that
        newsgroup for the first time) will likely have them all marked
        as "already read", unless the reading agent provides a distinct
        mark such as "never offered". This could lead to a later
        replacement with "revise" or "repost" for one of those articles
        being missed.

   The Supersedes header is obsolescent, is provided only for
   compatibility with existing software, and may be removed entirely in
   some future version of this standard. Its meaning is the same as that
   of a corresponding Replaces header with its Replaces-header-parameter
   set to "usage=replace", and whenever a Supersedes header is provided
   a matching Replaces header SHOULD be provided as well. Observe that
   the Supersedes header makes provision for only a single msg-id.

   Until the Replaces header has become widely implemented, software
   SHOULD generate Replaces headers with only one msg-id, and cancel
   control messages SHOULD be issued if needed for further identifiers.
   Moreover, until that time, any article containing a Replaces header
   SHOULD contain also a Supersedes header (or alternatively be
   accompanied by a Control cancel message) for that same msg-id, to
   ensure that older systems still at least remove the predecessor.

   When a message contains both a Replaces and a Supersedes header they
   MUST be for the same msg-id.  Furthermore, to resolve any doubt, the
   Replaces header shall be deemed to take priority.

   Whatever security or authentication mechanisms are required for a
   Control cancel message MUST also be required for an article with a
   Replaces or Supersedes header. In the absence or failure of such
   checks, the article SHOULD be discarded, or at most stored as an
   ordinary article.
[We can write something more constructive in here as soon as the
situation with regard to cancel-locks and signed headers has been
clarified.]