view Side-By-Side changes

SIMPLE

SIP WG                                                     A. Niemi, Ed.
Internet-Draft                                                     Nokia
Expires: December 28, 2003                                 June 29, March 9, 2004                                 September 9, 2003


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

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 December 28, 2003. March 9, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

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

   The mechanism described in this document can be extended to support
   publication of any event 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 better-suited
   mechanisms for this purpose (FTP, HTTP, etc.)





Niemi                    Expires December 28, 2003 March 9, 2004                  [Page 1]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Terminology    Definitions and Document Conventions . . . . . . . . . . . . . . . .  3
   3.    Overall Operation  . . . . . . . . . . . . . . . . . . . . .  4
   4.    Prerequisites    Considerations for Event Packages using PUBLISH  . . . . . . .  5
   4.1   PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . . . .  5
   4.2   PUBLISH Response Bodies  . . . . . . . . . . . . . . . . . .  5
   4.3   Partial Event State  . . . . . . . . . . . . . . . . . . . .  6  5
   4.4   Event State Decomposition  . . . . . . . . . . . . . . . . .  6
   4.5   Default Expiration of PUBLISH  . . . . . . . . . . . . . . .  6
   5.    Constructing the PUBLISH Request Requests  . . . . . . . . . . . . . . .  7  6
   5.1   Creating Initial Publication . . . . . . . . . . . . . . . .  8
   5.2   Setting the Expiration Interval  . . . . . . . . . . . . . .  9  8
   5.3   Refreshing Event State . . . . . . . . . . . . . . . . . . .  9  8
   5.4   Modifying Event State  . . . . . . . . . . . . . . . . . . . 10  9
   5.5   Removing Event State . . . . . . . . . . . . . . . . . . . . 10
   5.6   Querying the Current Event State . . . . . . . . . . . . . . 11 10
   5.7   Error Responses  . . . . . . . . . . . . . . . . . . . . . . 10
   6.    Processing PUBLISH Requests  . . . . . . . . . . . . . . . . 11
   7.    Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.1   New Methods  . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.1.1 PUBLISH Method . . . . . . . . . . . . . . . . . . . . . . . 14
   7.2   New Response Codes . . . . . . . . . . . . . . . . . . . . . 16
   7.2.1 "412 Precondition Failed" Response Code  . . . . . . . . . . 16
   7.3   New Header Fields  . . . . . . . . . . . . . . . . . . . . . 16
   7.3.1 "ETag" Header  . . . Field  . . . . . . . . . . . . . . . . . . . . 17
   7.3.2 "If-Match" Header  . . . Field  . . . . . . . . . . . . . . . . . . 17
   7.4   Augmented BNF Definitions  . . . . . . . . . . . . . . . . . 17
   8.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 17
   8.1   Methods  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.2   Response Codes . . . . . . . . . . . . . . . . . . . . . . . 18
   8.3   Header Field Names . . . . . . . . . . . . . . . . . . . . . 18
   9.    Security Considerations  . . . . . . . . . . . . . . . . . . 18
   9.1   Access Control . . . . . . . . . . . . . . . . . . . . . . . 18
   9.2   Denial of Service Attacks  . . . . . . . . . . . . . . . . . 19
   9.3   Replay Attack  . . . . . . . . . . . . . . . . . . . . . . . 19
   9.4   Man in the Middle Attacks  . . . . . . . . . . . . . . . . . 19
   9.5   Confidentiality  . . . . . . . . . . . . . . . . . . . . . . 20
   10.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 20
   11.   Open Issues   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 27
   12.   Contributors   Document Change History  . . . . . . . . . . . . . . . . . . 27
   12.1  Changes from "draft-ietf-simple-publish-01"  . . . . . . . . 26
   13. 27
   12.2  Changes from "draft-ietf-simple-publish-00"  . . . . . . . . 26 28
         Normative References . . . . . . . . . . . . . . . . . . . . 27 29
         Informative References . . . . . . . . . . . . . . . . . . . 27 29
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 28 30
         Intellectual Property and Copyright Statements . . . . . . . 29 31




Niemi                    Expires December 28, 2003 March 9, 2004                  [Page 2]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


1. Introduction

   The focus of this specification is to provide a framework for the
   publication of event state from a user agent to an entity that is
   responsible for compositing composing this event state and distributing it to
   interested parties through the SIP events [1] framework. This
   specification fills a gap in the SIP events framework to allow for a
   client to push its event state to the state agent that acts on its
   behalf.

   The first application of this mechanism is the publication of
   presence state by a presence user agent to a presence compositor compositor,
   which has a tightly coupled relationship to with the presence agent. The
   requirements and model for presence publication are documented in
   [2].
   [4]. This specification will address each of those requirements.

   The mechanism described in this document can be extended to support
   publication of any event 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 better-suited mechanisms for this purpose (FTP [7], [5], HTTP [8], [6],
   etc.)

2. Terminology Definitions and Document Conventions

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

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

   Event Publication Agent (EPA): The UAC which that issues a PUBLISH request requests
      to publish event state or event state segments. state. For presence, this corresponds to the PUA.

   Event State Compositor (ESC): The UAS which that processes PUBLISH
      requests
      requests, and is responsible of compositing event state or composing event state segments into a
      complete, composite event state. state of a resource. For presence, this
      corresponds to the PA.

   Event State Segment: For some event packages, there exists a natural
      decomposition

   Publication: The act of an EPA sending a PUBLISH message to an ESC to
      publish event state into event state segments. For
      presence, such decomposition is the presence tuple. state.

   Hard State: Hard state is the The steady-state or default state version
      of event state at the ESC, of a resource,
      which the ESC may be used use in the absence of any
      other of, or in addition to, soft
      state publications.






Niemi                    Expires December 28, 2003 March 9, 2004                  [Page 3]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


   Soft State: Soft state is a version of event Event state at the ESC, that
      is published by an EPA using the EPA. Soft state has a defined lifetime and
      will expire after a negotiated amount of time.

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

   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 [4] [3] 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 normative protocol behavior.


3. Overall Operation

   This document defines a new SIP method, PUBLISH, for publishing event
   state. PUBLISH is analogous to REGISTER in that it allows a user to
   add,
   create, modify, and remove state in another entity which manages this
   state on behalf of a the user. The user may in turn have multiple UAs
   or endpoints. Each endpoint may publish its own unique state, out of
   which the event agent generates the composite event state and through of the
   resource. Through a subscription to that event package package, the user is
   able to discover the composite event state of all the
   other active
   endpoints.

   In the generic sense, a UAC which that publishes event state is labelled labeled an
   Event Publication Agent (EPA). For presence in particular, this is
   the familiar PUA role as defined in [5]. [7]. The entity which that processes
   the PUBLISH request is known as an Event State Compositor (ESC). For
   presence in particular, this is the familiar PA role as defined in
   [5].
   [7].

   PUBLISH requests create soft state in the state agent. ESC. This 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 may in turn define
   hard-state hard
   state for a particular event package. That is, the steady-state of
   this event package in the absence of any other of, or in addition to, soft state
   provided through the PUBLISH method. mechanism. Setting this hard state or
   configuring the composer policy is out of the scope of this
   specification.

   Typically, the body of a PUBLISH request carries the published event
   state. In the response to a PUBLISH request, the EPA ESC assigns a
   version an
   identifier to the published event state or this event state
   segment. state. This identifier is then used by the



Niemi                    Expires March 9, 2004                  [Page 4]

Internet-Draft        SIP Event State Publication         September 2003


   EPA as part of a version request precondition to point to that specific event state
   in the subsequent refreshing PUBLISH requests of that modify, refresh or remove
   that event state. In case the PUBLISH request points to an expired
   event that state, the publication refresh is to an outdated
   version of event state, the versioning precondition will fail. This
   enables an EPA to detect collisions between new and refresh
   publications of the same event state among a set of endpoints.




Niemi                  Expires December 28, 2003                [Page 4]

Internet-Draft          SIP Presence Publication               June 2003

   Event state publication inherently involves at least two parties: the
   source of the publication and the target of the publication. The
   source of Both the publication is naturally represented as an
   address-of-record (AOR).

   For some types of event state, namely presence,
   source and the target of the publication may not sufficiently be represented by an
   address-of-record (AOR) alone. Rather, the target is a combination of
   both an AOR and a unique identifier which acts to represent one of N
   possible sections of an overall event state for that AOR. In this
   specification, these sections are referred to naturally represented as event state
   segments.

   In the context of presence publication, the event state segment is
   nothing more than the presence tuple associated with the presentity
   (AOR). It is the role of the compositor to aggregate these segments
   into a complete event state which is presented to the subscribers of
   that event state. This composition logic is a matter of local policy.

   For some event packages, there is no natural decomposition of event
   state into these segments and for these packages,
   an AOR is
   sufficient to identify the target of the publication. address-of-record.

4. Prerequisites Considerations for Event Packages using PUBLISH

   In order to make use of the event publication mechanism, certain
   prerequisites have to

   This section discusses several issues which should be fulfilled for each specific event package.
   In order to satisfy the requirements of [2], the body of taken into
   consideration when applying the PUBLISH
   request must fulfill several requirements as well.

   This section outlines these prerequisites, and mechanism to event packages.
   It also demonstrates how they these issues are fulfilled specifically handled when using PUBLISH
   for presence publication.

4.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 support a define what content type which fulfills the requirements or types are expected in [2].
   PUBLISH requests. Each event package MUST also describe the semantics
   associated with that content content, and MUST prescribe a default, mandatory
   to implement
   format. MIME type.

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

4.2 PUBLISH Response Bodies




Niemi                  Expires December 28, 2003                [Page 5]

Internet-Draft          SIP Presence Publication               June 2003

   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 a presence
   publication when the document format used is CPIM PIDF.

4.3 Partial Event State

   The content type MUST provide a way to publish partial state for an
   event package. The intention is to allow each device or client endpoint for an
   address-of-record to publish event state independently. To accomplish
   this, the event state that is published by these devices endpoints MUST be



Niemi                    Expires March 9, 2004                  [Page 5]

Internet-Draft        SIP Event State Publication         September 2003


   allowed to be only a portion of the complete state that the state
   agent advertises for that AOR. address-of-record.

      Note that sources for event state other than those using the
      PUBLISH mechanism are explicitly allowed. It is beyond the scope
      of this document to define such interfaces.

   For presence in particular, a PUA can publish presence state for just
   a subset of the tuples that may be composited composed into the presence
   document that watchers receive in a NOTIFY. The mechanism by which
   the ESC aggregates this information is a matter of local policy.

4.4 Event State Decomposition

   If the content type allows for event state segments to be
   represented, the content type MUST provide a means to uniquely
   identify each unique segment.

   For presence, the CPIM PIDF presence document provides a tuple-ID to
   distinguish the segments of the presence document associated with the
   encompassing presentity.

      OPEN ISSUE: The specifics policy and
   out of how the tuple-ID is used to identify
      specific segments scope of the composite state is still open. Currently,
      a specific naming convention for the tuple-ID seems like a
      reasonable approach. However, this naming convention is to be
      defined.


4.5 specification.

4.4 Default Expiration of PUBLISH

   PUBLISH establishes requests establish soft state in the ESC which expires after
   a negotiated amount of time. Each event package MUST provide a
   default expiration value recommendation (SHOULD strength).



Niemi                  Expires December 28, 2003                [Page 6]

Internet-Draft          SIP Presence Publication               June 2003

   For presence publication, it is RECOMMENDED that the ESC use a
   default value of 3600 seconds (1 hour) for this default expiration
   value.

5. Constructing the PUBLISH Request Requests

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

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

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

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

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



Niemi                    Expires March 9, 2004                  [Page 6]

Internet-Draft        SIP Event State Publication         September 2003


   The following header fields are fields, except Expires and If-Match, MUST be
   included in a PUBLISH request:

   Request-URI: The Request-URI initially contains the address-of-record
      whose publication is to request. An Expires header field SHOULD be
   included and an If-Match header field MAY be included:

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




Niemi                  Expires December 28, 2003                [Page 7]

Internet-Draft          SIP Presence Publication               June 2003

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

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

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

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

   If-Match: PUBLISH requests MAY contain a single If-Match header
      field. This header field SHOULD MUST contain one or more entity-tags a single entity-tag provided
      by the ESC, to be used as a versioning precondition to a
      PUBLISH refresh. which identifies the event state that the request is
      refreshing, modifying or removing.

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

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

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



Niemi                    Expires March 9, 2004                  [Page 7]

Internet-Draft        SIP Event State Publication         September 2003


   carried directly within the SIP signaling (PUBLISH request).

5.1 Creating Initial Publication

   The PUBLISH request created by the EPA and sent to the Event State
   Compositor (ESC) ESC
   establishes soft state in the state agent for the event package indicated in the request Event
   header field of the request, and bound to the address-of-record in
   the To header field of the request. Additionally, the
   PUBLISH request may publish event state that is further sub-divided
   into segments of

   The published event state that may be manipulated independently.
   As an example, presence publication using the CPIM PIDF format may
   manipulate individual tuples related to a common presentity.





Niemi                  Expires December 28, 2003                [Page 8]

Internet-Draft          SIP Presence Publication               June 2003


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

   Once the initial
   PUBLISH request has been processed by the ESC, the request.

   The EPA MAY send subsequent PUBLISH requests to refresh, modify, or
   delete
   remove the publication event state established by the first PUBLISH
   request. a prior publication. These
   operations will be described in subsequent sections.

   EPAs MUST NOT send a new

   An initial PUBLISH request (not a re-transmission)
   until they have received a final response from MUST not contain an If-Match header field.
   However, if the EPA expects an appropriate, locally stored entity-tag
   to still be valid, it SHOULD try to modify that event state agent for
   the previous one or the previous PUBLISH request has timed out. as
   described in Section 5.4, instead of submitting an initial
   publication.

5.2 Setting the Expiration Interval

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

      For example, a reasonable implementation might maintain event
      state over a short grace period even after the publication on
      which it arrived has expired.

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

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

5.3 Refreshing Event State

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

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




Niemi                    Expires March 9, 2004                  [Page 8]

Internet-Draft        SIP Event State Publication         September 2003


   Also, the 200 (OK) response to a PUBLISH request from the state agent MUST contain ESC
   contains an ETag header field with a single entity-tag indicating an
   identifier for the version information of
   the publication. published event state. To refresh the event state,
   the EPA MUST include includes the



Niemi                  Expires December 28, 2003                [Page 9]

Internet-Draft          SIP Presence Publication               June 2003 received entity-tag in an If-Match header field in a
   of the PUBLISH request.

      Note that for the EPA, the entity-tag is simply an opaque string.
      It carries no further token
      without any semantics for the EPA. associated with it.

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

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

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

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

   A PUBLISH request if
   the that refreshes event state changes again.

   A PUBLISH refresh SHOULD NOT contain a
   body.

5.4 Modifying Event State

   Modification of

   Modifying event state is considered a new publication similar
   to closely resembles the creation of initial event
   state. Because the modification But instead of establishing completely new event state in the
   ESC, already existing event state is not a refresh publication, replaced with modified event
   state. Typically, the EPA does not include a
   versioning precondition modified event state is carried in the body of
   the PUBLISH request. Therefore, the

   The 200 (OK) response to a PUBLISH request MUST NOT include from the ESC contains an If-Match
   ETag header field, and the
   EPA MUST discard any previously received version field with a single entity-tag indicating an identifier
   for this the published event state.

5.5 Removing Event State

   PUBLISH establishes soft state which expires unless refreshed. This To modify that event state may also be explicitly removed. A UA requests state, the
   immediate removal of event state by specifying EPA
   includes the received entity-tag in an Expires value If-Match header field of
   "0" in the
   PUBLISH request. Such a

   The If-Match header field containing an entity-tag preconditions the
   PUBLISH request SHOULD NOT contain any
   body. UAs to modify a specific instance of event state in the
   ESC. If the entity-tag matches a valid event state in the ESC, that
   event state is replaced by the event state carried in the PUBLISH
   request, and the EPA receives a 200 (OK) response. If there is no
   matching event state at the ESC, i.e., the event state to be modified
   has already expired, the EPA receives a 412 (Precondition Failed)
   response to the PUBLISH request.

      Note that the entity-tag will remain unchanged when modifying the
      event state associated with it.






Niemi                    Expires March 9, 2004                  [Page 9]

Internet-Draft        SIP Event State Publication         September 2003


5.5 Removing Event State

   Soft state established by the PUBLISH request will expire unless
   periodically refreshed. This event state may also be explicitly
   removed. An EPA can influence the expiration interval selected by the
   ESC as described in Section 5.2.

   An EPA requests the immediate removal of event state by specifying in
   the PUBLISH request an Expires value of "0", and setting the If-Match
   header field to contain the entity-tag of the event state to be
   removed.

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

   A PUBLISH request that removes event state SHOULD NOT contain a body.
   EPAs which support the PUBLISH method SHOULD support this mechanism
   for explicitly removing event state.




Niemi                  Expires December 28, 2003               [Page 10]

Internet-Draft          SIP Presence Publication               June 2003

5.6 Querying the Current Event State

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

6. Processing PUBLISH Requests

   The Event State Compositor (ESC) is a UAS RFC3265 [1].

      Note that responds to PUBLISH
   requests and maintains a list subscription to the event package will likely deliver
      results of publications for a given
   address-of-record. The ESC MUST ignore the Record-Route header field
   if it is included in event composition process of the state agent, which
      may be a PUBLISH request. The ESC subset or a superset of the current published event
      state.


5.7 Error Responses

   If an EPA receives a 412 (Precondition Failed) response, it MUST NOT include
   reattempt the PUBLISH request. Instead, to publish event state, the
   EPA SHOULD perform an initial publication, i.e., a
   Record-Route header field PUBLISH request
   without a request precondition, as described in any Section 5.1.

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



Niemi                    Expires March 9, 2004                 [Page 10]

Internet-Draft        SIP Event State Publication         September 2003


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. The ESC has to know (for example, (e.g., through configuration)
   the domain or set of
   domain(s) domains for which it maintains 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 in any response to a PUBLISH request.

   PUBLISH requests MUST be processed in the order that they are
   received. PUBLISH requests MUST also be processed atomically, meaning
   that a particular PUBLISH request is either processed completely or
   not at all.

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

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

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

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

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

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




Niemi                  Expires December 28, 2003               [Page 11]

Internet-Draft          SIP Presence Publication               June 2003


   4.   The
        RFC3261 [2]. If no authentication mechanism is available, the
        ESC extracts MAY take the address-of-record from of the To From header field as
        the asserted identity of the originator of the request.  If

   4.   The ESC SHOULD determine if the address-of-record authenticated user is not valid authorized
        to perform event state publication for the address-of-record of
        the To header field. If the authenticated user is not
        authorized, the ESC MUST return a 403 (Forbidden) and skip the
        rest of the remaining steps.



Niemi                    Expires March 9, 2004                 [Page 11]

Internet-Draft        SIP Event State Publication         September 2003


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

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

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

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

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

   7.   The ESC now processes examines the Expires If-Match header value from field of the PUBLISH
        request.
        request for the presence of a request precondition.

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

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

        *  The ESC MAY choose an expiration less than checks
           whether the requested
           expiration interval. header field contains a single entity-tag. If and only if
           not, the requested expiration
           interval request is greater than zero AND less than a
           locally-configured minimum, invalid, and the ESC MAY reject the
           publication MUST return with a 400
           (Invalid Request) response of 423 (Interval Too Brief), and skip the rest of the remaining steps.  This response MUST
           contain a Min-Expires header field that states the minimum
           expiration interval

        *  Else, the ESC is willing to honor.

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



Niemi                  Expires December 28, 2003               [Page 12]

Internet-Draft          SIP Presence Publication               June 2003 match is found, the ESC MUST reject the
           publication with a response of 412 (Precondition Failed), and
           skip the remaining steps.

   9.   The ESC may then process the body of the PUBLISH request (the
        actual event state).

        *  If the request contains no body (when it
        should contain one), or the Content-Type of the request does not
        match the event-package, or is not understood by the ESC, the
        ESC MUST reject the request with an appropriate response.

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

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

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

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

        * entity-tag.

   8.   The processing of ESC processes the Expires header field value from the
        PUBLISH request.

        *  If the request must has an Expires header field, that value MUST



Niemi                    Expires March 9, 2004                 [Page 12]

Internet-Draft        SIP Event State Publication         September 2003


           be atomic. If
           internal errors (such taken as the inability to access requested expiration.

        *  Else, a back-end
           database) occur before processing 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 is complete, greater than zero and less than a
           locally-configured minimum, the ESC MAY reject the
           publication with a response of 423 (Interval Too Brief), and
           skip the remaining steps.  This response MUST contain a
           Min-Expires header field that states the minimum expiration
           interval the ESC is willing to honor.

   9.   The ESC processes the published event state, typically contained
        in the body of the PUBLISH request. If the request contains no portion
        body (when it should contain one), or the content type of the
        request does not match the event package, or is not understood
        by the ESC, the ESC MUST reject the request with an appropriate
        response and skip the remainder of the steps.

        *  For each publication, the ESC records the target of the
           publication, the entity-tag identifying the publication, the
           expiration value of the event state, and a pointer to the
           actual event state.

        *  If present, the ESC stores the event state delivered in the
           PUBLISH document must request and identified by the associated 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 a
           special value of "0", the event state identified by the
           entity-tag MUST be published immediately removed.

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

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




Niemi                    Expires March 9, 2004                 [Page 13]

Internet-Draft        SIP Event State Publication         September 2003


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



Niemi                  Expires December 28, 2003               [Page 13]

Internet-Draft          SIP Presence Publication               June 2003


7. Syntax

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

7.1 New Methods

7.1.1 PUBLISH Method

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

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


























Niemi                    Expires December 28, 2003 March 9, 2004                 [Page 14]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


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

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







Niemi                    Expires December 28, 2003 March 9, 2004                 [Page 15]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


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

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


7.2 New Response Codes

7.2.1 "412 Precondition Failed" Response Code

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

7.3 New Header Fields

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








Niemi                    Expires December 28, 2003 March 9, 2004                 [Page 16]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


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


 +--------------+-----+-----+----+----+----+----+----+----+----+-----+
 | Header Field | where whr | proxy prx | AC | BY | CA | IN | OP | RE | PR | PUB |
                 +--------------+-------+-------+-----+
 +--------------+-----+-----+----+----+----+----+----+----+----+-----+
 | ETag         | 2xx |     |    |    |    |    |    |    |    |  m  |
 | If-Match     |   R  R  |     |    |    |    |    |    |    |    |  o  |
                 +--------------+-------+-------+-----+
 +--------------+-----+-----+----+----+----+----+----+----+----+-----+

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


7.3.1 "ETag" Header Field

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

7.3.2 "If-Match" Header Field

   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.

7.4 Augmented BNF Definitions

   This section describes the Augmented BNF definitions for the various
   new and modified syntax elements. The notation is as used in SIP [3] [2]
   and the documents to which it refers.

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



8. IANA Considerations

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

8.1 Methods

   This document registers a new SIP method, defined by the following
   information
   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



Niemi                    Expires December 28, 2003 March 9, 2004                 [Page 17]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


       Method Name:   PUBLISH


       Reference:     [RFCYYYY]

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


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


8.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:    ETag
       Compact Form:   (none)

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


9. Security Considerations

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

   The state agent SHOULD authenticate the Event Publication Agent
   (EPA), 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
   a compositor (ESC) an ESC are on the same network, or in the same
   administrative domain.

   Authentication issues are discussed in SIP [2]. The exact methods for
   creation and manipulation of the ESC authorization policies are
   outside the scope of this document.



Niemi                    Expires March 9, 2004                 [Page 18]

Internet-Draft        SIP Event State Publication         September 2003


9.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 in SIP [2].

   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 Expires: Expires header
   field values for the supported event packages at a 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 method.




Niemi                  Expires December 28, 2003               [Page 18]

Internet-Draft          SIP Presence Publication               June 2003


   Integrity protection and privacy of request.

9.3 Replay Attack

   Replaying the PUBLISH requests request can have detrimental effects. An
   attacker may be
   ensured using able to perform any event state publication it
   witnessed being performed at some point in the S/MIME mechanisms outlined past, by replaying a
   PUBLISH request. Among other things, such a replay message may be
   used to spoof old event state information, although a versioning
   mechanism, e.g., a timestamp, in section 23 of
   RFC3261. Integrity the state information may help
   mitigate such an attack.

   To prevent replay attacks, implementations SHOULD require
   authentication with anti-replay protection. Authentication issues are
   discussed in SIP [2].

9.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
   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 of across the To, From, Call-ID, CSeq, Event,
   ETag, If-Match,
   Route, and Expires headers should be done at a
   minimum. Expires headers and the bodies of PUBLISH messages.

   If the ESC receives event state in a PUBLISH request which is
   integrity protected using a security association that is not with the
   ESC (for example,
   end-to-end S/MIME (e.g., integrity protection), 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
   watchers subscribers of this event



Niemi                    Expires March 9, 2004                 [Page 19]

Internet-Draft        SIP Event State Publication         September 2003


   state in a NOTIFY request(s). requests. This is to preserve the end-to-end
   integrity of the event state.

   Integrity protection of message headers and bodies is discussed in
   SIP [2].

9.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 providing confidentiality are detailed in SIP [2].

10. Examples

   The following

   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 will 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. PUA, and is not shown in this
   example.


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



Niemi                    Expires March 9, 2004                 [Page 20]

Internet-Draft        SIP Event State Publication         September 2003


        |                       |                         |
        |                       |                         |
        | --- M9: M11: PUBLISH ----> ---> |                         |
        |                       |                         |
        | <-- M10: M12: 200 OK ----  |                         |
        |                       |                         |
        |                       | ----- M11: M13: NOTIFY ----> |
        |                       |                         |
        |                       | <---- M14: 200 OK ----- |
        |                       |                         |


   Message flow:

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

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

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

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

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

      NOTIFY ----> |
        |                       |                         | sip:presentity@domain.com SIP/2.0
      Via: SIP/2.0/UDP pa.domain.com;branch=z9hG4bK8sdf2



Niemi                    Expires December 28, 2003 March 9, 2004                 [Page 19] 21]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


        |                       | <---- M12: 200 OK ----- |
        |                       |                         |
        |                       |                         |
        |<---- M13:


      To: <sip:watcher@domain.com>;tag=12341234
      From: <sip:presentity@domain.com>;tag=abcd1234
      Call-ID: 12345678@10.0.0.1
      CSeq: 1 NOTIFY ---- |                         |
        |                       |                         |
        |----- M14: 200 OK  --> |                         |
        |                       |                         |


   Message flow:

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

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

   M4: The watcher confirms receipt of the NOTIFY request.

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

   M5: A presence user agent for the presentity initiates a new subscription PUBLISH to
      the
      presentity@domain.com's presentity's presence agent.

      SUBSCRIBE agent in order to update it with new
      presence information. The Expires header indicates the desired
      duration of this soft state.

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



Niemi                    Expires March 9, 2004                 [Page 22]

Internet-Draft        SIP Event State Publication         September 2003


      Event: presence
      Contact: <sip:watcher@domain.com>
      Content-Type: application/cpim-pidf+xml
      Content-Length: 0

   M2: ...

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

   M6: The presence agent for presentity@domain.com processes the
      subscription request receives, and creates a new subscription. accepts the presence
      information. The published data is incorporated into the
      presentity's presence document. A 200 (OK) response is sent to
      confirm the subscription. publication. The 200 (OK) response contains an 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 10.0.0.1:5060;branch=z9hG4bKnashds7 pua.domain.com;branch=z9hG4bK652hsge
      To: <sip:presentity@domain.com>;tag=abcd1234 <sip:presentity@domain.com>;tag=1a2b3c4d
      From: <sip:watcher@domain.com>;tag=12341234 <sip:presentity@domain.com>;tag=1234wxyz
      Call-ID: 12345678@10.0.0.1 81818181@pua.domain.com
      CSeq: 1 SUBSCRIBE
      Contact: <sip:pa@domain.com> PUBLISH
      ETag: dx200xyz
      Expires: 3600
      Content-Length: 0

   M3: In order 1800

   M7: The presence agent determines that a reportable change has been
      made to complete the process, the presentity's presence agent document, and sends another
      notification to those watching the
      watcher a NOTIFY with presentity to update their
      information regarding the presentity's current presence state of the
      presentity. status.

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



Niemi                  Expires December 28, 2003               [Page 20]

Internet-Draft          SIP Presence Publication               June 2003
      CSeq: 1 2 NOTIFY
      Event: presence
      Subscription-State: active; expires=3599 expires=3400
      Content-Type: application/cpim-pidf+xml
      Content-Length: ...

      <?xml version="1.0" encoding="UTF-8"?>



Niemi                    Expires March 9, 2004                 [Page 23]

Internet-Draft        SIP Event State Publication         September 2003


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

   M4:

   M8: The watcher confirms receipt of the NOTIFY request.

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

   M5: To view its composite presence state, the
      Content-Length: 0

   M9: The PUA issues a SUBSCRIBE
      to determines that the PA for itself.

      SUBSCRIBE event state it previously published
      is about to expire, and refreshes that event state.

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





Niemi                  Expires December 28, 2003               [Page 21]

Internet-Draft          SIP Presence Publication               June 2003


   M6:

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

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

   M7: In order to complete accepts the process, publication
      refresh. The timers regarding the presence agent sends expiration of the
      PUA a NOTIFY with specific event
      state identified by the current presence entity-tag are updated. Note that no
      actual state of change has occured, so the presentity.

      NOTIFY sip:presentity@domain.com SIP/2.0
      Via: SIP/2.0/UDP pa.domain.com;branch=z9hG4bK8sdfk
      To: <sip:watcher@domain.com>;tag=abcd1235
      From: <sip:presentity@domain.com>;tag=43214321
      Call-ID: 87654321@10.0.0.2
      CSeq: 1 NOTIFY
      Event: presence
      Subscription-State: active; expires=3599
      Content-Type: application/cpim-pidf+xml
      Content-Length: ...

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

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pua.domain.com;branch=z9hG4bK771ash02



Niemi                    Expires December 28, 2003 March 9, 2004                 [Page 22] 24]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


   M9: A presence user agent for


      To: <sip:presentity@domain.com>;tag=2affde434
      From: <sip:presentity@domain.com>;tag=1234kljk
      Call-ID: 98798798@pua.domain.com
      CSeq: 1 PUBLISH
      ETag: dx200xyz
      Expires: 1800

   M11: The PUA of the presentity detects a change in the user's
      presence state. It initiates a PUBLISH request to the presentity's presence
      agent in order to update it with modify the new published presence
      information. The timestamp element is updated to indicate the time
      of information with the recent
      change. The Expires header indicates the desired duration
      of this soft state. The "entity" attribute of the presence element
      in the PIDF document matches the To AOR.

      PUBLISH sip:presentity@domain.com SIP/2.0
      Via: SIP/2.0/UDP pua.domain.com;branch=z9hG4bK652hsge pua.domain.com;branch=z9hG4bKcdad2
      To: <sip:presentity@domain.com>;tag=1a2b3c4d <sip:presentity@domain.com>
      From: <sip:presentity@domain.com>;tag=1234wxyz <sip:presentity@domain.com>;tag=54321mm
      Call-ID: 81818181@pua.domain.com 5566778@pua.domain.com
      CSeq: 1 PUBLISH
      If-Match: dx200xyz
      Expires: 3600
      Event: presence
      Content-Type: application/cpim-pidf+xml
      Content-Length: ...

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

   M10:

   M12: The presence agent receives, and accepts the presence
      information. 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. A 200 (OK) response is sent to
      confirm Note that the publication. document delivered in this modification
      will replace the previous document.

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP pua.domain.com;branch=z9hG4bK652hsge pua.domain.com;branch=z9hG4bKcdad2
      To: <sip:presentity@domain.com>;tag=1a2b3c4d <sip:presentity@domain.com>;tag=effe22aa
      From: <sip:presentity@domain.com>;tag=1234wxyz <sip:presentity@domain.com>;tag=54321mm
      Call-ID: 81818181@pua.domain.com 5566778@pua.domain.com
      CSeq: 1 PUBLISH



Niemi                    Expires March 9, 2004                 [Page 25]

Internet-Draft        SIP Event State Publication         September 2003


      ETag: "dx200xyz" dx200xyz
      Expires: 1800

   M11: 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 December 28, 2003               [Page 23]

Internet-Draft          SIP Presence Publication               June 2003


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

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

   M12: The watcher confirms receipt of the NOTIFY request.

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

   M13: The presence agent also sends a NOTIFY
      notification to those watching the PUA. presentity to update their
      information regarding the presentity's current presence status.

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



Niemi                  Expires December 28, 2003               [Page 24]

Internet-Draft          SIP Presence Publication               June 2003
      Content-Type: application/cpim-pidf+xml
      Content-Length: ...

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

   M14: The PUA watcher confirms receipt of the NOTIFY request.

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






Niemi                    Expires March 9, 2004                 [Page 26]

Internet-Draft        SIP Event State Publication         September 2003


11. Open Issues

   o  Atomicity of publication. Should the segments of event state
      (presence tuples) be sent in separate PUBLISH requests or is it
      enough Contributors

   The original contributors to this specification are:

      Ben Campbell
      dynamicsoft

      Sean Olson
      Microsoft

      Jon Peterson
      Neustar, Inc.

      Jonathan Rosenberg
      dynamicsoft

      Brian Stucker
      Nortel Networks, Inc.


12. Document Change History

   (Note to RFC Editor: please remove this whole section prior to treat these as implicitly separate
   publication requests?

   o as an RFC.)

12.1 Changes from "draft-ietf-simple-publish-01"

   The exact naming convention used for following changes were made since the tuple-ID when publishing
      tuples. last version:

   o  In case a refresh publication fails, what should the EPA do?
      Current suggestion is  Submitted as "draft-ietf-sip-publish-00".

   o  Changed title to query the principal, i.e., "prompt better reflect the
      user", but this is not quite specific. content.

   o  Does end-to-end S/MIME integrity protection make sense when an  Removed event compositor is used? Does it indicate that the segment should
      be carried state segmentation and collision detection of
      segments, and simplified usage of entity-tags.

   o  Rewrote Ch 4 "Considerations for Event Packages Using PUBLISH" to
      mimic the watcher intact, or is another mechanism way RFC 3265 defines considerations for this
      needed? event packages.
      Also, removed normative dependency to
      "draft-ietf-simple-publish-reqs".

   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.




Niemi                    Expires December 28, 2003 March 9, 2004                 [Page 25] 27]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


   o  The examples seem a bit elaborate,  Improved description of UAS functionality of Ch 6 "Processing
      PUBLISH Requests", and don't even cover the
      publication refresh case. We should probably work alinged it with RFC 3261 Chapter 10 on them.
      processing registrations.

   o  Do we need another response code (new or some existing one) for
      the case when an EPA tries  Changed entity-tag syntax from "quoted-string" to refresh "token". This is
      a publication, deviation from RFC 2616 entity-tag syntax, but more aligned to
      how similar things are expressed in SIP.

   o  Restricted the ESC
      has lost all version information it has, e.g., after e reboot?
      This seems If-Match header syntax to only allow a slightly different scenario 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 the usual
      "Precondition Failed".


12. Contributors

   The original contributors caller-prefs to this specification are:

      Ben Campbell
      dynamicsoft

      Sean Olson
      Microsoft

      Jon Peterson
      Neustar, Inc.

      Jonathan Rosenberg
      dynamicsoft

      Brian Stucker
      Nortel Networks, Inc.


13. callee-caps.

   o  Overall language and structure tweaking.


12.2 Changes from "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

   o  Added section for ABNF definitions

   o  Editorial corrections, restructuring of document to improve



Niemi                  Expires December 28, 2003               [Page 26]

Internet-Draft          SIP Presence Publication               June 2003
      readability

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

   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



Niemi                    Expires March 9, 2004                 [Page 28]

Internet-Draft        SIP Event State Publication         September 2003


      OPTIONS and "methods" parameter usage.

Normative References

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

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

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

   [4]

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

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

   [6]  Fujimoto, S. and H. Sugano, "Common

Informative References

   [4]   Campbell, B., "SIMPLE Presence and Instant
        Messaging (CPIM)Presence Information Data  Format",
        draft-ietf-impp-cpim-pidf-07 Publication Requirements",
         draft-ietf-simple-publish-reqs-00 (work in progress), January February
         2003.

Informative References

   [7]

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

   [8]

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

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

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

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



Niemi                  Expires December 28, 2003               [Page 27]

Internet-Draft          SIP Presence Publication               June 2003

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









Niemi                    Expires March 9, 2004                 [Page 29]

Internet-Draft        SIP Event State Publication         September 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 December 28, 2003 March 9, 2004                 [Page 28] 30]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


Intellectual Property Statement

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

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


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   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 December 28, 2003 March 9, 2004                 [Page 29] 31]

Internet-Draft        SIP Presence Event State Publication               June         September 2003


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


Acknowledgement

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











































Niemi                    Expires December 28, 2003 March 9, 2004                 [Page 30] 32]

----