On Jul 7, 2008, at 12:27 PM, Robert Burrell Donkin wrote:
On Mon, Jul 7, 2008 at 1:18 PM, Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote:Robert Burrell Donkin wrote:On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <stephan@xxxxxxxxxxxx> wrote: <snip>Ok, I did some preliminary implementation of the new commands. Regardingthe NOOP command I have only one (nitpicking) remark. The managesieve specification explicitly lists which commands are valid beforeauthentication. However, by introducing extensions this becomes a littlemore sketchy. The RENAMESCRIPT command is clearly not useful beforeauthentication. However, implementors with IMAP experience might think of allowing NOOP before authentication, because in IMAP the NOOP commandmay 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 thinkthis would be a good option.i can see that's a tough choice: codification of existing (possibly dubious but at least well understood) practice verses the creation of a better protocol
Documenting what exists is the limit of what we can do with this document. The protocol itself is already implemented by several servers and clients and has good interoperability*. We need to freeze the current state and call it "version 1" before we start working on version 2.
* actually, I need to compare my implementation with the document that's been posted, because I recall at least two things that I followed drafts on but clients did not like, one was about response codes and another was about {number+} vs. {number}, but I don't remember exactly when and what those interop problems were. I do know that the clients in question changed to accommodate my server and not vice versa, because I was following the draft spec and they agreed.
Other server implementations I know about: managesieve in dbmail (I wrote this one): https://svn.ic-s.nl/svn/dbmail/trunk/dbmail/src/timsieve.c managesieve for dovecot: http://sinas.rename-it.nl/~sirius/ managesieve in citadel: www.citadel.org
it seems unfortunate that this means that a separate port is required for sieve management. a compatible extension to IMAP would allow sieve management using the same URI.
It's entirely possible that this is the future of sieve script management. I, for one, would really like to see sieve scripts exposed through some namespace within folder annotations. There are problems with that, though, and it's not going to be implemented everywhere tomorrow, if at all. So we need to finish documenting what we have that works for now.
Aaron