Subject: Results of the Working Group Last Call on draft-ietf-sieve-notify-05.txt

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Jan 2007 20:40:00 +0000

Issue #1:

Make tagged "method" parameter positional. (Michael, Dylan are in favor 
of the change).
I would welcome additional opinions on this issue.

Issue #2:

Michael has suggested some changes to the requirement on timestamps. I 
will discuss this offline with Michael and Barry and will suggest some 
new text.

Issue #3:

:subject versa :message. Aaron, Dilyan in favor of adding :subject. 
Michael wants to keep using :message.

Issue #4:

Dilyan suggested to add "expiration" parameter/option to the notify 
action. While I see some utility in this option, I am reluctant to 
extend the document so late in the game, unless there is strong support 
from the WG. I would recommend to add this option in a separate 
document. Opinions?

Issue #5:

Ken (in a private message) has suggested to extend "body" test instead 
of introducing a new "extract_text" test. Opinions?

Issue #6:

Arnt wants to be able to do "send notification over XMPP, if can be 
delivered immediately. Otherwise send it over SMS".
This issue needs further discussion.

Issue #7:

Lisa: controlling who can receive notifications and throttling.

Have I listed all issues raised so far?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Jan 2007 21:42:54 +0000

Alexey Melnikov wrote:

> Issue #1:
>
> Make tagged "method" parameter positional. (Michael, Dylan are in 
> favor of the change).

Mark E. Mallett is also in favor of this change (doesn't feel strongly)

> extend the document so late in the game, unless there is strong 
> support from the WG. I would recommend to add this option in a 
> separate document. Opinions?
>
> Issue #5:
>

Somewhat related to this:
Mark (and I was thinking the same) has suggested to move "extract_text" 
to another document (e.g. MIME loops), as it has applicability beyond 
Sieve notify.

> Have I listed all issues raised so far?

Also, several people including Mark has suggested to rename 
"valid_notif_method" to "valid_notify_method". Unless I hear otherwise, 
I will do that in the next revision.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 21 Jan 2007 14:30:03 +0000

> Mark E. Mallett is also in favor of this change (doesn't feel strongly)

I've done this change now.

>> Michael has suggested some changes to the requirement on timestamps. 
>> I will discuss this offline with Michael and Barry and will suggest 
>> some new text.
>
The updated text reads:
    Notifications SHOULD include timestamps, if the notification method 
allows
    for their transmission outside of the textual message. 
Implementation methods
    which can only transmit timestamps in the textual message MAY 
include them
    in the textual message.

 [...]

>> Lisa: controlling who can receive notifications and throttling.
I've sent some suggested text to the mailing list.

> "valid_notif_method" to "valid_notify_method". Unless I hear 
> otherwise, I will do that in the next revision.

This change is done now.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 27 Jan 2007 17:24:24 +0000

>> Michael wants to keep using :message.
I need to poll people on this, as I don't hear a clear consensus on 
this. Please pick one of the following:

1). keep the existing :message (it may or may not map to email Subject:, 
this is a separate issue at this point)
2). rename existing :message to :subject
3). I don't care whether we have :message or :subject, but we should 
have only one of them.
4). notify should have both :message and :subject

Let me know your opinion or if I've missed some choice.

>> separate document. Opinions?
I've heard a couple of voices for this feature, but no rough consensus yet.

Hint for people who want this functionality: please provide some text 
for inclusion into the document. This will improve your chances of 
winning the argument ;-).

>> Issue #5:
>>
>> Ken (in a private message) has suggested to extend "body" test 
>> instead of introducing a new "extract_text" test. Opinions?
>
In order to make some progress on this issue, here is how the updated 
body test can look like:

   "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM] [BODY-EXTRACT]
                <key-list: string-list>

where BODY-TRANSFORM is defined as (section 4 of 
draft-ietf-sieve-body-05.txt):

          ":raw"
        / ":content" <content-types: string-list>
        / ":text"

I've added BODY-EXTRACT:

    :extract_none /
    :extract_whole /
    :extract_first number

:extract_none is the default, i.e. if the variables extension is 
present, then the match variables ${1}, ${2}, ... are not set as a side 
effect of successful matching;
:extract_first will truncate the current body part after <number> bytes 
and will set the match variables.
:extract_whole will set the match variable, without performing any 
truncation.

>> This issue needs further discussion.
Aaron replied that he likes the idea. Anybody else?

Arnt has suggested that the notify action should take multiple :method 
parameters. As tagged parameters can't be specified multiple times in 
the same test (3028bis, section 2.6), this will mean changing the 
:method parameter to be a string list.

Other alternative are:
1). Add a test to check if a notification method (specified as an URI) 
can deliver the notification immediately.
 IMHO, I like this a bit better than Arnt's proposal, as it is easier to 
implement and the resulting script is going to be easier to read.
2). Keep the existing syntax. A new "stackable" notification method can 
be specified that will perform the desired functionality.

Opinions?
=======
+ A new issues (# 8): the Sieve notify document needs to describe what 
should happen if a parameter specified in two ways in the same notify 
call: as a notify action parameter and as an URI parameter to the method 
parameter, for example:

        notify :method "xmpp:[email-masked]?message;subject=SIEVE" 
:message "You got mail";

(assume for a moment that the content of the :message gets translated 
into the subject of the resulting notification)

Options suggested so far:
1). URI parameters are always ignored
2). URI parameters (if any) override the corresponding notify parameters
3). the notify parameters override the corresponding URI parameters
4). specify both the notify and the URI parameters is an error.

Opinions?

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 29 Jan 2007 14:11:21 -0000

> 3). I don't care whether we have :message or :subject, but we should 

Option 3, or better still, make it a positional argument, ie the last argument.  :o)

> winning the argument ;-).

I'm not interested in this, it sounds like an unnecessary layer of complexity based on the premise that the transport is frequently unreliable.  It sounds to me like a feature more useful on the client that receives the notifications to filter (perhaps using sieve) out the "old" notifications and bin them.

> >> instead of introducing a new "extract_text" test. Opinions?

I agree.

> can deliver the notification immediately.

I have a hesitant preference for a test to check the capabilites of a notification method.  Perhaps a set of variables in a namespace.

> 4). specify both the notify and the URI parameters is an error.

Option 4.  Preferably parse time error.

Nigel