Re: Updated Sieve notification draft

["Nigel Swinson" <[e-mail]>]

> I took a stab at updating draft-martin-sieve-notify-01.txt, which should 
> be published soon as draft-ietf-sieve-notify-00.txt. The document is 
> attached.
> 
> The two major changes are:
> 1). updated the document to reference Sieve variables. Some notification 
> variables line "$text$" can't be mapped directly, but I will send a 
> separate message on this.
> 2). changed the document to use notification URIs, e.g. "sms:[phone]"
> 
> I remember there was a discussion few months ago about defining a 
> separate SMS notification mechanism. I just want to let people know that 
> the update I've made doesn't prevent any other documents in this area. 
> Just treat it as an input for discussion.

Abstract:
    This draft describes an extension to the Sieve mail filtering
    language that allows users to give specific preferences for
-    notification of Sieve actions.
+   notification of mail delivery.

That sounds like the extension allows you to be notified about an action, rather than a message.  I thought the significant event was the delivery of mail rather than a sieve action.  Similar comments apply to Introduction section.

    This document does not dictate the notification method used.
    Examples of possible notification methods are Zephyr and Jabber. The
-    method shall be site-defined.
+    available methods shall be site-defined.

Which makes me wonder if each desired "method" should really be available via a require command?

3.1 Notify Action
    In
    addition, if the notification method does not provide a timestamp,
    one SHOULD be appended to the notification.

Why bother with this?  While I agree it might be a sensible idea, I was surprised to see it as a SHOULD, I guess it's not a MUST though :o/

    If, for example, the user marks
    herself as "busy", an implementation SHOULD NOT send a notification
    for a new mailing list message with a priority of :low

This makes it sound like there are hard and fast rules between user status notifications and the setting of the priority parameter, yet the discussion is very brief and doesn't elaborate to rigorously define all those rules.  I also feel uneasy about adding syntax that permits only 3 levels of priority.   I think we should either drop the parameter, or extend it to allow an almost arbitrary number and style of priority statuses, even if we only define 3 for now.  I'm thinking of the Priority/X-Priority/X-MSMail-Priority mess in mail headers.  I'd suggest a string which could be used with the relational draft to do numeric comparisons if desired.

    If the message parameter is absent, a default message
    containing the value of the From header field and the value of the
    Subject header field will be used.

Could this be specific to the notification mechanism in use?  And can it just be left to be implementation specific?  The use of "will be" instead of SHOULD/MUST makes this sentence pretty ignorable anyway.  As it stands it doesn't seem to want me to include as much of the message body as I can, which is clearly a nice feature.

    <<Open issue: the previous version of this draft has defined the two
      variables that can't be currently represented:

         $text$     - the first text/* part

         $text[n]$  - the first n bytes of the first text/* part
    >>

I'd like to drop both of these, and wait for other extensions used with VARIABLES to allow the behaviour.  The syntax of the above doesn't sit well with VARIABLES.

-    The denotify action can be used to cancel a previous notification.
+    The denotify action can be used to cancel previous notifications.

5.  Security Consideration

Is there additional risk of mail loops when using this extension?

Cheers

Nigel