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

Hi Chris,

Chris Newman wrote:

> --On March 16, 2011 9:42:54 +0200 Mykyta Yevstifeyev 
> <[email protected]> wrote:
>
>> 2011/3/15, Chris Newman <[email protected]>:
>>
>>> 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."
>
>>> 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.

Interesting. Do they do the same when no client certificate is 
specified? I suspect the answer would be no, but I would like to double 
check.

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

Right.

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

I was actually thinking the same. So Mykyta and I should add such text.