Serious design flaw in STARTLS documents

In implementing draft-hoffman-smtp-ssl-05.txt and
draft-newman-tls-imappop-03.txt, I have found a security problem and
interoperability problem which I believe should be addressed before
these documents are published as RFC's.

The protocols as specified are likely to lead to client implementations
vulnerable to a man-in-the-middle attack directed at
capabilities/service-extensions OTHER than the STARTTLS extension
itself.  This occurs if a client believes extensions it received before
starting up TLS.

The fix is to require that the client discard all knowledge of
capabilities/extensions it received prior to negotiating TLS.  After
negotiating TLS, the client must re-query for capabilities/extensions. 
The documents could save a round trip by stating that following a TLS
negotiation, the server must immediately send a list of
capabilities/extensions to the client.

This fix would also address the interoperability problem, which is that
the list of available SASL mechanisms is likely to depend on the state
of the TLS negotiation.  A server does not want to advertise the SASL
EXTERNAL mechanism unless it accepts the client's TLS certificate.  A
server does not want to advertise the SASL PLAIN mechanism unless there
is sufficient encryption to protect from passive sniffing any password
the client would send in response.

Since STARTTLS is an extension which is only enabled by active
negotiation of both parties, it is reasonable for it to amend any
restrictions in the SMTP or IMAP protocols against the list of
capabilities/extensions changing due to session state.