SIMPLE Hong. Zhou Internet Draft Huawei Technologies Expires: December 2006 June 9, 2006 Hierarchical presence event notification draft-zhou-simple-hierarchical-presence-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 December 9, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document describe a new method for the Presence Server to process presence in inter-domain scenarios. The currently-defined method according to RFC 3261 [1] and RFC 3265 [2] results in duplicated messaging. This document provides a new method to avoid this duplication. Hong Expires December 9, 2006 [Page 1] Internet-Draft Hierarchical presence June 2006 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [5]. Table of Contents 1. Introduction............................................ 2 2. Process Presence in Inter-domain........................ 2 2.1. Currently-defined Method........................... 2 2.2. Hierarchical Method................................ 6 2.3. Compatible with RFC 3857........................... 8 3. Presence Server Behavior............................... 11 4. UA Considerations ..................................... 12 5. Security Considerations................................ 12 6. Acknowledgments........................................ 12 7. References............................................. 13 7.1. Normative References.............................. 13 7.2. Informative References............................ 13 Author's Addresses........................................ 13 Intellectual Property Statement .......................... 13 Disclaimer of Validity.................................... 14 Copyright Statement....................................... 14 Acknowledgment ........................................... 14 1. Introduction RFC 3856 [3] describes the usage of SIP for subscriptions and notifications of presence, but the method described in RFC 3261 [1] and RFC3265 [2] (called "currently-defined method" in this document) results in duplicated messaging for each listener between domains. This document provides a additional way to process presence without duplicated messaging. The new method is compatible with the currently-defined Method and is called Hierarchical Method. 2. Processing Presence Information in Inter-domain This section describes the duplicated messaging in the currently- defined method and the hierarchical method being proposed. 2.1. Currently-defined Method Consider this scenario: there are two domains(Domain A and Domain B)in the SIP network, Server A is a presence server in Domain A and Server B is a presence server in Domain B, both the user Watcher1 and Hong Expires December 9, 2006 [Page 2] Internet-Draft Hierarchical presence June 2006 Watcher2 in Domain A want to subscribe the Presence User Agent's (PUA's) presence information and the PUA in Domain B. The main steps are shown in Figure 1.: o Watcher1 sends SUBSCRIBE to Server A and Server A forwards the message to Server B. o Server B accepts the request and responds 200, then sends NOTIFY to Server A. Server A only forwards 200 for SUBSCRIBE and NOTIFY to Watcher1. o Watcher2 sends SUBSCRIBE to Server A and Server A forwards the message to Server B. o Server B accepts the request and responds 200, then sends NOTIFY to Server A. Server A only forwards 200 for SUBSCRIBE and NOTIFY to Watcher2. o PUA tells Server B its new state if its state is changed. o Server B sends NOTIFY to tell Watcher1 the new state. o Server B sends NOTIFY to tell Watcher2 the new state. Hong Expires December 9, 2006 [Page 3] Internet-Draft Hierarchical presence June 2006 +---------Domain A -----------+ +----Domain B---+ | | | | v v v v Watcher1 Watcher2 Server A Server B PUA | F1 SUBSCRIBE | | | | |--------------|------------->| F2 SUBSCRIBE | | | | |------------->| | | | | F3 200 OK | | | | |<-------------| | | F4 200 OK | | | | |<-------------|--------------| | | | | | F5 NOTIFY | | | | |<-------------| | | F6 NOTIFY | | | | |<-------------|--------------| | | | F7 200 OK | | | | |--------------|------------->| | | | | | F8 200 OK | | | | |------------->| | | | F9 SUBSCRIBE | | | | |------------->| | | | | | F10 SUBSCRIBE| | | | |------------->| | | | | F11 200 OK | | | | |<-------------| | | | F12 200 OK | | | | |<-------------| | | | | | F13 NOTIFY | | | | |<-------------| | | | F14 NOTIFY | | | | |<-------------| | | | | F15 200 OK | | | | |------------->| | | | | | F16 200 OK | | | | |------------->| | | | | |Update presence| | | | |<--------------| | | | F17 NOTIFY | | | | |<-------------| | | F18 NOTIFY | | | | |<-------------|--------------| | | | F19 200 OK | | | | |--------------|------------->| | | | | | F20 200 OK | | | | |------------->| | | | | F21 NOTIFY | | | | |<-------------| | Hong Expires December 9, 2006 [Page 4] Internet-Draft Hierarchical presence June 2006 | | F22 NOTIFY | | | | |<-------------| | | | | | | | Watcher1 Watcher2 Server A Server B PUA | | | | | | | F23 200 OK | | | | |------------->| | | | | | F24 200 OK | | | | |------------->| | | | | | | | | | | | Figure 1 As we can see, the messages F17 and F21 carry the same information about PUA'S presence. So if many users in Domain A subscribe the PUA's presence information, and if the PUA's presence information is changed, there will be many NOTIFYs (along with their responses) carrying duplicated information between Server A and Server B. Hong Expires December 9, 2006 [Page 5] Internet-Draft Hierarchical presence June 2006 2.2. Hierarchical Method The hierarchical method's basic concept is that Presence Servers subscribe to presence information from other domain's Presence Server. An example is shown in Figure 2. The relationships among Watcher1, Watcher2, PUA, Server A and Server B are the same as Section 2.1. The main steps are: o Watcher1 sends SUBSCRIBE to Server A, Server A responds 202. o Server A itself sends SUBSCRIBE to Server B to subscribe the PUA's presence state. o Server B accepts the Server A's request and responds 200, then sends NOTIFY to tell Server A the PUA's presence state. o Server A gets the PUA's presence state and stores it, then sends NOTIFY to Watcher1. o Watcher2 sends SUBSCRIBE to Server A, Server A responds 202. o Server A sends NOTIFY to Watcher2 as it knows the PUA's presence state. o PUA tells Server B its new state when its state is changed. o Server B sends NOTIFY to tell Server A the new state. o Server A sends NOTIFY to tell Watcher1 and Watcher2 the new state. Hong Expires December 9, 2006 [Page 6] Internet-Draft Hierarchical presence June 2006 +---------Domain A -----------+ +----Domain B---+ | | | | v v v v Watcher1 Watcher2 Server A Server B PUA | F1 SUBSCRIBE | | | | |--------------|------------->| | | | F2 202 Accepted | | | |<-------------|--------------| | | | | | F3 SUBSCRIBE | | | | |------------->| | | | | F4 200 OK | | | | |<-------------| | | | | F5 NOTIFY | | | | |<-------------| | | | | F6 200 OK | | | F7 NOTIFY | |------------->| | |<-------------|--------------| | | | F8 200 OK | | | | |--------------|------------->| | | | | F9 SUBSCRIBE | | | | |------------->| | | | | F10 202 Accepted | | | |<-------------| | | | | F11 NOTIFY | | | | |<-------------| | | | | F12 200 OK | | | | |------------->| | | | | | |Update presence| | | | |<--------------| | | | F13 NOTIFY | | | | |<-------------| | | | | F14 200 OK | | | | |------------->| | | F15 NOTIFY | | | | |<-------------|--------------| | | | F16 200 OK | | | | |--------------|------------->| | | | | F17 NOTIFY | | | | |<-------------| | | | | F18 200 OK | | | | |------------->| | | | | | | | Figure 2 Note: Authentication and authorization did not show in this figure. That will be discussed in Section 2.3. Hong Expires December 9, 2006 [Page 7] Internet-Draft Hierarchical presence June 2006 The flow chart shows that the NOTIFY messages between Server A and Server B are reduced. Assuming N users in Domain A subscribed the PUA's presence information, and using Currently-defined Method, the number of NOTIFY message sent from Server B to Server A is N. Using Hierarchical Method, the number is 1. Additional, the user in Domain A will quickly get the PUA's presence state if the Server A has gotten this state. 2.3. Compatibility with RFC 3857 RFC 3856 says "In inter-domain scenarios, establishing an authenticated identity of the subscriber is harder. It is anticipated that authentication will often be established through transitive trust". This document also uses this assumption. Authorization is complex. This document provide one approach, compatible with RFC 3857. Of course, this document does not exclude other authorization mechanisms. Figure 2 shows a example, based on Section 2.2. Hong Expires December 9, 2006 [Page 8] Internet-Draft Hierarchical presence June 2006 +---------Domain A -----------+ +----Domain B---+ | | | | v v v v Watcher1 Watcher2 Server A Server B PUA | | | | | | | | |notify presence| | | | |<--------------| | | | | F1 SUBSCRIBE | | | | (event=presence.winfo) | | | |<--------------| | | | | F2 200 OK | | | | |-------------->| | | | | F3 NOTIFY | | | | (event=presence.winfo) | | | |-------------->| | | | | F4 200 OK | | | | |<--------------| | | | | | | F5 SUBSCRIBE(event=presence)| | | |--------------|------------->| | | | F6 407 Proxy Authentication Required | | |<-------------|--------------| | | | F7 SUBSCRIBE(event=presence)| | | |--------------|------------->| | | | F8 202 Accepted | | | |<-------------|--------------| | | | | | F9 SUBSCRIBE(event=presence) | | | |------------->| | | | | F10 200 OK | | | | |<-------------| | | | | F11 NOTIFY(event=presence) | | | |<-------------| | | | | F12 200 OK | | | | |------------->| | | | | | | | | |F13 SUBSCRIBE(event=presence.winfo) | | |<-------------| | | | | F14 200 OK | | | | |------------->| | | | | F15 NOTIFY(event=presence.winfo) | | |------------->| | | | | F16 200 OK | | | | |<-------------| | | | | | F17 NOTIFY | | | | (event=presence.winfo) | | | |-------------->| | | | | F18 200 OK | Hong Expires December 9, 2006 [Page 9] Internet-Draft Hierarchical presence June 2006 | | | |<--------------| | | | make decision | | | | | | | F19 NOTIFY(event=presence) | | | |<-------------|--------------| | | | F20 200 OK | | | | |--------------|------------->| | | | | | | | | | F21 SUBSCRIBE(event=presence) | | |------------->| | | | | F22 407 Proxy Authentication Required | | |<-------------| | | | | F23 SUBSCRIBE(event=presence) | | |------------->| | | | | F24 202 Accepted | | | |<-------------| | | | | | F25 NOTIFY(event=presence.winfo) | | |------------->| | | | | F26 200 OK | | | | |<-------------| | | | | | F27 NOTIFY | | | | (event=presence.winfo) | | | |-------------->| | | | | F28 200 OK | | | | |<--------------| | | | make decision | | | | | | | | F29 NOTIFY(event=presence) | | | |<-------------| | | | | F30 200 OK | | | | |------------->| | | | | | |Update presence| | | | |<--------------| | | | | | | | | F31 NOTIFY(event=presence) | | | |<-------------| | | | | F32 200 OK | | | | |------------->| | | F33 NOTIFY(event=presence) | | | |<-------------|--------------| | | | F34 200 OK | | | | |--------------|------------->| | | | | F35 NOTIFY(event=presence) | | | |<-------------| | | | | F36 200 OK | | | | |------------->| | | | | | | | Hong Expires December 9, 2006 [Page 10] Internet-Draft Hierarchical presence June 2006 Figure 3 3. Presence Server Behavior First of all, the Presence Server MUST know whether the other Domain's Presence Server supports Hierarchical Method. The simplest approach is manual configuration. This document neither supports nor excludes other approaches. If a Presence Server receives a SUBSCRIBE request, the Presence Server SHOULD process the message as follows: o Presence Server got the subscribed user from the SUBSCRIBE message. o If the subscribed user belongs to its domain, then Presence Server process the SUBSCRIBE message using the currently-defined Method. o If the subscribed user does not belong to its domain, but the Presence Server can't use Hierarchical Method then it uses the currently-defined Method. o Otherwise, Presence Server use Hierarchical Method: - Presence Server responds 202 for the SUBSCRIBE, and simultaneously creates (if no dialog already exists) or maintains (if dialog has already been created) dialog according to RFC3265 [2]. - If Presence Server has the subscribed user's presence information, then Presence Server sends NOTIFY message to subscriber. - Otherwise, Presence Server creates new SUBCRIBE according to the Watcher's SUBSCRIBE and sends it to the other domain's Presence Server. - Presence Server distributes the NOTIFY to the subscribers according to dialogs it created when it receives NOTIFY message from other domain's Presence Server. Hong Expires December 9, 2006 [Page 11] Internet-Draft Hierarchical presence June 2006 4. UA Considerations UA needn't know the Presence Server using Currently-defined Method or Hierarchical Method, So UA need no additional behavior to support this document. 5. Security Considerations Security considerations of this document are unchanged from RFC 3856 [3] and RFC 3857 [4]. 6. Acknowledgments We would like to thank Spencer Dawkins, Feng Li, Xinyu Hu, Kewei Zhang, Xia Qin, Changsheng Wan, Jian Chen, Palin Yang, Yuping Zhao, Hao Wang, Qikun Wei and Rong Zou for their comments and support of this specification. Hong Expires December 9, 2006 [Page 12] Internet-Draft Hierarchical presence June 2006 7. References 7.1. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, July 2004. [4] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [5] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [6] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, May 2004. Author's Addresses Hong Zhou NanJing Institute,Huawei Technologies Co.,Ltd. Floor 10,HuiHong Mansion,No.91 BaiXia Rd. NanJing, P.R. of China Phone: +86 25 8456 5478 Email: zhouhong@huawei.com Intellectual Property Statement 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 Hong Expires December 9, 2006 [Page 13] Internet-Draft Hierarchical presence June 2006 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 Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hong Expires December 9, 2006 [Page 14]