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 94 17:53:44 GMT
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