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

[Dave Cridland <dave at cridland.net>]

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:
>    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.
I'll change to this - I've had comments about this paragraph already.



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


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


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


> Section 4.3.1
> The first, second and third paragraphs should be combined into one  
> paragraph.
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.


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


> Section 4.3.2, last paragraph
> 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:dave at cridland.net - xmpp:dwd at jabber.org
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf