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

[Chris Newman <[e-mail]>]

Only aesthetic editorial suggestions left, use if you wish...

--On August 23, 2011 8:07:33 +0300 Mykyta Yevstifeyev <[e-mail]> 
wrote:
> 18.08.2011 3:39, Chris Newman wrote:
>>> From a technical viewpoint, I have two suggestions:
>>
>> Add to section 2.1:
>>
>>  Servers that lack configuration to accept an X.509 client certificate 
for
>>  authentication purposes MUST NOT send a CertificateRequest handshake to 
the client
>>  during TLS negotiation.
>
> Here I concur with Alexey that SHOULD NOT is fine to add such sentence.

That works for me.

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

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

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

Otherwise looks good.

		- Chris