Revised TLS + IMAP/POP/ACAP draft-06

I just sent in a revised "compromise" draft it should come out next week
sometime.  A preview is available at:

  <http://www.innosoft.com/iii/persons/chris/tls-imappop-06.html>

The basic changes are as follows:

* Fleshed out motivation section to note desire to eliminate unencrypted
  transmission of passwords
* Forbid use of any unencrypted password mechanism which
  isn't already standards track (including PLAIN) to align with
  motiviation.  I used most of Mark Crispin's suggested text and added
  some of my own.
* Moved STARTTLS result test requirement from security considerations to
  new section 2.5 and used better language from SMTP TLS spec for this
  purpose.
* Added IMAP4 LOGINDISABLED capability.
* Added appendix documenting current usage of PLAIN.
* Added compliance checklist appendix.
* Removed the "NO" failure case for STARTTLS in IMAP and ACAP.  It was
  an unnecessary case.  "BAD" sufficies for use of STARTTLS whenever it's
  not supposed to be used (wrong state, security layer active or command
  unknown).
* Made the "-ERR" text in the POP3 example more generic.

What I didn't do:

* Add text about security warning messages.  Mark Crispin didn't like it
  and it wasn't worth delaying the spec over.
* I didn't add Mark Crispin's specific language forbidding server
  advertisement about PLAIN.  The generic requirement that PLAIN can't be
  used unless encryption is active makes it quite clear now that servers
  are forbidden from advertising PLAIN if encryption is not active. I don't
  want to confuse implementors into the mistaken impression that server
  advertisement of PLAIN has a significant impact on protocol security
  when it's the client's responsibility to determine when PLAIN is
  acceptable.

I'll want to ask for this draft to go last call in two weeks (after I get
back from vacation).  If Mark Crispin makes more demands for changes, I'm
likely to leave the decision up to the IESG unless there is a lot of
support on the mailing list.

		- Chris