Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!pyramid!pesnta!hplabs!sdcrdcf!trwrb!trwrba!aero!isi-hobgoblin!chase
From: chase@isi-hobgoblin.UUCP
Newsgroups: net.news.b
Subject: Re: POP2 (RFC937) comments...
Message-ID: <1251@isi-hobgoblin.ARPA>
Date: Wed, 23-Apr-86 16:51:44 EDT
Article-I.D.: isi-hobg.1251
Posted: Wed Apr 23 16:51:44 1986
Date-Received: Sun, 27-Apr-86 04:58:11 EDT
References: <22000002@hplabsc.UUCP>, <22000002@hplabsc.UUCP>
Organization: USC-Information Sciences Institute
Lines: 59


Dave- I will try to address each of your points.

1.  When a READ nnnn request is sent, the argument is relative to the
beginning of the folder (ie, it's absolute).

2.  The sentence that states that the RETR command "must be followed
by an acknowledgement command" could use a little reworking and/or
relocation.  The intent is that this ack command (one of ACKS, ACKD
or NACK) is sent after the server has completed sending the requested
message, and indicates the success or failure of receiving the
message.

3.  The suggestion of delimiting arguments like the login name with
metacharacters in the document is a good one in general, although in
some cases such conventions can be more confusing than helpful.
Italics would be ideal for a strictly hardcopy version.  Pains were
taken in the specific instances of these arguments to be clear in the
rfc.

4.  The reference to /usr/spool/mail/user and /usr/user/Mail/inbox/*
(where "user" is the value supplied in the HELO command [here's
another instance of 3. above ;]), is indeed a localism.  A note
should be made to this effect at the least.  The intent is mostly to
point out the need to consider both the directory where the system
queues incoming mail and the directory where some other mail
program(s) have "inc'd" mail.  The fact that none of the authors
(least of all myself) are unix gurus sticks out here.

5.  Responses to the FOLD command can indicate that access has been
denied, or any other condition, in the option text string that
follows the # response (ie, #0 Read access denied).

6.  If the client requests deletion of a message with the ACKD
command, and the client does not have write access to the folder, the
folder is not changed.  As above, this may be indicated in the
optional text of the response (ie, =cccc Previous message not deleted
[where cccc is the number of characters in the following message]).

7.  A RETR of a 0 character message is viewed as anomalous.  Recovery
would likely be non-trivial.  One of the guiding principles of the
protocol is stated in paragraph 3 of page 2, "if anything goes wrong
close the connection".  We really do want to keep it simple.

8.  As to whether the response to an ACKS (or ACKD) should
distinguish between no-more-messages and next-message-is-deleted,
there shouldn't be a difference as far as the protocol is concerned.
The "=0" response indicates that a RETR command (without an argument)
will not be appropriate.  If there are more messages, the client
already knows that based on the number of messages reported when the
folder was first opened.  Again, an optional text field should
suffice (ie, =0 no more messages [an example taken directly from the
example scenario in the rfc]).

9.  As dpk points out, SMTP is the appropriate protocol for queueing
outbound messages.  It is, in fact, in use in conjunction with POP on
local PCs at ISI.

<>Dale Chase