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

Mykyta Yevstifeyev <evnikita2@gmail.com> Tue, 09 August 2011 04:13 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p794DIdD059556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2011 21:13:18 -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 p794DIBx059555; Mon, 8 Aug 2011 21:13:18 -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-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p794DGsX059550 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <ietf-pop3ext@imc.org>; Mon, 8 Aug 2011 21:13:17 -0700 (MST) (envelope-from evnikita2@gmail.com)
Received: by fxg17 with SMTP id 17so4873752fxg.16 for <ietf-pop3ext@imc.org>; Mon, 08 Aug 2011 21:13:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=u4lWHlVrmcj+3aYnklmYHte5yQdyCcXmBJ90JC239II=; b=E/Ejmh7wGr30PrgStxsIbHEBPPECd3/Zy8cGVX6VLEG7mUJ5EpT/VVCiBiNp+p2he7 LjL+gZ0vqmeFTuJwl3RMkfr4TQka105o3+PlzYGt9Uf10GnGQE5o8d9skbZX4cGe+WKu by4iefG1Mr2UIMnMzl9bsOvG4mB8cBGFsBmdA=
Received: by 10.223.121.204 with SMTP id i12mr8726503far.83.1312863216713; Mon, 08 Aug 2011 21:13:36 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q15sm4652505fah.8.2011.08.08.21.13.35 (version=SSLv3 cipher=OTHER); Mon, 08 Aug 2011 21:13:35 -0700 (PDT)
Message-ID: <4E40B415.2060307@gmail.com>
Date: Tue, 09 Aug 2011 07:14:13 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Chris Newman <chris.newman@oracle.com>
CC: Paul Smith <paul@pscs.co.uk>, 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>
In-Reply-To: <BF09F734FB495FA4A985B928@96B2F16665FF96BAE59E9B90>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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>

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.

Mykyta

>
>         - Chris
>
>