SIMPLE WG M. Lonnfors Internet-Draft Nokia Research Center Expires: December 18, 2003 J. Costa-Requena E. Leppanen H. Khartabil Nokia June 19, 2003 Partial Notification of Presence Information draft-lonnfors-simple-partial-notify-02 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 December 18, 2003. Copyright Notice Copyright (C) The Internet Society (2003). 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. Other limitations can be caused by the interface between the terminal and the network, i.e. over 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 efficiency, by introducing a mechanism called partial notification. Lonnfors, et al. Expires December 18, 2003 [Page 1] Internet-Draft Partial notifications June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction of the partial notification mechanism . . . . . 4 3.1 Normal presence server operation . . . . . . . . . . . . . . 4 3.2 Operation of the partial notification . . . . . . . . . . . 4 4. Client and server operations . . . . . . . . . . . . . . . . 5 4.1 Content-type for partial notifications . . . . . . . . . . . 5 4.2 Watcher generating 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 5.1 URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf-partial' . . . . . . . . . . . 8 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1 Changes since -00 . . . . . . . . . . . . . . . . . . . . . 15 10.2 Changes since -01 . . . . . . . . . . . . . . . . . . . . . 16 Normative references . . . . . . . . . . . . . . . . . . . . 16 Informative references . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . 19 Lonnfors, et al. Expires December 18, 2003 [Page 2] Internet-Draft Partial notifications June 2003 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). It may not be reasonable to send the complete presence information over low bandwidth and high latency links when only part of that information changes. This may end up degrading the presence service and causing bad perception at the watcher side. Presence based applications in wireless terminals have certain limitations because it is envisioned that the presence service may demand high bandwidth. Requirements for wireless environments can be found in [12]. There are some mechanisms, such as signaling compression [14] and content indirection [11], [10] that might be used to help in this problem. However, none of the existing solutions are optimal because they 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 these problems, called Partial Notifications. Requirements for this mechanism are presented in [3]. Other set of requirements can be found from [12]. The idea is already identified by the SIP Extensions for Presence document [4] as a potential solution. In general, the partial notification approach means that the Presence Server (PS) delivers to the watchers only those parts of the presence information that have changed compared to the presence information sent in the previous notification. Note that partial notification is not IMPP compliant. This document introduces a new MIME-Type 'application/pidf- partial+xml'. 2. Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", Lonnfors, et al. Expires December 18, 2003 [Page 3] Internet-Draft Partial notifications June 2003 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Introduction of the partial notification mechanism This chapter briefly introduces the current functionality of the presence service, and gives an overview of the partial notification solution and new items needed to implement it. 3.1 Normal 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, 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 [2] 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 of the partial notification The mechanism for implementing the partial notification consists of defining a new content type. The new content type is named as 'application/pidf-partial+xml'. It is similar to PIDF [6] except that it adds new XML items to element in order to enable the partial notifications. The new XML attributes are "version" and "state". The new XML element is "removed". The "version" attribute is a sequence number that is progressively incremented for each watcher when notification is sent. The "state" attribute indicates the nature of the presence information included in the notified document, whether it contains full or partial state corresponding to the cases when the full presence information or only changed parts of the presence information are delivered. The use of these attributes is similar to the watcher information template package [9]. In the scope of this document the partial updates apply only to Lonnfors, et al. Expires December 18, 2003 [Page 4] Internet-Draft Partial notifications June 2003 level XML elements and everything what is contained inside these elements, in other words: tuples are considered to be atomic data elements. This means the 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 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 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 Presence Server 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 server. 4.4 Notifier generating partial notifications If the content type negotiation between the watcher and the PS resulted in the agreement to use partial notifications, then the PS MUST use the 'application/pidf-partial+xml' content type in the NOTIFY requests. Lonnfors, et al. Expires December 18, 2003 [Page 5] Internet-Draft Partial notifications June 2003 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 presence document according to the following logic: o The delivered presence information is constructed according to [4] in such a way that only the changed tuples are delivered. New tuples are also be added to the presence information, if any. o The "version" and "state" attributes are also 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. The version number should follow the COUNTER32 format so that after reaching the maximum value it starts from zero [15]. 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 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 notifications MUST always have that data. 4.5 Watcher processing of partial notifications If the negotiation between the watcher and the PS resulted in the agreement to use the partial notifications, then the watcher receives 'application/pidf-partial+xml' content type in the NOTIFY requests. The watcher receives the full state of the presence information according to [4] in the first notification using the partial notifications. In this case, the "state" element of the presence document has the value "full". When the watcher receives the full state notification it MUST perform the following actions: Lonnfors, et al. Expires December 18, 2003 [Page 6] Internet-Draft Partial notifications June 2003 o The watcher MUST discard all previously received presence information from that particular presentity. o The watcher MUST initialize an internal version counter, related that particular presentity or subscription, to the value received in the notification. o The watcher MUST store the values of all tuple IDs together with the content received in the notification. When the watcher receives subsequent notifications and the PS has not changed the used content type, the presence document includes only those tuples that have changed compared to the previous notification. The "state" element includes the value of "partial" telling to the watcher that the notification includes partial information. 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 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 partial notification with the "version" attribute value higher than the stored value by more than one, the watcher assumes that one or more NOTIFY were lost and SHOULD either refresh the subscription within the existing dialog in order to receive a complete update (full state) of the presence information or terminate the subscription. If the watcher receives a notification with "state" attribute value "partial" and the "version" attribute value 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 Lonnfors, et al. Expires December 18, 2003 [Page 7] Internet-Draft Partial notifications June 2003 watcher must replace the existing data with data received in the 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. IANA Considerations This memo calls for IANA to register a new XML namespace URN per [8]. A new content type 'application/pidf-partial+xml' is defined to represent an XML MIME for the partial presence information content. This specification follows the guidelines of RFC3023 [13]. 5.1 URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf-partial' URI: uurn:ietf:params:xml:ns:pidf-partial Description: This is the XML namespace for XML elements defined by [[[RFCXXXX]]] to describe the 'application/pidf-partial+xml' content type for partial notifications. Registrant Contact: IETF, SIMPLE working group, Mikko Lonnfors, XML: Lonnfors, et al. Expires December 18, 2003 [Page 8] Internet-Draft Partial notifications June 2003 BEGIN PIDF extension for partial notifications

Namespace for PIDF extension for partial notifications

application/pidf-partial+xml

See RFCXXXX.

END 6. Examples The following message flow show an example applying the partial notifications mechanism. The document of the 'application/ pidf-partial+xml' format mentioned in the message details is constructed according to the XML schema described in the chapter Section 7. 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 | | |-------------------------->| | | | | Lonnfors, et al. Expires December 18, 2003 [Page 9] Internet-Draft Partial notifications June 2003 | | 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;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/cpim-pidf+xml;q=0.3, application/pidf-partial+xml;q=1 Contact: user@watcherhost.example.com Expires: 600 Content-Length: 0 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 notitifcations. (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 Content-Length: 0 F3 NOTIFY example.com server-> watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Lonnfors, et al. Expires December 18, 2003 [Page 10] Internet-Draft Partial notifications June 2003 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: .. PIDF-PARTIAL+XML Document with FULL STATE information: 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 Content-Length: 0 F5 NOTIFY example.com server -> watcher Lonnfors, et al. Expires December 18, 2003 [Page 11] Internet-Draft Partial notifications June 2003 It is the local policy issue to construct the 'PIDF-partial+xml' formated document including the delta from the previous NOTIFY. Note that the tuple which id was "r1230d" was deleted. 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 PIDF-PARTIAL+XML Document with PARTIAL STATE information: 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 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl ;received=192.0.2.2 To: sip:watcher@somewhere.com;tag=xfg9 Lonnfors, et al. Expires December 18, 2003 [Page 12] Internet-Draft Partial notifications June 2003 From: sip:resource@example.com;tag=ffd2 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY Content-Length: 0 7. XML Schema The XML schema for the 'pidf-partial+xml' data format. Lonnfors, et al. Expires December 18, 2003 [Page 13] Internet-Draft Partial notifications June 2003 Lonnfors, et al. Expires December 18, 2003 [Page 14] Internet-Draft Partial notifications June 2003 This attribute may be used on any element within an optional PIDF extension to indicate that the corresponding element must be understood by the PIDF processor if the enclosing optional element is to be handled. 8. Security Considerations Presence information may contain highly sensitive information about the presentities. Presence related security considerations are extensively discussed in [4] and all those identified security consideration apply to this document as well. Partial notification mechanism does not add anything new which (in term of the security) is not already specified in [4] and [5]. Thus no new security considerations are introduced here. 9. Acknowledgements The authors would like to thank Jyrki Aarnos, Jonathan Rosenberg, Dean Willis, Kriztian Kiss, Juha Kalliokulju and Tim Moran for their valuable comments. 10. Changes 10.1 Changes since -00 o Section comparing the existing mechanisms removed. o Solution on the removal of the tuple changed. Texts, XML Schema and examples modified accordinly. o Reduntant texts and issues specified in other specifications Lonnfors, et al. Expires December 18, 2003 [Page 15] Internet-Draft Partial notifications June 2003 removed. o Other editorial changes, e.g., more normative style, references devided into Informal and Normative. 10.2 Changes since -01 o Open issues concerning the usage of Require header was solved by the qvalue, and caused changes were incorporated to the text. o Open issue concerning the change of content type in mid-dialog incorporated to the text. Normative references [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [3] Lonnfors, M., Leppanen, E., Requena, J. and H. Khartabil, "Requirements for Efficient Delivery of Presence Information", draft-ietf-simple-presinfo-deliv-reg-00 (work in progress), April 2003. [4] Rosenberg, J., "SIP Extensions for Presence", draft-ietf-simple-presence-10 (work in progress), January 2003. [5] Rosenberg, J., "SIP: Session Initiation Protocol", RFC 3261, June 2002. [6] Sugano, H., "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] Mealling, M., "The IETF XML Registry", draft-mealling-iana-xmlns-registry-04 (work in progress), June 2002. [9] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-winfo-package-05 (work in progress), January Lonnfors, et al. Expires December 18, 2003 [Page 16] Internet-Draft Partial notifications June 2003 2003. [10] Khartabil, H., "Congestion safety and Content Indirection", draft-khartabil-sip-congestionsafe-ci-02 (work in progress), March 2003. [11] Olson, S., "Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", draft-ietf-sip-content-indirect-mech-02 (work in progress), February 2003. [12] Kiss, K., "Requirements for Presence Service based on 3GPP specifications and wireless environment characheristics", draft-kiss-simple-presence-wireless-reqs-01 (work in progress), February 2003. [13] Murata, M., "XML media types", RFC 3023, January 2001. [14] Price, R., "Signaling Compression (SigComp)", RFC 3320, January 2003. [15] McCloghrie, K., "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999. Authors' Addresses Mikko Lonnfors Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland Phone: +358 50 4836402 EMail: mikko.lonnfors@nokia.com Jose Costa-Requena Nokia Valimotie 9 00380 Helsinki Finland Phone: +358 71 8008000 EMail: jose.costa-requena@nokia.com Lonnfors, et al. Expires December 18, 2003 [Page 17] Internet-Draft Partial notifications June 2003 Eva Leppanen Nokia P.O BOX 785 Tampere Finland Phone: +358 7180 77066 EMail: eva-maria.leppanen@nokia.com Hisham Khartabil Nokia P.O. Box 321 Helsinki Finland Phone: +358 7180 76161 EMail: hisham.khartabil@nokia.com Lonnfors, et al. Expires December 18, 2003 [Page 18] Internet-Draft Partial notifications June 2003 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 (2003). 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 December 18, 2003 [Page 19] Internet-Draft Partial notifications June 2003 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 December 18, 2003 [Page 20]