Stephan Bosch wrote:
Hi Alexey,
Hi Stephan,
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.
Right. Description in -08 was an error on my part. As far as I am aware
the ManageSieve protocol never allowed + to be optional.
Now it is explicitly required from the clients, making such clients
fail (if they indeed exist, let's hope not).
If such broken clients exist, I hope that they would be found and fixed.
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.
Good point. I will clarify that.
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.
Fixed, thanks.