Re: Converging
Steve Dorner <sdorner@qualcomm.com> Fri, 03 June 1994 21:48 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12394; 3 Jun 94 17:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12385; 3 Jun 94 17:48 EDT
Received: from PO6.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa19817; 3 Jun 94 17:48 EDT
Received: (from postman@localhost) by po6.andrew.cmu.edu (8.6.7/8.6.6) id RAA27418; Fri, 3 Jun 1994 17:46:43 -0400
Received: via switchmail for ietf-pop3+@andrew.cmu.edu; Fri, 3 Jun 1994 17:46:42 -0400 (EDT)
Received: from po2.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q004/QF.whvuGTe00UdaBXMk4T>; Fri, 3 Jun 1994 17:46:08 -0400 (EDT)
Received: from ux1.cso.uiuc.edu (ux1.cso.uiuc.edu [128.174.5.59]) by po2.andrew.cmu.edu (8.6.7/8.6.6) with SMTP id RAA25438 for <ietf-pop3@andrew.cmu.edu>; Fri, 3 Jun 1994 17:46:04 -0400
Received: from dorner.slip.uiuc.edu by ux1.cso.uiuc.edu with SMTP id AA01220 (5.67b8/IDA-1.5 for <ietf-pop3@andrew.cmu.edu>); Fri, 3 Jun 1994 16:45:13 -0500
Received: from [192.17.5.3] by dorner.slip.uiuc.edu with SMTP id AA06309 (5.67b/IDA-1.5); Fri, 3 Jun 1994 16:45:17 -0500
X-Sender: sdorner@192.17.5.1
Message-Id: <aa1546fb01021016aa9f@[192.17.5.3]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 03 Jun 1994 16:45:06 -0500
To: ietf-pop3@andrew.cmu.edu
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Dorner <sdorner@qualcomm.com>
Subject: Re: Converging
Cc: John C Klensin <klensin@infoods.unu.edu>, Erik.Huizer@surfnet.nl
At 2:59 PM 6/3/94, John C Klensin wrote: >--> If there are real differences in opinion as to what things mean that >cannot be resolved (and quickly), then we need to find a mechanism to get a >consensus among existing implementations. The ambiguous areas of the old spec have been interpreted in different ways by different folks. If the ambiguities in the spec are resolved, we will wind up with implementations that are out of spec. My reading of what I've heard is that these implementations are very likely to stay out of spec, since whichever way the spec lands on some issues, there is vehement feeling in the other direction. >Any protocol *changes* are either going to require extensive IETF review and >approval (and I'll warn you, I use POP3 -- in several implementations of >both clients and servers-- for *my* mail and am not prepared to be >sympathetic to things that might mess up the installed base) Whose installed base? Some of the suggested "clarifications" would break my installed base, if they were to be implemented. I rather suspect that this is a matter of whose ox is being gored. (I impute no ill-will; just that not everyone knows what's important to somebody else's implementation.) As I see it, we have three major and one minor open issues: 1. Spaces in passwords. This is the minor one. The revision of the spec does not (to my satisfaction) clarify whether "pass foo bar" is a syntax error or a way to use the password "foo bar". Initial spaces in passwords will remain non-interoperable in any case. I don't think anybody cares much, though. 2. Behavior on connection termination. There will clearly be no consensus on this. 3. Persistence of the LAST command. The draft calls for non-persistence. This would make the existing persistent implementations non-compliant and make them reduce their functionality if they wish to become compliant. On the plus side, it would declare non-persistent LAST implementations to be compliant, without improving their functionality. 4. UIDL. This change would make all the crap regarding LAST and connection termination unimportant. If we want to avoid changes, this one is out. Without UIDL, I don't see any improvements to interoperability being made by this revision. -- Steve Dorner, Qualcomm Incorporated "There's nothing wrong with you that can't be cured with a little Prozac and a polo mallet." - Woody Allen
- Converging John C Klensin
- Re: Converging Steve Dorner
- Re: Converging Mark Crispin