headers
Richard Clayton | 1 Feb 2006 01:15

Re: #1047 permitted constructs - a list


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <43DFEE6D.7B24 <at> xyzzy.claranet.de>, Frank Ellermann
<nobody <at> xyzzy.claranet.de> writes

>How do you avoid that ?  Should we mention that using a common
>"not-for-mail" is a SHOULD on the border to MUST, best excuse
>to violate it would be no <tail-local> at all ?  Mention it in
>USEFOR ?  Ordinary users and leaf-nodes have no reason to look
>into USEPRO when they configure whatever <tail-local>.

systems will still create tails like

        !highwayman.com!richard

since that was the way you could write back to richard <at> highwayman.com
(back when you needed more text to the left of this bang path as well to
reach the site)  [AIUI, I didn't use Usenet that long ago]

hence "not-for-mail" to stress not using it this way :)

There's no need for a SHOULD here (making existing working clients only
"conditionally compliant") merely for specious tidyness.

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
(Continue reading)

Permalink | Reply | 11 comments |
headers
Frank Ellermann | 1 Feb 2006 05:03
Picon
Picon

Re: #1047 permitted constructs - a list


Richard Clayton wrote:

> systems will still create tails like

>         !highwayman.com!richard

> since that was the way you could write back to
> richard <at> highwayman.com

Yes.  But it's a case of "no news is bad news" for any system
styling itself with <path-legacy> name "richard".  Can we now
please stop to pretend that all legacy names are completely
harmless ?

> I didn't use Usenet that long ago

Nor me, I learned about s-o-1036 and gateway issues in an FTN
echo (Fido Technology Network, zone 21, not the core FidoNet).

Before that all I knew was "Emily Postnews" (IMHO still better
than all other "netiquette" texts including the obscure RfC ;-)

> 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.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Richard Clayton | 1 Feb 2006 10:15

Re: #1047 permitted constructs - a list


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <43E03307.44D7 <at> xyzzy.claranet.de>, Frank Ellermann
<nobody <at> xyzzy.claranet.de> writes
>
>Richard Clayton wrote:
> 
>> systems will still create tails like
> 
>>         !highwayman.com!richard
> 
>> since that was the way you could write back to
>> richard <at> highwayman.com
>
>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
(Continue reading)

Permalink | Reply | 9 comments |
headers
Seth Breidbart | 1 Feb 2006 19:17
Picon
Favicon

Re: #1047 permitted constructs - a list


>>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
Permalink | Reply | 8 comments |
headers
Richard Clayton | 1 Feb 2006 19:37

Re: #1047 permitted constructs - a list


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <200602011817.k11IHxm21995 <at> panix5.panix.com>, Seth Breidbart
<sethb <at> panix.com> 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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Charles Lindsey | 2 Feb 2006 13:17
Picon
Picon

Re: #1047 permitted constructs - a list


In <43DF9F9D.22D5 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Charles Lindsey | 2 Feb 2006 13:50
Picon
Picon

Re: #1047 permitted constructs - a list


In <87fyn4tfgw.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>Charles Lindsey <chl <at> clerew.man.ac.uk> 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Charles Lindsey | 2 Feb 2006 13:55
Picon
Picon

Re: #1047 permitted constructs - a list


In <43DFEE6D.7B24 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> 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.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      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
Permalink | Reply | 2 comments |
headers
Charles Lindsey | 2 Feb 2006 14:06
Picon
Picon

Re: #1047 permitted constructs - a list


In <Lm3RPi8Q$P4DFAUz <at> highwayman.com> Richard Clayton <richard <at> highwayman.com> writes:

>In message <200602011817.k11IHxm21995 <at> panix5.panix.com>, Seth Breidbart
><sethb <at> panix.com> 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.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Charles Lindsey | 2 Feb 2006 15:27
Picon
Picon

Re: POSTED-1 vs. POSTED-2


In <43DFB0D0.58A2 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> 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
(Continue reading)

Permalink | Reply | 3 comments |

Gmane