I have a couple comments on Alexey's comments. I don't think I've
read the draft in detail, so please pardon my ignorance.
Alexey Melnikov <mel(_at_)messagingdirect(_dot_)com> writes:
The service name specified by this protocol's profile of SASL is
"imap" since implementations are generally tied to an IMAP
installation.
I object because the service name is an element used in several SASL
mechanisms (at least KERBEROS_V4, GSSAPI & DIGEST-MD5)
I object as well. The service name matters.
[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.
I don't see the case of "backward compatibility" for the protocol. The
situation is different from POP3/IMAP4 where PLAIN is widely deployed.
Backwards compatibility is an issue. If a system is authenticating
against a Unix passwd database, plaintext is the only thing that
works.
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.
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.)
Tim