Re: Path header field

["Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>]

In <87bqlmigu8.fsf@xxxxxxxxxxxxxxxxxxxxx> Russ Allbery <rra@xxxxxxxxxxxx> writes:

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

I think that is more restrictive than we intended. The idea was that if
there was a "farm" of servers at one site, splitting the various duties
(incoming articles, outgoing articles, local storage of articles) amongst
themselves in some manner, it was not necessary to include every server
the article actually passed through (i.e. we do not need to see, from the
outside, the detailed internal structure of that site).

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

I don't think that we ever agreed to permit a <diag-identity> after
"POSTED", though we did discuss it. I have no great objection if others
want it (semantically, it is rather like "SEEN"). However, if allowed, it
needs to indicate that the FQDN or IP address is indeed a <diag-identity>,
in which case the question arises of why you have not permitted a
<path-nodot> (which the syntax would allow).

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

At this point, you need a definition of "expected". I see that you mention
"trusted" sources and agents in 3.4 and 3.5 (but not 3.6). In USEPRO, I
had a generic definition in section 7, but using "verified" rather than
"trusted". I think you either need such a generic definition in this
section, or you need to define "expected" by reference to those earlier
mentions.  And I would have thought that "verified" was a better term than
"expected", but that is less of an issue than ensuring the term in
question is consistently defined somehow.

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

Again, you are actually constructing a <diag-match> here, but this time
you DO allow a <path-nodot>.

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

But now the <path-nodot> is gone again :-( .

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

You need to be careful here. Certainly an agent with several
<path-identity>s can prepend a selection of them, but it MUST ensure that
the last (leftmost) prepended one is its "official identity" by which it
will be known to its peers; otherwise, it risks getting MISMATCHed.

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

OK, the general structure of what you have written is fine. The only extra
item I can think of at the moment is that you need to say that you have
only defined three <diag-keyword>s (there is a pointer to USEPRO regarding
this in USEFOR), and that other <diag-keyword>s MUST/SHOULD NOT be used,
except those beginning with "X" (for sites that claim a need to say
something that cannot be expressed with the three we have provided, or for
other such experimental reasons).

The section on Path Examples presumably follows here here. If Richard
Clayton is listening, could he please repeat his reasons why the
<path-nodot> "demom" was needed (and is still used) by demon's servers,
and can we please then incporate that into the examples somewhere. The
whole <path-nodot> business was heavily influenced by his example, but I
forget the precise reasoning now.

>>  * (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.

If this means A and AAAA records then please, for the removal of all
doubt, make that explicit.

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

Again, if this is meant to include MX records and CNAMES, please make it
explicit, because the wording does not immediately suggest that, and it
will hopefully be the common case.

However, I am still opposed to allowing domain-names for which no DNS
exists, and if that gets taken out then there is little point in keeping
this paragraph, and the MX and CNAMEs may as well go back in #1.

>   3.  Some other (arbitrary) name .....


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

There hasn't been any such protocol-required connection for a long time.
We decided to let RFC 2142 (muddled though it is) speak for itself.
However, that it no reason not to draw attention to it as USEPRO did
(slightly differently in the two alternatives, of which I prefer the
freestanding second version which came from Harald); observe that it
carefully refrains from saying that you MUST/SHOULD follow it. I would be
equally happy yo see it in a NOTE, but it needs to be mentioned somewhere.

-- 
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: chl@xxxxxxxxxxxxxxxx      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