Subject: SECDIR review of draft-cridland-imap-context-03

From: Chris Lonvick <[email-masked]>
Date: Fri, 18 Jan 2008 06:00:14 -0800 (PST)

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security area 
directors.  Document editors and WG chairs should treat these comments 
just like any other last call comments.

Overall, I found the document to be well written and I endorse it becoming 
a standards track RFC.  I did not find anything that would appear to be a 
security problem but I would like to see some of the wording changed in 
the Security Considerations section.  Specifically, the first paragraph 
states:
    It is believed that this specification introduces no serious new
    security considerations.  However, implementors are advised to refer
    to [IMAP].
I think it could be better worded as:
    This document defines additional IMAP4 capabilities.  As such it does
    not change the underlying security considerations of IMAP [IMAP].  The
    authors and reviewers believe that no new security issues are
    introduced with these additional IMAP4 capabilities.

Below are some other editorial items which you may consider.

Section 2, second paragaph (s/will/MUST)
    If this is missing, the server will return results as specified in
    [SORT].
should be:
    If this is missing, the server MUST return results as specified in
    [SORT].

Section 4.1, fifth paragraph (s/will/MUST)
    mailbox order - that is, by message number and UID.  Therefore, the
    UID SEARCH, SEARCH, UID SORT, or SORT command used - collectively
    known as the searching command - will always have an order, the
    requested order, which will be the mailbox order for UID SEARCH and
    SEARCH commands.
Should be:
    mailbox order - that is, by message number and UID.  Therefore, the
    UID SEARCH, SEARCH, UID SORT, or SORT command used - collectively
    known as the searching command - MUST always have an order, the
    requested order, which will be the mailbox order for UID SEARCH and
    SEARCH commands.
(or perhaps SHOULD?)

Section 4.3
The third and fourth paragraphs should be combined as they discuss the 
same topic.

Section 4.3
The seventh and eighth paragraphs should be combined.

Section 4.3.1
The first, second and third paragraphs should be combined into one 
paragraph.

Section 4.3.2, second paragraph (missing "the")
    The client MUST process ADDTO and REMOVEFROM return data items in
    order they appear, including those within a single ESEARCH response.
Should be:
    The client MUST process ADDTO and REMOVEFROM return data items in the
    order they appear, including those within a single ESEARCH response.

Section 4.3.2, last paragraph
The 2119 keywords should be used when describing expected behaviour.

Section 4.4, second paragraph (s/may/MAY)
    Only a single PARTIAL search return option may be present in a single
    command.
Should this be:
    Only a single PARTIAL search return option MAY be present in a single
    command.

Best regards,
Chris

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Cridland <[email-masked]>
Date: Sat, 19 Jan 2008 11:24:48 +0000

Thanks for the detailed and useful review.

On Fri Jan 18 14:00:14 2008, Chris Lonvick wrote:
> Overall, I found the document to be well written and I endorse it  
> becoming a standards track RFC.  I did not find anything that would  
> appear to be a security problem but I would like to see some of the  
> wording changed in the Security Considerations section.   
> Specifically, the first paragraph states:
I'll change to this - I've had comments about this paragraph already.

>    If this is missing, the server MUST return results as specified  
Disagree - this is stating the obvious - that an unextended search  
command invokes unextended behaviour. It is not an interoperability  
issue of this protocol, it's merely stating that it remains backwards  
compatible.

>    requested order, which will be the mailbox order for UID SEARCH  
No, will be, logically. The first "will" in that paragraph could be a  
MUST, but the sentence you've quoted is mere clarification of the  
logical consequence of the first.

> Section 4.3
> The third and fourth paragraphs should be combined as they discuss  
> the same topic.
> 
> 
One is a normative requirement, one is informative clarification.

> The seventh and eighth paragraphs should be combined.
Seems reasonable - I note that MAY in the eighth paragraph ought be  
to "could" or "might", since there's no optional behaviour here.

> The first, second and third paragraphs should be combined into one  
I kept the third paragraph distinct for emphasis, and it's a  
reasonable candidate for a MUST there, too. I'll combine the other  
two, though.

>    order they appear, including those within a single ESEARCH  
Thanks.

> The 2119 keywords should be used when describing expected behaviour.
Disagree - there are some cases when this cannot occur, and there's  
no impact to interoperability. I do note I've used the subjunctive  
incorrectly, here, which could imply that EXPUNGE might not occur at  
all - not the case.

As I noted in my other message, I try not to over-use RFC2119, for  
fear of diluting the effect. I've not managed to use it quite so  
sparingly as RFC4469, however. :-)

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade