Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt

On 09/08/2011 06:14, Mykyta Yevstifeyev wrote:
> 09.08.2011 0:59, Chris Newman wrote:
>> --On August 6, 2011 7:38:53 +0300 Mykyta Yevstifeyev 
>> <[email protected]> wrote:
>>> Well, in the case when we define a response code, a clear reason for
>>> issuing it should be stated.  For the STATE response code, there is no
>>> one.  With respect to POP3S.  After some discussions with Alexey we
>>> reached the agreement to follow RFC 1939, and state the following: (1)
>>> TLS negotiation --> /AUTHORIZATION/ (2) [due to client/server's 
>>> settings]
>>> use SASL EXTERNAL --> (3) [if 2 fails, or there was no convention 
>>> between
>>> client and server] authenticate itself --> /TRANSACTION/ (4) actual
>>> transaction.  So the response code for this purpose isn't useful any 
>>> more.
>>
>> Ok. So then why is the WRONG-STATE code useful enough to be worth the 
>> trouble to publish a document?
>>
>> The litmus test that's been mostly followed for IMAP is that a 
>> response code is justified if the client can usefully behave 
>> differently as a result of the response code. Can you articulate how 
>> the client would usefully behave differently as a result of this 
>> code? If so, I suggest adding that explanation to the document.
>
> There already is.  When the client receives such response, it should 
> change its state according to the server's one.  If client and a 
> server are unsynchronized, WRONG-STATE response code will facilitate 
> their synchronizing.
My view is that if a POP3 agent will be changed according to a new 
document, it should be changed to use authentication - even if it's SASL 
EXTERNAL, so 'WRONG-STATE' will never happen

If we are just documenting existing behaviour, then a 'WRONG-STATE' code 
is irrelevant as that is not in existing behaviour

So, either way the 'WRONG-STATE' code is no use.