Robert Burrell Donkin wrote:
On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <stephan(_at_)rename-it(_dot_)nl>
wrote:
<snip>
Ok, I did some preliminary implementation of the new commands. Regarding the
NOOP command I have only one (nitpicking) remark. The managesieve
specification explicitly lists which commands are valid before
authentication. However, by introducing extensions this becomes a little
more sketchy. The RENAMESCRIPT command is clearly not useful before
authentication. However, implementors with IMAP experience might think of
allowing NOOP before authentication, because in IMAP the NOOP command may
be issued before authentication.
failing to allow NOOP as may be expected violates the principle of
least surprise.
is there any reason for this?
in general, this protocol seems more than a little peculiar. it's
close in syntax to IMAP but has enough differences for IMAP
implementors to be surprised and confused by the differences.
is there any reason for this choice?
The protocol is trying to stay backward compatible with CMU
implementation (and there are many other client and server
implementations that mimic it).
If I were to design a new protocol from scratch, I would have made it as
similar to IMAP as possible. But due to existing deployments, I don't
think this would be a good option.