Re: Request to review draft-yevstifeyev-pops-uri-scheme-02

[Mykyta Yevstifeyev <[e-mail]>]

16.03.2011 19:59, Chris Newman wrote:
> --On March 16, 2011 9:42:54 +0200 Mykyta Yevstifeyev 
> <[e-mail]> wrote:
>> 2011/3/15, Chris Newman <[e-mail]>:
>>> This document fails to state whether the POP server is in AUTHORIZATION
>>> state or TRANSACTION state upon conclusion of the SSL/TLS 
>>> negotiation on
>>> the pops port.
>>>
>> It's considered that the user agent will enter AUTHORIZATION state
>> after TLS negotiation. The case when it will be already in
>> TRANSACTION state is described in RFC 2595.
>
> There is no such case described for POP in RFC 2595. RFC 2595's POP 
> section states:
>
> "The STLS command is only permitted in AUTHORIZATION state and the server
>  remains in AUTHORIZATION state, even if client credentials are supplied
>  during the TLS negotiation."
However this depends on the implementation.  Since the pop3s protocol is 
not properly documented, some software might treat do in one way (enter 
the AUTHORIZATION state after the TLS handshake) while others might 
enter TRANSACTION state.  But now, when we're trying to document this 
protocol it's needed to be documented.  But this needs additional 
discussion.
>
>>> If you state that the POP server is in AUTHORIZATION state after the 
>>> TLS
>>> negotiation completes, even if a client certificate is supplied, then
>>> your document will be consistent with RFC 2595 and the EXTERNAL SASL 
> mechanism
>>> can be used to enter TRANSACTION state, but the document will not
>>> necessarily be consistent with the majority behavior of de-facto pops
>>> implementations that support client certificates.
>>>
>> You mean the implementations of RFC 2595, while the proposed document
>> contains different POP3 over TLS binding at all.
>
> No. I mean existing implementations of pop3s (negotiating SSL/TLS at 
> connection start on port 995 for POP). I believe Thunderbird and 
> Outlook, for example, assume the server enters TRANSACTION state 
> automatically when a valid client certificate is provided with the 
> pop3s protocol.
>
>> The purpose of it is
>> to provide another procedure, not that described in 2595.
>
> I understand. RFC 2595 section 7 attempted to discourage use of imaps 
> and pop3s with reason. But reason rarely trumps deployment. So imaps 
> and pop3s are deployed but not standardized protocols so there are 
> some interoperability problems. We should accept they won't go away 
> and document how they should interoperate. If your draft does that for 
> pop3s, I consider it a welcome contribution to the RFC series.
>
> While we're on the subject, I recommend your IANA considerations also 
> updates the "pop3s" port registration to point to your document. That 
> would be useful as your document will be the first time the "pop3s" 
> protocol behavior is actually written down in a specification.
OK, these concerns will be considered in the next version.

All the best,
Mykyta Yevstifeyev
>
>         - Chris
>
>