Re: draft-ietf-usefor-usepro-02

["Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>]

In <Pine.LNX.4.53.0412101042090.14565@xxxxxxxxxxxxxxxx> John Stanley <stanley@xxxxxxxx> writes:


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, given that he keeps
repeating the same complaints ad nauseam, he deliberately
misreads/misunderstands what is said to him (or else he is even stupider
than I thought), and jumbles up unrelated topics so that it is hard to
spot what he is talking about at any given moment.

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


>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>No, it implies no such thing. Agents may or may not be able to detect
>>validity/invalidity of various classes of address, as Seth has pointed
>>out. The "MAY" permits them to make use of such information as they may
>>have available.

>Since they do not have the information that says "your address is invalid" 
>in the general case, there is no use to be made of that "information". 
>Pretending they CAN know this is the problem. 

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",
in which case they MAY choose to reject. 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". So
what?


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

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


>>No, there is nothing else that will nearly always work on Usenet as it
>>presently exists.

>Well, DOH! But that is not an excuse for preventing it from being created.
>There is no reason to demand in the standard that "by email" be the only
>method of sending articles to the moderator. If that is the only current 
>implementation, that's one thing, but to close out any other 
>implementation is just ridiculous.

That is the only implementation currently deployed on Usenet. You
yourself agreed that other arrangements would only be available on Private
networks. A Private network is, by definition, a "cooperating subnet"
which is, by definition, permitted to use additional protocols not defined
by the standard. Such additional protocols may, at some future date,
become defined as extensions to the standard; but for the moment the only
universally accepted way on Usenet to send articles to a moderator is by
email, and no alternative mechanism is on the table; that is therefore
what we are going to standardize.

>I'm sorry, but in another section of the draft you try to "standardize" 
>the "exceptional" cases of reinjection.

That is because there was some small existing usage of reinjection,
because there were good reasons why it should happen in a small number of
situations, and because we discussed it and concluded that the possibility
should be mentioned (because there needed to be some restrictions on
exactly how it was done). None of those preconditions applies in the case
of novel methods of communicating with moderators.


Now we have switched to Injection-Date. ...

>>>>So if the Injection-Date is earlier than the expiry date
>>>>(however computed) that it implements (probably of a per group basis), 
>>>>then it MUST drop it.

>>>I asked once, and I expected an answer. Why is this a MUST? Expiration 
>>>policy is the site's responsibility, not ours. 

>>This is nothing to do with controlling the expiration dates of sites. It
>>is a matter of preventing loops, for which purpose that MUST is essential.

>I see nothing in that statement about "loops", and everything about 
>"expiry date". 

The word "expiry" does not appear in the text under discussion. That text
was an agreed part of the protocol as discussed when we introduced the
Injection-Date header, and before we added that header it was an agreed
part of the protocol applying to the Date header.

Note that the critical date for a site is that of "the earliest articles of
which it normally keeps record", which will usually be earlier than that
of the earliest expired article, since it is usual to keep message-ids in
the history file for a further period even after those articles have been
expired. So if an article arrives with an even earlier Injection-Date than
that, then it MUST be dropped.


Now we are back on ".invalid" again. ...


>>... both Frank and Seth seem to he saying that it is about
>>right as I currently have it. 

>>I agree that the
>>way it is currently worded seems to be pulling two ways at once and will
>>probably need to be changed. But I need guidance as to which direction to
>>change it in.

>Well, that's what I've been giving you. 

And other people have been giving different guidance.


Now we have switched to "take". ...

>>>There is no reason to redefine a standard english word when there is 
>>>already a standard english word that conveys the correct meaning.

>>"Take" is also a standard english word, and conveys the intended meaning
>>in this case. 

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

Take v.t. to lay hold of; to get into one's possession: to seize: to
catch: to capture: to captivate: to receive or come to have willngly or by
an act of one's own; to appropriate: to assume, adopt: to accept: to
receive: to admit: to submerge (scot.): to have normally assigned to one:
to find out, come upon, surprise, detect: to swallow or inhale: to apply
to oneself: to obtain: to engage, secure: to seek and receive: to have
recourse to: to attend a course in: to visit: to call for, necessitate,
use up: to remove: to cause to go: to subtract: to convey: to escort: to
detract: to derive: to understand: to apprehend: to assume, suppose: to
mistake: to conceive: to accept as true: to tolerate: to ascertain: to
observe or measure: to ascertain something from: to execute, perform: to
set down: to portray: to photograph: to charge oneself with: to
asseverate: to strike: to come upon and affect: to bewitch: to blight: to
deliver, give (obs.): to betake - and then there are the intransitive
forms ...

A very versatile word, as you can see. To determine its meaning in any
given case, you have to examine its context. Fortunately, in this case,
the context is clear, because I have given an explicit definition of the
term.  I think, of the bunch listed above, "to ascertain something from"
fits my defined meaning best.

Switching now to followup agents. ...

>>>Nonsense. We tell it what it must use. We do NOT tell the user what he 
>>>uses. Since there is only ONE thing that the followup agent is allowed to 
>>>do ("copy the content") that is the default. There is no other default.

>>There are TWO things the followup agent can do. One is to accept (without
>>demur) what the user types in. 

>The user has typed NOTHING in at the point in question. We are telling it 
>what it must do when it prepares the article for user action. There is 
>only ONE THING that it does -- and that means that ONE action is the 
>default. Saying that it must, by default, do the only thing we tell it it 
>can do is just silly. 

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. Therefore, its duties include accepting text from the
user and using it in place of whatever default it might otherwise have
used. Our draft carefully defines the allowed defaults and, in the
circumstances "default" is a perfectly proper word to use.

And now References. ...

>>>You want to trim the one in the followup. "If the resulting 
>>>References-header is excessively long, it may be trimmed by removing 
>>>message identifiers other than the first and the last."

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

The original wording allowed the trimming of <B>, but not of <A> or <C>.
The new wording allows precisely the same. You asked me for a change of
wording, not for a change of meaning, so that is what I did.

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. Consider the case where <C> and <E> are
available, bur <D> is missing, for example.

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


Now we are at Duties of a Reading Agent. ...

>>The only limitations are those imposed by the lack of appropriate
>>facilities in the reading agent. The whole point of the wording is to
>>indicate that the poster cannot assume that every reading agent will be
>>able to make sense of everything, however bizarre, that he might choose to
>>put in the article.

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

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.


Now you have suddenly switched to gateways. ...

>>>We already cover the possibility of loops, so there is no need for this 
>>>paragraph at all.

>>There are various ways in which loops can arise. It is necessary to draw
>>attention to them.

>We already draw attention to them, in the previous section where it is 
>stated as "the primary dictat": Above all, prevent loops.

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

> But it 
>is wrong in that it says that the limits are due to the PRESENCE of 
>another incoming gateway, and that is not true. The operation MUST 
>consider the POSSIBILITY of an incoming gateway, not just the PRESENCE of 
>one.

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

7.9.1.  Duties of an Outgoing Gateway

   From the perspective of Netnews, an outgoing gateway is just a
   special type of reading agent. The exact nature of what the outgoing
   gateway will need to do to articles depends on the medium to which
   the articles are being gated. The operation of the outgoing gateway
   is subject to additional constraints due to the possibility of one or
   more corresponding incoming gateways back from that medium to
   Netnews, since this opens the possibility of loops.

>So, to solve the problem, and make things shorter (something you like to 
>do), remove it. One paragraph shorter.

>>>It is unlikely that an outgoing gateway is going to see an incoming 
>>>message.

>>On the contrary, that is just the kind of loop we are trying to catch.

>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. Normally,
these will be messages that have arrived via other relaying agents in the
normal manner (and that includes the ones which might turn out to be parts
of loops).

> Problem solved. In fact, I doubt 
>there are many outgoing gateways that do accept incoming messages. I know 
>the ones I have written do not. There is, in fact, no way to SEND an 
>incoming message to my outgoing gateway. 

So your outgoing gateway never has any messages to process at all then?
Why did you go to all that trouble to write it?

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

NO! Incoming messages don't just come from incoming gateways. They arrive
by the usual Usenet relaying mechanisms. Consider the following setup:

In Usenet:

    Site A ---> Site B ---> Site C ---> Site D --->
                  ^                       |
                  |                       |
                  | inGate                | outGate
In the other      |                       |
medium:           |                       |
                  |                       |
    Site E <--- Site F <--- Site G <--- Site H <---


>>>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. Maybe even no
message-id concept at all.

>An outgoing gateway takes NEWS 
>articles and sends them to the other medium. If you think an outgoing 
>gateway author is going to throw the message id away prior to checking for 
>dupes just because the "other medium" doesn't understand message ids, then 
>you are being foolish.

Then what do YOU want outGate to do with the News message-id? 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? You have to
allow for the possibility that the 2nd time outGate sees the message it
will have a different message-id.

>>> A comment in the body 
>>>of a messsage is not likely to prevent loops. Saying it does is silly.

>>No. If the gateway to the "other medium" (which presumably understands the
>>rules for contructing messages in the other medium) can manage to insert
>>some distinct identifier into whatever passes for a body in the other
>>medium, then it is quite capable (and indeed it is the only agent in the
>>whole world with that capability) of recognizing the identifier that it
>>itself placed there, should it ever come back again. 

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

> Well 
>now, that's a serious requirement. But since the content of the body is 
>UNSTRUCTURED, you've got a long row to hoe defining structure of headers 
>in the body. But before you can claim that a comment in the body of a 
>message (in some other medium than news, to boot) is likely to prevent 
>loops, you need that structure.

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

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

>>If there is, then it can be relied on to do the checks.

>Not when we tell the gateway author that the gateway author that the 
>articles the gateway forms must follow all the standards.

Why ever not? It has the responsibility of causing the necessary checks to
be done. It has a choice. Either it does them itself, or it ensures that
the injecting agent it hands off to will do it. What is so wrong with
that? It is not our job to tell implementors how to do it - just to tell
them that it must be done somehow.

>>>It takes a bit of thought there to realize that a duplicated message id is 
>>>an illegal content for the message id header. And most injecting agents 
>>>do, indeed, reject duplicates.

>>How?

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

Injecting agents don't keep histories. With a bit of luck their friendly
neighbourhopod serving agent will keep one and silently reject it.

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


>>>>I would suggest checking for and noting the presence of the cancel message
>>>>_before_ removing it.

>>>There is no cancel message before removing it. I am told I must remove it 
>>>before I can inject it.

>>Eh?

>I have an incoming gateway for group X. User Y sends a message to the 
>gateway containing the header "Control: cancel <foo123@xxxxxxx>". My 
>gateway is told I MUST NOT pass that message without removing or renaming 
>that header. On the other hand, since I can determine that this is a valid
>cancel message, I can create a cancel message of my own. How? By passing
>the message WITH the control header. 

You are postulating another medium whose cancel messages are in the same
format as Netnews cancel messages. I agree that a typical mail2news
gateway has this property.

Yes, if you follow the draft, you notice two things:

1. The incoming message is a cancel message, so you generate an equivalent
(brand new) News cancel message.

2. The incoming message contains a Control-header, so you remove it before
you pass it on (so you have now inserted two messages into the News
system). OTOH, in the case of a pure cancel message there is little point
in passing on the emasculated message (which is why I used a message with
a Supersedes header in my example) so maybe you just drop it.

And yes, in this very particular case of a mail2news gateway there is an
obvious optimization just to let it through. But strictly speaking that is
wrong. When Russ wrote this, he concluded that letting Control messages
through as received was a Bad Thing. If you disagree with him, then please
try to persuade him otherwise. Otherwise, I will not change it.


>Now, YOU told me that I was supposed to look for a cancel message before I
>remove the header. I ask my server for that message and, not surprisingly,
>since I have not yet posted one, it does not yet exist. So how does this 
>help the problem? If the cancel message already existed, yes, I'm out of 
>the woods, I don't have to process the incoming message. But since it does 
>not, and I MUST NOT/SHOULD process it, I'm stuck.

You are in fact hoist with your own petard. Nobody required you to
implement your gateway in such a stupid way.

>>If an article with a Supersedes header arrives at an outgoing gateway,

>So what? We're talking about duties of an INCOMING gateway here.

The draft has discouraging things to say about control messages for BOTH
kinds of gateway.

-- 
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: chl@xxxxxxxxxxxxxxxx      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