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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]