SIMPLE WG M. Lonnfors Internet-Draft Nokia Research Center Expires: July 21, 2004 J. Costa-Requena E. Leppanen H. Khartabil Nokia January 21, 2004 Partial Notification of Presence Information draft-ietf-simple-partial-notify-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 July 21, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Limitations can also be caused by the interface between the terminal and the network, i.e. radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase transport efficiency, by introducing a mechanism called partial notification. Lonnfors, et al. Expires July 21, 2004 [Page 1] Internet-Draft Partial notification January 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction to the partial notification mechanism . . . . . . 4 3.1 Basic presence server operation . . . . . . . . . . . . . . . 4 3.2 Operation with partial notification . . . . . . . . . . . . . 4 4. Client and server operations . . . . . . . . . . . . . . . . . 5 4.1 Content-type for partial notifications . . . . . . . . . . . . 5 4.2 Watcher generating of SUBSCRIBE requests . . . . . . . . . . . 5 4.3 Notifier processing of SUBSCRIBE requests . . . . . . . . . . 5 4.4 Notifier generating partial notifications . . . . . . . . . . 5 4.5 Watcher processing of partial notifications . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 12 6.2 Message Integrity and Authenticity . . . . . . . . . . . . . . 12 6.3 Outbound Authentication . . . . . . . . . . . . . . . . . . . 12 6.4 Replay Prevention . . . . . . . . . . . . . . . . . . . . . . 12 6.5 Denial of Service Attacks Against Third Parties . . . . . . . 12 6.6 Denial Of Service Attacks Against Servers . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 Normative references . . . . . . . . . . . . . . . . . . . . . 13 Informative references . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 16 Lonnfors, et al. Expires July 21, 2004 [Page 2] Internet-Draft Partial notification January 2004 1. Introduction SIP extensions for presence [4] allow users ('watchers') to subscribe to other users' ('presentities') presence information. The presence information is composed of multiple pieces of data that are delivered to the watcher. The size of the presence information document can be large (i.e. the presence document can contain an arbitrary number of elements called presence tuples that convey data). As specified in [3] and , [4] a Presence server (PS) always delivers all presence data that has been authorized for a certain watcher in presence notification. This is done regardless what presence data has changed compared to last notification. It may not be reasonable to send the complete presence information over low bandwidth and high latency links when only part of presence information changes. This may end up degrading the presence service and causing bad perception at the watcher side. There are some mechanisms, such as signaling compression [10] and content indirection [9] that can be used to help in this problem. However these solutions set additional requirements on basic network functionalities such as security. Some of the existing solutions enforce certain requirements on the network and terminals for supporting compression mechanism, while other solutions require having a specific server to store the requested presence information until the terminal fetches it using another protocol (HTTP) and therefore increases possible security concerns. This draft presents a solution to problems described above, called partial notifications. In general, the partial notification approach means that the presence server delivers to the watchers only those parts of the presence information that have changed compared to the presence information sent in the previous notifications. This reduces the amount of data that needs be trasported over the network. Mechanism utilizes presence event package [4] and partial PIDF MIME type [2]. 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 [1] and indicate requirement levels for compliant implementations. This document makes use of the vocabulary defined in RFC2778 [3], presence event package [4], and partial PIDF definition [2]. Lonnfors, et al. Expires July 21, 2004 [Page 3] Internet-Draft Partial notification January 2004 3. Introduction to the partial notification mechanism This chapter briefly introduces the normal functionality of the presence service, and gives an overview of the partial notification solution. 3.1 Basic presence server operation The presence service normally operates so that the watcher sends the SIP SUBSCRIBE request targeted to the presentity. The request is routed up to the presence server responsible for terminating the request. The SUBSCRIBE request MAY include an Accept header field for indicating the supported content types [5]. The PS receives the SUBSCRIBE request and if there is no Accept header indicating the supported content types or Accept header contains the default PIDF content type, the PS will generate the presence notification using the default PIDF format [6]. The PIDF may contain one or multiple tuples and presence document level information. The tuples include a set of elements defined in the presence model [3] for representing the presence information. The presence information is sent to the watcher in the body of the NOTIFY request according to [7]. By default, the presence information contains the full state corresponding to the presence status of the presentity, as determinated by the PS local policy and authorization rules. 3.2 Operation with partial notification The partial notification mechanism enables the watcher to ask and the presence server to send only those parts of the presence information that have changed since the last notifications was sent. When watcher receives a notification where the "state" attribute, as defined in [2], is set to "full", this presence document is concidered to be local the presence document for the presentity in question. Partial notifications (when the "state" attribute as defined in [2] is set to "partial") are relative to the full presence document. This means that if a partial notification contains new tuples (tuples which have new tuple ids compared to the full presence document) they are added to the local full presence document. If it contains tuples which have exsting tuple ids it means that those tuples are updated. If "removed" element contains existing tuple ids it means that those tuples are removed. The wathcer updates the local copy accordingly. This behavior is described in detail in Section 4. In the scope of this document the partial notifications apply only to the level XML elements and everything what is contained Lonnfors, et al. Expires July 21, 2004 [Page 4] Internet-Draft Partial notification January 2004 inside these elements i.e. tuples are considered to be atomic data elements. This means that when an update is send to a tuple it is assumed that the whole tuple is completely replaced by the new one. All the data which is located outside the elements must be processed as specified in [4]. Usually this means that all those XML elements (for example the element) must be included in every notification. 4. Client and server operations This document assumes that unless otherwise specified in this document the normal subscriber and notifier behavior is applied as defined in [4]. The watcher has the same behavior as a subscriber. 4.1 Content-type for partial notifications The entities supporting the partial notification extension described in this document MUST support the 'application/pidf-partial+xml' content-type. 4.2 Watcher generating of SUBSCRIBE requests The SUBSCRIBE request can be used to negotiate the preferred content type to be used in the notifications. The Accept header is used for this purpose as specified in [5]. When a watcher wants to allow PS to send partial notifications it MUST include the Accept header value 'application/pidf-partial+xml' in the SUBSCRIBE request. The qvalue parameter of the Accept header can be used to indicate the most preferred content type to be used. 4.3 Notifier processing of SUBSCRIBE requests The notifier receives the subscriptions from the watchers and generates the notifications according to [4]. If the watcher has indicated the supported content types in the Accept header the presence server compares the content types included in the Accept header with the supported ones, and decides which one to use. If the watcher has used the qvalue parameter of the Accept header for the content types the decision SHOULD be based on them. Otherwise the decision is made according to the local policy of the presence server. 4.4 Notifier generating partial notifications It is RECOMMENDED that if the watcher indicates support for partial notifications, using the Accept-header, that the PS compliant with this specification sends partial notifications. If the PS decides to send notifications according to this specification, then the notifier Lonnfors, et al. Expires July 21, 2004 [Page 5] Internet-Draft Partial notification January 2004 MUST use the 'application/pidf-partial+xml' content type in the NOTIFY requests. The PS MUST deliver the full state of the presence information according to [4] in the first notification. In this case, the "state" attribute of the element in the presence document MUST be set to the value "full". The "version" attribute MUST also be present and it MUST be initialized to value zero. When the PS generates subsequent notifications, the presence document includes only the tuples that have changed compared to the previous notification. It is up to the local policy to determine what is considered as a change to the previous state. The "state" attribute's value MUST be set to "partial". The PS constructs the partial presence document according to the following logic: o The delivered presence information MUST be constructed according to [4] in such a way that only the changed tuples are delivered. New tuples are also added to the presence information, if any. o The "version" and "state" attributes MUST be included in the presence document. The version number is incremented by one compared to the earlier delivered presence document to the watcher associated with a certain subscription. o When there are changes (e.g. in the authorization) which lead to removal of tuples from the previously delivered presence information the PS lists the tuple ids of the removed tuples in the "removed" element. o All the presence information outside the elements MUST be included in each notification, i.e., all the notifications which convey partial presence documents MUST always have that data. 4.5 Watcher processing of partial notifications If the PS decided to use the partial notifications, then the watcher receives 'application/pidf-partial+xml' content type in the NOTIFY requests. The watcher receives the full presence document in the first notification. In this case, the "state" element of the presence document has the value "full". When the watcher receives the full presence document it MUST perform the following actions: Lonnfors, et al. Expires July 21, 2004 [Page 6] Internet-Draft Partial notification January 2004 o The watcher MUST discard all previously received presence information from that particular presentity in the context of current dialog. o The watcher MUST initialize an internal version counter, related to the particular presentity or subscription, to the value of "version" atttribute received in the notification. o The watcher MUST store the values of all tuple ids together with the content received in the notification. This is the watcher's local copy of the full presence document. When the watcher receives subsequent notifications and the PS has not changed the used content type, and the "state" element includes the value "partial" the watcher MUST construct the presence information according to the following logic: o The "version" attribute of the element is compared with the version information in the previously received presence document. If the version number is incremented by one, the watcher continues handling the content present in the notification. o The watcher compares tuple ids to the tuple ids received in the previous notifications. If a tuple id in the notification matches an existing tuple id, the existing tuple is replaced with the newly received in the notification. If the tuple id does not match to those received in the earlier notifications, it is stored as a new tuple. o If the presence document includes the "removed" element the tuples which ids are listed are removed from the local storage. o Tuples whose ids are missing in the NOTIFY remain unchanged. In case the watcher receives a notification with the "version" attribute value higher than the locally stored value by more than one, the watcher assumes that one or more NOTIFYs were lost. The watcher SHOULD either refresh the subscription within the existing dialog in order to receive a full presence document or terminate the subscription. If the watcher receives a notification with the "state" attribute's value "partial" and the "version" attribute's value is equal or smaller than the one in the previous notification, it is considered a PS failure and the watcher SHOULD either refresh or terminate the subscription. All information received in the notification which is located outside the element must be processed as specified in [4] i.e., the watcher must replace the existing data with data received in the Lonnfors, et al. Expires July 21, 2004 [Page 7] Internet-Draft Partial notification January 2004 latest notification. In case the PS changes the content type used in notifications within the existing dialog the watcher must discard all previously received presence information from that particular presentity and process the new content as specified for that content type. 5. Examples The following message flow shows an example applying the partial notifications mechanism. The watcher sends a SUBSCRIBE request including the default presence format (PIDF) and the content type for the partial notification in the Accept header field. The watcher uses the qvalue parameter to set the preference for receiving partial notifications. The PS accepts the subscription and based on the qvalue information selects to send partial notifications in NOTIFY requests. The first NOTIFY request includes the full state of presence information represented in the 'application/pidf-partial+xml' content type. The following notifications only include the delta of the presence information from the previous NOTIFY request. Watcher Presence Server PUA | F1 SUBSCRIBE | | |-------------------------->| | | F2 200 OK | | |<--------------------------| | | F3 NOTIFY | | |<--------------------------| | | F4 200 OK | | |-------------------------->| | | | | | | Update presence | | |<----------------------- | | | | | F5 NOTIFY | | |<--------------------------| | | F6 200 OK | | |-------------------------->| | Message Details F1 SUBSCRIBE watcher->example.com server SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/TCP watcherhost.example.com; Lonnfors, et al. Expires July 21, 2004 [Page 8] Internet-Draft Partial notification January 2004 branch=z9hG4bKnashds7 To: sip:resource@example.com From: sip:watcher@somewhere.com ;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 17766 SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml;q=0.3, application/pidf-partial+xml;q=1 Contact: user@watcherhost.example.com Expires: 600 F2 200 OK example.com server->watcher The Presence Server accepts the subscription and based on the qvalue information in the Accept header uses the partial notifications. (See that the value 'application/pidf-partial+xml' in the Content-Type header). SIP/2.0 200 OK Via: SIP/2.0/TCP watcherhost.example.com; branch=z9hG4bKnashds7 ;received=192.0.2.1 To: sip:resource@example.com;tag=ffd2 From: sip:watcher@somewhere.com;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 17766 SUBSCRIBE Event: presence Expires: 600 Contact: sip:server.example.com F3 NOTIFY example.com server-> watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCP server.example.com; branch=z9hG4bKna998sk To: sip:watcher@somewhere.com;tag=xfg9 From: sip:resource@example.com;tag=ffd2 Call-ID: 2010@watcherhost.example.com Event: presence Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: sip:server.example.com Content-Type: application/pidf-partial+xml Content-Length: .. Lonnfors, et al. Expires July 21, 2004 [Page 9] Internet-Draft Partial notification January 2004 'application/pidf-partial+xml' document containing full presence document: open tel:09012345678 open im:pep@example.com closed sip:pep@example.com F4 200 OK watcher-> example.com server SIP/2.0 200 OK Via: SIP/2.0/TCP server.example.com; branch=z9hG4bKna998sk ;received=192.0.2.2 To: sip:watcher@somewhere.com;tag=xfg9 From: sip:resource@example.com;tag=ffd2 Call-ID: 2010@watcherhost.example.com CSeq: 8775 NOTIFY F5 NOTIFY example.com server -> watcher It is the local policy issue to construct the 'application/pidf-partial+xml' formated document including the delta from the previous NOTIFY. Note that the tuple which id "r1230d" was deleted. Lonnfors, et al. Expires July 21, 2004 [Page 10] Internet-Draft Partial notification January 2004 NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCP server.example.com; branch=z9hG4bKna998sl To: sip:watcher@somewhere.com;tag=xfg9 From: sip:resource@example.com;tag=ffd2 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY Event: presence Subscription-State: active;expires=543 Max-Forwards: 70 Contact: sip:server.example.com Content-Type: application/pidf-partial+xml Content-Length: ... New 'application/pidf-partial+xml document containing partial presence document: r1230d closed im:pep@examploe.com This is an update of existing tuple sent in previous notification open im:mac@hut.com This is a completely new tuple not sent in previous notification F6 200 OK watcher-> example.com server SIP/2.0 200 OK Lonnfors, et al. Expires July 21, 2004 [Page 11] Internet-Draft Partial notification January 2004 Via: SIP/2.0/TCP server.example.com; branch=z9hG4bKna998sl ;received=192.0.2.2 To: sip:watcher@somewhere.com;tag=xfg9 From: sip:resource@example.com;tag=ffd2 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY 6. Security Considerations This specification relies on presence event package [4] and it does not introduce any new protocol functionality. Partial notifications can reveal information what has changed compared to last time when notificatiuon was sent. This can make it easier for evesdropper to know what kind of changes are happening in presentity's presence information. However, same information can be found if presence event package is used with baseline PIDF [6]. Thus, this specification does not introduce any new security conciderations compared to presence event package [4]. Presence related security considerations are extensively discussed in [4] and all those identified security consideration apply to this document as well. Issues described in [4] are briefly reviewed below. 6.1 Confidentiality Confidentiality considerations identified in [4] apply here without any changes. 6.2 Message Integrity and Authenticity Message Integrity and Authenticity identified in [4] apply here without any changes. 6.3 Outbound Authentication Outbound Authentication considerations identified in [4] apply here without any changes. 6.4 Replay Prevention Replay Prevention considerations identified in [4] apply here without any changes. 6.5 Denial of Service Attacks Against Third Parties Lonnfors, et al. Expires July 21, 2004 [Page 12] Internet-Draft Partial notification January 2004 Denial of Service Attacks Against Third Parties considerations identified in [4] apply here without any changes. 6.6 Denial Of Service Attacks Against Servers Denial Of Service Attacks Against Servers considerations identified in [4] apply here without any changes. 7. Acknowledgements The authors would like to thank Jyrki Aarnos, Jonathan Rosenberg, Dean Willis, Kriztian Kiss, Juha Kalliokulju and Tim Moran for their valuable comments. Normative references [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Lonnfors, M., Khartabil, H. and E. Leppanen, "Presence Information Data Format (PIDF) Extension for Partial Presence", draft-ietf-simple-partial-pidf-format-00 (work in progress), January 2004. [3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [4] Rosenberg, J., "SIP Extensions for Presence", draft-ietf-simple-presence-10 (work in progress), January 2003. [5] 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. [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and J. Peterson, "CPIM presence information data format", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. [7] Roach, A., "SIP-Specific Event Notification", RFC 3265, June 2002. Informative references [8] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-winfo-package-05 (work in progress), January 2003. Lonnfors, et al. Expires July 21, 2004 [Page 13] Internet-Draft Partial notification January 2004 [9] Olson, S., "Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", draft-ietf-sip-content-indirect-mech-03 (work in progress), February 2003. [10] Price, R., "Signaling Compression (SigComp)", RFC 3320, January 2003. Authors' Addresses Mikko Lonnfors Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland Phone: +358 71 8008000 EMail: mikko.lonnfors@nokia.com Jose Costa-Requena Nokia Valimotie 9 00380 Helsinki Finland Phone: +358 71 8008000 EMail: jose.costa-requena@nokia.com Eva Leppanen Nokia P.O BOX 785 Tampere Finland Phone: +358 7180 77066 EMail: eva-maria.leppanen@nokia.com Lonnfors, et al. Expires July 21, 2004 [Page 14] Internet-Draft Partial notification January 2004 Hisham Khartabil Nokia P.O. Box 321 Helsinki Finland Phone: +358 7180 76161 EMail: hisham.khartabil@nokia.com Lonnfors, et al. Expires July 21, 2004 [Page 15] Internet-Draft Partial notification January 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Lonnfors, et al. Expires July 21, 2004 [Page 16] Internet-Draft Partial notification January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Lonnfors, et al. Expires July 21, 2004 [Page 17]