The IESG has reviewed draft-crispin-imapv-16.txt and has found a number
of issues that need to be addressed before the document can be approved
as a proposed standard:
(1) The AUTHENTICATE command -- which is recommended -- may fail
in practice because no mandatory-to-implement SASL mechanism is
specified. A mandatory-to-implement mechanism needs to be
specified to insure interoperability can be achieved.
(2) The document should note that it obsoletes RFC 2060 in the header.
(3)
> 3. State and Flow Diagram
>
> An IMAP4rev1 server is in one of four states. Most commands are
> valid in only certain states. It is a protocol error for the client
> to attempt a command while the command is in an inappropriate state.
^^^^^^^
"server"?
(4) The state diagram shows states (or non-states) that are not
described. (Do double arrows have any special meaning?)
(5) Section 6.1 should probably say that if a command is rejected, the
server should remain in the same state unless otherwise
specified.
(6) For sections--
> 6.2.1. AUTHENTICATE Command
and
> 6.2.2. LOGIN Command
some discussion of methods to limit the number of auth/login attempts
allowed and/or other mechanisms to discourage name/password
hacking (e.g. exponentially delay the server reply for failed attempts)
might be appropriate.
(7) The references in this document should be split between normative and
informative.
Ned
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
