doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc3903.txt b/doc/rfc/rfc3903.txt
new file mode 100644
index 0000000..21a425f
--- /dev/null
+++ b/doc/rfc/rfc3903.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                      A. Niemi, Ed.
+Request for Comments: 3903                                         Nokia
+Category: Standards Track                                   October 2004
+
+
+              Session Initiation Protocol (SIP) Extension
+                      for Event State Publication
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document describes an extension to the Session Initiation
+   Protocol (SIP) for publishing event state used within the SIP 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 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.
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.   Definitions and Document Conventions . . . . . . . . . . . .   3
+   3.   Overall Operation  . . . . . . . . . . . . . . . . . . . . .   4
+   4.   Constructing PUBLISH Requests  . . . . . . . . . . . . . . .   5
+        4.1.  Identification of Published Event State. . . . . . . .   6
+        4.2.  Creating Initial Publication . . . . . . . . . . . . .   7
+        4.3.  Refreshing Event State . . . . . . . . . . . . . . . .   8
+        4.4.  Modifying Event State  . . . . . . . . . . . . . . . .   9
+        4.5.  Removing Event State . . . . . . . . . . . . . . . . .   9
+   5.   Processing PUBLISH Responses . . . . . . . . . . . . . . . .  10
+   6.   Processing PUBLISH Requests  . . . . . . . . . . . . . . . .  10
+   7.   Processing OPTIONS Requests  . . . . . . . . . . . . . . . .  13
+   8.   Use of Entity-tags in PUBLISH  . . . . . . . . . . . . . . .  13
+
+
+
+Niemi                       Standards Track                     [Page 1]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+        8.1.  General Notes. . . . . . . . . . . . . . . . . . . . .  13
+        8.2.  Client Usage . . . . . . . . . . . . . . . . . . . . .  14
+        8.3.  Server Usage . . . . . . . . . . . . . . . . . . . . .  14
+   9.   Controlling the Rate of Publication  . . . . . . . . . . . .  15
+   10.  Considerations for Event Packages using PUBLISH  . . . . . .  15
+        10.1. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . .  16
+        10.2. PUBLISH Response Bodies. . . . . . . . . . . . . . . .  16
+        10.3. Multiple Sources for Event State . . . . . . . . . . .  16
+        10.4. Event State Segmentation . . . . . . . . . . . . . . .  17
+        10.5. Rate of Publication. . . . . . . . . . . . . . . . . .  17
+   11.  Protocol Element Definitions . . . . . . . . . . . . . . . .  17
+        11.1. New Methods. . . . . . . . . . . . . . . . . . . . . .  17
+              11.1.1. PUBLISH Method . . . . . . . . . . . . . . . .  17
+        11.2. New Response Codes . . . . . . . . . . . . . . . . . .  19
+              11.2.1. "412 Conditional Request Failed" Response Code  19
+        11.3. New Header Fields  . . . . . . . . . . . . . . . . . .  20
+              11.3.1. "SIP-ETag" Header Field  . . . . . . . . . . .  20
+              11.3.2. "SIP-If-Match" Header Field  . . . . . . . . .  20
+   12.  Augmented BNF Definitions  . . . . . . . . . . . . . . . . .  21
+   13.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  21
+        13.1. Methods  . . . . . . . . . . . . . . . . . . . . . . .  21
+        13.2. Response Codes . . . . . . . . . . . . . . . . . . . .  21
+        13.3. Header Field Names . . . . . . . . . . . . . . . . . .  21
+   14.  Security Considerations  . . . . . . . . . . . . . . . . . .  22
+        14.1. Access Control . . . . . . . . . . . . . . . . . . . .  22
+        14.2. Denial of Service Attacks  . . . . . . . . . . . . . .  22
+        14.3. Replay Attacks . . . . . . . . . . . . . . . . . . . .  22
+        14.4. Man in the Middle Attacks  . . . . . . . . . . . . . .  23
+        14.5. Confidentiality  . . . . . . . . . . . . . . . . . . .  23
+   15.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  24
+   16.  Contributors . . . . . . . . . . . . . . . . . . . . . . . .  29
+   17.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  30
+   18.  References . . . . . . . . . . . . . . . . . . . . . . . . .  30
+        18.1. Normative References . . . . . . . . . . . . . . . . .  30
+        18.2. Informative References . . . . . . . . . . . . . . . .  31
+   Author's Address. . . . . . . . . . . . . . . . . . . . . . . . .  31
+   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .  32
+
+1.  Introduction
+
+   This specification 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 [1] framework.
+
+
+
+
+
+
+
+Niemi                       Standards Track                     [Page 2]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   In addition to defining an event publication framework, this
+   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 [1].
+
+   The requirements and model for presence publication are documented in
+   [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 for which there exists an appropriate
+   event package as defined in [1].  For instance, an application of SIP
+   events for message waiting indications [11] might choose to collect
+   the statuses of voice-mail boxes across a set of user agents using
+   the PUBLISH mechanism.  The compositor in such an application would
+   then be responsible for collecting and distributing this state to the
+   subscribers of the event package.
+
+   Each application that makes use of the PUBLISH mechanism in the
+   publication of event state will need to adhere to the guidelines set
+   in Section 10.  The mechanism described in this document is not
+   intended to be a general-purpose mechanism for transport of arbitrary
+   data, as there are better-suited mechanisms for this purpose.
+
+2.  Definitions and Document Conventions
+
+   In addition to the definitions of RFC 2778 [3], RFC 3265 [1], and RFC
+   3261 [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 User Agent Client (UAC) that
+      issues PUBLISH requests to publish event state.
+
+   Event State Compositor (ESC): The User Agent Server (UAS) that
+      processes PUBLISH requests, and is responsible 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, soft state publications.
+
+
+
+Niemi                       Standards Track                     [Page 3]
+
+RFC 3903              SIP Event State Publication           October 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 soft state entity at 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 BCP 14, RFC 2119 [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 User Agents or endpoints that publish event state.
+   Each endpoint may publish its own unique state, out of which the
+   event 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.
+
+   A User Agent Client (UAC) that publishes event state is labeled an
+   Event Publication Agent (EPA).  For presence, this is the familiar
+   Presence User Agent (PUA) role as defined in [2].  The entity that
+   processes the PUBLISH request is known as an Event State Compositor
+   (ESC).  For presence, this is the familiar Presence Agent (PA) role
+   as defined in [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.  There may also be event hard state provisioned for each
+   resource for a particular event package.  This event state represents
+   the resource state that is present at all times, and does not expire.
+   The ESC may use event hard state in the absence of, or in addition
+   to, event soft state provided through the PUBLISH mechanism.  Setting
+
+
+
+
+Niemi                       Standards Track                     [Page 4]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   this event hard state or configuring the ESC policy regarding the
+   aggregation of different event state is out of the scope of this
+   specification.
+
+   The body of a PUBLISH request carries the published event state.  In
+   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 publication for an
+   invalid entity-tag will naturally fail, and the EPA needs to start
+   anew and resend its event state without referencing a previous
+   entity-tag.
+
+4.  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.
+
+   Except as noted, the construction of the PUBLISH request and the
+   behavior of clients sending a PUBLISH request are identical to the
+   general UAC behavior described in Section 8.1 and Section 17.1 of RFC
+   3261 [4].
+
+   If necessary, clients may probe for the support of PUBLISH using the
+   OPTIONS request defined in SIP [4].  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.
+
+      Note that it is possible for the OPTIONS request to fork, and
+      consequently return a response from a User Agent other than the
+      ESC.  In that case, support for the PUBLISH method may not be
+      appropriately represented for that particular Request-URI.
+
+   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 RFC 3261 [4].  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 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
+
+
+
+Niemi                       Standards Track                     [Page 5]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   request within an existing dialog.  In that case, the request is
+   received in the context of any media session or sessions associated
+   with that dialog.
+
+      Note that while sending a PUBLISH request within an existing
+      dialog is not prohibited, it will typically not result in the
+      expected behavior.  Unless the other end of the dialog is also an
+      ESC, 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 a final response from
+   the ESC for the previous one or the previous PUBLISH request has
+   timed out.
+
+4.1.  Identification of Published Event State
+
+   Identification of published event state is provided by three pieces
+   of 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 RFC 3261 [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.
+
+   For determining the type of the published event state, the EPA MUST
+   include a single Event header field in PUBLISH requests.  The value
+   of this header field indicates the event package for which this
+   request is publishing event state.
+
+   For each successful PUBLISH request, the ESC will generate and assign
+   an entity-tag and return it in the SIP-ETag header field of the 2xx
+   response.
+
+   When updating previously published event state, PUBLISH requests MUST
+   contain a single SIP-If-Match header field identifying the specific
+   event state that the request is refreshing, modifying or removing.
+   This header field MUST contain a single entity-tag that was returned
+   by the ESC in the SIP-ETag header field of the response to a previous
+   publication.
+
+   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
+   field.
+
+
+
+
+Niemi                       Standards Track                     [Page 6]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   The presence of a body and the SIP-If-Match header field determine
+   the specific operation that the request is performing, as described
+   in 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. There may, of course, already be event state
+   published by other EPAs (for the same address-of-record). That state
+   is unaffected by an initial publication.  A 'Refresh' publication
+   refreshes the lifetime of a previous publication, whereas a 'Modify'
+   publication modifies the event state of a previous publication.  A
+   'Remove' publication requests immediate removal of event state.
+   These operations are described in more detail in the following
+   sections.
+
+4.2.  Creating Initial Publication
+
+   An initial publication is a PUBLISH request created by the EPA and
+   sent to the ESC that establishes soft state for the event package
+   indicated in the Event header field of the request, and bound to the
+   address in the Request-URI of the request.
+
+   An initial PUBLISH request MUST NOT contain a SIP-If-Match header
+   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 4.4, instead of submitting an
+   initial publication.
+
+   An initial PUBLISH request MUST contain a body that contains the
+   published event state.
+
+   An initial PUBLISH request MAY contain a single Expires header field.
+   This value indicates the suggested lifetime of the event state
+   publication.
+
+
+
+
+
+
+
+Niemi                       Standards Track                     [Page 7]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   The ESC may lower the suggested lifetime of the publication, but it
+   will never extend it.  If an Expires header field is not present, the
+   EPA is indicating its desire for the ESC to choose.  The Expires
+   header field in a 2xx response to the initial PUBLISH indicates the
+   actual duration for which the publication will remain active.  Unless
+   refreshed before this lifetime is exceeded, the publication will
+   expire.
+
+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 that
+   includes in a SIP-If-Match header field the entity-tag of the
+   publication to be refreshed.
+
+   The SIP-If-Match header field containing an entity-tag conditions the
+   PUBLISH request to refresh a specific event state established by a
+   prior publication.  If the entity-tag matches previously published
+   event state at the ESC, the refresh succeeds, and the EPA receives a
+   2xx response.
+
+   Like the 2xx response to an initial PUBLISH request, the 2xx response
+   to a refresh PUBLISH request will contain a SIP-ETag header field
+   with an entity-tag.  The EPA MUST store this entity-tag, replacing
+   any existing entity-tag for the refreshed event state.  See Section
+   8.2 for more information on the EPA handling of entity-tags.
+
+   If there is no matching event state, e.g., the event state to be
+   refreshed has already expired, the EPA receives a 412 (Conditional
+   Request Failed) response to the PUBLISH request.
+
+   A publication refresh MAY contain a single Expires header field.
+   This value indicates the suggested lifetime of the event state.
+
+   The ESC may lower the suggested lifetime of the publication refresh,
+   but it will never extend it.  If an Expires header field is not
+   present, the EPA is indicating its desire for the ESC to choose.  The
+   Expires header field in a 2xx response to the publication refresh
+   indicates the actual duration for 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 in any
+   other way.  Therefore, a PUBLISH request that refreshes event state
+   MUST NOT have a body.
+
+
+
+
+
+Niemi                       Standards Track                     [Page 8]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+4.4.  Modifying Event State
+
+   Modifying event state closely resembles the creation of initial event
+   state.  However, instead of establishing completely new event state
+   at the ESC, already existing event state is updated with modified
+   event state.  The nature of this update depends on the content of the
+   body, and the semantics associated with the format of that body.
+
+   To modify event state, the EPA MUST construct a PUBLISH request that
+   includes in a SIP-If-Match header field the entity-tag of the event
+   state publication to be modified.  A PUBLISH request that modifies
+   event state MUST contain a body that includes the modified event
+   state.
+
+   The SIP-If-Match header field conditions the PUBLISH request to
+   modify a specific event state established by a prior publication, and
+   identified by the entity-tag.  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 contain a SIP-ETag header field
+   with an entity-tag.  The EPA MUST store this entity-tag, replacing
+   any existing entity-tag for the modified event state.  See Section
+   8.2 for more information on the EPA handling of entity-tags.
+
+   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
+   (Conditional Request Failed) response to the PUBLISH request.
+
+   A modifying PUBLISH request MAY contain a single Expires header
+   field.  This value indicates the suggested lifetime of the event
+   state publication.
+
+   The ESC may lower the suggested lifetime of the publication, but it
+   will never extend it.  If an Expires header field is not present, the
+   EPA is indicating its desire for the ESC to choose.  The Expires
+   header field in a 2xx response to the modifying PUBLISH request
+   indicates the actual duration for which the publication will remain
+   active.  Unless refreshed before this lifetime is exceeded, the
+   publication will expire.
+
+4.5.  Removing Event State
+
+   Event state established by a prior publication may also be explicitly
+   removed.
+
+
+
+
+Niemi                       Standards Track                     [Page 9]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   To request the immediate removal of event state, an EPA MUST create a
+   PUBLISH request 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 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.
+
+   Similar to an event state refresh, the removal of event state only
+   affects the expiry of the event state.  Therefore, a PUBLISH request
+   that removes event state MUST NOT contain a body.
+
+5.  Processing PUBLISH Responses
+
+   When processing responses to PUBLISH requests, the steps in Section
+   8.1.2 of RFC 3261 [4] apply.
+
+   If an EPA receives a 412 (Conditional Request Failed) response, it
+   MUST NOT reattempt the PUBLISH request.  Instead, to publish event
+   state, the EPA SHOULD perform an initial publication, i.e., a PUBLISH
+   request without a SIP-If-Match header field, as described in Section
+   4.2.  The EPA MUST also discard the entity-tag that produced this
+   error response.
+
+   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 field to be equal to or greater than
+   the expiration interval within the Min-Expires header field of the
+   423 (Interval Too Brief) response.
+
+6.  Processing PUBLISH Requests
+
+   The Event State Compositor (ESC) is a User Agent Server (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
+   (e.g., through configuration) the set of addresses 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.  The ESC MUST ignore the
+   Contact header field if one is present in a PUBLISH request.
+
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 10]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   PUBLISH requests with the same Request-URI 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.
+
+   When receiving a PUBLISH request, the ESC follows the 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 determine whether this request
+      is targeted to a resource for which the ESC is responsible for
+      maintaining event state.  If not, the ESC MUST return a 404 (Not
+      Found) response and skip the remaining steps.
+
+      It may also be that the Request-URI points to a domain that the
+      ESC is not responsible for.  In that case, the UAS receiving the
+      request can assume the role of a proxy server and forward the
+      request to a more appropriate target.
+
+   2. 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, and skip the
+      remaining steps.
+
+   3. The ESC examines the SIP-If-Match header field of the PUBLISH
+      request for the presence of a request precondition.
+
+      *  If the request does not contain a SIP-If-Match header field,
+         the ESC MUST generate and store a locally unique entity-tag for
+         identifying the publication.  This entity-tag is associated
+         with the event-state carried in the body of the PUBLISH
+         request.
+
+      *  Else, if the request has a SIP-If-Match header field, the ESC
+         checks whether the header field contains a single entity-tag.
+         If not, the request is invalid, and the 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 (Conditional Request Failed), and skip the
+         remaining steps.
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 11]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   4. The ESC processes the Expires header field value from the PUBLISH
+      request.
+
+      *  If the request has an Expires header field, that value MUST be
+         taken as the requested expiration.
+
+      *  Else, a locally-configured default value MUST be taken as the
+         requested expiration.
+
+      *  The ESC MAY choose an expiration less than the requested
+         expiration interval.  Only if the requested expiration interval
+         is greater than zero and less than a locally-configured
+         minimum, the ESC MAY reject the publication with a response of
+         423 (Interval Too Brief), and skip the remaining steps.  This
+         response MUST contain a Min-Expires header field that states
+         the minimum expiration interval the ESC is willing to honor.
+
+   5. The ESC processes the published event state contained in the body
+      of the PUBLISH request.  If 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, such as
+      415 (Unsupported Media Type), and skip the remainder of the steps.
+
+      *  The ESC stores the event state delivered in the body of the
+         PUBLISH request and identified by the associated entity-tag,
+         updating any existing event state for that entity-tag.  The
+         expiration value is set to the chosen expiration interval.
+
+      *  If the request has no message body and contained no entity-tag,
+         the ESC SHOULD reject the request with an appropriate response,
+         such as 400 (Invalid Request), and skip the remainder of the
+         steps.  Alternatively, in case either ESC local policy or the
+         event package has defined semantics for an initial publication
+         containing no message body, the ESC MAY accept it.
+
+      *  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
+         immediately removed.  The ESC MUST NOT store any event state as
+         a result of such a request.
+
+
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 12]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+      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 an appropriate error response, such as
+      504 (Server Time-out), and skip the last step.
+
+   6. The ESC returns a 200 (OK) response.  The response MUST contain an
+      Expires header field indicating the expiration interval chosen by
+      the ESC.  The response MUST also contain a SIP-ETag header field
+      that contains a single entity-tag identifying the publication.
+      The ESC MUST generate a new entity-tag for each successful
+      publication, replacing any previous entity-tag associated with
+      that event state. The generated entity-tag MUST be unique from any
+      other entity-tags currently assigned to event state associated
+      with that Request-URI, and MUST be different from any entity-tag
+      assigned previously to event state for that Request-URI.  See
+      Section 8.3 for more information on the ESC handling of entity-
+      tags.
+
+7.  Processing OPTIONS Requests
+
+   A client may probe the ESC for the support of PUBLISH using the
+   OPTIONS request defined in SIP [4].  The ESC processes OPTIONS
+   requests as defined in Section 11.2 of RFC 3261 [4].  In the response
+   to an OPTIONS request, the ESC SHOULD include "PUBLISH" to the list
+   of allowed methods in the Allow header field.  Also, it SHOULD list
+   the supported event packages in an Allow-Events header field.
+
+   The Allow header field may also be used to specifically announce
+   support for PUBLISH messages when registering.  (See SIP Capabilities
+   [12] for details).
+
+8.  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.
+
+8.1.  General Notes
+
+   The PUBLISH mechanism makes use of entity-tags, as defined in HTTP/
+   1.1 [13].  While the main functionality is preserved, the syntax and
+   semantics for entity-tags and the corresponding header fields is
+   adapted specifically for use with the PUBLISH method.  The main
+   differences are:
+
+   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.
+
+
+
+Niemi                       Standards Track                    [Page 13]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   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 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, replacing any previous
+   entity-tag for that event state.  If a request fails with a 412
+   (Conditional Request 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
+   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 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.
+
+
+
+
+Niemi                       Standards Track                    [Page 14]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   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 an entity responsible for aggregating 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 RFC 3261 [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
+   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.
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 15]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+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 Common Profile for
+   Presence (CPP) Presence Information Data Format (PIDF) [6] is used.
+   A PUA that uses PUBLISH to publish presence state to the PA MUST
+   support the 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 a presence
+   publication.
+
+10.3.  Multiple Sources for Event State
+
+   For some event packages, the underlying model is that of a single
+   entity responsible for aggregating event state (ESC), and multiple
+   sources, out of which only some may be using the PUBLISH mechanism.
+
+      Note that sources for event state other than those using the
+      PUBLISH mechanism are explicitly allowed.  However, it is beyond
+      the scope of this document to define such interfaces.
+
+   Event packages that make use of the PUBLISH mechanism SHOULD describe
+   whether this model for event state publication is applicable, and MAY
+   describe specific mechanisms used for aggregating publications from
+   multiple sources.
+
+   For presence, a PUA can publish presence state for just a subset of
+   the tuples that may be composited 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 and out of
+   the scope of this specification.
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 16]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+10.4.  Event State Segmentation
+
+   For some event packages, there exists a natural decomposition of
+   event state into segments.  Each segment is defined as one of
+   potentially many identifiable sections in the published event state.
+   Any event package whose content type supports such segmentation of
+   event state, SHOULD describe the way in which these event state
+   segments are identified by the ESC.
+
+   In presence publication, the EPA MUST keep the "id" attributes of
+   tuples consistent in the context of an entity-tag.  If a publication
+   modifies the contents of a tuple, that tuple MUST maintain its
+   original "id".  The ESC will interpret each tuple in the context of
+   the entity-tag with which the request arrived.  A tuple whose "id" is
+   missing compared to 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.
+
+10.5.  Rate of Publication
+
+   Controlling the rate of publication is discussed in Section 9.
+   Individual event packages MAY 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 presence publication.
+
+11.  Protocol Element Definitions
+
+   This section describes the extensions required for event publication
+   in SIP.
+
+11.1.  New Methods
+
+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
+   entity responsible for compositing this event state.
+
+   Table 2 and Table 3 extend Tables 2 and 3 of RFC 3261 [4] by adding
+   an additional column, defining the header fields that can be used in
+   PUBLISH requests and responses.  The keys in these tables are
+   specified in Section 20 of RFC 3261 [4].
+
+
+
+
+
+Niemi                       Standards Track                    [Page 17]
+
+RFC 3903              SIP Event State Publication           October 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               |    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                       Standards Track                    [Page 18]
+
+RFC 3903              SIP Event State Publication           October 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
+
+11.2.  New Response Codes
+
+11.2.1.  "412 Conditional Request Failed" Response Code
+
+   The 412 (Conditional Request Failed) response is added to the
+   "Client-Error" header field definition.  412 (Conditional Request
+   Failed) is used to indicate that the precondition given for the
+   request has failed.
+
+
+
+
+
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 19]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+11.3.  New Header Fields
+
+   Table 4, Table 5, and Table 6 expand on Table 3 in SIP [4], as
+   amended by the changes in Section 11.1.
+
+   +--------------+-------+-------+-----+-----+-----+-----+-----+
+   | 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 | NOT | OPT | PRA | REG | SUB |
+   +--------------+-------+-------+-----+-----+-----+-----+-----+
+   | SIP-ETag     |  2xx  |       |  -  |  -  |  -  |  -  |  -  |
+   | SIP-If-Match |   R   |       |  -  |  -  |  -  |  -  |  -  |
+   +--------------+-------+-------+-----+-----+-----+-----+-----+
+
+              Table 5: Summary of header fields, P--Z
+
+    +--------------+-------+-------+-----+-----+-----+---------+
+    | Header Field | where | proxy | UPD | MSG | REF | PUBLISH |
+    +--------------+-------+-------+-----+-----+-----+---------+
+    | SIP-ETag     |  2xx  |       |  -  |  -  |  -  |    m    |
+    | SIP-If-Match |   R   |       |  -  |  -  |  -  |    o    |
+    +--------------+-------+-------+-----+-----+-----+---------+
+
+              Table 6: Summary of header fields, P--Z
+
+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 4 and Section 6.
+
+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 4 and Section 6.
+
+
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 20]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+12.  Augmented BNF 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 [7] format used in SIP
+   [4], and contain references to elements defined therein.
+
+      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
+
+13.  IANA Considerations
+
+   This document registers a new method name, a new response code and
+   two new header field names.
+
+13.1.  Methods
+
+   This document registers a new SIP method, defined by the following
+   information, which has been added to the method and response-code
+   sub-registry under http://www.iana.org/assignments/sip-parameters.
+
+      Method Name:   PUBLISH
+      Reference:     [RFC3903]
+
+13.2.  Response Codes
+
+   This document registers a new response code.  This response code is
+   defined by the following information, which has been added to the
+   method and response-code sub-registry under
+   http://www.iana.org/assignments/sip-parameters.
+
+      Response Code Number:   412
+      Default Reason Phrase:  Conditional Request Failed
+
+13.3.  Header Field Names
+
+   This document registers two new SIP header field names.  These
+   headers are defined by the following information, which has been
+   added to the header sub-registry under
+   http://www.iana.org/assignments/sip-parameters.
+
+      Header Name:    SIP-ETag
+      Compact Form:   (none)
+
+
+
+
+
+Niemi                       Standards Track                    [Page 21]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+      Header Name:    SIP-If-Match
+      Compact Form:   (none)
+
+14.  Security Considerations
+
+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.
+
+   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.
+
+   ESCs and EPAs MUST implement Digest for authenticating PUBLISH
+   requests, as defined in RFC 3261 [4].  The exact methods for creating
+   and manipulating access control policies in the ESC are outside the
+   scope of this document.
+
+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.  Implementations
+   MUST support Digest authentication, as defined in 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.
+
+14.3.  Replay Attacks
+
+   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
+
+
+
+Niemi                       Standards Track                    [Page 22]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   be used to 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 MUST support Digest
+   authentication with replay protection, as defined in RFC 3261 [4].
+   Further mechanisms for countering replay attacks are discussed in SIP
+   [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
+   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 header fields 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.
+
+   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
+   initiating TLS and SHOULD support the SIPS URI scheme.  ESCs and EPAs
+   MAY support S/MIME [9] for integrity protection, as defined in SIP
+   [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.
+
+   For providing 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 [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                       Standards Track                    [Page 23]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+15.  Examples
+
+   This section shows an example of using the PUBLISH method for
+   publishing a presence document from a presence user agent to a
+   presence agent.  The watcher in this example is subscribing to the
+   presentity's presence information from the PA.  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.
+
+   When the value of the Content-Length header field is "..." this means
+   that the value should be whatever the computed length of the body is.
+
+          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 ----- |
+           |                       |                         |
+
+
+
+
+
+Niemi                       Standards Track                    [Page 24]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+   Message flow:
+
+   M1: The watcher initiates a new subscription to the
+      presentity@example.com's presence agent.
+
+      SUBSCRIBE sip:presentity@example.com SIP/2.0
+      Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
+      To: <sip:presentity@example.com>
+      From: <sip:watcher@example.com>;tag=12341234
+      Call-ID: 12345678@host.example.com
+      CSeq: 1 SUBSCRIBE
+      Max-Forwards: 70
+      Expires: 3600
+      Event: presence
+      Contact: 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 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@host.example.com
+      CSeq: 1 SUBSCRIBE
+      Contact: 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.
+
+      NOTIFY 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@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: ...
+
+
+
+Niemi                       Standards Track                    [Page 25]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+      [PIDF document]
+
+   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@host.example.com
+      CSeq: 1 NOTIFY
+
+   M5: A presence user agent (acting for the presentity) initiates a
+       PUBLISH request to the presence agent in order to update it with
+       new presence information.  The Expires header field indicates the
+       suggested duration for this event soft state.
+
+      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: ...
+
+      [Published PIDF document]
+
+   M6: The presence agent receives, and accepts the presence
+      publication.  The published data is incorporated into the
+      presentity's presence information.
+
+      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 information, and sends a
+      new presence notification to the watcher.
+
+
+
+Niemi                       Standards Track                    [Page 26]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+      NOTIFY sip:user@host.example.com SIP/2.0
+      Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
+      To: <sip:watcher@example.com>;tag=12341234
+      From: <sip:presentity@example.com>;tag=abcd1234
+      Call-ID: 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: ...
+
+      [New PIDF document]
+
+   M8: The watcher confirms receipt of the NOTIFY request.
+
+      SIP/2.0 200 OK
+      Via: SIP/2.0/UDP 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@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.
+
+      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 occurred, so the
+      watchers will receive no NOTIFYs.
+
+
+
+
+Niemi                       Standards Track                    [Page 27]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+      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.
+
+      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: ...
+
+      [Published PIDF Document]
+
+   M12: The presence agent receives, and accepts the modifying
+       publication.  The published data is incorporated into the
+       presentity's presence information, updating the previous
+       publication from the same PUA.
+
+      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 a
+       new presence notification to all active subscriptions.
+
+
+
+Niemi                       Standards Track                    [Page 28]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+      NOTIFY sip:user@host.example.com SIP/2.0
+      Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3
+      To: <sip:watcher@example.com>;tag=12341234
+      From: <sip:presentity@example.com>;tag=abcd1234
+      Call-ID: 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: ...
+
+      [New PIDF document]
+
+   M14: The watcher confirms receipt of the NOTIFY request.
+
+      SIP/2.0 200 OK
+      Via: SIP/2.0/UDP 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@host.example.com
+      CSeq: 2 NOTIFY
+      Content-Length: 0
+
+16.  Contributors
+
+   The original contributors to this specification are:
+
+      Ben Campbell
+      Estacado Systems
+
+      Sean Olson
+      Microsoft
+
+      Jon Peterson
+      Neustar, Inc.
+
+      Jonathan Rosenberg
+      dynamicsoft
+
+      Brian Stucker
+      Nortel Networks, Inc.
+
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 29]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+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.  References
+
+18.1.  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)", RFC 3856, August 2004.
+
+   [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.
+
+   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [6]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
+        J.  Peterson, "Presence Information Data Format (PIDF)", RFC
+        3863, August 2004.
+
+   [7]  Crocker, D., Ed. 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., Ed., "Secure/Multipurpose Internet Mail Extensions
+        (S/MIME) Version 3.1 Message Specification", RFC 3851, July
+        2004.
+
+
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 30]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+19.2.  Informative References
+
+   [10] Campbell, B., "SIMPLE Presence Publication Requirements", Work
+        in Progress, February 2003.
+
+   [11] Mahy, R., "A Message Summary and Message Waiting Indication
+        Event Package for the  Session Initiation Protocol (SIP)", RFC
+        3842, August 2004.
+
+   [12] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
+        Agent Capabilities in the Session Initiation Protocol (SIP)",
+        RFC 3840, August 2004.
+
+   [13] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+        Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
+        HTTP/1.1", RFC 2616, June 1999.
+
+Author's Address
+
+   Aki Niemi (editor)
+   Nokia
+   P.O. Box 407
+   NOKIA GROUP, FIN  00045
+   Finland
+
+   Phone: +358 50 389 1644
+   EMail: aki.niemi@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 31]
+
+RFC 3903              SIP Event State Publication           October 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Niemi                       Standards Track                    [Page 32]
+