Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!mcvax!dpk From: dpk@mcvax.uucp (Doug Kingston) Newsgroups: net.news.b Subject: Re: POP2 (RFC937) comments... Message-ID: <134@sering.mcvax.UUCP> Date: Sun, 13-Apr-86 05:26:46 EST Article-I.D.: sering.134 Posted: Sun Apr 13 05:26:46 1986 Date-Received: Sat, 19-Apr-86 04:21:50 EST References: <22000002@hplabsc.UUCP> Reply-To: dpk@sering.uucp (Doug Kingston) Organization: CWI, Amsterdam Lines: 37 Apparently-To: rnews@haring A number of good points were made, however a couple of the comments deserve further comment: In article <22000002@hplabsc.UUCP> taylor@hplabsc.UUCP writes: > 4. The default mailboxes for Unix are strange. Specifically, I've > never heard of any Unix system that queues mail in > /usr//Mail/inbox/* > On the other hand, "/usr/mail/" is quite common on Bell > systems... Yes indeed. The suggestion of putting user directories under /usr is a mistake. It greatly complicates system administration. Reference to specific os dependent strings should be avoided in an Internet spec. > 8. In the sequence RETR 2 ; ; ACKD ; RETR 1 ; ; ACKS > the return should be different from the sequence HELO a b ; #1 ; > RETR ; < send > ; ACKS. That is, the return should distinguish > between no-more-messages and next-message-marked-as-deleted. > (In fact, in the latter case, perhaps the ACK* should increment > the current-message to the next UNDELETED message or EOF, which- > ever comes first) I disagree with the latter comment in parens. The behavior of ACK* should be very predictable so the client and server do not get out of sync. Don't increment by more than one each time. If the next message is "deleted", say so. > 9. In a more general sense, it would be interesting to have a > similar protocol for queueing OUTBOUND messages too...(to be > distinguished from the UUCP wait-till-it-calls-us method) > It's called SMTP, RFC-821. (if I understood your desire properly...) Cheers, -Doug-