One document matched: draft-ietf-simple-partial-notify-10.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<rfc ipr="full3978" category="std">
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<?rfc toc='yes'?>
<?rfc strict='yes'?>
<front>
<title abbrev="Partial notification">Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information</title>
<author fullname="Mikko Lonnfors" surname="Lonnfors" initials="M.A">
<organization>Nokia</organization>
<address>
<postal>
<street>P.O. Box 321</street>
<city>Helsinki</city>
<country>Finland</country>
</postal>
<phone>+358 71 8008000</phone>
<email>mikko.lonnfors@nokia.com</email>
</address>
</author>
<author fullname="Jose Costa-Requena" surname="Costa-Requena" initials="J.">
<organization>Nokia</organization>
<address>
<postal>
<street>P.O. Box 321</street>
<city>Helsinki</city>
<country>Finland</country>
</postal>
<phone>+358 71 8008000</phone>
<email>jose.costa-requena@nokia.com</email>
</address>
</author>
<author fullname="Eva Leppanen" surname="Leppanen" initials="E.">
<organization>Nokia</organization>
<address>
<postal>
<street></street>
<city>Lempaala</city>
<country>Finland</country>
</postal>
<email>eva.leppanen@saunalahti.fi</email>
</address>
</author>
<author fullname="Hisham Khartabil" surname="Khartabil" initials="H.">
<organization></organization>
<address>
<postal>
<street>
</street>
<city>Melbourne</city>
<country>Australia</country>
</postal>
<phone>+61 416 108 890</phone>
<email>hisham.khartabil@gmail.com</email>
</address>
</author>
<date year="2008" month="January"/>
<area>Application</area>
<workgroup>SIMPLE WG</workgroup>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>
A presence event package for Session Initiation Protocol (SIP) <xref target="RFC-presence"/> 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 RFC2778
<xref target="RFC2778"/> and the presence event package for SIP <xref target="RFC-presence"/>, 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.
</t>
<!-- REMOVED because this is not needed anymore
<t>
There are some mechanisms, such as signaling compression (SigComp) <xref target="RFC3320"/> and content indirection
<xref target="draft-CI"/> 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 force certain requirements on the network
and terminals for supporting a compression mechanism, while other solutions require having a specific server to store the
requested presence information until the terminal fetches it using another protocol (e.g. HTTP) and, therefore, increases
possible security concerns.
</t>
-->
<t>
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.
</t>
<t>
This mechanism utilizes the presence event package for SIP <xref target="RFC-presence"/> and a new MIME type for carrying partial
Presence Information Data Format documents <xref target="draft-partial-pidf"/>.
</t>
</section>
<section title="Conventions" anchor="Conventions">
<t>
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 <xref target="RFC2119"/> and
indicate requirement levels for compliant implementations.
</t>
<t>
This document makes use of the vocabulary defined in RFC2778 <xref target="RFC2778"/>, RFC3265 <xref target="RFC3265"/>,
the presence event package for SIP <xref target="RFC-presence"/>, and the PIDF extension for Partial Presence
<xref target="draft-partial-pidf"/>.
</t>
</section>
<section title="Introduction to the partial notification mechanism" anchor="Introduction-partial-notification-mechanism">
<t>
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.
</t>
<section title="Basic presence agent operation" anchor="Normal-presence-server-operation">
<t>
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.
</t>
<t>
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 <xref target="RFC-pidf"/>. The PIDF document can contain one or multiple XML elements.
The PIDF document include a set of elements defined in RFC2778 <xref target="RFC2778"/> and its extensions for representing
the presence information.
This PIDF document will be carried in the body of a NOTIFY request constructed as per RFC3265 <xref target="RFC3265"/>.
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.
</t>
</section>
<section title="Operation with partial notification" anchor="Operation-partial-notification">
<t>
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 contains the
"application/pidf-diff+xml" tag as well as the "application/pidf+xml" tag.
</t>
<t>
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
<xref target="Client-and-server-operations"/>.
</t>
</section>
</section>
<section title="Client and server operations" anchor="Client-and-server-operations">
<t>
Unless otherwise specified in this document, the regular watcher and presence agent behavior is applied as defined in the SIP presence event
package <xref target="RFC-presence"/>.
</t>
<section title="Content-type for partial notifications" anchor="content-type-for-partial-notifications">
<t>
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 <xref target="draft-partial-pidf"/>.
</t>
</section>
<section title="Watcher generation of SUBSCRIBE requests" anchor="Watcher-generating-SUBSCRIBE-requests">
<t>
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 RFC3261 <xref target="RFC3261"/>. 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 <xref target="RFC-presence"/>). The watcher MAY include a "q" parameter with each Accept
value to indicate the relative preference of that value.
</t>
</section>
<section title="Presence agent processing of SUBSCRIBE requests" anchor=" Notifier-processing-SUBSCRIBE-requests">
<t>
The presence agent receives subscriptions from watchers and generates notifications according to the SIP presence event package <xref target="RFC-presence"/>.
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 agent SHOULD base the decision on those preferences, unless otherwise indicated by the presence agent local policy.
</t>
</section>
<section title="Presence agent generation of partial notifications" anchor="Notifier-generating-of-partial-notifications">
<t>
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 <xref target="draft-partial-pidf"/> and MUST set the Content-Type header field to the value
'application/pidf-diff+xml'.
</t>
<t>
When using the 'application/pidf-diff+xml' MIME type the PA MUST include a "version" attribute and 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.
</t>
<t>
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.
</t>
<t>
The PA MUST construct the partial presence document according to the following logic:
<list style="symbols">
<t>
The PA MUST construct the presence information according to the PIDF extension for Partial Presence <xref target="draft-partial-pidf"/>.
All the information that have been added to the presence document are listed inside <add> elements. All information that have been removed from
the presence document are listed inside <remove> elements and all information that have been changed are listed under <replace> elements.
</t>
<t>
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 <xref target="draft-partial-pidf"/> format to the watcher associated with a certain subscription.
</t>
</list>
</t>
<t>
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.
</t>
<!--t>
The PA always ends a sequence of partial notifications when it receives any SUBSCRIBE request (refresh or termination) within the associated
subscription. The PA sends a NOTIFY request containing the full presence document to this SUBSCRIBE request.
</t-->
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Watcher processing of NOTIFY requests" anchor="Watcher-processing-of-partial-notifications">
<t>
Watcher processes all NOTIFY requests that contain 'application/pidf+xml' content type as specified in RFC3856 <xref target="RFC-presence"/>.
</t>
<t>
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 presence document as its local copy.
</t>
<t>
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:
<list style="symbols">
<t>
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.
</t>
<t>
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 <xref target="draft-partial-pidf"/>. The watcher MUST increment the local version counter by one.
</t>
<t>
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.
</t>
</list>
</t>
<t>
if watcher encounters a processing error while processing received 'application/pidf-diff+xml' encoded presence
document, look at Section 5.1 of <xref target="patch-ops"/>. In this case watcher SHOULD renew the subscription.
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.
</t>
<t>
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. Local version counter MUST NOT be discarded because if PA changes back to 'application/pidf-diff+xml' MIME type version counter will
continue to increase from the last version value.
</t>
</section>
</section>
<section title="Examples" anchor="Examples">
<t>
The following message flow shows an example applying the partial notifications mechanism.
</t>
<t>
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.
<vspace blankLines="0"/>
<figure>
<artwork>
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
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: [replace with real 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">
<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>
<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: [replace with real content length]
<?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
</artwork>
</figure>
</t>
</section>
<section title="Security Considerations" anchor="Security-Considerations">
<t>
This specification relies on the presence event package for SIP <xref target="RFC-presence"/>.
Partial notifications can reveal information about what has changed
compared to the previous notification. This can make it
easier for 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 <xref target="RFC-pidf"/>.
</t>
<t>
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.
</t>
<t>
Presence related security considerations are extensively discussed in
the presence event package for SIP <xref target="RFC-presence"/> and all those identified
security considerations apply to this document as well. Issues
described in the presence event package for SIP <xref target="RFC-presence"/>, including confidentiality,
message integrity and authenticity, outbound authentication, replay prevention, DoS attacks against thirst parties
and DoS attacks against servers all apply here without any change.
</t>
<t>
It is RECOMMENDED that TLS <xref target="RFC2246"/> 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.
</t>
</section>
<section title="Acknowledgments" anchor="Acknowledgements">
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative references">
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." fullname="Bradner" surname="Bradner">
<organization/>
</author>
<date year="1997" month="March"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="draft-partial-pidf">
<front>
<title>Presence Information Data Format (PIDF) Extension for Partial Presence</title>
<author initials="M." fullname="Mikko Lonnfors" surname="Lonnfors">
<organization/>
</author>
<author initials="H." surname="Khartabil">
<organization/>
</author>
<author initials="E." surname="Leppanen">
<organization/>
</author>
<author initials="J." surname="Urpalainen">
<organization/>
</author>
<date year="2007" month="November"/>
</front>
<seriesInfo name="" value="draft-ietf-simple-partial-pidf-format-10 (work in progress)"/>
</reference>
<reference anchor="RFC-presence">
<front>
<title>A Presence Event Package for the Session Initiation Protocol (SIP)</title>
<author initials="J." surname="Rosenberg">
<organization/>
</author>
<date year="2004" month="August"/>
</front>
<seriesInfo name="RFC" value="3856"/>
</reference>
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials="J." surname="Rosenberg">
<organization/>
</author>
<author initials="H." surname="Schulzrinne">
<organization/>
</author>
<author initials="G." surname="Camarillo">
<organization/>
</author>
<author initials="A." surname="Johnston">
<organization/>
</author>
<author initials="J." surname="Peterson">
<organization/>
</author>
<author initials="R." surname="Sparks">
<organization/>
</author>
<author initials="M." surname="Handley">
<organization/>
</author>
<author initials="E." surname="Schooler">
<organization/>
</author>
<date year="2002" month="June"/>
</front>
<seriesInfo name="RFC" value="3261"/>
</reference>
<reference anchor="RFC-pidf">
<front>
<title>Presence Information Data Format (PIDF)</title>
<author initials="H." surname="Sugano">
<organization/>
</author>
<author initials="S." surname="Fujimoto">
<organization/>
</author>
<author initials="G." surname="Klyne">
<organization/>
</author>
<author initials="A." surname="Bateman">
<organization/>
</author>
<author initials="W." surname="Carr">
<organization/>
</author>
<author initials="J." surname="Peterson">
<organization/>
</author>
<date year="2004" month="August"/>
</front>
<seriesInfo name="RFC" value="3863"/>
</reference>
<reference anchor="RFC3265">
<front>
<title>SIP-Specific Event Notification</title>
<author initials="A." surname="Roach">
<organization/>
</author>
<date year="2002" month="June"/>
</front>
<seriesInfo name="RFC" value="3265"/>
</reference>
<reference anchor="RFC2246">
<front>
<title>The TLS Protocol Version 1.1</title>
<author initials="T." surname="Dierks">
<organization/>
</author>
<author initials="E." surname="Rescorla">
<organization/>
</author>
<date year="2006" month="April"/>
</front>
<seriesInfo name="RFC" value="4346"/>
</reference>
<reference anchor="patch-ops">
<front>
<title>An Extensible Markup Language (XML) Patch Operations Framework Utilizing
XML Path Language (XPath) Selectors</title>
<author initials="J." surname="Urpalainen">
<organization/>
</author>
<date year="2007" month="November"/>
</front>
<seriesInfo name="" value="draft-ietf-simple-xml-patch-ops-04"/>
</reference>
</references>
<references title="Informative references">
<reference anchor="RFC2778">
<front>
<title>A Model for Presence and Instant Messaging</title>
<author initials="M." fullname="Mark Day" surname="Day">
<organization/>
</author>
<author initials="J." surname="Rosenberg">
<organization/>
</author>
<author initials="H." surname="Sugano">
<organization/>
</author>
<date year="2000" month="February"/>
</front>
<seriesInfo name="RFC" value="2778"/>
</reference>
<!--
<reference anchor="draft-CI">
<front>
<title>Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages</title>
<author initials="S." surname="Olson">
<organization/>
</author>
<date year="2003" month="February"/>
</front>
<seriesInfo name="" value="draft-ietf-sip-content-indirect-mech-05 (work in progress)"/>
</reference>
<reference anchor="RFC3320">
<front>
<title>Signaling Compression (SigComp)</title>
<author initials="R." surname="Price">
<organization/>
</author>
<date year="2003" month="January"/>
</front>
<seriesInfo name="RFC" value="3320"/>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:32:32 |