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

From: John Stanley <[email-masked]>
Date: Wed, 27 Jul 2005 19:50:32 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>My proposed requirements for "news" and "usenet" are less onerous than for
>2142. Do you have a problem with that?

My fault. I added a parenthetical comment in my description of a problem 
which allowed you to latch on to something that isn't an issue and pretend 
that you're discussing the real problem. Knock it off, Charles.

>My proposal regarding "abuse" is less onerous than for 2142

That is a patently false, and you know better, because it has been
explained to you multiple times now.

Mandating an "abuse@" address for an FQDN is EXPLICITELY NOT required by 
RFC2142. RFC2142 says EXPLICITELY that an "abuse@" address is required 
ONLY for the top level domain.

You are requiring an "abuse@" address for the FQDN of an injecting agent.
That is NOT less onerous than RFC2142, it is a direct contradiction of 
RFC2142 and is MUCH STRONGER than the language in RFC2142. 

> ... insofar as it is not required for relaying agents 

RFC2142 does not require it for relaying agents, so you are not less 
onerous w.r.t. relaying agents, at best you are the same. 

> ... and it is not required if there is a suitable parameter in 
> Injection-Info,

Again, RFC2142 says nothing about "injection info", so your text is not 
"less onerous" since it changes NOTHING if the agent inserts a top level 
domain. If the injecting agent inserts a top level domain name as its 
path-identity, it is still required to have a valid abuse@ address for 
that path-identity. Your text is irrelevant, and thus is nether less nor 
more onerous.

> Do you have a problem with that?

With the patent falsehood that your mandate is less onerous than the
explicit statement that the address is optional for anything but a top
level domain? Yes, I have a serious problem with that. Please stop doing 
it.

>My use of RFC 2119 language is consistent with its use to describe the
>"postmaster" address in RFC 2821 ...

No, it is not. "Abuse@" is not a news-specific management or configuration 
address like "postmaster@" is for email. The same kind of mandate that 
says "you must have an address at which management and configuration 
issues for your protocol can be addressed" does NOT apply to "abuse@" a 
news site. It DOES apply to "usenet" and "news", which is why I've already 
told you that those addresses are not the issue and that mandates for 
those are consistent with other standards.

>Do you have a problem with RFC 2821?

Knock it off, Charles. We are not discussing RFC2821 here, this is USEFOR 
and we are discussing USEPRO and USEFOR and USAGE and whatever other NEWS 
standards are being written. 

>My proposal regarding "abuse" is more onerous that for 2142 insofar as it
>requires you either to provide an MX record for the <path-identity> used
>for injection or else to choose a <path-identity> which is already your
>"top level domain". 

That is incomplete and thus deliberately misleading.  The issue has
nothing to do with "provid[ing] an MX record", and your proposal says more
than that. It says that the address "abuse@" the FQDN MUST be mailable.  
The latter is not synonymous with the former. Please read your own text
and come back here when you've figured out what you actually wrote.

>And it does so with "MUST" wording. Evidently you do
>have a problem with that.

Gosh, do you think he finally understands what the problem is, after being 
told a dozen times or more?

>The reason it is so proposed is that it provides a clear and unambiguous
>route to find a working "abuse" address starting from information
>contained in the article's header fields.

A. That is not an interoperability issue supporting the use of RFC2119 
mandate language. I've already told you this, so please stop pretending it 
is.

B. There is no guarantee that the address is "working", only that it be 
"available". It may be routed to /dev/null on the recipient's end, for all 
we know, or for all the sender knows. 

C. It isn't that hard to determine a valid abuse address from the 
information in the headers of a news message, despite your trouble 
identifying what a "top level domain" is. It just doesn't merit any 
additional burden. 

D. We ALREADY mandate "usenet" AND "news", and email regarding abuse can
easily be sent to those addresses. It would be a rare site indeed where
the "usenet" mailbox owner doesn't know (or isn't himself) the person who
deals with abuse issues. If the "usenet@" address goes to someone who 
is abusing the system, the "abuse@" address probably does, too. 

We've been here before, Charles, and covered all of these "reasons". They 
do not read RFC2119 level, nor do they merit any mandate for any 
additional addresses. This is especially true in light of the language of 
RFC2142 which EXPLICITELY says that it is NOT a requirement for anything 
but the top level domain.

You have not even begun to present a sufficient justification for RFC2119 
language or for contradicting an existing standard that is intended to 
deal with address requirements for internet sites. 

The comments of every person I've seen comment on this (other than you) is
that the requirement is not needed and should be removed. That's a 
consensus in my book. If I have to live with results of "consensus" I do 
not like, then YOU ought to live with them too, and not abuse your 
position as editor to keep text in a draft that consensus says remove.

>RFC 2142 fails to provide such a route,

That is patently and deliberately false. "abuse@" the top level domain is
a REQUIREMENT.  That is "providing such a route". We've gone through this 
before, please stop tossing up this old chestnut.

>as evidenced by the fact that when I gave a concrete example that could be
>derived from the article's header fields, different members of this WG
>arrived at different conclusions as to what the correct "abuse" address
>should be.

Poppycock. Three people played your game, as I recall, and all three came 
up with working abuse reporting addresses. That's not proof that such an 
address cannot be found, it is proof that there are often several such 
addresses available, even without your specious mandate for more.

Here we are again: either justify the mandate (in any version or flavor)  
or remove it. You have not done so yet, and I get no impression that you
are capable of doing so. All you do is repeat the same old non-starters.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 28 Jul 2005 15:40:44 GMT

>explained to you multiple times now.

You have made assertions based on reading the first 8 words of the
sentence which are quite nonsensical in the context established by the

>> ... insofar as it is not required for relaying agents 

If you intend to deliberately ignore the structure of what is written, and
to pick out arbitrary sequences in the middle of a sentence for criticism,
then I see little point in continuing this exchange.

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