From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5263.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc5263.txt (limited to 'doc/rfc/rfc5263.txt') diff --git a/doc/rfc/rfc5263.txt b/doc/rfc/rfc5263.txt new file mode 100644 index 0000000..db6eece --- /dev/null +++ b/doc/rfc/rfc5263.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group M. Lonnfors +Request for Comments: 5263 J. Costa-Requena +Category: Standards Track E. Leppanen + Nokia + H. Khartabil + Ericsson + September 2008 + + + Session Initiation Protocol (SIP) Extension for + Partial Notification of Presence Information + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + By default, presence delivered using the presence event package for + the Session Initiation Protocol (SIP) is represented in the Presence + Information Data Format (PIDF). A PIDF document contains a set of + elements, each representing a different aspect of the presence being + reported. When any subset of the elements change, even just a single + element, a new document containing the full set of elements is + delivered. This memo defines an extension allowing delivery of only + the presence data that has actually changed. + + + + + + + + + + + + + + + + + + + + + +Lonnfors, et al. Standards Track [Page 1] + +RFC 5263 Partial Notification September 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Introduction to the Partial Notification Mechanism . . . . . . 3 + 3.1. Basic Presence Agent Operation . . . . . . . . . . . . . . 3 + 3.2. Operation with Partial Notification . . . . . . . . . . . 3 + 4. Client and Server Operations . . . . . . . . . . . . . . . . . 4 + 4.1. Content-Type for Partial Notifications . . . . . . . . . . 4 + 4.2. Watcher Generation of SUBSCRIBE Requests . . . . . . . . . 4 + 4.3. Presence Agent Processing of SUBSCRIBE Requests . . . . . 4 + 4.4. Presence Agent Generation of Partial Notifications . . . . 5 + 4.5. Watcher Processing of NOTIFY Requests . . . . . . . . . . 6 + 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 + +1. Introduction + + A presence event package for Session Initiation Protocol (SIP) [3] + allows 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 + RFC 2778 [9] and the presence event package for SIP [3], a Presence + Agent (PA) always delivers in presence notifications all the presence + data that has been authorized for a certain watcher. This is done + regardless of 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 the presence information has actually changed. This may end up + degrading the presence service and causing bad perception at the + watcher side. + + This document defines a partial notification approach where 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 is transported over the network. + + This mechanism utilizes the presence event package for SIP [3] and a + new MIME type for carrying partial Presence Information Data Format + documents [2]. + + + +Lonnfors, et al. Standards Track [Page 2] + +RFC 5263 Partial Notification September 2008 + + +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 RFC 2778 [9], + RFC 3265 [6], the presence event package for SIP [3], and the PIDF + extension for Partial Presence [2]. + +3. Introduction to the Partial Notification Mechanism + + This chapter briefly introduces the regular functionality of the + presence service, and gives an overview of the partial notification + solution. This section is informational in nature. It does not + contain any normative statements. + +3.1. Basic Presence Agent Operation + + The presence service normally operates so that a watcher sends a SIP + SUBSCRIBE request targeted to the presentity. The request is routed + to the presence agent where the presentity's presence information is + stored. The SUBSCRIBE request can include an Accept header field + that indicates the supported content types. + + The presence agent receives the SUBSCRIBE request and if there is no + Accept header indicating the supported content types or the Accept + header contains the default PIDF content type, the PA will generate + presence notifications using the default PIDF format [5]. The PIDF + document can contain one or multiple XML elements. The PIDF document + includes a set of elements defined in RFC 2778 [9], and its + extensions for representing the presence information. This PIDF + document will be carried in the body of a NOTIFY request constructed + as per RFC 3265 [6]. During basic operation, the presence document + always contains the full state corresponding to the presence status + of the presentity, as determined by the PA local policy and + authorization rules. + +3.2. Operation with Partial Notification + + The partial notification mechanism allows a watcher to request that, + whenever possible, notifications contain only presence information + that has actually changed. A watcher that wants to receive partial + notifications according to this document, creates a SIP SUBSCRIBE + request similar to that of a regular presence subscription. However, + the SIP SUBSCRIBE request contains an Accept header field whose value + + + + +Lonnfors, et al. Standards Track [Page 3] + +RFC 5263 Partial Notification September 2008 + + + contains the "application/pidf-diff+xml" tag as well as the + "application/pidf+xml" tag. + + When the presence agent receives the subscription, it examines the + Accept header field value and if the "application/pidf-diff+xml" + value is present, it can decide to use the partial notifications + mechanism specified in this memo. The presence agent builds NOTIFY + requests that contain the Content-Type header field set to + "application/pidf-diff+xml". The first NOTIFY request that contains + presence information will contain a full presence document. + Subsequent NOTIFY requests can contain partial presence documents. + This behavior is described in detail in Section 4. + +4. Client and Server Operations + + Unless otherwise specified in this document, the regular watcher and + presence agent behavior is applied as defined in the SIP presence + event package [3]. + +4.1. Content-Type for Partial Notifications + + Entities supporting the partial notification extension described in + this document MUST support the 'application/pidf-diff+xml' content + type specified in the PIDF extension for partial presence [2]. + +4.2. Watcher Generation of SUBSCRIBE Requests + + A SUBSCRIBE request can be used to negotiate the preferred content + type to be used in the notifications. The Accept header field is + used for this purpose as specified in RFC 3261 [4]. When a watcher + wants to allow the presence agent to send partial notifications the + watcher MUST include an Accept header field in its SUBSCRIBE request. + The value of the Accept header field MUST contain 'application/ + pidf-diff+xml' (in addition to 'application/pidf+xml' required by the + SIP presence event package [3]). The watcher MAY include a "q" + parameter with each Accept value to indicate the relative preference + of that value. + +4.3. Presence Agent Processing of SUBSCRIBE Requests + + The presence agent receives subscriptions from watchers and generates + notifications according to the SIP presence event package [3]. If + the watcher has indicated the supported content types in the Accept + header field of the SUBSCRIBE request, the presence agent compares + the values included in the Accept header field with the supported + ones, and decides which one to use. If the watcher has indicated + preferred accept values by means of "q" parameters, the presence + + + + +Lonnfors, et al. Standards Track [Page 4] + +RFC 5263 Partial Notification September 2008 + + + agent SHOULD base the decision on those preferences, unless otherwise + indicated by the presence agent local policy. + +4.4. Presence Agent Generation of Partial Notifications + + Once a subscription is accepted and installed, the PA MUST deliver + the full state of the presence information in the first partial + notification that contains a presence document having + root element. If the presence agent decides to send notifications + that include a presence document according to this specification, the + presence agent MUST build a presence document according to the PIDF + extension for Partial Presence [2] and MUST set the Content-Type + header field to the value 'application/pidf-diff+xml'. + + When using the 'application/pidf-diff+xml' MIME type, the PA MUST + include a "version" attribute; for the first partial notification + (within a given subscription), the PA MUST initialize version to + value one (1). This version counter is scoped to the subscription, + and is incremented by one within each partial notification. The + version value is only reset when the given subscription is + terminated. It is not reset when the subscription is refreshed. + + When the PA generates a partial presence document, the PA SHOULD + include only that presence information that has changed compared to + the previous notifications. It is up to the PA's local policy to + determine what is considered as a change to the previous state. + + The PA MUST construct the partial presence document according to the + following logic: + + o The PA MUST construct the presence information according to the + PIDF extension for Partial Presence [2]. All the information that + has been added to the presence document is listed inside + elements. All information that has been removed from the presence + document is listed inside elements, and all information + that has been changed is listed under elements. + + o The PA MUST include a "version" attribute in the presence + document. The PA MUST increment the version number by one + compared to the earlier successfully sent presence document in the + PIDF extension for Partial Presence [2] format to the watcher + associated with a certain subscription. + + The PA MUST NOT send a new NOTIFY request that contains a partial + notification for the same Request-URI until it has received a final + response from the watcher for the previous one or the previous NOTIFY + request has timed out. + + + + +Lonnfors, et al. Standards Track [Page 5] + +RFC 5263 Partial Notification September 2008 + + + When the PA receives a SUBSCRIBE request (refresh or termination) + within the associated subscription, it SHOULD send a NOTIFY request + containing the full presence document. + + If the PA has used other than the 'application/pidf-diff+xml' content + type in notifications within the existing subscription, and changes + to deliver partial notifications, the PA MUST deliver the full state + of the presence information containing a presence document having + root element as the first partial notification. + +4.5. Watcher Processing of NOTIFY Requests + + Watcher processes all NOTIFY requests that contain 'application/ + pidf+xml' content type as specified in RFC 3856 [3]. + + When the watcher receives the first notification containing the + 'application/pidf-diff+xml' MIME body the watcher MUST initialize an + internal version counter, related to this subscription, to the value + of the "version" included in the presence document. This version + counter is scoped to the subscription. The watcher MUST also store + the received full presence document as its local copy. + + When the watcher receives a subsequent 'application/pidf-diff+xml' + encoded presence document the watcher MUST compare the received + "version" attribute with the local version counter. If the watcher + receives a presence document with the "version" attribute value equal + or lower than the locally stored version number, it is considered a + PA failure, and the watcher SHOULD discard the document without + further processing. Otherwise, the watcher MUST modify its locally + stored information according to the following logic: + + o If the root element of the presence document is , the + watcher must replace its local copy of the presence document with + the presence document received in the 'application/pidf-diff+xml' + body and set the internal version value to the value of the + "version" attribute included in the presence document. + + o If the root element of the presence document is and + the received version number is incremented by one compared with + the local version counter, the watcher MUST apply the changes to + its local copy of the full presence document indicated in the + received 'application/pidf-diff+xml' document as specified in PIDF + extension for Partial Presence [2]. The watcher MUST increment + the local version counter by one. + + + + + + + +Lonnfors, et al. Standards Track [Page 6] + +RFC 5263 Partial Notification September 2008 + + + o If the root element of the presence document is and + the received "version" value is higher by more than one compared + with the locally stored value, the watcher assumes that one or + more NOTIFYs were lost. The watcher SHOULD either refresh the + subscription in order to receive a full presence document or + terminate the subscription. + + If the watcher encounters a processing error while processing the + received 'application/pidf-diff+xml' encoded presence document, look + at Section 5.1 of [8]. In this case, the watcher SHOULD renew the + subscription. The watcher MAY also fall back to normal presence + operations by not inserting 'application/pidf-diff+xml' in a new + SUBSCRIBE request. It is hardly reasonable to signal this error to + the notifier even if the error exists in the notifier process. + + If the PA changes the content type used in notifications within the + existing subscription, the watcher MUST discard all the previously + received presence information (except local version counter) from + that particular presentity and process the new content as specified + for that content type. The local version counter MUST NOT be + discarded because if the PA changes back to 'application/ + pidf-diff+xml', the MIME type version counter will continue to + increase from the last version value. + +5. Examples + + The following message flow shows an example applying the partial + notifications mechanism. + + A watcher sends a SUBSCRIBE request declaring support for the default + presence format ('application/pidf+xml) and for the partial + notification format ('application/pidf-diff+xml') in the Accept + header field value. The watcher uses the "q" parameter to set the + preference for receiving partial notifications. The PA accepts the + subscription and, based on the "q" parameter value, selects to send + partial notifications in NOTIFY requests. The first NOTIFY request + includes the full state of presence information. The following + notifications only include information about delta of the presence + information from the previous NOTIFY requests. + + + + + + + + + + + + +Lonnfors, et al. Standards Track [Page 7] + +RFC 5263 Partial Notification September 2008 + + + Watcher Presence Agent 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; + branch=z9hG4bKnashds7 + To: + From: ;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-diff+xml;q=1 + Contact: + Expires: 3600 + Content-Length: 0 + + + + + + + + + + + + + + + +Lonnfors, et al. Standards Track [Page 8] + +RFC 5263 Partial Notification September 2008 + + + The PA accepts the subscription and generates a 200 OK response + to the SUBSCRIBE request + + F2 200 OK example.com server ->watcher + + SIP/2.0 200 OK + Via: SIP/2.0/TCP watcherhost.example.com; + branch=z9hG4bKnashds7 + ;received=192.0.2.1 + To: ;tag=ffd2 + From: ;tag=xfg9 + Call-ID: 2010@watcherhost.example.com + CSeq: 17766 SUBSCRIBE + Event: presence + Expires: 3600 + Contact: + Content-Length: 0 + + The PA, based on the "q" parameter value in the Accept header + of the SUBSCRIBE request (F1), decides to use partial + notifications. The PA creates the first NOTIFY request that + includes the full presence document. + + 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: ;tag=xfg9 + From: ;tag=ffd2 + Call-ID: 2010@watcherhost.example.com + Event: presence + Subscription-State: active;expires=3599 + Max-Forwards: 70 + CSeq: 8775 NOTIFY + Contact: + Content-Type: application/pidf-diff+xml + Content-Length: ... + + + + + + +Lonnfors, et al. Standards Track [Page 9] + +RFC 5263 Partial Notification September 2008 + + + + + open + + + true + false + true + + + tel:09012345678 + + + + + open + + im:res@example.com + + + + + closed + + http://example.com/~res/ + http://example.com/~res/icon.gif + http://example.com/~res/card.vcd + sip:resource@example.com + + + Full state presence document + + + + + + + + + + + + + + + + + + + + +Lonnfors, et al. Standards Track [Page 10] + +RFC 5263 Partial Notification September 2008 + + + + + + + + + + + mac:xxx + + + + + 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: ;tag=xfg9 + From: ;tag=ffd2 + Call-ID: 2010@watcherhost.example.com + CSeq: 8775 NOTIFY + Content-Length: 0 + + At a later time, the presentity's presence information + changes. The PA generates a NOTIFY request + that includes information about the changes. + + F5 NOTIFY example.com server -> watcher + + NOTIFY sip:user@watcherhost.example.com SIP/2.0 + Via: SIP/2.0/TCP server.example.com; + branch=z9hG4bKna998sl + To: ;tag=xfg9 + From: ;tag=ffd2 + Call-ID: 2010@watcherhost.example.com + CSeq: 8776 NOTIFY + Event: presence + Subscription-State: active;expires=3543 + Max-Forwards: 70 + Contact: + Content-Type: application/pidf-diff+xml + Content-Length: ... + + + + + + + +Lonnfors, et al. Standards Track [Page 11] + +RFC 5263 Partial Notification September 2008 + + + + + + + + open + + mailto:res@example.com + This is a new tuple inserted + between the last tuple and note element + + + + + open + + + + 0.7 + + + + 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: ;tag=xfg9 + From: ;tag=ffd2 + Call-ID: 2010@watcherhost.example.com + CSeq: 8776 NOTIFY + Content-Length: 0 + + + + + + + + + + + +Lonnfors, et al. Standards Track [Page 12] + +RFC 5263 Partial Notification September 2008 + + +6. Security Considerations + + This specification relies on the presence event package for SIP [3]. + Partial notifications can reveal information about what has changed + compared to the previous notification. This can make it easier for + an eavesdropper to know what kind of changes are happening in the + presentity's presence information. However, the same information can + be found if the presence event package is used with baseline PIDF + [5]. + + A third party can inject a NOTIFY request with partial state that + will cause the watcher to think it has missed a partial notification + and to request a new full presence document. This is no worse than + what we have without this extension since a party that could perform + such action could also send a NOTIFY with Subscription-State: + terminated and achieve the same effect without knowing about the + extension. Partial Notification does not make the situation any + worse, and the protection mechanisms from the existing system apply + to preventing this attack against the partial notification mechanism. + + Presence-related security considerations are extensively discussed in + the presence event package for SIP [3] and all those identified + security considerations apply to this document as well. Issues + described in the presence event package for SIP [3], including + confidentiality, message integrity and authenticity, outbound + authentication, replay prevention, Denial-of-Service (DoS) attacks + against thirst parties and DoS attacks against servers all apply here + without any change. + + It is RECOMMENDED that TLS [7] be used between elements to provide + hop-by-hop confidentially protection. Furthermore, S/MIME MAY be + used for integrity and authenticity of SUBSCRIBE and NOTIFY requests. + This is described in Section 23 of RFC 3261. + +7. Acknowledgments + + The authors would like to thank Jari Urpalainen, Jyrki Aarnos, + Jonathan Rosenberg, Dean Willis, Kriztian Kiss, Juha Kalliokulju, + Miguel Garcia, Anders Kristensen, Yannis Pavlidis, Ben Cambell, + Robert Sparks, and Tim Moran for their valuable comments. + + + + + + + + + + + +Lonnfors, et al. Standards Track [Page 13] + +RFC 5263 Partial Notification September 2008 + + +8. References + +8.1. 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., Leppanen, E., and J. Urpalainen, + "Presence Information Data Format (PIDF) Extension for Partial + Presence", RFC 5262, August 008. + + [3] Rosenberg, J., "A Presence Event Package for the Session + Initiation Protocol (SIP)", RFC 3856, August 2004. + + [4] 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. + + [5] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and + J. Peterson, "Presence Information Data Format (PIDF)", + RFC 3863, August 2004. + + [6] Roach, A., "SIP-Specific Event Notification", RFC 3265, + June 2002. + + [7] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", + RFC 4346, April 2006. + + [8] Urpalainen, J., "An Extensible Markup Language (XML) Patch + Operations Framework Utilizing XML Path Language (XPath) + Selectors", RFC 5261, September 2008. + +8.2. Informative References + + [9] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and + Instant Messaging", RFC 2778, February 2000. + + + + + + + + + + + + + + + +Lonnfors, et al. Standards Track [Page 14] + +RFC 5263 Partial Notification September 2008 + + +Authors' Addresses + + Mikko Lonnfors + Nokia + P.O. Box 321 + Helsinki + Finland + + Phone: +358 71 8008000 + EMail: mikko.lonnfors@nokia.com + + + Jose Costa-Requena + Nokia + P.O. Box 321 + Helsinki + Finland + + Phone: +358 71 8008000 + EMail: jose.costa-requena@nokia.com + + + Eva Leppanen + Nokia + Lempaala + Finland + + EMail: eva.leppanen@saunalahti.fi + + + Hisham Khartabil + Ericsson + Melbourne + Australia + + Phone: +61 416 108 890 + EMail: hisham.khartabil@gmail.com + + + + + + + + + + + + + + +Lonnfors, et al. Standards Track [Page 15] + +RFC 5263 Partial Notification September 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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. + + + + + + + + + + + + +Lonnfors, et al. Standards Track [Page 16] + -- cgit v1.2.3