Notification Explosion

1
Notification Explosion

• Calendaring
• You have a new meeting request
• Your meeting begins in 15 minutes
• SIP
• Hello
• HTTP/WebDAV
• A resource you want to edit is now unlocked
• A resource you frequently view just changed

• XMPP
• Presence info
• Instant messages
• Email
• New mail
• News
• New postings
• Voice (unified) messaging
• New message

2
A notification aggregator combines event sources
VoiceMsgs
Email
HTTP
Presence
Presence
WebDAV
Calendar
RSS
?
SIP
XMPP
?
?
Notification Aggregator

• Client device cannot keep persistent connections
  (or poll) to all these event sources
• Client device does not know all protocols
  involved

• One persistent or frequent connection

3
A notification aggregator aggregates client
devices
Notifications

• The notification aggregator knows
• Which devices are online
• Which device is most in use at this moment
• Which device wants which notification (by
  subscription? By profile?)

Notification Aggregator
SIP
XMPP

• User can switch devices without rearranging with
  all event sources

4
What to do?

• See if we can identify problems
• See if some of them are easy to solve
• Keep larger architecture in mind

5
Model

• A resource generates events
• Requirement Use URIs for universality
• Event types depend on resource type.
• Need extensible event types
• Are application types needed? Sub-types? Event
  sub-information
• A subscriber requests events based on resource
  and type
• Requirement Use URI to identify subscriber too
• ldap//ldap.example.com/cnAlice20Wetherill?
• Alice.wetherill_at_mail.example.com?

6
Discovery Problems

• User
• I want to subscribe to http//example.com/my.doc
• Aggregator
• What protocol do I need to use to subscribe to
  this resource?
• What events can it offer?
• What ID do I use to identify the user?
• Source
• Is the user allowed to see resources and events?

Source

• SNAP, SIP

Notification Aggregator

• XMPP, SIP

7
Discovery Requirements protocol choice

• Given a URL, need to know how to connect to
  remote server.
• Problem familiar URLs are not notification URLs
• e.g. Web resources, email boxes, calendars
• Ideally need integration into content systems
• e.g. OPTIONS request to Web URL to see what
  notification protocol it supports ? use that
  protocol
• Or RSS feed information inside the body of Web
  resource
• Other URLs are easier
• Xmpp//lisa_at_example.com ? use XMPP

8
Search, resource listings

• A URL might point to a collection of notification
  resources
• How to ask a server what notification source
  resources it has
• E.g. XMPP DISCO
• WebDAV PROPFIND
• List of voice message mailboxes generating events
• LDAP could identify a users various notification
  sources (their calendar, email and voice mailbox)
• How to display these resources when user browses
  them
• Eventually, search capability

9
Discovery requirements finding events

• Once aggregator knows protocol
• Connect using protocol
• Requirement Provide user authorization
• Query event types
• Return to user to select event type
• Requirement Event source resource must offer a
  way to query event types.
• Event types should be protocol-agnostic, e.g.
  QNames
• ltpresence xmlnsurnietfwgxmpp/gt
• ltunlock xmlnsDAV/gt

10
Subscribe Requirements

• We already know what protocol to use, what
  resource to address
• And user chose what event to get
• Does a subscription need to be signed or just
  authenticated?
• Is access control based on LDAP identity or
  something else?
• Requirement source server must know subscriber
  identity and return address.
• For access control
• So events can be routed
• For auditing, etc.

11
Notification Requirements

• Notification contains context
• Event source URL, event type, subscriber URL
• Subscription ID?
• Does notification include pointer to information
  or all information? Probably either.
• Notification is signed
• Message Encryption could be used
• Everything else can be encrypted with users
  public key
• Subscriber URL and subscription ID must be
  readable by aggregator

12
Notification Requirements

• End-to-end security must be possible
• See XMPP solution message payload is encrypted
  end-to-end
• When payload is encrypted end-to-end, envelope
  must contain only necessary delivery information
• Problem how to determine whether end recipient
  can handle format of encrypted payload. E.g. SIP
  agent sends encrypted payload through bilingual
  aggregator, can XMPP recipient handle it?

13
Routing/Scalability requirements

• Scaling a very large notification system could be
  difficult. Some kind of routing via aggregation
  servers is required.
• XMPP/mail routing, could be made minimum standard
• SIP routing is an elaboration which is compatible?

psg.com
Sender always starts with own agg. server
Final delivery by username
Next hop specified in recipient address, as in
mail routing, possibly using persistent connection
romeo
To romeo_at_psg.com
14
Routing/Scalability requirements

• What if more scaling/routing is required? Can be
  added dynamically or configured.

Proxy is configured to route to destination server
First hop is configured to send certain addresses
to a proxy.
psg.com
Final delivery is the same
Sender does the same thing
Persistent connections?
romeo
To romeo_at_psg.com
15
Gatewaying
SIP request
XMPP stanza
Commoneventdata
Commoneventdata
16
Layering is good

• How to make gatewaying easier
• If you cant layer you must make everything
  translatable
• And then end-to-end encryption doesnt work
• Transport layer independence
• Layerable subscription request to cross
  transports
• Layerable event notification to cross transports
• Layerable discovery (resources, events) info

17
Reading material

• XMPP core
• JEP-60 Pub/sub
• JEP-30 Discovery
• GENA?

18
Alternate Model
VoiceMsgs
Email
HTTP
Presence
Presence
WebDAV
Calendar
RSS
?
SIP
XMPP
?
?
Subscription Manager
Stores list of servers, events