[SASL-ANON]. SASL mechanisms which use plaintext passwords
(including the PLAIN mechanism [PLAIN]) MUST NOT be used unless a
security layer is active or backwards compatibility dictates other
wise.
This paragraph seems to be unnecessary. PLAIN already states a
stronger requirement, and you can't weaken it here by pleading to
backwards compatibility. Implementations that implement cleartext
PLAIN are in violation of the protocol despite the best of intentions.
Agreed. I'm not sure why I didn't listen to you the first time :)
I prefer IMAP approach: use synchronizing literals in PUTSCRIPT. If
server respond '+ ...', then it will accept the script,
otherwise it will return NO.
This has the same race condition as HAVESPACE except it adds
synchronizing literals.
It doesn't have to. Once the server agrees to the syncronization it
can reserve that space because it knows the client will send a
script. However, this could possibly lead to denial of service attacks
and greatly complicates implementations.
PUTSCRIPT command has to be able to fail... or we can have a two-phase
commit. :-)
What do you think about adding response codes for various failures?
Please consider these. Adding them would greatly raises the hopes of
intelligent error recovery in client implementations, something that
seems to be very difficult for IMAP clients. (Fortunately this is
much simpler than IMAP.)
Would using the ACAP response codes be a good idea?
Thanks,
Tim