summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5263.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5263.txt')
-rw-r--r--doc/rfc/rfc5263.txt899
1 files changed, 899 insertions, 0 deletions
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 <pidf-full>
+ 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 <add>
+ elements. All information that has been removed from the presence
+ document is listed inside <remove> elements, and all information
+ that has been changed is listed under <replace> 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
+ <pidf-full> 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 <pidf-full>, 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 <pidf-diff> 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 <pidf-diff> 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: <sip:resource@example.com>
+ From: <sip:watcher@example.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-diff+xml;q=1
+ Contact: <sip:user@watcherhost.example.com>
+ 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: <sip:resource@example.com>;tag=ffd2
+ From: <sip:watcher@example.com>;tag=xfg9
+ Call-ID: 2010@watcherhost.example.com
+ CSeq: 17766 SUBSCRIBE
+ Event: presence
+ Expires: 3600
+ Contact: <sip:server.example.com>
+ 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: <sip:watcher@example.com>;tag=xfg9
+ From: <sip:resource@example.com>;tag=ffd2
+ Call-ID: 2010@watcherhost.example.com
+ Event: presence
+ Subscription-State: active;expires=3599
+ Max-Forwards: 70
+ CSeq: 8775 NOTIFY
+ Contact: <sip:server.example.com>
+ Content-Type: application/pidf-diff+xml
+ Content-Length: ...
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
+ xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
+ xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
+ xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
+ xmlns:cp="urn:ietf:params:xml:ns:pidf:cipid"
+ xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
+ entity="sip:resource@example.com"
+ version="1">
+
+
+
+Lonnfors, et al. Standards Track [Page 9]
+
+RFC 5263 Partial Notification September 2008
+
+
+ <tuple id="sg89ae">
+ <status>
+ <basic>open</basic>
+ </status>
+ <c:servcaps>
+ <c:audio>true</c:audio>
+ <c:video>false</c:video>
+ <c:message>true</c:message>
+ </c:servcaps>
+ <r:relationship><r:assistant/></r:relationship>
+ <contact priority="0.8">tel:09012345678</contact>
+ </tuple>
+
+ <tuple id="cg231jcr">
+ <status>
+ <basic>open</basic>
+ </status>
+ <contact priority="1.0">im:res@example.com</contact>
+ </tuple>
+
+ <tuple id="r1230d">
+ <status>
+ <basic>closed</basic>
+ </status>
+ <cp:homepage>http://example.com/~res/</cp:homepage>
+ <cp:icon>http://example.com/~res/icon.gif</cp:icon>
+ <cp:card>http://example.com/~res/card.vcd</cp:card>
+ <contact priority="0.9">sip:resource@example.com</contact>
+ </tuple>
+
+ <note xml:lang="en">Full state presence document</note>
+
+ <dm:person id="fdkfj">
+ <r:activities>
+ <r:on-the-phone/>
+ <r:busy/>
+ </r:activities>
+ </dm:person>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lonnfors, et al. Standards Track [Page 10]
+
+RFC 5263 Partial Notification September 2008
+
+
+ <dm:device id="u00b40c7">
+ <c:devcaps>
+ <c:mobility>
+ <c:supported>
+ <c:mobile/>
+ </c:supported>
+ </c:mobility>
+ </c:devcaps>
+ <dm:deviceID>mac:xxx</dm:deviceID>
+ </dm:device>
+
+ </p:pidf-full>
+
+ 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@example.com>;tag=xfg9
+ From: <sip:resource@example.com>;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: <sip:watcher@example.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=3543
+ Max-Forwards: 70
+ Contact: <sip:server.example.com>
+ Content-Type: application/pidf-diff+xml
+ Content-Length: ...
+
+
+
+
+
+
+
+Lonnfors, et al. Standards Track [Page 11]
+
+RFC 5263 Partial Notification September 2008
+
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <p:pidf-diff xmlns="urn:ietf:params:xml:ns:pidf"
+ xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
+ xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
+ xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
+ entity="sip:resource@example.com"
+ version="2">
+
+ <p:add sel="presence/note" pos="before"><tuple id="ert4773">
+ <status>
+ <basic>open</basic>
+ </status>
+ <contact priority="0.4">mailto:res@example.com</contact>
+ <note xml:lang="en">This is a new tuple inserted
+ between the last tuple and note element</note>
+ </tuple>
+
+ </p:add>
+
+ <p:replace sel="*/tuple[@id='r1230d']/status/basic/text()"
+ >open</p:replace>
+
+ <p:remove sel="*/dm:person/r:activities/r:busy"/>
+
+ <p:replace sel="*/tuple[@id='cg231jcr']/contact/@priority"
+ >0.7</p:replace>
+
+ </p:pidf-diff>
+
+ 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@example.com>;tag=xfg9
+ From: <sip:resource@example.com>;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]
+