rfc3903 session initiation protocol (sip) extension.txt

有关IMS SIP及Presence应用的RFC文档包

   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.