rfc3903 session initiation protocol (sip) extension.txt

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

   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