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

Chris Newman <> Fri, 05 August 2011 18:41 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p75IfG3i090712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2011 11:41:16 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p75IfGOh090711; Fri, 5 Aug 2011 11:41:16 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from (brmea-mail-2.Sun.COM []) by (8.14.4/8.14.3) with ESMTP id p75IfEgO090706 for <>; Fri, 5 Aug 2011 11:41:15 -0700 (MST) (envelope-from
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id p75IfWmr002968; Fri, 5 Aug 2011 18:41:32 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p75IfUGW018511; Fri, 5 Aug 2011 18:41:30 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from [] ( []) by (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <>; Fri, 05 Aug 2011 11:41:29 -0700 (PDT)
Date: Thu, 04 Aug 2011 23:07:03 -0700
From: Chris Newman <>
To: Mykyta Yevstifeyev <>, Paul Smith <>
Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt
Message-id: <648FDC3E662E2D6F71B314B0@96B2F16665FF96BAE59E9B90>
In-reply-to: <>
References: <> <> <>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

I see no reason for this to be experimental; it should be standards track. 
We have deployed protocols with similar error codes (including SMTP 503). 
It has not been harmful and has at least been helpful to debugging.

I think the specification should explicitly state that servers implementing 
WRONG-STATE MUST also advertise and implement the RESP-CODES capability 
from RFC 2449. That makes client parsing deterministic.

I think it would be helpful to state that a motivation for this document is 
to provide a way for deployed (non-standard) pop3s servers that support 
client certificate authentication to deterministically indicate whether or 
not the server accepted the client certificate in a way that also does not 
break backwards compatibility with deployed client software. That is a good 
reason for a new error code, and without a statement like that, it is not 
obvious this idea merits the cost of RFC publication. And informative 
reference to your pop3s specification may also be helpful for that purpose.

It occurs to me the response code could be more useful if it was 
"STATE/<state>" rather than WRONG-STATE. Then it could be used in the "+OK" 
banner after SSL/TLS negotiation in pop3s. In that case, we'd have:

<SSL/TLS negotiation with client cert>
+OK [STATE/TRANSACTION] client certificate accepted


<SSL/TLS negotation with client cert>
+OK [STATE/AUTHORIZATION] ready for authentication

That avoids the need for an upgraded client/server pair to try something 
and see if it fails.

		- Chris

--On August 4, 2011 6:57:06 +0300 Mykyta Yevstifeyev <> 

> Hello all,
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> 	Title           : Post Office Protocol (POP) WRONG-STATE Response Code
>> 	Author(s)       : Mykyta Yevstifeyev
>> 	Filename        : draft-yevstifeyev-pop-wrong-state-00.txt
>> 	Pages           : 4
>> 	Date            : 2011-08-03
>>     This document defines new experimental POP response code to be used
>>     in responses to commands which mismatch the state they were given in.
>> A URL for this Internet-Draft is:
>> .txt
>> Internet-Drafts are also available by anonymous FTP at:
>> This Internet-Draft can be retrieved at:
>> txt
> The HTMLized version -
>  Any
> comments are welcome, of course.
> Mykyta Yevstifeyev