Subject: Re: #1415 USEPRO 3.2.1 - Number of path entries per site

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 14 Feb 2007 12:42:40 GMT

As Harald has pointed out, this has received no discussion. I won't repeat
my full argument here (see the issue tracker), but will just summarize.

There are two issues, plus some niggles (including #1414 which refers to
the same bit of text).

1. To permit sites to omit path entries which merely reflect their
internal structure without being of any benefit to the world outside. My
suggested rewording of the first paragraph of 3.2.1 was

   Except possibly when relaying to other hosts on the same site, every
   injecting, relaying, or serving agent that accepts an article MUST
   update the Path header field ....

2. The present Steps 4 and 5 of 3.2.1 are just plain wrong.

Since receiving agents are expected to do a MISMATCH check on articles
relayed to them (inserting "!!" or "!.MISMATCH...." accordingly), and only
look at the leftmost <path-identity> when doing that check, it is
essential that the 'true' identity of the site (the ones its downstreams
will be 'expecting') be the last one to be prepended, after prepending any
extra ones (e.g. a <path-nodot> such as 'demon'). However, Steps 4 and 5
currently prepend these things in the wrong order, which could cause
MISMATCH checks to fail.

Note that such "extra" identities are only put there because that site does
not want to receive articles with any of those identities already present
from its upstreams, and for historical reasons it needed more than one
identity for that purpose.

My suggested fix was to replace both those steps by

   4. The agent MUST then prepend one or more <path-identity>s identifying
   itself (as set out in section 3.2) to the Path header field content,
   separated by either "!!" or "!". However, the last (leftmost) such
   <path-identity> so appended MUST be one that is expected by the
   destination site when it in turn comes to apply Step 3 above.

Note. There is some confusion as to whether a "!" belongs to the
identity/diagnostic to its left, or to its right, and the present wording
switches betweeen these two conventions in the middle of Step 4 (and my
revision does the same switch with its "separated by"). So some further
tidying up of the whole wording might be a good idea.

On top of that, my 'either "!!" or "!"' needs further rewording to reflect
the outcome of issue #1414.

And, for my final niggle, please can we have a definition of the term
"expected" which is used at several places in 3.2.1. Essentially, it needs
to reflect whatever the receiving site is using as the "verified" identity
of the sending site (whether derived from the IP address, or from some
earlier SASL authentication, or whatever else). Usepro-06 covered this by
requiring sites to establish such a verified identity, and by then using
the term "verified" rather than "expected".

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

---

From: Russ Allbery <[email-masked]>
Date: Mon, 19 Feb 2007 22:56:49 -0800

>    update the Path header field ....

I don't think this is necessary.  There are two possibilities: the site is
using the Netnews protocol within the site or not.  If it is, it needs to
fill out the Path header field for the same reasons that any other Netnews
servers need to.  If it's not, then those components are, from the Netnews
perspective, conceptually a single news server, and hence the existing
language already permits omitting Path entries.

Nothing in the document should be requiring the components of a news
server be running on a single system.

> relayed to them (inserting "!!" or "!.MISMATCH...." accordingly), and
> only look at the leftmost <path-identity> when doing that check, it is
> will be 'expecting') be the last one to be prepended, after prepending
> any extra ones (e.g. a <path-nodot> such as 'demon'). However, Steps 4
> and 5 currently prepend these things in the wrong order, which could
> cause MISMATCH checks to fail.

You're reading more into steps 4 and 5 than is actually there.  :)  That
doesn't mean that it's not a good idea to change the wording if it's
confusing, but what you're arguing for isn't contradicated by the current
language.

   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.

This doesn't append the identities in the wrong order.  It appends them in
an unspecified order, as there's no distinction being made here between
the identity appended in step 4 and the identities possibly appended in
step 5.  They're all just identities for the site.  So nothing prevents
the identities from being appended in the order that minimizes MISMATCH.

Nothing *requires* it, either, so we should look at that.

> Note that such "extra" identities are only put there because that site
> does not want to receive articles with any of those identities already
> present from its upstreams, and for historical reasons it needed more
> than one identity for that purpose.

That's one possible reason.  Another reason for appending such extra
identities is because an ISP with independent news servers wants to add a
common identity to the Path for statistical purposes.  I've seen that
several times.

>    4. The agent MUST then prepend one or more <path-identity>s
>    identifying itself (as set out in section 3.2) to the Path header
>    field content, separated by either "!!" or "!". However, the last
>    (leftmost) such <path-identity> so appended MUST be one that is
>    expected by the destination site when it in turn comes to apply Step
>    3 above.

This language requires mind reading; you may have no idea what other sites
expect.  It's also hard to satisfy this MUST during a transition where
some peers may expect one ordering and others may be expecting a different
one.

I can see the argument for saying something here, but it would be nice to
say something that's a bit more clearly defined and less based on the
(unknown) behavior of one's peers.  Something like adding the below to the
end of the step five description:

    If the agent prepends additional <path-identity>s, the leftmost
    <path-identity> SHOULD be the one advertised to other news servers as
    the expected <path-identity> for this agent.

> identity/diagnostic to its left, or to its right, and the present
> wording switches betweeen these two conventions in the middle of Step 4
> (and my revision does the same switch with its "separated by").

The present wording doesn't consider "!" to belong to any identity and
instead treats it as a delimiter, so it's not following either of those
conventions.  The precise steps seemed to read more clearly to me doing it
that way.

> So some further tidying up of the whole wording might be a good idea.

Please do suggest other wording if you think there's a clearer way to
explain it.

> On top of that, my 'either "!!" or "!"' needs further rewording to
> reflect the outcome of issue #1414.

Yup.

> "expected" which is used at several places in 3.2.1.

I don't think we gain much from this.  This checking is not particularly
formal, so I think more specification implies more rigorous verification
than we're actually specifying.  "Expected" feels to me like it captures
about the level of checking and formality we're getting.  The definition
of the term is the standard English definition of the word.

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