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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 01 Feb 2007 19:16:23 +0000

Hi folks,
Quick summary of comments received so far below:

Alexey Melnikov wrote:

> Alexey Melnikov wrote:
>
>>> Issue #3:
>>>
>>> :subject versa :message. Aaron, Dilyan in favor of adding :subject. 
>>> 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.

My reading of the rough consensus so far is to keep :message (no change 
to the draft).

>>> 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?
>>
> 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 ;-).

Even though specific text was suggested for inclusion, my reading of the 
rough consensus is that there is no support for adding this feature to 
the base Sieve notify document.

>>> 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:

It sounds like people would prefer to extend the body test, rather than 
introducing a new action.
However people are not entirely sure about the new syntax I've suggested.

I think there is agreement to move this part of the document somewhere 
else, like Sieve MIME loops. So the WG should continue discussing the 
best syntax for this test or action, but this open issue is not blocking 
publication of the Sieve notify document.

>   "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.
>
>>> 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.
>>
> 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.

Consensus seems to be to go with option #1.

> 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.

I don't see any consensus on this issue so far. More discussion/opinions 
needed.

> Opinions?

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 4 Feb 2007 14:17:21 +0100

Alexey Melnikov writes:
>> 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.

Fine with me. There is a bit of complexity or even a race condition 
("can deliver at the time of the test" vs. "can deliver at the time of 
the notify execution"), but I don't think it's serious. (If we worry 
about that, we'd better worry something much bigger: what happens if 
the notification is dislayed, but not seen because the screensaver 
kicks in 0.02 seconds later, or the user logs out 0.04 seconds later, 
or the mobile device runs out of power and dies 0.01 seconds later.)

Arnt