On Mon, Dec 18, 2006, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> said:
Michael Haardt wrote:
Optional tagged arguments can appear in any order, but they must appear
before positional arguments.
So if we switch to make the method argument positional, the usage
statement needs to be modified to become:
Usage: notify
[":from" string]
[":importance" <"1" / "2" / "3">]
[":options" string-list]
[":message" string]
string
If you write it as
<method: string>
it looks much better.
I agree.
But should this start a lengthy discussion
in the group, then never mind.
I would like to hear at least two other opinions in favor of keeping or
changing the current behavior.
I apologize for not being on top of this 1-2 months ago. This is so much
different than Vacation as to cause unreasonable confusion on the part of
end-users writing their own scripts. It is also different in xmpp vs.
mail.
From draft-ietf-sieve-notify-mailto-01:
o The "Subject:" field of the notification message contains the
value defined by the :message notify tag, as described in
[Notify]. If there is no :message tag, the subject is retained
from the triggering message. Note that Sieve [Variables] can be
used to advantage here, as shown in the example in Section 3.
Presumably the body would be [MAY be?] empty.
From draft-ietf-sieve-notify-xmpp-02:
o The XMPP <message/> stanza MAY include a <subject/> child element
whose value is some configurable text indicating that the message
is a Sieve notification.
I recognize that the point of notifications is to provide "one-liner"
updates, but giving different names to the subject and body fields isn't
good, and then using the subject/body distinction present in xmpp vs. mail
in opposite ways isn't good, either.
I'm definitely bringing up more than a WGLC should. Oops.
If instead we had:
Usage: notify
[":from" string]
[":importance" <"1" / "2" / "3">]
[":options" string-list]
[":subject" string]
[":message" string]
"method:" string
Basically that breaks every extant implementation, doesn't it.
Aaron