a different tack
William Allen Simpson <bill.simpson@um.cc.umich.edu> Tue, 14 June 1994 19:45 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08278; 14 Jun 94 15:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08274; 14 Jun 94 15:45 EDT
Received: from PO5.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa14311; 14 Jun 94 15:45 EDT
Received: (from postman@localhost) by po5.andrew.cmu.edu (8.6.7/8.6.6) id PAA23386; Tue, 14 Jun 1994 15:35:52 -0400
Received: via switchmail for ietf-pop3+@andrew.cmu.edu; Tue, 14 Jun 1994 15:35:51 -0400 (EDT)
Received: from po5.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q000/QF.QhzUNvK00UddJPFk43>; Tue, 14 Jun 1994 15:35:27 -0400 (EDT)
Received: from merit.edu (merit.edu [35.1.1.42]) by po5.andrew.cmu.edu (8.6.7/8.6.6) with ESMTP id PAA23346 for <ietf-pop3@andrew.cmu.edu>; Tue, 14 Jun 1994 15:35:03 -0400
Received: from pm002-28.dialip.mich.net (pm002-28.dialip.mich.net [35.1.48.109]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA25428 for <ietf-pop3@andrew.cmu.edu>; Tue, 14 Jun 1994 15:34:59 -0400
Date: Tue, 14 Jun 1994 17:53:44 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson@um.cc.umich.edu>
Message-ID: <2656.bill.simpson@um.cc.umich.edu>
To: ietf-pop3@andrew.cmu.edu
Reply-to: bsimpson@morningstar.com
Subject: a different tack
Having slowly caught up on the large amount of email generated in a short time, may I suggest that we are moving a bit in the wrong direction? In my experience, upgrading the Standardization status of a protocol means we _should_ add implementation detail, but _not_ add new features. New features should go in a separate extensions draft, or the whole POP3 should go back to Proposed Standard, and we have to go through forming a working group. So, I suggest that we add implementation history about what people have really done in the past, together with a "recommendation" as to what the "best" solution would be. We can't force anyone, we have no protocol police. Writing down the goods and bads is our best insurance. DELE/QUIT, for example, should note that some enter UPDATE on connection failure, but the _recommended_ solution is _not_ to delete. There are some subtleties, like what happens if the QUIT goes through, but the +OK fails. These should all be written down. Nothing left to chance. BTW, I like UIDL. I would prefer it to go in a separate extensions document, which everybody just implements, and it advances on its own. Bill.Simpson@um.cc.umich.edu
- Re: a different tack Steve Dorner
- a different tack William Allen Simpson
- Re: a different tack Michael D'Errico
- Re: a different tack John Gardiner Myers
- Re: a different tack Marshall Rose
- Re: a different tack William Allen Simpson
- Re: a different tack John Gardiner Myers