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

[Mykyta Yevstifeyev <[e-mail]>]

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 
> <[e-mail]> 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
>>
>>
>
>
>
>
>