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.
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.
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)
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
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].
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 ----- |
| | |
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: ...
[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.
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.
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.
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.
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.
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.,