WDIFF

draft-ietf-simple-partial-notify-01.txt --> draft-ietf-simple-partial-notify-02.txt

SIMPLE WG M. Lonnfors
Internet-Draft Nokia Research Center
Expires: July 21, 2004 J. Costa-Requena
Expires: October 19, 2004 E. Leppanen
H. Khartabil
Nokia
January 21,
April 20, 2004

Session Initiation Protocol (SIP) extension for Partial Notification
of Presence Information
draft-ietf-simple-partial-notify-01
draft-ietf-simple-partial-notify-02

Status of this Memo

This document is an Internet-Draft

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and is any of which I become aware will be disclosed, in full conformance accordance with
all provisions of Section 10 of RFC2026.
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 21, October 19, 2004.

Abstract

A Presence service can have constraints for delivering presence
information to devices with low data processing capabilities, small
display, and limited battery power. Limitations can also be caused by
the interface between the terminal and the network, i.e. radio links
with high latency and low bandwidth. This memo presents a solution
that aids in reducing the impact of those constrains and to increase
transport efficiency, by introducing a mechanism called partial
notification.

Lonnfors, et al. Expires July 21, October 19, 2004 [Page 1]

Internet-Draft Partial notification January April 2004

notification.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction to the partial notification mechanism . . . . . . 4
3.1 Basic presence server agent operation . . . . . . . . . . . . . . . 4
3.2 Operation with partial notification . . . . . . . . . . . . . 4
4. Client and server operations . . . . . . . . . . . . . . . . . 5
4.1 Content-type for partial notifications . . . . . . . . . . . . 5
4.2 Watcher generating generation of SUBSCRIBE requests . . . . . . . . . . . 5
4.3 Notifier Presence agent processing of SUBSCRIBE requests . . . . . . . . . . 5 6
4.4 Notifier generating Presence agent generation of partial notifications . . . . . . . . . . 5 6
4.5 Watcher processing of partial notifications NOTIFY requests . . . . . . . . . 6 . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 13
6.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 12 13
6.2 Message Integrity and Authenticity . . . . . . . . . . . . . . 12 13
6.3 Outbound Authentication . . . . . . . . . . . . . . . . . . . 12 13
6.4 Replay Prevention . . . . . . . . . . . . . . . . . . . . . . 12 14
6.5 Denial of Service Attacks Against Third Parties . . . . . . . 12 14
6.6 Denial Of Service Attacks Against Servers . . . . . . . . . . 13 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Normative references . . . . . . . . . . . . . . . . . . . . . 13 14
8.2 Informative references . . . . . . . . . . . . . . . . . . . . 13 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 15
Intellectual Property and Copyright Statements . . . . . . . . 16 17

Lonnfors, et al. Expires July 21, October 19, 2004 [Page 2]

Internet-Draft Partial notification January April 2004

1. Introduction

SIP extensions for

A presence event package for the Session Initiation Protocol (SIP)
[4] allow users ('watchers') to subscribe to other users'
('presentities') presence information. The presence information is
composed of multiple pieces of data that are delivered to the
watcher. The size of the presence information document can be large
(i.e. the presence document can contain an arbitrary number of
elements called presence tuples that convey data). As specified in
RFC2778 [3] and , presence event package for the SIP [4] a Presence server (PS)
Agent (PA) always delivers in presence notifications all the presence
data that has been authorized for a certain watcher in presence
notification. 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 changes. has actually changed. This may end up
degrading the presence service and causing bad perception at the
watcher side.

There are some mechanisms, such as signaling compression (SigComp)
[10] and content indirection [9] that can be used to help in this
problem. However these solutions set additional requirements on basic
network functionalities such as security. Some of the existing
solutions enforce certain requirements on the network and terminals
for supporting compression mechanism, while other solutions require
having a specific server to store the requested presence information
until the terminal fetches it using another protocol (HTTP) and
therefore (e.g. HTTP) and,
therefore, increases possible security concerns.

This draft presents a solution to problems described above, called
partial notifications.

In general, the partial notification approach means that the presence
server delivers to the watchers only those parts of the presence
information that have changed compared to the presence information
sent in the previous notifications. This reduces the amount of data
that needs be trasported transported over the network.

Mechanism

This mechanism utilizes the presence event package for SIP [4] and
the partial PIDF MIME type [2].

2. Conventions

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations.

Lonnfors, et al. Expires October 19, 2004 [Page 3]

Internet-Draft Partial notification April 2004

This document makes use of the vocabulary defined in RFC2778 [3],
RFC3265 [7], presence event package for the SIP [4], and partial PIDF definition
format [2].

Lonnfors, et al. Expires July 21, 2004 [Page 3]

Internet-Draft Partial notification January 2004

3. Introduction to the partial notification mechanism

This chapter briefly introduces the normal regular functionality of the
presence service, and gives an overview of the partial notification
solution. This section is information in nature and it does not
provide any normative statements.

3.1 Basic presence server agent operation

The presence service normally operates so that the a watcher sends the a SIP
SUBSCRIBE request targeted to the presentity. The request is routed up
to the presence server responsible for terminating agent where the
request. presentity's presence information is
stored. The SUBSCRIBE request MAY can include an Accept header field for
indicating that
indicates the supported content types [5]. types.

The PS 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 PS PA will generate the
presence notification notifications using the default PIDF format [6]. The PIDF may
document can contain one or multiple tuples and presence document
level information. The tuples include a set of elements defined in the
presence model
RFC2778 [3] for representing the presence information. The
presence information is sent NOTIFY
requests, built according to the watcher RFC 3265 [7], carry in the body of the NOTIFY
request according to [7]. By default, a presence document containing presence information. Unless
otherwise specified, the presence information document contains the full state
corresponding to the presence status of the presentity, as
determinated by the PS PA local policy and authorization rules.

3.2 Operation with partial notification

The partial notification mechanism enables the watcher to ask and the
presence server to send only request
those parts of the presence information that have changed since the
last notifications was sent.

When The presence agent will send only the
changed presence information since the last notification.

A watcher receives that wants to receive partial notifications according to
this specification, 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-partial+xml" tag. Besides the Accept header field,
there is no other difference between a regular presence subscription
and a subscription requesting partial notifications.

When the presence agent receives the subscription, it examines the

Lonnfors, et al. Expires October 19, 2004 [Page 4]

Internet-Draft Partial notification where April 2004

Accept header field value and decides to use the "state" attribute, as
defined partial
notifications mechanism specified in [2], is this memo. The presence agent
builds NOTIFY requests that contain the Accept header field set to "full", this
"application/pidf-partial+xml". The first NOTIFY request that
contains presence document information will contain a full presence document.
This is
concidered identified by the "state" attribute set to be local "full" in the XML
presence document for the presentity in
question. Partial notifications (when document. Subsequent NOTIFY requests will contain partial
notifications, identified by the "state" attribute as
defined in [2] is set to "partial") are relative to "partial"
in the full XML presence document.

This means that if a partial notification contains new tuples (tuples
which have new tuple ids compared to the full presence document) they
are added to the local full presence document. If it contains tuples
which have exsting existing tuple ids it means that those tuples are updated.
If "removed" element in the XML document contains existing tuple ids
it means that those tuples are removed. The wathcer watcher updates the local
copy accordingly. This behavior is described in detail in Section 4.

Partial notifications, within the scope of this document the partial notifications document, apply only
to
the <tuple> level XML elements and everything what is all possible elements that are
contained

Lonnfors, et al. Expires July 21, 2004 [Page 4]

Internet-Draft Partial notification January 2004

inside in these elements i.e. elements, i.e., tuples are considered to be atomic
data elements. This means that when that, if a notification contains an update is send
to a tuple it is
assumed that an existing tuple, the whole updated tuple is completely replaced by replaces the new existing one.
All
The SIP presence event package [4] provides instructions to process
all the data elements which is are located outside the <tuple> elements must be
processed as specified in [4]. Usually this elements.
This typically means that every notification will include all those
XML elements (for example the <note> element) must be included in every
notification. element).

4. Client and server operations

This document assumes assumes, that unless otherwise specified in this
document
document, the normal subscriber regular watcheer and notifier presence agent behavior is applied
as defined in [4]. The watcher has the same behavior as a subscriber. SIP presence event package [4].

4.1 Content-type for partial notifications

The entities

Entities supporting the partial notification extension described in
this document MUST support the 'application/pidf-partial+xml'
content-type.
content-type specified in the PIDF extension for partial presence
[2].

4.2 Watcher generating generation of SUBSCRIBE requests

The

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 RFC2161 [5]. When a watcher wants to
allow PS the presence agent to send partial notifications it the watcher
MUST include the an Accept header value
'application/pidf-partial+xml' field in the a SUBSCRIBE request. The qvalue
parameter value

Lonnfors, et al. Expires October 19, 2004 [Page 5]

Internet-Draft Partial notification April 2004

of the Accept header can be used file MUST contain 'application/pidf-partial+xml'
(in addition to 'application/pid+xml' required by the SIP presence
event package [4]). The watcher MAY include a "q" parameter to each
accept value to indicate the weight of the accept value, i.e., the
most preferred content type to be used. accept value.

4.3 Notifier Presence agent processing of SUBSCRIBE requests

The notifier presence agent receives the subscriptions from the watchers and
generates the notifications according to SIP presence event package
[4]. If the watcher has indicated the supported content types in the
Accept header field of the SUBSCRIBE request, the presence server agent
compares the content types values included in the Accept header field with the
supported ones, and decides which one to use. If the watcher has used the qvalue parameter
decisionindicated preferred accept values by means of "q" parameters,
the Accept header for the
content types the decision presence agent SHOULD be based on them. Otherwise base the decision is made according to the local policy of on those preferences,
unless otherwise indicated by the presence
server. agent local policy.

4.4 Notifier generating Presence agent generation of partial notifications

It is RECOMMENDED that if the watcher indicates support for partial
notifications, using the Accept-header, that the PS compliant with
this specification sends partial notifications.

If the PS presence agent decides to send notifications according to this specification, then
specification that include a presence document, the notifier

Lonnfors, et al. Expires July 21, 2004 [Page 5]

Internet-Draft presence agent
MUST build a presence document according to the PIDF extension for
Partial notification January 2004 Presence [2] and MUST set the Content-Type header field to
the value 'application/pidf-partial+xml'.

Tuple ids are used to match tuples across subsequent notifications.
Presence agent MUST use the 'application/pidf-partial+xml' content type in same tuple ids for tuples which are
identical between subsequent notifications and MUST allocate
different tuple ids for tuples which are different from previously
sent tuples. Presence agents MUST keep tuple ids consistent until the
NOTIFY requests.
next full state presence documentis delivered. The PS decision on
whether tuple ids are the same or different is left up to PA's local
policy.

Once a subscription is accepted and installed, the PA MUST deliver
the full state of the presence information
according to [4] in the first notification. notification
that contains a presence document. In this case, the PA MUST set the
"state" attribute of the <presence> element in the presence document MUST be
set
to the value "full". The "version" attribute "full". PA MUST also be present include a "version" attribute and it
MUST be initialized to value zero.

When the PS PA generates subsequent notifications, the presence document
includes PA SHOULD include
only the those tuples that have changed compared to the previous
notification. It is up to the PA local policy to determine what is
considered as a change to the previous state. The "state" attribute's
value When the presence
document does not include a full presence state, the PA MUST be set the
"state" attribute value of the <presence> element to "partial".

Lonnfors, et al. Expires October 19, 2004 [Page 6]

Internet-Draft Partial notification April 2004

The PA MUST ensure that all tuple ids used in the presence document
are unique. This applies to all tuple ids in <tuple> elements and in
<t_id> elements under the <removed> element.

The PS constructs PA SHOULD construct the partial presence document according to
the following logic:

o The delivered PA MUST construct the presence information MUST be constructed according to [4] in such a way the
Presence event package [4], with the exception that only the
changed tuples are delivered.
New tuples are included in the presence document. The PA MUST
also added add all newly created tuples, if any, to the presence information, if any.
information.

o The PA MUST include a "version" and "state" attributes MUST be included in the
presence document. The PA MUST increment the version number is incremented by one
compared to the earlier delivered presence document to the watcher
associated with a certain subscription.

o When there are changes (e.g. in the authorization) which lead to
removal of tuples from the previously delivered presence
information the PS PA MUST construct a partial notification document
that lists the tuple ids of the removed tuples in the "removed"
element.

o All The PA MUST include all the presence information outside the
<tuple> elements MUST be
included in each notification, i.e., all the notifications
which convey partial presence documents MUST always have that
data.

In case the PA receives a subscription refresh or termination request
from existing subscription (with any value in the Expires header
field) and the PA decides to include a body into the following NOTIFY
request the PA MUST build a NOTIFY request that contains a full
presence document (i.e. the attribute "state" is set to "full" and
the attribute "version" is set to value 0).

4.5 Watcher processing of partial notifications NOTIFY requests

If the PS PA decided to use the partial notifications, then the watcher
receives 'application/pidf-partial+xml' content type in the
will receive a NOTIFY
requests. request with the Content-Type header field
value set to 'application/pidf-partial+xml' .

The watcher receives will receive the full presence document in the first
notification. In this case, the "state" element attribute of the <presence>
element in the presence document has is set to the value "full". When the
watcher receives the full presence document it MUST perform the
following actions:

Lonnfors, et al. Expires July 21, October 19, 2004 [Page 6] 7]

Internet-Draft Partial notification January April 2004

o The watcher MUST discard all previously received presence
information from that particular presentity in the context of
current dialog. subscription.

o The watcher MUST initialize an internal version counter, related
to the particular presentity or subscription, to the value of
"version" atttribute received attributeof the <presence> element included in the notification.
presence document.

o The watcher MUST store the values of all tuple ids together with
the content received in the notification. This is constitutes the
watcher's local copy of the full presence document. full presence document.

o If the presence document contains a <removed> element the watcher
MUST ignore the content of that element.

When the watcher receives subsequent notifications and the PS notifier
has not changed the used content type, and the "state" attribute of
the <presence> element includes the value "partial" "partial", the watcher MUST
construct the presence information according to the following logic:

o The watcher MUST compare the "version" attribute of the <presence>
element is compared with the version information in the of a previously received
presence document. If the version number is incremented by one,
the watcher
continues MUST continue handling the content present in the
notification.

o The watcher compares MUST compare the tuple ids to with the tuple ids received
in the previous notifications. If a tuple id in the current
notification matches an existing tuple id, the existing tuple is
replaced with the newly received in the notification. tuple. If the tuple id does not
match
to those any tuple received in the earlier notifications, the watcher
MUST store it is stored as a new tuple.

o If the presence document includes the "removed" element The watcher MUST remove from the local storage those tuples
which whose
tuple ids are listed are removed from in the local storage. "removed" element of the presence
document.

o Tuples whose tuple ids are missing not listed in the presence document
included in the NOTIFY remain unchanged.

In case unchanged

If the watcher receives a notification with the presence document whose "version" attribute
value higher by more than one with the locally stored value by more than
one, the
watcher assumes that one or more NOTIFYs were lost. The watcher
SHOULD either refresh the subscription within the existing
dialog in order to receive a full
presence document or terminate the subscription. If the watcher
receives a notification presence document with the "state"
attribute's value attribute set to
"partial" and the "version" attribute's attribute value is equal or smaller lower than

Lonnfors, et al. Expires October 19, 2004 [Page 8]

Internet-Draft Partial notification April 2004

the one received in the presence docment of a previous notification,
it is considered a PS PA failure and the watcher SHOULD either refresh or
terminate discard the subscription.
document without further processing.

All information received in the notification which is information located outside the <tuple> element must be
processed as specified in the SIP presence event package [4] i.e.,
the watcher must MUST replace the existing data with data received in the

Lonnfors, et al. Expires July 21, 2004 [Page 7]

Internet-Draft Partial notification January 2004
latest notification.

In case

If the PS PA changes the content type used in notifications within the
existing dialog subscription the watcher must MUST discard all the previously
received presence information from that particular presentity and
process the new content as specified for that content type.

5. Examples

The following message flow shows an example applying the partial
notifications mechanism.

The

A watcher sends a SUBSCRIBE request including declaring support for the default
presence format (PIDF) ('application/pidf+xml)) and the content type for the partial
notification ('application/pidf-partial+xml') in the Accept header field.
field value. The watcher uses the qvalue "q" parameter to set the preference
for receiving partial notifications. The PS PA accepts the subscription and
and, based on the qvalue information "q" parameter value, 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 Agent PUA
| F1 SUBSCRIBE | |
|-------------------------->| |
| F2 200 OK | |
|<--------------------------| |
| F3 NOTIFY | |
|<--------------------------| |
| F4 200 OK | |
|-------------------------->| |
| | |
| | Update presence |
| |<----------------------- |
| | |
| F5 NOTIFY | |
|<--------------------------| |
| F6 200 OK | |
|-------------------------->| |

Lonnfors, et al. Expires October 19, 2004 [Page 9]

Internet-Draft Partial notification April 2004

Message Details

F1 SUBSCRIBE watcher->example.com server

SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/TCP watcherhost.example.com;

Lonnfors, et al. Expires July 21, 2004 [Page 8]

Internet-Draft Partial notification January 2004
branch=z9hG4bKnashds7
To: sip:resource@example.com
From: sip:watcher@somewhere.com <sip:watcher@somewhere.com> ;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml;q=0.3,
application/pidf-partial+xml;q=1
Contact: user@watcherhost.example.com sip:user@watcherhost.example.com
Expires: 600

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@somewhere.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Event: presence
Expires: 600
Contact: sip:server.example.com

The Presence Server accepts the subscription and PA, based on the qvalue information "q" parameter value in the Accept
header uses of the SUBSCRIBE request (F1), decides to use
partial notifications. (See The PA creates a first NOTIFY
request that includes a partical notification document that
contains 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 full state.

F3 NOTIFY example.com server-> watcher

NOTIFY sip:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/TCP server.example.com;
branch=z9hG4bKna998sk
To: sip:watcher@somewhere.com;tag=xfg9 <sip:watcher@somewhere.com>;tag=xfg9
From: sip:resource@example.com;tag=ffd2 <sip:resource@example.com>;tag=ffd2

Lonnfors, et al. Expires October 19, 2004 [Page 10]

Internet-Draft Partial notification April 2004

Call-ID: 2010@watcherhost.example.com
Event: presence
Subscription-State: active;expires=599
Max-Forwards: 70
CSeq: 8775 NOTIFY
Contact: sip:server.example.com
Content-Type: application/pidf-partial+xml
Content-Length: ..

Lonnfors, et al. Expires July 21, 2004 [Page 9]

Internet-Draft Partial notification January 2004

'application/pidf-partial+xml' document containing
full presence document: [replace with real content length]

<?xml version="1.0" encoding="UTF-8"?>
<pidf-part:presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf-part="urn:ietf:params:xml:ns:pidf-partial"
entity="pres:someone@example.com" pidf:part:version="1"
pidf-part:state="full"> version="0"
state="full">

<tuple id="cg231jcr">
<status><basic>open</basic>
</status>
<contact priority="1.0">
im:pep@example.com</contact>
</tuple>
<tuple id="r1230d">
<status><basic>closed</basic>
</status>
<contact priority="0.9">
sip:pep@example.com</contact>
</tuple>
</presence>
</pidf-part:presence>

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 <sip:watcher@somewhere.com>;tag=xfg9
From: sip:resource@example.com;tag=ffd2 <sip:resource@example.com>;tag=ffd2
Call-ID: 2010@watcherhost.example.com
CSeq: 8775 NOTIFY

F5 NOTIFY example.com server -> watcher

It is the local policy issue to construct the
'application/pidf-partial+xml' formated document including the
delta from the previous NOTIFY. Note that

At a later time, the tuple which id
"r1230d" was deleted. presentity's presence information

Lonnfors, et al. Expires July 21, October 19, 2004 [Page 10] 11]

Internet-Draft Partial notification January April 2004

changes: the tuple id "cg231jcr" has changed its
status, a new tuple id "wsqw798jcr" is added and the
tuple id "r1230d" is deleted from the presence
document. The PA generates a NOTIFY request
that includes a partial presence document that includes
the deleted tuple

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@somewhere.com;tag=xfg9 <sip:watcher@somewhere.com>;tag=xfg9
From: sip:resource@example.com;tag=ffd2 <sip:resource@example.com>;tag=ffd2
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY
Event: presence
Subscription-State: active;expires=543
Max-Forwards: 70
Contact: sip:server.example.com
Content-Type: application/pidf-partial+xml
Content-Length: ...

New 'application/pidf-partial+xml document containing partial
presence document: [replace with real content length]

<pidf-part:removed><pidf-part:t_id>r1230d</pidf-part:t_id>
</pidf-part:removed> version="1"
state="partial">

<tuple id="cg231jcr">
<status><basic>closed</basic>
</status>
<contact priority="1.0">
im:pep@examploe.com</contact>
<notexml:lang="en">This
im:pep@example.com</contact>
<note xml:lang="en">This is an update of existing
tuple sent in previous notification</note>
</tuple>

<tuple id="wsqw798jcr">
<status><basic>open</basic>
</status>
<contact priority="0.4">
im:mac@hut.com</contact>
<note xml:lang="en">This is a completely new
tuple not sent in previous notification</note>
</tuple>
</presence>

F6 200 OK watcher-> example.com server

SIP/2.0 200 OK

<pidf-part:removed><pidf-part:t_id>r1230d</pidf-part:t_id>

Lonnfors, et al. Expires July 21, October 19, 2004 [Page 11] 12]

Internet-Draft Partial notification January April 2004

</pidf-part:removed>

</pidf-part:presence>

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 <sip:watcher@somewhere.com>;tag=xfg9
From: sip:resource@example.com;tag=ffd2 <sip:resource@example.com>;tag=ffd2
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY

6. Security Considerations

This specification relies on presence event package for the SIP [4]
and it does not introduce any new protocol functionality. Partial
notifications can reveal information what has changed compared to
last time when
notificatiuon notification was sent. This can make it easier for evesdropper
eavesdropper to know what kind of changes are happening in
presentity's presence information. However, same information can be
found if presence event package is used with baseline PIDF [6]. Thus,
this specification does not introduce any new security conciderations considerations
compared to presence event package for the SIP [4].

Presence related security considerations are extensively discussed in
the presence event package for the SIP [4] and all those identified
security consideration apply to this document as well. Issues
described in the presence event package for the SIP [4] are briefly
reviewed below.

6.1 Confidentiality

Confidentiality considerations identified in the presence event
package for the SIP [4] apply here without any changes.

6.2 Message Integrity and Authenticity

Message Integrity and Authenticity identified in the presence event
package for the SIP [4] apply here without any changes.

6.3 Outbound Authentication

Outbound Authentication considerations identified in the presence

Lonnfors, et al. Expires October 19, 2004 [Page 13]

Internet-Draft Partial notification April 2004

event package for the SIP [4] apply here without any changes.

6.4 Replay Prevention

Replay Prevention considerations identified in the presence event
package for the SIP [4] apply here without any changes.

6.5 Denial of Service Attacks Against Third Parties

Lonnfors, et al. Expires July 21, 2004 [Page 12]

Internet-Draft Partial notification January 2004 changes.

6.5 Denial of Service Attacks Against Third Parties

Denial of Service Attacks Against Third Parties considerations
identified in the presence event package for the SIP [4] apply here
without any changes.

6.6 Denial Of Service Attacks Against Servers

Denial Of Service Attacks Against Servers considerations identified
in the presence event package for the SIP [4] apply here without any
changes.

7. Acknowledgements

The authors would like to thank Jyrki Aarnos, Jonathan Rosenberg,
Dean Willis, Kriztian Kiss, Juha Kalliokulju Kalliokulju, Miguel Garcia, Anders
Kristensen, Yannis Pavlidis, Ben Cambell, and Tim Moran for their
valuable comments.

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. and E. Leppanen, "Presence
Information Data Format (PIDF) Extension for Partial Presence",
draft-ietf-simple-partial-pidf-format-00
draft-ietf-simple-partial-pidf-format-01 (work in progress),
January 2004.

[3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.

[4] Rosenberg, J., "SIP Extensions "A Presence Event Package for Presence", the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.

[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.

Lonnfors, et al. Expires October 19, 2004 [Page 14]

Internet-Draft Partial notification April 2004

[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
J. Peterson, "CPIM presence information data format",
draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.

[7] Roach, A., "SIP-Specific Event Notification", RFC 3265, June
2002.

8.2 Informative references

[8] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05 (work in progress), January
2003.

Lonnfors, et al. Expires July 21, 2004 [Page 13]

Internet-Draft Partial notification January 2004

[9] Olson, S., "Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages",
draft-ietf-sip-content-indirect-mech-03 (work in progress),
February 2003.

[10] Price, R., "Signaling Compression (SigComp)", RFC 3320, January
2003.

Authors' Addresses

Mikko Lonnfors
Nokia Research Center
Itamerenkatu 11-13 00180
Helsinki
Finland

Phone: +358 71 8008000
EMail: mikko.lonnfors@nokia.com

Jose Costa-Requena
Nokia
Valimotie 9 00380
Helsinki
Finland

Phone: +358 71 8008000
EMail: jose.costa-requena@nokia.com

Lonnfors, et al. Expires October 19, 2004 [Page 15]

Internet-Draft Partial notification April 2004

Eva Leppanen
Nokia
P.O BOX 785
Tampere
Finland

Phone: +358 7180 77066
EMail: eva-maria.leppanen@nokia.com

Lonnfors, et al. Expires July 21, 2004 [Page 14]

Internet-Draft Partial notification January 2004

Hisham Khartabil
Nokia
P.O. Box 321
Helsinki
Finland

Phone: +358 7180 76161
EMail: hisham.khartabil@nokia.com

Lonnfors, et al. Expires July 21, October 19, 2004 [Page 15] 16]

Internet-Draft Partial notification January April 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property
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; neither nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in standards-track and
standards-related documentation IETF Documents can
be found in BCP-11. BCP 78 and BCP 79.

Copies of
claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

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 at
ietf-ipr@ietf.org.

Disclaimer 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. Validity

This document and the information contained herein is are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION

Lonnfors, et al. Expires July 21, 2004 [Page 16]

Internet-Draft Partial notification January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Copyright (C) The Internet Society (2004). 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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Lonnfors, et al. Expires July 21, October 19, 2004 [Page 17]

----