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

Paul Smith <paul@pscs.co.uk> Tue, 09 August 2011 15:23 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p79FNhKi092272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Aug 2011 08:23:43 -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 p79FNhDA092271; Tue, 9 Aug 2011 08:23:43 -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 p79FNeHv092265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pop3ext@imc.org>; Tue, 9 Aug 2011 08:23:42 -0700 (MST) (envelope-from prvs=0202B864E8=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, 9 Aug 2011 16:19:50 +0100
Received: from [192.168.0.6] ([2.14.192.115]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Tue, 9 Aug 2011 16:15:05 +0100
Message-ID: <4E414EF5.8040507@pscs.co.uk>
Date: Tue, 09 Aug 2011 17:15:01 +0200
From: Paul Smith <paul@pscs.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
CC: Chris Newman <chris.newman@oracle.com>, ietf-pop3ext@imc.org
Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt
References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E3A1892.7030301@gmail.com> <648FDC3E662E2D6F71B314B0@96B2F16665FF96BAE59E9B90> <4E3CC55D.2050507@gmail.com> <BF09F734FB495FA4A985B928@96B2F16665FF96BAE59E9B90> <4E40B415.2060307@gmail.com>
In-Reply-To: <4E40B415.2060307@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; 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 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 
>> <evnikita2@gmail.com> 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.