WDIFF

draft-ietf-sip-publish-02.txt --> draft-ietf-sip-publish-03.txt

SIP WG A. Niemi, Ed.
Internet-Draft Nokia
Expires: July 5, August 13, 2004 January 5, February 13, 2004

An Event State Publication Extension to the Session Initiation
Protocol (SIP) Extension for Event State
Publication
draft-ietf-sip-publish-02
draft-ietf-sip-publish-03

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 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 5, August 13, 2004.

Abstract

This document describes an extension to the Session Initiation
Protocol (SIP) for publishing event state used within the framework
for SIP Event Notification. Events
framework. The first application of this extension is for the
publication of presence information.

The mechanism described in this document can be extended to support
publication of any event state, state for which there exists an appropriate
event package. It is not intended to be a general-purpose mechanism
for transport of arbitrary data, as there are better-suited
mechanisms for this purpose (FTP, HTTP, etc.) purpose.

Niemi Expires July 5, August 13, 2004 [Page 1]

Internet-Draft SIP Event State Publication January February 2004

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions and Document Conventions . . . . . . . . . . . . 4
3. Overall Operation . . . . . . . . . . . . . . . . . . . . . 5
4. Considerations for Event Packages using PUBLISH . . . . . . 6
4.1 Constructing PUBLISH Bodies Requests . . . . . . . . . . . . . . 6
4.1 Identification of Published Event State . . . . . . . . . 6 7
4.2 PUBLISH Response Bodies . . . Creating Initial Publication . . . . . . . . . . . . . . . 6 8
4.3 Multple Sources for Refreshing Event State . . . . . . . . . . . . . . 6 . . . . 9
4.4 Modifying Event State Segmentation . . . . . . . . . . . . . . . . . . 7 9
4.5 Rate of Publication . Removing Event State . . . . . . . . . . . . . . . . . . . 7 10
5. Constructing Processing PUBLISH Requests Responses . . . . . . . . . . . . . . . 7
5.1 Identification of Published Event State 11
6. Processing PUBLISH Requests . . . . . . . . . . 8
5.2 Creating Initial Publication . . . . . 11
7. Processing OPTIONS Requests . . . . . . . . . . . 10
5.3 Setting the Expiration Interval . . . . 13
8. Use of Entity-tags in PUBLISH . . . . . . . . . . 10
5.4 Refreshing Event State . . . . 14
8.1 General Notes . . . . . . . . . . . . . . . 10
5.5 Modifying Event State . . . . . . . 14
8.2 Client Usage . . . . . . . . . . . . 11
5.6 Removing Event State . . . . . . . . . . . 14
8.3 Server Usage . . . . . . . . . 12
5.7 Querying the Current Event State . . . . . . . . . . . . . . 12
5.8 Error Responses 15
9. Controlling the Rate of Publication . . . . . . . . . . . 15
10. Considerations for Event Packages using PUBLISH . . . . . 16
10.1 PUBLISH Bodies . . . . . . 12
6. Processing PUBLISH Requests . . . . . . . . . . . . . . . . 13
7. Use of Entity-tags in 16
10.2 PUBLISH Response Bodies . . . . . . . . . . . . . . . . 15
7.1 General Notes . 16
10.3 Multiple Sources for Event State . . . . . . . . . . . . . 16
10.4 Event State Segmentation . . . . . . . . . 15
7.2 Client Usage . . . . . . . . 17
10.5 Rate of Publication . . . . . . . . . . . . . . . . 16
7.3 Server Usage . . . 17
11. Protocol Element Definitions . . . . . . . . . . . . . . . 17
11.1 New Methods . . . . . . 16
8. Controlling the Rate of Publication . . . . . . . . . . . . 17
9. Syntax . . . . . 17
11.1.1 PUBLISH Method . . . . . . . . . . . . . . . . . . . . . . 17
9.1 18
11.2 New Methods . Response Codes . . . . . . . . . . . . . . . . . . . . 20
11.2.1 "412 Precondition Failed" Response Code . . . 17
9.1.1 PUBLISH Method . . . . . . 20
11.3 New Header Fields . . . . . . . . . . . . . . . . . 17
9.2 New Response Codes . . . . . . . . . . . . . . . . . . . . . 20
9.2.1 "412 Precondition Failed" Response Code . . . . . . . . . . 20
9.3 New Header Fields . . . . . . . . . . . . . . . . . . . . . 20
9.3.1 "SIP-ETag" Header Field . 20
11.3.1 "SIP-ETag" Header Field . . . . . . . . . . . . . . . . . 21
9.3.2
11.3.2 "SIP-If-Match" Header Field . . . . . . . . . . . . . . . . 21
9.4
12. Augmented BNF Definitions . . . . . . . . . . . . . . . . . 21
10.
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
10.1 22
13.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2
13.2 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 22
10.3
13.3 Header Field Names . . . . . . . . . . . . . . . . . . . . . 22
11.
14. Security Considerations . . . . . . . . . . . . . . . . . . 22
11.1 23
14.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . 22
11.2 23
14.2 Denial of Service Attacks . . . . . . . . . . . . . . . . . 23
11.3
14.3 Replay Attack . . . . . . . . . . . . . . . . . . . . . . . 23
11.4
14.4 Man in the Middle Attacks . . . . . . . . . . . . . . . . . 23
11.5 24
14.5 Confidentiality . . . . . . . . . . . . . . . . . . . . . . 24
12.
15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13. 25
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
14.
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33

Niemi Expires July 5, 2004 [Page 2]

Internet-Draft SIP Event State Publication January 2004

15.
18. Document Change History . . . . . . . . . . . . . . . . . 33

Niemi Expires August 13, 2004 [Page 2]

Internet-Draft SIP Event State Publication February 2004

18.1 Changes since "draft-ietf-sip-publish-02" . . . . . . . . 33
15.1
18.2 Changes since "draft-ietf-sip-publish-01" . . . . . . . . . 33
15.2 34
18.3 Changes since "draft-ietf-sip-publish-00" . . . . . . . . . 34
15.3 35
18.4 Changes since "draft-ietf-simple-publish-01" . . . . . . . . 34
15.4 35
18.5 Changes since "draft-ietf-simple-publish-00" . . . . . . . . 35 36
Normative References . . . . . . . . . . . . . . . . . . . . 36 37
Informative References . . . . . . . . . . . . . . . . . . . 36 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . 37 38
Intellectual Property and Copyright Statements . . . . . . . 38 39

Niemi Expires July 5, August 13, 2004 [Page 3]

Internet-Draft SIP Event State Publication January February 2004

1. Introduction

The focus of this

This specification is to provide provides a framework for the publication of event
state from a user agent to an entity that is responsible for
compositing this event state and distributing it to interested
parties through the SIP events Events [1] framework.

The first application of

In addition to defining an event publication framework, this mechanism is
specification defines a concrete usage of that framework for the
publication of presence state [2] by a presence user agent [3] to a
presence compositor, which has a tightly coupled relationship with
the presence agent. agent [1].

The requirements and model for presence publication are documented in
[5].
[10]. This specification will address each of those requirements.

The mechanism described in this document can be extended to support
publication of any event state, state for which there exists an appropriate
event package as defined in [1]. It is not intended to be a
general-purpose mechanism for transport of arbitrary data, as there
are better-suited mechanisms for this purpose (FTP [6], HTTP [7],
etc.) purpose.

2. Definitions and Document Conventions

In addition to the definitions of RFC 2778 [3], RFC 3265 [1] [1], and RFC
3261 [2], [4], this document introduces some new concepts:

Event State: State information for a resource, associated with an
event package and an address-of-record.

Event Publication Agent (EPA): The UAC that issues PUBLISH requests
to publish event state.

Event State Compositor (ESC): The UAS that processes PUBLISH
requests, and is responsible of for compositing event state into a
complete, composite event state of a resource.

Presence Compositor: A type of Event State Compositor that is
responsible for compositing presence state for a presentity.

Publication: The act of an EPA sending a PUBLISH request to an ESC to
publish event state.

Event Hard State: The steady-state or default event state of a
resource, which the ESC may use in the absence of, or in addition
to, event soft state publications.

Niemi Expires August 13, 2004 [Page 4]

Internet-Draft SIP Event State Publication February 2004

Event Soft State: Event state published by an EPA using the PUBLISH
mechanism. A protocol element (i.e., an entity-tag) is used to
identify a specific event soft state entity at the ESC. Soft Event soft
state has a defined lifetime and will expire after a negotiated
amount of time.

Niemi Expires July 5, 2004 [Page 4]

Internet-Draft SIP Event State Publication January 2004

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

Indented passages such as this one are used in this document to
provide additional information and clarifying text. They do not
contain descriptions of normative protocol behavior.

3. Overall Operation

This document defines a new SIP method, PUBLISH, for publishing event
state. PUBLISH is similar to REGISTER in that it allows a user to
create, modify, and remove state in another entity which manages this
state on behalf of the user. Addressing a PUBLISH request is
identical to addressing a SUBSCRIBE request. The Request-URI of a
PUBLISH request is populated with the address of the resource for
which the user wishes to publish event state. The user may in turn
have multiple UAs or endpoints that publish event state. Each
endpoint may publish its own unique state, out of which the event
agent
state compositor generates the composite event state of the resource.
In addition to a particular resource, all published event state is
associated with a specific event package. Through a subscription to
that event package, the user is able to discover the composite event
state of all of the active publications.

In the generic sense, a

A UAC that publishes event state is labeled an Event Publication
Agent (EPA). For presence, this is the familiar PUA role as defined
in [8]. [2]. The entity that processes the PUBLISH request is known as an
Event State Compositor (ESC). For presence, this is the familiar PA
role as defined in [8]. [2].

PUBLISH requests create soft state in the ESC. This event soft state
has a defined lifetime and will expire after a negotiated amount of
time, requiring the publication to be refreshed by subsequent PUBLISH
requests. Local policy at the compositor There may in turn define also be event hard state provisioned for each
resource for a particular event package. That is, This event state represents
the steady-state of
this resource state that is present at all times, and does not expire.
The ESC may use event package hard state in the absence of, or in addition
to, event soft state provided through the PUBLISH mechanism. Setting
this event hard state or configuring the composer ESC policy regarding the

Niemi Expires August 13, 2004 [Page 5]

Internet-Draft SIP Event State Publication February 2004

aggregation of different event state is out of the scope of this
specification.

Typically, the

The body of a PUBLISH request carries the published event state. In
the response to every successful PUBLISH request, the ESC assigns an
identifier to the publication in the form of an entity-tag. This
identifier is then used by the EPA in any subsequent PUBLISH request
that modifies, refreshes or removes the event state of that
publication. When event state expires or is explicitly removed, the
entity-tag associated with it becomes invalid. A

Niemi Expires July 5, 2004 [Page 5]

Internet-Draft SIP Event State Publication January 2004 publication for an
invalid entity-tag will naturally fail, and the EPA needs to start
anew and resend its event state without the
entity-tag reference. referencing a previous
entity-tag.

4. Considerations for Event Packages using Constructing PUBLISH

This section discusses several issues which should be taken into
consideration when applying the Requests

PUBLISH mechanism to requests create, modify, and remove event packages.
It state associated
with an address-of-record. A suitably authorized third party may also demonstrates how these issues are handled when using PUBLISH
for presence publication.

Any future event package specification SHOULD include a discussion
perform publication on behalf of
its considerations for using PUBLISH. At a minimum those
considerations SHOULD address particular address-of-record.

Except as noted, the issues presented in this chapter,
and MAY include additional considerations.

4.1 PUBLISH Bodies

The body construction of the PUBLISH request typically carries and the published event
state. Any application
behavior of the PUBLISH mechanism for clients sending a given event
package MUST define what content type or types are expected in PUBLISH requests. Each event package MUST also describe request are identical to the semantics
associated with that content type,
general UAC behavior described in Section 8.1 and MUST prescribe a default,
mandatory to implement MIME type.

This document defines the semantics Section 17.1 of RFC
3261 [4].

If necessary, clients may probe for the presence publication
requests (event package "presence") when the CPIM PIDF [9] presence
document format is used. A PUA that uses PUBLISH to publish presence
state to the PA MUST support the CPIM PIDF presence format. It MAY support other formats.

4.2 of PUBLISH Response Bodies using the
OPTIONS request defined in SIP [4]. The presence of "PUBLISH" in the
"Allow" header field in a response to a PUBLISH an OPTIONS request indicates whether
support for the request was
successful or not. PUBLISH method. In general, addition, the body of such a response will be
empty unless "Allow-Events"
header field indicates the supported event package defines explicit meaning for such a
body.

There packages.

Note that it is no such meaning possible for the body of OPTIONS request to fork, and
consequently return a response to from a presence
publication when UA other than the document format used is CPIM PIDF.

4.3 Multple Sources ESC. In
that case, support for Event State

For some event packages, the underlying model is PUBLISH method may not be appropriately
represented for that of particular Request-URI.

A PUBLISH request does not establish a single
aggregator 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 event state (ESC), RFC 3261 [4]. The Record-Route
header field has no meaning in PUBLISH requests or responses, and multiple sources, out of which
only some may
MUST be using ignored if present. In particular, the PUBLISH mechanism.

Niemi Expires July 5, 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 MAY contain a Contact header field, but including
one in a PUBLISH request has no meaning in the event publication
context and will be ignored by the ESC. An EPA MAY send a PUBLISH
request within an existing dialog. In that case, the request is

Niemi Expires August 13, 2004 [Page 6]

Internet-Draft SIP Event State Publication January February 2004

received in the context of any media session or sessions associated
with that dialog.

Note that sources for event state other than those using the while sending a PUBLISH mechanism are explicitly allowed. However, it request within an existing
dialog is beyond not prohibited, it will typically not result in the scope of this document to define such interfaces.

Event packages that make use
expected behavior. Unless the other end of the PUBLISH mechanism SHOULD describe
whether this model for event state publication dialog is applicable, and MAY
describe specific mechanisms used for aggregating publications from
multiple sources.

For presence, also an
ESC, it will probably reject the request.

EPAs MUST NOT send a PUA can publish presence state for just new PUBLISH request (not a subset of
the tuples that may be composed into re-transmission) for
the presence document that
watchers receive in same Request-URI, until they have received a NOTIFY. The mechanism by which final response from
the ESC
aggregates this information is a matter of local policy and out of for the scope previous one or the previous PUBLISH request has
timed out.

4.1 Identification of this specification.

4.4 Published Event State Segmentation

For some event packages, there exists a natural decomposition

Identification of published event state into segments. Each segment is defined as one provided by three pieces
of
potentially many identifiable sections information: Request-URI, event type, and (optionally) an
entity-tag.

The Request-URI of a PUBLISH request contains enough information to
route the request to the appropriate entity per the request routing
procedures outlined in RFC3261 [4]. It also contains enough
information to identify the resource whose event state is to be
published, but not enough information to determine the type of the
published event state.
Any event package whose content

For determining the type supports such segmentation of the published event state, SHOULD describe the way EPA MUST
include a single Event header field in PUBLISH requests. The value of
this header field indicates the event package for which these this request
is publishing event state
segments are identified by the ESC.

In presence publication, the EPA MUST keep state.

For each successful PUBLISH request, the "id" attributes of
tuples consistent ESC will generate and assign
an entity-tag and return it in the context SIP-ETag header field of an entity-tag. If a publication
modifies the contents of 2xx
response.

When updating previously published event state, PUBLISH requests MUST
contain a tuple, single SIP-If-Match header field identifying the specific
event state that tuple the request is refreshing, modifying or removing.
This header field MUST maintain its
original "id". The contain a single entity-tag that was returned
by the ESC will interpret each tuple in the context SIP-ETag header field of the entity-tag with response to a previous
publication.

The PUBLISH request MAY contain a body, which contains event state
that the request arrived. A tuple whose "id" is
missing compared client wishes to publish. The content format and semantics
are dependent on the original publication will be considered as
being removed. Similarly, a tuple is interpreted as being added if
its "id" attribute is one that the original publication did not
contain.

4.5 Rate of Publication

Controlling the rate of publication is discussed in Section 8.
Individual event packages MAY package identified in turn define recommendations (SHOULD
or MUST strength) on absolute maximum rates at which publications are
allowed to be generated by a single EPA.

There are no rate limiting recommendations for the Event header
field.

The presence publication.

5. Constructing PUBLISH Requests

PUBLISH requests create, modify, and remove event state associated
with an address-of-record. A suitably authorized third party may also
perform publication on behalf of a particular address-of-record. body and the SIP-If-Match header field determine

Niemi Expires July 5, August 13, 2004 [Page 7]

Internet-Draft SIP Event State Publication January February 2004

Except as noted, the construction of

the PUBLISH request and specific operation that the
behavior of clients sending a PUBLISH request are identical to the
general UAC behavior is performing, as described
in Section 8.1 and Section 17.1 of RFC
3261 [2].

If necessary, clients may probe Table 1.

+-----------+-------+---------------+---------------+
| Operation | Body? | SIP-If-Match? | Expires Value |
+-----------+-------+---------------+---------------+
| Initial | yes | no | > 0 |
| Refresh | no | yes | > 0 |
| Modify | yes | yes | > 0 |
| Remove | no | yes | 0 |
+-----------+-------+---------------+---------------+

Table 1: Publication Operations

An 'Initial' publication sets the initial event state for a
particular EPA. A 'Refresh' publication refreshes the support lifetime of PUBLISH using a
previous publication, whereas a 'Modify' publication modifies the
OPTIONS request defined in SIP [2]. The presence of "PUBLISH"
event state of a previous publication. A 'Remove' publication
requests immediate removal of event state. These operations are
described in the
"Allow" header field more detail in the following sections.

4.2 Creating Initial Publication

An initial publication is a response to an OPTIONS PUBLISH request indicates
support created by the EPA and
sent to the ESC that establishes soft state for the PUBLISH method. In addition, event package
indicated in the "Allow-Events" Event header field indicates the supported event packages.

Note that it is possible for of the OPTIONS request to fork, request, and
consequently return a response from a UA other than bound to the ESC. In
that case, support for
address in the PUBLISH method may not be appropriately
represented for that particular Request-URI.

A Request-URI of the request.

An initial PUBLISH request does not establish a dialog. A UAC MAY include MUST NOT contain a
Route SIP-If-Match header field in a PUBLISH request based on a pre-existing route
set
field. However, if the EPA expects an appropriate, locally stored
entity-tag to still be valid, it SHOULD first try to modify that
event state as described in Section 8.1 4.4, instead of RFC 3261 [2]. The Record-Route
header field has no meaning in submitting an
initial publication.

An initial PUBLISH requests or responses, and
MUST be ignored if present. In particular, the UAC request MUST NOT create contain a
new route set based on body that contains the presence or absence of a Record-Route
header field in any response to a PUBLISH request.

The
published event state.

An initial PUBLISH request MAY contain a Contact single Expires header field, but including
one in a PUBLISH request has no meaning in field.
This value indicates the event publication
context and will be ignored by suggested lifetime of the ESC. An EPA MAY send a PUBLISH
request within event state
publication.

If an existing dialog. In that case, the request Expires header is
received in not present, the context of any media session or sessions associated
with that dialog.

Note that while sending a PUBLISH request within an existing
dialog EPA is not prohibited, it will typically not result in indicating its desire
for the
expected behavior. Unless ESC to choose. The ESC may lower the other end suggested lifetime of
the dialog is also an
ESC, publication, but it will probably reject the request.

EPAs MUST NOT send a new PUBLISH request (not a re-transmission) for
the same Request-URI, until they have received never extend it. The Expires header
field in a final 2xx response from to the ESC for initial PUBLISH indicates the previous one or actual
duration for which the previous PUBLISH request has
timed out.

5.1 Identification of Published Event State

Identification of published event state publication will remain active. Unless
refreshed before this lifetime is provided by four pieces of
information: Request-URI, event type, and (optionally) an entity-tag
and exceeded, the message body.

The Request-URI of a PUBLISH request contains enough information to publication will
expire.

Niemi Expires July 5, August 13, 2004 [Page 8]

Internet-Draft SIP Event State Publication January February 2004

route the request to the appropriate entity per

4.3 Refreshing Event State

An EPA is responsible for refreshing its previously established
publications before their expiration interval has elapsed. To refresh
a publication, the EPA MUST create a PUBLISH request routing
procedures outlined that includes in RFC3261 [2]. It also contains enough
information to identify
a SIP-If-Match header field the resource whose event state is entity-tag of the publication to be
published, but not enough information to determine
refreshed.

The SIP-If-Match header field containing an entity-tag conditions the type of
PUBLISH request to refresh a specific event state established by a
prior publication. If the entity-tag matches previously published
event state.

For determining state at the type of ESC, the published event state, refresh succeeds, and the EPA MUST
include receives a single Event header field in the PUBLISH requests. The
value of this header field indicates
2xx response.

Like the event package, for which
this request is publishing event state.

For each successful 2xx response to an initial PUBLISH request, the ESC 2xx
response to a refresh PUBLISH request will generate and assign contain a SIP-ETag
header field with an entity-tag. There is no requirement that this
entity-tag and return it is the same one as was given in the SIP-ETag SIP-If-Match header
field of the 200
(OK) response.

When updating previously published request.

If there is no matching event state, PUBLISH requests MUST
contain a single SIP-If-Match header field identifying e.g., the specific event state that to be
refreshed has already expired, the request is refreshing, modifying or removing.
This header field MUST contain EPA receives a single entity-tag that was returned
by the ESC in the SIP-ETag header field of the 412 (Precondition
Failed) response to a previous
publication.

The the PUBLISH request request.

A publication refresh 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 single Expires header field.

The presence This
value indicates the suggested lifetime of a body and the SIP-If-Match event state.

If an Expires header field determine
the specific operation that is not present, the request EPA is performing, as described
in Table 1. These operations are described in more detail in indicating its desire
for the
following sections.

+-----------+-------+---------------+
| Operation | Body? | SIP-If-Match? |
+-----------+-------+---------------+
| Initial | yes | no |
| Refresh | no | yes |
| Modify | yes | yes |
| Remove | no | yes |
+-----------+-------+---------------+

Table 1: Publication Operations

As with any other SIP message, ESC to choose. The ESC may lower the PUBLISH mechanism MAY use suggested lifetime of
the
content indirection mechanism defined publication refresh, but it will never extend it. The Expires
header field in [10]. There are no
additional requirements or restrictions on content indirection as
applied a 2xx response to the PUBLISH request. Content indirection is a useful
mechanism publication refresh indicates
the actual duration for communicating large which the publication will remain active.

A publication refresh only extends the expiration time of already
existing event state. It does not affect that event state information in any
other way. Therefore, a PUBLISH request that cannot

Niemi Expires July 5, 2004 [Page 9]

Internet-Draft SIP refreshes event state
MUST NOT have a body.

4.4 Modifying Event State Publication January 2004

reasonably be carried directly within

Modifying event state closely resembles the SIP signaling (PUBLISH
request).

5.2 Creating Initial Publication

An creation of initial publication is a PUBLISH request created by the EPA and
sent to the ESC that establishes soft event
state. However, instead of establishing completely new event state for at
the ESC, already existing event package
indicated in state is updated with modified event
state. The nature of this update depends on the Event header field content of the request, body,
and bound to the
address in semantics associated with the Request-URI format of that body.

To modify event state, the request.

An initial EPA MUST construct a PUBLISH request MUST NOT contain that
includes in a SIP-If-Match header
field. However, if field the EPA expects an appropriate, locally stored entity-tag of the event

Niemi Expires August 13, 2004 [Page 9]

Internet-Draft SIP Event State Publication February 2004

state publication to still be valid, it SHOULD first try to modify modified. A PUBLISH request that modifies
event state as described in Section 5.5, instead of submitting an
initial publication. MUST contain a body that includes the modified event
state.

The EPA MAY send subsequent SIP-If-Match header field conditions the PUBLISH requests request to refresh, modify, or
remove the
modify a specific event state established by a prior publication publication, and
identified by the associated entity-tag. These operations If the entity-tag matches previously
published event state at the ESC, that event state is replaced by the
event state carried in the PUBLISH request, and the EPA receives a
2xx response.

Like the 2xx response to an initial PUBLISH request, the 2xx
response to a modifying PUBLISH request will be
described contain a SIP-ETag
header field with an entity-tag. There is no requirement that this
entity-tag is the same one as was given in the following sections.

5.3 Setting SIP-If-Match header
field of the request.

If there is no matching event state at the ESC, e.g., the event state
to be modified has already expired, the EPA receives a 412
(Precondition Failed) response to the Expiration Interval PUBLISH requests SHOULD request.

A modifying PUBLISH request MAY contain a single Expires header
field. This value indicates the suggested lifetime of the event state
publication. The actual validity period of the soft state is defined
by local policy at the ESC, although typically the event state is
cleared immediately after the publication expires.

Some implementations might maintain event state over a short grace
period even after the publication on which it arrived has expired.

If an Expires header is not present, the EPA is indicating its desire
for the ESC to choose. The Expires header field in a 200 (OK)
response ESC may lower the suggested lifetime of
the publication, but it will never extend it. The Expires header
field in a 2xx response to the modifying PUBLISH indicates the actual
duration for which the publication will remain active. Unless refreshed,
refreshed before this lifetime is exceeded, the publication will
expire.

5.4 Refreshing

4.5 Removing Event State

An EPA is responsible for refreshing its previously

Event state established
publications before their expiration interval has elapsed. To refresh by a publication, prior publication may also be explicitly
removed.

To request the immediate removal of event state, an EPA MUST create a
PUBLISH request that includes in
a with an Expires value of "0", and set the
SIP-If-Match header field to contain the entity-tag of the event
state publication to be
refreshed. An EPA can influence the expiration interval selected by
the ESC as described in Section 5.3.

The SIP-If-Match header field containing removed.

Note that removing event state is effectively a publication
refresh suggesting an entity-tag conditions infinitesimal expiration interval.
Consequently, the refreshed event state expires immediately after
being refreshed.

Niemi Expires July 5, August 13, 2004 [Page 10]

Internet-Draft SIP Event State Publication January February 2004

PUBLISH request

Similar to refresh a specific an event state established by a
prior publication. If refresh, the entity-tag matches previously published removal of event state at the ESC, only
affects the refresh succeeds, and expiry of the EPA receives event state. Therefore, a
200 (OK) response.

Note PUBLISH request
that like any other 200 (OK) response to a PUBLISH, also this
response will removes event state MUST NOT contain a SIP-ETag header field with an entity-tag.
There is no requirement that this entity-tag is body.

5. Processing PUBLISH Responses

When processing responses to PUBLISH requests, the same one as
was given steps in the SIP-If-Match header field Section
8.1.2 of the request. RFC 3261 [4] apply.

If there is no matching event state, e.g., the event state to be
refreshed has already expired, the an EPA receives a 412 (Precondition Failed) response to the PUBLISH request.

A publication refresh only extends the expiration time of already
existing event state. It does not affect that event state in any
other way. Therefore, a PUBLISH request that refreshes event state response, it MUST NOT have a body.

5.5 Modifying Event State

Modifying event state closely resembles the creation of initial event
state. However, instead of establishing completely new event state at
reattempt the ESC, already existing event state is replaced with modified event
state.

To modify PUBLISH request. Instead, to publish event state, the
EPA MUST construct SHOULD perform an initial publication, i.e., a PUBLISH request that
includes in
without a SIP-If-Match header field field, as described in Section 4.2. The
EPA MUST also discard the entity-tag of that produced this error
resoponse.

If an EPA receives a 423 (Interval Too Brief) response to a PUBLISH
request, it MAY retry the event
state publication to be modified. Typically, after changing the modified event state
is carried expiration
interval in the body of Expires header field to be equal to or greater than
the PUBLISH request.

The SIP-If-Match expiration interval within the Min-Expires header field conditions of the
423 (Interval Too Brief) response.

6. Processing PUBLISH request Requests

The Event State Compositor (ESC) is a UAS that processes and responds
to
modify PUBLISH requests, and maintains a specific event state established by list of publications for a prior publication, and
identified by the entity-tag. If given
address-of-record. The ESC has to know (e.g., through configuration)
the entity-tag matches previously
published set of addresses for which it maintains event state at state.

The ESC MUST ignore the ESC, that event state Record-Route header field if it is replaced by the
event state carried included
in the PUBLISH request, and the EPA receives a
200 (OK) response.

Note that like PUBLISH request. The ESC MUST NOT include a Record-Route header
field in any other 200 (OK) response to a PUBLISH, also this
response will contain a SIP-ETag PUBLISH request. The ESC MUST ignore the
Contact header field with an entity-tag.
There is no requirement that this entity-tag if one is present in a PUBLISH request.

PUBLISH requests with the same one as
was given Request-URI MUST be processed in the SIP-If-Match header field of the request.

If there
order that they are received. PUBLISH requests MUST also be processed
atomically, meaning that a particular PUBLISH request is no matching event state either
processed completely or not at all.

When receiving a PUBLISH request, the ESC, e.g., ESC follows the event state steps defining
general UAS behavior in Section 8.2 of RFC 3261 [4]. In addition, for
PUBLISH specific behavior the ESC follows these steps:

1. The ESC inspects the Request-URI to be modified has already expired, determine whether this
request is targeted to a resource for which the EPA receives ESC is
responsible for maintaining event state. If not, the ESC MUST
return a 412
(Precondition Failed) 404 (Not Found) response to and skip the PUBLISH request. remaining steps.

Niemi Expires July 5, August 13, 2004 [Page 11]

Internet-Draft SIP Event State Publication January February 2004

5.6 Removing Event State

Event state established by a prior publication

It may also be explicitly
removed.

To request that the immediate removal of event state, an EPA MUST create Request-URI points to a
PUBLISH domain that
the ESC is not responsible for. In that case, the UAS
receiving the request with an Expires value can assume the role of "0", a proxy server
and set forward the
SIP-If-Match header field request to contain a more appropriate target.

2. The ESC examines the entity-tag Event header field of the event
state publication to be removed.

Note that removing event state is effectively a publication
refresh suggesting an infinitesimal expiration interval.
Consequently, PUBLISH request.
If the refreshed event state expires immediately after
being refreshed.

Similar to Event header field is missing or contains an event state refresh, package
which the removal of event state only
affects ESC does not support, the expiry of ESC MUST respond to the event state. Therefore, a
PUBLISH request
that removes event state MUST NOT contain with a body.

5.7 Querying the Current Event State

To query the composite event state that the state agent in fact
delivers to 489 (Bad Event) response, and skip the subscribers,
remaining steps.

3. The ESC examines the client may SUBSCRIBE to SIP-If-Match header field of the event
package and Request-URI for which it has sent a PUBLISH request. An
Expires header value
request for the presence of "0" may be used in this SUBSCRIBE a request to
do precondition.

* If the request does not contain a one-time fetch of this event state as defined in RFC3265 [1].

Note that SIP-If-Match header field,
the ESC MUST generate and store a subscription to locally unique entity-tag
for identifying the event package will likely deliver
results of publication. This entity-tag is associated
with the event composition process of event-state carried in the state agent, which
may be a subset or a superset body of the current published event
state.

5.8 Error Responses

If an EPA receives a 412 (Precondition Failed) response, it MUST NOT
reattempt the PUBLISH
request. Instead, to publish event state,

* Else, if the
EPA SHOULD perform an initial publication, i.e., a PUBLISH request
without has a SIP-If-Match header field, as described in Section 5.2. The
EPA MUST also discard the entity-tag that produced this error
resoponse.

If an EPA receives a 423 (Interval Too Brief) response to ESC
checks whether the header field contains a PUBLISH
request, it MAY retry single entity-tag.
If not, the publication after changing request is invalid, and the expiration
interval ESC MUST return with a
400 (Invalid Request) response and skip the remaining steps.

* Else, the ESC extracts the entity-tag contained in the
SIP-If-Match header field and matches that entity-tag against
all locally stored entity-tags for this resource and event
package. If no match is found, the ESC MUST reject the
publication with a response of 412 (Precondition Failed), and
skip the remaining steps.

4. The ESC processes the Expires header field to value from the PUBLISH
request.

* If the request has an Expires header field, that value MUST be equal to or greater
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. Only if the requested expiration interval within
is greater than zero and less than a locally-configured
minimum, the Min-Expires header field of ESC MAY reject the publication with a response of
423 (Interval Too Brief) response. Brief), and skip the remaining steps. This
response MUST contain a Min-Expires header field that states
the minimum expiration interval the ESC is willing to honor.

Niemi Expires July 5, August 13, 2004 [Page 12]

Internet-Draft SIP Event State Publication January February 2004

6. Processing PUBLISH Requests

The Event State Compositor (ESC) is a UAS that processes and responds
to PUBLISH requests, and maintains a list of publications for a given
address-of-record.

5. The ESC has to know (e.g., through configuration) processes the set of addresses for which it maintains published event state.

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 state contained in any response to a PUBLISH request. The ESC MUST ignore the
Contact header field if one is present in a body
of the PUBLISH request.

PUBLISH requests MUST be processed in If the content type of the order that they are
received. PUBLISH requests MUST also be processed atomically, meaning
that a particular PUBLISH request is either processed completely does
not match the event package, or is not at all.

A client may probe understood by the ESC for ESC, the support of PUBLISH using
ESC MUST reject the
OPTIONS request defined in SIP [2]. In the response to such with an
OPTIONS request, the ESC SHOULD include "PUBLISH" to appropriate response, such as
415 (Unsupported Media Type), and skip the list remainder of
allowed methods in the Allow header field. Also, it SHOULD list
steps.

* If present, the ESC stores the
supported event packages state delivered in an Allow-Events header field.

The "methods" Contact header field parameter may also be used to
specifically announce support for PUBLISH messages when
registering. (See SIP Capabilities [11] for details on the
"methods" parameter).

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

1. The ESC inspects associated entity-tag,
updating any existing event state for that entity-tag.

* Else, the Request-URI to determine whether this
request event state identified by the entity-tag is targeted
refreshed, setting the expiration value to a resource for which the ESC is
responsible for maintaining event state. chosen
expiration interval. If not, the ESC MUST
return chosen expiration interval has a 404 (Not Found) response and skip the remaining steps.

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

3. An ESC SHOULD authenticate the EPA. Mechanisms for the
authentication of SIP user agents are described in Section 22 of
RFC3261 [2]. If no authentication mechanism is available, the ESC
MAY take the address-of-record of the From header field as the
asserted identity of the originator
special value of "0", the request.

4. The ESC SHOULD determine if the authenticated user is authorized
to perform event state publication for the resource identified by the Request-URI. If the authenticated user is not authorized, the

Niemi Expires July 5, 2004 [Page 13]

Internet-Draft SIP Event State Publication January 2004

ESC
entity-tag MUST return a 403 (Forbidden) response and skip the rest of
the remaining steps.

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

5. be immediately removed.

The ESC examines the Event header field processing of the PUBLISH request. request MUST be atomic. If internal
errors (such as the Event header field inability to access a back-end database)
occur before processing is missing or contains an event package
which complete, the ESC does not support, publication MUST NOT
succeed, and the ESC MUST respond to the
PUBLISH request fail with a 489 (Bad Event) an appropriate error
response, such as 504 (Server Time-out), and skip the
remaining steps. last step.

6. The ESC examines the SIP-If-Match returns a 200 (OK) response. The response MUST contain an
Expires header field of the PUBLISH
request for indicating the presence of a request precondition.

* If expiration interval chosen by
the request has ESC. The response MUST also contain a SIP-If-Match header field, the ESC checks
whether the SIP-ETag header field
that contains a single entity-tag. If not,
the request is invalid, and entity-tag identifying the publication.
The ESC MUST return with generate a 400
(Invalid Request) response and skip the remaining steps.

* Else, the ESC extracts the entity-tag contained in the
SIP-If-Match header field and matches that new entity-tag against
all locally stored entity-tags for this resource and each successful
publication, replacing any previous entity-tag associated with
that event
package. If no match is found, state.

7. Processing OPTIONS Requests

A client may probe the ESC MUST reject for the
publication with a response support of 412 (Precondition Failed), and
skip the remaining steps.

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

* If using the
OPTIONS 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.

* defined in SIP [4]. The ESC MAY choose an expiration less than the requested
expiration interval. 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 processes OPTIONS
requests as defined in Section 11.2 of
423 (Interval Too Brief), and skip RFC 3261 [4]. In the remaining steps. This response MUST contain a Min-Expires header field that states
the minimum expiration interval
to an OPTIONS request, the ESC is willing SHOULD include "PUBLISH" to honor.

8. The ESC processes the published event state, typically contained
in the body list
of allowed methods in the PUBLISH request. If the request contains no
body (when Allow header field. Also, it should contain one), or the content type of the
request does not match SHOULD list
the supported event package, or is not understood by packages in an Allow-Events header field.

The Allow header field may also be used to specifically announce
support for PUBLISH messages when registering. (See SIP
Capabilities [11] for details).

Niemi Expires July 5, August 13, 2004 [Page 14] 13]

Internet-Draft SIP Event State Publication January February 2004

the ESC, the ESC MUST reject the request with an appropriate
response, such as 415 (Unsupported Media Type), and skip the
remainder

8. Use of the steps.

* If present, the ESC stores the event state delivered Entity-tags in the PUBLISH request and identified by the associated entity-tag,
replacing any existing event state for that entity-tag.

* Else, the event state identified by the entity-tag is
refreshed, setting the expiration value to the chosen
expiration interval. If the chosen expiration interval has

This section makes a
special value general overview of "0", the event state identified by the
entity-tag MUST be immediately removed. entity-tags usage in
PUBLISH. It is informative in nature and thus contains no normative
protocol description.

8.1 General Notes

The processing of the PUBLISH request MUST be atomic. If internal
errors (such mechanism makes use of entity-tags, as defined in HTTP/
1.1 [12]. While the inability to access a back-end database)
occur before processing main functionality is complete, preserved, the publication MUST NOT
succeed, syntax and the ESC MUST fail with an appropriate error
response, such as 504 (Server Time-out),
semantics for entity-tags and skip the last step.

9. 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 a SIP-ETag corresponding header field fields is
adapted specifically for
which the ESC MUST generate and store a locally unique entity-tag
for identifying the publication. After returning the 200 (OK)
response, 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.

7. Use of Entity-tags in PUBLISH

This section makes a general overview of the entity-tags usage in
PUBLISH. It is informative in nature and thus contains no normative
protocol description.

7.1 General Notes

The PUBLISH mechanism makes use of entity-tags, as defined in HTTP/
1.1 [7]. While the main functionality is preserved, the syntax and
semantics for entity-tags and the corresponding header fields is
adapted specifically for use with use with the PUBLISH method. The main
differences are:

Niemi Expires July 5, 2004 [Page 15]

Internet-Draft SIP Event State Publication January 2004

o The syntax for entity-tags is a token instead of quoted-string.
There is also no prefix defined for indicating a weak entity-tag.

o A PUBLISH precondition can only apply to a single entity-tag, so
request preconditions with multiple entity-tags are not allowed.

o A request precondition can't apply to "any" entity, namely there
is no special "*" entity-tag value defined for PUBLISH.

o Whereas in HTTP/1.1 returning an entity-tag is optional for origin
servers, in PUBLISH ESCs are required to always return an
entity-tag for a successful publication.

The main motivation for the above adaptation is that PUBLISH is
conceptually an HTTP PUT, for which only a subset of the features in
cache validation using entity-tags is allowed in HTTP/1.1. It makes
little sense to enable features other than this subset for event
state publication.

To make it apparent that the entity-tags usage in PUBLISH is similar
but not identical to HTTP/1.1, we have not adopted the header field
names directly from HTTP/1.1, but rather have created similar but
distinct names, as can be seen in Section 9.

7.2 11.

8.2 Client Usage

Each successful publication will get assigned an entity-tag which is
then delivered to the EPA in the response to the PUBLISH request. The
EPA needs to store that entity-tag, which replaces any previous
entity-tag for that event state. If a request fails with a 412
(Precondition Failed) response, the EPA discards the entity-tag that
caused the failure.

Entity-tags are opaque tokens to the EPA. The EPA cannot infer any

Niemi Expires August 13, 2004 [Page 14]

Internet-Draft SIP Event State Publication February 2004

further semantics from an entity-tag beyond a simple identifier, or
assume a specific formatting. An entity-tag may be a monotonically
increasing counter, but it may also be a totally random token. It is
up to the ESC implementation as ESC implementation as to what the formatting of an
entity-tag is.

8.3 Server Usage

Entity-tags are generated and maintained by the ESC. They are part of
the state maintained by the ESC that also includes the actual event
state and its remaining expiration interval. An entity-tag is
generated and stored for each successful event state publication, and
returned to the EPA in a 200 (OK) response. Each event state
publication from the EPA that updates a previous publication will
include an entity-tag that the ESC can use as a search key in the set
of active publications.

The way in which an entity-tag is generated is an implementation
decision. One possible way to generate an entity-tag is to implement
it as an integer counter that is incremented by one for each
successfully processed publication. Other, equally valid ways for
generating entity-tags exist, and this document makes no
recommendations or preference for a single way.

9. Controlling the Rate of Publication

As the aggregator of state information from potentially many sources,
the ESC can be subject to considerable amounts of publication
traffic. There are ways to reduce the amount of PUBLISH requests that
the ESC receives:

o Choice of the expiration interval for a publication can be
affected by the ESC. It can insist that an EPA chooses a longer
expiration value to what it suggests, in case the ESC's local
default minimum expiration value is not reached. Maintaining a
longer default minimum expiration value at the ESC reduces the
rate at which publications are refreshed.

o Another way of reducing publication traffic is to use a SIP-level
push-back to quench a specific source of publication traffic. To
push back on publications from a particular source, the ESC MAY
respond to a PUBLISH request with a 503 (Service Unavailable), as
defined in RFC3261 [4]. This response SHOULD contain a Retry-After
header field indicating the time interval that the publication
source is required to wait until sending another PUBLISH request.

At the time of writing this specification, work on managing load in
SIP is starting, which may be able to provide further tools for

Niemi Expires August 13, 2004 [Page 15]

Internet-Draft SIP Event State Publication February 2004

managing load in event state publication systems.

10. Considerations for Event Packages using PUBLISH

This section discusses several issues which should be taken into
consideration when applying the PUBLISH mechanism to event packages.
It also demonstrates how these issues are handled when using PUBLISH
for presence publication.

Any future event package specification SHOULD include a discussion of
its considerations for using PUBLISH. At a minimum those
considerations SHOULD address the issues presented in this chapter,
and MAY include additional considerations.

10.1 PUBLISH Bodies

The body of the PUBLISH request typically carries the published event
state. Any application of the PUBLISH mechanism for a given event
package MUST define what content type or types are expected in
PUBLISH requests. Each event package MUST also describe the semantics
associated with that content type, and MUST prescribe a default,
mandatory to implement MIME type.

This document defines the semantics of the presence publication
requests (event package "presence") when the CPIM PIDF [6] presence
document format is used. A PUA that uses PUBLISH to publish presence
state to the PA MUST support the CPIM PIDF presence format. It MAY
support other formats.

10.2 PUBLISH Response Bodies

The response to a PUBLISH request indicates whether the request was
successful or not. In general, the body of such a response will be
empty unless the event package defines explicit meaning for such a
body.

There is no such meaning for the body of a response to what a presence
publication.

10.3 Multiple Sources for Event State

For some event packages, the formatting underlying model is that of an
entity-tag is.

7.3 Server Usage

Entity-tags are generated and maintained by the ESC. They are part a single
aggregator of
the state maintained by the ESC that also includes the actual event state (ESC), and its remaining expiration interval. An entity-tag is
generated and stored multiple sources, out of which
only some may be using the PUBLISH mechanism.

Note that sources for each successful event state publication, and
returned to other than those using the EPA in a 200 (OK) response. Each event state
publication from
PUBLISH mechanism are explicitly allowed. However, it is beyond
the EPA that updates a previous publication will scope of this document to define such interfaces.

Niemi Expires July 5, August 13, 2004 [Page 16]

Internet-Draft SIP Event State Publication January February 2004

include an entity-tag

Event packages that the ESC can make use as a search key in the set of active publications.

The way in which an entity-tag is generated is an implementation
decision. One possible way to generate an entity-tag is to implement
it as an integer counter that the PUBLISH mechanism SHOULD describe
whether this model for event state publication is incremented by one applicable, and MAY
describe specific mechanisms used for each
successfully processed publication. Other, equally valid ways aggregating publications from
multiple sources.

For presence, a PUA can publish presence state for
generating entity-tags exist, and this just a subset of
the tuples that may be composited into the presence document makes no
recommendations or preference for that
watchers receive in a single way.

8. Controlling NOTIFY. The mechanism by which the Rate ESC
aggregates this information is a matter of local policy and out of Publication

As
the aggregator scope of this specification.

10.4 Event State Segmentation

For some event packages, there exists a natural decomposition of
event state information from into segments. Each segment is defined as one of
potentially many sources, identifiable sections in the ESC can be subject to considerable amount published event state.
Any event package whose content type supports such segmentation of publication traffic.
There
event state, SHOULD describe the way in which these event state
segments are ways to reduce identified by the amount of PUBLISH requests that ESC.

In presence publication, the ESC
receives:

o As already explained EPA MUST keep the "id" attributes of
tuples consistent in Section 5.3, choosing the expiration
interval for context of an entity-tag. If a publication is ultimately the ESC's responsibility,
and choosing longer expiration values reduces
modifies the rate at which
publications are refreshed.

o Another way contents of reducing publication traffic is to use a SIP-level
push-back to quench a specific source tuple, that tuple MUST maintain its
original "id". The ESC will interpret each tuple in the context of publication traffic. To
push back on publications from a particular source,
the ESC MAY
respond to a PUBLISH request entity-tag with a 503 (Service Unavailable), which the request arrived. A tuple whose "id" is
missing compared to the original publication will be considered as
defined in RFC3261 [2]. This response SHOULD contain
being removed. Similarly, a Retry-After
header field indicating the time interval tuple is interpreted as being added if
its "id" attribute is one that the original publication
source is required to wait until sending another PUBLISH request.

At did not
contain.

10.5 Rate of Publication

Controlling the time rate of writing this specification, work on managing load in
SIP publication is starting, discussed in Section 9.
Individual event packages MAY in turn define recommendations (SHOULD
or MUST strength) on absolute maximum rates at which may be able publications are
allowed to provide further tools be generated by a single EPA.

There are no rate limiting recommendations for
managing load in event state publication systems.

9. Syntax presence publication.

11. Protocol Element Definitions

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

9.1

11.1 New Methods

9.1.1

Niemi Expires August 13, 2004 [Page 17]

Internet-Draft SIP Event State Publication February 2004

11.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

Niemi Expires July 5, 2004 [Page 17]

Internet-Draft SIP Event State Publication January 2004
entity responsible for compositing this event state.

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

Niemi Expires July 5, August 13, 2004 [Page 18]

Internet-Draft SIP Event State Publication January February 2004

+---------------------+---------+---------+
| Header Field | where | PUBLISH |
+---------------------+---------+---------+
| Accept | R | o |
| Accept | 2xx | - |
| Accept | 415 | m* |
| Accept-Encoding | R | o |
| Accept-Encoding | 2xx | - |
| Accept-Encoding | 415 | m* |
| Accept-Language | R | o |
| Accept-Language | 2xx | - |
| Accept-Language | 415 | m* |
| Alert-Info | | - |
| Allow | R | o |
| Allow | 2xx | o |
| Allow | r | o |
| Allow | 405 | m |
| Allow-Events | R | o |
| Allow-Events | 489 | m |
| Authentication-Info | 2xx | o |
| Authorization | R | o |
| Call-ID | c | m |
| Call-Info | | o |
| Contact | R | - |
| Contact | 1xx | - |
| Contact | 2xx | - |
| Contact | 3xx | o |
| Contact | 485 | o |
| Content-Disposition | | o |
| Content-Encoding | | o |
| Content-Language | | o |
| Content-Length | | t |
| Content-Type | | * |
| CSeq | c | m |
| Date | | o |
| Event | R | m |
| Error-Info | 300-699 | o |
| Expires | | o |
| Expires | 2xx | m |
| From | c | m |
| In-Reply-To | R | - |
| Max-Forwards | R | m |
| Min-Expires | 423 | m |
| MIME-Version | | o |
| Organization | | o |
+---------------------+---------+---------+

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

Niemi Expires July 5, August 13, 2004 [Page 19]

Internet-Draft SIP Event State Publication January February 2004

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

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

9.2

11.2 New Response Codes

9.2.1

11.2.1 "412 Precondition Failed" Response Code

The 412 (Precondition Failed) response is added to the "Client-Error"
header field definition. 412 (Precondition Failed) is used to
indicate that the precondition given for the request has failed.

9.3

11.3 New Header Fields

Table 4 4, Table 5, and Table 5 6 expand on Table 3 in SIP [2], [4], as
amended by the changes in Section 9.1. 11.1.

Niemi Expires July 5, August 13, 2004 [Page 20]

Internet-Draft SIP Event State Publication January February 2004

+--------------+-------+-------+-----+-----+-----+

+--------------+-------+-------+-----+-----+-----+-----+-----+
| Header Field | where | proxy | ACK | BYE | CAN |
+--------------+-------+-------+-----+-----+-----+ INF | INV |
+--------------+-------+-------+-----+-----+-----+-----+-----+
| SIP-ETag | 2xx | | - | - | - | - | - |
| SIP-If-Match | R | | - | - | - |
+--------------+-------+-------+-----+-----+-----+ - | - |
+--------------+-------+-------+-----+-----+-----+-----+-----+

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

+--------------+-------+-------+-----+-----+-----+---------+

+--------------+-------+-------+-----+-----+-----+-----+-----+
| Header Field | where | proxy | INV NOT | OPT | PRA | REG | PUBLISH SUB |
+--------------+-------+-------+-----+-----+-----+-----+-----+
| SIP-ETag | 2xx | | - | - | - | - | - |
| SIP-If-Match | R | | - | - | - | - | - |
+--------------+-------+-------+-----+-----+-----+-----+-----+

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

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

Table 5: 6: Summary of header fields, P--Z

9.3.1

11.3.1 "SIP-ETag" Header Field

SIP-ETag is added to the definition of the element "general-header"
in the SIP message grammar. Usage of this header is described in
Section 5 4 and Section 6.

9.3.2

11.3.2 "SIP-If-Match" Header Field

SIP-If-Match is added to the definition of the element
"general-header" in the SIP message grammar. Usage of this header is
described in Section 5 4 and Section 6.

9.4

12. Augmented BNF Definitions

This section describes the Augmented BNF definitions for the various
new and modified syntax elements. extensions required for event
publication in SIP. The notation is as formal syntax definitions described in this
section are expressed in the Augmented BNF [7] format used in SIP [2]
[4], and the documents contain references to which it refers. elements defined therein.

Niemi Expires August 13, 2004 [Page 21]

Internet-Draft SIP Event State Publication February 2004

PUBLISHm = %x50.55.42.4C.49.53.48 ; PUBLISH in caps.
extension-method = PUBLISHm / token
SIP-ETag = "SIP-ETag" HCOLON entity-tag
SIP-If-Match = "SIP-If-Match" HCOLON entity-tag
entity-tag = token

10.

13. IANA Considerations

This document registers a new method name, a new response code and

Niemi Expires July 5, 2004 [Page 21]

Internet-Draft SIP Event State Publication January 2004
two new header field names.

10.1

13.1 Methods

This document registers a new SIP method, defined by the following
information, which is to be added to the method and response-code
sub-registry under http://www.iana.org/assignments/sip-parameters.

Method Name: PUBLISH
Reference: [RFCYYYY]

(Note to RFC Editor: Replace YYYY with the RFC number of this
document when published).

10.2

13.2 Response Codes

This document registers a new response code. This response code is
defined by the following information, which is to be added to the
method and response-code sub-registry under http://www.iana.org/
assignments/sip-parameters.

Response Code Number: 412
Default Reason Phrase: Precondition Failed

10.3

13.3 Header Field Names

This document registers two new SIP header field names. These headers
are defined by the following information, which is to be added to the
header sub-registry under http://www.iana.org/assignments/
sip-parameters.

Header Name: SIP-ETag
Compact Form: (none)

Header Name: SIP-If-Match

Niemi Expires August 13, 2004 [Page 22]

Internet-Draft SIP Event State Publication February 2004

Compact Form: (none)

11.

14. Security Considerations

11.1

14.1 Access Control

Since event state may be considered sensitive information, the ESC
should have the ability to selectively accept publications from
authorized sources only, based on the identity of the EPA.

Niemi Expires July 5, 2004 [Page 22]

Internet-Draft SIP Event State Publication January 2004

The state agent SHOULD authenticate the EPA, and SHOULD apply its
authorization policies (e.g., based on access control lists) to all
requests. The composition model makes no assumptions that all input
sources for an ESC are on the same network, or in the same
administrative domain.

Authentication issues are discussed

ESCs and EPAs MUST implement Digest for authenticating PUBLISH
requests, as defined in SIP [2]. RFC 3261 [4]. The exact methods for
creation creating
and manipulation of manipulating access control policies in the ESC authorization policies are outside the
scope of this document.

11.2

14.2 Denial of Service Attacks

The creation of state at the ESC upon receipt of a PUBLISH request
can be used by attackers to consume resources on a victim's machine,
possibly rendering it unusable.

To reduce the chances of such an attack, implementations of ESCs
SHOULD require authentication of PUBLISH requests. Authentication
issues are discussed Implementations
MUST support Digest authentication, as defined in SIP [2]. RFC 3261 [4].

Also, the ESC SHOULD throttle incoming publications and the
corresponding notifications resulting from the changes in event
state. As a first step, careful selection of default minimum Expires
header field values for the supported event packages at an ESC can
help limit refreshes of event state.

Additional throttling and debounce logic at the ESC is advisable to
further reduce the notification traffic produced as a result of a
PUBLISH request.

11.3

14.3 Replay Attack

Replaying a PUBLISH request can have detrimental effects. An attacker
may be able to perform any event state publication it witnessed being
performed at some point in the past, by replaying that PUBLISH
request. Among other things, such a replay message may be used to

Niemi Expires August 13, 2004 [Page 23]

Internet-Draft SIP Event State Publication February 2004

spoof old event state information, although a versioning mechanism,
e.g., a timestamp, in the state information may help mitigate such an
attack.

To prevent replay attacks, implementations SHOULD require MUST support Digest
authentication with anti-replay protection. Authentication issues replay protection, as defined in RFC 3261 [4].
Further mechanisms for countering replay attacks are discussed in SIP [2].

11.4
[4].

14.4 Man in the Middle Attacks

Even with authentication, man-in-the-middle attacks using PUBLISH may
be used to install arbitrary event state information, modify or

Niemi Expires July 5, 2004 [Page 23]

Internet-Draft SIP Event State Publication January 2004
remove existing event state information in publications, or even
remove event state altogether at an ESC.

To prevent such attacks, implementations SHOULD, at a minimum,
provide integrity protection across the To, From, Event,
SIP-If-Match, Route, and Expires headers and the bodies of PUBLISH
requests.

If the ESC receives event state in a PUBLISH request which is
integrity protected using a security association that is not with the
ESC (e.g., integrity protection is applied end-to-end, from publisher
to subscriber), the state agent coupled with the ESC MUST NOT modify
the event state before exposing it to the subscribers of this event
state in NOTIFY requests. This is to preserve the end-to-end
integrity of the event state.

Integrity protection

For integrity protection, ESCs MUST implement TLS [8], and MUST
support both mutual and one-way authentication, and MUST also support
the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of message headers
initiating TLS and bodies is discussed SHOULD support the SIPS URI scheme. ESCs and EPAs
MAY support S/MIME [9] for integrity protection, as defined in SIP [2].

11.5
[4].

14.5 Confidentiality

The state information contained in a PUBLISH message may potentially
contain sensitive information. Implementations MAY encrypt such
information to ensure confidentiality.

The mechanisms for

For providing confidentiality are detailed confidentiality, ESCs MUST implement TLS [8], MUST
support both mutual and one-way authentication, and MUST also support
the SIPS URI scheme defined in SIP [2].

12. [4]. EPAs SHOULD be capable of
initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs
MAY support S/MIME [9] for encryption of event state information, as
defined in SIP [4].

Niemi Expires August 13, 2004 [Page 24]

Internet-Draft SIP Event State Publication February 2004

15. Examples

This 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. The PUA may also 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, and is not shown in this
example.

Niemi Expires July 5, 2004 [Page 24]

Internet-Draft SIP Event State Publication January 2004

PUA PA WATCHER
(EPA) (ESC)
| | |
| | <---- M1: SUBSCRIBE --- |
| | |
| | ----- M2: 200 OK -----> |
| | |
| | ----- M3: NOTIFY -----> |
| | |
| | <---- M4: 200 OK ------ |
| | |
| | |
| ---- M5: PUBLISH ---> | |
| | |
| <--- M6: 200 OK ---- | |
| | |
| | ----- M7: NOTIFY -----> |
| | |
| | <---- M8: 200 OK ------ |
| | |
| ---- M9: PUBLISH ---> | |
| | |
| <--- M10: 200 OK --- | |
| | |
| | |
| --- M11: PUBLISH ---> | |
| | |
| <-- M12: 200 OK ---- | |
| | |
| | ----- M13: NOTIFY ----> |
| | |
| | <---- M14: 200 OK ----- |
| | |

Message flow:

Niemi Expires August 13, 2004 [Page 25]

Internet-Draft SIP Event State Publication February 2004

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

Niemi Expires July 5, 2004 [Page 25]

Internet-Draft SIP Event State Publication January 2004

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

M2: The presence agent for presentity@example.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 host.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
To: <sip:presentity@example.com>;tag=abcd1234
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@10.0.0.1 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Contact: <sip:pa@example.com> sip:pa.example.com
Expires: 3600
Content-Length: 0

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

Niemi Expires July 5, August 13, 2004 [Page 26]

Internet-Draft SIP Event State Publication January February 2004

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

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:presentity@example.com">
<tuple id="mobile-phone">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T16:49:29Z</timestamp>
</tuple>
<tuple id="gwewg991">
<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.example.com;branch=z9hG4bK8sdf2
;received=192.0.2.2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@10.0.0.1 12345678@host.example.com
CSeq: 1 NOTIFY
Contact: <sip:watcher@example.com>

M5: A presence user agent for the presentity initiates a PUBLISH to
the presentity's presence agent in order to update it with new
presence information. The Expires header indicates the desired
duration of this soft state.

Niemi Expires July 5, August 13, 2004 [Page 27]

Internet-Draft SIP Event State Publication January February 2004

PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: ...

M6: 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. The 200 (OK) response contains an
SIP-ETag header field with an entity-tag. This is used to identify
the published event state in subsequent PUBLISH requests.

SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=1a2b3c4d
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: dx200xyz
Expires: 1800

M7: 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 July 5, August 13, 2004 [Page 28]

Internet-Draft SIP Event State Publication January February 2004

NOTIFY sip:presentity@example.com sip:user@host.example.com SIP/2.0
Via: SIP/2.0/UDP presence.example.com;branch=z9hG4bK4cd42a pa.example.com;branch=z9hG4bK4cd42a
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@10.0.0.1 12345678@host.example.com
CSeq: 2 NOTIFY
Max-Forwards: 70
Event: presence
Subscription-State: active; expires=3400
Contact: sip:pa.example.com
Content-Type: application/pidf+xml
Content-Length: ...

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

M8: The watcher confirms receipt of the NOTIFY request.

SIP/2.0 200 OK
Via: SIP/2.0/UDP presence.example.com;branch=z9hG4bK4cd42a pa.example.com;branch=z9hG4bK4cd42a
;received=192.0.2.2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@10.0.0.1 12345678@host.example.com
CSeq: 2 NOTIFY
Content-Length: 0

M9: The PUA determines that the event state it previously published
is about to expire, and refreshes that event state.

Niemi Expires July 5, August 13, 2004 [Page 29]

Internet-Draft SIP Event State Publication January February 2004

PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
SIP-If-Match: dx200xyz
Expires: 3600
Event: presence
Content-Length: 0

M10: The presence agent receives, and accepts the publication
refresh. The timers regarding the expiration of the specific event
state identified by the entity-tag are updated. As always, the ESC
returns an entity-tag in the response to a successful PUBLISH.
Note that no actual state change has occured, so the watchers will
receive no NOTIFYs.

SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=2affde434
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: kwj449x
Expires: 1800

M11: The PUA of the presentity detects a change in the user's
presence state. It initiates a PUBLISH request to the presence
agent to modify the published presence information with the recent
change.

Niemi Expires July 5, August 13, 2004 [Page 30]

Internet-Draft SIP Event State Publication January February 2004

PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=54321mm
Call-ID: 5566778@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
SIP-If-Match: kwj449x
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: ...

M12: The presence agent receives, and accepts the publication
modification. The timers regarding the expiration of the specific
event state identified by the entity-tag are updated, and the
published data is incorporated into the presentity's presence
document. Note that the document delivered in this modification
will replace the previous document.

SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=effe22aa
From: <sip:presentity@example.com>;tag=54321mm
Call-ID: 5566778@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: qwi982ks
Expires: 3600

M13: 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 July 5, August 13, 2004 [Page 31]

Internet-Draft SIP Event State Publication January February 2004

NOTIFY sip:presentity@example.com sip:user@host.example.com SIP/2.0
Via: SIP/2.0/UDP presence.example.com;branch=z9hG4bK32defd3 pa.example.com;branch=z9hG4bK32defd3
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@10.0.0.1 12345678@host.example.com
CSeq: 2 NOTIFY
Max-Forwards: 70
Event: presence
Subscription-State: active; expires=3400
Contact: sip:pa.example.com
Content-Type: application/pidf+xml
Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:presentity@example.com">
<tuple id="efeef223">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T19:15:15Z</timestamp>
</tuple>
<tuple id="gwewg991">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T12:21:29Z</timestamp>
</tuple>
</presence>

M14: The watcher confirms receipt of the NOTIFY request.

SIP/2.0 200 OK
Via: SIP/2.0/UDP presence.example.com;branch=z9hG4bK32defd3 pa.example.com;branch=z9hG4bK32defd3
;received=192.0.2.3
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@10.0.0.1 12345678@host.example.com
CSeq: 2 NOTIFY
Content-Length: 0

13.

16. Contributors

The original contributors to this specification are:

Ben Campbell
dynamicsoft

Niemi Expires August 13, 2004 [Page 32]

Internet-Draft SIP Event State Publication February 2004

Sean Olson
Microsoft

Jon Peterson
Neustar, Inc.

Jonathan Rosenberg
dynamicsoft

Brian Stucker
Nortel Networks, Inc.

17. Acknowledgements

The authors would like to thank the SIMPLE Working Group for their
collective effort, and specifically the following people for their
review and support of this work: Henning Schulzrinne, Paul Kyzivat,
Hisham Khartabil, George Foti, Keith Drage, Samir Srivastava, Arun
Kumar, Adam Roach, Pekka Pessi, Kai Wang, Cullen Jennings, Mikko
Lonnfors, Eva-Maria Leppanen, Ernst Horvath, Thanos Diacakis, Oded
Cnaan, Rohan Mahy and Dean Willis.

18. Document Change History

(Note to RFC Editor: please remove this whole section prior to
publication as an RFC.)

18.1 Changes since "draft-ietf-sip-publish-02"

The following changes were made since the last version:

o Changed title to be in line with draft-ietf-sip-guidelines.

o Added RFC 2779 reference, as well as added a reference for
draft-ietf-simple-presence wrt the definition of a PUA.

o Added a definition for presence compositor in the definitions
section.

o Refined definitions of event hard state and event soft state to
disambiguate the meaning from typical use of hard/soft state.

o Moved Section 10 near the end of the document for clarity.

o Added column "Expires Value" in table 1, and a short description
of what each row represents.

Niemi Expires July 5, August 13, 2004 [Page 32] 33]

Internet-Draft SIP Event State Publication January February 2004

Microsoft

Jon Peterson
Neustar, Inc.

Jonathan Rosenberg
dynamicsoft

Brian Stucker
Nortel Networks, Inc.

14. Acknowledgements

The authors would like

o Removed text about content indirection. Its usage with PUBLISH is
no different from any other SIP method, thus explicitly
referencing it is not needed.

o Removed note from expiration handling that suggested an ESC didn't
necessarily need to thank honor expiry times of event states.

o Deleted section on setting the SIMPLE Working Group for their
collective effort, expiration interval, and specifically instead
folded the following people for their
review and support text into each chapter defining a specific operation.

o Removed section on querying event state.

o Moved processing of this work: Henning Schulzrinne, Paul Kyzivat,
Hisham Khartabil, George Foti, Keith Drage, Samir Srivastava, Arun
Kumar, Adam Roach, Pekka Pessi, Kai Wang, Cullen Jennings, Mikko
Lonnfors, Eva-Maria Leppanen, Ernst Horvath, Thanos Diacakis, Oded
Cnaan, Rohan Mahy and Dean Willis.

15. Document Change History

(Note PUBLISH responses to a separate section.

o Removed steps 2, 3, 4 from PUBLISH processing, and instead
references general UAS behavior defined in RFC Editor: please remove this whole section prior 3261.

o Moved OPTIONS processing to
publication as an RFC.)

15.1 a separate section.

o Added all methods to tables 4, 5, and 6 that have made RFC.

o Split syntax definition to a separate section.

o Pruned table 2 and 3.

o Added some normative requirements for implementations wrt
security.

o Cleaned up the message syntax in the examples section.

o Fixed typos and improved wording.

18.2 Changes since "draft-ietf-sip-publish-01"

The following changes were made since the last version:

o Added new chapter discussing entity-tags in general.

o Added new chapter discussing rate control for publications,
including SIP level push-back.

o Added back a considerations section for event segmentation (in
Chapter 4), and clarified text in other parts.

o Clarified text on constructing a PUBLISH. Added a table describing
the operations and their properties.

Niemi Expires August 13, 2004 [Page 34]

Internet-Draft SIP Event State Publication February 2004

o Changed syntax by adding a "SIP-" prefix to the header field
names. This is to indicate that the syntax/semantics of
entity-tags is similar but different from the HTTP counterparts.

o Fixed the draft to consistently use Request-URI as identifying the
target resource for the publication.

Niemi Expires July 5, 2004 [Page 33]

Internet-Draft SIP Event State Publication January 2004
target resource for the publication.

o Clarified Contact usage and in-dialog requests.

o Lots of fixes to various places in the draft based on review
comments.

o Split the old Table 3 into two for better readability.

o Fixed examples to use correct PIDF XML namespace declarations and
MIME type.

o Added reference to ABNF.

15.2

18.3 Changes since "draft-ietf-sip-publish-00"

The following changes were made since the last version:

o Specified the role of the Request-URI in identifying the
publication target resource. Also, clarified chapter 5 in this
regard to explicitly talk about the identification of
publications.

o Changed chapter 6 to use Request-URI in determining the
publication target resource. Also clarified language within the
processing steps of an ESC.

o Added missing header fields and removed unneeded "proxy" column in
Table 1 and Table 2. Corrected Table 3 content.

o Corrected various nits in examples and in body text.

15.3

18.4 Changes since "draft-ietf-simple-publish-01"

The following changes were made since the last version:

o Submitted as "draft-ietf-sip-publish-00".

o Changed title to better reflect the content.

o Removed event state segmentation and collision detection of

Niemi Expires August 13, 2004 [Page 35]

Internet-Draft SIP Event State Publication February 2004

segments, and simplified usage of entity-tags.

o Rewrote Ch 4 "Considerations for Event Packages Using PUBLISH" to
mimic the way RFC 3265 defines considerations for event packages.
Also, removed normative dependency to
"draft-ietf-simple-publish-reqs".

Niemi Expires July 5, 2004 [Page 34]

Internet-Draft SIP Event State Publication January 2004

o Rewrote Ch 9 "Security Considerations" to now include text about
specific vulnerabilities and the security tools to counter those
attacks.

o Clarified both UAC and UAS usage of entity-tags. Moved common
error handling of UACs to a separate sub-section.

o Improved description of UAS functionality of Ch 6 "Processing
PUBLISH Requests", and alinged it with RFC 3261 Chapter 10 on
processing registrations.

o Changed entity-tag syntax from "quoted-string" to "token". This is
a deviation from RFC 2616 entity-tag syntax, but more aligned to
how similar things are expressed in SIP.

o Restricted the If-Match header syntax to only allow a single
entity-tag. Multiple entity-tags are not applicable to PUBLISH.

o Added methods other than PUBLISH to Table 3.

o Rewrote Ch 10 "Examples" to better reflect actual PUBLISH usage.

o Changed reference [10] from caller-prefs to callee-caps.

o Overall language and structure tweaking.

15.4

18.5 Changes since "draft-ietf-simple-publish-00"

The following changes were made since the last version:

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

o Removed usage of Call-ID and 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 content-indirection as Informative

Niemi Expires August 13, 2004 [Page 36]

Internet-Draft SIP Event State Publication February 2004

o Added section for ABNF definitions

o Editorial corrections, restructuring of document to improve
readability

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

Niemi Expires July 5, 2004 [Page 35]

Internet-Draft SIP Event State Publication January 2004

o Added new definitions in Terminology, and clarified EPA and ESC
definitions

o Strengthened the IANA considerations section.

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

Normative References

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

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

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

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

[3]

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

[4]

[6] Sugano, H. and S. Fujimoto, "Presence Information Data Format
(PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May
2003.

[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.

[9] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.

Informative References

[5]

Niemi Expires August 13, 2004 [Page 37]

Internet-Draft SIP Event State Publication February 2004

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

[6] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.

[7]

[11] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-03 (work in progress), January 2004.

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

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

[9] Sugano, H. and S. Fujimoto, "Presence Information Data Format
(PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May
2003.

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

Niemi Expires July 5, 2004 [Page 36]

Internet-Draft SIP Event State Publication January 2004

[11] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-02 (work in progress), December
2003.

Author's Address

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

Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com

Niemi Expires July 5, August 13, 2004 [Page 37] 38]

Internet-Draft SIP Event State Publication January February 2004

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 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 July 5, August 13, 2004 [Page 38] 39]

Internet-Draft SIP Event State Publication January February 2004

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

Acknowledgment

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

Niemi Expires July 5, August 13, 2004 [Page 39] 40]

----