From: John Stanley (stanley@peak.org)
Date: Mon Jun 10 2002 - 14:10:50 CDT
Erland Sommarskog (sommar@algonet.se):
> All this reasoning is based on the assumption that "entity" and "person"
> are complete synonyms.
No. They do not need to be "complete" synonyms, just able to mean the same
thing. While there is a potential argument that you posting as
postmaster@somewhere.example and you posting as joe.user@somewhere.example
are two different entities (because one is a position of authority at the
site and one is not apparently so), the fact remains that stanley@peak.org
and stanley@skyking.oce.orst.edu are the same entity. And even when you
post as joe.user, you may be the same entity as postmaster -- I've seen
too many times that the "postmaster" entity speaks using his
non-postmaster address.
So, the injector has to guess when the "entities" aren't the same, which
is should not be doing, and when it guesses wrong it is violating this
standard by changing the meaning of the Sender header.
> It is well-known from previous discussions that
> you have this idea about the English language.
Yes, that "entity" and "person" can mean the same thing. Quirky language,
isn't it?
> It should also be well-
> known to you from those discussion that no one else, neither foreign
> nor native speakers of English, agree with you on that point.
Speaking for eveyrone in the world now, are you? Also wrong.
Charles Lindsey (chl@clw.cs.man.ac.uk):
> Because we are a Working Group that is supposed to achieve a Rough
> Consensus.
A rough consensus that is demonstrably contradictory is silly and needs to
be fixed. Digging your heels in because you don't like getting caught
doesn't help. Making other changes to the proposed draft after an alleged
hard-deadline but saying that this cannot be fixed because of that
deadline is hypocritical.
>And that MUST NOT did not "slip in". It is there for a purpose, and that
>purpose is quite consistent with what the draft has to say about From,
>Sender and .invalid, as Henry has been patiently explaining to you.
If a MUST NOT in one part of the proposed standard contradicts a "may" in
another part, which part is the implementor supposed to obey? He may
decide that a non-provable address must have a Sender header, which is his
right under site-policy, but then to add that header when 8.2.2 says that
he MUST NOT process an article that is not acceptable due to site policy
is a violation of this standard. The latter is NOT an option under site
policy, it is an explict MUST NOT. The only option is to REJECT the
article and let the poster fix it, since ONLY the poster knows the right
thing to put in the Sender header. That is not just my opinion, it is
stated rather explicitely in 8.2.2.
So, you'll apparently directly reference a section of the standard that
says what has just been permitted isn't really permitted, but you'll not
remove the permission. Why is that?
>>1. I see nothing in 5.2 that mentions 8.2.2.
>That is because you were so full of the exuberant turgidity of your
>ranting that you neglected to read my reply (in this same thread) in which
>I stated that I had added such a mention. For your especial benefit.
No, that is because I got a copy of the draft from the draft repository
and read it, and saw nothing in that draft that mentions 5.2. And then,
AFTER I said that I saw nothing in 5.2, I saw a comment that you had
changed the draft (but apparently not the copy that is publicly
available.) Once again, you are working from your own personal copy of the
draft, changing it as you see fit, and then using insult to attack those
to whom you've not provided a current copy. That's your typical style, so
I've learned to expect it. I would have thought the last time we had the
discussion about you making changes without updating the public copy you
would have remembered to keep the public copy up to date, but no, you are
particularly slow at these things it seems. There, now I've insulted you,
can we get back to the issue?