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

[Chris Newman <[e-mail]>]

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

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

		- Chris