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

[Alexey Melnikov <alexey.melnikov@xxxxxxxxx>]

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.