Subject: the notify issues

From: Dilyan Palauzov <[email-masked]>
Date: Sat, 27 Jan 2007 22:06:48 +0100

Hello,

> Issue #3: :message vs :subject

I am for
4). notify should have both :message and :subject

> Issue #6
> "send notification over XMPP, if can be delivered immediately.  
> Otherwise send it over SMS"
I am in favour of:

   1). Add a test to check if a notification method (specified
   as an URI) can deliver the notification immediately.

   1)  Add a test to check if a notification method (specified
   as an URI) HAS delieverED the notification immediately.

Expanations: for sending an SMS, or mail it cannot be said if the  
message can be delivered immediately, as it depends on many things,  
and even if a notification can be delivered during the test, this does  
not mean that it is delivered delivered immediately at a later point,  
when the notification is send. On the other side, if an SMS of mail is  
send, an acknowledgement can be requested, that the notification is  
read/delivered. Naturally, this will mean that the interpreter has to  
stop for certain time, like 10s, and wait for the acknowledgement.

   2). Keep the existing syntax. A new "stackable" notification method
   can be specified that will perform the desired functionality.

I do not get what means "stackable notification".

> Issue #4, expire:
Let's add to
Section 3 Notify Action

    Usage:  notify ":method" string
            [":from" string]
            [":importance" <"1" / "2" / "3">]
            [":options" string-list]
            [":message" string]
*          [":expire" number]

* Section 3.7 Notify tag ":expire"
*
*   If there are errors sending the notification, the parameter of the  
:expire tag sets for how long in seconds shall it be retried to  
deliver the notification. If the  notification cannot be delivered  
within the time, it can be discarded. Missing ":expire" leaves up to  
the implementation to set up some reasonable defaults.
*  A value of 0 (zero) means that delivering the message shall not be retried.

And add an example to the current 3.7

-- Does somebody know a standard, or part of it, to specify time  
period, but not date? In this way the seconds can be replaced with  
something easier to write.

# Issue #8, having both content in both :method and :message --
I like:
3). the notify parameters override the corresponding URI parameters
Or
4). specify both the notify and the URI parameters is an error...
... if they lead to generation of different notification.

(it is not an error, if the :message and ?message define the same )

But 3 is more fault-tolerant.

And final suggestion:
    Notifications SHOULD includes means to identify/track its origin, in order
***Notifications SHOULD include  means to          track its origin, in order
    to allow a recipient to stop notifications or find out how to contact the
    sender. This requirement is to help tracking a misconfigured or abusive
    origin of notifications.

Greetings,
    Dilian

---

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

> something easier to write.

See iCalendar:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.3.6

Nigel