Ad hominem

[John Stanley <stanley@xxxxxxxx>]

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Will the rest of the Working Group please tell me whether it wants me to
>continue to reply in detail to John's long rants,

They are "rants" when you do not agree. They are "responses" when you make 
them. 

>he deliberately
>misreads/misunderstands what is said to him (or else he is even stupider
>than I thought),

Thanks for making your position on this discussion clear, Charles.

>I have replied fully to this one, but I see little point in continuing to
>do so in the future.

I see little point in you doing so. You either change the text so it says
the same wrong thing when I say something is wrong, or refuse to change
anything when I point out that it is unclear. Or abdicate responsibility.

>As usual, you fail to distinguish between what some particular agents are
>able to do, and what agents in general are able to do. SOME agents may be
>able to determine (or think they are able) that an address is "invalid",

Of course some might be able to actually do that for some addresses, and
we both know I've not said otherwise. Those agents are not the issue. The
issue is the agent you mention next -- those that THINK they are able to.
Telling them they SHOULD do something based on information they do not
have is wrong. It makes them think they can do something they cannot.
There is not an agent in the world that could determine anything about the 
validity of an address I use from one of the domains I own, so the ONLY
correct behaviour on their part is the MAY behaviour. MAY do the right 
thing, instead of MUST or SHOULD?

>It nowhere says that ALL agents
>are able to make that determination, which inevitably means that there
>will exist SOME agents that are unable to take advantage of that "MAY".

Where do you see in the draft anything about any limitation on what agents 
can make use of the "MAY" clause in that paragraph? What draft are you 
reading? 

>>Consequently, people who use perfectly valid addresses may well find their
>>articles rejected, because we've told server admins they can pretend to
>>know if they are valid or not.

>We have told server admins no such thing.

That's what that paragraph tells them. Maybe it isn't what you intend it 
to tell them, but it certainly does. When you say that something SHOULD be 
done with certain information, you imply that the information is 
available. When it is not, they ought not be doing anything different.

>For those who are confused by John's snipping, the discussion has suddenly
>moved on to communication with moderators. ...

In USENET, it's called "editing", and it is the normal thing to do. If you 
want the full context, read the original.

>That is the only implementation currently deployed on Usenet. You
>yourself agreed that other arrangements would only be available on Private
>networks. 

The fact that it is the only CURRENT implementation does not mean it must 
be the ONLY implementation ever. And no, I did not "agree" to anything of 
the sort. I gave one example that disproved the requirement for "by email" 
which involved what you call a "private network", but wasn't specified by
me as such.

It is possible that tomorrow a moderation system could be written to use 
anonymous ftp to accept articles. New and updated injecting agents could 
be written to do that directly; meanwhile, isc.org implements a mail->ftp
gateway to forward the email it gets to the ftp system.

>but for the moment the only
>universally accepted way on Usenet to send articles to a moderator is by
>email, 

Do you really think that removing the "by email" limitation in the
standard will cause things to break overnight? Will software suddenly
start, I don't know, printing messages on the line printer just hoping
they make it to the moderator? I don't think so.

But will a "MUST do X" in the standard allow people to think about better 
ways of doing things? Why would they? They MUST do it this way, why waste 
time thinking of ways to improve it?

So, nothing breaks if you take out "by email" and innovation would be 
allowed. Seems like a no-brainer.

>>No, it does not. "Take" means that something is removed from one place and
>>moved to another.

>Take v.t. to lay hold of; ...
>A very versatile word, as you can see.

And you dare accuse ME of "long rants". 

Walk up to any person on the street. Hold out a dollar bill and say 
"please take this dollar bill". Report back if ANY of them ask you to go 
into the nearby Kinko's so they can copy the dollar, instead of simply 
taking it out of your hand like you told them to.

"Copy" has no such connotation, and "copy" is what you are doing. Say 
"copy". After all, nobody asked you to make the change in the first place.

>I think, of the bunch listed above, "to ascertain something from"
>fits my defined meaning best.

And "copy" fits it better. You aren't "ascertaining" anything, you are 
copying it.

>A followup agent is, by definition, a special case of a posting agent, so
>its duties are not complete until it has handed over the final text to an
>injecting agent.
 
It does not, however, have any duties CHANGING the subject, newsgroups,
or other headers after it has presented the article to the user. Thus,
its duties in that regard are solely to copy the various contents of the 
precursor and then let the user fiddle with them. It does nothing with 
them other than pass them to the injecting agent after that. 

Thus, the ONLY action specified for the followup agent when preparing the 
headers is the DEFAULT action BY DEFAULT, and repeating this "by default"
is meaningless. 

>>>But OK, I will buy that, except that it has to be the "last two" (i.e. you
>>>MUST keep the last one from the precursor).

>>Why? What breaks if the parent of the precursor is no longer threaded? 
>>Justify the MUST.

>The original text said "... but the first and last message identifiers
>from the precursor MUST NOT be removed". So if the precursor had:

>References: <A> <B> <C>
>Message-ID: <D>

>then the followup article will have

>References: <A> <B> <C> <D>
>Message-ID: <E>

Yes, that's right. So why must <C> be kept? What breaks? 

>The original wording allowed the trimming of <B>, but not of <A> or <C>.

Yes, the original wording was wrong and I thought we were changing it. 

>The new wording allows precisely the same. 

So I'll ask again. What breaks if <C> is removed? I understand that <D> 
MUST be kept (to keep the thread). <A> to link everything to the parent.
But WHY is there a MUST for keeping <C>?

>You asked me for a change of
>wording, not for a change of meaning, so that is what I did.

What kind of game are you playing? I pointed out that the text was WRONG.
That's not asking you for the same WRONG text written a different way.
Anyone with a brain would know that means CHANGE THE MEANING.

>If somebody wants a change of meaning, then that is a separate issue, to
>be discussed. However, allowing both <B> and <C> to be trimmed away might
>well cause threading with the earlier articles to fail if the precursor
>had failed to be delivered. 

Wrong. That's why <A> is kept. If nether B nor C have arrived, they cannot
be threaded against anyway. And you can extend your same wrong argument
back three, five, or even eightythree levels. That's not an excuse for a
MUST.

>There was a time when our draft suggested keeping at least 20, plus the
>first one (and USEAGE still says that, although some recent experiences
>with excessively long References breaching the 998 limit makes me think 20
>is too large). So I could easily be persuaded that keep "last two" should
>actually be increased to, maybe, "last three".

So I could easily be persuaded to keep asking WHAT BREAKS? What breaks?

>>Then say that. But that's so obvious that I don't think it needs to be 
>>said. That whole section about "reading agent" is a definition seeking a 
>>purpose.

>Maybe so, but that is a separate issue for separate discussion (there
>exist some people wanting to keep the whole section and some to remove
>it).

No, that is an issue for the current discussion, since it deals with the 
paragraph being discussed. What function does the current paragraph serve?
It make general statements about something we actually have no control 
over. Why bother? Define "reading agent" if you have to and leave it at 
that.

>But what you asked me to do, and which I did do, was to weaken the
>over-strong wording thjat was originally present. You said nothing then
>about removing the whole section.

You said nothing ten years ago about making any changes to the draft. Yes, 
seeing the wording made it clear that the section was irrelevant and ought 
to be removed completely.

>Now you have suddenly switched to gateways. ...

I didn't "suddenly" do anything, Charles. I got to the point in the 
discussion where we were talking about gateways.

>>The only content to the entire first paragraph of that section is to say:
>>loops are possible, please prevent them. We've already said that. There is 
>>no need for the entire paragraph. It adds no meaning to the draft, so 
>>while it may be completely true, it is also completely meaningless.

>That text was originally written by Russ. You have to persuade him if you
>want it taken out.

No, I don't. Are YOU the editor or are you NOT? You will gladly change his
text when you feel like it; when you don't, you create fictional
requirements for outside approval.

>You have already said that, and I have already changed it at your request.
>Why are you still complaining? It now says (as I have posted previously):

It is still irrelevant to the section of the document it is in (Duties), 
since it lists no duties! It was covered by an earlier section, so it is 
redundant. Changing it so it is still redundant does not solve the base 
problem.

>>That kind of loop is easy to catch: simply do not allow an outgoing 
>>gateway to accept incoming messages.

>Since the whole purpose of the outgoing gateway (which is presumably
>attached to some serving agent) is normally to gateway the whole of some
>newsgroup to the "other medium", then if it (or rather its serving agent)
>never receives any messages it will never gateway anything.

Are you that stupid, or are you being deliberately dense? I said "incoming
messages". The word "incoming" has a meaning, and it is important, just 
like it is important when talking about "incoming gateways". For a 
news gateway, an INCOMING message would be one that comes from the 
other medium. You know, something that an INCOMING gateway would process.

The simple way to prevent loops from INCOMING messages in an outgoing 
gateway is to simply not allow them. No comments in the body of the 
outgoing message are necessary.

The outgoing gateway has the message id of the news message, so it 
does not need to scan the body of the messages hoping for structure, it 
just looks at the MANDATORY message id.

>>In fact, if a gateway accepts INCOMING messages, then it is an INCOMING 
>>gateway, and is dealt with elsewhere.

>NO! 

What, it is NOT dealt with elsewhere? Or an incoming gateway doesn't deal 
with incoming messages?

>Incoming messages don't just come from incoming gateways.

I didn't say they did. Incoming messages are dealt with by incoming 
gateways BY DEFINITION. They don't come from incoming gateways, they are 
processed by them. Incoming messages come FROM the other medium. They are 
coming IN to news. 

>They arrive by the usual Usenet relaying mechanisms.

An incoming message to news that arrives via the usual USENET relaying 
mechanisms is not going through a gateway. 

>>>>However, if you meant that the same outgoing gateway is going to 
>>>>see the same message outgoing more than once, then it already has the 
>>>>mandatory message id (not in the body) to work with.

>>>There might not be such a thing as a message id in the other medium. 

>>There is a MANDATORY message id in news.

>There is no MANDATORY message id in the other medium.

The outgoing gateway is processing NEWS articles and sending them out. In 
NEWS, there is a MANDATORY message id. If you are concerned that the 
outgoing gateway is going to see the same NEWS message more than once and 
send it out again, then the gateway solves THIS problem by keeping track 
of the message id OF THE NEWS ARTICLE. It's pretty simple. About three 
lines of perl code and the problem is solved. It doesn't matter if the 
"other medium" has no concept of message id, news does, and it is 
MANDATORY. If the outgoing gateway doesn't find a message id in the 
headers of the news message it is gating, then it drops it. It isn't a 
news message.

>Then what do YOU want outGate to do with the News message-id? 

I don't care what it does with the news message id. And that is not the 
issue that started this discussion. You claimed that putting the message 
id as a comment in the body of the outgoing message prevented loops. It 
does nothing of the sort. 

>And how can
>you be sure that, wherever you hide it, inGate will subsequently put it
>back in the News message-id before handing it over to Site B?

Who said anyone could be sure? And how can YOU be sure that by hiding it 
in the body of the message that inGate will do anything with it? You must 
be sure if you are so sure that putting it there will prevent loops.

>You have to
>allow for the possibility that the 2nd time outGate sees the message it
>will have a different message-id.

If it has a different message id, by definition, it is a different 
message. That's what news says. You cannot otherwise determine the 
difference between an article posted twice and the same message arriving 
twice.

If you want anything else, then you've just put a requirement on the 
structure of the body of the "other medium" in a draft that covers news. 
Will the FIDO or whoever else is involved groups appreciate you doing 
this, and would it be binding on them anyway?

>>So you expect outgoing gateways to parse the BODIES of the messages it 
>>converts looking for things that look like something it understands?

>Yes, if it can't find a better way to do it (which hopefully it can).

An undefined structure in an unstructured message element is not a very 
good way of defining something. 

>But fortunately inGate is in a position to invent the little bit of
>structure that it needs.

inGate can invent whatever structure it wants, but if the other medium 
also believes that the body is unstructured, it is violating their 
standards. And even when it invents this structure, who is to say that it 
is the same structure that outGate imposes? outGate can put all the 
comments in the body that it wants, if nobody knows how to decipher them, 
or deciphers them differently, nothing is gained. 

>>>It is nowhere stated that a separate injecting agent is involved in an
>>>incoming gateway. 

>>Nowhere is it stated that it is not.

>True. So what?

So by making the gateway responsible for ALL compliance you've ruled it
out implicitely. We apparently did not want to rule it out, so the 
statement about it being responsible must be incorrect.

>>By trying to inject it and getting a rejection, because the duplicate ID 
>>is already in the history. 

>Injecting agents don't keep histories.

The agents that they inject to DO, and just what did you think was meant
by "by trying to inject it" if it wasn't that it tried to inject it?

>With a bit of luck their friendly
>neighbourhopod serving agent will keep one and silently reject it.

A bit of luck? By the way, how can the injecting agent know that an 
article has already been injected unless it has a history available to it?
You say it MUST NOT forward such an article to a moderator, and it cannot 
know how to obey that MUST NOT without a local history (or one always 
available to it). It could, I suppose, be a history of just articles 
appearing in moderated groups, but that would be more difficult to 
maintain than a full history.

>But that is no use if the message-id got changed to a different message-id
>within the other medium.

Yes, we cannot prevent problems in other media. We know this.