[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request to review draft-yevstifeyev-pops-uri-scheme-02
--On March 16, 2011 9:42:54 +0200 Mykyta Yevstifeyev <evnikita2@xxxxxxxxx>
2011/3/15, Chris Newman <chris.newman@xxxxxxxxxx>:
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
"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
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.