1 / 14

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

glynn
Download Presentation

Notification Explosion

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 Notification Explosion

  2. A notification aggregator combines event sources VoiceMsgs Email HTTP Presence Presence WebDAV Calendar ? RSS ? XMPP SIP ? 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 • 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? • Alice.wetherill@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 1st 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, 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

  8. 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 user’s various notification sources (their calendar, email and voice mailbox) • Implies: Request to list event server’s resources • Implies: Eventually, search capability too

  9. 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:”/>

  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? • 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?

  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. • 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

  12. 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

  13. 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-s2s-event-reqs-00.txt • Some history: • http://nih.blogspot.com/2002_07_21_nih_archive.html • SIP Notification: • http://www.ietf.org/rfc/rfc3265.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/WebDAV events: • http://www.upnp.org/download/draft-cohen-gena-client-01.txt

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

More Related