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 –New mail News –New postings Voice (unified) messaging –New message

A notification aggregator combines event sources Notification Aggregator Voice Msgs HTTPPresence 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 WebDAV SIPXMPP ? RSS? ? Calendar

A notification aggregator aggregates client devices Notifications Notification Aggregator 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?) XMPP SIP User can switch devices without rearranging with all event sources

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

Model A resource generates events –Implies: 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 –Implies: Use URI to identify subscriber too –ldap://ldap.example.com/cn=Alice%20Wetherill?

Discovery Problems User: –I want to subscribe to 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? Notification Aggregator XMPP, SIP… SNAP, SIP… Source

Discovery 1 st step: 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, 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 use XMPP

Search, resource listings A URI 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, and voice mailbox) Implies: Request to list event servers resources Implies: Eventually, search capability too

Discovery requirements: finding events Once aggregator knows protocol –Connect using protocol, what do you have permission to see –Implies: Provide user authorization on discovery Query event types –Return to user to select event type –Implies: Event source resource must offer a way to query event types. Event types should be protocol-agnostic, e.g. QNames

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? Implies: source server must know subscriber identity and return address. –For access control –So events can be routed –For auditing, etc. Are global subscription IDs needed?

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. Non-repudiation: did event really happen –Implies: Notification may be signed –Implies: Message Encryption could be used In notification with encryption: –Payload can be encrypted with key known to subscriber –Subscriber URL and subscription ID must be readable by aggregator

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

A bit of reading material This presentation – Server-to-server requirements rough draft – Some history: – SIP Notification: – XMPP core – –JEP-60: Pub/sub –JEP-30: Discovery HTTP/WebDAV events: –

Alternate Model Voice Msgs HTTPPresence WebDAV SIPXMPP ? RSS? ? Calendar Subscription Manager Stores list of servers, events…