WDIFF

draft-ietf-simple-publish-00.txt --> draft-ietf-simple-publish-01.txt

SIMPLE B. Campbell WG A. Niemi, Ed.
Internet-Draft dynamicsoft Nokia
Expires: August 25, December 28, 2003 S. Olson
Microsoft
J. Peterson
NeuStar, Inc.
J. Rosenberg
dynamicsoft
B. Stucker
Nortel Networks, Inc.
February 24, June 29, 2003

SIMPLE

Session Initiation Protocol (SIP) Extension for Presence Publication Mechanism
draft-ietf-simple-publish-00
draft-ietf-simple-publish-01

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

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

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 August 25, December 28, 2003.

Abstract

This document describes an extension to the Session Initiation
Protocol (SIP) [1]. The purpose of this extension to create a means for publishing event state used within the framework
for SIP Event
Notification (RFC3265 [2]). Notification. The first application of this extension

Campbell, et al. Expires August 25, 2003 [Page 1]

Internet-Draft PUBLISH method February 2003
is targeted at the publication of presence information as defined by
the SIMPLE [7] working group.

1. Introduction

This document describes a mechanism for event publication in SIP that
satisfies the requirements set forward in the SIMPLE publication
requirements [4]. A new SIP method, the PUBLISH method, is defined
by this document. information.

The method mechanism described in this document allows presence information to
be published to a presence agent on behalf of a user. This method can be extended to support
publication of other any event state, but it for which there exists an appropriate
event package. It is not intended to be a general-purpose mechanism
for transport of arbitrary data data, as there are better suited
mechanisms for this purpose
(ftp, http, (FTP, HTTP, etc.) This method is intended to be a simple, light-
weight mechanism that employs SIP in order to support SIMPLE
services.

1.1 Why a new SIP method?

In order to satisfy the requirements necessary for publishing event
state to an event agent, different

Niemi Expires December 28, 2003 [Page 1]

Internet-Draft SIP protocol elements were
evaluated, namely REGISTER Presence Publication June 2003

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and SUBSCRIBE/NOTIFY.

REGISTER solves Conventions . . . . . . . . . . . . . . . . 3
3. Overall Operation . . . . . . . . . . . . . . . . . . . . . 4
4. Prerequisites for Event Packages using PUBLISH . . . . . . . 5
4.1 PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 PUBLISH Response Bodies . . . . . . . . . . . . . . . . . . 5
4.3 Partial Event State . . . . . . . . . . . . . . . . . . . . 6
4.4 Event State Decomposition . . . . . . . . . . . . . . . . . 6
4.5 Default Expiration of PUBLISH . . . . . . . . . . . . . . . 6
5. Constructing the problem of publishing PUBLISH Request . . . . . . . . . . . . . . 7
5.1 Creating Initial Publication . . . . . . . . . . . . . . . . 8
5.2 Setting the Expiration Interval . . . . . . . . . . . . . . 9
5.3 Refreshing Event State . . . . . . . . . . . . . . . . . . . 9
5.4 Modifying Event State . . . . . . . . . . . . . . . . . . . 10
5.5 Removing Event State . . . . . . . . . . . . . . . . . . . . 10
5.6 Querying the set Current Event State . . . . . . . . . . . . . . 11
6. Processing PUBLISH Requests . . . . . . . . . . . . . . . . 11
7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1 New Methods . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1.1 PUBLISH Method . . . . . . . . . . . . . . . . . . . . . . . 14
7.2 New Response Codes . . . . . . . . . . . . . . . . . . . . . 16
7.2.1 "412 Precondition Failed" Response Code . . . . . . . . . . 16
7.3 New Header Fields . . . . . . . . . . . . . . . . . . . . . 16
7.3.1 "ETag" Header . . . . . . . . . . . . . . . . . . . . . . . 17
7.3.2 "If-Match" Header . . . . . . . . . . . . . . . . . . . . . 17
7.4 Augmented BNF Definitions . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
8.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 18
8.3 Header Field Names . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . 18
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 25
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
13. Changes from "draft-ietf-simple-publish-00" . . . . . . . . 26
Normative References . . . . . . . . . . . . . . . . . . . . 27
Informative References . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . 29

Niemi Expires December 28, 2003 [Page 2]

Internet-Draft SIP Presence Publication June 2003

1. Introduction

The focus of contacts for this specification is to provide a
given address of record. However, framework for the more general requirements
publication of
publishing event state from a user agent to an event agent call entity that is
responsible for a different
solution. Event agents (consumers of published event state) may
exist anywhere in the network. With REGISTER, the sole consumer of
the data being published is the registrar. For presence publication,
there may be more than one event agent that is interested in the
published event state. The inability to fork REGISTERs prevents
this. As such, the routing requirements for published compositing this event state
(e.g. a presence document) cannot be covered by the mechanisms
available and distributing it to us
interested parties through the REGISTER method.

We already have SIP events [1] framework. This
specification fills a mechanism for publishing event state throughout gap in the
network: SUBSCRIBE/NOTIFY. The subscription mechanism exists SIP events framework to allow for a device to assert interest in a piece of state. Typically it
is used
client to allow potentially multiple subscribers push its event state to watch a piece of
state, where the state agent could not be expected to know in advance
all the potential watchers for that acts on its
behalf.

The first application of this state and where mechanism is the set of
watchers changes over time. The desired publication mechanism has a
different goal: publishing event of
presence state by a presence user agent to a small number of locations presence compositor
which are known in advance. The target of has a tightly coupled relationship to the presence agent. The
requirements and model for presence publication request is
known are documented in advance while the source
[2]. This specification will address each of those publication requests are
not. SUBSCRIBE/NOTIFY cannot easily solve the problem at hand.

Campbell, et al. Expires August 25, 2003 [Page 2]

Internet-Draft PUBLISH method February 2003

As such, we are left with one option, to create a new method requirements.

The mechanism described in this document can be extended to support
publication of any event state to a set of possibly unknown (in a
routing sense) state, for which there exists an appropriate
event agents, who may or may not have expressed prior
interest package as defined in receiving said data: the PUBLISH method.

1.2 Publication Classes

The sources that are publishing event state can [1]. It is not intended to be subdivided into
classes. These classes are a logical subdivision that allows
composition policy to treat different kinds
general-purpose mechanism for transport of inputs in different
manners. In some circumstances, the classes may be arbitrary,
ephemeral arbitrary data, as there
are better suited mechanisms for this purpose (FTP [7], HTTP [8],
etc.)

2. Terminology and without fixed semantic value. Conventions

In others, addition to the classes
may be well defined, persistent and even standardized. Examples terminology of
the latter might include classifications such as: geolocation
publishers, mobile devices, automatons or PDAs. RFC 3265 [1] and RFC 3261 [3], this
document introduces some new concepts:

Event State: The publisher will
indicate its publication class as part composition state of the publication process. a resource.

Event Publication Agent (EPA): The compositor is free UAC which issues a PUBLISH request
to use publish event state or ignore event state segments. For presence, this information in
conjunction with its local policy for compositing
corresponds to the many inputs it
receives. PUA.

Event State Compositor (ESC): The publication class names are completely arbitrary, UAS which processes PUBLISH
requests and there may
be any number of inputs is responsible of any class. We envision that compositing event state or event
state segments into a complete, composite event state. For
presence, this corresponds to the PA.

Event State Segment: For some event packages, there will be exists a number natural
decomposition of common classes that event state into event state segments. For
presence, such decomposition is the presence tuple.

Hard State: Hard state is the steady-state or default state version
of event state at the ESC, which may be standardized, as well as a
number used in the absence of application specific classes. We will need a mechanism to
avoid publication class name collisions.

There any
other soft state publications.

Niemi Expires December 28, 2003 [Page 3]

Internet-Draft SIP Presence Publication June 2003

Soft State: Soft state is a temptation to associate the idea version of class with a tuple ID
in event state at the CPIM PIDF document. However, ESC, that
is published by the tuple ID EPA. Soft state has no semantics
(although some examples in early versions a defined lifetime and
will expire after a negotiated amount of the PIDF document time.

Version Identifier: A protocol element (i.e., an entity-tag) that is
used
the tuple ID incorrectly in this fashion). Moreover, other
composition applications may exist where this will not work. For
example, to identify a geolocation class might get applied across multiple
tuples.

OPEN ISSUE: Does Class overlap with work specific soft state version of published event
state at the ESC.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in RPIDS? Should we look
to presence formats to provide their own class identifiers for
status or tuple elements?

1.3 Correlating Publications from Multiple Sources

It is sometimes desirable this
document are to be interpreted as described in RFC 2119 [4] and
indicate the specific instance of requirement levels for compliant implementations.

3. Overall Operation

This document defines a
publication class that is new SIP method, PUBLISH, for publishing event
state. This instance PUBLISH is
intended analogous to be a correlation identifier which is unique and
consistent across multiple publications from the same source. This
serves REGISTER in that it allows a similar purpose user to the local or remote tag
add, modify, and remove state in another entity which manages this
state on behalf of a SIP dialog.

For example, a presentity might have multiple PUAs that act as "user"

Campbell, et al. Expires August 25, 2003 [Page 3]

Internet-Draft PUBLISH method February 2003

inputs. user. The compositor might user may in turn have policy multiple UAs or
endpoints. Each endpoint may publish its own unique state and through
a subscription to combine that event package discover the event state from
each user PUA into of the composite document. But if
other active endpoints.

In the same PUA generic sense, a UAC which publishes again, the policy may involve replacing the previous
published event state of that particular PUA. Doing so requires some
manner of correlation identifier (publisher instance). The
correlation ID is highly dynamic, and should be globally unique for
any associated group of publications.

There labelled
an Event Publication Agent (EPA). For presence in particular, this is a temptation too have the correlation ID derive from
the
authentication credentials of a publisher. But there may be
applications where each familiar PUA publishes using the credentials of the
presentity. This could mean that multiple PUAs would publish with
the same credentials. role as defined in [5]. The PUBLISH method looks to entity which processes
the PUBLISH request is known as an Event State Compositor (ESC). For
presence format to provide globally-
unique identifiers for particular segments of presence that are in a
single stream of publication. In PIDF, particular, this would be the tuple ID.
Note that presence formats must also supply a way of ordering
presence information (for example, is the timestamp element in PIDF).

1.4 Publication to Multiple Destinations

Just familiar PA role as defined in
[5].

PUBLISH requests create soft state in the publication class and publication instance are used to
categorize and differentiate the publication source, there is state agent. This state has
a need
to categorize defined lifetime and differentiate the publication "destination". The
compositor may then apply policy on behalf will expire after a negotiated amount of time,
requiring the publisher publication to limit,
transform, or otherwise constrain be refreshed by subsequent PUBLISH
requests. Local policy at the composite event state which
various watchers compositor may receive from the PA. Some amount of metadata is
required that aids in turn define
hard-state for a particular event package. That is, the decisions about composition and
dissemination steady-state
of this event state.

For example, a given publisher may wish to publish geolocation
information package in varying degrees of fidelity. The most trusted
watchers the absence of that event any other soft state should receive provided
through the highest fidelity
information. Less trusted, perhaps anonymous, watchers should
receive a more restricted view PUBLISH method.

Typically, the body of a PUBLISH request carries the composite published event
state. A wide range
of authorization policies can be built around this concept. To meet
this requirement, In the publisher might publish several versions of response to a PUBLISH request, the
event state, each somehow marked with EPA assigns a different
version identifier
indicating the destination grouping of to the state, published event state or somehow instruct
a presence agent to change event state before distributing it to
various destinations.

There
segment. This identifier is work underway in used by the SIMPLE working group on EPA as part of a general way
to provide authorization instructions version
precondition to a presence agent regarding subsequent refreshing PUBLISH requests of that event
state. In the event that the distribution publication refresh is to an outdated
version of presence information (see event state, the SIMPLE data
manipulation [5] mechanism). Publishers should use this
authorization mechanism versioning precondition will fail. This
enables an EPA to manage detect collisions between new and refresh
publications of the selective distribution same event state among a set of

Campbell, et al. endpoints.

Niemi Expires August 25, December 28, 2003 [Page 4]

Internet-Draft PUBLISH method February SIP Presence Publication June 2003

presence information.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",

Event state publication inherently involves at least two parties: the
source of the publication and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].

3. The PUBLISH method the target of the publication. The PUBLISH method
source of the publication is used to push data to a set naturally represented as an
address-of-record (AOR).

For some types of event agents that
may or state, namely presence, the target of the
publication may not consume sufficiently be represented by an
address-of-record (AOR) alone. Rather, the data being published. The method target is
constructed as a combination of
both an OPTIONS request would be, AOR and is allowed a unique identifier which acts to fork.
The Request-URI represent one of the PUBLISH identifies the resource N
possible sections of an overall event state for whom that AOR. In this
data is being published. As such,
specification, these sections are referred to as event state
segments.

In the sender of a PUBLISH may not
know all context of presence publication, the endpoints that processed event state segment is
nothing more than the request successfully,
but will know if at least one endpoint accepted presence tuple associated with the request by way of presentity
(AOR). It is the forking rules for isomorphic requests within SIP.

A PUBLISH request MAY contain a body, using role of the standard MIME headers compositor to identify the content. The typical PUBLISH request will contain aggregate these segments
into a
body with the complete event state which is presented to publish. The absence the subscribers of
that event state. This composition logic is a body in a
PUBLISH request may have the semantics matter of local policy.

For some event packages, there is no natural decomposition of clearing the event
state into these segments and for this publication instance depending on the policy at the
compositor.

The following these packages, an AOR is
sufficient to identify the BNF definition for target of the publication.

4. Prerequisites for Event Packages using PUBLISH method. As with
all other SIP methods,

In order to make use of the event publication mechanism, certain
prerequisites have to be fulfilled for each specific event package.
In order to satisfy the requirements of [2], the body of the PUBLISH
request must fulfill several requirements as well.

This section outlines these prerequisites, and demonstrates how they
are fulfilled specifically for presence publication.

4.1 PUBLISH Bodies

Any application of the method name is case sensitive.

PUBLISHm = %x50.55.42.4C.49.53.48 ; PUBLISH mechanism for a given event package
MUST support a content type which fulfills the requirements in caps.

Tables 1 and 2 extend Tables 2 [2].
Each event package MUST also describe the semantics associated with
that content and 3 MUST prescribe a default, mandatory to implement
format.

This document defines the semantics of SIP [1] by adding an
additional column, defining the header fields that can be used in
PUBLISH presence publication
requests and responses.

Header Field where proxy (event package "presence") when the CPIM PIDF [6] presence
document format is used. A PUA which uses PUBLISH
__________________________________________
Accept R -
Accept 2xx -
Accept 415 m*
Accept-Encoding R -
Accept-Encoding 2xx -
Accept-Encoding 415 m*
Accept-Language R -
Accept-Language 2xx -

Campbell, et al. to publish presence
state to the PA MUST support the CPIM PIDF presence format.

4.2 PUBLISH Response Bodies

Niemi Expires August 25, December 28, 2003 [Page 5]

Internet-Draft PUBLISH method February SIP Presence Publication June 2003

Accept-Language 415 m*
Alert-Info R -
Alert-Info 180 -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Authentication-Info 2xx o
Authorization R o
Call-ID c r m
Call-Info ar o
Class R o
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length ar t
Content-Type *
CSeq c r m
Date

The response to a o
Event PUBLISH request indicates whether the request was
successful or not. In general, the body of such a m
Error-Info 300-699 response will be
empty unless the event package defines explicit meaning for such a o
Expires o
From c r m
In-Reply-To R o
Max-Forwards R amr m
Organization ar o

Table 1: Summary of header fields, A--O

Campbell, et al. Expires August 25, 2003 [Page 6]

Internet-Draft PUBLISH method February 2003

Header Field where proxy PUBLISH
__________________________________________
Priority R ar o
Proxy-Authenticate 407 ar m
Proxy-Authenticate 401 ar o
Proxy-Authorization R dr o
Proxy-Require R ar o
Record-Route ar -
Reply-To o
Require ar c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R adr o
Server r o
Subject R o
Timestamp o
To c(1) r m
Unsupported 420 o
User-Agent o
Via R amr m
Via rc dr m
Warning r o
WWW-Authenticate 401 ar m
WWW-Authenticate 407 ar o

3.1 Request-URI

The Request-URI, as previously stated,
body.

There is no such meaning for a PUBLISH identifies response to a presence publication
when the
resource document format used is CPIM PIDF.

4.3 Partial Event State

The content type MUST provide a way to publish partial state for which an
event package. The intention is to allow each device or client for an
address-of-record to publish event state independently. To accomplish
this, the published event state that is intended. For
example, if we were published by these devices MUST be
allowed to take the case be only a portion of presence, then the Request-
URI, and the To could begin as the well known address of complete state that the
presentity state
agent advertises for whom we that AOR.

Note that sources for event state other than those using the
PUBLISH mechanism are publishing a fragment explicitly allowed. It is beyond the scope
of their presence
document.

OPEN ISSUE: Is this actually what we want document to do? Or is define such interfaces.

For presence in particular, a
compositor's URI is the correct destination of PUA can publish presence state for just
a PUBLISH request?

3.2 Class (Publication Class) Header

As part subset of the presence publication model tuples that PUBLISH belongs to, may be composited into the presence
document that watchers receive in a NOTIFY. The mechanism by which
the ESC aggregates this information is being published may become part of a larger
composite document consisting matter of multiple parts. This is not local policy.

4.4 Event State Decomposition

If the content type allows for event state segments to be
confused with multipart MIME, however. An example of this would be
represented, the content type MUST provide a
presence document that spans several devices for which means to uniquely
identify each presence

Campbell, et al. Expires August 25, 2003 [Page 7]

Internet-Draft PUBLISH method February 2003

tuple could be considered a "part" of unique segment.

For presence, the overall CPIM PIDF presence document.
The exact definition of what entails a recognizable portion of the
overall document being published is left entirely up provides a tuple-ID to
distinguish the semantics segments of the content type being operated on. presence document associated with the
encompassing presentity.

OPEN ISSUE: The reverse may also be true, in that we may wish to publish a single
piece specifics of data, which how the event agent compositor tuple-ID is expected to apply used to multiple components of a composite document.

Because identify
specific segments of this, simply identifying the resource party (TO) for which
the data is intended may be insufficient in order to correctly
process the document or document fragment being published. The Class
(publication class) header composite state is used to denote still open. Currently,
a token specific naming convention for which the
published content tuple-ID seems like a
reasonable approach. However, this naming convention is to be applied. Multiple tokens may be denoted
in the Class header, each being separated by
defined.

4.5 Default Expiration of PUBLISH

PUBLISH establishes soft state which expires after a comma. This is an
optional header. In the absence negotiated
amount of time. Each event package MUST provide a Class header, default expiration
value recommendation (SHOULD strength).

Niemi Expires December 28, 2003 [Page 6]

Internet-Draft SIP Presence Publication June 2003

For presence publication, it is RECOMMENDED that the compositor
may ESC use local policy to determine an appropriate class to sort a
default value of 3600 seconds (1 hour) for this default expiration
value.

5. Constructing the
publication information into.

Class = "Class" HCOLON (token *(COMMA token))

Example:
Class: geoloc, mobile

3.3 Expires Header PUBLISH Request

PUBLISH requests create, remove, and modify event state. A PUBLISH
request can create new event state in the state agent, associating
this event state with an address-of-record and optionally with a
unique identifier for segments of event state being published.
Publication on behalf of a particular address-of-record may also be
performed by a suitably authorized third party. To determine the
current published state for a particular address-of-record, the
client MAY create a subscription for this address-of-record and event
package using the SUBSCRIBE/NOTIFY mechanism of RFC3265 [1].

Note that in the case the event state is segmented, each segment
logically represents an independent publication that may be added,
removed, modified, and expired separately.

Except as noted, the construction of the PUBLISH request and the
behavior of clients sending a PUBLISH request is identical to the
general UAC behavior described in Section 8.1 and Section 17.1 of RFC
3261 [3].

If necessary, clients may probe for the support of PUBLISH using the
OPTIONS request defined in SIP [3]. The presence of "PUBLISH" in the
"Allow" header field in a response to an OPTIONS request indicates
support for the PUBLISH method. In addition, the "Allow-Events"
header field indicates the supported event packages.

A PUBLISH request does not establish a dialog. A UAC MAY include a
Route header field in a PUBLISH request based on a pre-existing route
set as described in Section 8.1 of RFC3261. The Record-Route header
field has no meaning in PUBLISH requests or responses, and MUST be
ignored if present. In particular, the UAC MUST NOT create a new
route set based on the presence or absence of a Record-Route header
field in any response to a PUBLISH request. The PUBLISH request MUST
NOT contain a Contact header.

The following header fields are included in a PUBLISH request:

Request-URI: The Request-URI initially contains the address-of-record
whose publication is to be created, removed, or modified. The
address-of-record MUST be a SIP URI or SIPS URI. Unlike the
REGISTER request, the Request-URI SHOULD contain both "userinfo"
and "@" components.

Niemi Expires December 28, 2003 [Page 7]

Internet-Draft SIP Presence Publication June 2003

To: The To header field contains the address-of-record whose
publication is to be created, removed, or modified. The To header
field and the Request-URI field are typically the same. This
address-of-record MUST be a SIP URI or SIPS URI.

From: The From header field contains the address-of-record of the
entity responsible for the publication. The value is the same as
the To header field unless the request is a third-party
publication. This address-of-record MUST be a SIP URI or SIPS URI.

Event: PUBLISH requests MUST contain a single Event header field. The
value of this header field indicates the event package for which
this request is publishing event state.

Expires: PUBLISH requests SHOULD contain a single Expires header
field. This value indicates the lifetime of the event state being
published by this request. A special value of "0" indicates the
removal of any prior soft state established by a prior PUBLISH
request from this EPA.

If-Match: PUBLISH requests MAY contain a single If-Match header
field. This header field SHOULD contain one or more entity-tags
provided by the ESC, to be used as a versioning precondition to a
PUBLISH refresh.

The PUBLISH request MAY contain a body, which contains event state
that the client wishes to publish. The content format and semantics
are dependent on the event package identified in the Event header.

As with any other SIP message, the PUBLISH mechanism MAY use the
content indirection mechanism defined in [9]. There are no additional
requirements or restrictions on content indirection as applied to the
PUBLISH request. Content indirection is a useful mechanism for
communicating large event state information that cannot reasonably be
carried directly within the SIP signaling (PUBLISH request).

5.1 Creating Initial Publication

The PUBLISH request created by the EPA and sent to the Event State
Compositor (ESC) establishes soft state in the state agent for the
event package indicated in the request and bound to the
address-of-record in the To header of the request. Additionally, the
PUBLISH request may publish event state that is further sub-divided
into segments of event state that may be manipulated independently.
As an example, presence publication using the CPIM PIDF format may
manipulate individual tuples related to a common presentity.

Niemi Expires December 28, 2003 [Page 8]

Internet-Draft SIP Presence Publication June 2003

OPEN ISSUE: Atomicity of publication. How exactly is this handled?
Can an initial "full" PIDF document be split into separate tuples
later on? If the initial publication contains several tuples, do
each of them inherit the version identifier? How can the EPA
publish presentity level information, e.g., presentity note?

Once the initial PUBLISH request has been processed by the ESC, the
EPA MAY send subsequent PUBLISH requests to refresh, modify, or
delete the publication state established by the first PUBLISH
request. These operations will be described in subsequent sections.

EPAs MUST NOT send a new PUBLISH request (not a re-transmission)
until they have received a final response from the state agent for
the previous one or the previous PUBLISH request has timed out.

5.2 Setting the Expiration Interval

When a client sends a PUBLISH request, it SHOULD suggest an
expiration interval that indicates how long the client would like the
publication to be valid. The actual duration of the soft state is
defined by local policy at the ESC.

The expiration value is presented in the Expires header of the
PUBLISH request. If an Expires header is not present, the client is
indicating its desire for the server to choose. It is RECOMMENDED
that the PA use a value of 3600 seconds (1 hour) for this default
expiration value in the case of presence publication. The default
value is generally event package specific.

If an EPA receives a 423 (Interval Too Brief) response to a PUBLISH
request, it MAY retry the publication after changing the expiration
interval in the Expires header to be equal to or greater than the
expiration interval within the Min-Expires header field of the
423(Interval Too Brief) response.

5.3 Refreshing Event State

Each EPA is responsible for refreshing the publications that it has
previously established.

The 200 (OK) response from the state agent MUST contain an Expires
header indicating the expiration time interval for the publication.
The EPA then issues a PUBLISH request for each of its publications
before the expiration interval has elapsed.

Also, the 200 (OK) response from the state agent MUST contain an ETag
header with a single entity-tag indicating the version information of
the publication. To refresh the event state, the EPA MUST include the

Niemi Expires December 28, 2003 [Page 9]

Internet-Draft SIP Presence Publication June 2003

received entity-tag in an If-Match header field in a PUBLISH request.

Note that for the EPA, the entity-tag is simply an opaque string.
It carries no further semantics for the EPA.

The If-Match header field with the version identifier entity-tag
establishes a versioning precondition to the PUBLISH request. If the
version identifier matches the version maintained by the ESC, the
refresh is successful, and the EPA receives a 200 (OK) response. If
there is no matching version at the ESC, i.e., the refreshed event
state is out-of-date, the EPA receives a 412 (Precondition Failed)
response to the PUBLISH request.

If an EPA receives a 412 (Precondition Failed) response, it MUST NOT
reattempt to refresh the event state. Instead, the EPA SHOULD query a
principal for further actions.

OPEN ISSUE: This may need some more thought. It's easy to see that
in a presence system, the UA could prompt the user when a refresh
fails. But there may be systems consisting of automata only, where
such a concept does not make much sense.

Also, to recover from this error, the client MAY determine the
current version of the event state at the server by sending a
SUBSCRIBE request to the server and re-issue the PUBLISH request if
the event state changes again.

A PUBLISH refresh SHOULD NOT contain a body.

5.4 Modifying Event State

Modification of event state is considered a new publication similar
to the creation of initial event state. Because the modification of
event state is not a refresh publication, the EPA does not include a
versioning precondition in the PUBLISH request. Therefore, the
PUBLISH request MUST NOT include an If-Match header field, and the
EPA MUST discard any previously received version identifier for this
event state.

5.5 Removing Event State

PUBLISH establishes soft state which expires unless refreshed. This
event state may also be explicitly removed. A UA requests the
immediate removal of event state by specifying an Expires value of
"0" in the PUBLISH request. Such a request SHOULD NOT contain any
body. UAs which support PUBLISH SHOULD support this mechanism for
explicitly removing event state.

Niemi Expires December 28, 2003 [Page 10]

Internet-Draft SIP Presence Publication June 2003

5.6 Querying the Current Event State

To query the event state that the state agent in fact delivers to the
subscribers, the client may SUBSCRIBE to the event package for which
it has sent a PUBLISH, indicating the same address-of-record in the
To header. An Expires header value of "0" may be used in this
SUBSCRIBE request to do a one-time fetch of this event state as
defined in RFC3265.

6. Processing PUBLISH Requests

The Event State Compositor (ESC) is a UAS that responds to PUBLISH
requests and maintains a list of publications for a given
address-of-record. The ESC MUST ignore the Record-Route header field
if it is included in a PUBLISH request. The ESC MUST NOT include a
Record-Route header field in any response to a PUBLISH request.

The ESC has to know (for example, through configuration) the set of
domain(s) for which it maintains event state. PUBLISH requests MUST
be processed in the order that they are received. PUBLISH requests
MUST also be processed atomically, meaning that a particular PUBLISH
request is either processed completely or not at all.

A client may probe the ESC for the support of PUBLISH using the
OPTIONS request defined in SIP [3]. In the response to an OPTIONS
request, the ESC SHOULD include "PUBLISH" to the list of allowed
methods in the "Allow" header field. Also, it SHOULD list the
supported event packages in an "Allow-Events" header field.

The "methods" parameter for Contact may also be used to
specifically announce support for PUBLISH messages when
registering. (See reference [10] for details on the "methods"
parameter).

When receiving a PUBLISH request, the ESC follows these steps:

1. The ESC inspects the Request-URI to determine whether this
request is for a domain supported by the ESC. If not, the ESC
SHOULD proxy the request to the addressed domain.

2. To guarantee that the ESC supports any necessary extensions, the
ESC MUST process the Require header field values as described
for UASs in Section 8.2.2 of RFC3261.

3. An ESC SHOULD authenticate the UAC. Possible mechanisms for the
authentication of SIP user agents are described in Section 22 of
RFC3261.

Niemi Expires December 28, 2003 [Page 11]

Internet-Draft SIP Presence Publication June 2003

4. The ESC extracts the address-of-record from the To header field
of the request. If the address-of-record is not valid for the
domain in the Request-URI, the ESC MUST send a 404 (Not Found)
response and skip the remaining steps. Else, the URI MUST then
be converted to a canonical form. To do that, all URI parameters
MUST be removed (including the user-param), and any escaped
characters MUST be converted to their unescaped form. The
result serves as an index into the list of publications
maintained by the ESC.

5. The ESC SHOULD determine if the authenticated user is authorized
to publish for the address-of-record of the To header field. If
the authenticated user is not authorized to publish, the ESC
MUST return a 403 (Forbidden).

Note that this authorization may take into account third
party publication of event state.

6. The ESC examines the Event header of the PUBLISH request. If the
Event header is missing or contains an event package which the
ESC does not support, the ESC MUST respond to the PUBLISH
request with a 489 (Bad Event) response.

7. The ESC now processes the Expires header value from the PUBLISH
request.

* If the request has an Expires header field, that value MUST
be taken as the requested expiration.

* Else, a locally-configured default value MUST be taken as the
requested expiration.

* The ESC MAY choose an expiration less than the requested
expiration interval. If and only if the requested expiration
interval is greater than zero AND less than a
locally-configured minimum, the ESC MAY reject the
publication with a response of 423 (Interval Too Brief), and
skip the rest of the remaining steps. This response MUST
contain a Min-Expires header field that states the minimum
expiration interval the ESC is willing to honor.

8. The ESC examines the If-Match header of the PUBLISH request. If
the If-Match header is absent, the request is a new publication;
if the request contains a version precondition in the form of an
If-Match header field, the request is a publication refresh. The
ESC extracts any entity-tags contained in the If-Match header
and then matches those entity-tags against all locally stored
entity-tags for this address-of-record and event package. If no

Niemi Expires December 28, 2003 [Page 12]

Internet-Draft SIP Presence Publication June 2003

match is found, the ESC MUST reject the publication with a
response of 412 (Precondition Failed), and skip the remaining
steps.

9. The ESC may then process the body of the PUBLISH request (the
actual event state). If the request contains no body (when it
should contain one), or the Content-Type of the request does not
match the event-package, or is not understood by the ESC, the
ESC MUST reject the request with an appropriate response.

* For each publication, the ESC will record the target of the
publication (To URI), the source of the publication (From
URI), and the version of the publication.

Note that this version information will be generated by
the ESC when receiving a new publication, and will be
present in the If-Match header field in publication
refreshes.

* For new publications, i.e., publications without a version
precondition, the ESC MUST generate a locally unique
entity-tag, and store it, replacing any existing entity-tags
stored for that particular event state. The new entity-tag
MUST be delivered to the EPA in an ETag header field of a 200
(OK) response.

Note that the exact way in which the ESC creates the
version entity-tag is a matter of local policy. One
reasonable implementation of a version entity-tag is a
counter which is incremented by one for each new version.

* The processing of the PUBLISH request must be atomic. If
internal errors (such as the inability to access a back-end
database) occur before processing is complete, no portion of
the PUBLISH document must be published and the ESC MUST fail
with a 500 (Server Error) response.

10. The ESC returns a 200 (OK) response. The response MUST contain
an Expires header indicating the expiration interval chosen by
the ESC. The response MUST also contain an ETag header
indicating the version of the published event state. The state
agent associated with this ESC may then issue appropriate NOTIFY
requests to any watchers of this event state.

Note that the timing between the receipt of the PUBLISH
request and the issuance of NOTIFY requests is implementation
dependent and may also vary according to throttling policies
at the state agent.

Niemi Expires December 28, 2003 [Page 13]

Internet-Draft SIP Presence Publication June 2003

7. Syntax

This section describes the syntax extensions required for event
publication in SIP. Note that the formal syntax definitions described
in this section are expressed in the Augmented BNF format used in SIP
[3], and contain references to elements defined therein.

7.1 New Methods

7.1.1 PUBLISH Method

"PUBLISH" is added to the definition of the element "Method" in the
SIP message grammar. As with all other SIP methods, the method name
is case sensitive. PUBLISH is used to publish event state to an
entity responsible for compositing this event state.

Table 1 and Table 2 extend Tables 2 and 3 of RFC 3261 [3] by adding
an additional column, defining the header fields that can be used in
PUBLISH requests and responses.

Niemi Expires December 28, 2003 [Page 14]

Internet-Draft SIP Presence Publication June 2003

+---------------------+---------+-------+-----+
| Header Field | where | proxy | PUB |
+---------------------+---------+-------+-----+
| Accept | R | | - |
| Accept | 2xx | | - |
| Accept | 415 | | m* |
| Accept-Encoding | R | | - |
| Accept-Encoding | 2xx | | - |
| Accept-Encoding | 415 | | m* |
| Accept-Language | R | | - |
| Accept-Language | 2xx | | - |
| Accept-Language | 415 | | m* |
| Alert-Info | R | | - |
| Alert-Info | 180 | | - |
| Allow | R | | o |
| Allow | 2xx | | o |
| Allow | r | | o |
| Allow | 405 | | m |
| Authentication-Info | 2xx | | o |
| Authorization | R | | o |
| Call-ID | c | r | m |
| Call-Info | | ar | o |
| Contact | R | | - |
| Contact | 1xx | | - |
| Contact | 2xx | | - |
| Contact | 3xx | | o |
| Contact | 485 | | o |
| Content-Disposition | | | o |
| Content-Encoding | | | o |
| Content-Language | | | o |
| Content-Length | | ar | t |
| Content-Type | | | * |
| CSeq | c | r | m |
| Date | | a | o |
| Event | a | m | |
| Error-Info | 300-699 | a | o |
| Expires | | | o |
| From | c | r | m |
| In-Reply-To | R | | o |
| Max-Forwards | R | amr | m |
| Organization | | ar | o |
+---------------------+---------+-------+-----+

Table 1: Summary of header fields, A--O

Niemi Expires December 28, 2003 [Page 15]

Internet-Draft SIP Presence Publication June 2003

+---------------------+-----------------+-------+-----+
| Header Field | where | proxy | PUB |
+---------------------+-----------------+-------+-----+
| Priority | R | ar | o |
| Proxy-Authenticate | 407 | ar | m |
| Proxy-Authenticate | 401 | ar | o |
| Proxy-Authorization | R | dr | o |
| Proxy-Require | R | ar | o |
| Record-Route | | ar | - |
| Reply-To | | | o |
| Require | | ar | c |
| Retry-After | 404,413,480,486 | | o |
| | 500,503 | | o |
| | 600,603 | | o |
| Route | R | adr | o |
| Server | r | | o |
| Subject | R | | o |
| Timestamp | | | o |
| To | c(1) | r | m |
| Unsupported | 420 | | o |
| User-Agent | | | o |
| Via | R | amr | m |
| Via | rc | dr | m |
| Warning | r | | o |
| WWW-Authenticate | 401 | ar | m |
| WWW-Authenticate | 407 | ar | o |
+---------------------+-----------------+-------+-----+

Table 2: Summary of header fields, P--Z

7.2 New Response Codes

7.2.1 "412 Precondition Failed" Response Code

The event state that 412 response is published through the PUBLISH method added to a
compositor/event agent the "Client-Error" header field
definition. "412 Precondition Failed" is soft-state. As such, used to indicate that the PUBLISH SHOULD
contain an expiration value
precondition given for the event state data it is
publishing. The intention request has failed.

7.3 New Header Fields

Table 3 expands on Table 2 in SIP [3], as amended by the changes in
Section 7.1.

Niemi Expires December 28, 2003 [Page 16]

Internet-Draft SIP Presence Publication June 2003

+--------------+-------+-------+-----+
| Header Field | where | proxy | PUB |
+--------------+-------+-------+-----+
| ETag | 2xx | | m |
| If-Match | R | | o |
+--------------+-------+-------+-----+

Table 3: Summary of header fields, A--O

7.3.1 "ETag" Header

ETag is added to inform the compositor definition of the
expected duration of this event state. This is a separate concern
from informing element "general-header" in
the watchers SIP message grammar. Usage of this event state of header is described in Section
6.

7.3.2 "If-Match" Header

If-Match is added to the duration definition of the composite state.

The publication state expiration should be carried through the
standard Expires: header as defined element "general-header"
in RFC3261. The value the SIP message grammar. Usage of this
expiration may be decreased by the compositor from header is described in
Section 5.

7.4 Augmented BNF Definitions

This section describes the expiration
given by Augmented BNF definitions for the publisher, but SHOULD NOT be increased. various
new and modified syntax elements. The final
response to the PUBLISH request MUST carry the expiration value
chosen by the compositor notation is as used in an Expires: header. In the absence of an
Expires: header, SIP [3]
and the compositor is free documents to choose which it refers.

PUBLISHm = %x50.55.42.4C.49.53.48 ; PUBLISH in caps.
extension-method = PUBLISHm / token
ETag = "ETag" HCOLON entity-tag
If-Match = "If-Match" HCOLON entity-tag
* (COMMA entity-tag)
entity-tag = quoted-string

8. IANA Considerations

This document registers a reasonable
default. It new method name, a new response code and
two new header field names.

8.1 Methods

This document registers a new SIP method, defined by the following
information which is RECOMMENDED that a default of 3600 seconds or one
hour to be used. The default expiration may vary from event package added to
event package depending on the semantics of the particular package.

Campbell, et al. method and response-code
sub-registry under http://www.iana.org/assignments/sip-parameters.

Niemi Expires August 25, December 28, 2003 [Page 8] 17]

Internet-Draft PUBLISH method February SIP Presence Publication June 2003

When the event state expires, the publisher MAY choose to refresh the
publication state by sending another

Method Name: PUBLISH request. When the event
state expires, the compositor should apply local policy
Reference: [RFCYYYY]

(Note to determine
the new composite event state based on RFC Editor: Replace YYYY with the removal or expiration RFC number of this particular publication input.
document when published).

8.2 Response Codes

This will typically result in the
generation of document registers a new notifications for response code. This response code is
defined by the watchers of following information, which is to be added to the composite
event state.

3.4 Event
method and response-code sub-registry under http://www.iana.org/
assignments/sip-parameters.

Response Code Number: 412
Default Reason Phrase: Precondition Failed

8.3 Header

Every PUBLISH request MUST contain an Event: Field Names

This document registers two new SIP header indicating field names. These headers
are defined by the
event package for following information, which this publication is carrying event state. In to be added to the absence of an Event: header,
header sub-registry under http://www.iana.org/assignments/
sip-parameters.

Header Name: ETag
Compact Form: (none)

Header Name: If-Match
Compact Form: (none)

9. Security Considerations

The state agent SHOULD authenticate the compositor MUST return a 489 Bad Event response. Publication Agent
(EPA), and SHOULD apply its authorization policies to all requests.
The publish mechanism described composition model makes no assumptions that all input sources for
a compositor (ESC) are on the same network, or in this document is
only intended to be applied to state associated with an event
package. This is the rationale behind requiring same
administrative domain.

The ESC SHOULD throttle incoming publications and the presence of an
Event: header.

When presence information is sent corresponding
notifications resulting from the changes in event state. As a PUBLISH method, first
step, careful selection of default Expires: values for the 'presence' supported
event packages at a ESC can help limit refreshes of event state.
Additional throttling and debounce logic at the ESC is specified. When advisable to
further reduce the notification traffic produced as a compositor that supports presence sends result of a
489 Bad Event response, it MUST indicate that it supports the
'presence' event.

3.5
PUBLISH and Presence Formats

All method.

Niemi Expires December 28, 2003 [Page 18]

Internet-Draft SIP implementations that support the PUBLISH method, Presence Publication June 2003

Integrity protection and use the
'presence' event, MUST implement privacy of the Presence Information Data Format
(PIDF [6]) as a MIME body type that PUBLISH requests can be sent
ensured using the S/MIME mechanisms outlined in section 23 of
RFC3261. Integrity protection of the To, From, Call-ID, CSeq, Event,
ETag, If-Match, Route, and Expires headers should be done at a PUBLISH method.
minimum.

If a compositor does not support the presence format provided by ESC receives a
publisher, it MUST return PUBLISH request which is integrity protected
using a 415 Unsupported Media Type security association that is not with an Accept
header listing the presence formats ESC (for example,
end-to-end S/MIME integrity protection), the state agent coupled with
the ESC MUST NOT modify the event state before exposing it does support (including
'application/cpim-pidf+xml', to the media type
watchers of PIDF).

4. Examples this event state in a NOTIFY request(s). This is to
preserve the end-to-end integrity of Use the event state.

10. Examples

The following section shows an example of the usage of the PUBLISH
method in the case of publishing the presence document from a
presence user agent to a presence agent. The watcher in this case is
watching the PUA's presentity, and has previously subscribed
successfully.

Campbell, et al. Expires August 25, 2003 [Page 9]

Internet-Draft PUBLISH method February 2003 presentity. The PUA will SUBSCRIBE to its own
presence to see the composite presence state exposed by the PA. This
is an optional but likely step for the PUA.

PUA PA WATCHER
(EPA) (ESC)
| | |
| | <---- 1. M1: SUBSCRIBE ---- --- |
| | |
| | ----- M2: 200 OK ------> -----> |
| | |
| | ----- 2. M3: NOTIFY ------> -----> |
| | |
| | <---- M4: 200 OK ------- ------ |
| | |
| ---- 3. --- M5: SUBSCRIBE --> | |
| | |
|<--- M6: 200 OK --> | |
| | |
|<--- M7: NOTIFY ----- | |
| | |
| --- M8: 200 OK --> | |
| | |
| --- M9: PUBLISH ----> | |
| | |
| <--- 4. <-- M10: 200 OK ---- | |
| | |
| | ----- M11: NOTIFY ----> |
| | |

Niemi Expires December 28, 2003 [Page 19]

Internet-Draft SIP Presence Publication June 2003

| | <---- M12: 200 OK ------ ----- |
| | |
| | | ----- 5.
|<---- M13: NOTIFY ------> | ---- | |
| | | <----
|----- M14: 200 OK ------- --> | |
| | |

Message flow:

M1: The watcher initiates a new subscription to the
presentity@domain.com's presence agent.

SUBSCRIBE sip:presentity@domain.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bKnashds7
To: <sip:presentity@domain.com>
From: <sip:watcher@domain.com>;tag=12341234
Call-ID: 12345678@10.0.0.1
CSeq: 1 SUBSCRIBE
Expires: 3600
Event: presence
Contact: <sip:watcher@domain.com>
Content-Length: 0

M2: The presence agent for presentity@domain.com processes the
subscription request and creates a new subscription. A 200 (OK)
response is sent to confirm the subscription.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bKnashds7
To: <sip:presentity@domain.com>;tag=abcd1234
From: <sip:watcher@domain.com>;tag=12341234
Call-ID: 12345678@10.0.0.1
CSeq: 1 SUBSCRIBE
Contact: <sip:pa@domain.com>
Expires: 3600
Content-Length: 0

M3: In order to complete the process process, the presence agent sends the
watcher a NOTIFY with the current with the current presence state of the
presentity.

NOTIFY sip:presentity@domain.com SIP/2.0
Via: SIP/2.0/UDP pa.domain.com;branch=z9hG4bK8sdf2
To: <sip:watcher@domain.com>;tag=12341234
From: <sip:presentity@domain.com>;tag=abcd1234
Call-ID: 12345678@10.0.0.1

Niemi Expires December 28, 2003 [Page 20]

Internet-Draft SIP Presence Publication June 2003

CSeq: 1 NOTIFY
Event: presence
Subscription-State: active; expires=3599
Content-Type: application/cpim-pidf+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
entity="pres:presentity@domain.com">
<tuple id="mobile-phone">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T16:49:29Z</timestamp>
</tuple>
<tuple id="desktop">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T12:21:29Z</timestamp>
</tuple>
</presence>

M4: The watcher confirms receipt of the NOTIFY request.

SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.domain.com;branch=z9hG4bK8sdf2
To: <sip:watcher@domain.com>;tag=12341234
From: <sip:presentity@domain.com>;tag=abcd1234
Call-ID: 12345678@10.0.0.1
CSeq: 1 NOTIFY
Contact: <sip:watcher@domain.com>

M5: To view its composite presence state, the PUA issues a SUBSCRIBE
to the PA for itself.

SUBSCRIBE sip:presentity@domain.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bKjjsdfj
To: <sip:presentity@domain.com>
From: <sip:presentity@domain.com>;tag=43214321
Call-ID: 87654321@10.0.0.2
CSeq: 1 SUBSCRIBE
Expires: 3600
Event: presence
Contact: <sip:pua@domain.com>
Content-Length: 0

Niemi Expires December 28, 2003 [Page 21]

Internet-Draft SIP Presence Publication June 2003

M6: The presence agent for presentity@domain.com processes the
subscription request and creates a new subscription. A 200 (OK)
response is sent to confirm the subscription.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.2:5060;branch=z9hG4bKjjsdfj
To: <sip:presentity@domain.com>;tag=abcd1235
From: <sip:watcher@domain.com>;tag=43214321
Call-ID: 87654321@10.0.0.2
CSeq: 1 SUBSCRIBE
Contact: <sip:pa@domain.com>
Expires: 3600
Content-Length: 0

M7: In order to complete the process, the presence agent sends the
PUA a NOTIFY with the current presence state of the presentity.

NOTIFY sip:presentity@domain.com SIP/2.0
Via: SIP/2.0/UDP pa.domain.com;branch=z9hG4bK8sdfk
To: <sip:watcher@domain.com>;tag=abcd1235
From: <sip:presentity@domain.com>;tag=43214321
Call-ID: 87654321@10.0.0.2
CSeq: 1 NOTIFY
Event: presence state of the presentity.

3.
Subscription-State: active; expires=3599
Content-Type: application/cpim-pidf+xml
Content-Length: ...

Niemi Expires December 28, 2003 [Page 22]

Internet-Draft SIP Presence Publication June 2003

M9: A presence user agent for the presentity detects a change in the
user's presence state. It initiates a PUBLISH to the presentity's
presence agent in order to update it with the new presence
information.

4. The presence agent receives, and accepts timestamp element is updated to indicate the presence
information. time
of the change. The published data is incorporated into Expires header indicates the
presentity's presence document.

5. desired duration
of this soft state. The presence agent determines that a reportable change has been
made to "entity" attribute of the presentity's presence document, and sends another
notification to those watching element
in the presentity to update their
information regarding PIDF document matches the presentity's current presence status.

Messages:

Campbell, et al. Expires August 25, 2003 [Page 10]

Internet-Draft To AOR.

PUBLISH method February 2003

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bKnashds7 pua.domain.com;branch=z9hG4bK652hsge
To: <sip:presentity@domain.com>;tag=abcd1234 <sip:presentity@domain.com>;tag=1a2b3c4d
From: <sip:watcher@domain.com>;tag=12341234 <sip:presentity@domain.com>;tag=1234wxyz
Call-ID: 12345678@10.0.0.1 81818181@pua.domain.com
CSeq: 1 SUBSCRIBE
Contact: <sip:watcher@domain.com> PUBLISH
Expires: 3600
Content-Length: 0

Campbell, et al. Expires August 25, 2003 [Page 11]

Internet-Draft PUBLISH method February 2003

NOTIFY sip:presentity@domain.com SIP/2.0
Via: SIP/2.0/UDP presence.domain.com;branch=z9hG4bK8sdf2
To: <sip:watcher@domain.com>;tag=12341234
From: <sip:presentity@domain.com>;tag=abcd1234
Call-ID: 12345678@10.0.0.1
CSeq: 1 NOTIFY
Event: presence
Subscription-State: active; expires=3599
Content-Type: application/cpim-pidf+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
entity="pres:presentity@domain.com">
<tuple id="j599ab8xx"> id="mobile-phone">
<status>
<basic>open</basic>
</status>
</tuple>
<tuple id="pl813rt4yh">
<status>
<basic>open</basic>
<basic>closed</basic>
</status>
<timestamp>2003-02-01T17:00:19Z</timestamp>
</tuple>
</presence>

M10: The presence agent receives, and accepts the presence
information. The published data is incorporated into the
presentity's presence document. A 200 (OK) response is sent to
confirm the publication.

SIP/2.0 200 OK
Via: SIP/2.0/UDP presence.domain.com;branch=z9hG4bK8sdf2 pua.domain.com;branch=z9hG4bK652hsge
To: <sip:watcher@domain.com>;tag=12341234 <sip:presentity@domain.com>;tag=1a2b3c4d
From: <sip:presentity@domain.com>;tag=abcd1234 <sip:presentity@domain.com>;tag=1234wxyz
Call-ID: 12345678@10.0.0.1 81818181@pua.domain.com
CSeq: 1 NOTIFY

Campbell, et al. PUBLISH
ETag: "dx200xyz"
Expires: 1800

M11: The presence agent determines that a reportable change has been
made to the presentity's presence document, and sends another
notification to those watching the presentity to update their
information regarding the presentity's current presence status.

Niemi Expires August 25, December 28, 2003 [Page 12] 23]

Internet-Draft PUBLISH method February SIP Presence Publication June 2003

PUBLISH

NOTIFY sip:presentity@domain.com SIP/2.0
Via: SIP/2.0/UDP pua.domain.com;branch=z9hG4bK652hsge presence.domain.com;branch=z9hG4bK4cd42a
To: <sip:presentity@domain.com>;tag=1a2b3c4d <sip:watcher@domain.com>;tag=12341234
From: <sip:presentity@domain.com>;tag=1234wxyz <sip:presentity@domain.com>;tag=abcd1234
Call-ID: 12345678@pua.domain.com 12345678@10.0.0.1
CSeq: 1 PUBLISH
Expires: 3600 2 NOTIFY
Event: presence
Class: mobile
Stream: 1@pua.domain.com
Facet: <sip:watcher@domain.com>
Subscription-State: active; expires=3400
Content-Type: application/cpim-pidf+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
entity="pres:presentity@domain.com">
<tuple id="j599ab8xx"> id="mobile-phone">
<status>
<basic>closed</basic>
</status>
<timestamp>2003-02-01T17:00:19Z</timestamp>
</tuple>
<tuple id="desktop">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T12:21:29Z</timestamp>
</tuple>
</presence>

M12: The watcher confirms receipt of the NOTIFY request.

SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.domain.com;branch=z9hG4bK652hsge presence.domain.com;branch=z9hG4bK4cd42a
To: <sip:presentity@domain.com>;tag=1a2b3c4d <sip:watcher@domain.com>;tag=12341234
From: <sip:presentity@domain.com>;tag=1234wxyz <sip:presentity@domain.com>;tag=abcd1234
Call-ID: 12345678@pua.domain.com 12345678@10.0.0.1
CSeq: 1 PUBLISH
Expires: 1800

Campbell, et al. Expires August 25, 2003 [Page 13]

Internet-Draft PUBLISH method February 2003 2 NOTIFY
Content-Length: 0

M13: The presence agent also sends a NOTIFY to the PUA.

NOTIFY sip:presentity@domain.com SIP/2.0
Via: SIP/2.0/UDP presence.domain.com;branch=z9hG4bK4cd42a presence.domain.com;branch=z9hG4bK4cd42b
To: <sip:watcher@domain.com>;tag=12341234 <sip:watcher@domain.com>;tag=abcd1235
From: <sip:presentity@domain.com>;tag=abcd1234 <sip:presentity@domain.com>;tag=43214321
Call-ID: 12345678@10.0.0.1 87654321@10.0.0.2
CSeq: 2 NOTIFY
Event: presence
Subscription-State: active; expires=3599 expires=3400

Niemi Expires December 28, 2003 [Page 24]

Internet-Draft SIP Presence Publication June 2003

Content-Type: application/cpim-pidf+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
entity="pres:presentity@domain.com">
<tuple id="j599ab8xx"> id="mobile-phone">
<status>
<basic>closed</basic>
</status>
<timestamp>2003-02-01T17:00:19Z</timestamp>
</tuple>
<tuple id="pl813rt4yh"> id="desktop">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T12:21:29Z</timestamp>
</tuple>
</presence>

M14: The PUA confirms receipt of the NOTIFY request.

SIP/2.0 200 OK
Via: SIP/2.0/UDP presence.domain.com;branch=z9hG4bK4cd42a presence.domain.com;branch=z9hG4bK4cd42b
To: <sip:watcher@domain.com>;tag=12341234 <sip:watcher@domain.com>;tag=abcd1235
From: <sip:presentity@domain.com>;tag=abcd1234 <sip:presentity@domain.com>;tag=43214321
Call-ID: 12345678@10.0.0.1 87654321@10.0.0.2
CSeq: 2 NOTIFY

5. IANA Considerations

This document introduces no considerations for the IANA.

6. Security Considerations

Like all SIP entities, implementations of the PUBLISH method MUST
meet all

11. Open Issues

o Atomicity of publication. Should the security implementation requirements segments of RFC3261
26.3.1.

Campbell, et al. Expires August 25, 2003 [Page 14]

Internet-Draft event state
(presence tuples) be sent in separate PUBLISH method February 2003

A presence compositor requests or is it
enough to treat these as implicitly separate publication requests?

o The exact naming convention used for the tuple-ID when publishing
tuples.

o In case a refresh publication fails, what should use the standard SIP security mechanisms EPA do?
Current suggestion is to authenticate publishing user agents, and may apply authorization
policies for query the distribution of presence information (following principal, i.e., "prompt the
model described by SIMPLE data manipulation [5]). The composition
model makes no assumptions
user", but this is not quite specific.

o Does end-to-end S/MIME integrity protection make sense when an
event compositor is used? Does it indicate that all input sources the segment should
be carried to the watcher intact, or is another mechanism for this
needed?

Niemi Expires December 28, 2003 [Page 25]

Internet-Draft SIP Presence Publication June 2003

o The examples seem a compositor
are bit elaborate, and don't even cover the
publication refresh case. We should probably work on the same network, them.

o Do we need another response code (new or in some existing one) for
the same administrative domain.

The compositor should throttle incoming publications and case when an EPA tries to refresh a publication, but the
corresponding notifications resulting ESC
has lost all version information it has, e.g., after e reboot?
This seems a slightly different scenario from the usual
"Precondition Failed".

12. Contributors

The original contributors to this specification are:

Ben Campbell
dynamicsoft

Sean Olson
Microsoft

Jon Peterson
Neustar, Inc.

Jonathan Rosenberg
dynamicsoft

Brian Stucker
Nortel Networks, Inc.

13. Changes from "draft-ietf-simple-publish-00"

The following changes in event
state. As a first step, careful selection of default Expires: values
for were made since the supported event packages at a compositor can help limit
refreshes last version:

o Merged with "draft-olson-simple-publish-02"

o Removed usage of event state. Additional throttling Call-ID and debounce logic
at the compositor is advisable CSeq for ordering

o Removed timestamp based versioning

o Added versioning based on entity-tag version information (ETag),
and request precondition (If-Match)

o Changed reference to further reduce the notification
traffic produced content-indirection as a result Informative

o Added section for ABNF definitions

o Editorial corrections, restructuring of a PUBLISH method.

The Class header can factor heavily into policy at the compositor.
For this reason, it is important document to protect improve

Niemi Expires December 28, 2003 [Page 26]

Internet-Draft SIP Presence Publication June 2003

readability

o Moved the integrity original authors into a new "Contributors" section

o Added new definitions in Terminology, and
potentially the privacy of the PUBLISH headers. It is recommended
that appropriate SIP integrity clarified EPA and privacy measures be used be
employed by publishers ESC
definitions

o Strengthened the IANA considerations section.

o Added text for announcing/probing support for publish, namely
OPTIONS and compositors. "methods" parameter usage.

Normative References

[1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.

[2] Campbell, B., "SIMPLE Presence Publication Requirements",
draft-ietf-simple-publish-reqs-00 (work in progress), February
2003.

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

[2] Roach, A., "Session Initiation Protocol(SIP)-Specific Event
Notification", RFC 3265, June 2002.

[3]

[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.

[4] Campbell, B., Olson, S., Peterson, J., Rosenberg, J. and B.
Stucker, "SIP Presence Publication Mechanism Requirements",
draft-ietf-simple-publish-reqs-00 (work in progress), February
2003. Requirement
Levels", BCP 14, RFC 2119, March 1997.

[5] Rosenberg, J. and M. Isomaki, "Requirements J., "A Presence Event Package for Manipulation of
Data Elements in SIMPLE Systems", draft-ietf-simple-data-reqs-00 the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), October 2002. January 2003.

[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A. S. and W. Carr, H. Sugano, "Common Presence and Instant
Messaging (CPIM) Presence (CPIM)Presence Information Data Format", draft-ietf-impp-cpim-pidf-05
draft-ietf-impp-cpim-pidf-07 (work in progress), May 2002. January 2003.

Informative References

[7] <http://www.ietf.org/html.charters/simple-charter.html>

Campbell, et al. Expires Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.

[8] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.

[9] Olson, S., "A Mechanism for Content Indirection in SIP
Messages", draft-olson-sip-content-indirect-mech-01 (work in
progress), August 25, 2003 [Page 15]

Internet-Draft PUBLISH method February 2003

Authors' Addresses

Ben Campbell
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75025
US

EMail: bcampbell@dynamicsoft.com

Sean Olson
Microsoft
One Microsoft Way
Redmond, WA 98052
US

Phone: +1-425-707-2846
EMail: seanol@microsoft.com
URI: http://www.microsoft.com/rtc

Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US

Phone: +1-925-363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz

Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
US

EMail: jdrosen@dynamicsoft.com

Campbell, et al. 2002.

Niemi Expires August 25, December 28, 2003 [Page 16] 27]

Internet-Draft PUBLISH method February SIP Presence Publication June 2003

Brian Stucker
Nortel Networks, Inc.
2380 Performance Drive
Richardson, TX 75082
US

[10] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller
Preferences and Callee Capabilities for the Session Initiation
Protocol (SIP)", draft-ietf-sip-callerprefs-08 (work in
progress), March 2003.

Author's Address

Aki Niemi (editor)
Nokia
P.O. Box 321
NOKIA GROUP, FIN 00045
Finland

Phone: +358 50 389 1644
EMail: bstucker@nortelnetworks.com

Campbell, et al. aki.niemi@nokia.com

Niemi Expires August 25, December 28, 2003 [Page 17] 28]

Internet-Draft PUBLISH method February SIP Presence Publication June 2003

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. assignees.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Niemi Expires December 28, 2003 [Page 29]

Internet-Draft SIP Presence Publication June 2003

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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

Campbell, et al.

Niemi Expires August 25, December 28, 2003 [Page 18] 30]

----