Re: POP3 highest number accessed

John Gardiner Myers <jgm+@cmu.edu> Wed, 25 May 1994 11:25 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00456; 25 May 94 7:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00451; 25 May 94 7:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id af01713; 25 May 94 7:25 EDT
Received: from ANDREW.CMU.EDU by IETF.CNRI.Reston.VA.US id aa07075; 25 May 94 0:34 EDT
Received: (from postman@localhost) by andrew.cmu.edu (8.6.7/8.6.6) id AAA20021; Wed, 25 May 1994 00:31:37 -0400
Received: via switchmail; Wed, 25 May 1994 00:31:37 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.whshFES00WBwAfDE49>; Wed, 25 May 1994 00:30:09 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr7/jm36/.Outgoing/QF.YhshEta00WBw4fBqdt>; Wed, 25 May 1994 00:29:45 -0400 (EDT)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 25 May 1994 00:29:37 -0400 (EDT)
Message-ID: <YhshEle00WBw4fBqQ4@andrew.cmu.edu>
Date: Wed, 25 May 1994 00:29:37 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Gardiner Myers <jgm+@cmu.edu>
To: POP3 IETF Mailing List <ietf-pop3+@andrew.cmu.edu>
Subject: Re: POP3 highest number accessed
In-Reply-To: <aa08476b11021014e0e0@[192.17.5.3]>
References: <aa08476b11021014e0e0@[192.17.5.3]>
Beak: is Not

sdorner@uiuc.edu (Steve Dorner) writes:
> I definitely vote for requiring persistence of the LAST value.  If
> persistence is deemed too difficult to require, make the command optional.

The problem with this is that there is at least one widely deployed
server implementation (popper) which implements LAST without
persistence.  Suddenly mandating persistence of the LAST value is not
going to make these servers go away.

It seems persistent-LAST and Status: are being used to do exactly the
same thing.  The problem is that in it is impossible for a client to
determine that a server does not implement one or the other.

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