Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA26241; Mon, 27 Apr 1998 09:26:22 -0400 (EDT) Received: by cs.cs.utk.edu (bulk_mailer v1.10); Mon, 27 Apr 1998 09:22:22 -0400 Received: by CS.UTK.EDU (cf v2.9s-UTK) id JAA25908; Mon, 27 Apr 1998 09:22:22 -0400 (EDT) Received: from taurus.cus.cam.ac.uk (cusexim@taurus.cus.cam.ac.uk [131.111.8.48]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id GAA21741; Mon, 27 Apr 1998 06:59:16 -0400 (EDT) Received: from ph10 (helo=localhost) by taurus.cus.cam.ac.uk with local-smtp (Exim 1.90 #1) for drums@cs.utk.edu id 0yTlcX-0004H5-00; Mon, 27 Apr 1998 11:58:49 +0100 Date: Mon, 27 Apr 1998 11:58:49 +0100 (BST) From: Philip Hazel To: drums@cs.utk.edu Subject: Re: RSET inconsistency In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 17 Apr 1998, John C Klensin wrote: > On Fri, 17 Apr 1998 23:58:06 +1000 Robert Elz > wrote: > > > | which is a contradiction. Presumably the E: line there should go? > > Two things here. First, as a consequence of some changes > elsewhere that the WG insisted upon, my recollection is that > I've worked over RSET. You might be sure that the next draft > doesn't break something you consider important. > > > These errors are the basic set that can occur in response to any command, > > and should be listed as possible responses to all of them. Or that set > > could be excerpted from each of the commands and be listed just once. > > Hmm. This strikes me as a good idea, with the only disadvantage > being that people will not notice the paragraph that says "these > aren't listed below, but apply to every command". But, unless > there are serious objections one way or the other, I'm probably > going to change the text to pull the "any command can return..." > codes out separately. Thinking over this while I've been away, it still seems to me that if you specify "these errors apply to every command" and then you specify that RSET MUST respond with 250, there is a contradiction. The comment that a server has to be prepared to receive these other error codes in case a broken client sends them is pointless. A server has to be prepared to receive *any* error code (or none). It also seems very odd to be trying to specify the behaviour of a broken server! If a server that returns 501 to RSET is "broken", what do you call a server that returns 999? "Seriously broken"?? -- Philip Hazel University Computing Service, ph10@cus.cam.ac.uk New Museums Site, Cambridge CB2 3QG, P.Hazel@ucs.cam.ac.uk England. Phone: +44 1223 334714