[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #1132: Allowing IP addresses as path-identiites - Poll result
In <> Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx> writes:
>I've taken out ticket #1132 to cover this specific issue, rather than the=20
>more generic #1047 ticket. They're linked in the tracker.
>Result:
>> YES - IP addresses should be allowed as path-identity.
>John Stanley
>Charles Lindsey
>> NO - IP addresses should not be allowed as path-identity.
>Richard Clayton
>Russ Allbery
>Frank Ellermann
>Dan Schlitt
I am disappointed at the way the decision went, but I have to live with it.
>I'll write up a suggested modification to section 3.2.1 based on this.
What is written has to be carefully tailored to what will be written in
USEFOR. Here is a suggested text (or rather two texts, with the second one
using SEEN/MATCH/MISMATCH to distingish diagnostics, which I propose to
call <source-identity>s, from <path-idenitiy>s.
I have followed Kai's suggestion for restricting the syntax of <bareword>.
Injection-Infor and Xref will simply use <path-identity> as redefined.
3.1.6 Path
The Path header field indicates the route taken by an article since
its injection into the Netnews system. Each agent that processes an
| article is required to prepend a <path-entry> to this header field
body. .......
[1st version of syntax, following the usage of POSTED and
MISMATCH in the present USEFOR.]
path = "Path" ":" SP [FWS] *( path-entry "!" [FWS]) tail-entry [FWS] CRLF
path-entry = path-identity *( "!" path-identity ) [ "!" "POSTED" ]
[ [ source-identity [ "!" "MISMATCH" ] ] "!" ]
path-identity = dot-atom-text / bareword
bareword = ALPHA *( [ "-" / "_" ] (ALPHA / DIGIT) )
tail-entry = dot-atom-text / bareword
source-identity = dot-atom-text / IP-address / bareword
IP-address = IPv4address / IPv6address ; see [RFC 3986]
Each <path-entry> (but not the <tail-entry>) indicates, from right to
left, the successive sites through which the article has passed. The
keyword "POSTED" indicates that the agent to its left injected the
article. A <source-identity>, if present, indicates the true source
from which the agent to its left acquired the article (and any
following "!MISMATCH" asserts that this differs from the
<path-identity>(s) inserted by the preceding site, whereas two "!"s
in succession indicate that the preceding <path-identity>(s) accords
with that true source).
The full procedure for constructing a <path-entry> as well as the
preferred format to be used in a <path-identity> are discussed in
[USEPRO].
NOTE: An <IPv6address> is the only place where a ":" can occur
within a <path-entry>. Since some current news-servers may treat
":" as a delimiter (in addition to the customary "!"), it is
inadvisable for any <bareword> to be composed only from
hexadecimal digits.
NOTE: Historically, the <tail-entry> .........
NOTE: Although case-insensitive, it is intended that the keywords
"POSTED" and "MISMATCH" should be in upper case, to distinguish
them from the <bareword>s which are traditionally in lower
case.
[2nd version of syntax, making <source-identity>s readily
distinguishable from <path-identity>s.]
path = "Path" ":" SP [FWS] *( path-entry "!" [FWS]) tail-entry [FWS] CRLF
path-entry = path-identity *( "!" path-identity )[ "!" "POSTED" ]
[ [ path-source ] "!" ]
path-identity = dot-atom-text / bareword
bareword = ALPHA *( [ "-" / "_" ] (ALPHA / DIGIT) )
tail-entry = dot-atom-text / bareword
path-source = source-identity ( ".SEEN" / ".MATCH" / ".MISMATCH" )
source-identity = dot-atom-text / IP-address / bareword
IP-address = IPv4address / IPv6address ; see [RFC 3986]
Each <path-entry> (but not the <tail-entry>) indicates, from right to
left, the successive sites through which the article has passed. The
keyword "POSTED" indicates that the agent to its left injected the
article. A <path-source>, if present, indicates the true source from
which the agent to its left acquired the article, and whether it
accords with the <path-identity>(s) inserted by the preceding site.
Two "!"s in succession are equivelent to "!site.example.MATCH!" where
"site.example" agrees with that preceding <path-identity>(s).
The full procedure ........
NOTE: An <IPv6address> is the only place ...........
NOTE: Historically, the <tail-entry> .........
NOTE: Although case-insensitive, it is intended that the "SEEN",
"POSTED" or "MISMATCH" in a <path-source> should be in upper case,
to distinguish them from the <bareword>s which are traditionally
in lower case.
In the following examples, "upstream.example.com" is a site which has
just sent an article (or so it is claimed) to "downstream.example.com".
"123.123.123.123" is the IP address from which downstream received it,
which may or may not be the IP address of upstream. The examples show the
full <path-entry> inserted by downstream, followed by (at least the start
of) the <path-entry> inserted by upstream.
1. downstream.example.com!123.123.123.123.SEEN!upstream.example.com...
2. downstream.example.com!123.123.123.123.MISMATCH!upstream.example.com...
3. downstream.example.com!123.123.123.123.MATCH!upstream.example.com...
4. downstream.example.com!!upstream.example.com...
5. downstream.example.com!upstream.example.com...
All the diagnostic <path-source>s are immediately distinguishable from the
<path-identity>s by the presence of a big uppercase keyword.
Even if you thought 123.123.123.123 was a site to which you were not
supposed to send articles, no current implementation would recognize it as
such in any of those examples.
Ex1. Downstream recorded that 123.123.123.123 was the source of the
article "just for the hell of it". It makes no claim to have verified that
it belonged to upstream.
Ex2. Downstream recorded that 123.123.123.123 was the source of the
article and asserted that it no way matched any known address associated
with upstream. Some current practice uses exactly that notation.
Ex3. Downstream recorded that 123.123.123.123 was the source of the
article and asserted that it was indeed a known address used by upstream.
In which case you may ask why it bothered to clutter the Path by quoting
it in full.
Ex4. Downstream noted the IP (whatever) of the source and asserts that it
was indeed a known address used by upstream. But it did not clutter the
Path with unnecessary detail. That is the notation proposed in the current
drafts, and will hopefully be the commonest case.
Ex5. Downstream made no checks and makes no assertions. That is
essentially current practice which we hope will be replaced by Ex4 over
time.
I have shown no example using the optional "!POSTED", but that would only
be inserted by an injecting agent, in which case any <path-source> shown
would presumably be the posting host.
NOTE: The use of an IP address for the <path-source> in the examples does
not imply that a corresponding domain name could not have been used
instead (indeed, it would be more user-friendly to have done so). So Ex3
could as well have been written
3. downstream.example.com!upstream.example.com.MATCH!upstream.example.com...
Observe that folding is not allowed in the middle of a <path-entry>.
--
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