Re: New USEPRO path-identity text

[John Stanley <stanley@xxxxxxxx>]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Moreover it is up to that organization to designate its preferred "abuse@"
>domain, rather that have it tied to some mythical "top level" 

Not according to RFC2142, which we are not free to change and is not the 
subject of our working group. 

And your inability to understand the simple concept "top level domain" 
does not make the top level domain any more mythical than your inability 
to understand electronics would make electrons mythical.

>Right, so the algorithm I am trying to establish for finding that person
>is:

Your "algorithm" creates new RFC2119 mandates and contradicts existing 
standards in areas that are outside the scope of the USEFOR working group.
Any acceptable algorithm must live within the constraints of the problem.

>Question: Clearly injecting agents have to arrange that a working abuse
>address can be found from the above algorithm.

Not clearly at all. You can fabricate a thousand different algorithms and 
the injecting agent admins (not "injecting agents", since injecting agents 
are pieces of software that cannot arrange anything on their own) are not 
bound by any of it, unless you can justify the mandates so that your 
algorithm can be considered and validly entered into a standards document.
Finding text in a standard just because the editor wanted to put it there 
and the chair didn't act to prevent it" is a silly way to write standards.

>But I would like us to agree on what the complaints procedure is to be, 

It is not our job to define what the "complaints procedure" is, certainly 
not using interoperability-level mandates. It is our job to define how the 
news system works. If "abuse reports" are part of the "news system", then 
they fall under "usenet/news" addressing and the problem is moot. 
Otherwise, not our problem. It's a problem already solved by an existing 
RFC.

>Sure. I was merely pointing out that RFC 2821 used the dreaded "MUST" word
>in much the same context as I was trying to use it,

And it has been pointed out to you that you are patently wrong when you
make that claim. "abuse" has nothing to do with administration and
configuration of a protocol; "postmaster" does. The context is different.  
But the context is the same for "postmaster" and "usenet/news", and that
is one reason that I do not find any issue in repeating a mandate for
those addresses.

>      ELSE
>         use "abuse@<path-identity>"

People can "use" whatever they want when they send abuse reports, and they 
sometimes do. Telling them to use an address that you know is OPTIONAL is 
hardly productive. Perhaps you should rewrite your "algorithm" in light of 
the existing standards, which would be:

	ELSE
		use "abuse @ top-level-domain-of-path-identity"

That is what RFC2142 tells you, that is certainly good enough for us, 
unless you have some NEW stab at interoperability problems that justifies 
an RFC2119 mandate?

>   ELSE
>      Locate the <path-identity> of the injecting agent in the Path
>      header (it should be followed by "POSTED");
>      use "abuse@<path-identity>"

Ditto this clause. 

>The MUST relates to providing enough information for my algorithm above to
>work.

RFC2119 does not list "making sure that Charles's pet algorithms work" as
a justification for MUST language. There is no interoperability issue.

>The
>question at issue was whether the "MUST" word could be used at all in the
>context of ensuring that a clear route to an abuse address exists.

And has been pointed out to you numerous times, the MUST word is already 
being used in the context of ensuring that a route to an abuse address 
exists -- in RFC2142. And RFC2142 is just as explicit in saying that that 
address is NOT required for anything but a top level domain. Yes, I know, 
you can't figure out what a "top level domain" is, but I assure you, lots 
of people dumber than you are can and do figure it out every day.

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

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

I went through each part of the remainder of your sentence and showed that
your proposal was either more onerous or made no difference. You cannot be
"less onerous" if the main thrust of your argument is more onerous and the
rest is the same. Less has a meaning;  please look it up if you don't
understand it. In fact, since your requirements are "greater than or equal 
to", your use of "less" is particularly insulting.

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

Each part was dealt with at length.

If you refuse to justify the mandates you want for a section of the new
standard, then I see little point in continuing this exchange.  
Unfortunately, because you are the editor of this new standard, you are
able to put whatever you want into the text and it appears that nobody is
going to fix this problem. Our chairs are ignoring it. Thanks for nothing.

Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>:

>Okay, now I think I see the problem:  What you want is in fact
>no "MUST abuse@<p-id>", 

What he wants is, I assume, what he has written and what he so fervently 
refuses to discuss on a reasonable level: a MUST that contradicts RFC2142 
without RFC2119 or any other reasonable justification.

>In other words, if abuse@<p-id> exists,
>a mail-complaints-to might be omitted, although that's not a
>good idea.  Is that so far correct ?

RFC2142 tells that that abuse@ is OPTIONAL (NOT required AT ALL) for 
anything but the top level domain. One cannot make it "mandatory unless 
other conditions are met" without contradicting RFC2142 which has NO 
conditions on the optional status of that address. 

And considering that abuse@ the top level domain is already mandatory, as 
well as usenet and news at the specific host, there is no justification 
for requiring it to be anything more than completely optional for the 
specific injecting agent. "Completely optional" is not "MUST/unless", it 
is "MAY" or even perhaps "SHOULD", but certainly not "MUST".

Richard Clayton <richard@xxxxxxxxxxxxxx>:

>yes, but there should be a simple default if they do not so designate

If a domain owner has not designated the "default" recipient of mail sent 
to the mandatory abuse address for his domain, he is already violating 
RFC2142, and we have no reason to expect him to be any more fastidious in 
his adherance to USEPRO or USEFOR or USAGE. Yes, there are people who 
explicitely ignore RFC2142, and who continue to ignore it after being 
eductated as to its existance. They are not our problem, nor are they 
within the scope of our working group.

>So now you only need to say that if people
>choose to have an Injection-Info header field they should ensure that
>following this algorithm will result in a suitable address for reporting
>problems with the article.

Why do I predict that if Charles follows this suggestion and writes new 
text to put into USEPRO, he will have converted the "should ensure" into 
some RFC2119 mandate?

>2142 was merely recording what "everyone knew" at the time. Times change
>(and so such specialist addresses fall out of use because of the need
>for spam filtering and the rise of the specialist abuse team). Hence I
>don't a huge value in repeating any of what is in 2142 if it's not an
>actual requirement to make the system work.

Excuse me, could you say that a little bit louder? Our draft editor isn't 
noticing the number of people who say "remove the mandate".