Thanks for the review and comments, Stephan, and for the interest in
implementing this.
I hope I'm still somewhat on time with the following small comments:
Late is fine, when the comments are useful. :-)
I'm about to upload an -06 version with the following changes.
*) In Section 2.1, the syntax of the new IMAP capability is described. It
includes a sieveurl-server syntax item. Although I expect anyone on this
list to know what it is for, I think it would be good to mention explicitly
that it points to the ManageSieve server the client needs to contact for
managing Sieve scripts.
I have added a new sentence to the end of this paragraph:
Only one "imapsieve" capability string, specifying one sieveurl-
server, can be present. The sieveurl-server identifies the
ManageSieve server that clients need to contact for managing Sieve
scripts associated with this IMAP server.
*) I wonder what happens if the fileinto action points to the mailbox the
message currently resides in (call it the 'source mailbox'). Does it match
'keep' behavior in that special case, or will it just create a copy of the
message in the source mailbox (potentially dropping the original)? Current
text suggests the latter and that is also what I prefer: I'd like to be able
to create a new version of the message in the same mailbox. I think it would
be good to mention this special situation explicitly either way.
I have added a new sentence to the end of this paragraph:
For APPEND, MULTIAPPEND, and COPY, the message is stored into the
fileinto mailbox IN ADDITION TO the original target mailbox. For
flag changes, the message is COPIED into the fileinto mailbox,
without removing the original. In all cases, fileinto always creates
a new message, separate from the original.
Barry
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve