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've submitted version 10 of the ManageSieve draft. I believe it
> > addresses all major issues with the document. I would like to request
> > publication of this document shortly.
> >
> > Because Sieve WG hasn't rechartered yet, I can't request a formal WGLC
> > on the document. However I would like to ask people to treat my
> > request as a WGLC.
> > Please send me your comments by July 7th.
> >    
> I've quickly scanned through the new document and the way the '+' issue
> is resolved for the string literals worries me. If I am not mistaken,
> the new specification requires the '+' from the client and prohibits it
> from the server. If I remember correctly, the '+' was required both ways
> in old versions of this draft and you decided to remove it to make
> things more logical compared to the similar IMAP string literal and to
> match the existing timsieved implementation.
Yes.

> 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.

> 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.

> Is there a specific reason to implement it this way? Sorry that I missed
> version 09 of this document, but I did not actively check for new
> versions and I didn't see it posted on this list.
>
> 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 :-).