Subject: [Notifications] draft on using SIP for email notifications

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 8 Jan 2007 17:49:46 -0800

Hi,

I wrote a draft describing how to extend the message-summary event
package (currently used for MWI) to do sieve notifications.  Until it
appears in the archive, it is here:

http://svn.resiprocate.org/rep/ietf-drafts/rohan/email-event/draft-mahy-sieve-notify-sip-00.html
http://svn.resiprocate.org/rep/ietf-drafts/rohan/email-event/draft-mahy-sieve-notify-sip-00.txt

btw: I do not have a real stake in this discussion.  As author of some
related technology I thought I would enumerate one way to do it.

thanks,
-rohan

_______________________________________________
Notifications mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/notifications

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 15 Jan 2007 15:16:09 -0800

I've been meaning to send this out more broadly after a bit of  
private comment: two quite different models for setting up event  
streams based on what's easier to authenticate -- the event stream  
"owner" (in this case the mailbox owner) or the stream recipient.  I  
hope it helps compare different approaches.

Lisa

---

The goal is to start (and stop) events flowing from an event source  
(in our case, an email server) to the event sink, frequently using a  
system with an explicit event relay.   Because there are often three  
parties required in an event flow , we have to pick some way for the  
three parties to coordinate.

The three parties are the event source (an email server), the event  
sink (a client, perhaps not an email client)  and an event relay.   
The event relay has many users thus it has addresses for each user  
and possibly also addresses for devices/clients.  Two kinds of  
application-layer explicit event relays are starting to be common:  
XMPP and SIP.  For the purposes of considering an event feed setup  
model, we do not want to be concerned about the mostly orthogonal  
issue of what protocol to use to talk to event relay.  So for now we  
assume that event relays have all features common to XMPP and SIP  
(addresses, pub/sub features, event stream aggregation).

Choosing between two event stream setup models requires assumptions  
about
	- what kind of authorization is easier or more important to provide
	- whether there are a lot of different event sink addressess
	- whether direct access to the event source is always/usually  
available (can be affected by whether the event source is publicly  
available)
	- whether event flows stop and start frequently, or can simply be  
turned on for a very long term

MODEL A.  SUBSCRIBE Chain

A-1 Description

In this model, when a user decides to get an email event flow to a  
particular device or piece of software, the user typically works with  
the event sink interface to indicate where to get the events from.   
Then a SUBSCRIBE message of some kind gets generated by the event  
sink, sent to the event relay and is handled by the event source.

A-2 Authorization issue

The authorization problem here is to determine if the address that  
the SUBSCRIBE message comes from is permitted to receive these  
events.  In the case of a publicly-subscribable resource this problem  
disappears.  In many email use cases, only a small number of event  
sink addresses will be authorized to receive event notifications --  
perhaps the event source (the email server) can simply be configured  
with a short allowed list of event recipients that doesn't change  
often (e.g. my personal IM address, my work address, and the one used  
by my phone provided by my phone service provider).

Some SUBSCRIBE systems have the ability to provide a PENDING response  
to a subscription.  This is used when an out-of-band mechanism is  
initiated to authorize the subscribing address.  In an email event  
source use case, one obvious out-of-band mechanism is for the email  
server to create an email with a link saying "Click here to authorize  
this subscription".

It's also possible to use a mechanism like URLAUTH to prove  
authorization -- in this approach, the subscriber provides a URL that  
has a secret token in it authorizing the subscription.  It's possible  
that this would authorize the subscribing address for future  
subscriptions as well, or only for a limited period.

A-3 Drawbacks:
    a)  Only some notification protocols support SUBSCRIBE semantics.

    b)  Complicated filters and event types (to support use cases  
like "Alert me on event type 'email arrives' if it is from my boss,  
has my full email address or the address of the developer list on the  
to line, and the subject does not begin with 'FUNNY'..." )  might  
need a little extra work.  Both SIP and XMPP subscriptions can be  
extended in such a way that existing notification relays would pass  
on a filter specification in whatever language/format most  
appropriate for email.  It might even be possible to send SIEVE  
conditionals in the body of the SUBSCRIBE message.  XMPP has  
notification nodes in XEP-0060 and notification filters in XEP-0163.

A-4 Advantages
    b) Allows for frequent starting and stopping of subscriptions,  
possibly an efficiency/scaling concern

MODEL B. Sender RULES

B-1 Description

In this model, the user typically works with the event source in  
order to configure it to send events to a given set of addresses.   
For example, the user might have access to a Web interface to an  
email server where it can say "Send new message notifications to  
xmpp://[email-masked]" or someday use MANAGESIEVE.

B-2 Authorization issue

The authorization problem here is to determine if the user creating  
the sending rule is authorized to send an event stream to the  
receiving address.  If anybody can send to the receiving address  
(e.g. email) then it's publicly addressable and the problem  
disappears.  Many kinds of addresses are publicly addressable and use  
whitelisting together with asking permission ("do you wish to allow  
messages from this source in the future").

B-3 Drawbacks:
    a) Only some event sources support RULE systems.  We are building  
SIEVE for email clients and servers but it may be harder to  
generalize this beyond email clients and servers.  Even sticking  
strictly the proposed scope of email server sources, we have to  
consider whether a client such as a calendar client (subscribing for  
IMIP messages) or a time-management dashboard (subscribes to "unread"  
counts but doesn't otherwise read email) are going to be able to  
implement SIEVE, authenticate to mail servers etc.

    b) If sender rules are setup through Web interfaces, users are  
definitely not going to turn them on and off frequently.

    c) Failure feedback: how does the event source let the user know  
that some address keeps bouncing?