Mark Crispin <MRC@cac.washington.edu> Tue, 21 June 1994 23:45 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15409; 21 Jun 94 19:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15405; 21 Jun 94 19:45 EDT
Received: from PO2.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa19657; 21 Jun 94 19:45 EDT
Received: (from postman@localhost) by po2.andrew.cmu.edu (8.6.7/8.6.6) id TAA29577; Tue, 21 Jun 1994 19:42:57 -0400
Received: via switchmail for ietf-pop3+@andrew.cmu.edu; Tue, 21 Jun 1994 19:42:57 -0400 (EDT)
Received: from po5.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/q001/QF.Yi1rcjW00UddEET05b>; Tue, 21 Jun 1994 19:39:30 -0400 (EDT)
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu []) by po5.andrew.cmu.edu (8.6.7/8.6.6) with SMTP id TAA04213 for <ietf-pop3@Andrew.CMU.EDU>; Tue, 21 Jun 1994 19:39:14 -0400
Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67e/UW-NDC Revision: 2.27.MRC ) id AA09085; Tue, 21 Jun 94 16:39:11 -0700
Date: Tue, 21 Jun 1994 16:10:56 -0700 (PDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Crispin <MRC@cac.washington.edu>
X-Orig-Sender: Mark Crispin <mrc@tomobiki-cho.cac.washington.edu>
Subject: draft-rose-pop3-again-02.txt
To: ietf-pop3@andrew.cmu.edu
Message-Id: <MailManager.772240256.8186.mrc@Tomobiki-Cho.CAC.Washington.EDU>
Mime-Version: 1.0

Just for my edification, why doesn't POP3 have an equivalent to the IMAP4
CAPABILITY command, and why doesn't POP3 have more command completion codes
than just +OK and -ERR?  I remember being badly beaten up on these sorts of
issues with IMAP, and am bewildered to see that nothing has been done with
either with POP.

Did we really decide that there should be ``one or more whitespace
characters'' delimiting keywords and arguments?  Does any client use more than
one whitespace character?  Does any client use TAB?  [Page 3]

Is -ERR really a ``success indicator''?  [Page 3]

``Hence a multi-line response is terminated with the five octets''... seems to
be restating the obvious and is confusing in the context of the previous
sentence.  [Page 3]

Why isn't a server permitted to give
	-ERR I can't talk with you now
as a greeting?  (Equivalent to IMAP4 BYE as a greeting) [Page 4]

AUTHORIZATION state information should mention APOP, and perhaps also AUTH.
Note that the current spec says ``must now issue the USER command'' -- this
should be modified given other means of authentication.  [Page 4]

It's a nasty implementation burden to make the server permit a new USER
command if the lock can't be obtained.  If clients don't implement it, it
should be nuked.  [Page 4]

``This line is called a "drop listing" for that''  For that what?  [Page 7]

``The first octets present must indicate the number of messages''  I had to
read this a few times before I figured out what this meant, especially in
light of the following sentence.  I suggest a rewrite.  [Page 7]

``This line is called a "scan listing" for that message.'' is stated twice.
[Page 8]

Same ``The first octets'' problem as on page 7.  [Page 8, Page 13]

Page 17 is awfully mealy-mouthed about the message size.  Is it a reliable
indicator of the RFC822 message size in Internet text format, or isn't it?