my 2 cents worth

Ian Duncan <> Mon, 06 June 1994 15:33 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa04265; 6 Jun 94 11:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04261; 6 Jun 94 11:33 EDT
Received: from ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa08773; 6 Jun 94 11:33 EDT
Received: (from postman@localhost) by (8.6.7/8.6.6) id LAA05266; Mon, 6 Jun 1994 11:29:37 -0400
Received: via switchmail for; Mon, 6 Jun 1994 11:29:36 -0400 (EDT)
Received: from via qmail ID </afs/>; Mon, 6 Jun 1994 11:28:55 -0400 (EDT)
Received: from sifon.CC.McGill.CA (sifon.CC.McGill.CA []) by (8.6.7/8.6.6) with ESMTP id LAA13242 for <>; Mon, 6 Jun 1994 11:28:34 -0400
Received: from (java.CC.McGill.CA []) by sifon.CC.McGill.CA (8.6.8/8.6.6) with SMTP id LAA11122 for <>; Mon, 6 Jun 1994 11:28:32 -0400
Date: Mon, 6 Jun 1994 11:28:32 -0400 (EDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ian Duncan <>
Subject: my 2 cents worth
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I've been too busy to indulge in the elliptical drift that the list 
seemed to need, but with the edict to "get focused" I spent this weekend 
reviewed the 100 or so messages posted since the list was started a few 
weeks ago along with the original (rfc1081) and recent (draft-rose-again) 
POP3 documents.

As I see it, there's about a half dozen real issues outstanding that need 
to be tightened up. Two are subject to significant differences of 
opinion, the persistance of LAST and behavior of servers on 
broken/timed-out connections.

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. 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. Done right this can 
be a big win and there are several server implementations that at least 
try to do this right already. Declaring them all wrong doesn't seem to be 
good RFC authorship practice. I suggest words documenting the orginal 
intent for LAST to provide a checkpoint for persistent client connections 
would be good sugar. There seemed to be some confusion about the 
permissibility of updates to add messages while a POP3 client is 
connected and this would clarify that point.

There's a related issue of defining how a server should generally 
constrain the changes in the message store -- the language in the current 
draft talks about "exclusive lock" etc. -- when that gets rewritten alot 
of the issues defining the edges of this will hopefully be clearer.

Answers to the broken/timed-out connection question (and yes I do realise
putting them together is a slight perversion of the conversation so far)
are little less clear to me. I'd like to play devil's advocate with Steve
Dorner for a moment. One of the great features of TCP/IP is the general
robustness in the face of transient network outages, eg. a modem
connection blows out. Are we discussing cases where folks are using POP3
over direct dialup connections and a modem blows out? This is a fairly
commonly used Eudora feature and I'm vague about how sympathetic we ought
to be. I can think of some other cases like transient net access servers
with node IP addresses bound to the interface not the user station where
similar problems arise. This is a very fuzzy space and my sense is there's
no good answer. 

My gut feeling is that words saying "SHOULD reset/SHOULD NOT update" with 
a nod and mumble about excepting non-standard use is reasonable. A few 
words mandating that server implementations should make this option 
switchable at execution/connection level (not compile-time) are probably 
worthwhile. I do think we need to acknowledge the requirement for server 
timeouts. 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. The 
server behavior on timeout should be expressly stated as "close the 
connection -- no traffic generated".

There's a proposal to add a command, UIDL. I think the arguments presented
for adding it are very strong. Even with a more permissive LAST adding
some easy method of uniquely identifying messages on the server without
retrieving it is very useful. I'm suggest we consider extending the result
of the LIST command to support this instead of extending the commands.
What I'd suggest is a short tagged value using the MIME base-64 set to
represent it. There's fairly strong language in both of the spec's I read
discouraging this kind of thing so I won't be suprised if it can't be done
for some reason. 

Finally a couple of other items I picked up in my reading. TOP has an 
index origin of 1. Even 1081 is fairly clear about this, albeit it's read 
into the example. The current Rose draft is consistent with. Robust 
clients should assume origin 1 and tolerate 0. No big deal. Values 
reported by LIST/STAT should be accurate, particularly the size from LIST 
and # of messages from STAT. 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 

I have no strong feeling about the other outstanding items.

   ...   ian   <>
Ian Duncan  ---  McGill University Computing Centre  ---  +.514.398.3710