Subject: Re: [Notifications] Setting up email event streams

From: Eric Burger <[email-masked]>
Date: Fri, 09 Feb 2007 08:12:34 -0600

I would offer Model B, the user contacts the server directly and provisions
it, is a way to go for now.

First, it is very simple - we do not need to build a protocol today.

Second, it meets the needs of lemonade.

Third, if the market / researchers / industry figures out how to provision
notification filters "in band," (Model A), then it is instantly
backwards-compatible with Model B.

We can always kick-off an IRTF WG on figuring out how Model A would work.

On 1/15/07 3:16 PM, "Lisa Dusseault" <[email-masked]> wrote:

> 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] <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?
>   
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Notifications mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/notifications

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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