Subject: NOOP command - your feedback needed

From: [email-masked] (Steve Mansour)
Date: Sun, 23 Jan 2000 13:53:18 -0800

Folks,

Doug and I had a quick talk about the NOOP command. Since CAP currently
states that an idle CAP connection can be dropped by the server, people
wanted a NOOP command as a way to keep a connection to the server
active.

We've seen a problem in the way the NOOP command is used (or misused) in
IMAP. Clients issue NOOP commands to keep the connection to the server
alive. This can cause a situation where lots of clients log in to a
server, hold their connections open for hours during which they sit idle
(except for issuing the NOOP commands). Others trying to access the
server during this time will receive connection refusals or "server too
busy" errors.

It is also used as a way to get the IMAP server to spew back pending
data. That is, the NOOP command is being used in a way it probably
wasn't intended to be.

So, the questions are:

   * Do we really want a NOOP command in CAP?
   * If so, it seems like we might want to allow the server to drop the
     connection anyway to avoid idle connections building up.  So, the
     server should probably be able to drop a connection at its
     discretion.  Do we _really_ want a NOOP command?

We could be overlooking something. We need your feedback.

-Steve

---

From: David Madeo <[email-masked]>
Date: Sun, 23 Jan 2000 17:52:32 -0500

Steve Mansour wrote:

> We've seen a problem in the way the NOOP command is used (or misused)
> in IMAP. Clients issue NOOP commands to keep the connection to the
> server alive. This can cause a situation where lots of clients log in
> to a server, hold their connections open for hours during which they
> sit idle (except for issuing the NOOP commands). Others trying to
> access the server during this time will receive connection refusals or
> "server too busy" errors.

In corporate type situations where bandwidth isn't an issue and keeping
the connection open is better than the small delay for tearup/down, I'd
configure the server to leave the connection up as long as NOOP's keep
arriving.

In a different situation where the bandwidth is an issue and the small
delay of establishing a connection is better than keeping the
connections open, I'd configure the server to drop the connection after
the 5th consecutive NOOP.

In any case, the client should be responsible for reconnecting to the
server whenever required.  If the "newevents?" timer expires, the client
should ask the server if anything new has arrived.  If the user starts
doing something in the client, it should check the connection and
reestablish with no further action on the part of the user.

Ideally as a user, I won't even know that it was doing so.  

> data. That is, the NOOP command is being used in a way it probably

This sounds wrong.  It's not a "get new messages", it's the equivalent
of ping.

>    * Do we really want a NOOP command in CAP?

Yes.  

>    * If so, it seems like we might want to allow the server to drop
>      the connection anyway to avoid idle connections building up.  So,
>      the server should probably be able to drop a connection at its

The server should be able to ignore the NOOP and drop the connection
whenever required.  The client should attempt to reconnect with a
backoff algorithim to prevent loading.

dmadeo

---

From: [email-masked] (Steve Mansour)
Date: Sun, 23 Jan 2000 15:08:50 -0800

> This sounds wrong.  It's not a "get new messages", it's the equivalent

which has been used get "unsolicited" data.

-Steve

---

From: Doug Royer <[email-masked]>
Date: Mon, 24 Jan 2000 13:01:15 -0800

> This sounds wrong.  It's not a "get new messages", it's the equivalent

It unfortunately is an overloaded command in IMAP. It mans both.

> backoff algorithim to prevent loading.

I agree, the CS should be the final authority. And I agree that
CAP should state the CUA needs to auto-reconnect (to summarize
what David said).

How about we rename NOOP to PING to avoid the undesired IMAP meaning?