The Future of SIP and Presence Jonathan Rosenberg Chief Scientist

SIP A Brief IETF History March 1998IETF begins investigating IM and presence in the PIPR BoF. August 1998Idea of SIP for Presence is first proposed to PIPR. March 1999IMPP group chartered to do requirements. February 2000RFC2778 (Model for IM and Presence) and RFC2779 (Requirements for IM and Presence Protocol)appear. March 2000IMPP goes dormant, can’t make progress on a single protocol. IESG requests complete proposals by June. June 2000Nine protocols are submitted to IETF, including SIP for presence, jointly proposed by folks from dynamicsoft, Microsoft, Columbia U., Cisco. August 2000Nine distill to three camps. IESG considers forming three working groups. December 2000SIMPLE BoF meets. March 2001 SIMPLE working group formed.

SIP Where Are We Now? SIP for Instant Messaging (aka the MESSAGE Method) Completed RFC3428 issued December 2002 SIP for Presence Specifications Completed in May 2002 and Submitted to IESG for Approval Baseline presence spec (draft-ietf-simple-presence) Watcherinfo spec (draft-ietf-simple-winfo-package) Watcherinfo XML format (draft-ietf-simple-winfo-format) Instant Messaging Sessions Making Progress Could not agree on a transport for a long time (almost 9 months) Finally agreed on CPIM/TCP Work is progressing well on details “Buddy List Package” Subscribe to a list of users Has received continuous attention for a year but had not stabilized Finally stabilized on a satisfactory approach

SIP Where Are We Going? The Main Goal Is to Develop a Set of Component Capabilities for Building a Variety of Presence-based Systems Guiding Principles Presence will drive many applications, not just IM Presence will be used as an integral part of any communications system Wireless is a key customer Main Activities in 2003 Application configuration data manipulation Generic IM features isTyping Delivery status notification Presence filtering Presence document enhancements Completion of buddy list package, messaging sessions BCP for IM systems

SIP Data Manipulation Presence and IM Systems Make Significant Use of Application Configuration Data (ACD) The buddy list White/black lists, authorization policy ACD Is Read and Written by End Users ACD Is Read and Written by Network Applications Example: Buddy List User adds Joe to Buddy List using ACD manipulation protocol ACD server stores new list User subscribes to their buddy list Presence server fetches the buddy list from the ACD server Presence server fans out subscriptions SUBSCRIBE to Buddylist Add Joe to Buddy List Get Buddy List Fanned Out Subscriptions ACD Server

SIP ACD Needs ACD Is Needed in Other Areas in the SIP Universe Conferencing policies Who can and cannot join Who can be moderator Creating conferences Group calling Network speed dials All ACD Usages Share Common Requirements Manipulation by end user clients Usage by a single user across multiple devices General editing – add elements, remove elements, change elements, list elements Synchronization with end device End user authentication Extensive authorization support Only Joe can write his own buddy list, but his department can read it ACID (Atomicity, Consistency, Isolation, Durability) Support lots of clients Work for wireless devices

SIP Approaches for ACD Two Approaches Vertical protocols General protocol Vertical Protocols Design a specific protocol for managing the specific data for each application This is the Wireless Village, PRIM, XMPP approaches Easy to design a specific protocol BUT, network complexity is horrible when you get multiple applications Hard to share data Expensive to add new applications Needs tie in to customer care, operations, etc. General Protocol and Server Single protocol and server for managing ACD for all applications Server itself is schema independent and ignorant Protocol is schema independent Hard to design generically BUT, works famously for multi-application networks Easier to share data across applications Easy to add new applications (no server changes – just publish a new schema, used only by the application) Easy to tie in to customer care, operations

SIP What Are the Challenges? The Data Model Generic enough to support a broad set of applications Simple enough to be implementable in a wide variety of devices Example data models Structure of Managed Information (SMI) from SNMP ACAP data model SQL relational Database Authorization Who is allowed to Read Write Search Delete Create Are user groups needed? Extensibility Making sure future applications can be supported without requiring server or database changes Synchronization Handling the case of multiple clients each updating the same data Need a notification mechanism to indicate changes in data

SIP isTyping What Is It? Existing IM feature that lets users know whether the other user is typing a reply Very useful in non-streaming interactive applications Solution Possibilities SIP Events – SUBSCRIBE to it, get notified when the typing state changes Hard to work with page mode Hard to sequence with the actual messages MESSAGE body type Works with page and session mode Will work through CPIM gateways In same sequence space as actual messages Use SDP to signal capability to use it Generalization “Typing” represents non- streaming interactive text There are other media types – voice, video Would like to generalize isTyping to general composition of non- streaming media Useful for voice IM, for example

SIP Delivery Status Notifications DSNs Indicate That a Message Was Ultimately Received or Failed Common in (RFC 1894) Several Uses in IM In Session Mode, used to indicate whether message is received by the endpoint or fails In session or page mode, handles delivery through gateways (SMS gateway) where final status is unknown at time of sending In page mode, handles delivery when recipient is not online, and logs on later to retrieve their IM RFC 1894 Is Almost Perfect, but Not Quite Specific to DSNs are quite large, would like something smaller for wireless Work Will Be in Determining the Level of Reuse of RFC 1894 for IM

SIP Presence Filtering Presence Is All About POLICY There Are Three Players Who Have Policy Inputs The watcher The presentity The administrator A Complete System Needs to Allow All Three Parties to Express Their Policy Requirements Presentity Policy Through ACD manipulation – set specific policies Administrator Policy Through operational and provisioning interfaces, usually not standardized But, How Does the Watcher Indicate Their Policies? Overall Policy Watcher Policy Presentity Policy Admin Policy

SIP Presence Filtering Examples of Watcher Policies Send me only geoloc information Send me presence updates only when the status goes from offline to online Don’t send me notifications faster than once per minute RFC 3265 Leaves a Space for This Problem SUBSCRIBE bodies contain policy document, called a “filter” No documents currently defined Main Issue: Presence Specific or Generic for All SIP-events Conclusion: most of it is package specific Task Is to Specify a Document Format for Presence Policy Main Challenge: Scope Potentially unbounded: “Send me only geoloc information when the basic status changes from online to offline if there are four tuples but only if one of those tuples supports IM and at least one of the remaining three indicates a SIP URI” Two Axes of Filtering On what state changes are notifications sent What is the content of the notifications that get sent

SIP Presence Document Enhancements Current PIDF Document Is Minimalistic OPEN/CLOSED status Multiple tuples, each with its own address, status and display note That’s it Several Potential Areas of Extension Tuple naming extensions Device capabilities General status Static content Tuple Naming Extensions Need a way to refer to a tuple for policy reasons Example: “send me only the PC tuple” Device Capabilities SIP Caller Preferences extension allows a device to indicate its capabilities Media types Codecs SIP Methods Would like to reflect this information in presence documents Indicate that tuple 1 supports audio and video General Status Busy, in a meeting, out to lunch, etc. Do these need to be standardized, or does a textual note suffice? Main issue: what is needed for an automata to process Static Content vCard, Image Thumbnail, recording of my name Indirection or inline content

SIP Putting It All Together The Challenge: Build a Consumer- grade IM/buddylist Application Using IETF Protocols, Comparable to Yahoo, AOL, MSN in Features SIMPLE to Generate a Document Explaining How Serves Several Purposes Verify that we have all the pieces standardized to do so Instruct operators on how to fit all the pieces together Makes Use of Many Protocols SIP for presence MESSAGE method, messaging sessions Data manipulation IMAP (IM message store) HTTP (content indirection) Whois++ (profile searches) HTML (emoticons) SIP (PC to phone, webcams) SIP Conferencing (IM conferences) Floor control protocols (IM conferences) Content Indirection (file sharing) Will Provide Guidelines on How to Use Some of These Protocols System Integration Is the Hardest Part

SIP Resources SIMPLE Charter: Advanced IM Requirements: rosenberg-simple-messaging-requirements-00.txt SIMPLE Components Model: rosenberg-simple-components-00.txt

Information Resource Jonathan Rosenberg Chief Scientist