Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt

Mykyta Yevstifeyev <evnikita2@gmail.com> Thu, 25 August 2011 09:16 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7P9GujK045515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2011 02:16:56 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p7P9Gu7E045514; Thu, 25 Aug 2011 02:16:56 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7P9GsWV045505 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <ietf-pop3ext@imc.org>; Thu, 25 Aug 2011 02:16:55 -0700 (MST) (envelope-from evnikita2@gmail.com)
Received: by bkbzv15 with SMTP id zv15so2605423bkb.16 for <ietf-pop3ext@imc.org>; Thu, 25 Aug 2011 02:16:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OgrkdIdtuknLBAHj5W8+EcOCUb2T7QKtQMhqYnuejJk=; b=rZ/Z5hlIVe7IpdaD6jLk50Kmu9ZJlMA+xPQ6m7Kus96rDtfgJNeGIDY4vKw06eJwCT GrTBQEOiewuo4xkGQKodo1ez/1AuB2Vu27VHdG01dNQ0fc1J2H9ZrQYOEjbPATRKFn8B Xt3B5HD5ldVu2Ezaq4qFX5YHDcPuhDyzMEMt4=
Received: by 10.204.128.80 with SMTP id j16mr2888920bks.9.1314263813546; Thu, 25 Aug 2011 02:16:53 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id f9sm109304bkt.3.2011.08.25.02.16.51 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 02:16:52 -0700 (PDT)
Message-ID: <4E561324.30000@gmail.com>
Date: Thu, 25 Aug 2011 12:17:24 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Chris Newman <chris.newman@oracle.com>
CC: ietf-pop3ext@imc.org, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
References: <4E44F27F.802@gmail.com> <688511DBDA04FDB2E5B1C431@96B2F16665FF96BAE59E9B90> <4E533595.2020907@gmail.com> <D26E39BC7394E13A0A88DBBA@96B2F16665FF96BAE59E9B90>
In-Reply-To: <D26E39BC7394E13A0A88DBBA@96B2F16665FF96BAE59E9B90>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

24.08.2011 6:41, Chris Newman wrote:
> Only aesthetic editorial suggestions left, use if you wish...
>
> --On August 23, 2011 8:07:33 +0300 Mykyta Yevstifeyev 
> <evnikita2@gmail.com> wrote:
>> 18.08.2011 3:39, Chris Newman wrote:
>>
>> [ . . . ]
>>> Here are some editorial suggestions:
>>>
>>> In Abstract, OLD:
>>>   This document specifies how the Post Office Protocol, Version 3
>>>   (POP3) may be secured with Transport Layer Security (TLS) protocol,
>>>   by establishing TLS layer connection directly before POP3
>>>   transaction.  It updates RFC 1939 and RFC 2595.
>>> NEW:
>>>   This document specifies use of Transport Layer Security (TLS) on
>>>   port 995 to protect Post Office Protocol, Version 3. It updates RFC 
> 2595.
>>>
>>> Discussion: This no longer changes any rules in RFC 1939, so I see no
>>> reason to update that specification -- perhaps best to avoid the
>>> debates about "does this update spec XXX?" and "what does it mean for
>>> a proposed standard to update a full standard?" during last call.
>>
>> I'm OK to remove "updates RFC 1939".  However, the current abstract,
>> compared with the proposed, seems to be clearer.
>
> I can live with either text. But consider changing the final clause 
> to: "establishing a TLS connection directly before the POP3 
> transaction". Note that "TLS" standards for "Transport Layer 
> Security", so "Transport Layer Security layer connection" just sounds 
> wrong to me, thus the suggestion to drop the redundant "layer".

Fine; fixed now.

>
>>>   Two mechanisms to protect POP3 using TLS have been deployed. One 
> negotiates
>>>   TLS within POP3 (also known as upgrading to TLS) [RFC2595].  The 
>>> other
>>>   starts TLS prior to starting the POP3 application layer. The latter
>>>   mechanism (called "POP3S" throughout this document) has not been 
> previously
>>>   specified in an RFC. This document specifies POP3S.
>>
>> The analogy with HTTP, I'm convinced, is very useful; however, some of
>> the improvements you propose here will be incorporated.  (Later:) I've
>> left the following text:
>
> Ok, how about this (to make the analogy appear in one place instead of 
> a subordinate clause with a forward reference):
>
> OLD:
>     Two ways of protecting POP3 with TLS have been deployed (like 2 ways
>     of securing HTTP [RFC2616]; see below).  The first includes
> NEW suggestion:
>     Two ways of protecting POP3 with TLS have been deployed similar to 
> the
>     two specified ways of protecting HTTP [RFC2616] with TLS described in
>     RFC 2817 [RFC2817] and RFC 2818 [RFC2818]. The first includes ...

When pointing to RFCs 2817 & 2818 after brief description of what these 
two ways mean, the reader can thus apply them to these references.  So 
I'll leave the current text (and I don't think it's a significant issue 
to have much discussion and debate).

>
>> This might be considered that POP3S is a protocol that is different from
>> POP3.  However, I'll try to change this sentence so that it gets shorter
>> and clearer.  I think the following is fine:
>>
>>     After the client has received the +OK response to the authentication
>>     command, they both enter TRANSACTION state.
>
> How about:
>     After the client has received the +OK response to the authentication
>     command, both the client and server enter TRANSACTION state.

Fixed.

Mykyta

>
> Otherwise looks good.
>
>         - Chris
>
>
>
>