my 2 cents worth
Ian Duncan <id@cc.mcgill.ca> Mon, 06 June 1994 15:33 UTC
Received: from ietf.nri.reston.va.us 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 andrew.cmu.edu (8.6.7/8.6.6) id LAA05266; Mon, 6 Jun 1994 11:29:37 -0400
Received: via switchmail for ietf-pop3+@andrew.cmu.edu; Mon, 6 Jun 1994 11:29:36 -0400 (EDT)
Received: from po5.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.khwo2lu00UddAnmk4V>; Mon, 6 Jun 1994 11:28:55 -0400 (EDT)
Received: from sifon.CC.McGill.CA (sifon.CC.McGill.CA [132.206.27.10]) by po5.andrew.cmu.edu (8.6.7/8.6.6) with ESMTP id LAA13242 for <ietf-pop3@andrew.cmu.edu>; Mon, 6 Jun 1994 11:28:34 -0400
Received: from java.cc.mcgill.ca (java.CC.McGill.CA [132.206.35.22]) by sifon.CC.McGill.CA (8.6.8/8.6.6) with SMTP id LAA11122 for <ietf-pop3@andrew.cmu.edu>; Mon, 6 Jun 1994 11:28:32 -0400
Date: Mon, 06 Jun 1994 11:28:32 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ian Duncan <id@cc.mcgill.ca>
Subject: my 2 cents worth
To: ietf-pop3@andrew.cmu.edu
Message-ID: <Pine.3.89.9406061124.B12726-0100000@java.cc.mcgill.ca>
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 magnitude. I have no strong feeling about the other outstanding items. ... ian <id@cc.mcgill.ca> Ian Duncan --- McGill University Computing Centre --- +.514.398.3710
- my 2 cents worth Ian Duncan
- Re: my 2 cents worth Frank Bieser
- Re: my 2 cents worth Steve Dorner
- Re: my 2 cents worth John Gardiner Myers
- Re: my 2 cents worth Michael D'Errico
- Re: my 2 cents worth Ian Duncan
- Re: my 2 cents worth Michael D'Errico
- Re: my 2 cents worth Michael D'Errico
- Re: my 2 cents worth John Gardiner Myers
- Re: my 2 cents worth Ian Duncan
- Re: my 2 cents worth Ian Duncan