Timothy Martin <tmartin(_at_)andrew(_dot_)cmu(_dot_)edu> writes:
[SASL-ANON]. SASL mechanisms which use plaintext passwords [..]
This paragraph seems to be unnecessary. [...]
Agreed. I'm not sure why I didn't listen to you the first time :)
I said that before? At least I'm consistant.
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.
HAVESPACE can also reserve the space. It moves the burden of doing so
elsewhere, which may not be the best thing to do.
But the command still has to be able to fail. What makes you think
that write(2) is going to succeed anyway, even if you've got the
space?
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?
They're probably the best thing going. They had several advantages
over IMAP with no real additional cost.
By the way, if you're not already using quoted strings for response
text, please consider that, too. It makes tokenization easier.
Tim