Subject: #1047 Path grammar proposals

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 21 Sep 2005 13:34:20 +0200

Currently I think that I have approximately 4 ABNF proposals for Path, with 
many posted variants and fiddles. They are below.

I think I see a consensus that we don't want to allow underscores in our 
domain-based identifiers, while they should be allowed in barewords and 
tail-entries; I don't see anything resembling a consensus on the exact 
format of a diagnostic.

If you prefer strongly that the USEFOR update should be based on one of the 
four variants, please say so.

                      Harald

------- Frank's of Sept 20:

 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 / "-" / "_" / "." )

 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" ) ) ]

with a suggested "domain" definition (not referenced above):

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

This has the interesting feature that it removes keywords, and changes the 
!! delimiter from a "delimiter" to "the introduction to a path-diag".

---- Charles' first proposal of Sept 15:

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

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

   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

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

--- Charles' second proposal of Sept 15:

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

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

   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

   path-source = source-identity ( ".SEEN" / ".MATCH" / ".MISMATCH" )

   source-identity = fqdn / IP-address / bareword

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

------ My proposal of September 13:

path = "Path:" SP path-list CRLF

path-list = [FWS]
  *( ( path-identity / path-keyword / path-diagnostic ) [FWS]
  path-delimiter [FWS] )
  tail-entry [FWS]

path-identity = ( ALPHA / DIGIT )
  *( ALPHA / DIGIT / "-" / "." / "_" )

path-keyword = "POSTED" / "MISMATCH"

path-diagnostic = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )

tail-entry = path-identity

path-delimiter = "!" / "!!"

This version needs an update to deal with the consensus to split barewords, 
tail-entries and domain-based identities, as sketched above.

---

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

>four variants, please say so.

I prefer either one of mine, or Frank's. Within those, there are
essentially two orthogonal questions to ask:

1. The style of the diagnostics, either
   (a) ...!example.com!MISMATCH!... or
   (b) ...!example.com.MISMATCH!... (or similar)
with POSTED probably in style (a) regardless, for technical reasons.
Note that there is existing usage of style (b) (even for POSTED, in spite
of the technical problem).

2. Which diagnostics:
   POSTED MISMATCH SEEN MATCH have been suggested. Do we want them all, or
   fewer?

> path-entry    = path-identity [ path-diag ]

This is very similar to my 2nd proposal. The essential difference is that
my <path-entry> is several <path-identity>s followed by one optional
<diag/source-identity>, whereas Frank's has just a single <path-identity>
(in which case a site that wants to insert several <path-identity>s for
itself simply inserts several <path-entry>s). I am quite happy to adopt
Frank's structure in my next edition (with appropriate mention in USEPRO).

Any remaining differences are just different ways of writing the ABNF (my
latest ABNF, discussed but not yet published in full) is eFrom [email-masked] Thu Sep 22 12:16:32 2005
To: [email-masked]
Xref: clerew local.usefor:22619
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 Path grammar proposals
Date: Thu, 22 Sep 2005 13:35:19 GMT
Lines: 97
Sender: [email-masked]

>four variants, please say so.

I prefer either one of mine, or Frank's. Within those, there are
essentially two orthogonal questions to ask:

1. The style of the diagnostics, either
   (a) ...!example.com!MISMATCH!... or
   (b) ...!example.com.MISMATCH!... (or similar)
with POSTED probably in style (a) regardless, for technical reasons.
Note that there is existing usage of style (b) (even for POSTED, in spite
of the technical problem).

2. Which diagnostics:
   POSTED MISMATCH SEEN MATCH have been suggested. Do we want them all, or
   fewer?

> path-entry    = path-identity [ path-diag ]

This is very similar to my 2nd proposal. The essential difference is that
my <path-entry> is several <path-identity>s followed by one optional
<diag/source-identity>, whereas Frank's has just a single <path-identity>
(in which case a site that wants to insert several <path-identity>s for
itself simply inserts several <path-entry>s). I am quite happy to adopt
Frank's structure in my next edition (with appropriate mention in USEPRO).

Any remaining differences are just different ways of writing the ABNF (my
latest ABNF, discussed but not yet published in full) is even closer to
Frank's. He also omits the MATCH keyword (#2 above).

>!! delimiter from a "delimiter" to "the introduction to a path-diag".

It essentially does the keywords in style (b). The meaning of "!!" is
exactly the same as the present USEFOR (modulo possible bugs concerning
[FWS], which can be fixed).

>---- Charles' first proposal of Sept 15:

This essentially takes style (a) of #1, and the minimal set from #2.

There are some small changes arising from recent discussions which I have
not published as a full set yet. I also want to put the [FWS] before the
'!' rather than after (as Russ suggested). I will probably simplify the
<path-entry> to be more like Frank's (see above). There remains the issue
of [FWS].

>--- Charles' second proposal of Sept 15:

This essentially takes style (b) of #1, and the maximal set from #2 (and
these are my personal preferences). Other remarks as above,

>------ My proposal of September 13:

This takes style (a) of #1, and the minimal set from #2.

The main differences are that it does not relate the various objects to
FQDNs, IP-addresses and barewords, it allows that ':' in places other than
IPv6addresses (hence more scope for dead:beef problems), and it contains
more ambiguities. OTOH, it is a fair representation of what servers will
in practice recognize (as opposed to the others which show what should be
generated).

>tail-entries and domain-based identities, as sketched above.

Which would actually bring it closer to the style of the others.

-- 
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: Thu, 22 Sep 2005 21:12:03 +0200

>    POSTED MISMATCH SEEN MATCH have been suggested. Do we want them all, or

A more fundamental question to address is probably whether the set of 
diagnostic keywords is cast in concrete by USEFOR or left open for future 
extension.

If it's supposed to be extensible, the USEFOR grammar should say 
"diagnostics can exist", but not "these are all the diagnostics that can 
be".

---

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

Charles Lindsey wrote:

> 2. Which diagnostics:
>    POSTED MISMATCH SEEN MATCH have been suggested.
>    Do we want them all, or fewer?

The server folks apparently say that it's all not very
useful, but at least it might cause no harm.  That's
not very encouraging, therefore I hope that we can get
rid of site!source?MATCH!source!... (for ? read . or !)
using the site!!source!... shorthand.  I hope I have
this concept in my version.

Mix this with your concept "at most one line per site",
i.e. multi-id plus optional diag plus at most one [FWS]
near the end, and it should be good enough.

Maybe add the 3696 <toplabel> concept, it's nowhere else
in syntax (all other RfCs use only "start with ALPHA").

                     Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Sep 2005 14:57:16 GMT

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

>--On 22. september 2005 13:35 +0000 Charles Lindsey <[email-masked]>=20
>wrote:

>A more fundamental question to address is probably whether the set of=20
>diagnostic keywords is cast in concrete by USEFOR or left open for future=20
>extension.

>If it's supposed to be extensible, the USEFOR grammar should say=20
>"diagnostics can exist", but not "these are all the diagnostics that can=20
>be".

That is a new suggestion which I had not considered. Yes, if the WG wants
it so it could be done (or maybe people will just do it anyway).

OTOH, Frank keeps leaning on me to shorten the list. Either way, I would
like to see some mechanism that prevented the present checks made by
relayers from being confused, even with current implementations (hence
some means - keywords/whatever - to distinguish genuine <path-identity>s
from anything else).

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Sep 2005 19:53:19 +0200

Charles Lindsey wrote:

> OTOH, Frank keeps leaning on me to shorten the list.

In fact I'd sign everything (without checking what it
is) if it's only supported by Russ + Richard + Forrest.

If they'd want ...!source.MATCH!source!... instead of
IIRC Henry's idea !!, fine.

For Harald's idea (an extensible list of keywords) I 
had horrible ideas like SPAM, XXX, EXPLICIT, or even
servers abusing it to insert their Ads into the Path:

...!site!this.path.presented.by.xyzzy.IGNORE!... ugh.

I've seen similar crap in mail header fields (incl.
timestamp lines).
                  Bye, Frank