On Wed, 29 May 2002 00:34:21 -0700 (PDT), [EMAIL PROTECTED] wrote: > 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.
I agree with Alexey Melnikov that a mandatory to implement SASL mechanism is a moving target. There is currently no such thing in IMAP or, for that matter, in SASL. That's the way the SASL people designed it. Furthermore, there are cases in which *no* offered mechanism is desirable. For example, a system which only has plaintext based authentication may choose to permit no authentication until after STARTTLS is negotiated. Do you still want anything done in the IMAP specification on this matter? > (2) The document should note that it obsoletes RFC 2060 in the header. Done. > (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"? I have changed "An IMAP4rev1 server" to "An IMAP4rev1 session" and "the command" to "the session". > (4) The state diagram shows states (or non-states) that are not > described. (Do double arrows have any special meaning?) I do not understand this comment. The state diagram was entered at IESG insistance, and followed the form and ASCII art of state diagrams in other IESG approved-documents. It is unmodified from what IESG approved in RFC 1730 and 2060. By "states that are not described", do you mean the external TCP events such as "initial connection" and "close connection"? What do you mean by "double arrows"? If you mean the ASCII art by which state transition paths are indicated, IESG wanted it that way last time to make the paths thicker and easier to distinguish from boxes. Please clarify to me what you want done. > (5) Section 6.1 should probably say that if a command is rejected, the > server should remain in the same state unless otherwise > specified. I don't understand what this is supposed to clarify, and more importantly why this would be in 6.1 instead of elsewhere, e.g. section 6 or section 3. "Command rejection" isn't meaningful in 6.1 since none of the commands in 6.1 would be rejected by an IMAP4rev1 server (note that the "BAD" response is, in effect, an "unrecognized command" although it can mean "syntax error"). Please clarify to me what you want done. > (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. I agree with Arnt Gulbrandsen, Barry Leiba, and Andreas Aardel Hanssen that this belongs in a separate BCP document, since it affects many protocols other than IMAP. Do you still want anything done in the IMAP specification on this matter? > (7) The references in this document should be split between normative and > informative. This is a strange requirement. I see many other examples of recently approved documents (e.g RFC 2821) which do not have such a split. I fail to see the benefit. Furthermore, a split between "normative" and "informative" can be extremely subjective with several of these documents. Do you still want anything done in the IMAP specification on this matter?
