Subject: Re: draft-ietf-usefor-usepro-01.txt

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 16 Nov 2004 11:21:57 GMT

There was some discussion regarding this a month back. I am now preparing
draft-usepro-02. Here are some of the new bits of text related to the
discussions we had.

Much of what you see here is pieces of existing text that were expected to
migrate to USEFOR, but in the event have come back here.

All that is new in the Control Messages section is a pointer to the Duties
of a Relaying Agent for handling non-existent newsgroups, the removal of a
sentence which Russ did not like (and which will reappear in some form in
USEAGE), and the obsoleting of the "cmsg" hack.

6.  Control Messages
 
   The following sections document the control messages.  "Message" is
   used herein as a synonym for "article" unless context indicates
   otherwise.
 
   The Newsgroups-header of each control message SHOULD include the
   newsgroup-name(s) for the group(s) affected (i.e. groups to be
   created, modified or removed, or containing articles to be canceled).
   This is to ensure that the message propagates to all sites which
   receive (or would receive) that group(s). It MAY include other
   newsgroup-names so as to improve propagation (but this practice may
   cause the control message to propagate also to places where it is
   unwanted, or even cause it not to propagate where it should, so it
   should not be used without good reason).
 
        NOTE: Propagation is controlled by relaying agents, and it may
        be necessary for relaying agents to take special steps to ensure
        that control messages such as newgroup messages for not-yet-
        existent newsgroups are propagated correctly (see 7.3).
[The first of those paragraphs was originally scheduled to be moved to
USEFOR (and it may yet be so moved). It has been reinstated here (at
least temporarily) to make sure that it does not get overlooked.]

   The presence of a Subject-content starting with the string "cmsg "
   and followed by a <control-message> was construed under [RFC 1036] as
   a request to perform that control action (even if no genuine Control
   header was present). Indeed, some implementations went further and
   added the implied Control header before injecting. Likewise, the
   presence of a newsgroup-name ending in ".ctl" in the Newsgroups
   header caused the Subject header content (not starting with "cmsg" in
   this case) to be interpreted as a <control-message>.

   All these practices are now declared to be Obsolete, and Subject
   headers MUST NOT now be interpreted as <control-message>s under any
   circumstances.

   The descriptions below set out REQUIREMENTS to be followed by sites
   that receive control messages and choose to honour them. However,
   nothing in these descriptions should be taken as overriding the right
   of any such site, in accordance with its local policy, to refuse to
   honour any particular control message, or to refer it to an
   administrator for approval (either as a class or on a case-by-case
   basis).

   In the following sections, each type of control message is defined
   syntactically by defining its verb, its arguments, and possibly its
   body.

6.1.  Digital Signature of Headers

   It is most desirable that group control messages (6.2) in particular
   be authenticated by incorporating them within some digital signature
   scheme that encompasses other headers closely associated with them
   (including at least the Approved-, Message-ID- and Date-headers). At
   the time of writing, this is usually done by means of a protocol
   known as "PGPverify" ([PGPVERIFY]), and continued usage of this is
   encouraged at least as an interim measure.

   However, PGPverify is not considered suitable for standardization in
   its present form, for various technical reasons. It is therefore
   expected that an early extension to this standard will provide a
   robust and general purpose digital authentication mechanism with
   applicability to all situations requiring protection against
   malicious use of, or interference with, headers.  That extension
   would also address other Netnews security issues.

7.3.  Duties of a Relaying Agent

   A Relaying Agent accepts injected articles from injecting and other
   relaying agents and passes them on to relaying or serving agents
   according to mutually agreed policy. Relaying agents SHOULD accept
   articles ONLY from trusted agents.

   An article SHOULD NOT be relayed unless the sending agent has been
   configured to supply and the receiving agent to receive at least one
   of the newsgroup-names in its Newsgroups-header and at least one of
   the distributions in its Distribution-header, if any.  Exceptionally,
   ALL relaying agents are deemed willing to supply or accept the
   distribution "world", and NO relaying agent should supply or accept
   the distribution "local".

   However, if the particular implementation does not relay non-existent
   newsgroups, even when included in the Newsgroups-header and implied
   (e.g. by some "wild card" notation) in the configuration tables, then
   the agent MUST examine all group control messages (6.2) in order to
   ensure that relaying of those messages proceeds normally.

............

   In order to avoid unnecessary relaying, an article SHOULD NOT be
   relayed if the path-identity of the receiving agent (or some known
   alias thereof) appears in its Path-header.

[Removed mention of similar checks at the receiving end, which apparently
are seldom done.]

   A relaying agent processes articles as follows:

............

   3. It SHOULD reject any article that does not include all the
      mandatory headers (section a-5).

   4. It MAY reject any article whose headers do not have legal
      contents.

............

7.4.  Duties of a Serving Agent

............

   A serving agent MAY decline to accept an article if the Path-content
   contains some path-identity whose articles the serving agent does not
   want, as a matter of local policy.

        NOTE: This last facility is sometimes used to detect and decline
        control messages (notably cancel messages) which have been
        deliberately seeded with a path-identity to be "aliased out" by
        sites not wishing to act upon them.
[INN at least does this. It might be argued that it is not necessary to
mention it here.]

   A serving agent processes articles as follows:

............

   3. It MUST reject any article that does not include all the mandatory
      headers (section a-5), or which contains any header that does not
      have legal contents.
[That is mentioned here mainly for comparison with the altered wording
under Relaying Agents.]

............

7.7.  Duties of a Reading Agent

   A reading agent downloads articles from a serving agent, as directed
   by the reader, and displays them (or processes them in some other
   manner), subject to any limitations of the reading agent, such as
   availability of charsets, and having first decoded any Content-
   Transfer-Encodings, encoded-words, etc.  It SHOULD also have the
   capability to show the raw article exactly as received.

[That wording has been toned down, as requested by John Stanley.]

   It MAY present lists of articles available for display, and MAY
   structure those lists so as to show the relationships between the
   articles, as determined by the References-, Subject-, Date- and
   other-headers (see [USEAGE] for some usual methods of doing this).
[A sentence regarding rejection of articles with unwanted distributions
has been removed, and will reappear in USEAGE.]

[This whole section may yet get omitted]

On top of the changes noted above, I am working on some further changes,
mainly in the form of texts that were expected to appear in USEFOR, but
will now appear in USEPRO following discussions with our Chair.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5