Notification Explosion Calendaring You have a new meeting

Notification Explosion • Calendaring – You have a new meeting request – Your meeting begins in 15 minutes • SIP – “Hello” • HTTP/Web. DAV – 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

A notification aggregator combines event sources Voice Msgs Email ? HTTP ? RSS Presence XMPP Notification Aggregator • One persistent or frequent connection SIP Web. DAV Calendar ? • Client device cannot keep persistent connections (or poll) to all these event sources • Client device does not know all protocols involved

A notification aggregator aggregates client devices Notifications The notification aggregator knows: • Which devices are online Notification Aggregator SIP XMPP • Which device is most “in use” at this moment • Which device wants which notification (by subscription? By profile? ) • 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 subinformation • A subscriber requests events based on resource and type – Implies: Use URI to identify subscriber too – ldap: //ldap. example. com/cn=Alice%20 Wetherill? – Alice. wetherill@mail. example. com?

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

Discovery 1 st step: protocol choice • Given a URL, need to know how to connect to remote server. • Problem: familiar URLs are 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@example. com 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 Web. DAV PROPFIND List of voice message mailboxes generating events LDAP could identify a user’s various notification sources (their calendar, email and voice mailbox) • Implies: Request to list event server’s 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 <presence xmlns=“urn: ietf: wg: xmpp: ”/> <unlock xmlns=“DAV: ”/>

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 can’t layer you must make everything translatable – And then end-to-end encryption doesn’t 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 – http: //www. sharemation. com/~milele/public/notification-architecture. ppt • Server-to-server requirements rough draft – http: //www. ietf. org/internet-drafts/draft-dusseault-s 2 s-event-reqs-00. txt • Some history: – http: //nih. blogspot. com/2002_07_21_nih_archive. html • SIP Notification: – http: //www. ietf. org/rfc 3265. txt • XMPP core – http: //www. ietf. org/internet-drafts/draft-ietf-xmpp-core-05. txt – JEP-60: Pub/sub • http: //www. jabber. org/jeps/jep-0060. html – JEP-30: Discovery • http: //www. jabber. org/jeps/jep-0030. html • HTTP/Web. DAV events: – http: //www. upnp. org/download/draft-cohen-gena-client-01. txt

Alternate Model Voice Msgs Email ? HTTP ? RSS Presence XMPP SIP Web. DAV Calendar ? Subscription Manager Stores list of servers, events…