Path header field (was: draft-allbery-usefor-usepro-00 errata)

[Russ Allbery <[e-mail]>]

Russ Allbery <[e-mail]> writes:

>  * A separate sub-section of duties, before the individual agent duties
>    and possibly as part of the same sub-section as the identity
>    discussion, should be added specifying Path header construction.  The
>    Path header example should be moved to be a sub-section of that
>    section.  That section can lay out all the construction requirements
>    for the Path header field and just be referred to by the individual
>    duties sections.

>  * The possibility of adding multiple path-identities should be
>    reintroduced as part of the rework of the Path description.

>  * Serving agents also are not required to modify the Path header field if
>    processing an article from a relaying agent or injecting agent that's
>    part of the same server.  This can be handled more generally in the
>    redone Path section.

As promised, here is the new section.  I also made the corresponding
updates to the other sections (removing the description and replacing it
with a reference to this section) and moved the Path header field example.

3.2.1.  Constructing the Path Header Field

   If a relaying or serving agent receives an article from an injecting
   or serving agent that is part of the same news server, it MAY leave
   the Path header field of the article unchanged.  Otherwise, every
   injecting, relaying, or serving agent that accepts an article MUST
   update the Path header field as follows.  Note that the Path header
   field content is constructed from right to left by prepending
   elements.

   1.  The agent MUST prepend "!" to the Path header field content.

   2.  An injecting agent SHOULD prepend the <path-diagnostic>
       "!.POSTED", optionally followed by "." and the FQDN or IP address
       of the source, to the Path header field content.

   3.  A relaying or serving agent SHOULD prepend a <path-diagnostic> to
       the Path header field content, where the <path-diagnostic> is
       chosen as follows:

       *  If the expected <path-identity> of the source of the article
          matches the leftmost <path-identity> of the Path header
          field's content, use "!" (<diag-match>).

       *  If the expected <path-identity> of the source of the article
          does not match, use "!.MISMATCH." followed by the expected
          <path-identity> of the source or its IP address.

       *  If the relaying or serving agent is not willing or able to
          check the <path-identity>, use "!.SEEN." followed by the FQDN,
          IP address, or expected <path-identity> of the source.

   4.  The agent MUST then prepend its own <path-identity> to the Path
       header field content.

   5.  The agent MAY then prepend additional <path-identity>s for itself
       to the Path header field content, following each <path-identity>
       so added with either "!!" or "!".  This is permitted for agents
       that have multiple <path-identity>s (such as during a transition
       from one to another).  Each of these <path-identity>s MUST meet
       the requirements set out in Section 3.2.

   Any agent which modifies the Path header field MAY fold it by
   inserting FWS immediately after any <path-identity> or <diag-other>
   it added (see section 3.1.5 of [USEFOR] for allowable locations for
   FWS).

>  * (Still under discussion.)  We may wish to reintroduce the possibility
>    of a path-identity that is not a resolvable name in DNS.

This was already in my draft.  I have:

   The <path-identity> used by an agent may be chosen via one of the
   following methods (in decreasing order of preference):

   1.  The fully-qualified domain name (FQDN) of the system on which the
       agent is running.

   2.  A fully-qualified domain name (FQDN) within a domain affiliated
       with the administrators of the agent and guaranteed to be unique
       by the administrators of that domain.  For example, the
       uniqueness of server.example.org could be guaranteed by the
       administrator of example.org even if there is no DNS record for
       server.example.org itself.

   3.  Some other (arbitrary) name in the form <path-nodot> believed to
       be unique and registered at least with all the other news servers
       to which that relaying agent or injecting agent sends articles.
       This option SHOULD NOT be used unless the earlier options are
       unavailable or unless the name is of longstanding usage.

This is the same as what's in the current USEPRO draft except that my 1.
replaces:

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

or

   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.

The most common current practice is to use the FQDN of the news server,
not a mail server, as a path identity.  If one wants to use a mail server,
2. still allows for that; it doesn't require that the name *not* exist in
DNS.

In my original draft, I intentionally removed any protocol-required
connection between a <path-identity> and a contact address.  After lots of
previous discussion of this point, I don't think the potential gains of
discussing such a connection in this specification are worth the
complexity and divergence from current practice.

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>