[Top] [All Lists]

Re: Treat as a WGLC: draft-martin-managesieve-10.txt

2008-07-07 01:36:57

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.


Stephan Bosch