Subject: USEPRO - Path header revisions

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 9 May 2006 21:36:16 GMT

Now that the issues of #1047 are largely resolved (any remaining issues
concern NOTEs about <diag-deprecated> and other non-normative matters), I
thought it would be useful to make all necessary changes to USEPRO to
bring it into line with the new syntax and terminology and to check our
understanding of any relateds protocol changes we have discussed.

This should enable us to identify any problems with what we have written
in USEFOR that might misfit with USEPRO (I have found none so far). But in
any case, it is time we were getting on with USEPRO now that USEFOR is
complete bar matters of style and fixing of typos.

The following are the changes to USEPRO that seem to be necessary. The
great bulk of them are minor fixes to adapt to the revised terminology. It
is only when you come to sections 7.3 and 7.3.1 that there is any major
rewriting.

There are some specific issues mentioned which we need to decide about,
and no doubt people will raise more. But could we please restrict
discussion to matters directly relevant to the Path header, and not to
other matters which might just happen to appear en passage in the texts I
have reproduced.

2.3.  Identification of news servers

[There are two alternative texts which have been proposed:]

   In order to record the passage of articles through the network, news
   servers need to identify themselves by means of a <path-identity>
   (F-3.1.6), which can appear in Path, Injection-Info and Xref header
   fields. Whatever <path-identity> is used in the Path header field
   SHOULD be used also in any Injection-Info header field (and it would
   be normal to use it in any Xref header field also).
[Maybe that last sentence moves elsewhere.]

        NOTE: Such <path-identity>s may also be suitable for sending
        email to news server administrators (see [USEAGE]).

[1st alternative]

   <Path-identity>s can take the following forms (in decreasing order of
   preference):

   1. A fully qualified domain name (FQDN) that SHOULD be resolvable in
      the DNS (whether via an A, AAAA or MX record or an equivalent
      CNAME), thus guaranteeing a unique identity. Ideally, it will also
      provide a means to contact the administrators by email (according
      to [RFC 2142], the forms "usenet@server" and "news@server" are
      common addresses for a news server administrator).

|  2. Some other (arbitrary) name in the form of a <path-nodot>, and
|     believed to be unique and registered at least with all other news
      servers sending articles directly to the given one. This option
      SHOULD NOT be used unless the earlier option is unavailable (e.g.
      because the server in question is not connected to the Internet),
      or unless it is of longstanding usage and cessation would be
      unduly disruptive, or unless the earlier option is provided as
      well.

[2nd alternative]

   <Path-identity>s can take the following forms (in decreasing order of
   preference):

   1. A fully qualified domain name (FQDN) that can be resolved to an
      email server via an MX, A or AAAA record according to the
      procedures of [RFC 2821]; this guarantees that the name is unique,
      and makes it easy to contact the administrators if needed.

   2. A fully qualified domain name (FQDN) that is guaranteed to be
      unique by the administrators of the domain; for instance, the
      uniqueness of "server.example.org" could be guaranteed by the
      administrator of "example.org" even if nothing is stored in the
      DNS for that name.

|  3. Some other (arbitrary) name in the form of a <path-nodot>, and
|     believed to be unique and registered at least with all other
      news-servers sending articles directly to the given one. This
      option SHOULD NOT be used unless the earlier options are
      unavailable, or unless the name is of longstanding usage and
      cessation would be unduly disruptive, or unless one of the earlier
      options is provided as well.

   According to [RFC 2142]], the forms "usenet@server" and "news@server"
   are common addresses for a news server administrator.
[end of alternatives]

|       NOTE: A news server administrator who chooses a <path-nodot>
        which turns out not to be unique will have to bear the
        consequences.

|       NOTE: An IP address is not permitted as a <path-identity>,
|       although it may still appear in a <diag-identity>. Since the
|       syntax permits a colon (":"  which, prior to this standard, was
|       an alternative to the "!"  delimiter) within any <diag-identity>
|       which takes the form of an <IPv6address>, it would be unwise to
|       choose as a <path-nodot> anything composed solely from four or
|       less hexadecimal digits.

3.2.  Transitional Arrangements

|    o The new style of Path header field, using a <diag-match> to allow
|      "!!"  as a delimiter> and introducing <path-diagnostic>s (which
|      can be distinguished from <path-identity>s by their leading ".")
       is already consistent with the previous standards. However, the
       intention is that relaying agents should eventually reject
       articles in the old style, and so this possibility should be
       offered as a configurable option in relaying agents. User agents
       are unaffected.

7.  Duties of Various Agents

   In this section, the word "trusted", as applied to the source of some
   article, means that an agent processing that article has verified, by
   some means, the identity of that source (which may be another agent
   or a poster).
[I am proposing to s/trusted identity/verified identity/ throughout this
chapter, as it seems to convey the sense better; anyone have any
problems with this?]

7.2.  Duties of an Injecting Agent

   In the normal course of events, an article that has already been
   injected into a Netnews network will never pass through another
   injecting agent.  So, if an injecting agent receives an otherwise
   valid article that has already been injected (as evidenced by the
   presence of an Injection-Date header field, an Injection-Info header
|  field, or more than one occurrence of the <diag-keyword> "POSTED" in
   a Path header field) it MAY choose to reject it, but otherwise SHOULD
   cause it to be relayed, as it stands, by a relaying agent (7.3).

7.2.1.  Proto-articles

        NOTE: An article that is offered for reinjection has, by
        definition, already been injected once, and is not therefore to
        be considered as a proto-article.  Hence a genuine proto-article
|       will not contain any Injection-Date header field nor the <diag-
|       keyword> "POSTED" anywhere in its Path header field, though that
        header field MAY contain <path-identity>s corresponding to
        machines traversed between the posting agent and the injecting
        agent proper.

7.2.2.  Procedure to be followed by Injecting Agents

   10.  It MUST then prepend the <path-identity> of the injecting agent,
|       followed by '!.' and the <diag-keyword> "POSTED", and then a
|       further "!",  to the content of the Path header field; this
        header field SHOULD then be folded if it would otherwise result
        in a header line of excessive length.

7.3.  Duties of a Relaying Agent

   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 as a <path-identity> in its Path header field.
|  But note that the <tail-entry> (which follows the last "!") is not a
|  <path-identity>, although not all current implementations observe
|  this distinction.

|  For this to work, each relaying agent needs to insert it own <path-
|  identity> (chosen according to 2.3) into the Path header field. It
|  MAY insert more than one <path-identity> for itself (in which case
|  the leftmost should be the one by which it is known to its immediate
|  neighbours), but where an article passes through several relaying
|  agents at the same site it MAY omit the <path-identity>s for some of
|  them (but NOT the one which finally relays it to an outside site).

|  It MAY (and usually SHOULD) also add a <path-diagnostic> giving
|  additional information concerning the route taken by the article
|  through the network.  A <path-diagnostic> consists of either the
|  special <diag-match> "!" (which effectively replaces the standard
|  delimiter "!" by "!!"), or it is composed from a <diag-keyword> usually
|  followed by a <diag-identity>. The following are the only <diag-
|  keyword>s defined by this standard:
|    o "POSTED" (already introduced in Step 10 of 7.2.2), which is never
|      followed by a <diag-identity>;
|    o "SEEN", whose following <diag-identity> indicates the trusted
|      identity (see 7) of the agent from which the article was received
|      (but makes no claim as to whether it matched the <path-identity)
|      inserted by that agent);
|    o "MISMATCH", whose following <diag-identity> indicates the trusted
|      identity of the agent from which the article was received and
|      asserts that it could not be reconciled with the <path-identity>
|      (supposedly) inserted by that agent.
|  Other <diag-keyword>s beginning with "X" MAY be used by a relaying
|  agent to make some assertion not envisaged here, but other (non-"X")
|  <diag-keyword>s MUST NOT be used unless defined by some extension to
|  this standard.

|       NOTE: The <diag-keyword> "MATCH", which might have indicated the
|       trusted identity of the source agent with an assertion that it
|       agreed with the <path-identity> inserted by that agent, has NOT
|       been provided, since the special <diag-match> conveys exactly
|       that meaning for this commonly occurring case.

|       NOTE: Whilst <diag-keywords>s are case insensitive, it is
|       intended that they should normally be rendered in upper case.

   A relaying agent processes articles as follows:

|     1. It MUST/SHOULD establish the trusted identity of the source of
         the article and compare it with the leftmost <path-identity> of
|        the existing Path header field's content.  Except possibly when
|        relaying to other hosts on the same site, It then MUST or
|        SHOULD, as indicated, prepend to that content (from left to
|        right) the following:
|        o (MUST) its own <path-identity>;
|        o (MUST) a "!" delimiter;
|        o (MUST/SHOULD) if the trusted and existing identities match, a
|          <diag-match> (effectively converting the "!" delimiter into
|          "!!");
|        o (MUST/SHOULD) alternatively, where the identities do not
|          match (or have not been determied to match), a ".", the
|          <diag-keyword> "MISMATCH" (or "SEEN"), another ".", a <diag-
|          identity> indicating the trusted identity, and finally a
|          further "!";
|        o possibly further <path-identity>s etc. as above, identifying
|          itself.
|     This header field SHOULD then be folded if it would otherwise
|     result in a header line of excessive length.
[The "MUST/SHOULD"s above were all "MUST" in the previous drafts.
Discussion is needed to resolve this.]

|       NOTE: Since each agent at one site can be assumed to be aware of
|       the identity of the others (and of itself), it would be most
|       unusual for their <path-identity>s to be separated other than by
|       "!!". Thus the presence of a single "!", unless followed by a
|       "." and some <diag-keyword>, can be taken as signifying an agent
|       that has not yet been upgraded to conform to this standard.

|       NOTE: Whilst the presence of a "MISMATCH" would normally
|       indicate that the existing Path was bogus in some sense, it
|       could also indicate that the ralaying agent was improperly
|       configured to recognise the identities or aliases used by its
|       neighbours. Administators of relaying agents should therefore
|       periodically monitor the <path-diagnostic> being inserted so as
|       to avoid this.

        NOTE: In order to prevent overloading, relaying agents should
        not routinely query an external entity (such as a DNS-server) in
        order to determine a trusted identity (though a local cache of
        the required information might usefully be consulted).

7.3.1.  Path Header Field Example

|     Path: bar.isp.example!.SEEN.news3.foo.isp.example!foo.isp.example
|        !!foo-server!.MISMATCH.2001:DB8:0:0:8:800:200C:417A
|        !dubious.site.example!!old.site.example!barbaz!!baz.isp.example
|        !.POSTED!dialup123.baz.isp.example!not-for-mail

        NOTE: That article was injected into the news stream by
|       baz.isp.example, as indicated by the <diag-keyword> "POSTED"
        (complaints may be addressed to [email-masked]). The
        injector has chosen to record that it got it from
        dialup123.baz.isp.example. "not-for-mail" is a dummy <tail-
        entry>, though sometimes a real userid is put there.

        The article was relayed, perhaps by UUCP, to the machine known,
        at least to old.site.example, as "barbaz".

        Barbaz relayed it to old.site.example, which does not yet
|       conform to this standard (hence the single '!' delimiter). So
        one cannot be sure that it really came from barbaz.

|       Old.site.example relayed it to a site claiming to be
|       dubious.site.example, and claiming (by using the '!!'
|       delimiter) to have verified that it came from old.site.example.

|       Dubious.site.example relayed it to "foo-server" which, not being
|       convinced that it truly came from dubious.site.example, and
|       knowing that it in fact arrived from a host with the IPv6address
|       [2001:DB8:0:0:8:800:200C:417A], inserted the <path-diagnostic>
|       "!.MISMATCH.2001:DB8:0:0:8:800:200C:417A" (that is not to say
|       that [2001:DB8:0:0:8:800:200C:417A] was not a correct IPv6
|       address for dubious-site.example, but simply that that
|       connection could not be substantiated by foo-server).

        "foo-server" is a locally significant name within the complex
        site of many machines run by foo.isp.example, so the latter
        should have no problem recognizing foo-server and using a '!!'
|       delimiter. It was not strictly necessary to insert the <path-
|       identity> "foo-server" as well as "foo.isp.example" (but maybe
|       some site elsewhere had some reason to test for it).
[Please could Richard Clayton provide a more plausible reason why "foo-
server" might be a <path-nodot> here?]

|       It then went to bar.isp.example which determined (by reverse
|       DNS) that it had come from news3.foo.isp.example, but had taken
|       no steps to check whether that was a known alias for
|       foo.isp.example (which it probably was). Strictly, it SHOULD
|       have made such a check, and then inserted either a "!!" or a
|       "!MISMATCH..." according to the result.

|       Presumably bar.isp.example then delivered the article to its
        direct clients.

|       It appears that foo.isp.example, foo-server and baz.isp.example
        decided to fold the line, on the grounds that it seemed to be
|       getting a little too long.  Note that folding and whitespace is
|       permitted before (but not after) any "!"  (but not within a
|       "!!"); hence continuation lines will always start with either
|       "!" or "!!".

7.4.  Duties of a Serving Agent

A serving agent processes articles as follows:

|  1. It MUST/SHOULD establish the trusted identity of the source of the
      article and modify the Path header field as for a relaying agent
      (7.3).

7.8.  Duties of a Moderator

   5. Any variant header fields (2.4) MUST be removed, except that a
      Path header field MAY be truncated to only those entries following
|     its "POSTED" <diag-keyword>.  Any Injection-Info header field (F-
      3.2.14) SHOULD be removed (and if not, the injecting agent will do
      so, as required in 7.2.2).

-- 
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