SIMPLE WG A. Houri (Ed.) Internet-Draft IBM Intended status: Standards Track V. Singh Expires: January 2, 2008 H. Schulzrinne Columbia U. S. Parameswar Microsoft Corporation E. Aoki AOL LLC July 1, 2007 Scaling Optimizations for Presence in SIP/SIMPLE draft-houri-simple-interdomain-scaling-optimizations-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The document suggests various optimizations for presence that uses the SIP/SIMPLE protocol. The suggestions are based on a separate Houri (Ed.), et al. Expires January 2, 2008 [Page 1] Internet-Draft Scaling Optimizations for Presence July 2007 document that contains scaling analysis and requirements. The current document reviews only suggestions that are not yet part of the work of the various SIP working groups while approved and in-work optimizations are reviewed in the scaling document. The intention here is to keep these suggestions at this document as a place holder until a set of requirements will be discussed and accepted and the work on optimizations will commence. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Possible Optimizations . . . . . . . . . . . . . . . . . . . . 3 2.1. Common NOTIFY for multiple watchers . . . . . . . . . . . 3 2.1.1. Privacy filtering . . . . . . . . . . . . . . . . . . 4 2.1.2. NOTIFY failure aggregation . . . . . . . . . . . . . . 4 2.1.3. Transferring the watcher list . . . . . . . . . . . . 5 2.1.4. Message flow example . . . . . . . . . . . . . . . . . 5 2.1.5. SIP message examples for common NOTIFY . . . . . . . . 7 2.2. Aggregation of NOTIFY messages (Batched notification) . . 8 2.2.1. Extracting and sending individual NOTIFY using Aggregated NOTIFY message body . . . . . . . . . . . . 8 2.2.2. Subscription termination and failure indication in NOTIFY delivery . . . . . . . . . . . . . . . . . . . 9 2.2.3. Message flow example . . . . . . . . . . . . . . . . . 9 2.2.4. SIP message flow example for batched notification . . 11 2.3. Timed presence . . . . . . . . . . . . . . . . . . . . . . 13 2.4. On-Demand presence (Fetch or Pull Model) . . . . . . . . . 14 2.5. Adapting the subscription rate . . . . . . . . . . . . . . 14 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 6.2. Informational References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Houri (Ed.), et al. Expires January 2, 2008 [Page 2] Internet-Draft Scaling Optimizations for Presence July 2007 1. Introduction The document gathers various optimizations for enabling better scaling of presence traffic between domains. The optimizations were suggested during the work on the scaling analysis document [6]. The intention by this document at this stage is to serve as a place holder for the various optimizations until there will be agreement on the requirements for scaling and the work on the actual optimizations will start. Note that most of the optimizations that are suggested here were suggested by Vishal Singh and Henning Schulzrine. The term presence domain or presence system appears in the document several time. By this term we refer to a presence server that provides presence subscription and notification services to its users. The system can be a system that is deployed in a small enterprise or in a very large consumer network. 2. Possible Optimizations This section contains suggested techniques which can be employed by the presence server and clients to reduce presence traffic, specifically, on inter-domain links. Several techniques proposed and briefly described here. The quantitative analysis of these techniques is not fully done yet and will be present in a future version of this document. Protocol mechanisms to employ these techniques are described briefly. This section is intended to help us evaluate and decide if such techniques should become a part of SIMPLE protocol suite. 2.1. Common NOTIFY for multiple watchers When multiple watchers from a domain (for example, domain B) SUBSCRIBE to a presentity in another domain (for example, domain A), a single NOTIFY [2] per presentity in domain B can be sent to domain B's presence server (PS). The presence server in domain B can then distribute the NOTIFY messages to each of the watchers. This eliminates the need to send individual NOTIFY messages from domain A's presence server to each watcher in domain B. The presence server and resource list server (RLS) are assumed to be co--located as a result of which NOTIFY messages are sent to presence server (RLS) in domain B rather then delivered directly to the watchers of domain B. The server distributes the NOTIFY message to a list of watchers based on a single NOTIFY message received from another presence agent. There are three main issues namely, privacy filtering, failure Houri (Ed.), et al. Expires January 2, 2008 [Page 3] Internet-Draft Scaling Optimizations for Presence July 2007 aggregation and transfer of watcher list to watcher's domain presence server to distribute NOTIFY. We discuss these in next subsections. 2.1.1. Privacy filtering Privacy filtering is typically done by presentity's presence server. We propose that presentity's privacy filtering task be handled by watcher domain's presence server, in this case domain B's presence server. There are two possibilities about privacy filtering rules of the presentity as described below. Per domain privacy filters: Presentity in domain A having same privacy filter rules for all the watchers in domain B. In other words, there is a domain level privacy filter specified by the presentity for users from domain B. Privacy filtering can be done by the presence server in domain A and a single NOTIFY can be sent from presence server in domain B. Per watcher privacy filters: Presentity in domain A has different privacy filter rules for different watchers in domain B. Since, presentity in domain A has different privacy filtering rules for watchers from domain B, the privacy filter has to be applied by the presence server in domain B. Complete presence state information needs to be sent from the presentity's domain to watcher's domain. Delegating the task of privacy filtering doesn't compromise any additional privacy information when compared with normal operations. The model is very similar to e-mail trust model. Transfer of a single NOTIFY from presentity's domain to watcher's domain implies that the presence server in watcher's domain receives that information and can potentially distribute it to unauthorized watchers. Thus, presentity implicitly trusts the presence server in its own domain as well as watcher's domain. The proposed mechanism extends such a trust to the presence server in domain B so that it performs the privacy filtering on behalf of presentity in domain A. One potential issue is when presence server in domain A encrypts the presence document for each watcher using SMIME in which case the watcher domain PS cannot perform privacy filtering. Hence, this kind of privacy filtering requires a layer 8 security negotiation between the presence servers of the two domains 2.1.2. NOTIFY failure aggregation The success or failure of NOTIFY message by the server changes the subscription status of the watcher on the presentity's presence server. Hence, to update about failure of NOTIFY delivery, domain B's presence server aggregates the success and failure responses for each watcher and send it to the presence server in domain A. Houri (Ed.), et al. Expires January 2, 2008 [Page 4] Internet-Draft Scaling Optimizations for Presence July 2007 Alternatively, application level negative acknowledgement can be used. 2.1.3. Transferring the watcher list In order to distribute the NOTIFY message received from domain A, the watcher domain presence server requires the list of watchers in its domain for that presentity. We propose the following ways to achieve this. o Watcher list sent in NOTIFY message: The watcher list can be sent from domain A's presence server to domain B's presence server in each NOTIFY message. The NOTIFY is then distributed to each watcher in the list. This has a disadvantage when the number of watcher's from domain B is very large, every NOTIFY message increases in size proportionately. An alternative could be sending the complete list initially and sending changes to the list using the XML-patch operations [7] specified in partial- publication and maintaining the list on presence server in domain B. Sending watcher- list and distributing it, is similar to multi recipient messages i.e., [8], and SUBSCRIBE contained list or Exploders. o Watcher list obtained by subscribing to WINFO [3]package: In this technique, the watcher's domain (domain B) presence server obtains the watcher list from domain A's PS. It also receives any changes to the watcher-list from domain A's PS by subscribing to the presentity with presence.winfo event package. The domain A's PS maintains and updates the watcher list as a part of its normal operation. The updates are sent whenever watcher list changes. They contain information about watchers from domain B only. o Watcher list created on subscriber's presence server: The watcher domain presence server maintains and updates the list of watchers per presentity based on the SUBSCRIBE requests from these watchers. Such a list is like a resource list of watchers per presentity in watcher's domain built dynamically based on SUBSCRIBE request which are not directly sent to presentity's PS. 2.1.4. Message flow example Below is the message flow diagram of how the system may work. Houri (Ed.), et al. Expires January 2, 2008 [Page 5] Internet-Draft Scaling Optimizations for Presence July 2007 Watchers Domain B Domain A Presentity (userB1, B2) (PS + RLS) (PS + RLS) (userA1, A2) ----------------------------------------------------------- 1 | SUBSCRIBE t:userA1 | | | 2 |--------------------->| | | 3 | f:userB1) | SUBSCRIBE | | 4 |<-------200OK---------|------------------>| | 5 | |<-----200OK -------| | 6 | | | | 7 | | NOTIFY | | 8 | |<------------------| | 9 | NOTIFY (f:userA1 |------200OK------->| | 10 |<---------------------| | | 11 | t:userB1) | | | 12 |---------200 OK------>| XCAP Filter B1 | | 13 | |<-----------------<| | 14 | | | | 15 | SUBSCRIBE t:userA1 | | | 16 |--------------------->| SUBSCRIBE | | 17 | f:userB2) |------------------>| | 18 |<-------200OK---------|<-----200OK -------| | 19 | | | | 20 | | NOTIFY | | 21 | NOTIFY (f:userA1 |<------------------| | 22 |<---------------------|------200OK------->| | 23 | t:userB2) | | | 24 |---------200 OK------>| XCAP Filter B2 | | 25 | |<-----------------<| PUBLISH | 26 | | |<-------------| 27 | | |------200OK ->| 28 | | NOTIFY (f:userA1 | | 29 | |<------------------| | 30 | | t: userB1, UserB2)| | 31 | NOTIFY (f:userA1 |------200OK------->| | 32 |<---------------------| | | 33 | t:userB1) | | | 34 |---------200 OK------>| | | 35 | NOTIFY (f:userA1 | | | 36 |<---------------------| | | 37 | t:userB2) | | PUT XCAP | 38 |---------200 OK------>| |<-------------| 39 | | NOTIFY (filter) 40 | |<------------------| | 41 | |------200OK------->| | 42 | | | | 43 | | XCAP Filter B2 | | 44 | |<-----------------<| | ----------------------------------------------------------- Houri (Ed.), et al. Expires January 2, 2008 [Page 6] Internet-Draft Scaling Optimizations for Presence July 2007 Figure 1: Example message flow for common NOTIFY for watchers in a domain We can see in figure above that a single NOTIFY from userA1@ domainA.com is sent to watchers {userB1, userB2}@domainB.com. Also, we can see that a change in privacy filter rule causes a NOTIFY which triggers an XCAP-based download of privacy filtering rules by domain B PS. 2.1.5. SIP message examples for common NOTIFY The following NOTIFY message contains the list of watchers and the presence document of the presentity. The RLS /presence server in B will distribute it to all the watchers in the list. NOTIFY sip:rlserver.domainB.com SIP/2.0 Via: SIP/2.0/TCP rlsserver.domainA.com;branch=z9hG4bK4EPlfSFQK1 Max-Forwards: 70 From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@domainA.com CSeq: 997935769 NOTIFY Contact: Event: presence Subscription-State: active;expires=7200 Content-Type: multipart/related;type="resource-lists+xml"; start="<2BEI83@rlsserver.domainA.com >"; boundary=" tuLLl3lDyPZX0GMr2YOo " Content-Length: 2014 --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <2BEI83@rlsserver.domainA. com> Content-Type: application/resource-lists+xml; charset="UTF-8" --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <2BEI83@rlsserver.domainA.example.com > Content-Type:type="application/pidf+xml;charset="UTF-8" start=""; boundary=" TfZxoxgAvLqgj4wRWPDL" Houri (Ed.), et al. Expires January 2, 2008 [Page 7] Internet-Draft Scaling Optimizations for Presence July 2007 --TfZxoxgAvLqgj4wRWPDL closed --TfZxoxgAvLqgj4wRWPDL-- Figure 2: SIP message examples using common notify technique 2.2. Aggregation of NOTIFY messages (Batched notification) When a watcher from a domain (for example domain B) SUBSCRIBE to multiple presentities in another domain (domain A), domain A's presence server can aggregate the notification messages and send them together as a single NOTIFY message to the presence server in domain B. The presence server in domain B can then deliver the message to the watcher or create individual NOTIFY messages for different watchers and send it to them. This reduces the number of NOTIFY/ 200 OK messages on the inter-domain link as well as access network. This aggregation of NOTIFY can be done on per watcher or per domain basis. The RLS specification describes aggregation and throttling however, leaves it open to the implementers. One problem in aggregation is that presence status update for presentities may not occur simultaneously. Hence, in order to bundle the NOTIFY messages for each watcher or domain, the presence server may have to delay some of the NOTIFY messages. One approach to solve this issue could be that the watcher specifies a tolerable delay for receiving presence state update of the presentities. The watcher can specify this delay value using the watcher filtering mechanism or a SIP-header extension in the SUBSCRIBE message. The presence server in presentity's domain can hold the NOTIFY message only for the amount of time specified. 2.2.1. Extracting and sending individual NOTIFY using Aggregated NOTIFY message body The aggregation of NOTIFY bodies originating from different presentities to a single NOTIFY body works on the basis of Multipart (MIME). Bundling of notification imply aggregating multiple NOTIFY bodies destined to a single watcher (or watcher domain) into a single Houri (Ed.), et al. Expires January 2, 2008 [Page 8] Internet-Draft Scaling Optimizations for Presence July 2007 NOTIFY and delivered to watcher domain presence server. If all the NOTIFY messages are destined to a single watcher, the watcher domain presence server delivers the message directly. Otherwise, the server extracts multiple presence bodies (PIDF) from the received NOTIFY message. Each presence document (PIDF [4]) contains an entity field which uniquely identifies the presentity; hence, there is no dependency on SIP headers to construct individual NOTIFY messages for delivering them to watchers. Delivering bundled NOTIFY messages reduces the traffic on access network as well. 2.2.2. Subscription termination and failure indication in NOTIFY delivery The Subscription-state header in the NOTIFY message is used to indicate subscription termination to a watcher. Bundled notification doesn't indicate subscription termination, hence, terminating NOTIFY messages cannot be sent using this mechanism. Additionally, the notifier needs to know if the NOTIFY was delivered successfully or not. The subscription can be terminated if NOTIFY is not delivered successfully. The presence server in domain B should aggregate and send to PS in domain A the success or failure of NOTIFY messages. The advantage is observed when a single watcher subscribes to multiple presentities from another domain. The delay tolerance interval specified by the watcher should be good enough so that multiple NOTIFY messages can be bundled or aggregated. The reduction in traffic can be seen under two scenarios, i.e., (i) when watcher logs in and subscribes to all the presentities. The NOTIFY from multiple presentities can be bundled and delivered as a single message to the watcher. (ii) In steady state, the gain can be calculated based on the delay tolerance interval, number of presentities to which a watcher is subscribed, probability of these presentities changing state in that interval. With increase in number of presentities, the probability that presentities will update presence state within a time difference of delay tolerance interval will increase and hence the inter domain traffic reduction (gain) will increase. 2.2.3. Message flow example The message flow diagram in Figure below assumes watchers in domain B (userB1, userB2) and presentities in domain A (userA1, userA2). We can see that when userA1 and userA2 send PUBLISH, a single NOTIFY is sent from domain A to domain B, which is converted to individual NOTIFY messages by presence server at domain B. Houri (Ed.), et al. Expires January 2, 2008 [Page 9] Internet-Draft Scaling Optimizations for Presence July 2007 Watchers Domain B Domain A Presentity (userB1,B2) (PS + RLS) (PS + RLS) (userA1,A2) ----------------------------------------------------------- 1 | SUBSCRIBE t:userA1 | | | 2 |--------------------->| | | 3 | f:userB1) | | | 4 |<-------200OK---------| SUBSCRIBE | | 5 | |------------------>| | 6 | |<-----200OK -------| | 7 | | | | 8 | | NOTIFY | | 9 | |<------------------| | 10 | NOTIFY (f:userA1 |------200OK------->| | 11 |<---------------------| | | 12 | t:userB1) | | | 13 |---------200 OK------>| | | 14 | | | | 15 | | | | 16 | SUBSCRIBE t:userA2 | | | 17 |--------------------->| SUBSCRIBE | | 18 | f:userB1) |------------------>| | 19 |<-------200OK---------|<-----200OK -------| | 20 | | | | 21 | | NOTIFY | | 22 | NOTIFY (f:userA2 |<------------------| | 23 |<---------------------|------200OK------->| | 24 | t:userB1) | | | 25 |---------200 OK------>| | PUBLISH | 26 | | userA1|<-------------| 27 | | |------200OK ->| 28 | | | | 29 | | | PUBLISH | 30 | | userA2|<-------------| 31 | | |------200OK ->| 32 | | | | 33 | | NOTIFY (multipart)| | 34 | |<------------------| | 35 | NOTIFY (f:userA1 | (userA1,userA2) | | 36 |<---------------------|------200OK------->| | 37 | t:userB1) | | | 38 |---------200 OK------>| | | 39 | | | | 40 | | | | 41 | NOTIFY (f:userA1 | | | 42 |<---------------------| | | 43 | t:userB1) | | | 44 |---------200 OK------>| | | ----------------------------------------------------------- Houri (Ed.), et al. Expires January 2, 2008 [Page 10] Internet-Draft Scaling Optimizations for Presence July 2007 Figure 3: Message flow for aggregation or batched notification 2.2.4. SIP message flow example for batched notification The following NOTIFY message contains presence documents of multiple presentities. In the example, all the presence documents are destined to a single watcher. Houri (Ed.), et al. Expires January 2, 2008 [Page 11] Internet-Draft Scaling Optimizations for Presence July 2007 NOTIFY sip:rlserver.domainB.com SIP/2.0 Via: SIP/2.0/TCP rlsserver.domainA.example.com;branch=z9hG4bK4EPlfSFQK1 Max-Forwards: 70 From: ;tag=zpNctbZq To: ;tag=ie4hbb8t Call-ID: cdB34qLToC@ domainA.com CSeq: 997935769 NOTIFY Contact: Event: presence Subscription-State: active;expires=7200 Content-Type: multipart/related;type="rlmi+xml"; start="<2BEI83@rlsserver.domainB.example.com >"; boundary=" tuLLl3lDyPZX0GMr2YOo " Content-Length: 2862 --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: <2BEI83@rlsserver.domainB.example.com> Content-Type: application/pidf+xml;charset="UTF-8" open sip:joe@stockholm.example.org --tuLLl3lDyPZX0GMr2YOo Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pidf+xml;charset="UTF-8" closed --tuLLl3lDyPZX0GMr2YOo-- Figure 4: Message Flow for Aggregation or Batched Notification Houri (Ed.), et al. Expires January 2, 2008 [Page 12] Internet-Draft Scaling Optimizations for Presence July 2007 2.3. Timed presence Watchers may be interested in general, coarse-grained availability information of certain presentities rather then getting notification for every status change of the presentity. For example, a manager may be interested in knowing if the employees under him are available or on vacation (calendar/timed-presence) rather then getting notification about every status change. This can be achieved using timed-presence [5]. An example of Timed-presence status is below: open closed sip:Vishal@cs.columbia.edu I'll be in San Diego IETF meeting Figure 5: Time-presence status example Thus, timed-presence can be used to automatically switch the subscription on or off which can lower the presence notification traffic. However, with current watcher filtering specification it is not straightforward to automatically enable or disable notifications based on calendar information from timed-presence. Watchers cannot specify a watcher filter indicating not to send NOTIFY based on timed-status as it would require them to know the 'from'/'until' attribute in before hand. Watcher filtering specification does not allow watchers to specify filter rules to disable notifications based on comparison of timestamps. A watcher application upon obtaining the can specify a watcher filter using the 'from' and 'until' attribute in the received , indicating the server not to send a NOTIFY unless the or 'from' or 'until' attribute changes. A watcher should not blindly un-subscribe for the time specified in the because presentity may update the time-status and watcher may not be aware of this. Hence, watcher must specify a watcher filter which triggers a notification upon changes in elements of , after it has received the first . Once the interval for the received is over, the watcher Houri (Ed.), et al. Expires January 2, 2008 [Page 13] Internet-Draft Scaling Optimizations for Presence July 2007 application removes the filter and starts receiving notifications in a normal manner. However, differential notification can be used to know about changes in the timed-presence. From the above discussion, it is clear that watcher filtering specification requires enhancements for timestamp based watcher filters. 2.4. On-Demand presence (Fetch or Pull Model) Watchers need not be notified about every presence update of all the contacts at all times. Watchers may be interested in regularly receiving presence updates for some of their contacts. But for other contacts, watchers may only want to know their presence information when they want to start a communication session. This can be labeled as on-demand presence and can be accomplished by using fetch based SUBSCRIBE with expiration interval set to zero. This approach requires a mechanism in the watcher application to enable watchers to indicate that they are not interested in regular presence updates, rather they only require presence information when starting a new session. Examples may include services, where presence status does not have to be seen or known to a watcher all of the time. For example, a cell-phone associated watcher may need presence updates only when the cell-phone application (e.g., phone book) runs in the foreground on the device. Another example is a presence-based call routing in telephony, where - before the call is delivered - a watcher issues a fetch-based SUBSCRIBE to learn whether and where the callee is available. 2.5. Adapting the subscription rate The rate of notification can be adjusted based on statistical information about past multimedia sessions with user's contacts. This can be initiated by the client or can be automatically done by the server as server can procure such information based on stored call and text session information. As a matter of fact, 60-70% of the calls/IM messages are sent to 20% of the contacts [Reference required, Observation based on call detail records of friends]. Nearly 50% of the buddies are called rarely. This may include buddies from old office, old college, and old city who are present in the buddy list but are not contacted actively. Based on such information the presence server or the client can adapt the subscription rate and use the fetch model for such buddies. 3. Conclusions The document analysis the scalability of presence systems and of the SIP based in particular. It is apparent that the scalability of these systems is far from being trivial from several perspectives: Houri (Ed.), et al. Expires January 2, 2008 [Page 14] Internet-Draft Scaling Optimizations for Presence July 2007 number of messages, network bandwidth, state management and CPU load. Several optimizations are suggested or are surveyed in this document. It is important to note that not every optimization is really an optimization and some of them may seem to optimize in one place while they actually create load in other parts of the system. It is very possible that the issues that are described in this document are inherent to presence systems in general and not specific to the SIMPLE protocol. Organizations need to be prepared to invest a lot in network and hardware in order to create real big systems. However, it is apparent that not all the possible optimizations were done yet and further work is needed in the IETF in order to provide better scalability It seems that we need to think about the problem in a different way. We need to think about scalability as part of the protocol design. The IETF tends not to think about actual deployments when designing a protocol but in this case it seems that if we do not think about scalability with the protocol design it will not be very hard to scale. We should also consider whether using the same protocol between clients and servers and between servers is a good choice with this problem? It may be that in interdomain or even between servers in the same domain (as between RLSs and presence servers) there is a need to have a different protocol that will be very optimized for the load and can assume some assumptions about the network (e.g. do not use unreliable protocol as UDP but only TCP). Another issue that is more concerning protocol design is whether NOTIFY messages should not be considered as media as the audio, video and even text messaging are considered? The SUBSCRIBE can be extended to do similar three way handshake as INVITE and negotiate where the notify messages should go, rate and other parameters. This way the load can be offloaded to specialized NOTIFY "relays" thus not loading the control path of SIP. 4. Security Considerations One of the biggest sources of traffic between commnunities when dealing with presence are multiple notifications on the same presentities. The need for multiple notifications is due to the need to provide different presence documents to different watchers according to the privacy settings of presentity. Optimizing the traffic between domains will most probably mean delegation of privacy handling of users to the other domain. This is one of the most Houri (Ed.), et al. Expires January 2, 2008 [Page 15] Internet-Draft Scaling Optimizations for Presence July 2007 hardest issues that will need to be solved as part of presence optimizations that directly touches the security of users. Another security threat is actually coming from the fact that users from one community subscribe to users on another community. The fact that there are at least two servers between the users, that the users need to trust for the real identity behind the watcher and the real identity of the provider of the presence information has to be considered while providing solutions for the protocol scalability. 5. Acknowledgments We would like to thank Jonathan Rosenberg, Ben Campbell, Markus Isomaki Piotr Boni, David Viamonte and Aki Niemi for their ideas and input. 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informational References [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [5] Schulzrinne, H., "Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals", RFC 4481, July 2006. [6] Houri, A., "Problem Statement for SIP/SIMPLE", draft-ietf-simple-interdomain-scaling-analysis-00 (work in progress), February 2007. [7] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", draft-ietf-simple-xml-patch-ops-02 (work in Houri (Ed.), et al. Expires January 2, 2008 [Page 16] Internet-Draft Scaling Optimizations for Presence July 2007 progress), March 2006. [8] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", draft-ietf-sip-uri-list-message-01 (work in progress), January 2007. Authors' Addresses Avshalom Houri IBM Science Park Building 18/D Rehovot, Israel Email: avshalom@il.ibm.com Vishal Singh Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Email: vs2140@cs.columbia.edu URI: http://www.cs.columbia.edu/~vs2140 Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Houri (Ed.), et al. Expires January 2, 2008 [Page 17] Internet-Draft Scaling Optimizations for Presence July 2007 Sriram Parameswar Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Email: Sriram.Parameswar@microsoft.com Edwin Aoki AOL LLC 360 W. Caribbean Drive Sunnyvale, CA 94089 USA Email: aoki@aol.net Houri (Ed.), et al. Expires January 2, 2008 [Page 18] Internet-Draft Scaling Optimizations for Presence July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Houri (Ed.), et al. Expires January 2, 2008 [Page 19]