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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
