Subject: Re: #1047 Path field delimiters and syntax - status

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Sep 2005 08:06:35 +0200

Harald Tveit Alvestrand wrote:

> I stand by "idiocy".

| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

Here's "Tough consensus", not only 10 years, STD 11 was 1982.

The 2822 syntax is (almost) perfect, but its semantics is
sometimes a bit vague.
                            Bye, Frank

---

From: [email-masked] (Kai Henningsen)
Date: 02 Sep 2005 12:22:00 +0200

[email-masked] (Richard Clayton)  wrote on 21.08.05 in <[email-masked]>:

> BTW: Usenet is not all that big -- I identified 2556 servers as being
> part of a "peering core" (from my vantage point). The other 8500
> machines were merely feeding into that core.
>
> The algorithm was to start from 'news.maxwell.syr.edu' and see if any
> article arrived that had been given any articles by this machine. If so
> then they were added to the core and a check made to see if there were
> now other machines to which articles had been given...  iterate.
>
> Looking now at those 2556 servers -- which are, at least from my vantage
> point, somewhat more important than the rest -- I find that 218 of them
> have chosen to use an identity that is a bare word, and I'd say that
> half of those look to be UUCP names.

To get an impression of how fully you saw the periphery of the net, can  
you tell me how many (or which) westfalen.de machines you found?

MfG Kai

---

From: Richard Clayton <[email-masked]>
Date: Fri, 2 Sep 2005 17:34:44 +0100

In message <[email-masked]>, Kai Henningsen
<[email-masked]> writes
>you tell me how many (or which) westfalen.de machines you found?

core path identities (I've no idea what a "machine" is)

        colo.khms.westfalen.de
        silvana.westfalen.de
        westfalen.de

other path identities that sent messages to machines in the core

        dl6dx.westfalen.de
        ripley.westfalen.de
        news.khms.westfalen.de

recall that this was July->October 2004

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

---

From: [email-masked] (Kai Henningsen)
Date: 03 Sep 2005 14:21:00 +0200

[email-masked] (Richard Clayton)  wrote on 02.09.05 in <[email-masked]>:

> >[email-masked] (Richard Clayton)  wrote on 21.08.05 in
> ><jr6LcRfMrKCDFARx @highwayman.com>:
> >

Those are in fact all different machines :-) (khms.westfalen.de would be  
the same as news.khms.westfalen.de, but you don't list it.)

I wouldn't have expected to see any of those in "core" ... on the other  
hand, I'd have expected to see khms.westfalen.de in the lower group; I  
certainly posted quite some articles during that time!

MfG Kai

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 5 Sep 2005 18:30:16 GMT

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>--On mandag, august 22, 2005 11:58:32 +0000 Charles Lindsey 
><[email-masked]> wrote:

>>> Saying that giving a name to your system is REQUIRED by the standards is
>>> a  Good Thing, and allows us to positively refuse to allow such idiocies
>>> as  using an IP address to identify your server in injection-info.
>>
>> Why is it an "idiocy"? We are talking about globally routable IP addresses
>> which are allocated according to a very well defined procedure. So, in
>> fact, they would actually be safer than "barewords".

>RFC 1958 section 4.1:

>   4.1 Avoid any design that requires addresses to be hard coded or
>   stored on non-volatile storage (except of course where this is an
>   essential requirement as in a name server or configuration server).
>   In general, user applications should use names rather than addresses.

But who said anything about "requiring addresses to be hard coded"?

Every internet protocol that I can think of (certainly email and URLs)
permits IP addresses in the syntax everywhere that domain-names are
allowed. It then goes on to tell you (with varying degrees of firmness)
that IP addresses SHOULD NOT be used without good cause (but the protocols
MUST still accept them and process them correctly). So indeed, there is no
place where they are REQUIRED to be used, but lots of places where they
MAY be used (subject to varying degrees of discouragement, as indicated).

That is all I am asking for in <path-identity>s. The syntax should
_permit_ them (as it will also for "diagnostic" use). But the semantics
(in USEPRO) will provide strong discouragement (as it will also do for
<bareword>s). My currently proposed USEPRO text is:

   <Path-identity>s can take the following forms (in decreasing order of
   preference):
 
   1. A fully qualified domain name (FQDN) associated with an "A" or
      "AAAA" record identifying that news-server, or with an "MX" record
      through which its administrators can be contacted; alternatively
      an equivalent "CNAME".

   2. An encoding of the public [RFC 1918], permanently routable IP
      address - <IPv4address> or <IPv6address> [RFC 3986] - of that
      news-server. This option SHOULD NOT be used if an FQDN for that
      server is available (however, such IP addresses are perfectly
      suitable for purely diagnostic identities [reference needed to
      later section]).

   3. Some other (arbitrary) name believed to be unique and registered
      at least with all other news-servers sending articles directly to
      the given one. This option SHOULD NOT be used unless the earlier
      options are unavailable (e.g. because the server in question is
      not connected to the Internet), or unless it is of longstanding
      usage and cessation would be unduly disruptive, or unless one
      of the earlier options is provided as well.

        NOTE: A news-server administrator who chooses a name which turns
        out not to be unique will have to bear the consequences.

        NOTE: The syntax permits the colon character (which, prior to
        this standard, was a <path-delimiter>) within any <path-
        identity> which is in the form of an <IPv6address>.  It would
        therefore be unwise to choose, as such a name, anything composed
        solely from four (or less) hexadecimal digits.

[The precise text is up for discussion, of course, and I just noticed that
the mention of MX records may need to be toned down.]

>That's been an Internet architectural principle for 10 years, and we have 
>LOTS of experience in what happens when you violate that principle.

Whay I am proposing seems exactly in conformance with that architectural
principle.

-- 
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: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 06 Sep 2005 12:33:23 +0200

technical contributor hat on:

In case anyone is in any doubt whatsoever, I think we should delete option 
2 in the list below. It adds zero value for the users of the standard, and 
creates one more reason for identities to be unstable.

chair hat on:

it's "me-too" time.
If you have an opinion of whether or not we should allow IP addresses as 
path-identities, either YES or NO, please speak up.

YES - IP addresses should be allowed as path-identity.
NO - IP addresses should not be allowed as path-identity.

NOTE: If we disallow IP addresses as path-identities, we will still allow 
them as "diagnostic data" - nobody's proposed that we should declare 
articles that have IP addresses in the path as non-conformant. However, if 
we disallow them, they WILL be disallowed in Injection-info and Xref, which 
are the two other places that use them.

(I'm offline, so can't take out a ticket number on this specific subject. 
Will do so when I get back online.)

               Harald

--On 5. september 2005 18:30 +0000 Charles Lindsey <[email-masked]> 
wrote:

> My currently proposed USEPRO text is:
>

---

From: Richard Clayton <[email-masked]>
Date: Tue, 6 Sep 2005 12:31:57 +0100

In message <6C715BFE8359F291F057BD04@B50854F0A9192E8EC6CDA126>, Harald
Tveit Alvestrand <[email-masked]> writes

>NO - IP addresses should not be allowed as path-identity.

I think they're unnecessary (and they're also currently uncommon). I
would not like to see any encouragement for them, so "no"

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

---

From: Russ Allbery <[email-masked]>
Date: Tue, 06 Sep 2005 10:30:33 -0700

Richard Clayton <[email-masked]> writes:
> Harald Tveit Alvestrand <[email-masked]> writes

> would not like to see any encouragement for them, so "no"

I agree.

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

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Tue, 06 Sep 2005 13:46:10 -0400

I think these poll choices are poorly specified.

I say MUST ACCEPT, MUST NOT generate.  Is that YES or NO?

And if it matters here, I think all diagnostics should start
with ".keyword.", such as  "!.mismatch.10.0.0.1".

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 6 Sep 2005 14:40:21 -0400 (EDT)

If IP addresses aren't allowed in paths, how is a site to denote "I
got this from someone claiming to be <domain> but the IP address
doesn't match, it's actually <ip>"?

Seth

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 06 Sep 2005 21:31:35 +0200

> I say MUST ACCEPT, MUST NOT generate.  Is that YES or NO?

Shucks, I forgot "none of the above" as a choice.....
Are you talking about components of the path, or about identities that can 
appear in Xref: and Injection-info:?

I haven't yet seen anyone claim to have seen an IP address in Xref: in the 
wild, and Injection-info: isn't implemented (AFAIK) by anyone yet, so I 
don't see any reason to do a MUST ACCEPT.
But YMMV.

             Harald

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 06 Sep 2005 23:55:26 +0200

---

From: Dan Schlitt <[email-masked]>
Date: Tue, 6 Sep 2005 20:54:53 -0400

/dan

-- 

Dan Schlitt
[email-masked]

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Wed, 07 Sep 2005 00:16:12 -0400

> appear in Xref: and Injection-info:?

Since you replied by asking a question....does that mean you agree your poll
choices are ambigous?  This has nothing to do with understanding English.
I observe that your understanding and use of English is excellent, but what's
the reason to avoid RFC2119 terms?  If we can't even ask simple questions
precisely, then let's just give up on writing a useful document.

"not allowed" can mean MUST NOT generate, MUST NOT relay, MUST NOT
use to determine propagation.  Or does it mean that the USEFOR grammar ends up
having no way to specify IP addresses in path-identity (which means there
may not be any RFC2119 MUST terminology.)

"path-identity" is used in the grammar defining the syntax of three
different header fields. (-- A mistake if you ask me....Quick tell me
what will every clients do with an IPv6 address with colons in the
path-identity Xref header field?)

When someone votes "NO - IP Addresses should not be allowed as path-identity"
are they voting that Relaying servers are supposed to reject articles which
have an IP in the Path: header field?   Are they voting that servers are permitted
to reject articles which have an IP in the Path: header field?  Or that
the Injection-info-experiment-trying-to-be-a-standard-field cannot use an IP
address for the first terminal after the first CFWS.

I hope people know what they are voting for. I don't.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Sep 2005 09:02:24 +0200

Forrest J. Cavalier III wrote:

> When someone votes "NO - IP Addresses should not be allowed
> as path-identity" are they voting that Relaying servers are
> supposed to reject articles which have an IP in the Path:
> header field?

We're not "voting".  It's only a poll, you can start your own
if you don't like Harald's.  When I posted "NO" what I meant
was this:

NO - I don't want IPs as "path identity", neither in the Path:
nor in Xref:, let alone nntp-URLs or Injection-Info.  It should
be easy to use a proper FQDN as name for _servers_ - and where
that's not the case we still offer the "traditional name" with
the necessary caveat that this won't work for conflicts.

> I hope people know what they are voting for.

s/voting//  Me too, if you think it's nonsense please tell me.
IMHO we've already discussed all pros and cons, it's possible
to get it right for IPs incl. IPv6, but it would be too messy.

> I don't.

Please post them if you have new arguments.  Just state what
you think - if it convinces Harald-with-hat-on he's free to
ignore all who posted "NO".  It's not really a "vote", it's
testing the water before declaring (rough) consensus.

                         Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 7 Sep 2005 10:40:18 GMT

In <4C8F9B0B48686F7B528A298D@[10.61.80.31]> Harald Tveit Alvestrand <[email-masked]> writes:

>Are you talking about components of the path, or about identities that can=20

I think we are talking about Path primarily, but it would be natural for
Injection-Info to follow what we decide. And Xref too for consistency,
though technically it hardly matters.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 7 Sep 2005 10:36:50 GMT

>I say MUST ACCEPT, MUST NOT generate.  Is that YES or NO?

If you said MUST accept, SHOULD NOT generqte, then that would certainly be
"YES". I grant you it would need some pretty weird circumstance to justify
breaking that SHOULD NOT, but the Real World is a weird place :-).

>with ".keyword.", such as  "!.mismatch.10.0.0.1".

Yes, I made a proposal along those lines, except I put the keyword at the
end (because there is some existing practice for that). We can decide
after whether to follow that route (certainly the stuff in USEPRO covering
diagnostics needs a revision, and that might affect the precise syntax
too).

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 7 Sep 2005 10:24:52 GMT

>it's "me-too" time.
>If you have an opinion of whether or not we should allow IP addresses as=20

>NO - IP addresses should not be allowed as path-identity.

YES

I don't want to encourage them, and I don't expect them to appear often,
if at all, and I support SHOULD NOT use them without good cause.

But you don't actually gain anything by forbidding them. The dead:beef
problem still remains (because IP addresses are still allowed as
diagnostics) and the syntax becomes a little more complicated.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Wed, 07 Sep 2005 09:08:56 -0400

> diagnostics needs a revision, and that might affect the precise syntax

Putting the keyword at the end makes it look like a TLD.  Starting with . makes
it easy to determine it is not a bare FQDN.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Wed, 07 Sep 2005 09:15:44 -0400

> the necessary caveat that this won't work for conflicts.

The poll wasn't for "server-name", it was for "path-identity."

Does that mean that someone saying NO for path-identity is also
saying that they reject uses of IP for diagnostics in path-list, since
the grammar says a path-list contains path-identities, not server-names?

You may argue that an implementor knows whether they are inserting
a server name or a diagnostic, and that there is no issue.  But the
grammar only allows path-identity, folded white space, keywords, and
delimiters.  (Well, it allows a tail entry which is a path-identity.)

So where do IP addresses for diagnostics fit in?

If people think they want IP addresses for diagnostics, but not
servers, it is another example of syntax that is easy to construct,
but impossible to determine if something is a server identity or a diagnostic
when parsing.  (I object to all syntax that is "write only", including
a References: header field which cannot be used to determine followups.)

If people don't want to allow IP addresses for path-identities, then
they should poll on whether it is a MUST NOT, SHOULD NOT, MUST REJECT,
MUST NOT RELAY.

Charles was correct in pointing out that I should reconsider and
indicate MUST ACCEPT, SHOULD NOT generate when used in path-list.  Or, if the
path-list syntax is changed to distinguish diagnostics (such as a prefix
keyword starting with ".") then MUST ACCEPT, MUST NOT generate, MAY use the keyword
prefix + IP address.

But MUST NOT for server-name, and SHOULD NOT when path-identity for Injection-info.

Harald can count that as a "YES", "NO", or a "NO RESPONSE" however he
likes.  He can interpret precise language into his imprecise choices.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 07 Sep 2005 22:06:01 +0200

Forrest J. Cavalier III wrote:

> Does that mean that someone saying NO for path-identity is
> also saying that they reject uses of IP for diagnostics in
> path-list

No, that part would be still TBD, you added "keyword dot IP"
to the list, Charles proposed "IP dot keyword", and I vaguely
recall a dot-atom-text construct from Harald (but that didn't
work because it contained path delimiters).

> You may argue that an implementor knows whether they are
> inserting a server name or a diagnostic, and that there is
> no issue.  But the grammar only allows path-identity, folded
> white space, keywords, and delimiters.  (Well, it allows a
> tail entry which is a path-identity.)

We'd update the Path-ABNF allowing some kind of diagnostics
if the poll results in "no IPs as path-identity".  With this
idea all problems of IPs elsewhere (Xref or Injection-Info)
are eliminated or rather reduced to "diagnostics in the Path".

IMHO it's cleaner than Charles' approach (a SHOULD NOT for
IPs as path-identity).

> Harald can count that as a "YES", "NO", or a "NO RESPONSE"
> however he likes.

What you said sounds like NO for me, and what Charles said
like YES.
                          Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 8 Sep 2005 14:11:12 GMT

>it easy to determine it is not a bare FQDN.

If it were not for existing practice I would agree with you. But DNews (I
think, plus some others) regularly generates things like
...!news.example.com.MISMATCH!... in the Path, so I think it best to
formalize that usage rather then invent a different kind of wheel. I doubt
ICANN are on the verge of creating a "mismatch" TLD.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 8 Sep 2005 14:11:12 GMT

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 8 Sep 2005 14:35:48 GMT

>the grammar says a path-list contains path-identities, not server-names?

No, the idea is that the syntax will be so written that IP addresses are
not allowed in <path-identity>s, but will be allowed in
<diagnostic-identity>s (or whatever we choose to call them). If there is
some technical difficulty in writing that syntax, then it will be written
as a prohibition in the wording.

It will be my intention, as soon as this issue is decided, to propose a
syntax, probably in two versions, with the diagnostic stuff incorporating
some sort of keyword in one of them.

Injection-Info and Xref will use only <path-identity>. Even if we do allow
IP addresses in <path-identity> (which I still favour), I don't think they
would do any actual harm (e.g. parsing problems) in either of those
headers.

>a References: header field which cannot be used to determine followups.)

There I agree with you. This restriction, if we agree to it, will be
impossible to enforce. Relayers, when examing the Path, are never going to
do more that take whatever stuff is between the delimiters (however they
understand what a delimiter is) and check whether that stuff matches one
of their peers.

>they should poll on whether it is a MUST NOT, SHOULD NOT, MUST REJECT,

I think the only viable options there are MUST NOT/SHOULD NOT generate,
which correspond pretty well to the NO and YES options in the poll.

>keyword starting with ".") then MUST ACCEPT, MUST NOT generate, MAY use the keyword

That is pretty close to "YES".

>But MUST NOT for server-name, and SHOULD NOT when path-identity for

But I fail to see why you would want to make Xref different. Nobody really
cares about Xref, so long as the list of <location>s in it can be
extracted so as to prevent crossposts from showing up twice. The
<server-name> there is really only for humans to look at.

---

From: [email-masked] (Kai Henningsen)
Date: 08 Sep 2005 22:18:00 +0200

>       through which its administrators can be contacted; alternatively

I think you're missing here a FQDN not associated with any of these,  
possibly not even existing according to DNS, but within "your" sphere of  
administration - that is, a FQDN which "you" could make exist or associate  
with one of the above, but haven't.

Because I'd still see that preferrable to your case 2, and it's certainly  
a case where whoever decides on the name has control over the uniqueness  
of the name just as for 1.

You currently subsume this under 3, where I don't think it belongs.

MfG Kai

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 09 Sep 2005 13:42:35 +0200

Poll text:

> articles that have IP addresses in the path as non-conformant. However,
> if we disallow them, they WILL be disallowed in Injection-info and Xref,
> which are the two other places that use them.

I've taken out ticket #1132 to cover this specific issue, rather than the 
more generic #1047 ticket. They're linked in the tracker.

> 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

> Other answers, like "you did not specify the question correctly"
Forrest J. Cavalier

I'll write up a suggested modification to section 3.2.1 based on this.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 9 Sep 2005 13:45:05 GMT

>with one of the above, but haven't.

I don't think I would really like that usage, but it could be written into
Case 1 if people want it so. We certainly need domain names that are not A
or AAAA records because some servers might not always be on line, and
might be using a leased IP. For example, my own server would use
clerew.man.ac.uk, which is an MX record (I have no fixed IP address). But
I would much prefer to stick with domain-names that resolve to at least
something in the DNS.

>>       of the earlier options is provided as well.

One of my worries is that <bareword>s (as we seem to be calling case 3)
will also need a syntax. Clearly it will not allow a ':' (that is where
this whole argument started), but would it allow a domain-name, or even an
IPv4Address (which would defeat the object of the proposed restriction)?

Maybe a <bareword> should be defined as needing to contain at least one
ALPHA.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 10 Sep 2005 15:39:13 +0200

--On fredag, september 09, 2005 13:45:05 +0000 Charles Lindsey 
<[email-masked]> wrote:

>>  administration - that is, a FQDN which "you" could make exist or
>> associate   with one of the above, but haven't.
>
> Case 1 if people want it so.

I think you can make that a Case 2; given that your previous case 2 should 
disappear, the number's free.

There's tradition for using DNS names like that - in another discussion, I 
got the following piece quoted at me from RFC 2486, Section 6:

   NAI realm names are required to be unique and the rights to use a
   given NAI realm for roaming purposes are obtained coincident with
   acquiring the rights to use a particular fully qualified domain name
   (FQDN).  Those wishing to use an NAI realm name should first acquire
   the rights to use the corresponding FQDN. Using an NAI realm without
   ownership of the corresponding FQDN creates the possibility of
   conflict and therefore is to be discouraged.

(NAIs are the things that look just like email addresses but aren't - they 
are used as principal identifiers in some VPN authentication schemes).

---

From: [email-masked] (Kai Henningsen)
Date: 11 Sep 2005 10:51:00 +0200

> Maybe a <bareword> should be defined as needing to contain at least one

Hmm.

I think the only place I've seen the term used before was in Perl, and so  
to me it suggests the syntax of a language identifier - that is, a letter  
followed by letters, digits, and underscores, and nothing else - and that  
includes no dots.

If that's not what we mean, I would very much prefer us using a different  
name for it.

MfG Kai

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 12 Sep 2005 12:28:54 GMT

>   conflict and therefore is to be discouraged.

Yes, but that does not go as far as Forrest was suggesting. RFC 2486 makes
it clear that if you want to use foo.bar.example.com as an NAI realm, then
it had better resolve to _something_ in the DNS (though maybe a mere TXT
record would suffice).

What Forrest seems to be suggesting is that, if bar.example.com belongs to
you, and is recorded in the nameserver for example.com, then you should
automatically be allowed to use foo.bar.example.com as a <path-identity>
without having it recorded in the DNS, either by the nameserver at
example.com, or by whatever nameserver you establish for bar.example.com.

That is going too far for my taste (though it could certainlky be written
into USEPRO if that is what this WG really wants).

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 12 Sep 2005 14:13:23 GMT

In <9F009A3C66B6C79AEB4756D7@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>I've taken out ticket #1132 to cover this specific issue, rather than the=20

>> NO - IP addresses should not be allowed as path-identity.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 12 Sep 2005 12:49:42 GMT

>followed by letters, digits, and underscores, and nothing else - and that  

The term was introduced by Harald ro describe all those <path-identity>s
that were neither domain names nor IP addresses.

And actually, I think restricting their syntax to what you describe might
actually make good sense. Does anyone know of existing practice contrary
to that?

>If that's not what we mean, I would very much prefer us using a different  

Sure.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 12 Sep 2005 16:34:34 +0200

[Changing subject - far off thread]

> it had better resolve to _something_ in the DNS (though maybe a mere TXT

No, it explicitly does not.
I did not quote all of RFC 2486, but the document makes it very clear that 
there is NO requirement for *anything* to be at this point in the DNS.

The requirement for using foo.bar.example.com as a NAI is that you have a 
"right to use" the name foo.bar.example.com in the DNS.
This can be an agreement with the bar.example.com administrator, or an 
agreement with the example.com administrator (if bar isn't administered 
separately) - there's no need for anything in the DNS.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 13 Sep 2005 05:18:27 +0200

>    path-identity = dot-atom-text / bareword

Hi, you can't say <dot-atom-text> here, it contains some
characters we don't like (delimiters for 1036 incl. "!"):

ATEXT: ALNUM ! # $ % & ' * + - / = ? ^ _ ` { | } ~
LDH  : ALNUM                           _

Let's stick to some kind of <ldh-string>.

>    bareword = ALPHA *( [ "-" / "_" ] (ALPHA / DIGIT) )

Yes.  For a "bare" version of <ldh-string> you'd get...

     ldh-fqdn = ALPHA *( [ "-" / "." ] (ALPHA / DIGIT) )

...or similar.  And for an unambiguous bareword without
underscore you'd need the "at least one dot" kludge, i.e.

 path-identity = ( 1*( label "." ) label ) / bareword
 label         = alphanum [ *( alphanum / "-" ) alphanum ]
 alphanum      = ALPHA / DIGIT

There are several cases of ALPHA / DIGIT in USEFOR, so the
additional <alphanum> is justified.

With that version of <label> there's still an unnecessary
ambiguity with <IPv4address>, it can be solved by <toplabel>:

 path-identity = ( 1*( label "." ) toplabel ) / bareword
 label         = alphanum [ *( alphanum / "-" ) alphanum ]
 toplabel      = ALPHA    [ *( alphanum / "-" ) alphanum ]
 alphanum      = ALPHA / DIGIT

IIRC we already had this part of the syntax before in the
discussions.

>    tail-entry = dot-atom-text / bareword

No <dot-atom-text>, just say tail-entry = path-identity

>    source-identity = dot-atom-text / IP-address / bareword

Dito, source-identity = path-identity / IP-address

Actually I don't see the point of bareword here, is that for
POSTED and MISMATCH in this variant ?  You could enumerate it:

     source-identity = ( 1*( label "." ) toplabel )
                     / "MISMATCH" / "POSTED" / IP-address

>    IP-address = IPv4address / IPv6address ;  see [RFC 3986]

Okay.  The latter has always a colon, so that's unambiguous
(add usual dead:beef rant here).  The former has always three
dots and digits, but never an ALPHA => no <toplabel>, no FQDN.

> distinguishable from <path-identity>s.]
[...]

>    path-identity = dot-atom-text / bareword

See above, better use <label> - in this variant an IPv4 is
always unambiguous, you don't need the <toplabel> detail.

>    tail-entry = dot-atom-text / bareword

See above, tail-entry = path-identity or, as you have it,
just the same syntax, but not the <dot-atom-text> version.

>    source-identity = dot-atom-text / IP-address / bareword

Something's wrong here, your syntax aparently allows...

     path-identity!path-identity!POSTED!path-source!
     path-identity!path-identity path-source!
     path-identity!path-identity

The third case is wrong, you want an "!" at the end, always.
The second case is also wrong, missing "!" before the source.

>  Two "!"s in succession are equivelent to
> "!site.example.MATCH!"

Okay, here's the fixed (?) version:

     path-entry = 1*( path-identity "!" )
                  [ "POSTED!" ] [[ path-source ] "!" ]

Skipping the prose, please could somebody else check this ?

                           Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 13 Sep 2005 05:35:40 +0200

Harald Tveit Alvestrand wrote:
 
> The requirement for using foo.bar.example.com as a NAI is
> that you have a "right to use" the name foo.bar.example.com
> in the DNS. This can be an agreement with the bar.example.com
> administrator
[.,.]
> there's no need for anything in the DNS.

Apparently the same idea as for <id-domain>, the wildcard for
xyzzy.claranet.de isn't a required part of the show (and with
some stupid spammers taking everything they see with an "@"
it's actually a PITA)
                     Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 13 Sep 2005 11:23:16 GMT

>separately) - there's no need for anything in the DNS.

The problem with that is that a "right" which is only established by some
verbal or written agreement with some administrator cannot be verified
externally.

The wording in RFC 2486 is far from clear.

  Those wishing to use an NAI realm name should first acquire the rights
  to use the corresponding FQDN.

It does not define "rights". If the nameserver for example.com does not
contain an NS or SOA record for bar.example.com, then the "right" to
foo.bar.example.com remains with example.com. OTOH, if such an NS or SOA
record does exist, then the "right" belongs to whoever owns the nameserver
contained therein, which would presumably be bar.example.com.

  Using an NAI realm without ownership of the corresponding FQDN creates
  the possibility of conflict and therefore is to be discouraged.

Again, what does "ownership" mean, and how does it relate to "rights"?

  Note that the use of an FQDN as the realm name does not imply use of the
  DNS for location of the authentication server or for authentication
  routing.

Which indicates that you don't have to use the DNS to locate the NAI host
(indeed, the DNS may not contain that nformation). But it seems that you
still need the DNS, or some part of it, in order to establish those
"rights" or "ownership".

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 14 Sep 2005 12:00:53 GMT

>characters we don't like (delimiters for 1036 incl. "!"):

Yes, you are correct. I was following the over-liberal RFC 2822, rather
than the down-to-earth RFC 2821. And even RFC 2821 allows things that RFC
1035 doesn't, such as subdomains starting with a digit.														

>     ldh-fqdn = ALPHA *( [ "-" / "." ] (ALPHA / DIGIT) )

OK, I have now s/dot-atom-text/fqdn/ everywhere, and I have

   fqdn = 1*( label "." ) label 
   label = ALPHA *( [ "-" / "." ] (ALPHA / DIGIT) ) 

>ambiguity with <IPv4address>, it can be solved by <toplabel>:

No, there is no need for that. Every <label> has to begin with ALPHA (and
that was in RFC 1035), so if you see anything with just digits and "."s
in it, it is either an <IPv4address> or it is a syntax error.

>No <dot-atom-text>, just say tail-entry = path-identity

No, because I want to be able to say, in USEPRO, that if you see any
<path-identity> that is the name of one of your peers, then you don't
relay it to that peer. But that only works if there is no <path-identity>
inside a <tail-entry>.

>POSTED and MISMATCH in this variant ?  You could enumerate it:

No, you still need <bareword> as a possibility for <source-identity>,
because the article may have arrived by UUCP, or it may have arrived from
an uninteresting IP address leased to a dialup, and what you want to quote
is the "true source of the article" which you only knew because the
sending site authenticted itself with SASL, using some <bareword> as its
identity.

>Okay.  The latter has always a colon, so that's unambiguous

I think we have to accept that this grammar is always going to be
ambiguous (but mostly it doesn't matter). Harald's grammar is even more
ambiguous.

>The second case is also wrong, missing "!" before the source.

No, I want a "!" at the end never, except when I am trying to construct
the "!!" case. And it is actually wrong in both versions of my syntax. Try
this:

[1st version]
   path-entry = path-identity *( "!" path-identity ) [ "!" "POSTED" ]
                  [ "!" [ source-identity [ "!" "MISMATCH" ] ] ]
[2nd version]
   path-entry = path-identity *( "!" path-identity )[ "!" "POSTED" ]
                   [ "!" [ path-source ] ]

>>  Two "!"s in succession are equivelent to

or a missing <path-source> (which gives rise to "!!") means it MATCHed.

Note also that my syntax severely limited where [FWS] was allowed
(essentially between things added by one site). If you want to relax that,
then I shall have to take care it does not arise inside a "!!".

---

From: Bill McQuillan <[email-masked]>
Date: Wed, 14 Sep 2005 14:36:05 -0700

> in it, it is either an <IPv4address> or it is a syntax error.

Actually RFC 1035 was superceded by RFC 1123 section 2.1 which states that
each label except the TLD may be all-numeric.

-- 
Bill McQuillan <[email-masked]>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 14 Sep 2005 23:38:07 +0200

> in it, it is either an <IPv4address> or it is a syntax error.

3com killed that piece of RFC 1035 many years ago.
These days, 121.net is a valid domain (belonging to a Hong Kong company).

Sorry, reality intruded.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 15 Sep 2005 03:20:28 +0200

Charles Lindsey wrote:

> Every <label> has to begin with ALPHA

That's unfortunately not more the case for the ldh-rule,
it's only the toplabel (compare RfC 2396 and others).

If you and Harald want to "allow" underscore you cannot
exclude "non-toplabel starting with DIGIT" at the same
time, that would be inconsistent.

>> say tail-entry = path-identity
> No

ACK, here I dropped the "starts with DIGIT" ball.

 [about no bareword> in <source-identity>]
> No, you still need <bareword> as a possibility for
> <source-identity>, because the article may have arrived
> by UUCP, or it may have arrived from an uninteresting IP
> address leased to a dialup, and what you want to quote
> is the "true source of the article" which you only knew
> because the sending site authenticted itself with SASL,
> using some <bareword> as its identity.

Sigh...  okay, IIRC Harald's proposal also covered that
idea, so "diag" or "source" can be an IP or just anything
also allowed as <path-identity>.

> I think we have to accept that this grammar is always going
> to be ambiguous (but mostly it doesn't matter). Harald's
> grammar is even more ambiguous.

Your second version (pseudo-TLD ".MISMATCH") had that clear.
It's possible to preserve this idea for "!MISMATCH" if we
restrict "diag" to "diag!MISMATCH".

Otherwise it's hard to see the point of "diag":  If nobody
but the site adding it knows what it is it's that red and
green sparkled duck feeding itself with dead:beef...

...at least we asked it to stay out of Injection-Info and
Xref, is that really all, syntactically ?

> my syntax severely limited where [FWS] was allowed
> (essentially between things added by one site). If you
> want to relax that, then I shall have to take care it
> does not arise inside a "!!".

I've no problem with "!" [FWS] "!" if that allows for a
syntax where we get this concept:

- either an (old) site doesn't care, then it shouldn't
  mess with "POSTED" / MISMATCH / "!!" / "diag" / "source"

- or it cares, then the two main cases (excl. POSTED) are
  "diag!MISMATCH!" or "!" (= match).

I consider the left of two adjacent "!" as shorthand for
"source!MATCH!" in a Path: site!source!MATCH!source!...

Not because I like potential cases of "!" FWS "!", but
as concept _IFF_ we want to restrict "diag" to "MISMATCH":

 path-diag = [ path-sep "POSTED" ]
             [ ( path-sep ( IP-address / path-identity )
                  path-sep "MISMATCH" ) / ( [FWS] "!" ) ]
                                          ^^^^^^^^^^^^^

The part ( [FWS] "!" ) is that match-shorthand.  For a
syntax with those read and green sparkled ducks it's of
course a bad idea to allow [FWS] "within" the "!!" case.

At least Harald's version allowed ...!!MISMATCH... or
...MISMATCH!!...  I hoped to remove this oddity somehow.

                    Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 15 Sep 2005 16:04:43 GMT

>each label except the TLD may be all-numeric.

Except that I see nothing in RFC 1123 that says the TLD is to be treated
differently. Frank found a nice syntax for <hostname> in RFC 2396, but its
successor RFC 3986 has removed that, and refers you instead to RFC 1034
plus RFC 1123. So it would seem that there is nowhere any standard syntax
for what a domain name looks like, although "everybody" (TINE) seems to
know what it is.

There is also the interesting question whether you are allowed two "-"s
in succession. Apparently you are, so I have incorporated that (and
allowed it in <bareword> too for good measure).

So here now are the two versions of my syntax, incporporating various
changes from recent discussions. There are still possibilities to simplify
them in the direction of Frank's version, or even Harald's. However, life
would be simpler if we could have some views on which of my two
alternatives we want to use for further progress (i.e. do we want to be
able to distinguish <source-identity>s from <path-identity>s by the
presence of .SEEN/.MATCH/.MISMATCH, or somesuch)?

   path-identity = fqdn / bareword

   fqdn = 1*( label "." ) toplabel

   label = alphanum / alphanum *( alphanum / "-" ) alphanum

   toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum

   alphanum = ALPHA / DIGIT

   bareword = ALPHA / ALPHA *( alphanum / [ "-" / "_" ] ) alphanum )

   tail-entry = fqdn / bareword

   source-identity = fqdn / IP-address / bareword

   path-identity = fqdn / bareword

   fqdn = 1*( label "." ) toplabel

   label = alphanum / alphanum *( alphanum / "-" ) alphanum

   toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum

   alphanum = ALPHA / DIGIT

   bareword = ALPHA / ALPHA *( alphanum / [ "-" / "_" ] ) alphanum )

   tail-entry = fqdn / bareword

   source-identity = fqdn / IP-address / bareword

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 15 Sep 2005 16:13:28 GMT

>syntax where we get this concept:

No, I would not like that. These Path headers, as folded, are going to be
read by humans. If they see a single "!" at the end of a line, or at the
start of a following line, then they will be happy and think they
understand it (not noticing that a line ending with "!" was immediately
followed by another line beginning with "!"). If we are going to use the
"!!" notation, then it needs to stick out like a sore thumb, so that
everybody reading the header will easily spot it.

I covered it in my version by disallowing [FWS] before a "!" (assuming it
would be a good practice to always split lines in a comsistent and
standard way). But if people want to permit [FWS] either before or after a
"!", then I am sure that a grammar can still be written that will prevent
FWS in the middle of a "!!". Opinions on whether we want to allow [FWS] on
either side of a "!"?

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 16 Sep 2005 05:44:28 +0200

Charles Lindsey wrote:

> I covered it in my version by disallowing [FWS] before a "!"

Cute, it also simplifies my "either !! or diag!MISMATCH!" idea.

BTW, Richard reports that in reality "diag!MISMATCH!" uses the
format "diag.MISMATCH" (as in your second version).  Time for
a new attempt to put it all together.  Goals:

1 - either !! [FWS] or ! [FWS]
2 - allow "_" in labels or bareword
3 - pseudo-TLD MISMATCH allows to identify "diag.MISMATCH!"
4 - IPs only in <diag> => <toplabel> details irrelevant
5 - colon only for IPv6 in "<diag>.MISMATCH!", duck or grouse
6 - <tail-entry> may start with DIGIT, anything (?) goes that
    is NOT 1036-punctuation (incl. ":") or WSP or CTL

Talking about "anything goes" in <tail-entry>, what precisely
is this ?  What about "$", "+", "#", "%", "@" ?   Whatever we
say, this is a major difference from 1036, we have to mention
it in the "differences from 1036" appendix.

 path          = "Path:" SP [FWS] path-list [FWS] CRLF
 path-list     = *( path-entry "!" {FWS] ) tail-entry
 path-entry    = path-identity [ path-diag ]

 tail-entry    = 1*( aplphanum / "-" / "_" / "." )    ; TBD ?!?

 path-identity = *( path-label "." ) path-label
 path-label    = alphanum [ *( alphanum / "-" / "_" ) alphanum ]
 alphanum      = ALPHA / DIGIT 

 path-diag     = [ "!" [FWS] "POSTED" ]
                 [ "!" 
                   [ [FWS] ( IPv4address       ; see [RFC 3986]
                           / IPv6address       ; see [RFC 3986]
                           / path-identity ) ".MISMATCH" ] ]

If we prefer a variant with "!" [FWS] "MISMATCH" it's obvious
where to change this proposal.  

It does NOT support Russ' idea "add <diag> without checking,
and therefore also without a MISMATCH".

                           Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 16 Sep 2005 07:00:45 +0200

Charles Lindsey wrote:

> Frank found a nice syntax for <hostname> in RFC 2396

Credits to Wayne Schlitt... ;-)  The prose for the LDH-rule
is in John's 3696, and of course there's a subtlety, 3696
says "at least one ALPHA in a TLD", not "start with ALPHA".

> its successor RFC 3986 has removed that, and refers you
> instead to RFC 1034 plus RFC 1123.

Maybe we need a 3696bis as a BCP, not only "informational".
The relaxed 3696 idea without optional trailing dot is:

 domain   = 1*( label "." ) toplabel     ; at least one dot
 label    = alphanum [ *( alphanum / "-" ) alphanum ]
 toplabel = [ label ] ALPHA [ label ]    ; at least one ALPHA

The stricter and simpler SPF idea copied from 2396 etc. is:

 domain   = 1*( label "." ) toplabel     ; at least one dot
 label    = alphanum [ *( alphanum / "-" ) alphanum ]
 toplabel = ALPHA    [ *( alphanum / "-" ) alphanum ]

Really sad that this detail didn't hit any "IETF last call"
after 2396, at the moment we can only hope that ICANN won't
break both.

> So it would seem that there is nowhere any standard syntax
> for what a domain name looks like, although "everybody"
> (TINE) seems to know what it is.

The (apparent) consensus here to allow "_" in addition to
"-" is already at odds with what "everybody" thinks to know.

> There is also the interesting question whether you are
> allowed two "-"s in succession.

There might be some restrictions for 2ALPHA "--" at the begin
of a label not limited to "xn--".  But I'm too lazy to check
if that's policy or standard or whatever.

> do we want to be able to distinguish <source-identity>s from
> <path-identity>s by the presence of .SEEN/.MATCH/.MISMATCH,
> or somesuch)?

IMHO a <source> is only relevant for !source.MISMATCH! cases.

For !source.MATCH! we offer !! as shorthand, IMO good enough.

Russ' concept (your source.SEEN! would be new, so far I don't
see the point.  Let's say a site got the path claimed-id!...

If site isn't "lazy" the path (modulo POSTED) would be either
site!!claimed-id!...  or  site!source.MISMATCH!claimed-id!...

IIRC Russ said that the site is "lazy", but still wants to add
some diagnostics.  If that's a <path-identity> it could simply
say site!path-id!claimed-id!...

Or even site!!path-id!claimed-id!... (is that really okay ?)

We're only in trouble (syntactically) if a "lazy" site insists
on adding an IP:  site!ip-address!claimed-id!...  would be a
red duck styling itself as green grouse, only in that case a
site!ip-address.SEEN!claimed-id!...  is better (or necessary)

                     Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Thu, 15 Sep 2005 22:15:14 -0700

Charles Lindsey <[email-masked]> writes:

> I covered it in my version by disallowing [FWS] before a "!" (assuming
> it would be a good practice to always split lines in a comsistent and
> standard way). But if people want to permit [FWS] either before or after
> a "!", then I am sure that a grammar can still be written that will
> prevent FWS in the middle of a "!!". Opinions on whether we want to
> allow [FWS] on either side of a "!"?

I'll make a brief plea to disallow [FWS] after "!" rather than before, if
you're introducing folding, on the same grounds that most programming
style guides recommend:

    if (a
        && b)

rather than:

    if (a &&
        b)

This message should not be taken as support for the idea of folding the
Path header in general.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 15 Sep 2005 22:49:40 +0200

--On 15. september 2005 16:04 +0000 Charles Lindsey <[email-masked]> 
wrote:

>>> No, there is no need for that. Every <label> has to begin with ALPHA
>>> (and that was in RFC 1035), so if you see anything with just digits and
>>> "."s in it, it is either an <IPv4address> or it is a syntax error.
>
>> Actually RFC 1035 was superceded by RFC 1123 section 2.1 which states
>> that each label except the TLD may be all-numeric.
>
> differently.

How about this?
>
>            If a dotted-decimal number can be entered without such
>            identifying delimiters, then a full syntactic check must be
>            made, because a segment of a host domain name is now allowed
>            to begin with a digit and could legally be entirely numeric
>            (see Section 6.1.2.4).  However, a valid host name can never
>            have the dotted-decimal form #.#.#.#, since at least the
>            highest-level component label will be alphabetic.
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Actually, we are somewhat at the mercy of ICANN here, but so far, I haven't 
seen even a single application for an all-numeric (or even seminumeric) TLD.

> allowed it in <bareword> too for good measure).

One word: IDN.
All IDN components (in ASCII form) are prefixed with xn--.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 16 Sep 2005 08:19:25 +0200

Russ Allbery wrote:

> I'll make a brief plea to disallow [FWS] after "!" rather
> than before

For my wannabe-simplified path ABNF that would result in:

 path          = "Path:" SP [FWS] path-list [FWS] CRLF
 path-list     = *( path-entry [FWS] "!" ) tail-entry
 path-entry    = path-identity [ path-diag ]

 tail-entry    = 1*( alphanum / "-" / "_" / "." )    ; TBD ?!?

 path-diag     = [ [FWS] "!POSTED" ]
                 [ "!" /                 ; match => "!!"
                   ( [FWS] "!"
                     ( IPv4address       ; see [RFC 3986]
                     / IPv6address       ; see [RFC 3986]
                     / path-identity ) ".MISMATCH" ) ]

If you prefer your "lazy IP-diagnostics" = Charles' .SEEN
please replace the ".MISMATCH" by ( ".SEEN" / ".MISMATCH" )
in this proposal.

Open questions:  what is allowed in a <tail-entry> ?

Is Charles ready to drop the "multi-id per entry" idea in
the syntax ?  If not adding it is simple:

--- multi id. ---
 path-entry    = *( path-identity [FWS] "!" ) path-identity [ path-diag ]
--- --------- ---

So that's one proposal with two optional tweaks .SEEN and / or
"multi-id", and the <tail-entry> details TBD.  Bye, Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 16 Sep 2005 13:44:05 +0200

> please replace the ".MISMATCH" by ( ".SEEN" / ".MISMATCH" )

You've removed "path-keyword" - so what you're proposing is different from 
what's specified in the current documents, not just a different syntax.

I'm hesitant to change what's in the documents, but I think there's still 
no implementation of these features, and getting the keywords into the 
diagnostics rather than treating them separately appeals to me.

                   Harald

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 16 Sep 2005 14:34:27 +0200

Harald Tveit Alvestrand wrote:

> You've removed "path-keyword" - so what you're proposing is
> different from what's specified in the current documents,
> not just a different syntax.

Actually I'm lost what the server folks here (Richard, Russ,
Forrest) really want.  Richard said what he sees in practice 
is the diag.MISMATCH-style, that's Charles's second variant
(with a similar diag.SEEN).

OTOH he said that this has no effect, and a log file makes
more sense.  For a real effect it has to be source!MISMATCH
(or similar source!SEEN) with source = path-id instead of
diag = IP (or path-id).

That's quite different,  Supporting both concepts at the
same time is something I don't understand, but I hope that
somebody will explain where that's still better than say

         path = "Path:" SP *( VCHAR ) CRLF

                        Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Fri, 16 Sep 2005 11:02:20 -0700

> Forrest) really want.

Between the various alternativesly currently being discussed, I have no
strong opinions.  I think they'd all likely work.  The only caveat is that
I think it would be useful to allow, however tagged or indicated, a server
to just always put diagnostic information into the Path for all peers
rather than requiring that all servers using the new Path format do Path
identity checking.

> Richard said what he sees in practice is the diag.MISMATCH-style, that's
> Charles's second variant (with a similar diag.SEEN).

Right, Diablo does this now and Andrew submitted a patch to INN to do this
as well, a long time back, which I haven't applied because I was waiting
for the working group to converge on a recommendation for how this
information should be formally represented.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Sep 2005 11:32:58 GMT

In <171EBBFFC2E070D0E8648F37@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>--On 15. september 2005 16:04 +0000 Charles Lindsey <[email-masked]>=20
>wrote:

>>            highest-level component label will be alphabetic.

OK. Point noted (though "will be alphabetic" is not quite the same thing
as "MUST be alphabetic"). Anyway, all the syntaxes under discussion
incorporate it.

>seen even a single application for an all-numeric (or even seminumeric) =
>TLD.

We are actually at the mercy of ICANN for several things, including
"example", "POSTED", "MISMATCH, etc.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Sep 2005 12:50:14 GMT

>you're introducing folding, on the same grounds that most programming

No problem with that. I have made a note to put it before in the next
version of my syntax (modulo whatever comes out of Harald's latest
initiative).

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Sep 2005 13:23:02 GMT

>rather than requiring that all servers using the new Path format do Path

That checking is currently a MUST in USEPRO (to encourage sites to upgrade
ASAP). I think you are suggesting reducing it to SHOULD. That can easily
be done if the WG wishes, though I personally prefer MUST.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Sep 2005 13:18:49 GMT

>what's specified in the current documents, not just a different syntax.

There are two issues here, and it is important to realise they are
orthogonal and can be decided separately.

1. Do the keywords take the form of (a) ...!KEYWORD!... or (b)
...!foo.example.KEYWORD!... .

2. What set of keywords (POSTED/SEEN/MATCH/MISMATCH/WHATEVER) do we
provide?

Ad #1, I opriginally proposed ...!KEYWORD!..., and it was accepted (hence
that is the current official WG position). The reason was that if you
allow

...!injector.example.com.POSTED!tail-entry

then a site that peers with injector.example.com will not know that it is
not supposed to relay the article back to injector.example.com. OTOH, it
does not matter with

...!news.example.com.MISMATCH!bogus.example.com!...

because you are not supposed to look at <diagnostic/source-identity>s when
deciding which peers to relay to. Note that there is some existing
practice with style (b) with both MISMATCH and POSTED.

Hence my proposed 2nd alternative used style (b) for MISMATCH et al, but
still used style <a) for POSTED.

Ad #2, POSTED is presumably non-controversial, as it MISMATCH. There seems
some merit in SEEN (so that all <diagnostic/source-identity>s are
immediately recognizable as such). MATCH is just for the sake of
completeness; it is redundant and would be discouraged in USEPRO; if the
WG wants to omit it, I have no problem.

>diagnostics rather than treating them separately appeals to me.

Essentially, you are supporting style (b), but maybe not for POSTED.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Sep 2005 12:57:39 GMT

>Open questions:  what is allowed in a <tail-entry> ?

Given that it's intended to be ignored, it doesn't really matter provided
there is nothing that might ever be recognized as a delimiter inside it.
My present thought is just

tail-entry = 1*( alphanum / "-" / "_" / "." )

>the syntax ?  If not adding it is simple:

I have no huge problem with that, provided it is made clear somewhere,
i.e. USEPRO, that a site can add several entries it it wishes (e.g.
...!demon!news.demon.co.uk!... so as to keep all its peers happy). The
only difference my syntax would make is that it would not allow a
<source-identity> in the middle of one site's bunch (it would be stupid to
do so, but no great harm would arise).

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Sep 2005 11:53:12 GMT

>The relaxed 3696 idea without optional trailing dot is:

What we actually need is a 1034/1035bis :-( .

> toplabel = [ label ] ALPHA [ label ]    ; at least one ALPHA

OK, I've put that into my syntax proposal.

>"-" is already at odds with what "everybody" thinks to know.

Eh? There is no proposal anywhere to allow "_" in FQDNs. It is proposed to
allow it in <bareword>s, because it always has been so since out earliest
drafts, and there is apparently some usage (someone said so here recently
IIRC).

>IMHO a <source> is only relevant for !source.MISMATCH! cases.

But there is existing practice to insert the source (usually as an
IP-address) by sites which apparently haven't checked whether it MATCHes
or not. Hence the proposal to introduce ".SEEN" (or "!SEEN!").

Whether you then introduce ".MATCH" (or "!MATCH!") is just a matter of
being consistent by offering the complete set. If it is allowed, USEPRO
will certainly discourage you from using it, in favour of "!!".

>Or even site!!path-id!claimed-id!... (is that really okay ?)

No, because that looks like the same site inserted both path-id and
claimed-id (just to cover all its options - like demon who might want both
"demon" and "news.demon.co.uk" to be present because some peers expected
one and some the other).

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 20 Sep 2005 02:58:52 +0200

Charles Lindsey wrote:

> We are actually at the mercy of ICANN for several things,
> including "example", "POSTED", "MISMATCH, etc.

"example" etc. are in a BCP:  <http://purl.net/net/rfc/2606>

"POSTED" and "MISMATCH" are some madness found in the wild.

I'd prefer a clean solution, maybe 'all top labels starting
with x- are invalid' resulting in "x-POSTED" etc.

OTOH there is already "invalid" for this purpose - whatever
we do, we lose. same problem as with "local".

                             Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 20 Sep 2005 03:52:15 +0200

Charles Lindsey wrote:

  [3696 rule for TLDs]

> OK, I've put that into my syntax proposal.

Oops, careful, it was wrong, I forgot the critical hyphens for
labels like 12-A--3.  A bit like <id-special> aka <mqspecial>:

   domain   = 1*( label "." ) toplabel     ; at least one dot
   label    = alphanum [ *( alphanum / "-" ) alphanum ]
   toplabel = [label *( "-" )] ALPHA [*( "-" ) label]

We don't need these <toplabel> details for something remotely
related to your pseudo-TLD .MISMATCH version (second version).

> Eh? There is no proposal anywhere to allow "_" in FQDNs.

Harald mumbled something in that direction, and you refused for
months to kill the underscores in non-<bareword>s:

 <http://permalink.gmane.org/gmane.ietf.usenet.format/30046>
|> Like Charles you also have an "_" in the <path-identity> for
|> the non-<bareword> case.

| Yep. Allowing _ in hostnames seems to be an old tradition for
| USEFOR drafts, and I didn't change it for this.

If you now say that this was all wrong and underscores are of
course nonsense outside of <bareword> or <tail-entry> it will
again change the resulting syntax:

 path-identity = ( 1*( path-label "." ) path-label ) / bareword
 path-label    = alphanum [ *( alphanum / "-" ) alphanum ]
 bareword      = alphanum [ *( alphanum / "-" / "_" ) alphanum ]
 alphanum      = ALPHA / DIGIT

 path-diag     = [ [FWS] "!POSTED" ]
                 [ "!" /                 ; match => "!!"
                   ( [FWS] "!"
                     ( IPv4address       ; see [RFC 3986]
                     / IPv6address       ; see [RFC 3986]
                     / path-identity )
                     ( ".MISMATCH" / ".SEEN" ) ) ]

Bill's parser still says "no error".  I'd prefer to rename the
<bareword>, how about <obs-id> ?  It's an obs-cenity and broken
by design, the world map project died in the second millennium.

                         Bye, Frank

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Mon, 19 Sep 2005 22:10:31 -0400

> we do, we lose. same problem as with "local".

!example.com..POSTED!tail

or the easier to parse....

!.POSTED.example.com!tail

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 20 Sep 2005 11:28:49 GMT

>"example" etc. are in a BCP:  <http://purl.net/net/rfc/2606>

Unfortunately, ICANN never signed up to RFC 2606, and the claim within the
RFC that IANA had signed up to it appears not (or no longer) to be true if
you search the IANA site. "invalid" has the same problem.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 20 Sep 2005 11:43:20 GMT

>!.POSTED.example.com!tail

But neither of those will be recognised as "example.com" by a relayer
which is not supposed to send articles back to there (unless its 'sys'
file has been deliberately pre-loaded with "example.com..POSTED", etc).

That is why we invented the ...!example.com!POSTED!... notation (as in our
present draft), and which I still retain even in my 2nd alternative.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 20 Sep 2005 11:38:20 GMT

>   toplabel = [label *( "-" )] ALPHA [*( "-" ) label]

OK, I now have that.

>|> the non-<bareword> case.

Eh? In all my proposed syntaxes, AFAIR, the "_" was only in the <bareword>
within the <path-identity> (which it still is).

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Sep 2005 14:53:27 +0200

Charles Lindsey wrote:

> Unfortunately, ICANN never signed up to RFC 2606

How's "verisign up" supposed to work in the case of ICANN ?

I'd guess that there was an "IETF last call" for this BCP,
and if they didn't like it their objection didn't make it
into the final text or into a published appeal.

But actually I think they have no problems with RfC 2606,
IANA hosted the (dummy) <http://example.org> etc. pages
for the three example SLDs defined in RfC 2606 chapter 3.

A Google search "2606 site:icann.org" resulted in 25 hits,
some indicate that ICANN does know and support this BCP,
e.g. <http://www.icann.org/tlds/tld-criteria-15aug00.htm>

> the claim within the RFC that IANA had signed up to it
> appears not (or no longer) to be true if you search the
> IANA site.

For the reserved TLDs it's a semantical problem, they
don't "exist", they are forever reserved.  Probably the
Web master is no Escher-fan, otherwise (s)he could list
"TLD example" and the other three as "this is no TLD" ;-)

                      Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 21 Sep 2005 16:08:28 +0200

Charles Lindsey wrote:

> Eh? In all my proposed syntaxes, AFAIR, the "_" was only in
> the <bareword> within the <path-identity> (which it still
> is).

The first <bareword>-enabled versions used <dot-atom-text> -
at the moment I don't find the older underscore-discussions.

                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 22 Sep 2005 13:53:58 GMT

>I'd guess that there was an "IETF last call" for this BCP,

I don't think the IETF procedures were quite as rigorous in those days -
and a BCP is not in itself mandatory.

>for the three example SLDs defined in RfC 2606 chapter 3.

Yes, but they never hosted or reserved example (etc) as a TLD (which
technically could have been done in the same way as those three).

And all of invalid.[org,com,net] are already taken (and not by IANA).

>e.g. <http://www.icann.org/tlds/tld-criteria-15aug00.htm>

Right! I did not spot that one on my previous searches through IANA. I am
much happier now.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Sep 2005 10:49:47 +0200

> Right! I did not spot that one on my previous searches
> through IANA. I am much happier now.

Happier ?  You're not hoping that they'd add POSTED, SEEN,
and MISMATCH to their list only because one obscure USEFOR
RfC waiting in the queue for USEPRO and USEAGE says so, or
are you ?

Some folks want a TLD ".berlin", and from there to ".seen"
(= de for ".seas") would be only a small step.  Forrest's
ideas, keywords before diag and / or "impossible" keywords
starting with a dot (or maybe underscore) could guarantee
to avoid potential conflicts.
                              Bye, Frank

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 23 Sep 2005 07:29:42 -0400

> to avoid potential conflicts.

I think prefix dot is much better than underscore.  Many
internationalization overloads have been proposed using a prefix 
underscore in the past.

Why use up that option and force future innovators into a corner for 
no good reason?

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Sep 2005 15:06:58 +0200

Forrest J. Cavalier III wrote:

> I think prefix dot is much better than underscore.

Underscore is a "traditional" way to do "funny" things
with DNS labels.  Or at least it pops up in discussions
I've seen again and again (MARID, DKIM, etc.)

For labels a dot would be the worst idea after 0xFF ;-)

Okay, here we're not really creating DNS labels, we
only try to avoid potential conflicts with FQDNs.

As far as host names are concerned undersore is good
enough - and for your dot idea there's also a (small)
chance to get it wrong if say host seen.site.example
exists with ...!.SEEN.site.example!... in the Path.

> Why use up that option and force future innovators
> into a corner for no good reason?

It's what everybody else does or proposes... <shrug />
Some problems with both "leading keyword" proposals:

- Russ or Richard said that diag-keywords like SEEN
  or MISMATCH are not really useful.

- So if we introduce it anyway let's at least stick
  to "common practice" for .MISMATCH (= pseudo-TLD)

- If we do this for .MISMATCH then using a different
  approach for "SEEN" would be odd (assuming that we
  introduce "SEEN" at all)

- Apparently it's *_not impossible_* to reserve such
  pseudo-TLDs, and I didn't know that RfC 2860 detail:
  <http://mid.gmane.org/[email-masked]>

- We're still free to do "the right thing" for POSTED,
  and introduce ...!.POSTED!... or ...!_POSTED!... (?)

                     Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 26 Sep 2005 11:41:22 GMT

>> I think prefix dot is much better than underscore.

I agree with Forrest. At least to the extent that a dot is better. But
small inconspicuous characters at the start are liable to get lost, so I
have changed my proposed syntax to

   ...!site.example.com..MISMATCH!...

which was another of Forrest's suggestions. That way we are safe if ICANN
goes mad and envents a MISMATCH TLD.

And it will be immediately recognizable by anybody who is familiar with
the current Diablo usage.

>  or MISMATCH are not really useful.

Richard I think. It was a comment by Russ that set me to propose SEEN
a few weeks back.