Subject: Re: New USEPRO path-identity text (Hello, Chair?)

From: John Stanley <[email-masked]>
Date: Thu, 4 Aug 2005 17:06:29 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

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

A news server administrator who chooses to do anything against a MUST 
will have to bear the consequences. Just how many patently obvious things 
do you think we need to put in a standard? Why aren't we threatening them 
every time we use MUST? 

Admins who ignore MUSTS are outside the scope of our document. Telling 
them they have to "bear the consequences" is patently silly.

>I find that rather bizarre. What harm arises, or what security hole is
>opened, if the Xref header uses a different identity? 

A fascinating argument. What harm arises if the injecting agent does not 
have an abuse@ address for the FQDN it uses as a path-identity?

>I now have:

>   There are various circumstances when news-server administrators may
>   need to be contacted. To facilitate this, the following email
>   addresses are provided:

Unless you personally are willing to provide those addresses, don't tell 
people that they "are provided". 

>However, I don't think it is wise to describe a "SHOULD" feature as
>"optional". 

You don't have to. RFC2119 already does that.

>>Is it the function of Path to "enable administrators to be contacted", or 
>>is it to simply record the path the article has taken? 

>Both.

Then, of course, the "not-for-mail" that is commonly appended is, what, a
lie? Then, of course, RFC1036, when it says "The "Path" line is not used
for replies, and should not be taken as a mailing address" is what,
telling another lie? And the RFC1036 definition of Path that says "This
line shows the path the message took to reach the current system" and 
nothing at all about it being intended as a contact address is what, yet 
another lie?

>Harald's syntax is not yet definitive. And it did include colons within
><IPv6address>s, so you still need to eschew "dead" and "beef".

As I recall, no, colons were NOT allowed in a path-identity. So no, we do 
not need to "eschew" 'dead' and 'beef'. 

>The minimum we can expect is that is does not bounce (i.e. if you give it
>as RCPT TO: to the proper server, then it will not be (permanently)
>blocked).

Unfortunately, as soon as RBL adds the sending site to it's blacklist, any 
mail server that uses RBL will block it. Unless you want to demand that 
RBL not be allowed for any mail server that handles USENET-related email, 
you can't say much more than "correct syntax", and that's useless.

>If you can suggest any other phrase in place of "working" that conveys
>that sense, without going into long descriptions of SMTP protocol details,
>then please do so.

"Syntactically correct".

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 5 Aug 2005 10:15:22 GMT

>do you think we need to put in a standard? Why aren't we threatening them 

Such an administrator has not actually violated any MUST AFAICS. He has
merely exercised bad judgement.

>You don't have to. RFC2119 already does that.

It has been patiently explained to you many times and by many people that
"SHOULD" does not equate to "optional".

>nothing at all about it being intended as a contact address is what, yet 

And RFC 2142, when it says "if an NNTP server's host name is
DATA.RAMONA.VIX.COM yet it advertises the domain name VIX.COM in its
"Path:" headewrs, then email must be deliverable to both <[email-masked]>
and <[email-masked]>..." is telling another lie :-) .

>you can't say much more than "correct syntax", and that's useless.

If the designated server for the abuse@ address uses that RBL blacklist,
then indeed the administrator has not fulfilled his responsibilities under
whatever MUST/SHOULD/... we write into our draft.

[The latest stupidity that has arisen is those abuse@ addresses whose
virus filters reject emails sent to them containing copies of
virus-containing emails that have emananated from those ISPs.]

>"Syntactically correct". 

<[email-masked]> is syntactically correct, but it is not a "working"
email address. I note that RFC 2142 (as quoted above) uses "deliverable".
Would that be better than "working" or "valid"?

-- 
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: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 05 Aug 2005 10:37:03 -0400

> "SHOULD" does not equate to "optional".

It has been patiently and impatiently explained to you that RFC2119
makes it clear that if you only need a valid reason to disregard a SHOULD.

Standards are all about defining consequences, not creating some
petty heirarchy of who is more compliant and shaming implementors.  No
one who is an editor should need RFC2119 terms explained, or why
"optional" is different than "OPTIONAL."

John is precise enough to write "must" and "optional" when he
means "must" and "optional" and not "MUST" and "OPTIONAL."  You are
an editor, so you MUST follow the convention that John uses.

I asked before, and the Chair ruled.  Can the Chair please use private
email to force Charles to use RFC2119 terms properly?