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

Mykyta Yevstifeyev <evnikita2@gmail.com> Sat, 06 August 2011 04:38 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p764c0PC010616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2011 21:38:00 -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 p764c07V010615; Fri, 5 Aug 2011 21:38:00 -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 p764bvSY010608 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <ietf-pop3ext@imc.org>; Fri, 5 Aug 2011 21:37:58 -0700 (MST) (envelope-from evnikita2@gmail.com)
Received: by fxg17 with SMTP id 17so817188fxg.16 for <ietf-pop3ext@imc.org>; Fri, 05 Aug 2011 21:38:16 -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=AG4QTXkuqX+ZZMBU9hERf1hy7DrORC7JCrQNj7yWZeQ=; b=JhJAEkPkeRF+keEv4qfyJpvFRObskBUdyMCKtiNO0tdP53ZLqq/G/qsT8n1Qy+QEfw BcR5Z0Zeyrjh4BPcOczyso1ZqLUF80fnzQGTG1+zJsgDHnUmIQw3vGtUzagPEx3kMPw1 gfem6y5bbmcBp4i8oxBtiEuqTb9OtU5Yg/4lQ=
Received: by 10.223.50.131 with SMTP id z3mr3961688faf.127.1312605496026; Fri, 05 Aug 2011 21:38:16 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x13sm2419022fah.29.2011.08.05.21.38.14 (version=SSLv3 cipher=OTHER); Fri, 05 Aug 2011 21:38:15 -0700 (PDT)
Message-ID: <4E3CC55D.2050507@gmail.com>
Date: Sat, 06 Aug 2011 07:38:53 +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>
In-Reply-To: <648FDC3E662E2D6F71B314B0@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>

05.08.2011 9:07, Chris Newman wrote:
> 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.

Well, I'll change this.

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

This is clear from RFC 2449, but to be clearer, I'll mention this.

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

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.

Mykyta

>
>         - Chris
>
> --On August 4, 2011 6:57:06 +0300 Mykyta Yevstifeyev 
> <evnikita2@gmail.com> wrote:
>
>>
>> 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:
>>> http://www.ietf.org/internet-drafts/draft-yevstifeyev-pop-wrong-state-00 
>>>
>>> .txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-yevstifeyev-pop-wrong-state-00. 
>>>
>>> txt
>>
>> The HTMLized version -
>> http://tools.ietf.org/html/draft-yevstifeyev-pop-wrong-state-00.  Any
>> comments are welcome, of course.
>>
>> Mykyta Yevstifeyev
>>
>>
>
>
>
>
>