[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
On Mon, Dec 18, 2006, Alexey Melnikov <alexey.melnikov@xxxxxxxxx> 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]
>>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.
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.
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:
[":importance" <"1" / "2" / "3">]
Basically that breaks every extant implementation, doesn't it.