headers
Stephan Bosch | 9 Jul 2012 10:34
Picon

Re: WGLC: draft-ietf-sieve-imap-sieve-04.txt

On 5/30/2012 10:30 PM, Cyrus Daboo wrote:
> Hi folks,
> I am starting a working group last call on 
> draft-ietf-sieve-imap-sieve-04.txt. This is the last document this 
> working group has on its plate and once finished, we intend to shut 
> down the working group.
>
> The last call on draft-ietf-sieve-imap-sieve-04.txt will run for two 
> weeks. Please review this draft and send comments to the list. This 
> document has been around for a while, so if you have done a detailed 
> review before, just checking the changes now should be sufficient. In 
> any case, the chairs want to heard from everyone who has done a review 
> and those who have decided for or against doing an implementation of 
> this in the near future.
>

I hope I'm still somewhat on time with the following small comments:

*) 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 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Cyrus Daboo | 9 Jul 2012 16:07
Favicon

Re: WGLC: draft-ietf-sieve-imap-sieve-04.txt

Hi Stephan,

--On July 9, 2012 10:34:43 AM +0200 Stephan Bosch <stephan <at> rename-it.nl> 
wrote:

> I hope I'm still somewhat on time with the following small comments:
>
> *) 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 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.
>
> Overall, I really like the quality of this specification. Once our IMAP
> server gains the required METADATA support I intend to implement this
> extension.

Thanks for the feedback. I'll leave Barry to address these points now if he 
wishes. However, I am in the process of putting together a write-up for 
this document so we can move forward with processing it. So we might wait 
until after IETF last call to address your issues in a new draft, depending
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barry Leiba | 14 Jul 2012 22:11
Picon
Favicon
Gravatar

Re: WGLC: draft-ietf-sieve-imap-sieve-04.txt

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:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephan Bosch | 15 Jul 2012 01:29
Picon

Re: WGLC: draft-ietf-sieve-imap-sieve-04.txt

On 7/14/2012 10:11 PM, Barry Leiba wrote:
>> *) 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.

Agreed.

>> *) 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aaron Stone | 23 Jul 2012 20:10
Gravatar

Unicode regular expressions

http://www.unicode.org/reports/tr18/tr18-15.html

Unicode Technical Standard #18, Unicode Regular Expressions, just got
a new draft in July 2012; the previous draft was done in 2008. Who's
ready to update our own Regex draft?

*ducks*

Aaron
_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 0 comments |

Gmane