Re: [Uri-review] Request to review draft-yevstifeyev-pops-uri-scheme-02
Alexey Melnikov <alexey.melnikov@isode.com> Tue, 22 March 2011 12:54 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6965E28C10E for <uri-review@core3.amsl.com>; Tue, 22 Mar 2011 05:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level:
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLuFF2vrce6f for <uri-review@core3.amsl.com>; Tue, 22 Mar 2011 05:54:05 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 341AB28B797 for <uri-review@ietf.org>; Tue, 22 Mar 2011 05:54:05 -0700 (PDT)
Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TYicSAADL75m@rufus.isode.com>; Tue, 22 Mar 2011 12:55:37 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4D886E9F.7020509@isode.com>
Date: Tue, 22 Mar 2011 09:40:47 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Chris Newman <chris.newman@oracle.com>
References: <4D7F86F1.1070507@gmail.com> <6D07F4374764D58687F8B4B7@96B2F16665FF96BAE59E9B90> <AANLkTim7o-mVfo4F-8zXXvCK8sZcfcXs-9cECt0J-_ac@mail.gmail.com> <D72150CF3E13284F51B8EF8C@96B2F16665FF96BAE59E9B90>
In-Reply-To: <D72150CF3E13284F51B8EF8C@96B2F16665FF96BAE59E9B90>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-yevstifeyev-pops-uri-scheme@tools.ietf.org, uri-review@ietf.org, ietf-pop3ext@imc.org
Subject: Re: [Uri-review] Request to review draft-yevstifeyev-pops-uri-scheme-02
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2011 12:54:06 -0000
Hi Chris, Chris Newman wrote: > --On March 16, 2011 9:42:54 +0200 Mykyta Yevstifeyev > <evnikita2@gmail.com> wrote: > >> 2011/3/15, Chris Newman <chris.newman@oracle.com>: >> >>> 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.
- [Uri-review] Request to review draft-yevstifeyev-… Mykyta Yevstifeyev
- Re: [Uri-review] Request to review draft-yevstife… Chris Newman
- Re: [Uri-review] Request to review draft-yevstife… Mykyta Yevstifeyev
- Re: [Uri-review] Request to review draft-yevstife… Chris Newman
- Re: [Uri-review] Request to review draft-yevstife… Mykyta Yevstifeyev
- Re: [Uri-review] Request to review draft-yevstife… Alexey Melnikov