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.
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 ;-).
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.
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.
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:tim(_at_)example(_dot_)com?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?