Subject: Ticket status, February 20, 2006

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Feb 2006 13:26:57 +0100

The last ticket status update was from Jan 3. Time for another round.

1032 USEFOR general: Document changes from RFC 1036

  Comments from Charles Lindsey and Frank Ellermann that the convention
  of putting "cmsg" in the subject is no longer valid.

  Suggested addition to appendix B:

    The convention to interpret subjects starting
    with the word "cmsg" as control message was removed.

  Status: "Text proposed".

1047 USEFOR 3.1.6: Path field delimiters and components

  Poll executed; we're in the process of defining an ABNF syntax.
  Still unclear whether keywords are specified in USEFOR or in USEPRO.

  Status: "Text proposed" - but still refining.

1078 USEFOR 3.1.5: Need to describe meaning of Newsgroups header field in 
email

  I proposed "no change" on Jan 3. Two comments did not object.
  I'm closing this as "no change needed"; we may return to the subject
  in USEAGE.

1080 USEFOR 3.2.14 - MIME parameters for Injection-Info and Archive header 
field need more text/updated syntax

  Ticket closed; nobody's objected to the ABNF version

1084 USEFOR 2.1, 3 Names for ABNF productions redefining 822 constructs

  Ticket closed; "no change".

1132 USEFOR 3.1.6: Outlaw IP address in path-identity?

 was "text accepted" on Nov 28 - this is closely enough linked to 1047
 that they should be considered together, but I regard the specific
 issue as closed.

======== "New" issues =======

1155 USEFOR 1.4: Formalize ABNF imports?

  I've seen no comments to Frank's suggestion; in this case, I'm
  interpreting silence as consensus. Editor has incorporated text.

1156 USEFOR Appendix: IANA registration form for headers.

  Seems uncontroversial, once the rules have been made clear.
  Editor has added registration templates.

1157: USEFOR 3.2.5 Control: can't use "value" construct

  Status: "Text proposed".

1158: USEFOR 3.2.14: Need better ABNF for host-value

  Status: "Text proposed" - seems uncontroversial

1159: USEFOR 3.2.14: Advice on sender vs posting-account

  Status: No consensus - use seems controversial

1177: USEFOR 3.2.12 Archive ABNF + 3.2.14 Injection-info ABNF

  Status not completely clear to me. I think the ABNF is uncontroversial,
  but I'm not clear what the note modification should be.

1178: USEFOR 3.1.6: Whitespace in Path header

  Consensus is not clear to me.

1179: USEFOR general: [FWS] that should be *WSP

  Frank suggests replacing [FWS] that can't be allowed to fold with *WSP.
  Charles favours "no change needed".
  Consensus not clear to me.

That's all folks....

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 20 Feb 2006 15:40:06 +0100

Harald Tveit Alvestrand wrote:

> Time for another round.

>   Editor has added registration templates.

The precise set of header fields is not yet clear, please keep
that open (text proposed) until we see the next draft.  Or let
us discuss the proposed text - I recall that Charles and I want
some additions / modifications.  Minor points, no showstoppers.

>   Status: No consensus - use seems controversial

There were several folks saying that it can't stay as is, and
a proposal to delete it got some support.

>   Status not completely clear to me. I think the ABNF is
>   uncontroversial, but I'm not clear what the note
>   modification should be.

IIRC the rough idea was "do what Keith did in 3834, add CFWS".

>   Consensus is not clear to me.

Oops, that's a misleading title.  The issue is WSP in all of
Newsgroups, FollowupsTo, and Distribution:

Newsgroups: one, two, three

That doesn't work as expected on many servers, the blank after
the comma (any FWS).  USEPRO offers a note about this issue to
be moved to USEFOR.  For FollowupsTo and Disribution it's the
same issue, they only need a pointer to SHOULD NOT (or whatever
it is) for Newsgroups.

Or rather FollowupsTo is clear as soon as Newgroups is clear -
it's the same syntax.  So only Distribution needs a pointer.

>   Consensus not clear to me.

No news from the 2822-erratum side of this issue:  Submitted,
unconfirmed, unrejected, probably pending (or lost in space).

For the next potential 2822-FWS-"victim" Jabber-ID compare
<http://permalink.gmane.org/gmane.ietf.rfc822/11777>

                            Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Mon, 20 Feb 2006 11:08:41 -0800

>  Status: "Text proposed".

Sounds good to me.

>  Consensus not clear to me.

I'm with Frank on this, I think, unless there's some negative consequence
that I'm not seeing.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Feb 2006 12:05:55 GMT

>I'm with Frank on this, I think, unless there's some negative consequence

It actually changes nothing. There is currently verbiage to forbid empty
header lines and header lines with nothing visible beyond the header-name.
That verbiage will still be needed, because this syntactic change does not
cover all of the cases where that verbiage needs to apply.

In fact, that is its danger - it seems like it is trying to solve a
problem, but it isn't. RFC 2822 dug itself into this pit, and I think we
should leave it to RFC 2822-bis to get itself out.

If we knew that RFC 2822-bis was going to make this change, then we might
go this route, but we don't know that and they may choose some third way
to attack the (non)problem.

OTOH, since it is no actual change, let Harald just choose which way to
jump if he cannot see a clear consensus.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Feb 2006 13:34:24 GMT

>  but I'm not clear what the note modification should be.

The proposed wording for 3.2.14 was 

      NOTE: The syntax of <parameter> ([RFC2045] as amended by
      [RFC2231]), taken in conjunction with the folding rules of
      [RFC0822], effectively allows [CFWS] to occur on either side of
      the "=" inside a <parameter>.

(see http://www.imc.org/ietf-usefor/mail-archive/msg02759.html)

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Feb 2006 19:01:35 +0100

Charles Lindsey wrote:

> http://www.imc.org/ietf-usefor/mail-archive/msg02759.html

+1, #1177 "text proposed".  Bye, Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 24 Feb 2006 13:47:32 +0100

I agree with Charles that it changes nothing, but it makes the ABNF look 
consistent with the text.

I suggest (making a call for consensus as WG chair) that unless someone 
objects strongly with a reasoned argument, we make the change as Frank 
suggested.

--On 23. februar 2006 12:05 +0000 Charles Lindsey <[email-masked]> 
wrote:

> Charles H. Lindsey ---------At Home, doing my own
> thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133
> Web: http://www.cs.man.ac.uk/~chl Email: [email-masked]      Snail:
> 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint:
> 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
>
>
>

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 27 Feb 2006 11:25:46 GMT

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

>I agree with Charles that it changes nothing, but it makes the ABNF look=20

>I suggest (making a call for consensus as WG chair) that unless someone=20
>objects strongly with a reasoned argument, we make the change as Frank=20
>suggested.

In that case, please can we have a NOTE such as the following after the
2nd bullet in 2.2:

    NOTE: It would be hard to enforce this restriction generally in the
    syntax.  Nevertheless, the opportunity has been to do so in a few easy
    cases by the use of *FWS rather than [FWS].

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 27 Feb 2006 13:49:06 +0100

>     cases by the use of *FWS rather than [FWS].

typo: s/*FWS/*WSP/

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 28 Feb 2006 17:08:06 +0100

--On mandag, februar 27, 2006 11:25:46 +0000 Charles Lindsey 
<[email-masked]> wrote:

>
> In <C1826EE1679CB4C4FBC725A1@B50854F0A9192E8EC6CDA126> Harald Tveit
> Alvestrand <[email-masked]> writes:
>
>> I agree with Charles that it changes nothing, but it makes the ABNF
>> look=20 consistent with the text.
>
>> I suggest (making a call for consensus as WG chair) that unless
>> someone=20 objects strongly with a reasoned argument, we make the change
>> as Frank=20 suggested.
>

I don't see the need for such a note. Harmless, but why?

(in general, ABNF has to allow everything the text allows, but ABNF can't 
possibly disallow everything the text disallows)

Date: Tue, 28 Feb 2006 17:08:06 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: #1177 FWS -> *WSP (Re: Ticket status, February 20, 2006)
Sender: [email-masked]

--On mandag, februar 27, 2006 11:25:46 +0000 Charles Lindsey 
<[email-masked]> wrote:

>
> In <C1826EE1679CB4C4FBC725A1@B50854F0A9192E8EC6CDA126> Harald Tveit
> Alvestrand <[email-masked]> writes:
>
>> I agree with Charles that it changes nothing, but it makes the ABNF
>> look=20 consistent with the text.
>
>> I suggest (making a call for consensus as WG chair) that unless
>> someone=20 objects strongly with a reasoned argument, we make the change
>> as Frank=20 suggested.
>

I don't see the need for such a note. Harmless, but why?

(in general, ABNF has to allow everything the text allows, but ABNF can't 
possibly disallow everything the text disallows)

To: [email-masked]
Xref: clerew local.usefor:23157
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 full circle
Date: Tue, 28 Feb 2006 10:34:14 GMT
Lines: 41
Sender: [email-masked]

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

>Other points skipped, obviously we disagree.  If the simple set
>of four diagnostics !.m, !.p, !.s, and !! is already dubious I
>fail to see why future extensions incl. !.X-whatever should be
>desirable.  This is the <path>, it's transported by all relays
>and all readers of an article, it's not the place to allow some
>kind of X-Face for relays.

The Path header in news serves a similar purpose to the Received header in
email. In recent years, the content of the Received header has grown like
Topsy as people have crammed more and more information into it, putting
formatted stuff into comments (a gross misuse of the comment facility, but
there was no other way to do it). By and large, this increased information
is desirable and useful, in spite of the fact that the notations used are
far from consistent.

What this shows is that the need for diagnostic information tends to grow,
but that the syntax of the Received header was far too restrictive to
accomodate what turned out to be needed.

Let us not make the same mistake. I doubt that we need as much information
as currently goes into Received headers, and I cannot at the moment
foresee more than the !.m, !.p, !.s, and !! that you mention, of which the
"!!" and the "!.p" are the only ones which should regularly appear. But it
costs us nothing to allow for future extension should it be needed.

Yes, there is the possility that some relayers will abuse the
possibilities, but you may be sure that USEPRO will make it clear such
practices are a Bad Thing (probably with SHOULD NOT wording).

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 full circle
Date:  Mon, 27 Feb 2006 14:37:38 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Sender: [email-masked]

Charles Lindsey wrote:

> Who said a bareword was necessarily UUCP?

s-o-1036 chapter 5.6 (excl. its obscure "cooperating subnets"):

| a relayer name MUST be either a UUCP name registered in the
| UUCP maps (without any domain suffix such as ".UUCP"), or a
| complete Internet domain name.

> It was made clear that barewords were only to be used 
> where there was a Good Reason (and "legacy", or rather
> "longstanding usage" was certainly one Good Rreason).

Yes, of course, we're talking about a comment in the ABNF line:

| path-nodot   =  1*( alphanum / "-" / "_" )    ; legacy names

Other points skipped, obviously we disagree.  If the simple set
of four diagnostics !.m, !.p, !.s, and !! is already dubious I
fail to see why future extensions incl. !.X-whatever should be
desirable.  This is the <path>, it's transported by all relays
and all readers of an article, it's not the place to allow some
kind of X-Face for relays.
                          Bye, Frank

Date: Mon, 27 Feb 2006 13:37:16 +0000
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1047 not-for-mail (Re: #1047 permitted constructs - a list)
Sender: [email-masked]

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes
>
>Charles Lindsey wrote:
>
>> if we follow s-o-1036 (tail-entry to be ignored by relayers),
>> then a NOTE pointing out some diversity of current practice
>> is in order (probably in USEPRO), together with mention of
>> "not-for-mail" (which is alread done in USEPRO).
>
>We also need it in USEFOR - only clueful folks will look into
>USEPRO.  The minimal approach is an ABNF comment:
>
>      tail-entry = path-nodot      ; not-for-mail
>
>Maybe too minimalistic, how about "The <tail-entry> SHOULD be
>the lower case string not-for-mail as explained in [USEPRO]" ?

looking at the very last item in the Path for 26,125,927 articles from a
couple of summers ago ...  here's the top 40 (note that I've upper cased
them to ensure case insensitivity in the matches I made [doesn't make
all that much difference if case insensitive])

19096174  NOT-FOR-MAIL                73.09%
 1317084  TJUBBS                       5.04%
  631392  TK2MSFTNGXA03.PHX.GBL        2.42%
  231491  CPMSFTNGXA06.PHX.GBL         0.89%
  225470  TK2MSFTNGP11.PHX.GBL         0.86%
  217073  TK2MSFTNGP13.PHX.GBL         0.83%
  215733  TK2MSFTNGP09.PHX.GBL         0.83%
  208797  TK2MSFTNGP10.PHX.GBL         0.80%
  194575  TK2MSFTNGP12.PHX.GBL         0.74%
  191901  ROBOMOD                      0.73%
  164954  CPMSFTNGXA10.PHX.GBL         0.63%
  150967  KKCITY                       0.58%
  136417  CLARINEWS                    0.52%
  135656  TK2MSFTNGP15.PHX.GBL         0.52%
  110554  SPAMCANCEL                   0.42%
  101004  USENET                       0.39%
   90221  TK2MSFTNGP14.PHX.GBL         0.35%
   89158  TK2MSFTNGP08.PHX.GBL         0.34%
   80567  MAIL2NEWS                    0.31%
   80379  WRETCH                       0.31%
   76426  NANKAI                       0.29%
   71106  CHAINSAW                     0.27%
   66658  WEBX                         0.26%
   64050  NIUSY.ONET.PL                0.25%
   54217  YTHT                         0.21%
   49287  SMTH                         0.19%
   48169  FORMOSA                      0.18%
   48126  CIS_NCTU                     0.18%
   44988  NEWS                         0.17%
   41496  THERE.IS.NO.CABAL            0.16%
   41198  MAPLE                        0.16%
   32528  KIMOWEBBBS                   0.12%
   32395  BBS.OPENFIND.COM.TW          0.12%
   31336  PTT                          0.12%
   30351  SIMFARM                      0.12%
   29634  MIRRORPOST                   0.11%
   28339  HIT                          0.11%
   27314  TK2MSFTNGXA02.PHX.GBL        0.10%
   26794  KIMOBBS                      0.10%
   26505  DRN                          0.10%

           ... remainder ...           6.07%

we can see that not-for-mail is common, but far from universal. Is there
really an overriding reason here for a SHOULD (making a quarter of all
articles non-conformant) ?

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 not-for-mail
Date:  Mon, 27 Feb 2006 14:10:29 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Charles Lindsey wrote:

>>      tail-entry = path-nodot      ; not-for-mail

>> Maybe too minimalistic, how about "The <tail-entry> SHOULD be
>> the lower case string not-for-mail as explained in [USEPRO]" ?

> No, "not-for-mail" is the default that you write (or somewhere in the
> software writes for you) if you choose not to use your name "joe". But
> it has not been suggested that using names such as "joe" should be
> deprecated.

It's more like "required" than "suggested" after I learned that
1036 servers would interpret it as "site 'joe' already has the
article".
                             Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1177 FWS -> *WSP
Date:  Mon, 27 Feb 2006 13:49:06 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

typo: s/*FWS/*WSP/

To: [email-masked]
Xref: clerew local.usefor:23151
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Date: Mon, 27 Feb 2006 11:31:17 GMT
Lines: 33
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

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

>> Some sites like news.t-online.de have (or had) a X-Trace.  Encoded in
>> later versions.  They could determine the IP and maybe more from it,
>> with that info they could find who posted, and then send a warning or
>> TOS or what else.

>Oh, is this supposed to be the replacement for NNTP-Posting-Host
>specifically?

I think it was meant to be a replacement for *everything*.

>  Hm.  I'd be more inclined to put that into posting-account;
>I'd rather put all of the identifying information in one place so that I
>can encrypt it only once and not have to deal with multiple parameters.

It might well be that the more paranoid ISPs would put everything into the
logging parameter, and have no other parameters. That would be allowable
under the rules as written, but not overly helpful to the rest of the
community.

To: [email-masked]
Xref: clerew local.usefor:23149
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 full circle
Date: Mon, 27 Feb 2006 11:10:58 GMT
Lines: 97
Sender: [email-masked]

>>> it's too difficult to split it cleanly, we would get
>>> diag-match and diag-obs in USEFOR, and diag-other
>>> details in USEPRO, enumerating POSTED / SEEN / MATCH
>>> there for a new diag-keyword in USEFOR, that's IMO too
>>> confusing:

>> Nevertheless, I think we should try it that way.

>IBTD.  It's not the same situation as for the "Control:", where
>a clean split is possible and makes sense.  You've enough to do
>to explain the various diagnostics in USEPRO.

>We're talking about three ABNF lines (for !.s, !.m, !.p) versus
>two lines "diag-other" and "diag.keywords" here.

It's not about saving lines. It's about allowing for future extensibility
(always a good idea when you are introducing something new, which may need
some fine tuning later). And maybe even allowing keywords beginning with
"X" for people to use experimentally.

And also it is about not making any suggestion that software should be
parsing and rejecting Path headers at that level of detail. So long as you
can recognize the delimiters and FWS, and so separate out the items, and
then maybe distinguish which items are diagnostics and which are not
(assuming the particular piece of software neds to know that distinction),
then it does not really matter what is present, syntactically speaking.

OTOH, for making the protocol work, and for providing information useful
for troubleshooting, then there need to be rules/conventions/whatever for
what goes in there, but USEPRO is the place for those.

>> <diag-match> needs to be in USEFOR because it is a special
>> case syntactically speaking. There would be wording to
>> explain this, along with wording to direct you to USEPRO

>It is OBVIOUS if the complete syntax is here, no additional
>wording needed.  What can <diag-match> be if it's followed
>by <diag-mismatch> ?  You only need long and irritating prose
>in both documents if you split it.

>> I would remove <diag-deprecated> to <identity-deprecated>.
>> Syntactically, it looks like a <path-identity>, and
>> software will inevitably treat it as such

>But we've decided that it shouldn't do this for IPv4, and IIRC
>Richard observed that IPv4 is apparently used as some kind of
>diagnostics in paths today.  Not as identity.  We had a poll
>and rough consensus about "no IP as identity".

Yes, but the poll was for what would be allowed in future. In the present,
people DO put IPv4 addresses in the Path, so thay are MUST accept but MUST
NOT generate in future. But whether the ones in current use are there for
identity of diagnostic reasons is irrelevant to that - either way they are
still MUST accept NOT generate. Yes, we believe that most of the present
usage is diagnostic, but that is irrelevant and nothing is gained by
writing it into the syntax (and in fact doing so causes harm by suggesting
that it has some meaning that parsers should be taking note of).

>Jumping to the end of another article:

>>> path-nodot   =  1*( alphanum / "-" / "_" )    ; legacy names

>> <path-nodot> is what we have sometimes referred to as a
>> <bareword>.

>> Whatever it is called, I would object strongly to including
>> the word "legacy" in here.

>Yes, I insist on it because it's the truth.  UUCP-names _are_
>legacy.  We cannot protect them in any way against collisions
>in their namespace.  They might even clash with a <tail-entry>
>on 1036-servers (and in theory that's _all_  servers today).

Who said a bareword was necessarily UUCP? In any case, some news is still
transported by UUCP. We agreed months ago on some wording now in USEPOR on
what was acceptable for identities. It was made clear that barewords were
only to be used where there was a Good Reason (and "legacy", or rather
"longstanding usage" was certainly one Good Rreason). And it was made clear
that uniqueness could not be absolutely guaranteed. That said, it was left
to newsadmins to decide in each case whether the benefit outweighed the
disadvantage.

To: [email-masked]
Xref: clerew local.usefor:23148
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Date: Mon, 27 Feb 2006 10:39:44 GMT
Lines: 44
Sender: [email-masked]

In <[email-masked]> "Forrest J. Cavalier III" <[email-masked]> writes:

>Frank Ellermann wrote:

>> Simplified, could be wrong, and I don't know the details.
>> What they didn't have was a database of Message-IDs to
>> users.

I don't think we can assume that servers will all be willing to index
their logs by Message-ID (sensible though that idea might be). It is an
implementation detail, and our standard cannot make assumptions about
implementation details.

>>  It's a huge ISP, and a big server, just using
>> what works everywhere for them in X-Trace (encrypted) 
>> was probably the smart thing.  <shrug />

>Shrug?  That site is saying....

>"I can't waste 100 bytes per message on my local logs
>so I'll waste 100 bytes of SPOOL ON EVERY SITE that stores
>articles injected here.  Oh, if you want me to store your
>X-Trace headers for you, I guess so...."

Again, it may not be the most Usenet-friendly technique, but we can't
really stop servers doing it that way if they so choose. An implementation
detail, again.

Essentially, what I am saying is that if the same source of the article
produces (essentially) the same text for the parameter, then it is a
posting account, but if it produces a string of gibberish, different every
time (whether it is an index into the ISP's log, or an encryption of the
whole log entry), then it is a logging parameter.

To: [email-masked]
Xref: clerew local.usefor:23150
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1177 FWS -> *WSP (Re: Ticket status, February 20, 2006)
Date: Mon, 27 Feb 2006 11:25:46 GMT
Lines: 26
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23147
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 not-for-mail (Re: #1047 permitted constructs - a list)
Date: Mon, 27 Feb 2006 10:21:10 GMT
Lines: 22
Sender: [email-masked]

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

>      tail-entry = path-nodot      ; not-for-mail

>Maybe too minimalistic, how about "The <tail-entry> SHOULD be
>the lower case string not-for-mail as explained in [USEPRO]" ?

No, "not-for-mail" is the default that you write (or somewhere in the
software writes for you) if you choose not to use your name "joe". But it
has not been suggested that using names such as "joe" should be
deprecated.

Date: Fri, 24 Feb 2006 13:47:32 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: #1177 FWS -> *WSP (Re: Ticket status, February 20, 2006)
Sender: [email-masked]

--==========41A8D015B0763DAEFB31==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 23. februar 2006 12:05 +0000 Charles Lindsey <[email-masked]>=20
wrote:

>>>  Frank suggests replacing [FWS] that can't be allowed to fold with =
*WSP.
>> I'm with Frank on this, I think, unless there's some negative =
consequence
> header lines and header lines with nothing visible beyond the =
header-name.
> That verbiage will still be needed, because this syntactic change does =
not
> jump if he cannot see a clear consensus.

--==========41A8D015B0763DAEFB31==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========41A8D015B0763DAEFB31==========--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Date:  Thu, 23 Feb 2006 23:48:54 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Sender: [email-masked]

Russ Allbery wrote:

> You're rather optimistic there.  :)

Yes.  Generally I liked their server, about 2002..2004.

The unencoded format was a pain, it included a variant
of the account number, and everybody and his dog knew
how to derive a working mail address from it, or an URL
of user home pages, each with an auto-generated subpage
containing the real name and address...

...well, they were forced to encrypt this later.  Bye

Date: Thu, 23 Feb 2006 17:08:25 -0500
From: "Forrest J. Cavalier III" <[email-masked]>
To: [email-masked]
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Sender: [email-masked]

Frank Ellermann wrote:

> Russ Allbery wrote:
> 
> 
>>I'm still failing to see the difference from Message-ID.
> 
> 
> Some sites like news.t-online.de have (or had) a X-Trace.
> Encoded in later versions.  They could determine the IP
> and maybe more from it, with that info they could find
> who posted, and then send a warning or TOS or what else.
> 
> Simplified, could be wrong, and I don't know the details.
> What they didn't have was a database of Message-IDs to
> users.  It's a huge ISP, and a big server, just using
> what works everywhere for them in X-Trace (encrypted) 
> was probably the smart thing.  <shrug />

Shrug?  That site is saying....

"I can't waste 100 bytes per message on my local logs
so I'll waste 100 bytes of SPOOL ON EVERY SITE that stores
articles injected here.  Oh, if you want me to store your
X-Trace headers for you, I guess so...."

Forgive me if I am not sympathetic to lusers[*] who actually
believe they eat free lunches.

Forrest

* - Real word alert: Sometimes admins are lusers too.  They
aren't too hard to spot on Usenet, in fact.  Technology hasn't
solved social problems, doncha know.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Organization: The Eyrie
Date: Thu, 23 Feb 2006 13:53:27 -0800
Sender: [email-masked]

Frank Ellermann <[email-masked]> writes:
> Russ Allbery wrote:

>> I'm still failing to see the difference from Message-ID.

> Some sites like news.t-online.de have (or had) a X-Trace.  Encoded in
> later versions.  They could determine the IP and maybe more from it,
> with that info they could find who posted, and then send a warning or
> TOS or what else.

Oh, is this supposed to be the replacement for NNTP-Posting-Host
specifically?  Hm.  I'd be more inclined to put that into posting-account;
I'd rather put all of the identifying information in one place so that I
can encrypt it only once and not have to deal with multiple parameters.

> Simplified, could be wrong, and I don't know the details.  What they
> didn't have was a database of Message-IDs to users.  It's a huge ISP,
> and a big server, just using what works everywhere for them in X-Trace
> (encrypted) was probably the smart thing.  <shrug />

Yeah, but that sort of thing I was expecting to see in posting-account.
The description of logging-data is specifically "here's some cookie that
the site can look up in their logs," which message ID can already do.

> Apparently not there, they had some privacy trouble with the unencoded
> X-Trace, they wouldn't stick to it if it's redundant.

You're rather optimistic there.  :)

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Date:  Thu, 23 Feb 2006 22:27:57 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 34
Sender: [email-masked]

Russ Allbery wrote:

> I'm still failing to see the difference from Message-ID.

Some sites like news.t-online.de have (or had) a X-Trace.
Encoded in later versions.  They could determine the IP
and maybe more from it, with that info they could find
who posted, and then send a warning or TOS or what else.

Simplified, could be wrong, and I don't know the details.
What they didn't have was a database of Message-IDs to
users.  It's a huge ISP, and a big server, just using
what works everywhere for them in X-Trace (encrypted) 
was probably the smart thing.  <shrug />

> it does strike me as rather redundant.  Wouldn't it
> be better to encourage sites to be able to find logs
> of messages by message ID, which is far more likely
> to be available in practice?

Apparently not there, they had some privacy trouble
with the unencoded X-Trace, they wouldn't stick to it
if it's redundant.  Maybe they just don't have a log
"Message-ID -> user".  This log would automatically
attract the attention of their privacy officer.  

We have privacy laws over here, companies MUST have
a privacy officer, and they MUST avoid to collect 
personal data whereever it's not required.  A kind
of "SHOULD NOT generate" for sensitive data, with a
good excuse it's of course possible.

                           Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 full circle
Date:  Thu, 23 Feb 2006 20:31:04 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 100
Sender: [email-masked]

Charles Lindsey wrote:

>> it's too difficult to split it cleanly, we would get
>> diag-match and diag-obs in USEFOR, and diag-other
>> details in USEPRO, enumerating POSTED / SEEN / MATCH
>> there for a new diag-keyword in USEFOR, that's IMO too
>> confusing:

> Nevertheless, I think we should try it that way.

IBTD.  It's not the same situation as for the "Control:", where
a clean split is possible and makes sense.  You've enough to do
to explain the various diagnostics in USEPRO.

We're talking about three ABNF lines (for !.s, !.m, !.p) versus
two lines "diag-other" and "diag.keywords" here.

> <diag-match> needs to be in USEFOR because it is a special
> case syntactically speaking. There would be wording to
> explain this, along with wording to direct you to USEPRO

It is OBVIOUS if the complete syntax is here, no additional
wording needed.  What can <diag-match> be if it's followed
by <diag-mismatch> ?  You only need long and irritating prose
in both documents if you split it.

> I would remove <diag-deprecated> to <identity-deprecated>.
> Syntactically, it looks like a <path-identity>, and
> software will inevitably treat it as such

But we've decided that it shouldn't do this for IPv4, and IIRC
Richard observed that IPv4 is apparently used as some kind of
diagnostics in paths today.  Not as identity.  We had a poll
and rough consensus about "no IP as identity".

We can reduce <diag-deprecated> to  "!" IPv4address  to get rid
of the ambiguity.  It's then also more obvious that it's _not_
some kind of <identity-deprecated>:

<IPv4address> doesn't match <path-identity>, and vice versa.

As you said elsewhere no harm done if a weirdo puts !oo..ps in
the path (adjacent dots).  Matching !o_o.p_s (underscore) as a
"valid" <diag-deprecated> doesn't really help if we don't catch
the similar !oo..ps,  I'd say let's take the clear IPv4address.

>> Besides <diag-identity> isn't optional for !.SEEN or !.MATCH

> Indeed. There will be all sorts of unsuitable things allowed
> syntactically, but so what? They cause no harm.

All crap in the path can be harmful, it makes it longer, that
means folding, and I'm far from sure that all news servers will
get a folded path right (both creating and reading).

> USEPRO will tell you what you are allowed to put, and
> strongly discourage anything else.

That's unnecessary for !.SEEN and !.MISMATCH if the syntax is
here and clear.  You can then focus on the important stuff in
USEPRO.  Without wasting time for pointless explanations why a
<diag-identity> is required after "!.SEEN." and "!.MISMATCH."

No SHOULD or other MUSTard needed, neither here nor in USEPRO.

> no harm arises from a more liberal syntax (and software is
> not going to bother to check it anyway

I strongly disagree that a "liberal syntax" with "MUST accept"
and "MUST NOT generate" is better than a clear syntax without
any prose, let alone MUSTard.

Jumping to the end of another article:

>> path-nodot   =  1*( alphanum / "-" / "_" )    ; legacy names

> <path-nodot> is what we have sometimes referred to as a
> <bareword>.

Also sometimes referred as <path-legacy>, yes.  <path-nodot>
stresses the syntactically more important point, no dot.

> Whatever it is called, I would object strongly to including
> the word "legacy" in here.

Yes, I insist on it because it's the truth.  UUCP-names _are_
legacy.  We cannot protect them in any way against collisions
in their namespace.  They might even clash with a <tail-entry>
on 1036-servers (and in theory that's _all_  servers today).

All we can do to protect them is to forbid FQDNs without dot
(= TLDs), and we've done this.  For more protection we'd need
the UUCP world map as a new IANA registry or a similar stunt.

As long as this doesn't happen I insist on saying "legacy" for
"legacy", because it's an utter dubious idea to create any new
identities in this legacy style in an uncoordinated manner.

                          Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  #1177 (was: Ticket status, February 20, 2006)
Date:  Thu, 23 Feb 2006 19:01:35 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 7
Sender: [email-masked]

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Date:  Thu, 23 Feb 2006 19:19:01 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Sender: [email-masked]

Charles Lindsey wrote:

> a Sender header is put there by the user agent, not the
> injecting agent (indeed, USEPRO currently forbids altering
> any Sender header already present).

ACK, this isn't 2476bis option 8.1 or an experimental SenderID,
it's NetNews.

> There is indeed a case (I don't buy it myself) for omitting
> this parameter, but this is a privacy issue

I buy it.  Servers wishing to enforce a simple kind of "PRA"
(SenderID's "purportable responsible address") are free to do
it by rejecting articles they don't like.

If we kill the "sender"-parameter we also need no convoluted
explanation of its differences from "posting-account".  Just
saying that the latter is optional is fine, admins will know
what to do with it if they want it, "cryptic" or not.

                           Bye, Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Organization: The Eyrie
Date: Thu, 23 Feb 2006 10:22:54 -0800
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> I'm opposed to including that sort of sender parameter.  If the server
>> wants to put in a Sender header, it should just do that, not stick the
>> equivalent in some other header.

> Generally speaking, a Sender header is put there by the user agent, not
> the injecting agent (indeed, USEPRO currently forbids altering any
> Sender header already present).

Right, because you reject articles with headers you don't like rather than
altering them.  That doesn't change the overall point.

> There is indeed a case (I don't buy it myself) for omitting this
> parameter, but this is a privacy issue and is best discussed in USEAGE
> (see mt reply to Harald).

Yes, but I'm not talking about that.

I realize that Sender is slightly ambiguous in practice, but the
information is also near-worthless, so I don't see why we care.  If a
particular site wants to use that header, they should go right ahead.
I'm not seeing the benefit gained by introducing yet another version of
it.

>> The solution to that problem is to remove logging-data, which is not
>> clearly specified and probably in practice indistinguishable from
>> Message-ID.

> No, the essential difference with the logging-parameter is that it just
> identifies an entry in the servers log-file. So it it totally opaque to
> the outside world and gives you no clue to the identity of the poster
> unless you can persuade the ISP concerned to divulge the information or
> to TOS the guy itself. Trouble is, ISPs who are reluctant to divulge or
> TOS tend to attract the Bad Guys :-( .

I'm still failing to see the difference from Message-ID.

I don't suppose it really hurts anything, but it does strike me as rather
redundant.  Wouldn't it be better to encourage sites to be able to find
logs of messages by message ID, which is far more likely to be available
in practice?

To: [email-masked]
Xref: clerew local.usefor:23132
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Date: Thu, 23 Feb 2006 13:10:46 GMT
Lines: 74
Sender: [email-masked]

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

>Current text:

>   The "posting-account" <parameter> identifies the source from which
>   that news server received the article.  For security reasons, it
>   SHOULD be in a cryptic notation understandable only by the
>   administrator of the news server.

Yes, the word "cryptic" there was a bit misleading (mea culpa), carrying
overtones of cloak-and-dagger stuff :-( .

>   The "sender" <parameter> identifies the mailbox of the verified
>   sender of the article (alternatively, it uses the token "verified" to
>   indicate that at least any addr-spec in the Sender header field of
>   the article, or in the From header field if the Sender header field
>   is absent, is correct).  If a news server can verify the sender of an
>   article, it SHOULD use this <parameter> in favor of the "posting-
>   account" <parameter>.

>After reviewing discussion, a proposed alternate text:

>   The "posting-account" <parameter> identifies the source from which
>   that news server received the article, in a notation that can be
>   interpreted by the news server admin. This notation can include any
>   info the admin deems pertinent, such as the authorized and/or
>   authenticated identity of the poster. In order to limit the exposure
>   of personal data, it SHOULD be given in a form that can't be interpreted
>   by other sites.

Yes, that is better, but not quite there. The essential property is that a
given source will still lead to the same posting-account (so you can
killfile on it). So something like:

   The "posting-account" <parameter> identifies the source from which that
   news server received the article, in a notation convenient to the news
   server admin (and possibly related to some authorized and/or
   authenticated identity of the poster [Refer to SASL]), but not one
   that identifies the poster directly.

Observe that I have removed the "SHOULD", as suggested by Richard.

>   The "sender" <parameter> identifies a mailbox that the news server
>   believes can be used to reach the user posting the article. There is
>   no implied relationship between the "sender" parameter and the "From"
>   or "Sender" header fields of the article.

   The "sender" <parameter> identifies a mailbox that can be used to reach
   the poster of the article (which may or may not be the same as in the
   "From" or "Sender" header fields of the article).

And a bit more wording if we retain the "verified" form of this parameter.

>   It is a matter of local policy whether to include the "posting-account"
>   <parameter>, the "<sender>" parameter, both, or neither.

Whilst it is right and proper to mention local policy and privacy here,
this applies to ALL the available parameters on this header, and not just
to these two. Moreover, it was agreeds long ago that detailed discussion
of this belonged in USEAGE, so all that is needed here is to say that
choice of parameters to include is a matter of local policy, but that it
has privacy implications which are addressed in more detail in USEAGE.

To: [email-masked]
Xref: clerew local.usefor:23131
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 full circle
Date: Thu, 23 Feb 2006 12:47:46 GMT
Lines: 64
Sender: [email-masked]

>> - Keywords can only be added by updating -usefor-

>Yes.  Otherwise it's too difficult to split it cleanly, we
>would get diag-match and diag-obs in USEFOR, and diag-other
>details in USEPRO, enumerating POSTED / SEEN / MATCH there
>for a new diag-keyword in USEFOR, that's IMO too confusing:

Nevertheless, I think we should try it that way.

> diag-match      = "!"                     ; another "!"
> diag-deprecated = "!" IPv4address         ; (see below)
> diag-other      = "!." diag-keyword [ "." diag-identity ]

<diag-match> needs to be in USEFOR because it is a special case
syntactically speaking. There would be wording to explain this, along with
wording to direct you to USEPRO for that and for rules explaining how to
use <diag-keyword>s.

I would remove <diag-deprecated> to <identity-deprecated>. Syntactically,
it looks like a <path-identity>, and software will inevitably treat it as
such (i.e. software may detect and act upon a "." after a "!", but is
unlikely to detect IP addresses as such - you just never put them in your
'sys' file and so they never get recognized to be acted upon).

> diag-keyword    = 1*ALPHA                 ; see USEPRO

>Besides <diag-identity> isn't optional for !.SEEN or !.MATCH

Indeed. There will be all sorts of unsuitable things allowed
syntactically, but so what? They cause no harm. USEPRO will tell you what
you are allowed to put, and strongly discourage anything else.

>> - diag-deprecated must contain at least one dot, but is
>> otherwise free-form, so not distinguishable from
>> path-identity. Was this your intention?

>That should be Russ' intention (*), "other crap with a dot not
>matched by a <path-identity>".  What we really need is IPv4.

Personally, I would just allow anything separated by dots in
<path-identity> (plus <path-nodot/bareword> of course) and then say that,
although that would permit IPv4addresses, that was only for legacy (and
possibly diagnostic) reasons - i.e. MUST accept, MUST NOT generate.

And I would also allow multiple diagnostics after each <path-identity> (so
people can say .SEEN-like things as well as .POSTED), and leave it to
USEPRO to restrict it to sensible usages. Again, no harm arises from a
more liberal syntax (and software is not going to bother to check it
anyway).

To: [email-masked]
Xref: clerew local.usefor:23130
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 full circle
Date: Thu, 23 Feb 2006 12:24:12 GMT
Lines: 49
Sender: [email-masked]

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

>I'd be happy to declare consensus on this one, so people who object should 
>speak up quickly....

Well it's certainly a cleaner syntax than some of Frank's earlier ones.

>Implications:

>- Keywords can only be added by updating -usefor-

Not so sure about that. See my comments in reply to Frank.

>- diag-deprecated must contain at least one dot, but is otherwise 
>free-form, so not distinguishable from path-identity. Was this your 
>intention?

It is ambiguous, but maybe it is best left so. But I would prefer to see
it as a deprecated-identity than as a deprecated-diagnostic. Again, see my
reply to Frank.

>Personally, I like to allow "!.POSTED!", so would prefer your second 
>alternative - YMMV.

Yes, the nakes ...!.POSTED!... is still needed.

>--On tirsdag, februar 21, 2006 09:37:49 +0100 Frank Ellermann 
><[email-masked]> wrote:

>> path-nodot      =  1*( alphanum / "-" / "_" )    ; legacy names

<path-nodot> is what we have sometimes referred to as a <bareword>.
Whatever it is called, I would object strongly to including the word
"legacy" in here. USEPRO contains wording to describe what should and
should not be used for a <path-identity>, and a domain-name is much to be
preferred, and hence you need a good reason to be using a
<bareword/path-nodot>. But that is not to say that such "good reasons" may
continue to arise in the future, hence "legacy" is not correct.

To: [email-masked]
Xref: clerew local.usefor:23133
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Date: Thu, 23 Feb 2006 13:24:41 GMT
Lines: 59
Sender: [email-masked]

>>   It is a matter of local policy whether to include the "posting-account"
>>   <parameter>, the "<sender>" parameter, both, or neither.

>I'm opposed to including that sort of sender parameter.  If the server
>wants to put in a Sender header, it should just do that, not stick the
>equivalent in some other header.

Generally speaking, a Sender header is put there by the user agent, not
the injecting agent (indeed, USEPRO currently forbids altering any Sender
header already present).

There is indeed a case (I don't buy it myself) for omitting this
parameter, but this is a privacy issue and is best discussed in USEAGE
(see mt reply to Harald).

>So to me, the only one that's potentially useful here is the
>posting-account parameter, plus an additional authentication-identity
>parameter to hold the other identity.  I have no problem with the above
>description of the field.

Authentication-identity is either a special use of the posting-account
parameter, or it belongs in a distinct authentication-parameter of its own
(I mildly prefer the latter).

>The solution to that problem is to remove logging-data, which is not
>clearly specified and probably in practice indistinguishable from
>Message-ID.

No, the essential difference with the logging-parameter is that it just
identifies an entry in the servers log-file. So it it totally opaque to
the outside world and gives you no clue to the identity of the poster
unless you can persuade the ISP concerned to divulge the information or to
TOS the guy itself. Trouble is, ISPs who are reluctant to divulge or TOS
tend to attract the Bad Guys :-( .

>Whether to really hide the identity or to maintain enough consistency
>between posts from the same account to allow automatic EMP recognition
>(thereby risking some privacy by creating a persistant identifier) is, I
>think, a choice for the local administrator.

The essence of the posting-parameter (as opposed to the logging-parameter)
is that such consistency would exist. The choice is indeed a matter of
local policy, but USEAGE is the place to discuss it in detail.

To: [email-masked]
Xref: clerew local.usefor:23134
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Ticket status, February 20, 2006
Date: Thu, 23 Feb 2006 13:34:24 GMT
Lines: 26
Sender: [email-masked]

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  #1047 double diags (was: #1047 permitted constructs - a list)
Date:  Thu, 23 Feb 2006 13:56:02 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Sender: [email-masked]

Charles Lindsey wrote:

>> The <path-identity> and the <tail-entry> are a unit.  They
>> come from the same system.  There's no reason why a system
>> should add <path-diagnostic> about itself to the path.  The
>> "unit" was <path-poster>, now I renamed it to <path-orig>.

> No, I don't think so. The <tail-entry> ("joe") comes from
> the user agent.  The first <path-identity> usually (but not
> inevitably) comes from the injecting agent.

Interesting, that's different from the explanation in 1036.

And reflects what s-o-1036 says.  But even in the s-o-1036
model it's clear that there can't be any case of (mis)MATCH
for <tail-entry> "joe".  Joe is supposed to be a user, not
a feed.

If we say !.POSTED  or !.POSTED.diag is for users / posters,
and !.SEEN.diag or (mis)MATCH is between relays, all should
be clear:  No "double-diags".
                              Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  #1047 not-for-mail (Re: #1047 permitted constructs - a list)
Date:  Thu, 23 Feb 2006 13:35:56 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Charles Lindsey wrote:

> if we follow s-o-1036 (tail-entry to be ignored by relayers),
> then a NOTE pointing out some diversity of current practice
> is in order (probably in USEPRO), together with mention of
> "not-for-mail" (which is alread done in USEPRO).

We also need it in USEFOR - only clueful folks will look into
USEPRO.  The minimal approach is an ABNF comment:

      tail-entry = path-nodot      ; not-for-mail

Maybe too minimalistic, how about "The <tail-entry> SHOULD be
the lower case string not-for-mail as explained in [USEPRO]" ?

                          Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:23129
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Ticket status, February 20, 2006
Date: Thu, 23 Feb 2006 12:05:55 GMT
Lines: 39
Sender: [email-masked]

To: [email-masked]
Xref: clerew local.usefor:23125
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Thu, 23 Feb 2006 11:26:32 GMT
Lines: 68
Sender: [email-masked]

>Charles Lindsey wrote:
...

>I just don't get why the very first <path-identity>
>needs !.MISMATCH or !.SEEN or !! (= match), all that
>might be to its right is "not-for-mail" or similar:

It's syntactically harmless, though maybe semantically meaningless. So not
worth extra syntax just to prevent it.

>There can't be any (mis)match for say "not-for-mail".

But there might be a (mis)match for "joe".

>> Either way, it does no harm so the syntax need not forbid
>> it (USEPRO might not allow it, but that is another matter).

>Simplified we have  *( entry "!" ) tail  in the s-o-1036 ABNF.

>Now Russ opted for an optional tail as in INN and 1036.  For
>that I couldn't say  *( entry "!" ) [ tail ]  in the syntax,
>Russ certainly did NOT propose that a path might end with "!".

No, the one thing you cannot have is an *optional* tail, because there is
no way to tell whether the last item is a tail or an identity. So either
there is *always* a tail (as in s-0-1036, and it is to be ignored by
relayers), or there is *never* a tail and the last thing is always a
path-identity (maybe with a diagnostic) and relayers take it into account.

>> "not-for-mail" already _is_ the convention

>Of course, in practice, but not yet in the USEFOR draft.

>> (unless Joe prefers to put "joe").

>That Joe should get a clue why that's a really bad idea:

No, it is NOT a bad idea. It is a fairly common practice, and once upon a
time might even have provided a working UUCP email address.

> 
>IMO "not-for-mail" is a SHOULD.  Can't let him try "demon"
>with no hint that this is a bad idea (unless he wants it).

No, not a SHOULD, but a warning that some current software might not
ignore it.

>> Actually, <empty> after the final "!" would also work
>> with current sotware, I suspect, so we might allow that.

>See above, my gut feeling was that this is a non-starter.

OK. Just a suggestion.

To: [email-masked]
Xref: clerew local.usefor:23127
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Thu, 23 Feb 2006 11:46:15 GMT
Lines: 30
Sender: [email-masked]

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

>What's the "joe" here ?  I assume it's one of the permissible
>user names in 1036, in other words a case of "not-for-mail".

>But there never is a "not-for-mail" without <path-identity>
>at the moment, i.e. today we'd have an injecting-server!joe
>or maybe leaf-node!joe (?)

>The <path-identity> and the <tail-entry> are a unit.  They
>come from the same system.  There's no reason why a system
>should add <path-diagnostic> about itself to the path.  The
>"unit" was <path-poster>, now I renamed it to <path-orig>.

No, I don't think so. The <tail-entry> ("joe") comes from the user agent.
The first <path-identity> usually (but not inevitably) comes from the
injecting agent. And if the injecting agent does not see any "joe" in what
it receives, then it adds a "not-for-mail" itself just to keep the syntax
happy.

To: [email-masked]
Xref: clerew local.usefor:23128
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Thu, 23 Feb 2006 11:56:51 GMT
Lines: 46
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> I don't think Russ necessarily wanted 1036 - he just pointed out that
>> INN did not implement s-o-1036.

>If we're going to include Injection-Info, I prefer treating all Path
>entries other than diagnostics as Path entries and not overloading the
>field for injection information.  The latter is primarily useful to avoid
>a new header, and I believe that's why Brad originally proposed the
>complex injection syntax.

Agreed that there is some redundancy here, it is convenient to be able to
glance quickly through the Path header to spot the point in injection. The
additional cost of .POSTED is small, and it causes no harm.

>  If we have a new, complex header to put that
>information in, the only point in also putting it into the Path is to
>carry extra trace information for reinjection.  And that purpose is
>probably better served by renaming the original Injection-Info header.

But that cannot be relied upon. Even insertion of the first
Injection-Info is opnly a SHOUld as things stand.

>> As I said above, if you want to define it that way (which is Not 1036),
>> then you just omit the <tail-entry> entirely.

>Yes.  A note mentioning the not-for-mail bit is worthwhile given existing
>practice.

I agree that if we follow s-o-1036 (tail-entry to be ignored by relayers),
then a NOTE pointing out some diversity of current practice is in order
(probably in USEPRO), together with mention of "not-for-mail" (which is
alread done in USEPRO).

To: [email-masked]
Xref: clerew local.usefor:23126
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Thu, 23 Feb 2006 11:40:01 GMT
Lines: 45
Sender: [email-masked]

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

>I think I'd like to see

>....injecting-server!.POSTED.fifth-modem-from-the-left-in-rack-2!joe
>as a legal construct.

Meaning "we (injecting-server) injected this, and we got it from
fifth-modem-from-the-left-in-rack-2". But in that case, surely
"fifth-modem-from-the-left-in-rack-2" is actually the <path-identity> of
the apparatus that fed it to you (I presume it was injecting-server's rack
and not joe's rack).

So surely what you meant was more like

....injecting-server!.POSTED.joes-laptop!joe

or more likely

....injecting-server!.POSTED.123.234.345.456!joe

in which case injecting-server is asserting that is was the injecting
agent, and also that it came from joes-laptop or from 123.234.345.456 (in
the sense of "SEEN").  But in that case, you might also want to assert
that it didn't come from joes-laptop (in the sense of "MISMATCH").

So wouldn't it be simpler to allow

....injecting-server!.POSTED!.SEEN.joes-laptop!joe
or
....injecting-server!.POSTED!.SEEN.123.234.345.456!joe

(i.e. allow more than one diagnostic), and then you can construct all the
bizarre special cases that you could ever dream of.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 full circle
Date:  Wed, 22 Feb 2006 04:58:19 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 37
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> - Keywords can only be added by updating -usefor-

Yes.  Otherwise it's too difficult to split it cleanly, we
would get diag-match and diag-obs in USEFOR, and diag-other
details in USEPRO, enumerating POSTED / SEEN / MATCH there
for a new diag-keyword in USEFOR, that's IMO too confusing:

 diag-match      = "!"                     ; another "!"
 diag-deprecated = "!" IPv4address         ; (see below)
 diag-other      = "!." diag-keyword [ "." diag-identity ]

 diag-keyword    = 1*ALPHA                 ; see USEPRO

Besides <diag-identity> isn't optional for !.SEEN or !.MATCH

> - diag-deprecated must contain at least one dot, but is
> otherwise free-form, so not distinguishable from
> path-identity. Was this your intention?

That should be Russ' intention (*), "other crap with a dot not
matched by a <path-identity>".  What we really need is IPv4.

We could say so (shown above).  Then some crappy paths where
nobody knows what it is, neither a <path-identity> nor IPv4,
would be "syntactically invalid".  Whatever that means.

For Russ' version (*) we need prose explaining the ambiguity,
and why <path-identity> should match before <diag-deprecated>
for _some_ crappy paths.  Weirder nonsense like adjacent dots
would be still invalid in this version.

So maybe  diag-deprecated = "!" IPv4address  is better.  Bye

*: of course read "as I understood what Russ said"

Date: Wed, 22 Feb 2006 00:34:45 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: #1047 full circle
Sender: [email-masked]

I'd be happy to declare consensus on this one, so people who object should 
speak up quickly....

Implications:

- Keywords can only be added by updating -usefor-
- diag-deprecated must contain at least one dot, but is otherwise 
free-form, so not distinguishable from path-identity. Was this your 
intention?
(I think this is more like "alt B" in the poll than "alt A" - but if the WG 
now has the consensus to keep it in, that's OK with me too)

Personally, I like to allow "!.POSTED!", so would prefer your second 
alternative - YMMV.

                        Harald

--On tirsdag, februar 21, 2006 09:37:49 +0100 Frank Ellermann 
<[email-masked]> wrote:

>
> Hi, a curious effect, I tried to simplify the <path>-ABNF
> with a mandatory <tail-entry> as in s-o-1036 and optional
> <diag-posted> as proposed by Harald, and arrived at the
> same syntax already proposed and discussed some weeks ago.
>
> It's now only clearer (my POV) why <diag-posted> is never
> combined with other diagnostics.  Two possibilities:
>
>      diag-posted = "!.POSTED." diag-identity
>
> Simple, but it doesn't allow a terse ...!.POSTED!...
>
>      diag-posted = "!.POSTED" [ "." diag-identity ]
>
> Could the folks supporting POSTED please state what they
> like better ?  For a <tail-entry> I think it's now clear
> why allowing dots would be a bad idea, we need a "SHOULD
> be not-for-mail" or a decent hint in this direction.
>
> JFTR I add the complete ABNF below, you know it already
> from an earlier attempt.  Can we declare "#1047 solved" ?
>
>                           Bye, Frank
>
> ; ------------------------------------------------------------------#
>
> path            =  "Path:" SP *WSP path-list tail-entry *WSP CRLF
> path-list       =  *( path-identity [FWS] [path-diagnostic] "!" )
>
> path-diagnostic =  diag-match / diag-mismatch / diag-seen /
>                    diag-posted / diag-deprecated
>
> diag-match      =  "!"                           ; an additional "!"
> diag-seen       =  "!.SEEN."           diag-identity
> diag-mismatch   =  "!.MISMATCH."       diag-identity
> diag-posted     =  "!.POSTED"    [ "." diag-identity ]
> diag-deprecated =  "!" 1*( path-nodot "." ) path-nodot
>
> diag-identity   =  path-identity / IPv4address / IPv6address
> tail-entry      =  path-nodot                    ; not-for-mail
>
> path-identity   =  ( 1*( label "." ) toplabel ) / path-nodot
> path-nodot      =  1*( alphanum / "-" / "_" )    ; legacy names
>
> label           =  alphanum [ *( alphanum / "-" ) alphanum ]
> toplabel        =  ( [ label *( "-" ) ] ALPHA   *( "-" ) label   ) /
>                    (   label *( "-" )   ALPHA [ *( "-" ) label ] ) /
>                    (   label          1*( "-" )          label   )
>
> alphanum        =  ALPHA / DIGIT                 ; compare RFC 3696
>
>
>

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  #1047 full circle
Date:  Tue, 21 Feb 2006 09:37:49 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 51
Sender: [email-masked]

Hi, a curious effect, I tried to simplify the <path>-ABNF 
with a mandatory <tail-entry> as in s-o-1036 and optional
<diag-posted> as proposed by Harald, and arrived at the
same syntax already proposed and discussed some weeks ago.

It's now only clearer (my POV) why <diag-posted> is never
combined with other diagnostics.  Two possibilities:

     diag-posted = "!.POSTED." diag-identity

Simple, but it doesn't allow a terse ...!.POSTED!...

     diag-posted = "!.POSTED" [ "." diag-identity ]

Could the folks supporting POSTED please state what they
like better ?  For a <tail-entry> I think it's now clear
why allowing dots would be a bad idea, we need a "SHOULD
be not-for-mail" or a decent hint in this direction.

JFTR I add the complete ABNF below, you know it already
from an earlier attempt.  Can we declare "#1047 solved" ?

                          Bye, Frank

; ------------------------------------------------------------------#

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

path-diagnostic =  diag-match / diag-mismatch / diag-seen /
                   diag-posted / diag-deprecated

diag-match      =  "!"                           ; an additional "!"
diag-seen       =  "!.SEEN."           diag-identity
diag-mismatch   =  "!.MISMATCH."       diag-identity
diag-posted     =  "!.POSTED"    [ "." diag-identity ]
diag-deprecated =  "!" 1*( path-nodot "." ) path-nodot

diag-identity   =  path-identity / IPv4address / IPv6address
tail-entry      =  path-nodot                    ; not-for-mail

path-identity   =  ( 1*( label "." ) toplabel ) / path-nodot
path-nodot      =  1*( alphanum / "-" / "_" )    ; legacy names

label           =  alphanum [ *( alphanum / "-" ) alphanum ]
toplabel        =  ( [ label *( "-" ) ] ALPHA   *( "-" ) label   ) /
                   (   label *( "-" )   ALPHA [ *( "-" ) label ] ) /
                   (   label          1*( "-" )          label   )

alphanum        =  ALPHA / DIGIT                 ; compare RFC 3696

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Organization: The Eyrie
Date: Mon, 20 Feb 2006 11:15:25 -0800
Sender: [email-masked]

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

> After reviewing discussion, a proposed alternate text:

>   The "posting-account" <parameter> identifies the source from which
>   that news server received the article, in a notation that can be
>   interpreted by the news server admin. This notation can include any
>   info the admin deems pertinent, such as the authorized and/or
>   authenticated identity of the poster. In order to limit the exposure
>   of personal data, it SHOULD be given in a form that can't be
>   interpreted by other sites.

>   The "sender" <parameter> identifies a mailbox that the news server
>   believes can be used to reach the user posting the article. There is
>   no implied relationship between the "sender" parameter and the "From"
>   or "Sender" header fields of the article.

>   It is a matter of local policy whether to include the "posting-account"
>   <parameter>, the "<sender>" parameter, both, or neither.

I'm opposed to including that sort of sender parameter.  If the server
wants to put in a Sender header, it should just do that, not stick the
equivalent in some other header.

So to me, the only one that's potentially useful here is the
posting-account parameter, plus an additional authentication-identity
parameter to hold the other identity.  I have no problem with the above
description of the field.

> I'm skeptical myself about the "posting-account" hiding; real hiding
> would mean encryption with a server-specific key, and would have to add
> salt into the encryption to prevent matching posting-account between
> different messages, which would make it indistinguishable from
> "logging-data".

The solution to that problem is to remove logging-data, which is not
clearly specified and probably in practice indistinguishable from
Message-ID.

Whether to really hide the identity or to maintain enough consistency
between posts from the same account to allow automatic EMP recognition
(thereby risking some privacy by creating a persistant identifier) is, I
think, a choice for the local administrator.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Ticket status, February 20, 2006
Organization: The Eyrie
Date: Mon, 20 Feb 2006 11:08:41 -0800
Sender: [email-masked]

Sounds good to me.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1047 permitted constructs - a list
Organization: The Eyrie
Date: Mon, 20 Feb 2006 11:06:37 -0800
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> I don't think Russ necessarily wanted 1036 - he just pointed out that
> INN did not implement s-o-1036.

If we're going to include Injection-Info, I prefer treating all Path
entries other than diagnostics as Path entries and not overloading the
field for injection information.  The latter is primarily useful to avoid
a new header, and I believe that's why Brad originally proposed the
complex injection syntax.  If we have a new, complex header to put that
information in, the only point in also putting it into the Path is to
carry extra trace information for reinjection.  And that purpose is
probably better served by renaming the original Injection-Info header.

> As I said above, if you want to define it that way (which is Not 1036),
> then you just omit the <tail-entry> entirely.

Yes.  A note mentioning the not-for-mail bit is worthwhile given existing
practice.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  !.POSTED ABNF nits and stats (was: #1047 permitted constructs - a list)
Date:  Mon, 20 Feb 2006 17:02:36 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 27
Sender: [email-masked]

> ; ------------------------------------------------------------------#
[...]
> path-orig       =  path-identity [FWS] [orig-diagnostic] "!" orig-tail

Sigh, it doesn't fit into one RfC line this way.  Any good idea
for another name instead of <orig-tail>, but one char. shorter ?

Or could the "!" go to the begin of <orih-tail> ?  Testing:

; ------------------------------------------------------------------#
; [...]
path-list       =  *( path-identity [FWS] [path-diagnostic] "!" )

path-orig       =  path-identity [FWS] [orig-diagnostic] tail-entry
tail-entry      =  path-nodot                    ; not-for-mail

Not the same style as for <path-list>, but maybe acceptable (?)

We're at 26 ABNF lines from <path> to <alphanum> with seven
blank lines.  Without the !.POSTED it was four lines shorter.

But actually <tail-entry> should get its own line if it's not
only an optional <path-nodot> legacy name (as in 1036-style),
so the complete !.POSTED overhead (in ABNF lines) is three.

                         Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 permitted constructs - a list
Date:  Mon, 20 Feb 2006 16:32:09 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 75
Sender: [email-masked]

Harald Tveit Alvestrand wrote:
 
> I think I'd like to see
 
> ....injecting-server!.POSTED.fifth-modem-from-the-left-in-rack-2!joe

> as a legal construct.

What's the "joe" here ?  I assume it's one of the permissible
user names in 1036, in other words a case of "not-for-mail".

But there never is a "not-for-mail" without <path-identity>
at the moment, i.e. today we'd have an injecting-server!joe
or maybe leaf-node!joe (?)

The <path-identity> and the <tail-entry> are a unit.  They
come from the same system.  There's no reason why a system
should add <path-diagnostic> about itself to the path.  The
"unit" was <path-poster>, now I renamed it to <path-orig>.

What you like to see apparently comes from an injecting-server.
It has its very own header field Injection-Info to add such
details, so why do it in the path (again) ?  That's redundant.

Assuming that you still want it, redundant or not:

Then it's in a position where _other_ diagnostics make no
sense at all.  So we could have an optional !.POSTED here
in the <path-orig>, in s-o-1036 style (mandatory tail):

 path-orig = path-id [ "!.POSTED" diag-posted ] "!" path-nodot

Actually we'd also want <diag-obs> here for IPv4, I skip
that detail, the important point is:  No SEEN, no (mis)match
at this place in <path-orig>.

That kills at least the two / three / four weird combos of
POSTED with other diagnostics.

For the very obscure reinjection case we might get POSTED
elsewhere in the path, but if it started in the right way
(not combined with SEEN etc.) it stays in the right way,
it's a proper alternative for a normal <path-diagnostic>.

Is that how you want it ?  Syntax added below, bye, Frank

; ------------------------------------------------------------------#

path            =  "Path:" SP *WSP path-list path-orig *WSP CRLF
path-list       =  *( path-identity [FWS] [path-diagnostic] "!" )

path-orig       =  path-identity [FWS] [orig-diagnostic] "!" orig-tail
orig-tail       =  path-nodot                    ; not-for-mail

path-diagnostic =  diag-match / diag-mismatch / diag-seen / diag-obs
orig-diagnostic =  diag-posted / diag-obs

diag-match      =  "!"                           ; an additional "!"
diag-seen       =  "!.SEEN."     diag-identity
diag-mismatch   =  "!.MISMATCH." diag-identity
diag-posted     =  "!.POSTED"    diag-identity
diag-obs        =  "!" 1*( path-nodot "." ) path-nodot

diag-identity   =  path-identity / IPv4address / IPv6address

path-identity   =  ( 1*( label "." ) toplabel ) / path-nodot
path-nodot      =  1*( alphanum / "-" / "_" )    ; legacy names

label           =  alphanum [ *( alphanum / "-" ) alphanum ]
toplabel        =  ( [ label *( "-" ) ] ALPHA   *( "-" ) label   ) /
                   (   label *( "-" )   ALPHA [ *( "-" ) label ] ) /
                   (   label          1*( "-" )          label   )

alphanum        =  ALPHA / DIGIT                 ; compare RFC 3696

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Ticket status, February 20, 2006
Date:  Mon, 20 Feb 2006 15:40:06 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 61
Sender: [email-masked]

                            Bye, Frank

Date: Mon, 20 Feb 2006 15:35:12 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

--On mandag, februar 20, 2006 15:09:09 +0100 Frank Ellermann 
<[email-masked]> wrote:

>>> path-poster   =  path-identity [ "!" path-nodot ]
>
>> Yes, but that does not even reflect RFC 1036. The
>> <path-identity> there is no different from any other
>> <path-identity> in the RFC 1036 Path (i.e. it is a
>> candidate for examination and refusal to propagate
>> by relayers
>
> It surely says that paths aren't empty and dont't end
> with "!".  We want an optional <path-diagnostic> to the
> right of all later <path-identity>, but not here to the
> right of the very first <path-identity>.

I think I'd like to see

....injecting-server!.POSTED.fifth-modem-from-the-left-in-rack-2!joe

as a legal construct.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 permitted constructs - a list
Date:  Mon, 20 Feb 2006 15:09:09 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 129
Sender: [email-masked]

Charles Lindsey wrote:
 
>> path-poster   =  path-identity [ "!" path-nodot ]
 
> Yes, but that does not even reflect RFC 1036. The
> <path-identity> there is no different from any other
> <path-identity> in the RFC 1036 Path (i.e. it is a
> candidate for examination and refusal to propagate
> by relayers

It surely says that paths aren't empty and dont't end
with "!".  We want an optional <path-diagnostic> to the
right of all later <path-identity>, but not here to the
right of the very first <path-identity>.

> nothing is gained by putting it inside a separate
> <path-poster> item since it implies no semantic 
> difference.

That's not the case, see above, no diagnostic after the
"originating system", as 1036 puts it.

> In all current usage (1036, s-o-1036, INN, whatever),
> it is ONLY what comes after the final "!" that is,
> or is not, treated differently.

Current usage has no <path-diagnostic> as we want to
define it.  There's an off-by-one error either in my
or in your thinking.

> My view is that we should follow s-o-1036

Yes, that's clear, and in theory it should be enough to
remove the square brackets in my <path-poster> to move
from "1036 permissible" to "s-o-1036 required".

But you say it's not, one of us must be wrong.  Won't
surprise me if it's me, but lets get a third opinion.

I just don't get why the very first <path-identity>
needs !.MISMATCH or !.SEEN or !! (= match), all that
might be to its right is "not-for-mail" or similar:

There can't be any (mis)match for say "not-for-mail".

> Yes, but your definition achieves nothing, so what
> is the purpose of it?

Finding out who's right... ;-)  No, seriously, it's
just what I thought how <path-diagnostic> should work,
between peers,

>> The path cannot end with ....!.SEEN.x.y.z!not-for-mail
>> Or maybe it could, but that would be a new idea for me (?!?)
 
> Why ever not? If a diagnostic can appear at other places
> in the Path, why can it not appear there?

Yes, that's the question,

> Either way, it does no harm so the syntax need not forbid
> it (USEPRO might not allow it, but that is another matter).

Simplified we have  *( entry "!" ) tail  in the s-o-1036 ABNF.

Now Russ opted for an optional tail as in INN and 1036.  For
that I couldn't say  *( entry "!" ) [ tail ]  in the syntax,
Russ certainly did NOT propose that a path might end with "!".

And that's the reason why I extracted the required rightmost
<path-identity> getting  *( entry "!" ) entry [ "!" tail ]

I don't prefer 1036-style, but it's the only way to get it
right.  A better name for the <path-poster> is <path-orig>,
but it's not the same as <tail-entry> for s-o-1036-style.

  [s-o-1036 style]
>> That would go to Appendix B "differences from 1036".
 
> Possibly. Not so much a "difference" as "removal of an
> ambiguity".

Okay, but difference is difference whatever the reason is.

> "not-for-mail" already _is_ the convention

Of course, in practice, but not yet in the USEFOR draft.

> (unless Joe prefers to put "joe").

That Joe should get a clue why that's a really bad idea:
 
IMO "not-for-mail" is a SHOULD.  Can't let him try "demon"
with no hint that this is a bad idea (unless he wants it).

> Actually, <empty> after the final "!" would also work
> with current sotware, I suspect, so we might allow that.

See above, my gut feeling was that this is a non-starter.

Could be wrong.  Note that in one of your earlier proposals
that could be an isolated "!" in the last line of a folded
path.

> three or four !.POSTED conbinations were your invention,
> not mine

No.  I asked if you need just two (posted-1 and posted-2).

You said there are three or four combinations, seen-posted,
match-posted, mismatch-posted, only posted.  At that moment
Richard saw that POSTED is cargo-cult and should be deleted,
and I second this, POSTED R.I.P.

> yet you persist in introducing complicated new features to
> what is otherwise a straightforward syntax.

There never was any path-syntax passing Bruce's test, but I
hope that he would be hard pressed to tackle what I tried to
extract from what Russ and Harald apparently want to express.

> I don't think Russ necessarily wanted 1036 - he just pointed
> out that INN did not implement s-o-1036.

He'll tell us.  Removing two square brackets in my proposal
and renaming <path-poster> to <path-orig> is simple enough.

                           Bye, Frank

Date: Mon, 20 Feb 2006 13:37:38 +0000
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Sender: [email-masked]

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

>  The "posting-account" <parameter> identifies the source from which
>  that news server received the article, in a notation that can be
>  interpreted by the news server admin. This notation can include any
>  info the admin deems pertinent, such as the authorized and/or
>  authenticated identity of the poster. In order to limit the exposure
>  of personal data, it SHOULD be given in a form that can't be interpreted
>  by other sites.

Usenet is a public medium where people make public statements. If you
wish to have more privacy than hiding behind a cyberspace identifier
[and that is considerable] then you can purchase service from someone
who provides it.

viz: I don't see the reasoning for the SHOULD rather than MAY, but it is
reasonable to draw attention to the issue

I certainly agree with recasting the text as a privacy issue rather than
a "security" issue.

>  The "sender" <parameter> identifies a mailbox that the news server
>  believes can be used to reach the user posting the article. There is
>  no implied relationship between the "sender" parameter and the "From"
>  or "Sender" header fields of the article.

I don't think a news server can have beliefs... at least not in most
major religions :(

>  It is a matter of local policy whether to include the "posting-account"
>  <parameter>, the "<sender>" parameter, both, or neither.

what you're really trying to say is that there can be two parameters
inserted -- one of which has the form of an email address that may or
may not work and the other of which has the form of values that can be
used to access account level authorisation...

... BUT only the "posting-account" will be of any use to the server
admin and the "sender" is essentially just a way of providing a constant
value that people can use in killfiles -- there's no way of anyone
ensuring that email will actually reach anyone :(

>I'm skeptical myself about the "posting-account" hiding; real hiding would 
>mean encryption with a server-specific key, and would have to add salt into 
>the encryption to prevent matching posting-account between different 
>messages, which would make it indistinguishable from "logging-data". 
>Anything less than that is just protection against people who don't really 
>want to attack you.

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

Date: Mon, 20 Feb 2006 14:12:36 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1159 USEFOR 3.2.14 - Advice on sender vs posting-account
Sender: [email-masked]

Current text:

   The "posting-account" <parameter> identifies the source from which
   that news server received the article.  For security reasons, it
   SHOULD be in a cryptic notation understandable only by the
   administrator of the news server.

   The "sender" <parameter> identifies the mailbox of the verified
   sender of the article (alternatively, it uses the token "verified" to
   indicate that at least any addr-spec in the Sender header field of
   the article, or in the From header field if the Sender header field
   is absent, is correct).  If a news server can verify the sender of an
   article, it SHOULD use this <parameter> in favor of the "posting-
   account" <parameter>.

After reviewing discussion, a proposed alternate text:

   The "posting-account" <parameter> identifies the source from which
   that news server received the article, in a notation that can be
   interpreted by the news server admin. This notation can include any
   info the admin deems pertinent, such as the authorized and/or
   authenticated identity of the poster. In order to limit the exposure
   of personal data, it SHOULD be given in a form that can't be interpreted
   by other sites.

   The "sender" <parameter> identifies a mailbox that the news server
   believes can be used to reach the user posting the article. There is
   no implied relationship between the "sender" parameter and the "From"
   or "Sender" header fields of the article.

   It is a matter of local policy whether to include the "posting-account"
   <parameter>, the "<sender>" parameter, both, or neither.

I'm skeptical myself about the "posting-account" hiding; real hiding would 
mean encryption with a server-specific key, and would have to add salt into 
the encryption to prevent matching posting-account between different 
messages, which would make it indistinguishable from "logging-data". 
Anything less than that is just protection against people who don't really 
want to attack you.

Thoughts?

                       Harald

Date: Mon, 20 Feb 2006 13:26:57 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Ticket status, February 20, 2006
Sender: [email-masked]

  Status: "Text proposed".

  Status: "Text proposed".

That's all folks....

To: [email-masked]
Xref: clerew local.usefor:23110
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Mon, 20 Feb 2006 11:53:00 GMT
Lines: 119
Sender: [email-masked]

>Charles Lindsey wrote:

...

>| Normally, the rightmost name will be the name of the
>| originating system.  However, it is also permissible to
>| include an extra entry on the right, which is the name
>| of the sender.  This is for upward compatibility with
>| older systems.

>Translated to:

>  path-poster   =  path-identity [ "!" path-nodot ]

Yes, but that does not even reflect RFC 1036. The <path-identity> there is
no different from any other <path-identity> in the RFC 1036 Path (i.e. it
is a candidate for examination and refusal to propagate by relayers -
which is exactly how INN will currently treat it). Therefore, nothing is
gained by putting it inside a separate <path-poster> item since it implies
no semantic difference.

In all current usage (1036, s-o-1036, INN, whatever), it is ONLY what
comes after the final "!" that is, or is not, treated differently. I see
no reason whatsoever to change that. So if we define what comes after the
final "!" as the <tail-entry> (just to give it a name) then we can make
some special rule about it (like for relayers to ignore it as in
s-o-1036). My view is that we should follow s-o-1036, as our drafts have
always done, but if you wanted to follow INN, then all you would need to
do would be to remove the <tail-entry> from the syntax entirely, because
that is how INN treats it.

>> The <tail-entry> is BY DEFINITION what comes after the last
>> "!",

>Yes, that's why I renamed it for the 1036 idea with another
>definition, see above.

Yes, but your definition achieves nothing, so what is the purpose of it?

>The path cannot end with ....!.SEEN.x.y.z!not-for-mail  
>Or maybe it could, but that would be a new idea for me (?!?)

Why ever not? If a diagnostic can appear at other places in the Path, why
can it not appear there? It is certainly clearer than
...!added-by-demon.x.y.z!not-for-mail, and even ...!.SEEN.bill!fred might
make some sort of sense. Either way, it does no harm so the syntax need
not forbid it (USEPRO might not allow it, but that is another matter).

>> I would be in favour of following s-o-1036, as our drafts
>> have always done, and hope that INN will conform in due course

>That would go to Appendix B "differences from 1036". 

Possibly. Not so much a "difference" as "removal of an ambiguity".

>  
>> little actual harm appears to have arisen from the present
>> INN

>It would be hard to see any harm.  We'd also need not-for-mail
>as convention to keep the harm as limited as it apparently is.

"not-for-mail" already _is_ the convention (unless Joe prefers to put
"joe"). Actually, <empty> after the final "!" would also work with current
sotware, I suspect, so we might allow that.

>> So leave it be. It causes no harm, and may even provide for
>> special treatment of the pre-injection part of the Path at
>> some future date

>Sorry, when we arrived at three or four !.POSTED combinations
>it was too much for me.  I'd opt to kill it, it is redundant,
>the old NNTP-Posting-Host is visible in the new Injection-Info.

The three or four !.POSTED conbinations were your invention, not mine, so
they hardly form an argument for not having .POSTED. They are clearly a
nonsense. If we need that effect, then we allow more than one diagnostic
after each <path-identity>. If we don't, then we restrict it to one. You
keep telling me to KISS, and yet you persist in introducing complicated
new features to what is otherwise a straightforward syntax.

>>> 4  demon!added-by-demon-2-0-0-127-adsl.example!not-for-mail
>>> 5  demon!added-by-demon-2-0-0-127-adsl.example
>[...]
>> And the "added-by-demon" examples should really have started
>> with a ".", since their intent was evidently diagnostic.

>See above.  If the syntax says <path-poster> and what you see
>is <path-poster>....

Which seems to me like a good argument for not saying anything at all
about <path-poster>.

>Note that (4) is as expected ambiguous with the 1036 idea, and
>you said that you want s-o-1036.  Russ wanted 1036, I tried to
>reflect his ideas in syntax.  We can't have a syntax that tries
>both at the same time.

I don't think Russ necessarily wanted 1036 - he just pointed out that INN
did not implement s-o-1036. As I said above, if you want to define it that
way (which is Not 1036), then you just omit the <tail-entry> entirely.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 permitted constructs - a list
Date:  Fri, 17 Feb 2006 23:37:00 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 130
Sender: [email-masked]

Charles Lindsey wrote:

> Changing <tail-entry> to <path-poster> will not if itself
> achieve anything. 

Sure, I changed the name because it reflects what 1036 says:

| Normally, the rightmost name will be the name of the
| originating system.  However, it is also permissible to
| include an extra entry on the right, which is the name
| of the sender.  This is for upward compatibility with
| older systems.

Translated to:

  path-poster   =  path-identity [ "!" path-nodot ]

> Either way, the syntax you have given is plain WRONG.

It's the 1036 prose in ABNF, interpreting "name of the sender"
as syntactically the same as "legacy name", i.e. <path-nodot>.

Of course it's "wrong" if you want s-o-1036 instead od 1036,
I've said this later in the quoted article:

# If the outcome is "mandatory" the proposed syntax as shown
# above is of course wrong.  This is a tricky part of #1047
# with some consequences for the ABNF, the prose, and USEPRO.

> The <tail-entry> is BY DEFINITION what comes after the last
> "!",

Yes, that's why I renamed it for the 1036 idea with another
definition, see above.

> So anything to the left of the last "!" is always a
> <path-identity>,

The left side of <path-poster> as shown _is_ a <path-identity>,
(or there's only a <path-identity> - different case)

> or maybe a <diagnostic>, whether it was placed there before
> or after injection. So that includes "joes-laptop".

A <path-poster> or <tail-entry> made up by the news server is
still a <path-poster> or <tail-entry>, not a diagnostic.  

The path cannot end with ....!.SEEN.x.y.z!not-for-mail  
Or maybe it could, but that would be a new idea for me (?!?)

> I would be in favour of following s-o-1036, as our drafts
> have always done, and hope that INN will conform in due course

That would go to Appendix B "differences from 1036". 
  
> little actual harm appears to have arisen from the present
> INN

It would be hard to see any harm.  We'd also need not-for-mail
as convention to keep the harm as limited as it apparently is.

And not in USEPRO, users could be tempted to "improve" this
not-for-mail if they don't see that it's no nonsense.  I didn't
know this until Russ mentioned what INN does two weeks ago.
 
> Please, no new tickets. This is part of #1047.

#1047 is apparently too big to tackle it in one piece.  It's
not necessarily better to have three new instead of one old
ticket, but we didn't make a decisive progress with #1047 :-(

> So leave it be. It causes no harm, and may even provide for
> special treatment of the pre-injection part of the Path at
> some future date

Sorry, when we arrived at three or four !.POSTED combinations
it was too much for me.  I'd opt to kill it, it is redundant,
the old NNTP-Posting-Host is visible in the new Injection-Info.

> it will be a long time before it is widely enough implemented
> to be able to rely on its presence.

I'm not that optimistic about the future of Usenet.  Maybe if
folks adopt a new text format, Wiki formatting or even HTML.

>> 4  demon!added-by-demon-2-0-0-127-adsl.example!not-for-mail
>> 5  demon!added-by-demon-2-0-0-127-adsl.example
[...]
> And the "added-by-demon" examples should really have started
> with a ".", since their intent was evidently diagnostic.

See above.  If the syntax says <path-poster> and what you see
is <path-poster>, then it is <path-poster> no matter who put it
there.  If you want another possibility you need another syntax.

>> Case (4) and (5) are a situation where demon makes up a tail
>> entry based on reverse DNS.
 
> No, they are NOT part of the <tail-entry>.

With your definition !added-by-... in (5) is the <tail-entry>,
stuff to the right of the last "!".  The rest of the confusion
is just again 1036 <path-poster> vs. s-o-1035 <tail-entry>.

Note that (4) is as expected ambiguous with the 1036 idea, and
you said that you want s-o-1036.  Russ wanted 1036, I tried to
reflect his ideas in syntax.  We can't have a syntax that tries
both at the same time.

> As written, #4 will get treated as a normal <path-identity>s 
> by s-o-1036 systems (indeed by all current systems).

We've heard that that's not the case, INN treats not-for-mail
as legacy name, only because there is no such system it works.

>> 6  demon!127.0.0.2!not-for-mail
>> 7  demon!127.0.0.2
[...]
> #6 MUST be accepted (though maybe not generated - though
> I believe only one major site currently inserts such things).

Okay, the 127.0.0.2 is <diag-obs>.  For the 1036 syntax and INN
that would result in the known not-for-mail "system", no harm.

> I don't really care whether #7 is legal or not.

Let's say illegal and skip the tricks needed to "legalize" it.

                      Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:23107
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Fri, 17 Feb 2006 11:54:51 GMT
Lines: 134
Sender: [email-masked]

>>> 6 tail-entry       = path-identity [ "!" tail-local ]
>>> 7 tail-local       = *( path-nodot "." ) path-nodot

>Yes, mostly.  Some cases of this <tail-local> won't match
>a <path-identity>.  In a later wannabe-improved proposal
>(see below) I simlified it to...

>| path-poster   =  path-identity [ "!" path-nodot ]

>| path-identity =  ( 1*( label "." ) toplabel ) / path-nodot
>| path-nodot    =  1*( alphanum / "-" / "_" )    ; legacy names

>...with <path-poster> as rightmost entry in the <path>,
>A new name to avoid any confusion with older <tail-entry>
>concepts.

Changing <tail-entry> to <path-poster> will not if itself achieve
anything. Either way, the syntax you have given is plain WRONG.

The <tail-entry> is BY DEFINITION what comes after the last "!", and
therefore it cannot possibly have a "!" in it. It is NOT and NEVER HAS
BEEN the whole of what was present at the time the article was offered to
the injector (and it cannot be so, because of the occasional possibility
of reinjection).

So anything to the left of the last "!" is always a <path-identity>, or
maybe a <diagnostic>, whether it was placed there before or after
injection. So that includes "joes-laptop".

>ACK, either we pick what INN and 1036 do (= "permissible"),
>or we pick what s-o-1036 and Usefor drafts proposed, i.e.
>"mandatory" with a conventional "not-for-ail".

No, INN does not do what 1036 prescribes because 1036 contradicts itself
and does not prescribe anything (or it prescribes both, or however else
you choose to describe the mess).

So I would be in favour of following s-o-1036, as our drafts have always
done, and hope that INN will conform in due course (though little actual
harm appears to have arisen from the present INN).

>Therefore I think we should get a poll / ticket / decision
>about this point, some kind of #1047-a maybe:  Stick to
>1036 or adopt s-o-1036 for the right end of the <path> ?

Please, no new tickets. This is part of #1047.

>> demon!.POSTED!joe
>> demon!.POSTED!joes-laptop!joe
>> or something different?

>At the moment I think that !.POSTED is at best hopeless,
>useless, redundant, a bad idea, and dead.  So I'd say...

On the contrary, of the diagnostics currently envisioned, I think .POSTED
is the one most likely to catch some Bad Guys (certainly it will catch more
than .MISMATCH). So leave it be. It causes no harm, and may even provide
for special treatment of the pre-injection part of the Path at some future
date (modulo reinjection niggles when there would be two of them). Richard
seems to envisage such usage, but it will be a long time before it is
widely enough implemented to be able to rely on its presence.

>1  demon!joes-laptop
>2  demon!joes-laptop!joe
>3  demon!joes-laptop!not-for-mail
>4  demon!added-by-demon-2-0-0-127-adsl.example!not-for-mail
>5  demon!added-by-demon-2-0-0-127-adsl.example

>...for the 1036 variant.  All five cases for an article
>posted at demon.  For the s-o-1036 variant just strike
>cases (1) and (5).

No need to strike any of them. Perhaps "joes-laptop" really is the guy's
name. Whatever, it just gets ignored by relayers in the s-o-1036 variant.

And the "added-by-demon" examples should really have started with a ".",
since their intent was evidently diagnostic.

>Cases (1) up to (3) are from a system styling itself as
>as joes-laptop.  Case (4) and (5) are a situation where
>demon makes up a tail entry based on reverse DNS.

No, they are NOT part of the <tail-entry>. As written, #4 will get
treated as a normal <path-identity>s by s-o-1036 systems (indeed by all
current systems).

>JFTR, "we" decided, right or wrong, that constructs...

>6  demon!127.0.0.2!not-for-mail
>7  demon!127.0.0.2

>...are formally "illegal".  IPv4 is no <path-identity>,
>it matches only <diag-obs> in my latest propsal.  With
>that (7) is a "syntax error", there's no <path-poster>.

#6 MUST be accepted (though maybe not generated - though I believe only
one major site currently inserts such things). I don't really care whether
#7 is legal or not. It is certainly not worth a single line of extra
syntax to force it one way or the other.

>In (6) "not-for-mail" matches <path-identity>, that's
>syntactically fine, but semantically of course crap.

>I don't think that this subtlety could cause harm, but
>we _could_ "legalize" the IPv4 case in <path-poster>:

>- path-poster   =  path-identity [ "!" path-nodot ]
>+ path-poster   =  diag-identity [ "!" path-nodot ]

><diag-identity> allows <path-identity> plus IPs.  Ugly
>like hell, for months we tried to limit <diag-identity>
>and especially IPv4 to <path-diagnostic>, and here it
>would pop again outside of <path-diagnostic>.  At least
>only in <path-poster> and not elsewhere in the <path>.

You are inventing problems where none exists. Your <diag-identity> IS a
<path-diagnostic>. If people want to use such things, they should put a
".SEEN" into it (anything else should just be legacy).

To: [email-masked]
Xref: clerew local.usefor:23106
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Subject: Re: #1047 permitted constructs - a list
Date: Fri, 17 Feb 2006 11:14:14 GMT
Lines: 46
Sender: [email-masked]

In <[email-masked]> John Stanley <[email-masked]> writes:

>That's true, but the REASON that it is now a "diagnostic" and not just a
>path-identity is so that "we" could prohibit colons in path-identities and
>still keep IPv6 addresses with their colons. For many years, people have
>been able to put this stuff in the header field without a special name
>for it.

No, that is not the reason. Originally (in the days of Brad Templeton) a
diagnostic was indicated by assorted special delimiters. Then we changed
to keywords with assorted forms of syntax. And finally, we have settled
for diagnostics always starting with a "." (except for the special case of
"!!" which is really a shorthand for ".MATCH.the.identity.already.present").

As a separate issue, we seek to avoid the use of colons so far as
possible. We don't allow IP addresses as identities, but we still allow
them in diagnostics, and hence we restrict colons to IPv6 addresses in
diagnostics.

And as a further issue, the consensus seems to be that if IPv6 addresses
are to occur at all, then we will use the commonly accepted notation for
them, rather than inventing somethbng new.

As a result of all that, we can now safely say that the only barewords
which might be troublesome are those composed of four or less hexadecimal
digits, and that is considered an acceptable risk.

>I want it to either have a definition that is meaningful AND correct or 
>get rid of it. Either way. This "it's not ..." is meaningless, especially 
>since one known use is to record the identity of a site that the message 
>has passed through.

It would perhaps be useful to include an explanation of the purpose of
diagnostics in USEFOR perhaps using a tidied up version of what I wrote
yesterday.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 permitted constructs - a list
Date:  Fri, 17 Feb 2006 02:14:25 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 136
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

>> 6 tail-entry       = path-identity [ "!" tail-local ]
>> 7 tail-local       = *( path-nodot "." ) path-nodot

> I think tail-local is syntactically indistinguishable
> from a path-identity.

Yes, mostly.  Some cases of this <tail-local> won't match
a <path-identity>.  In a later wannabe-improved proposal
(see below) I simlified it to...

| path-poster   =  path-identity [ "!" path-nodot ]

| path-identity =  ( 1*( label "." ) toplabel ) / path-nodot
| path-nodot    =  1*( alphanum / "-" / "_" )    ; legacy names

...with <path-poster> as rightmost entry in the <path>,
A new name to avoid any confusion with older <tail-entry>
concepts.

> I don't think that's a problem (USENET has worked for a
> long time with it being indistinguishable), but we might
> want to point it out in prose.

ACK, either we pick what INN and 1036 do (= "permissible"),
or we pick what s-o-1036 and Usefor drafts proposed, i.e.
"mandatory" with a conventional "not-for-ail".

The convention would help to avoid real legacy names like
"demon" instead of "not-for-mail".  I don't care what we
pick, you could put your hat on and toss a coin... <g>

If the outcome is "mandatory" the proposed syntax as shown
above is of course wrong.  This is a tricky part of #1047
with some consequences for the ABNF, the prose, and USEPRO.

Therefore I think we should get a poll / ticket / decision
about this point, some kind of #1047-a maybe:  Stick to
1036 or adopt s-o-1036 for the right end of the <path> ?

> demon!.POSTED!joe
> demon!.POSTED!joes-laptop!joe
> or something different?

At the moment I think that !.POSTED is at best hopeless,
useless, redundant, a bad idea, and dead.  So I'd say...

1  demon!joes-laptop
2  demon!joes-laptop!joe
3  demon!joes-laptop!not-for-mail
4  demon!added-by-demon-2-0-0-127-adsl.example!not-for-mail
5  demon!added-by-demon-2-0-0-127-adsl.example

...for the 1036 variant.  All five cases for an article
posted at demon.  For the s-o-1036 variant just strike
cases (1) and (5).

Cases (1) up to (3) are from a system styling itself as
as joes-laptop.  Case (4) and (5) are a situation where
demon makes up a tail entry based on reverse DNS.

JFTR, "we" decided, right or wrong, that constructs...

6  demon!127.0.0.2!not-for-mail
7  demon!127.0.0.2

...are formally "illegal".  IPv4 is no <path-identity>,
it matches only <diag-obs> in my latest propsal.  With
that (7) is a "syntax error", there's no <path-poster>.

In (6) "not-for-mail" matches <path-identity>, that's
syntactically fine, but semantically of course crap.

I don't think that this subtlety could cause harm, but
we _could_ "legalize" the IPv4 case in <path-poster>:

- path-poster   =  path-identity [ "!" path-nodot ]
+ path-poster   =  diag-identity [ "!" path-nodot ]

<diag-identity> allows <path-identity> plus IPs.  Ugly
like hell, for months we tried to limit <diag-identity>
and especially IPv4 to <path-diagnostic>, and here it
would pop again outside of <path-diagnostic>.  At least
only in <path-poster> and not elsewhere in the <path>.

The ambiguity "is it <diah-obs> or <diag-identity> ?"
is clear for (7), only <diag-identity> works at the end
of a <path>.

For (6) it's really ambiguous as far as somebody thinks
that "not-for-mail" is a legacy name.

Maybe that question could be "#1047-a-a", do we want to
screw up your <path-diagnostic> plan for this IPv4 case ?

It's of course possible to tune this, so that at least
IPv6 is again strictly forbidden within <path-poster>.

The other open question could be a new "#1047-b", do we
want to get rid of !.POSTED

I'd say "yes", it's like the weird LTRU-stars, if there
is no progress for some time it was already screwed up.

For certain values of "some time", weeks in LTRU, years
here.  Last known state without a !.POSTED added below.

                        Bye, Frank

; ------------------------------------------------------------------#

path            =  "Path:" SP *WSP path-list path-poster *WSP CRLF
path-list       =  *( path-identity [FWS] [path-diagnostic] "!" )

path-diagnostic =  diag-match / diag-mismatch / diag-seen / diag-obs

diag-match      =  "!"                           ; an additional "!"
diag-seen       =  "!.SEEN."     diag-identity
diag-mismatch   =  "!.MISMATCH." diag-identity
diag-obs        =  "!" 1*( path-nodot "." ) path-nodot

diag-identity   =  path-identity / IPv4address / IPv6address

path-poster     =  path-identity [ "!" path-nodot ]

path-identity   =  ( 1*( label "." ) toplabel ) / path-nodot
path-nodot      =  1*( alphanum / "-" / "_" )    ; legacy names

label           =  alphanum [ *( alphanum / "-" ) alphanum ]
toplabel        =  ( [ label *( "-" ) ] ALPHA   *( "-" ) label   ) /
                   (   label *( "-" )   ALPHA [ *( "-" ) label ] ) /
                   (   label          1*( "-" )          label   )

alphanum        =  ALPHA / DIGIT                 ; compare RFC 3696

Date: Thu, 16 Feb 2006 13:53:49 -0800 (PST)
From: John Stanley <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>
cc: [email-masked]
Subject: Re: Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

On Thu, 16 Feb 2006, Harald Tveit Alvestrand wrote:

>> effect. And yet, the only reason it exists as a separate item is so that
>> colons can be made legal in an IPv6 that records -- a server that the
>> article has passed through.
>
> I don't see that as a reason. The decision of the WG to put stuff in the path 
> that wasn't "servers the article has passed through" seems to have been taken 
> a very long time before I joined the WG, and long before there was anything 
> near consensus on the format of IPv6 addresses.

That's true, but the REASON that it is now a "diagnostic" and not just a
path-identity is so that "we" could prohibit colons in path-identities and
still keep IPv6 addresses with their colons. For many years, people have
been able to put this stuff in the header field without a special name
for it.

>> If nobody can define it in any terms other than "it isn't" one of the
>> things that it actually IS, then it does not merit inclusion in a
>> standard.
>
> Do you want to call for a poll for "remove anything that isn't a 
> path-identity from the path"?

I want it to either have a definition that is meaningful AND correct or 
get rid of it. Either way. This "it's not ..." is meaningless, especially 
since one known use is to record the identity of a site that the message 
has passed through.

To: [email-masked]
Xref: clerew local.usefor:23102
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Thu, 16 Feb 2006 11:12:20 GMT
Lines: 48
Sender: [email-masked]

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

>--On tirsdag, januar 31, 2006 15:11:46 +0100 Frank Ellermann 
><[email-masked]> wrote:

>> 6 tail-entry       = path-identity [ "!" tail-local ]
>> 7 tail-local       = *( path-nodot "." ) path-nodot

>I think tail-local is syntactically indistinguishable from a path-identity. 
>I don't think that's a problem (USENET has worked for a long time with it 
>being indistinguishable), but we might want to point it out in prose.

>Also - in the case of "demon" accepting a submission from user "joe", do we 
>want the path to be

>demon!.POSTED!joe
>demon!.POSTED!joes-laptop!joe

>or something different?

Either of those if fine and such examples are seen regularly. It is up to joe.

>I don't think insisting that non-Usenet machines have valid and 
>discoverable names that are path-identities and don't clash with the 
>path-identity of a news-server is a Good Thing....

If joe wants to cause mischief by using the identity of a well-known news
server, then there is no way we can stop him (though the presence of
.POSTED may make it harder for joe to do so in the future).

The actual utility of such examples is more likely to appear when there is
a substantial local network behind some firewall, with the .POSTED only
being added to those (publicly available) articles which emerge outside
the firewall.

I agree that the syntax of the tail-entry may as well be the same as the
syntax of a path-identity.

To: [email-masked]
Xref: clerew local.usefor:23103
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Subject: Re: #1047 permitted constructs - a list
Date: Thu, 16 Feb 2006 11:22:30 GMT
Lines: 39
Sender: [email-masked]

In <[email-masked]> John Stanley <[email-masked]> writes:

>Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>>> But just what IS a path-diagnostic anyway?

>> It's not an identity, and most of the WG wants it in the path.

>What it is NOT is not a definition. "Wants it in the path" resulting it
>it BEING in the path ought to depend on it having some defined meaning,
>not just a desire to have something in the path that has no definition.

>The only "definition" we have is that it is "something in the path that
>isn't a server that article has passed through", or something to that
>effect. And yet, the only reason it exists as a separate item is so that
>colons can be made legal in an IPv6 that records -- a server that the
>article has passed through.

A reasonable definition would be that it is "something in the path that
isn't a server that article has passed through, and which was added by
some relayer as an aid to diagnosing problems that might arise (for
example attempts to disguise the source of an article)."

It will be up to USEPRO to define which diagnostics may be used, and how
(or else we hardcode the allowable ones into USEFOR, though I am coming
more and more to the belief that USEFOR should just establish the
framework and let USEPOR specify the gory details, as indeed it currently
does, though not with the currently proposed notations).

Date: Thu, 16 Feb 2006 09:47:05 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: John Stanley <[email-masked]>, [email-masked]
Subject: Re: Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

--==========8B2B77F1B98171CAC7E4==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 15. februar 2006 15:01 -0800 John Stanley <[email-masked]> wrote:

>
>
> Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:
>
>> Can you point me at your poll opinion? Didn't see it in the list =
archives
>> when I scanned them...
>
> Re: #1047 POLL: Path-diagnostics
> http://www.imc.org/ietf-usefor/mail-archive/msg02801.html

Thanks, and my apologies - don't understand why I missed it.

>
>>> But just what IS a path-diagnostic anyway?
>
>> It's not an identity, and most of the WG wants it in the path.
>
> What it is NOT is not a definition. "Wants it in the path" resulting it
> it BEING in the path ought to depend on it having some defined meaning,
> not just a desire to have something in the path that has no definition.
>
> The only "definition" we have is that it is "something in the path that
> isn't a server that article has passed through", or something to that
> effect. And yet, the only reason it exists as a separate item is so that
> colons can be made legal in an IPv6 that records -- a server that the
> article has passed through.

I don't see that as a reason. The decision of the WG to put stuff in the=20
path that wasn't "servers the article has passed through" seems to have=20
been taken a very long time before I joined the WG, and long before there=20
was anything near consensus on the format of IPv6 addresses.

> If nobody can define it in any terms other than "it isn't" one of the
> things that it actually IS, then it does not merit inclusion in a
> standard.

Do you want to call for a poll for "remove anything that isn't a=20
path-identity from the path"?

                       Harald

--==========8B2B77F1B98171CAC7E4==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========8B2B77F1B98171CAC7E4==========--

Date: Thu, 16 Feb 2006 10:06:17 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

--On tirsdag, januar 31, 2006 15:11:46 +0100 Frank Ellermann 
<[email-masked]> wrote:

> 6 tail-entry       = path-identity [ "!" tail-local ]
> 7 tail-local       = *( path-nodot "." ) path-nodot

I think tail-local is syntactically indistinguishable from a path-identity. 
I don't think that's a problem (USENET has worked for a long time with it 
being indistinguishable), but we might want to point it out in prose.

Also - in the case of "demon" accepting a submission from user "joe", do we 
want the path to be

demon!.POSTED!joe
demon!.POSTED!joes-laptop!joe

or something different?

I don't think insisting that non-Usenet machines have valid and 
discoverable names that are path-identities and don't clash with the 
path-identity of a news-server is a Good Thing....

                    Harald

Date: Wed, 15 Feb 2006 15:01:04 -0800 (PST)
From: John Stanley <[email-masked]>
To: [email-masked]
Subject: Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>Can you point me at your poll opinion? Didn't see it in the list archives
>when I scanned them...

Re: #1047 POLL: Path-diagnostics
http://www.imc.org/ietf-usefor/mail-archive/msg02801.html

>> But just what IS a path-diagnostic anyway?

> It's not an identity, and most of the WG wants it in the path.

What it is NOT is not a definition. "Wants it in the path" resulting it
it BEING in the path ought to depend on it having some defined meaning,
not just a desire to have something in the path that has no definition.

The only "definition" we have is that it is "something in the path that
isn't a server that article has passed through", or something to that
effect. And yet, the only reason it exists as a separate item is so that
colons can be made legal in an IPv6 that records -- a server that the
article has passed through.

If nobody can define it in any terms other than "it isn't" one of the
things that it actually IS, then it does not merit inclusion in a
standard.

To: [email-masked]
Xref: clerew local.usefor:23098
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Wed, 8 Feb 2006 16:33:20 GMT
Lines: 44
Sender: [email-masked]

>>> But just what IS a path-diagnostic anyway?
> 
>> It's not an identity, and most of the WG wants it in the
>> path. That's the only things *I* feel sure about.

>Richard convinced me that !.POSTED is somewhat redundant -
>servers supporting a new Path syntax will also support the
>new Injection-Info with a "posting-host" <host-value>.

>Charles showed - probably that wasn't his intention - that
>three kinds of !.POSTED are more trouble than they are worth.

>Without !.POSTED the syntax can be short (14 productions):
><http://article.gmane.org/gmane.ietf.usenet.format/30600>

No, I think it is still useful to have .POSTED at the proper place in the
Path, but if you want to avoid complications, then limit the number of
diagnostics to one. My point was that a SEEN/MISMATCH/etc diagnostic was
redundant as well as a .POSTED because that information should also be
available in the Injection-Info (however, there is certainly one current
site that puts an IP address - with the intention of "SEEN" - at the point
where the .POSTED would appear).

I think the real benefit of .POSTED is that it stands out in the Path
(for those looking for malpractice) and focusses attention on the place to
look. Moreover, if it appears twice, that immediately signals a place
where closer inspection may be needed (though it is not necessarily an
error, it often will be - i.e. a malefactor who tries to preload a .POSTED
into his Path will likely be spotted).

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 permitted constructs - a list
Date:  Tue, 07 Feb 2006 18:34:43 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

>> But just what IS a path-diagnostic anyway?
 
> It's not an identity, and most of the WG wants it in the
> path. That's the only things *I* feel sure about.

Richard convinced me that !.POSTED is somewhat redundant -
servers supporting a new Path syntax will also support the
new Injection-Info with a "posting-host" <host-value>.

Charles showed - probably that wasn't his intention - that
three kinds of !.POSTED are more trouble than they are worth.

Without !.POSTED the syntax can be short (14 productions):
<http://article.gmane.org/gmane.ietf.usenet.format/30600>

                          Bye, Frank

Date: Tue, 07 Feb 2006 15:09:49 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: John Stanley <[email-masked]>, [email-masked]
Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

Can you point me at your poll opinion? Didn't see it in the list archives 
when I scanned them...

WRT dot: Told you Frank was better at ABNF than I am....

--On torsdag, januar 26, 2006 14:07:06 -0800 John Stanley 
<[email-masked]> wrote:

> How about:
>
> - A path-element can be:
>
> * path-identity followed by !
> * path-diagnostic followed by !
>
> And then the rest about what a path-diagnostic can be, since the path
> diagnostic is defined to contain the leading dot.
>
> But just what IS a path-diagnostic anyway?

It's not an identity, and most of the WG wants it in the path. That's the 
only things *I* feel sure about.

                  Harald

To: [email-masked]
Xref: clerew local.usefor:23095
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Mon, 6 Feb 2006 10:54:50 GMT
Lines: 77
Sender: [email-masked]

In <[email-masked]> Richard Clayton <[email-masked]> writes:

>In message <[email-masked]>, Charles Lindsey
><[email-masked]> writes
>>
>>As a matter of interest, I have just posted an article with 'demon' at the
>>end of the Path to misc.test (message id <[email-masked]>).

>you also appear to have cross-posted it to demon.service, which isn't a
>test group :(

>It's rather poorly designed as a test -- since you need to concentrate
>on which peering arrangements actually use the !demon! tag :(

Wouldn't be the first time someone has misused demon.service :-( . I sent
it there in the hope that it might uncover a few cases where the !demon!
tag would be relevant, though I do not understand the particular
circumstances in which that tag can cause problems well enough to be sure.

>>Its primary intent was always to assist in the detection of malpractice,

>then it will fail, just like the other schemes for such detection

Hence the word "assist".

>>
>>Yes, the leading "." would help. But the simplest algorithm is still to go
>>along the Path and every time you encounter a "!" you take the chunk of
>>stuff since the last "!" and see if it occurs in the relevant part of your
>>'sys' file.

>you're changing emphasis. First you were discussing efficiency and now
>you are discussing "the simplest algorithm". Sometimes the two things
>align, but not always :(

Maybe. What I described is roughly what present implementations do AIUI.

>>It is possible (in rare cases of reinjection) for there to be two .POSTEDs
>>in the Path. 

>and the value of this re-injection is what ??

We discussed this 18 months or so ago, and it appeared that such
reinjection currently happens in occasional peculiar but justifiable
circumstances (such as complex pieces of gatewaying or some situations
where an article was injected at multiple sites), and that we therefore
needed to write our protocols to be resilient to it.

>>The Injection-Info header, as currently defined, is SHOULD
>>include, rather than MUST. 

>So do you envisage the POSTED being "MUST" or "SHOULD" ?

AS USEPRO is currently written, it is MUST, but if anyone wants to review
that when we come to discuss USEPRO, then fine. In any case, even a MUST
will take time to be implemented widely enough to be relied upon.

>>And it is simpler for someone looking for
>>malpractice to look for all the evidence in the one place.

>and that place is the logs of the machines through which the article
>passed. No trust should be placed elsewhere :(

Sadly, few sites will divulge the contents of their logs to outside
enquirers, and is would appear that such unwillingness to divulge
correlates highly with the blackness of the site's hat :-( .

To: [email-masked]
Xref: clerew local.usefor:23092
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: POSTED-1 vs. POSTED-2
Date: Fri, 3 Feb 2006 12:14:05 GMT
Lines: 48
Sender: [email-masked]

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

>--On 2. februar 2006 14:27 +0000 Charles Lindsey <[email-masked]>=20
>wrote:

>>> diag-match      =3D  "!"                           ; an additional "!"
>>> diag-posted     =3D  "!.POSTED" [ "." diag-identity ]
>>> diag-seen       =3D  "!.SEEN."        diag-identity
>>> diag-mismatch   =3D  "!.MISMATCH."    diag-identity
>>> diag-deprecated =3D  "!" 1*( path-nodot "." ) path-nodot
>>
>> No. That doesn't do the whole job. Consider all the different kinds of
>> diagnostic one might like to write:

>Charles,

>should I take your desire for "many different kinds of disagnostic" as a
>vote for leaving the actual set of keywords to USEPRO?

AIUI. Frank wants to hard-code the exact diagnostics into USEFOR. You
would like to leave it open in USEFOR and to deal with it in USEPRO. I
would be happy to accept either (but maybe with more MUSTard and less ABNF
that Frank). If pushed, I would express a mild preference for leaving the
details to USEPRO. I don't think anyone else has commented on this
particular issue.

The more immediate question is whether to allow more than one
<diagnostic-entry> to be inserted at one place. It does no inherent harm
(except to increase the length of the Path), but the only case known where
it might be useful is if the injecting agent wants to say that he
.POSTED it and also that the site he got it from was
SEEN/MATCHed/MISMATCHed/whatever.

There is currently provision to do that in USEPRO, but the Injection-Info
header is also available for that purpose, so no great harm would arise
from sticking with just a single diagnostic. I gather tha Russ takes that
view. I would prefer allowing several, but only mildly so.

To: [email-masked]
Xref: clerew local.usefor:23093
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Fri, 3 Feb 2006 12:23:27 GMT
Lines: 35
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> Moreover, splitting a <path-identity> and its following <diagnostic> (if
>> any) onto separate lines seems contrary to all good sense, since they
>> logically belong together.

>I was under the impression that diagnostics come *before* their
>corresponding path-identities, not after.  Please remember, ABNF is not a
>specification for how to construct the Path, just a specification for how
>it should look; don't draw conclusions from what's grouped in the ABNF.

You can argue that the identity followed by the diagnostic is the
interesting pairing, since that is what is added by one site (and
presumably that site then decided that the line had now gotten long enough
for a further fold).

Or you can argue that the diagnostic and the following identity is the
interesting pairing, because those two refer to the same site (or not in
the case of a MISMATCH).

My view is to let the relaying implementor worry about it by allowing the
fold in either place.

Date: Fri, 3 Feb 2006 12:42:50 +0000
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>
>In <[email-masked]> Richard Clayton <[email-masked]> 
>writes:
>
>>In message <[email-masked]>, Charles Lindsey
>><[email-masked]> writes
>>>>>
>>>>>There are people with username 'demon'.
>>>
>>>>Then, almost two decades later, I will finally be able to read their
>>>>pearls of wisdom on Usenet.... just as soon as there is one path between
>>>>their machine and Demon Internet's which stops scanning the Path: header
>>>>field when the POSTED text is reached.
>>>
>>>>I look forward to it :)
>
>As a matter of interest, I have just posted an article with 'demon' at the
>end of the Path to misc.test (message id <[email-masked]>).

you also appear to have cross-posted it to demon.service, which isn't a
test group :(

It's rather poorly designed as a test -- since you need to concentrate
on which peering arrangements actually use the !demon! tag :(

Hence it turned up just fine -- doubtless to confuse the denizens of
demon.service no end :(

   Newsgroups: misc.test,demon.service,demon.test
   Path: news.demon.co.uk!mutlu.news.demon.net!peer-uk.news.demon.net!ki
   bo.news.demon.net!aotearoa.belnet.be!news.belnet.be!news.germany.com!
   feeder.ecngs.de!ecngs!feeder2.ecngs.de!212.23.6.68.MISMATCH!zen.net.u
   k!hamilton.zen.co.uk!193.60.199.26.MISMATCH!feed4.jnfs.ja.net!jnfs.ja
   .net!peernews.mcc.ac.uk!news.mcc.ac.uk!clerew!demon
   From:  "Charles Lindsey" <[email-masked]>
   Subject: Path <tail-entry> test
   Message-ID: <[email-masked]>
   X-Newsreader: NN version 6.5.2 (NOV)
   Date: Fri, 3 Feb 2006 11:21:29 GMT
   Lines: 23
   Xref: news.demon.co.uk misc.test:301438 demon.service:41973
   demon.test:5167

etc

>>> >>Yes, but it has never been suggested that relayers are expected to
>detect >>that ".POSTED" and stop reading the Path at that point.
>
>>If you don't suggest that, then so far as I can see, the feature has
>>zero purpose whatsoever and I withdraw any support for it.
>
>Its primary intent was always to assist in the detection of malpractice,

then it will fail, just like the other schemes for such detection

>If some implementor likes to use it to shorten his search of the Path,
>then he is welcome to do so, but I don't think we can assume that all
>implementors are going to do that.

if this is added (and I'm rapidly failing to see that it is valuable)
then it is essential to prescribe its semantics!  saying "you might like
to use it" is just asking for trouble :(

>>>and I guess that detecting ".POSTED" would eat up more cpu cycles than
>>>just carrying on to the end (this code is in a time-critical part of any
>>>relayer).
>
>>not if you code it right ! [and note that the leading "." makes it easy
>>to feed into a separate path]
>
>Yes, the leading "." would help. But the simplest algorithm is still to go
>along the Path and every time you encounter a "!" you take the chunk of
>stuff since the last "!" and see if it occurs in the relevant part of your
>'sys' file.

you're changing emphasis. First you were discussing efficiency and now
you are discussing "the simplest algorithm". Sometimes the two things
align, but not always :(

>>The X-Trace header line (whatever that's now called) tells you which
>>machine did the injection. There's no value I can see in putting it
>>somewhere else as well. If there is such a value, then could you remind
>>us what it is?
>
>It is possible (in rare cases of reinjection) for there to be two .POSTEDs
>in the Path. 

and the value of this re-injection is what ??

>The Injection-Info header, as currently defined, is SHOULD
>include, rather than MUST. 

So do you envisage the POSTED being "MUST" or "SHOULD" ?

>And it is simpler for someone looking for
>malpractice to look for all the evidence in the one place.

and that place is the logs of the machines through which the article
passed. No trust should be placed elsewhere :(

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

To: [email-masked]
Xref: clerew local.usefor:23090
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Fri, 3 Feb 2006 11:53:56 GMT
Lines: 69
Sender: [email-masked]

In <[email-masked]> Richard Clayton <[email-masked]> writes:

>In message <[email-masked]>, Charles Lindsey
><[email-masked]> writes
>>>>
>>>>There are people with username 'demon'.
>>
>>>Then, almost two decades later, I will finally be able to read their
>>>pearls of wisdom on Usenet.... just as soon as there is one path between
>>>their machine and Demon Internet's which stops scanning the Path: header
>>>field when the POSTED text is reached.
>>
>>>I look forward to it :)

As a matter of interest, I have just posted an article with 'demon' at the
end of the Path to misc.test (message id <[email-masked]>).
It probably won't prove much, but it would be interesting to hear whether
it arrives at demon's servers, or whether any demon customers have
problems with it. As an afterthought, I have also included demon.service
and demon.test in the Newsgroups.

>> >>Yes, but it has never been suggested that relayers are expected to
detect >>that ".POSTED" and stop reading the Path at that point.

>If you don't suggest that, then so far as I can see, the feature has
>zero purpose whatsoever and I withdraw any support for it.

Its primary intent was always to assist in the detection of malpractice,
and there is some existing usage of it for that purpose (but not with our
presently proposed notation).

If some implementor likes to use it to shorten his search of the Path,
then he is welcome to do so, but I don't think we can assume that all
implementors are going to do that.

>>and I guess that detecting ".POSTED" would eat up more cpu cycles than
>>just carrying on to the end (this code is in a time-critical part of any
>>relayer).

>not if you code it right ! [and note that the leading "." makes it easy
>to feed into a separate path]

Yes, the leading "." would help. But the simplest algorithm is still to go
along the Path and every time you encounter a "!" you take the chunk of
stuff since the last "!" and see if it occurs in the relevant part of your
'sys' file.

>The X-Trace header line (whatever that's now called) tells you which
>machine did the injection. There's no value I can see in putting it
>somewhere else as well. If there is such a value, then could you remind
>us what it is?

It is possible (in rare cases of reinjection) for there to be two .POSTEDs
in the Path. The Injection-Info header, as currently defined, is SHOULD
include, rather than MUST. And it is simpler for someone looking for
malpractice to look for all the evidence in the one place.

To: [email-masked]
Xref: clerew local.usefor:23091
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Fri, 3 Feb 2006 11:58:45 GMT
Lines: 25
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> Moreover, since a relayer that ignores a genuine <path-identity> creates
>> only marginal harm, it would be safer to ignore that uncommon practice
>> than to run the risk that the sender's name in a <tail-entry> might
>> match something.

>If people want to require a non-site tail entry, I have no particular
>objections to that, but I do think that it's at least worth a warning that
>not all existing software is going to parse the Path that way.

Yes, I have made a Note to mention that in USEPRO.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  #1047 Path without POSTED (was: #1047 permitted constructs - a list)
Date:  Fri, 03 Feb 2006 01:30:42 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Sender: [email-masked]

path            =  "Path:" SP *WSP path-list path-poster *WSP CRLF
path-list       =  *( path-identity [FWS] [path-diagnostic] "!" )

path-diagnostic =  diag-match / diag-mismatch / diag-seen / diag-obs

diag-match      =  "!"                           ; an additional "!"
diag-seen       =  "!.SEEN."     diag-identity
diag-mismatch   =  "!.MISMATCH." diag-identity
diag-obs        =  "!" 1*( path-nodot "." ) path-nodot

diag-identity   =  path-identity / IPv4address / IPv6address

path-poster     =  path-identity [ "!" path-nodot ]

path-identity   =  ( 1*( label "." ) toplabel ) / path-nodot
path-nodot      =  1*( alphanum / "-" / "_" )    ; legacy names

label           =  alphanum [ *( alphanum / "-" ) alphanum ]
toplabel        =  ( [ label *( "-" ) ] ALPHA   *( "-" ) label   ) /
                   (   label *( "-" )   ALPHA [ *( "-" ) label ] ) /
                   (   label          1*( "-" )          label   )

alphanum        =  ALPHA / DIGIT                 ; compare RFC 3696

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 permitted constructs - a list
Date:  Fri, 03 Feb 2006 00:48:41 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

Russ Allbery wrote:

> sometimes I miss things

I certainly missed or never noted that this is a critical
difference between s-o-1036 and 1036.  Checking it again,
even RfC 850, the predecessor of 1036, had this:

| Normally, the rightmost name  will  be  the  name  of  the
| originating  system.   However,  it is also permissible to
| include an extra entry on the right, which is the name  of
| the  sender.   This is for upward compatibility with older
| system.

RfC 850 was published 1983.  The "permissible" local part is
now an adult.  <sigh />
                             Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1047 permitted constructs - a list
Date:  Fri, 03 Feb 2006 00:10:59 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 40
Sender: [email-masked]

Richard Clayton wrote:

>> it has never been suggested that relayers are expected to
>> detect that ".POSTED" and stop reading the Path at that
>> point.
 
> If you don't suggest that, then so far as I can see, the
> feature has zero purpose whatsoever and I withdraw any
> support for it.

+1
 
> there's some limited sense in at least trying to do it once
> and for all [and right] : not because it will be useful very
> often, but because it will prevent further re-inventions and
> hence reduce the risk of future damage

With now up to four kinds of POSTED, naked, combined with SEEN,
combined with MATCH, and combined with MISMATCH, and Harald
asking for "votes" about a list of keywords in USEPRO I "vote"
to get rid of that crap, no <diag> at all, copy either 1036 or
s-o-1036 - permissible <tail-entry> vs. mandatory <tail-entry>.

> The X-Trace header line (whatever that's now called) tells
> you which machine did the injection. There's no value I can
> see in putting it somewhere else as well.

+1

>> the only >safe thing is to stop looking when you find an
>> item that has no "!" after it.
 
> or as we programmers call it, "end of line"

End of header field:  "end of line" doesn't work with optional
folding _before_ "!".  The consequence of putting this "comma"
at the begin of the next line (instead of at the end of line).

                              Bye, Frank

Date: Thu, 02 Feb 2006 10:35:00 -0800
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: POSTED-1 vs. POSTED-2
Sender: [email-masked]

--==========F4DA8E6BE6C76FD4F300==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 2. februar 2006 14:27 +0000 Charles Lindsey <[email-masked]>=20
wrote:

>> diag-match      =3D  "!"                           ; an additional "!"
>> diag-posted     =3D  "!.POSTED" [ "." diag-identity ]
>> diag-seen       =3D  "!.SEEN."        diag-identity
>> diag-mismatch   =3D  "!.MISMATCH."    diag-identity
>> diag-deprecated =3D  "!" 1*( path-nodot "." ) path-nodot
>
> No. That doesn't do the whole job. Consider all the different kinds of
> diagnostic one might like to write:

Charles,

should I take your desire for "many different kinds of disagnostic" as a=20
vote for leaving the actual set of keywords to USEPRO?

              Harald

--==========F4DA8E6BE6C76FD4F300==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========F4DA8E6BE6C76FD4F300==========--

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: POSTED-1 vs. POSTED-2
Organization: The Eyrie
Date: Thu, 02 Feb 2006 10:41:00 -0800
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> No. That doesn't do the whole job. Consider all the different kinds of
> diagnostic one might like to write:

> 1. No diagnostics at all.
> 2. !.SEEN.foo.example!     (that's where I got the article from; I didn't
>                             check it against what the incoming Path said)
> 3. !.MISMATCH.foo.example! (that's where I got the article from; I
>                             checked, and that's NOT what the incoming
> 			    Path said)
> 4. !!                      (where I got the article from agreed with
>                             what the incoming Path said)
> 5. !.POSTED!               (I am the injecting agent)
> 6. #5 plus #2
> 7. #5 plus #3
> 8. #5 plus #4

> Your proposal gives !.POSTED.foo.example! for case #6, but makes no
> provision for #7 and #8.

> My suggestion allows:

>    !.POSTED!.SEEN.foo.example!...
>    !.POSTED!.MISMATCH.foo.example!...
>    !.POSTED!!...

I see no reason to allow any of those things.  They don't make any sense.
The step prior to an injecting agent has no valid Path identity that the
injecting agent should be concerned with.

> I.e., you just allow more than one diagnostic to be added by the one
> site.  A simple rule. It might admit some bizarre cases, but OTOH it
> would allow for more extensions in the future. Yes, your grammar could
> be extended to allow those, but it gets more complicated each time.

I have a hard time imagining why you'd need two consecutive diagnostics
rather than just adding another diagnostic type if you really needed
something else.

> The reason we have the short form "!!" for the !.MATCH! case rather than
> for !.POSTED! is that there could be a dozen or more !.MATCH!es in the
> header, and we are trying not to make that header unnecessarily long.

Yeah, I still sort of agree with this.

>>> path = "Path" ":" SP [FWS]

Er, that [FWS] is right out, is it not?  I thought we already said that
you're not allowed to have a continuation before any content.

>>>           *( path-identity [FWS] "!" *( path-diagnostic ) )
>>>           tail-entry [FWS] CRLF

>>> path-diagnostic = "." keyword [ "." diagnostic-identity ] [FWS] "!"
>>>                      / "!"

>> One [FWS] too many.  No "!.POSTED!.SEEN.ip".  No "!.POSTED!!y".

> I want [FWS] allowed in front of any "!" or "!!" (or after, or both if
> people so want). KISS and all that.

> My syntax allows both of "!.POSTED!.SEEN.ip" and "!.POSTED!!y", so I
> don't understand your last remark.

Charles's approach here doesn't bother me either.  As long as you can't
put FWS in the middle of !! and ideally the FWS comes before the !, I'm
happy.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1047 permitted constructs - a list
Organization: The Eyrie
Date: Thu, 02 Feb 2006 10:34:14 -0800
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Frank Ellermann <[email-masked]> writes:

>> Not exactly related rant:  This path-issue puzzles me.  A Path is
>> almost as essential as Message-ID, Newsgroups, and Control for NetNews.
>> What did the earlier incarnations of this WG do, if some of these
>> essential UseNet concepts still aren't clear ?

> The earlier incarnations of this WG were quite clear about the concept
> of the <tail-entry>, right up to the moment yesterday when Russ dropped
> his bombshell and told us that INN did not do what everyone else had
> assumed up to then.

The key word being "assumed."  That assumption was buried deep enough into
the discussions that I didn't notice it until the other day.  When I
noticed it, I thought "that doesn't sound right" and went and checked.

If you want me to go check something like that, you've got to either bring
the assumption prominently to my attention or (ideally) ask.  Also, I'm
human and sometimes I miss things (like large portions of the Path
discussion, which has for years been so far off in the weeds that I've
largely ignored it).

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1047 permitted constructs - a list
Organization: The Eyrie
Date: Thu, 02 Feb 2006 10:30:34 -0800
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> Well that is what Son-of-1036 tells you to do (and hence, not
> surprisingly, what CNews does). And it is what our drafts have said for
> the last nine years or so, and so I am amazed that nobody has nemtioned
> in all that time that INN in fact did not do it.

Yeah, it says something, doesn't it?

> However, senders are much less likely to use "due diligence" when
> choosing their names, and if a sender decides to call himself "demon"
> and to preload that into the tail of his Path, then there is not much we
> can do about it except to say that <tail-entry>s MUST NOT be inspected
> by relayers. In which case it would be better for INN to implement that.

This is all find and grand and all, and I don't even really disagree
(although I have even less time to work on INN than I had a year ago), but
there's a lot of existing software out there.  Again, can I strongly
recommend against assuming that anyone writing news software has even
*heard* of Son-of-1036, let alone implemented it?

>>>> path-list       = 1*( path-identity [FWS] path-separator )
>>>> path-separator  = [ path-diagnostic ] "!"

>>>     Path: news.site4.exmaple!news.site3.exmaple!news.site2.example
>>>           !news.site1.example!not-for-mail

>>> rather than splitting the line _after_ a "!" at the end of the previous
>>> line. On the basis of that, I have always tried to make my syntax that
>>> way round, and resisted Frank's attempts to make it the other way.

>> Yes, that's what the above does.  That's the whole point of the change.

> Aaaaarrrrrgggggghhhhhhhh! That is ugly!.

I sort of liked it.

> But to say that [FWS] is only allowed in a place that is not even next to
> a separator at all is bizarre.

That isn't what it says.  I think you need to look at the grammar in
context again.  It says that if you have a Path diagnostic, you have to
keep it together with the site that it's diagnosing, and otherwise you can
split before any path separator.

Now, I can see the argument that we should also allow [FWS] between a
!.SEEN diagnostic and the Path entry from that site, in case both are
fairly long, but shoehorning that into the ABNF is a bit beyond me this
morning.

> Moreover, splitting a <path-identity> and its following <diagnostic> (if
> any) onto separate lines seems contrary to all good sense, since they
> logically belong together.

I was under the impression that diagnostics come *before* their
corresponding path-identities, not after.  Please remember, ABNF is not a
specification for how to construct the Path, just a specification for how
it should look; don't draw conclusions from what's grouped in the ABNF.

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: #1047 permitted constructs - a list
Organization: The Eyrie
Date: Thu, 02 Feb 2006 10:23:55 -0800
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:

> Moreover, Russ did not say that "paths without local-part at the end are
> common practice". He actually said (or has said now) that they are a most
> UNcommon practice (in spite of 1036).

That's more emphasis than I think I used.

> Moreover, since a relayer that ignores a genuine <path-identity> creates
> only marginal harm, it would be safer to ignore that uncommon practice
> than to run the risk that the sender's name in a <tail-entry> might
> match something.

If people want to require a non-site tail entry, I have no particular
objections to that, but I do think that it's at least worth a warning that
not all existing software is going to parse the Path that way.

Date: Thu, 2 Feb 2006 17:31:18 +0000
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>
>In <[email-masked]> Richard Clayton <[email-masked]> 
>writes:
>
>>In message <[email-masked]>, Seth Breidbart
>><[email-masked]> writes
>>>
>>>There are people with username 'demon'.
>
>>Then, almost two decades later, I will finally be able to read their
>>pearls of wisdom on Usenet.... just as soon as there is one path between
>>their machine and Demon Internet's which stops scanning the Path: header
>>field when the POSTED text is reached.
>
>>I look forward to it :)
>
>Yes, but it has never been suggested that relayers are expected to detect
>that ".POSTED" and stop reading the Path at that point.

If you don't suggest that, then so far as I can see, the feature has
zero purpose whatsoever and I withdraw any support for it.

> Current ones don't,

Well indeed -- it's a new feature.

Of course if we stopped trying to create new features we'd be done
quicker.  However, this one did seem to have a small amount of merit

    unlike the traceability stuff where we're only pressing on because
    of Russ's observation that people kept re-inventing the feature and
    doing it badly -- so there's some limited sense in at least trying
    to do it once and for all [and right] : not because it will be
    useful very often, but because it will prevent further re-inventions
    and hence reduce the risk of future damage

>and I guess that detecting ".POSTED" would eat up more cpu cycles than
>just carrying on to the end (this code is in a time-critical part of any
>relayer).

not if you code it right ! [and note that the leading "." makes it easy
to feed into a separate path]

>Moreover, there are specialized things that come _after_ the .POSTED that
>relayers may need to be interested in, such as "cybercancel". 

If it was me issuing the cybercancels, I'd do a deal with my local
injector not to put in a .POSTED entry at all :)

However, if it's felt that people have to look at all of the items on
the path (which would include people's names, the names of their own
machines and a whole lot of other crud put there by their posting agents
then I suddenly stop seeing the point of POSTED).

The X-Trace header line (whatever that's now called) tells you which
machine did the injection. There's no value I can see in putting it
somewhere else as well. If there is such a value, then could you remind
us what it is?

>So the only
>safe thing is to stop looking when you find an item that has no "!" after
>it.

or as we programmers call it, "end of line"

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

To: [email-masked]
Xref: clerew local.usefor:23080
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: POSTED-1 vs. POSTED-2
Date: Thu, 2 Feb 2006 14:27:50 GMT
Lines: 113
Sender: [email-masked]

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

>In other words POSTED-1 is a standalone keyword, and POSTED-2
>comes with an argument <diagnostic-identity>.

>Therefore we don't need two different POSTED-1 and POSTED-2,
>one name POSTED with an optional <diagnostic-identity> will do:

>diag-match      =  "!"                           ; an additional "!"
>diag-posted     =  "!.POSTED" [ "." diag-identity ]
>diag-seen       =  "!.SEEN."        diag-identity
>diag-mismatch   =  "!.MISMATCH."    diag-identity
>diag-deprecated =  "!" 1*( path-nodot "." ) path-nodot

No. That doesn't do the whole job. Consider all the different kinds of
diagnostic one might like to write:

1. No diagnostics at all.
2. !.SEEN.foo.example!     (that's where I got the article from; I didn't
                            check it against what the incoming Path said)
3. !.MISMATCH.foo.example! (that's where I got the article from; I
                            checked, and that's NOT what the incoming
			    Path said)
4. !!                      (where I got the article from agreed with
                            what the incoming Path said)
5. !.POSTED!               (I am the injecting agent)
6. #5 plus #2
7. #5 plus #3
8. #5 plus #4

Your proposal gives !.POSTED.foo.example! for case #6, but makes no
provision for #7 and #8.

My suggestion allows:

   !.POSTED!.SEEN.foo.example!...
   !.POSTED!.MISMATCH.foo.example!...
   !.POSTED!!...

I.e., you just allow more than one diagnostic to be added by the one site.
A simple rule. It might admit some bizarre cases, but OTOH it would allow
for more extensions in the future. Yes, your grammar could be extended to
allow those, but it gets more complicated each time.

OTOH, we could decide that we don't actually need Cases #6, #7 and #8 at
all. I think that is the first decision we need to make, and then the gory
details can be fixed.

>Ideas about swapping "!.POSTED!" and "!.MATCH!" for "!!" also
>obsolete, we need some miracles to get the <path> right without
>any "!!" optimization.

The reason we have the short form "!!" for the !.MATCH! case rather than
for !.POSTED! is that there could be a dozen or more !.MATCH!es in the
header, and we are trying not to make that header unnecessarily long.

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

>> path-diagnostic = "." keyword [ "." diagnostic-identity ] [FWS] "!"
>>                      / "!"

>One [FWS] too many.  No "!.POSTED!.SEEN.ip".  No "!.POSTED!!y".

I want [FWS] allowed in front of any "!" or "!!" (or after, or both if
people so want). KISS and all that.

My syntax allows both of "!.POSTED!.SEEN.ip" and "!.POSTED!!y", so I don't
understand your last remark.

>>> We had some "no IP" rough consensus, therefore you can't
>>> match it as ordinary <path-identity> together with FQDNs.

>> The only agents that will ever "parse" the Path header in
>> anger are relaying agents,

>Yes, with your ABNF they match IPv4 as <o-p-i>, with my latest
>ABNF they get <diag-deprecated> (= Harald's <o-p-d>), and for
>Russ' _old_ proposal they would get a <path-legacy> with dots.

It makes no difference whether naked IPv4 is classed as <o-p-i> or as
<o-p-d>, just so long as it is written that any <o-p-*> is MUST accept,
MUST NOT generate. So you write whichever syntax is easiest to write,
which is <o-p-i> AFAICS.

>Harald's <o-p-d> tries to guarantee that they'd ignore IPv4.

Any "ignoring" that happens is done by relayers, who will write the
fastest bit of C-code that will get the job done (which is likely to be to
accept them all, but just don't have any of the ignorable ones in your
'sys' file). Like I said below:

>> all they are ever going to do is to ignore any folding and
>> whitespace, and then identify the chunks that come between
>> the "!"s. If any such chunk appears in their 'sys' file, then
>> they will not forward the article to that site. So if some
>> admin is stupid enough to put ".POSTED" in his 'sys' file,
>> he will never forward any articles anywhere :-( .

To: [email-masked]
Xref: clerew local.usefor:23077
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Thu, 2 Feb 2006 12:50:25 GMT
Lines: 84
Sender: [email-masked]

In <[email-masked]> Russ Allbery <[email-masked]> writes:

>Charles Lindsey <[email-masked]> writes:

>> My understanding is that existing practice is for relayers to ignore
>> whatever comes after the last "!" (typically "not-for-mail") when
>> deciding whether not to send the article back to some site listed in the
>> Path. The reason being, of course, that historically that last entry
>> respresented a person rather than a site (still does, sometimes).

>INN certainly doesn't do this.  I don't know what other servers you may
>have been looking at to judge existing practice.

Well that is what Son-of-1036 tells you to do (and hence, not
surprisingly, what CNews does). And it is what our drafts have said for
the last nine years or so, and so I am amazed that nobody has nemtioned in
all that time that INN in fact did not do it.

<bareword>s as <path-identity>s are tricky things, and admins who want to
use them need to do "due diligence" (e.g. by examining lots of existing
Paths) to be reasonably sure they are unique. USPERO contains suitable
dire warnings against such perils, but the practice of using them is
widespread and is unlikely to go away.

However, senders are much less likely to use "due diligence" when choosing
their names, and if a sender decides to call himself "demon" and to
preload that into the tail of his Path, then there is not much we can do
about it except to say that <tail-entry>s MUST NOT be inspected by
relayers. In which case it would be better for INN to implement that.

The converse problem, where the last thing in the Path is actually a
site-name is, so you say, rare. Moreover, a relayer failing to look at it
will, at worst, send an article to a site which already has it. So the
safe solution is for the <tail-entry> always to be ignored, as our drafts
have always said.

>>> path-list       = 1*( path-identity [FWS] path-separator )
>>> path-separator  = [ path-diagnostic ] "!"

>>     Path: news.site4.exmaple!news.site3.exmaple!news.site2.example
>>           !news.site1.example!not-for-mail

>> rather than splitting the line _after_ a "!" at the end of the previous
>> line. On the basis of that, I have always tried to make my syntax that
>> way round, and resisted Frank's attempts to make it the other way.

>Yes, that's what the above does.  That's the whole point of the change.

Aaaaarrrrrgggggghhhhhhhh! That is ugly!.

1. We could have a rule that [FWS] was allowed before ANY "!" (or "!!").
2. Or we could have a rule that [FWS] was allowed after ANY "!" (or "!!").
3. Or we could have a rule which allowed both.

Morover, that would be consistent with folding conventions for other
headers that consist of comma- or WSP-separated lists.

But to say that [FWS] is only allowed in a place that is not even next to
a separator at all is bizarre. Moreover, splitting a <path-identity> and
its following <diagnostic> (if any) onto separate lines seems contrary to
all good sense, since they logically belong together.

And what is gained by making such a rule? We only got into this argument
because Frank claimed, wrongly, that the ABNF could not be written to
allow option #1 above. Nonsense. It is easily done.

The casual observer is just going to see a stream of "chunks" separated by
"!"s, and would be most surprised to learn that folding is not allowed at
_any_ "!".

To: [email-masked]
Xref: clerew local.usefor:23079
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Thu, 2 Feb 2006 13:06:02 GMT
Lines: 35
Sender: [email-masked]

In <[email-masked]> Richard Clayton <[email-masked]> writes:

>In message <[email-masked]>, Seth Breidbart
><[email-masked]> writes
>>
>>There are people with username 'demon'.

>Then, almost two decades later, I will finally be able to read their
>pearls of wisdom on Usenet.... just as soon as there is one path between
>their machine and Demon Internet's which stops scanning the Path: header
>field when the POSTED text is reached.

>I look forward to it :)

Yes, but it has never been suggested that relayers are expected to detect
that ".POSTED" and stop reading the Path at that point. Current ones don't,
and I guess that detecting ".POSTED" would eat up more cpu cycles than
just carrying on to the end (this code is in a time-critical part of any
relayer).

Moreover, there are specialized things that come _after_ the .POSTED that
relayers may need to be interested in, such as "cybercancel". So the only
safe thing is to stop looking when you find an item that has no "!" after
it.

To: [email-masked]
Xref: clerew local.usefor:23076
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Thu, 2 Feb 2006 12:17:04 GMT
Lines: 41
Sender: [email-masked]

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

>Charles Lindsey wrote:
> 
>>> tail-entry       = path-identity [ "!" tail-local ]
>>> tail-local       = *( path-nodot "." ) path-nodot

>Right or wrong, it's strict 1036, and Russ said that paths
>without local-part at the end are common practice.  If that
>works somehow today, it will continue to work tomorrow.

That most certainly is NOT strict 1036.

1036 actually contradicts itself (no surprise there) by saying that the
thing after the last separator ("!") might be the name of a site or it
might be the name of the sender, and there is absolutely no way to tell
which. That is a problem which Son-of-1036 tried to fix.

But NO-WAY does 1036 allow a "!" inside of the name of anything (it would
plainly be ambiguous), so how come your syntax above is trying to allow a
"!" inside the <tail-entry> (which is, by definition, the thing that comes
_after_ the last "!"). Your syntax makes no sense at all.

Moreover, Russ did not say that "paths without local-part at the end are
common practice". He actually said (or has said now) that they are a most
UNcommon practice (in spite of 1036).  Moreover, since a relayer that
ignores a genuine <path-identity> creates only marginal harm, it would be
safer to ignore that uncommon practice than to run the risk that the
sender's name in a <tail-entry> might match something.

To: [email-masked]
Xref: clerew local.usefor:23078
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Date: Thu, 2 Feb 2006 12:55:00 GMT
Lines: 22
Sender: [email-masked]

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

>Not exactly related rant:  This path-issue puzzles me.  A Path
>is almost as essential as Message-ID, Newsgroups, and Control
>for NetNews.  What did the earlier incarnations of this WG do,
>if some of these essential UseNet concepts still aren't clear ?

The earlier incarnations of this WG were quite clear about the concept of
the <tail-entry>, right up to the moment yesterday when Russ dropped his
bombshell and told us that INN did not do what everyone else had assumed
up to then.

Date: Wed, 1 Feb 2006 18:37:04 +0000
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

In message <[email-masked]>, Seth Breidbart
<[email-masked]> writes
>
>>>Yes.  But it's a case of "no news is bad news" for any system
>>>styling itself with <path-legacy> name "richard". 
>>
>> there is no such system (trivial to check by inspection) and the wording
>> that was agreed means that there will be no such systems in the future
>>
>>> Can we now
>>>please stop to pretend that all legacy names are completely
>>>harmless ?
>>
>> this one is
>
>There are people with username 'demon'.

Then, almost two decades later, I will finally be able to read their
pearls of wisdom on Usenet.... just as soon as there is one path between
their machine and Demon Internet's which stops scanning the Path: header
field when the POSTED text is reached.

I look forward to it :)

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

Date: Wed, 1 Feb 2006 13:17:59 -0500 (EST)
From: Seth Breidbart <[email-masked]>
To: [email-masked]
Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

>>Yes.  But it's a case of "no news is bad news" for any system
>>styling itself with <path-legacy> name "richard". 
>
> there is no such system (trivial to check by inspection) and the wording
> that was agreed means that there will be no such systems in the future
>
>> Can we now
>>please stop to pretend that all legacy names are completely
>>harmless ?
>
> this one is

There are people with username 'demon'.

Seth

Date: Wed, 1 Feb 2006 09:15:42 +0000
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: Re: #1047 permitted constructs - a list
Sender: [email-masked]

In message <[email-masked]>, Frank Ellermann
<[email-masked]> writes
>
>Richard Clayton wrote:
> 
>> systems will still create tails like
> 
>>         !highwayman.com!richard
> 
>> since that was the way you could write back to
>> [email-masked]
>
>Yes.  But it's a case of "no news is bad news" for any system
>styling itself with <path-legacy> name "richard". 

there is no such system (trivial to check by inspection) and the wording
that was agreed means that there will be no such systems in the future

> Can we now
>please stop to pretend that all legacy names are completely
>harmless ?

this one is

>> There's no need for a SHOULD here (making existing working
>> clients only "conditionally compliant") merely for specious
>> tidyness.
>
>IBTD, as Russ explained it a "local part" news.clara.net would
>be a horrible idea, and users need to know that it's horrible.

provided that the injection agent adds "POSTED" then there will be a
separation between the part of the Path: that is being used to improve
the efficiency of the flood-fill algorithm and the part of the Path:
that provides some traceability beyond the injection agent machine

>> Usenet works really well with people putting email local
>> parts at the end of Paths ... they don't in practice clash
>> with either UUCP names or machine/domain names -- leastwise
>> if they do, no-one notices
>
>Exactly the latter is the problem:  noone notices.

perhaps because it never happens ?

>  If they'd
>do it _intentionally_ to exclude news.clara.net let them play.
>
>But if they don't know what they are doing it's a trap.  It's
>the purpose of a standard to prevent foreseeable harm as far as
>possible, and "SHOULD NOT use <tail-local>, or where required
>use a dummy not-for-mail" could help.  

I don't think the injection agent is in a position to understand the
traceability information in the Path: part of an article that is given
to it -- and therefore it should not be messing around with it because
it will discard potentially useful information [the owner of
highwayman.com may be in a position to lart "richard" rather than "fred"
by examining the tail]

The injection agent can prevent harm by adding POSTED (so there is value
in doing that -- and you'll have noted that I haven't spoken against
that construct).

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755