Re: my 2 cents worth

John Gardiner Myers <> Mon, 06 June 1994 17:02 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa05202; 6 Jun 94 13:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05198; 6 Jun 94 13:02 EDT
Received: from ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa15234; 6 Jun 94 13:02 EDT
Received: (from postman@localhost) by (8.6.7/8.6.6) id MAA07129; Mon, 6 Jun 1994 12:58:58 -0400
Received: via switchmail; Mon, 6 Jun 1994 12:58:58 -0400 (EDT)
Received: from via qmail ID </afs/>; Mon, 6 Jun 1994 12:57:31 -0400 (EDT)
Received: from via qmail ID </afs/>; Mon, 6 Jun 1994 12:57:18 -0400 (EDT)
Received: from via; Mon, 6 Jun 1994 12:57:17 -0400 (EDT)
Message-ID: <>
Date: Mon, 6 Jun 1994 12:57:17 -0400 (EDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Gardiner Myers <>
To: POP3 IETF Mailing List <>
Subject: Re: my 2 cents worth
In-Reply-To: <>
References: <>
Beak: is Not

Ian Duncan <id@CC.McGill.CA> writes:
> I suggest that LAST *not* be removed from the required set of commands. 
> Unless I've misunderstood John Klensin's note, dropping existing required 
> commands isn't in the mandate in any case.

I didn't read John Klensin's note that way.  Perhaps he could clarify.

> Instead we should add a more 
> detailed description of the rules servers should follow for computing it, 
> with strong words about the importance of congruity/coherence, and make 
> explicit provision for persistance across sessions.

The problem with LAST is that different implementations do widely
differing things.  Many of these differences come from constraints in
the underlying implementation.

The most specific rule we could come up with for the initial value of
LAST without seriously screwing someone is that it is to be set to
some implementation-defined value between zero and the highest message
ever accessed by RETR or DELE.

Even with a specifically well-defined value persistent across
sessions, we have shown that LAST is not particularly useful in the
face of access from multiple clients.

In short, LAST is broken and cannot be repaired.  We are fixing it by
replacing it with UIDL.

> The thirty minutes proposed in IMAP seems a trifle long to me, 
> both in IMAP and POP, but consitency with it is a reasonable idea.

In POP, unlike in IMAP, that translates to thirty minutes where the
user cannot access their mail.  There is good reason to make the
minimum timeout shorter, like 10 minutes.

> I'm suggest we consider extending the result
> of the LIST command to support this instead of extending the commands.

I think it would be a bad idea to have the server calculating values
the client might not be interested in.  It is far better to have the
client explicitly ask for those values it is interested in.

> I'd be prepared to accept a very relaxed 
> accuracy for the size of the total store reported by STAT with a 
> suggestion that error an over estimation, but less than an order of 
> magnitude.

If there's strong sentiment, I would accept changing the size of the
total store to be an upper bound, but can't see "less than an order of
magnitude" being defined in a standards document.  I doubt this is
broken enough to warrant changing a previously-unambiguous

_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!!give!up