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.
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Chris Newman
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Paul Smith
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Randall Gellens
- Re: POP handling commands given in wrong state Randall Gellens
- Re: POP handling commands given in wrong state Randall Gellens
- Re: POP handling commands given in wrong state Paul Smith
- Re: POP handling commands given in wrong state Paul Smith
- Re: POP handling commands given in wrong state Randall Gellens
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Paul Smith
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Paul Smith
- POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-… Paul Smith
- Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-… Mykyta Yevstifeyev
- Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-… Chris Newman
- Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-… Mykyta Yevstifeyev
- Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-… Chris Newman
- Re: POP handling commands given in wrong state Alexey Melnikov
- Fwd: I-D Action: draft-yevstifeyev-pop-wrong-stat… Mykyta Yevstifeyev