Re: POP handling commands given in wrong state

Paul Smith <paul@pscs.co.uk> Tue, 26 July 2011 08:19 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6Q8JvVx086685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 01:19:57 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p6Q8Jvak086684; Tue, 26 Jul 2011 01:19:57 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from mail.pscs.co.uk (mail.pscs.co.uk [46.20.224.92]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6Q8JsRq086677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pop3ext@imc.org>; Tue, 26 Jul 2011 01:19:57 -0700 (MST) (envelope-from prvs=018878D732=paul@pscs.co.uk)
Received: from lmail.pscs.co.uk ([217.155.61.14]) by mail.pscs.co.uk ([46.20.224.92] running VPOP3) with ESMTP; Tue, 26 Jul 2011 09:19:56 +0100
Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Tue, 26 Jul 2011 09:12:56 +0100
Message-ID: <4E2E7708.3080004@pscs.co.uk>
Date: Tue, 26 Jul 2011 09:12:56 +0100
From: Paul Smith <paul@pscs.co.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>, ietf-pop3ext@imc.org
Subject: Re: POP handling commands given in wrong state
References: <4E2E49AC.9090207@gmail.com>
In-Reply-To: <4E2E49AC.9090207@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: paul
X-Server: VPOP3 Enterprise V4.0.0e - Registered
X-Organisation: Paul Smith Computer Services
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

On 26/07/2011 05:59, Mykyta Yevstifeyev wrote:
>
> Hello,
>
> Post Office Protocol (POP) currently has no means of explicit 
> indicating that the command is given in the wrong state.
>
>>     A server MUST respond to a command issued when the
>>     session is in an incorrect state by responding with a negative 
>> status
>>     indicator.
>
> doesn't give enough information to the client.  The -ERR response 
> indicating wrong state may override -ERR response given with its 
> natural meaning.  I propose to define the new POP extension response 
> code (RFC 2449), WRONG-STATE, to indicate this.  Eg.:
>
>> C: <connects to the server>
>> S: +OK server ready
>> C: STAT
>> S: -ERR [WRONG-STATE] Not in TRANSACTION state yet
>
> Any thoughts?
I wouldn't have thought it would matter

AIUI the extension response codes are so that the client can understand 
it enough to tell the user what the error means (eg mailbox in use, 
rather than invalid password, during the login phase, so don't bother 
asking for the correct password)

Client code should never issue commands in the wrong state by the time 
it has been released to users... It may happen during development or 
testing, but at that time the interested people should have enough 
technical ability to read the standard and realise what has happened...

For that use:
-ERR not in transaction state yet
is just as good as
-ERR [WRONG-STATE] not in transaction state yet

If the state was server defined, so that it may change on the server's 
decision, rather than by purely bad coding in the client, then yes, an 
extended response code may be useful, but when it is only bad coding in 
the client which can make it happen - no.

Just my 2p worth