Re: POP handling commands given in wrong state

[Paul Smith <[e-mail]>]

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