I apologize for the cross-posting, but the theme has
some similarities with discussions that happened in the OPS area and
specifically in NETCONF.
Subscribing to the notifications list is probably the
right way to follow this discussion or even contribute to it.
Dan
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://lisa@psg.com" 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?