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 > >
- 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