Subject: Re: How to get NOOP out of pine?

From: [email-masked] (Mail automatically resent by Bigbird)
Date: Wed, 8 Feb 1995 08:37:16 -0800

On Mon, 6 Feb 1995 09:37:00 -0500 (EST), Dan Schlitt wrote:
> The reason that I mentioned Salz at all was that the complaint seemed to
> be one about the interoperation of Pine and INN.  I expect INN to reflect
> his thinking and that of the others who I knew were working on the
> revision of the protocol.

As I said, I think that Salz has the right ideas.  The problem is that I've
seen certain other individuals in the NNTP community challenge him on other
matters (specifically, the role of message headers in news), and what's worse,
by his own admission the NNTP document update effort has stalled.

It's a shame, but given what I've seen, I can understand the burnout.

> I guess that I would come down on the side of using HELP instead of NOOP
> provided using it would not generate unexpected output for the client to
> deal with.  But it is a matter of taste.

The other idea is to use DATE -- a nice sort-of no-op in INN.  Unfortunately,
DATE is also absent from RFC-977.  I'd rather explain to people what the
unrecognized NOOPs do than what the unrecognized DATEs do!  ;-)

> On the matter of the timeout, I just disagree about who is best to judge.
> The server is in the best position to manage the use of its resources.
> one should not undermine that management by non-standard behaviour of the
> client.

It depends upon what you consider the role of timeouts to be.  If you see them
as a safety belt to allow the garbage collection of abandoned collections,
then it is not only reasonable, it is *mandatory*, that the client reassure
the server that it is still there at periodic intervals.

> Perhaps the protocol should allow the negotiation of the timeout
> between client and server (back to the subject of point one).

Perhaps, but technically, timeouts are a violation of the TCP spec!  TCP is
rather emphatic about this.  During a nuclear war, you do not want Clinton's
telnet session to nuker.af.mil to be dropped just because a section of network
in Ohio evaporated and it took a few minutes before another 747 with a cisco
and microwave transceiver could be sent up to replace the lost line.

> In the
> case where the client and server are under the same administrative
> control you should be able to deal with this problem by modifying the
> server.  That ought to be the case at U. of Wn. where your most important
> user base is.

As I said, timeouts have a useful purpose in an LAN configuration with
machines such as PCs and Macs which are not completely careful about notifying
the other end (via TCP reset) when their applications go away (worse, they
tend to use the same port numbers, and get screwed if the connection is still
there at the server).  We're not really worried about keeping our NNTP service
available during nuclear war.  ;-)  But, we want to have abandoned servers
from PC/Mac clients go away fairly aggressively (for reasons outlined above)
without impacting live clients.  This leads us naturally to short timeouts and
keepalive pings.

---

From: [email-masked] (Bob Sloane)
Date: 16 Feb 95 13:21:39 CST

> unrecognized NOOPs do than what the unrecognized DATEs do!  ;-)

How about using STAT with no argument. If you are not in a group, it
will get an error, and if a group is selected, it will return the
status of the current articles, which can't take much time. Either
way, you get a one line response that doen't generate any error
message on the server.
-- 
USmail: Bob Sloane, University of Kansas Computer Center, Lawrence, KS, 66045
E-mail: [email-masked], Phone: (913) 864-0444, FAX: (913) 864-0485