headers
Kjetil Torgrim Homme | 1 Feb 2006 13:19
Picon
Picon

Re: Imapflags "hasflag" test interaction with relational draft


On Tue, 2006-01-31 at 13:45 -0500, Mark E. Mallett wrote:
> Relational says:
> 
>   The COUNT match type SHOULD only be used with numeric comparators.
> 
> which is quite different from saying that a different comparator should
> be defaulted when using :count .  I think that trying to induce
> different default comparators depending on combination of options opens
> up a can of worms; i.e. I would agree that the default comparator should
> not depend on the match type.

I agree.  changing the default comparator to numeric for "count" would
make just as much sense with every other match type, but it's too late
to do that now even if it was a good idea (I haven't thought it
through).

I think the hasflag test in "imapflags" should be extended to allow an
optional comparator, for consistency with other match types.  since the
default comparator is the same as for the rest of Sieve, this fits
nicely.
--

-- 
Kjetil T.
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 Feb 2006 00:50
Picon
Favicon

I-D ACTION:draft-ietf-sieve-vacation-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering:  Vacation Extension
	Author(s)	: T. Showalter, N. Freed
	Filename	: draft-ietf-sieve-vacation-06.txt
	Pages		: 17
	Date		: 2006-2-2
	
This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-06.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-vacation-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 Feb 2006 00:50
Picon
Favicon

I-D ACTION:draft-ietf-sieve-imapflags-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: SIEVE Email Filtering: IMAP flag Extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sieve-imapflags-04.txt
	Pages		: 0
	Date		: 2006-2-2
	
Recent discussions have shown that it is desirable to set different
   [IMAP] flags on message delivery.  This can be done, for example,
   by a Sieve interpreter that works as a part of a Mail Delivery
   Agent.

   This document describes an extension to the Sieve mail filtering
   language for setting [IMAP] flags. The extension allows to set both
   [IMAP] system flags and [IMAP] keywords.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-imapflags-04.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 5 Feb 2006 19:46
Favicon

Re: Last Call: 'Internet Application Protocol Collation Registry' to Proposed Standard


Hi folks,
I would like to call to your attention that 
draft-newman-i18n-comparator-06.txt is currently in IETF-wide Last Call. 
As this draft is an important dependency for the base Sieve document, I 
would like to request people to review it before March 3rd 2006.

The IESG wrote:

>The IESG has received a request from an individual submitter to consider the 
>following document:
>
>- 'Internet Application Protocol Collation Registry '
>   <draft-newman-i18n-comparator-06.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2006-03-03.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-06.txt
>
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 6 Feb 2006 21:50
Picon
Favicon

I-D ACTION:draft-ietf-sieve-notify-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Extension: Notifications
	Author(s)	: A. Melnikov, et al.
	Filename	: draft-ietf-sieve-notify-02.txt
	Pages		: 17
	Date		: 2006-2-6
	
Users go to great lengths to be notified as quickly as possible that
   they have received new mail.  Most of these methods involve polling
   to check for new messages periodically.  A push method handled by the
   final delivery agent gives users quicker notifications and saves
   server resources.  This document does not specify the notification
   method but is expected that using existing instant messaging
   infrastructure such as Zephyr, Jabber, or SMS messages will be
   popular.  This draft describes an extension to the Sieve mail
   filtering language that allows users to give specific rules for how
   and when notifications should be sent.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
(Continue reading)

Permalink | Reply | 11 comments |
headers
The IESG | 6 Feb 2006 23:07
Picon
Favicon

Protocol Action: 'Sieve Email Filtering: Vacation Extension' to Proposed Standard


The IESG has approved the following document:

- 'Sieve Email Filtering: Vacation Extension '
   <draft-ietf-sieve-vacation-06.txt> as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working 
Group. 

The IESG contact persons are Scott Hollenbeck and Ted Hardie.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-06.txt

Technical Summary

The Sieve vacation extension implements a vacation autoresponder similar to 
the vacation command available under many versions of Unix.  Its purpose is 
to provide correspondents with notification that the user is away for an 
extended period of time and that they should not expect quick responses.

The extension defines a vacation action with parameters that allow 
customization of the response. It goes into detail about how the 
auto-response should be handled, with particular emphasis to tracking 
previous vacation messages sent to correspondents to avoid duplicates, and 
to how the response message itself should be constructed.

The draft has a description of how interactions with other SIEVE 
extensions/actions are handled.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark E. Mallett | 6 Feb 2006 23:22

Re: IESG Review of draft-ietf-sieve-vacation


On Tue, Jan 24, 2006 at 07:46:39PM -0500, Cyrus Daboo wrote:
> Hi Scott,
> 
> --On January 19, 2006 1:46:00 PM -0500 Scott Hollenbeck 
> <sah <at> 428cobrajet.net> wrote:
> 
> >Thanks for the note, Ned.  It leads me to two more specific questions:
> >
> >Does the document need to describe the issues noted below in an
> >Internationalization Considerations section?  It might make sense.
> 
> My feeling is that what Ned described would be better off being put in the 
> base spec revision rather than vacation, since its is applicable to base 
> spec actions and other extensions too. i.e. we don't need to add this 
> directly to vacation itself.
> 
> What do others on the list think?

I would have agreed with you, but the text in the latest (-06) draft
looks good too.  The only typo I noted:

7.

   > The Sieve language itself allows a vacation response to selected
   > based on the content of the original message.

needs a "be" -- "to be selected" (not "to selected")

Yours,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ned Freed | 7 Feb 2006 00:30

Re: IESG Review of draft-ietf-sieve-vacation


> I would have agreed with you, but the text in the latest (-06) draft
> looks good too.

FWIW, I think the addition of an internationalization considerations section
to the base spec also makes sense. The one I wrote only deals with issues
specific to vacation (and maybe refuse and notify).

  The only typo I noted:

> 7.

>    > The Sieve language itself allows a vacation response to selected
>    > based on the content of the original message.

> needs a "be" -- "to be selected" (not "to selected")

Thanks for the catch - Kristin Hubner also pointed this out in private
email. Unfortunately I made the change to the XML but then forgot to rerun
xml2rfc one last time before submission. I'll fix it during auth48.

				Ned
Permalink | Reply | 0 comments |
headers
Michael Haardt | 7 Feb 2006 12:05
Picon

Re: I-D ACTION:draft-ietf-sieve-notify-02.txt


First of all, please add a Changelog.

   However, all content specified in the notify action SHOULD be
   included.  It is RECOMMENDED that a timestamp be included in the
   notification.

Do we really need SHOULD and RECOMMENDED? If a method can not implement
the above for technical reasons, of course that qualifies as reason to
violate the SHOULD.  But isn't it silly to set a strong default, knowing
it will be violated?

I recommend that each method MUST define if specified content is not
included in the notification and if it includes a timestamp.  Do we
define anywhere that this timestamp should be as close to the delivery
as possible?

   If there are errors sending the notification, the Sieve interpreter
   SHOULD ignore the notification and not retry indefinitely.
   [[Barry 4: Does this really belong here?  Shouldn't we push the
   question of error recovery to the individual methods?]]

I think defining the default behaviour is useful, but again I question
the "SHOULD".  How about "should" and saying that each method MUST define
how error recovery works?

                  The entirety of the string SHOULD be sent but
   implementations MAY shorten the message for technical or aesthetic
   reasons.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Alexandros Vellis | 7 Feb 2006 14:11
Picon

Re: I-D ACTION:draft-ietf-sieve-notify-02.txt


[Cc: ing notifications list]

On Tue, 2006-02-07 at 12:05 +0100, Michael Haardt wrote:

> I suggest that allowed modifications MUST or at least SHOULD be
> documented.
> 
>    Usage:  valid_notif_method <notification-uris: string-list>
> 
> Of course that is real easy to implement, but it is also real ugly.
> There is nothing I know of else in Sieve that checks certain options
> of actions for validity.  I still suggest a generic extension for
> exception handling.

I don't know about generic exception handling, but wouldn't it make more
sense, in this particular case, that the available notifications are
present in the capabilities of the Sieve server?

So, just as IMAP4 Capability responds with a set such as AUTH=DIGEST-MD5
AUTH=ANONYMOUS or THREAD=ORDEREDSUBJECT THREAD=REFERENCES, a Sieve
server could respond with "notify notifymethod=mailto
notifymethod=xmpp", or something similar.

For a client implementation that has no idea what is suppored on the
server, this would be ideal. It will also save my client implementation
from an extra configuration option. :)

> Since we broke compatibility with the original draft, I repeat my
> point of view to remove ":method" and change its argument to an
(Continue reading)

Permalink | Reply | 8 comments |

Gmane