Subject: Re: #1047 Path-identity: A proposal (perhaps)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 01 Jul 2005 13:55:53 +0200

--On torsdag, juni 30, 2005 19:47:58 +0000 Charles Lindsey 
<[email-masked]> wrote:

>    path-identity   =  ( ALPHA / DIGIT )
>>                      *( ALPHA / DIGIT / "-" / "." / "_" )
>
>>   path-keyword    = "POSTED" / "MISMATCH"
>
>
>>   path-address    =  IPv4address / no-fold-literal ; see [RFC2373]
>
> A good idea, but the term <path-identity> needs to include everything that
> may occur in the list, except the two keywords, because it is used with
> that meaning in many places.

8 times in usefor, 10 times in usepro....

If a path-address is really diagnostic information, this separation is in 
fact useful, since you do NOT want those diagnostics where a real 
path-identity is desired; I'd argue that the Xref header and the 
Injection-info header should not need to contain a path-address.

USEPRO uses the term in the IHAVE/SENDME messages and in the description of 
handling of the Path header; in both cases, it seems to me useful to draw a 
distinction between diagnostic information and a real server name - indeed, 
the only place where I can see the need to use a path-address is in the 
part about verification of address:

   1. It MUST establish the trusted identity of the source of the
      article and compare it with the leftmost <path-identity> of the
      Path header's content. If it matches it MUST then prepend its own
      <path-identity> and a '/' <path-delimiter> to that content; this
      SHOULD then be followed by CRLF and WSP if it would otherwise
      result in a line longer than 79 characters.  If it does not match
      then it prepends instead two entries to that content; firstly the
      true established <path-identity> of the source followed by a '?'
      <path-delimiter>, and then, to the left of that, its own <path-
      identity> followed by a '/' <path-delimiter> as usual. This
      prepending of two entries SHOULD NOT be done if the provided and
      established identities match.  See a-5.6.4 for the significance of
      the various <path-delimiter>s.

I think you've just strengthened the argument for separating the two....

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 1 Jul 2005 19:50:04 GMT

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>On Wed June 29 2005 08:33, Harald Tveit Alvestrand wrote:
>>   A path-identity identifies an agent. For the news system to work
>>   properly, the path-identity must be globally unique.

>If we mean "public name" we should probably say so: s/identifies/is a
>public name identifying/

Well it is really the text in USEPRO that should say that, but it is a
good point, so the proposed USEPRO text now starts:

   News-servers need to identify themselves by inserting their public
   name, in the form of a <path-identity> (F-3.1.6), into Path,
   Injection-Info and Xref headers. An injecting agent MUST identify
   itself with the same <path-identity> in both Path and Injection-Info
   headers.  To ensure that a <path-identity> provides a unique identity
   for the news-server concerned, it SHOULD be one of: ..........

>Global uniqueness is an interoperability requirement ("to work properly");
>s/must/MUST/ would make that clear.

I think the USEPRO text above covers that.

>Because of the global uniqueness requirement, s/should/MUST/.  Add
>something to address Frank's concern about unauthorized use.

And the proposed USEPRO text also covers that, though it could be
strengthened.

>The ABNF implies that
>  Path: MISMATCH!tail-entry
>and
>  Path: MISMATCH!MISMATCH!tail-entry
>are legal, which I believe is not the intended use of the keywords.

The procedures for constructing a Path entry are contained in my suggested
USEPRO text posted here a week or so ago. It makes it clear exactly where
and when those two keywords may appear, so it is hardly necessary to
complicate the syntax with such matters (and there is no particular need
for agents to take note of those keywords when parsing).

>>   NOTE: The path-address contains characters that some systems consider
>>      path-delimiters. This can cause problems; path-address should
>>      therefore only be used when absolutely necessary.
>>      See [USEPRO] for details on when to use them.

>Because of the backward compatibility/interoperability problem
>s/should/MUST/.

No, because there are plenty of hosts around that have IP addresses but no
domain name. The text proposed for USEPRO makes it clear that IP addresses
are the least desirable alternative.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Fri, 1 Jul 2005 20:02:43 GMT

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

So I have s/SHOULD/should/. I tried other wordings, but that seemed to fit
best.

>>| The FQDN of a news-server is "mailable" if its
>>| administrators can be reached by email using both of the
>>| forms "usenet@<FQDN>" and "news@<FQDN>", in conformity
>>| with [RFC 2142].

>Maybe say 'forms "usenet@" and "news@" at the FQDN represented
>by the <path-identity>, in conformity with [RFC 2142].'  Issue:
>I'm not sure about using <FQDN> if that's no term in the ABNF.

OK, I have done that:

   The FQDN of a news-server is "mailable" if its administrators can be
   reached by email using both of the forms "usenet@" and "news@"
   followed by that FQDN, in conformity with [RFC 2142].

>Some of Bruce's points are not yet covered, MISMATCH!MISMATCH
>etc., maybe we have to declare these beasts as special cases
>of a path-delimiter, brain-storming:

See my reply to Bruce. USEPRO gives clear instructions how to construct
them, and that is probably enough.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 1 Jul 2005 18:51:28 -0400

> for agents to take note of those keywords when parsing).

We *could* simply say
 path = "Path: " *text CRLF
but that would hardly provide clarity about what is in the field.  There
are two related issues:
1. the text appears to be wrong about the description, particularly w.r.t.
   MISMATCH
2. the ABNF should be consistent with the text, and should work with the
   text to provide a *clear* specification

> are the least desirable alternative.

That goes against Harald's "diagnostic stuff" suggestion.  A host with
an IP address but no domain name could, I suppose, concoct one in
in-addr.arpa.  The big problem is that many IP addresses are not unique,
and I suspect that the ones with unique ones have a domain name, especially
if they're running a news server, if for no other reason than to comply
with RFC 2142.  *If* they have no other choice, then that would meet the
"when absolutely necessary" condition, so there's no problem with MUST.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Jul 2005 13:26:05 GMT

>but that would hardly provide clarity about what is in the field.

Indeed, but all what a relaying agent needs (and has time) to do is to
identify the <path-delimiter>s and the <path-identity>s, so that it can
determine whether it is about to send to a site whose <path-identity> is
already listed. So that is all that the ABNF needs to cover.

All the rest is adequately described by the text which tells you how/when
to insert POSTED/MISMATCH, etc. If you ignore that text and put those
keywords in places where they should not be, then relaying agents won't
care, though humans might well be confused.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Jul 2005 13:16:18 GMT

>Injection-info header should not need to contain a path-address.

Yes, but the path-address (IPv[46]address) is NOT "just diagnopstic
information"	. It is in fairly widespread current use, with the intent of
avoiding duplicate propagation to the site which inserted it.

OTOH, the keywords POSTED and MISMATCH, plus the double "!!" delimiter
_are_ for purely diagnostice purposes, and those are the things I want
excluded from <path-identity>.

>I think you've just strengthened the argument for separating the two....

I hope I have just strengthened the argument for keeping them together.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Jul 2005 13:16:18 GMT

---

From: Russ Allbery <[email-masked]>
Date: Mon, 04 Jul 2005 11:34:59 -0700

Charles Lindsey <[email-masked]> writes:

> information" . It is in fairly widespread current use, with the intent
> of avoiding duplicate propagation to the site which inserted it.

Huh, really?  I'm not saying you're wrong, since I've not checked, but
I've not personally seen anyone use an IP address as their actual path
identity (as opposed to having it added by their peers as diagnostic
information).

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 5 Jul 2005 19:03:02 GMT

>identity (as opposed to having it added by their peers as diagnostic

Well there is certainly a lot of IP addresses followed by ".MISMATCH", but
discounting those there are still a lot of IP addresses to be found

I trawled through 17893 articles in my archive, and found 721 (4%) with
naked IP addresses in them. Of these, 481 were one particular site
(uni-berlin.de) whose injector routinely inserted the dial-in IP after the
not-for-mail (the same as the NNTP-Posting-Host in fact). But that still
leaves 240 (1.3%) with IP addresses in the middle. 202 of these were three
sites (small.news.tele.dk, cyclone-sf.pbi.net and worldnet.att.net) which
seem sytematically to insert the IP from which it received the message
(but they did not appear to be MISMATCHes).

news-uk.onetel.net.uk seemed to insert its own IP address, followed by the
posting host (and no-not-for-mail) when injecting (30 0f those). Which
left a small core of other odds and ends.

So yes, a lot of it seems to be down to a small number of sites adding
their peer's IP as you said, but also some mavericks who do odd things when
injecting.

But I still think we have to allow it, for a variety of odd cases, and I
still think <path-identity> ought to include them for the purposes for
which I use it in USEPRO. But clearly the SHOULD NOT use IP addresses when
you have a perfectly good domain-name, in my latest proposed text, is
still OK (and most people seem already to be following it). Note that the
text I have written applies to sites identifying themselves - MISMATCHes
are dealt with elsewhere in USEPRO.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Jul 2005 14:23:34 -0400

On Tue July 5 2005 15:03, Charles Lindsey wrote:

> leaves 240 (1.3%) with IP addresses in the middle.

1.3% is about the same the fraction of messages still using a subset of
RFC 561/680/724/733/822/2822 time zone abbreviations.

[...]
> But I still think we have to allow it, for a variety of odd cases,

Do try to be consistent.  If that 1.3 percent warrants handling
IP addresses, then surely the same 1.3 percent warrants handling
the [ECMP][DS]T zone abbreviations.