Network Working Group Xiao. Wang Internet-Draft Peili. Xu Expires: March 25, 2006 Huawei Technologies September 21, 2005 A Method to deliver Resource Information List for Presence Information draft-wang-simple-presence-ril-00 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 March 25, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Presence Information Data Format(PIDF) [1] and Rich Presence Extensions to the Presence Information Data Format(RPID) [2] have definition for a lot of presence information. Notifier can filter the presence information to subscriber according to local policy . But the notifier may not support all the presence information. It is a matter how to inform the subscriber the allowed, forbidden and unsupported presence information. This document provides a method to solve this problem by introducing the concept of Resource Information Wang & Xu Expires March 25, 2006 [Page 1] Internet-Draft A Method of RIL September 2005 List(RIL). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Description of Notifier Behavior . . . . . . . . . . . . . 6 4.2. Description of Subscriber Behavior . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Wang & Xu Expires March 25, 2006 [Page 2] Internet-Draft A Method of RIL September 2005 1. Introduction RFC 3265 [3] described a general framework by which notification of event, and the rules of creating SUBSCRIBE request and NOTIFY request. SUBSCRIBE applies to subscription and NOTIFY applies to notification when the resource state has changed. Presence is the important part of SIMPLE. PIDF [1] and RPID [2] defined a lot of presence information. One user can achieve the presence information of other users by sending SUBSCRIBE request. Whereas, the presence information has privacy, notifier can have a local policy to control who can have what part of presence information. This policy can be configured through Web, Terminal User Interface etc. Another issue to be considered is that the Notifier MAY NOT support all the presence information defined by PIDF [1] and RPID [2] for the reason of physical device, environment, or the notifier itself etc. Currently, if the notifier provide partial presence information in PIDF, the subscriber can not know the exact reason for the missing part, whether it is not supported, temporarily not available or forbidden to expose. This document introduces a method to solve the above issues by allowing NOTIFY to deliver RIL(Resource Information List) to subscriber. Wang & Xu Expires March 25, 2006 [Page 3] Internet-Draft A Method of RIL September 2005 2. Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate requirement levels for compliant implementations. Wang & Xu Expires March 25, 2006 [Page 4] Internet-Draft A Method of RIL September 2005 3. Definitions USRIL: Unsupported Resource Information List, base on a set which describe all presence element that the RFC and Draft supported, but in this set notifier can not support some presence element, the unsupported part of this set is called USRIL. USRIL can be some single presence element or some presence element set or the both. ASPE: Allowed Subscribe Presence Element, notifier perform local policy to decide which presence element can be subscribed, and with the subscriber wish to obtain presence element together making "and" operation, that is called ASPE. ASPE can be some single presence element or some presence element set or the both. But purpose to make ASPE simple, ASPE may include a subset of FSPE. FSPE: Forbidden Subscribe Presence Element, notifier perform local policy to decide which presence element can not be subscribed, and with the subscriber wish to obtain presence element together making "and" operation, that is called FSPE. FSPE can be some single presence element or some presence element set or the both. FASPE: Final Allowed Subscribe Presence Element, subscriber make "and" operation by ASPE and FSPE. In the FASPE exclude any subset of FSPE and USRIL. RIL: Resource Information List, include ASPE, FSPE and USRIL. Wang & Xu Expires March 25, 2006 [Page 5] Internet-Draft A Method of RIL September 2005 4. Node Behavior 4.1. Description of Notifier Behavior RIL is conveyed as an independent message body in NOTIFY message. Certainly, the NOTIFY message body may only contain RIL. The definition of RIL is out of the scope of this document and should be contained in another document. The RIL may be conveyed in the following scenarios: 1) Initial Subscription: The Notifier may contain RIL in the first NOTIFY , just after the subscription is accepted. 2) Presence notification: The Notifier may convey RIL in the NOTIFY delivered during subscription to provide the latest RIL especially when the local policy for presence information publication is changed. 3) Subscription refresh: The Notifier may also convey the latest RIL in NOTIFY when the Subscriber refreshs the subscription if the RIL is changed. 4.2. Description of Subscriber Behavior RFC 3265 [3] describes the manner of obtaining presence information, one is immediate fetch manner, another is persistent subscription manner. Subscriber can obtain the currently RIL through any of them if required. Subscriber can directly get USRIL and FSPE from RIL in NOTIFY message, and also can make use of intersection operation to obtain FASPE by ASPE , FSPE and USRIL. The rule to calculate FASPE is as follow: 1) If ASPE is NULL then FASPE is NULL. 2) If ASPE and FSPE is not NULL then FASPE equal ASPE not belong FSPE part. 3) If ASPE and USRIL is not NULL then FASPE equal ASPE not belong USRIL part. 4) If ASPE, FSPE and USRIL is not NULL then FASPE equal ASPE not belong FSPE and USRIL part Wang & Xu Expires March 25, 2006 [Page 6] Internet-Draft A Method of RIL September 2005 5. Examples If a notifier supports all the presence element, in the other words RIL excludes USRIL, then RIL can be described by [4] .This example assumes subscriber called Bob, notifier called Alice. Alice supported all the presence information as follow: urn:ietf:params:xml:ns:pidf, urn:ietf:params:xml:ns:pidf:rpid Bob is interested only in part of Alice's presence element such as: status, contact, activities, mood, place-type 1) Bob send SUBSCRIBE message to Alice. Wang & Xu Expires March 25, 2006 [Page 7] Internet-Draft A Method of RIL September 2005 SUBSCRIBE sip:Alice@example.com SIP/2.0 Via: SIP/2.0/TCP [6666::1:2:3:4]:5060;branch=z9hG4bKxjfdsjfk To: From: ;tag=12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: Content-Type: application/simple-filter+xml Content-Length: ... /pidf:tuple/pidf:status /pidf:tuple/pidf:contact /pidf:tuple/rpid:activities /pidf:tuple/rpid:mood /pidf:tuple/rpid:place-type 2) Alice's local policy only allows Bob to subscribe to the following presence element: status, activities, status-icon, the first NOTIFY the current presence state information and RIL NOTIFY sip:Bob@example.com SIP/2.0 Via: SIP/2.0/TCP [5555::1:2:3:4]:5060;branch=z9hG4bKxjfder To: ;tag=12341111 From: ;tag=232321 Wang & Xu Expires March 25, 2006 [Page 8] Internet-Draft A Method of RIL September 2005 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Event: Presence Subscription-State: active; expires=3599 Contact: Content-Type: multipart/related;type="application/simple-filter+xml"; start=""; boundary="50UBfW7LSCVLtggUPe5z" Content-Length: ... --50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Content-ID: Content-Type: application/simple-filter+xml;charset="UTF-8" /pidf:tuple/pidf:status /pidf:tuple/rpid:activities /pidf:tuple/pidf:contact /pidf:tuple/rpid:mood /pidf:tuple/rpid:place-type --50UBfW7LSCVLtggUPe5z Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pidf+xml;charset="UTF-8" Wang & Xu Expires March 25, 2006 [Page 9] Internet-Draft A Method of RIL September 2005 open lunch --50UBfW7LSCVLtggUPe5z 3) During the subscription, Alice wants to change the local policy, the new local policy allows more presence information as follows to be subscribed: status, activities, status-icon, contact, mood. So Alice's user agent actively send a NOTIFY including the updated RIL to Bob NOTIFY sip:Bob@example.com SIP/2.0 Via: SIP/2.0/TCP [5555::1:2:3:4]:5060;branch=z9hG4bKxjfder To: ;tag=12341111 From: ;tag=232321 Call-ID: 32432udfidfjmk342 Cseq: 2 NOTIFY Event: Presence Subscription-State: active; expires=3512 Contact: Content-Type: multipart/related;type="application/simple-filter+xml"; start=""; boundary="50UBdsLtfghggUPe5z" Content-Length: ... --50UBdsLtfghggUPe5z Content-Transfer-Encoding: binary Content-ID: Content-Type: application/simple-filter+xml;charset="UTF-8" Wang & Xu Expires March 25, 2006 [Page 10] Internet-Draft A Method of RIL September 2005 /pidf:tuple/pidf:status /pidf:tuple/rpid:activities /pidf:tuple/pidf:contact /pidf:tuple/rpid:mood /pidf:tuple/rpid:place-type --50UBdsLtfghggUPe5z Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pidf+xml;charset="UTF-8" open sip:Alice@example.com lunch happy --50UBdsLtfghggUPe5z Wang & Xu Expires March 25, 2006 [Page 11] Internet-Draft A Method of RIL September 2005 4) When the updated RIL is received, Bob may want to refresh the subscription to get more presence information which is allowed now. He changes the element: status, activities, mood, deviceID, status-icon, Alice's user agent acknowledges the subscription refresh and then send a NOTIFY containing the current presence information and also RIL to Bob now. NOTIFY sip:Bob@example.com SIP/2.0 Via: SIP/2.0/TCP [5555::1:2:3:4]:5060;branch=z9hG4bKxjfder To: ;tag=12341111 From: ;tag=232321 Call-ID: 32432udfidfjmk342 Cseq: 3 NOTIFY Event: Presence Subscription-State: active; expires=3512 Contact: Content-Type: multipart/related;type="application/simple-filter+xml"; start=""; boundary="50UBdsLtfghggUPe5z" Content-Length: ... --rtdBdsLtfghasqPe5z Content-Transfer-Encoding: binary Content-ID: Content-Type: application/simple-filter+xml;charset="UTF-8" /pidf:tuple/pidf:status /pidf:tuple/rpid:activities /pidf:tuple/rpid:mood /pidf:tuple/pidf:status-icon Wang & Xu Expires March 25, 2006 [Page 12] Internet-Draft A Method of RIL September 2005 /pidf:tuple/rpid:deviceID --rtdBdsLtfghasqPe5z Content-Transfer-Encoding: binary Content-ID: Content-Type: application/pidf+xml;charset="UTF-8" open http://example.com/open.ico lunch happy --rtdBdsLtfghasqPe5z Wang & Xu Expires March 25, 2006 [Page 13] Internet-Draft A Method of RIL September 2005 6. Security Considerations This is important to user that include RIL in NOTIFY message body. As a result, it is especially important that message containing this extension be authenticated and authorized. Authentication can be achieved using the Digest Authentication mechanism described in RFC 3261 [5]. The authorization decision is made based on the permissions that the resource (notifier) has given to the watcher. An example of such authorization policy can be found in [6]. 7. Normative References [1] Sugano, H., "Presence Information Data Format", RFC 3863, Auguest 2004. [2] Schulzrinne, H., "RPID -- Rich Presence Information Data Format", Draft draft-ietf-simple-rpid-08, Auguest 2004. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [4] Khartabil, H., "An Extensible Markup Language (XML) Based Format for Event Notification Filtering", Draft draft-ietf-simple-filter-format-05, February 2005. [5] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [6] Rosenberg, J., "Presence Authorization Rules", Draft draft-ietf-simple-presence-rules-03, February 2005. Wang & Xu Expires March 25, 2006 [Page 14] Internet-Draft A Method of RIL September 2005 Authors' Addresses Xiao Wang Huawei Technologies Bantian Shenzhen, Longgang 518129 China Phone: +86 755 28788996 Email: wangsmile@huawei.com Peili Xu Huawei Technologies Bantian Shenzhen, Longgang 518129 China Phone: +86 755 28780808 Email: xupeili@huawei.com Wang & Xu Expires March 25, 2006 [Page 15] Internet-Draft A Method of RIL September 2005 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 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 (2005). 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. Wang & Xu Expires March 25, 2006 [Page 16]