Hi Alexey,
Alexey Melnikov wrote:
I thought the idea was to simply allow and ignore the '+' for legacy
implementations.
ManageSieve was largely documenting Cyrus timsieved and timsieved
never emitted "+" to clients.
If you know any server that emits non-synchronizing literals to
clients, please let me know. But absent any evidence that this would
break deployed servers, I would prefer to keep consistency with IMAP
and timsieved.
Ok, if I encounter any in the near future I will notify you.
Strictly requiring it from clients seems cumbersome and will, to my
opinion,
likely introduce even more incompatibilities.
As far as I know ManageSieve never allowed clients to send
synchronizing literals (literals without +). timsieved allows for that
(because it reuses IMAP parser), but I don't think it ever emits IMAP
style "+ go ahead" back to clients. So it is not consistent with IMAP
either.
If people think that support for synchronizing literals in the
direction from the client to the server is needed, I can add that. But
I am not convinced that this is a problem either.
I am not so much interested in the (IMAP) synchronizing semantics of the
'+' character. With version 08 of the managesieve specification the '+'
character was indicated as 'only allowed from clients' in the comment
somewhere in the ABNF. I am worried that some client implementors have
interpreted this as being optional and decided to drop the '+'
altogether. Now it is explicitly required from the clients, making such
clients fail (if they indeed exist, let's hope not).
I do like the new extensions you introduced. :) I'll thoroughly read the
new document in a few days to update my ManageSieve implementation.
Sounds good to me :-).
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. I think it cannot hurt to
make explicit whether these new commands may be issued before
authentication.
Other than that, I found a typo in section 1.3 in the TRYLATER
explanation: 'This response code only make sense when returned in a
NO/BYE response.'. You should add an 's' there somewhere.
Regards,
--
Stephan Bosch
stephan(_at_)rename-it(_dot_)nl