Subject: Path Punctuation summary

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 4 Nov 2004 21:35:49 GMT

I first posted this in the middle of August, when I was away from home
    (which maybe explains why it never made it to the list). So when I was
    home again, and it was clear that it had not made it, I posted it
    again on August 27th. I don't know whether it made it that time (did
    any of you see it?), but what is clear is that Landfield was in a bad
    state at that time because nothing had been archived since August
    13th.

    At some later stage, in the middle of September, some of the missing
    articles miraculously appeared in the Archive, but not this one (and I
    think serveral other people's must be missing also because the archive
    is showing only two messages posted at all in the last 5 days of
    August).

    So here it is again, for the third time :-( .

There was earlier discussion concerning which delimiters could be used on
the Path header, having regard to the vagueness of the word "punctuation"
as used in RFC 1036.

Given that the checks we have put into the Path-header are generally
agreed to be desirable for tracing the origin of scams of various sorts,
and that the principle problem seems to be whether the characters proposed
as delimiters for this purpose would cause problems with existing
implementations, here is a summary of some of the options we could
consider.

First, the scheme as proposed requires that relaying agents should be able
to make the following assertions when they add a new path-identity to the
Path-header:

#1  I am the injecting site.
#2  I have checked the identity of the previous site, and I believe the
    path-identity inserted by that site to be correct.
#3  I have checked the identity of the previous site, and I do not believe
    the path-identity claimed by that site; here is what I believe to be
    the true identity of that site.
#4  I have made no checks on the identity of the previous site.

In the following running example
    injector.com always uses #1
    new-site.com always uses #2 or #3
    good-site.com always uses #2 or #3
    old-site always uses #4
    dodgy.com was a bogus identity actually inserted by mallet.com

A. Current draft:
-----------------

Uses '%' for #1, '/' for #2, '?' for #3 amd '!' for #4

Path: good-site.com/mallet.com?dodgy.com!old-site.com!
      new-site.com/injector.com%not-for-mail

B. Henry's proposal <http://www.landfield.com/2004/Jul/0236.html>:
------------------------------------------------------------------

Uses '@' for #1, ',' for #2, ' ' for #3 amd '!' for #4, since it is clear
from RFC 1036 that all of those are intended to be usable as delimiters.

Path: good-site.com,mallet.com dodgy.com!old-site.com!
      new-site.com,injector.com@not-for-mail

Observe that the ' ' delimiter turns up rather conveniently as a separator
between the correct and bogus identities of mallet.com. One would need to
discuss whether FWS as well as SP should delimit this case.

C. The Diablo scheme
--------------------

I still have not been able to find documentation on this, but from
observed instances it appears to work as follows:

Path: good-site.com!mallet.com.MISMATCH!dodgy.com!old-site.com!
      new-site.com!injector.com.POSTED!not-for-mail

I see 2 problems with this one:

1: Any site which peers with injector.com (e.g. new-site.com) would
normally scan the received Path for occurrences of "injector.com", and would
send the article back to injector.com if it was not found (which, of
course, it isn't here ecause it recorded itself as "injector.com.POSTED").

2: It provides no distinction betwen cases #2 and #4, which rather defeats
the object of the whole exercise.

D. Another possible scheme
--------------------------

If you want to avoid all delimiters other than '!', and to overcome the
problems with the Diablo scheme, then here is one which relies on special
keywords "M", "MISMATCH" and "POSTED" in places where the current syntax
would expect a path-identity.

Path: good-site.com!M!mallet.com!MISMATCH!dodgy.com!old-site.com!
      new-site.com!M!injector.com!POSTED!not-for-mail

It makes the Path a little longer, but not unacceptably so, and assumes
that those keywords will never represent real sites.

Comments? I think I would prefer Henry's scheme out of that bunch, but
there might also be the possibility of using some of the other delimiters
known to be used in the BNews implementation, which Bruce considers might
be safe.

-- 
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: Frank Ellermann <[email-masked]>
Date: Fri, 05 Nov 2004 14:12:47 +0100

Charles Lindsey wrote:

> I think I would prefer Henry's scheme out of that bunch

Yes, it's nice.  For a scheme based on s-o-1036 (only "!")
like POSTED and MISMATCH I'd prefer other "keywords":

POSTED   => LOCALHOST
MISMATCH => INVALID

But TEST for M would result in messy Path: headers, that 
idea probably can't fly.  I don't like M, MISMATCH, and
POSTED because it's very near to odd cases like host TV.

tv = 65.201.175.144

The poor TV has a serious problem with a bug (?) in 2821:

| A domain (or domain name) consists of one or more
| dot-separated components.

True.

| The domain name, as described in this document and in [22],
| is the entire, fully-qualified name (often referred to as
| an "FQDN").

True, [22] is 1035 resp. Std 13

| Domain = (sub-domain 1*("." sub-domain)) / address-literal

But that's wrong, or isn't it ?  There's no dot in FQDN tv.

                     Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 8 Nov 2004 13:52:26 GMT

>idea probably can't fly.

OK, I think you're talking about my Scheme D now.

Another possibility I have thought of is that you could use an empty
path-identity (i.e. two '!'s together) for the 'M' case, gving:

Path: good-site.com!!mallet.com!MISMATCH!dodgy.com!old-site.com!
      new-site.com!!injector.com!POSTED!not-for-mail

So the double "!!" shows that good-site.com and newsite.com assert
that they have confirmed the identity of their upstream sites, and the
single '!' shows that old-site.com had merely copied the existing
path-identity without checking it. By all means propose alternative
keywords/notations for MISMATCH and POSTED.

  I don't like M, MISMATCH, and

>tv = 65.201.175.144

Eh? Does that domain actually exist? Seems broken to me.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 09 Nov 2004 00:36:28 +0100

>       new-site.com!!injector.com!POSTED!not-for-mail

That's better than M.  

> propose alternative keywords/notations for MISMATCH and POSTED.

INVALID and LOCALHOST would be reserved, but LOCALHOST was a
horrible idea, please forget it.  If we could get rid of the
POSTED, then replacing MISMATCH by INVALID makes sense.

But Henry's idea was better.  Your !! is also nice, you could
use it instead of Henry's space:

| Path: good-site.com,mallet.com dodgy.com!old-site.com!
|      new-site.com,injector.com@not-for-mail
| 
| Observe that the ' ' delimiter turns up rather conveniently as a separator
| between the correct and bogus identities of mallet.com. One would need to
| discuss whether FWS as well as SP should delimit this case.

Path: good-site.com,mallet.com!!dodgy.com!old-site.com!
      new-site.com,injector.com@not-for-mail
  
> Eh? Does that domain actually exist? Seems broken to me.

TV is Tuvalu, a ccTLD, see <gopher://whois.iana.org:43/0tv>

TV is also host.  A TLD POSTED or MISMATCH is unlikely, but
not "verboten" like INVALID.  With UUCP host names INVALID
is probably not much better than MISMATCH.

                     Bye, Frank