IETF Logo Mail Archive

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

Chris Newman <chris.newman@oracle.com> Mon, 08 August 2011 21:59 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p78Lx80n047598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2011 14:59:08 -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 p78Lx8UJ047597; Mon, 8 Aug 2011 14:59:08 -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 brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p78Lx74k047592 for <ietf-pop3ext@imc.org>; Mon, 8 Aug 2011 14:59:08 -0700 (MST) (envelope-from chris.newman@oracle.com)
Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p78LxO1u011285; Mon, 8 Aug 2011 21:59:25 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p78LxO9b046070; Mon, 8 Aug 2011 21:59:24 GMT
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"; format="flowed"
Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LPM00735QEYNH00@gotmail.us.oracle.com>; Mon, 08 Aug 2011 14:59:24 -0700 (PDT)
Date: Mon, 08 Aug 2011 14:59:22 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Mykyta Yevstifeyev <evnikita2@gmail.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
Message-id: <BF09F734FB495FA4A985B928@96B2F16665FF96BAE59E9B90>
In-reply-to: <4E3CC55D.2050507@gmail.com>
References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E3A1892.7030301@gmail.com> <648FDC3E662E2D6F71B314B0@96B2F16665FF96BAE59E9B90> <4E3CC55D.2050507@gmail.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
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 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.

		- Chris

v2.23.0 | Report a Bug | By Email