< draft-ietf-sipcore-event-rate-control-03.txt   draft-ietf-sipcore-event-rate-control-04.txt >
Network Working Group A. Niemi Network Working Group A. Niemi
Internet-Draft K. Kiss Internet-Draft K. Kiss
Intended status: Standards Track Nokia Intended status: Standards Track Nokia
Expires: August 26, 2010 S. Loreto Expires: January 10, 2011 S. Loreto
Ericsson Ericsson
February 22, 2010 July 09, 2010
Session Initiation Protocol (SIP) Event Notification Extension for Session Initiation Protocol (SIP) Event Notification Extension for
Notification Rate Control Notification Rate Control
draft-ietf-sipcore-event-rate-control-03 draft-ietf-sipcore-event-rate-control-04
Abstract Abstract
This document specifies mechanisms for adjusting the rate of Session This document specifies mechanisms for adjusting the rate of Session
Initiation Protocol (SIP) event notifications. These mechanisms can Initiation Protocol (SIP) event notifications. These mechanisms can
be applied in subscriptions to all SIP event packages. be applied in subscriptions to all SIP event packages.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 10, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions and Document Conventions . . . . . . . . . . . . . 5 2. Definitions and Document Conventions . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Use Case for limiting the maximum rate of notifications . 5 3.1. Use Case for limiting the maximum rate of notifications . 5
3.2. Use Case for setting a minimum rate for notifications . . 6 3.2. Use Case for setting a minimum rate for notifications . . 6
3.3. Use Case for specifying the average rate of 3.3. Use Case for specifying the average rate of
notifications . . . . . . . . . . . . . . . . . . . . . . 7 notifications . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. The maximum rate mechanism for Resource List Server . . . 8 3.5. The maximum rate mechanism for Resource List Server . . . 8
3.6. Basic Operation . . . . . . . . . . . . . . . . . . . . . 10 3.6. Basic Operation . . . . . . . . . . . . . . . . . . . . . 10
4. Operation of the maximum rate mechanism . . . . . . . . . . . 11 4. Operation of the maximum rate mechanism . . . . . . . . . . . 11
4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 11 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 11
4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 12 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 11
4.3. Selecting the maximum rate . . . . . . . . . . . . . . . . 12 4.3. Selecting the maximum rate . . . . . . . . . . . . . . . . 12
4.4. Buffer Policy Description . . . . . . . . . . . . . . . . 13 4.4. Buffer Policy Description . . . . . . . . . . . . . . . . 13
4.4.1. Partial State Notifications . . . . . . . . . . . . . 13 4.4.1. Partial State Notifications . . . . . . . . . . . . . 13
4.4.2. Full State Notifications . . . . . . . . . . . . . . . 14 4.4.2. Full State Notifications . . . . . . . . . . . . . . . 14
4.5. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 14 4.5. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 14
5. Operation of the minimum rate mechanism . . . . . . . . . . . 15 5. Operation of the minimum rate mechanism . . . . . . . . . . . 14
5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 15 5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 15
5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 15 5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 15
6. Operation of the average rate mechanism . . . . . . . . . . . 16 6. Operation of the average rate mechanism . . . . . . . . . . . 16
6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 16 6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 16
6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17 6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17
6.3. Calculating the timeout . . . . . . . . . . . . . . . . . 18 6.3. Calculating the timeout . . . . . . . . . . . . . . . . . 18
7. Usage of "min-interval", "max-interval" and 7. Usage of "min-interval", "max-interval" and
"average-interval" in a combination . . . . . . . . . . . . . 19 "average-interval" in a combination . . . . . . . . . . . . . 19
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. "min-interval", "max-interval" and "average-interval" 8.1. "min-interval", "max-interval" and "average-interval"
Header Field Parameters . . . . . . . . . . . . . . . . . 20 Header Field Parameters . . . . . . . . . . . . . . . . . 20
8.2. Augmented BNF Definitions . . . . . . . . . . . . . . . . 20 8.2. Augmented BNF Definitions . . . . . . . . . . . . . . . . 20
8.3. Event header field usage in responses to the NOTIFY 8.3. Event header field usage in responses to the NOTIFY
request . . . . . . . . . . . . . . . . . . . . . . . . . 20 request . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The SIP events framework [RFC3265] defines a generic framework for The SIP events framework [RFC3265] defines a generic framework for
subscriptions to and notifications of events related to SIP systems. subscriptions to and notifications of events related to SIP systems.
This framework defines the methods SUBSCRIBE and NOTIFY, and This framework defines the methods SUBSCRIBE and NOTIFY, and
introduces the concept of an event package, which is a concrete introduces the concept of an event package, which is a concrete
application of the SIP events framework to a particular class of application of the SIP events framework to a particular class of
events. events.
One of the things the SIP events framework mandates is that each One of the things the SIP events framework mandates is that each
event package specification defines an absolute maximum on the rate event package specification defines an absolute maximum on the rate
at which notifications are allowed to be generated by a single at which notifications are allowed to be generated by a single
notifier. Such a limit is provided in order to reduce network notifier. Such a limit is provided in order to reduce network load.
congestion.
All of the existing event package specifications include a maximum All of the existing event package specifications include a maximum
notification rate recommendation, ranging from once in every five notification rate recommendation, ranging from once in every five
seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842]. seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842].
Per the SIP events framework, each event package specification is Per the SIP events framework, each event package specification is
also allowed to define additional throttle mechanisms which allow the also allowed to define additional throttle mechanisms which allow the
subscriber to further limit the rate of event notification. So far subscriber to further limit the rate of event notification. So far
none of the event package specifications have defined such a none of the event package specifications have defined such a
mechanism. mechanism.
skipping to change at page 5, line 12 skipping to change at page 5, line 12
min-interval: specifies a minimum notification time period between min-interval: specifies a minimum notification time period between
two notifications, in seconds. two notifications, in seconds.
max-interval: specifies a maximum notification time period between max-interval: specifies a maximum notification time period between
two notifications, in seconds. two notifications, in seconds.
average-interval: specifies an average cadence at which average-interval: specifies an average cadence at which
notifications are desired, in seconds. notifications are desired, in seconds.
The requirements and model are further discussed in Section 3. All The requirements and model are further discussed in Section 3. All
those mechanisms are simply timer values that indicates the minimum, these mechanisms are simply timer values that indicate the minimum,
maximum and average time period allowed between two notifications. maximum and average time period allowed between two notifications.
As a result of those mechanism, a compliant notifier will adjust the As a result of these mechanisms, a compliant notifier will adjust the
rate at which it generates notifications. rate at which it generates notifications.
These mechanisms are applicable to any event subscription, both These mechanisms are applicable to any event subscription, both
single event subscription and event list subscription. single event subscription and event list subscription.
2. Definitions and Document Conventions 2. Definitions and Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119] and
skipping to change at page 6, line 6 skipping to change at page 6, line 6
sets a maximum rate ("min-interval" parameter), i.e. a minimum time sets a maximum rate ("min-interval" parameter), i.e. a minimum time
interval between two notifications. Alternatively, the presence interval between two notifications. Alternatively, the presence
client could set the maximum rate for the resource list via a list client could set the maximum rate for the resource list via a list
manipulation interface, e.g., using the XML Configuration Access manipulation interface, e.g., using the XML Configuration Access
Protocol (XCAP) [RFC4825]. Protocol (XCAP) [RFC4825].
The RLS will buffer notifications that do not comply with the maximum The RLS will buffer notifications that do not comply with the maximum
rate and batch all of the buffered state changes together in a single rate and batch all of the buffered state changes together in a single
notification only when allowed by the maximum rate. The maximum rate notification only when allowed by the maximum rate. The maximum rate
applies to the overall resource list, which means that there is a applies to the overall resource list, which means that there is a
hard cap imposed by the maximum rate to the amount of traffic the hard cap imposed by the maximum rate to the number of notifications
presence client can expect to receive. the presence client can expect to receive.
For example, with a "min-interval" of 20 seconds, the presence For example, with a "min-interval" of 20 seconds, the presence
application can expect to receive a notification at a minimum of application can expect to receive a notification at a minimum of
every 20 seconds. every 20 seconds.
The presence client can also modify the "min-interval" parameter The presence client can also modify the "min-interval" parameter
during the lifetime of the subscription. For example, if the User during the lifetime of the subscription. For example, if the User
Interface (UI) of the application shows inactivity for a period of Interface (UI) of the application shows inactivity for a period of
time, it can simply pause the notifications by setting the "min- time, it can simply pause the notifications by setting the "min-
interval" parameter to the subscription expiration time, while still interval" parameter to the subscription expiration time, while still
keeping the subscription alive. When the user becomes active again, keeping the subscription alive. When the user becomes active again,
the presence client can resume the stream of notifications by re- the presence client can resume the stream of notifications by re-
setting the "min-interval" parameter to the earlier used value. subscribing with a "min-interval" parameter set to the earlier used
value. Application of the mechanism defined by RFC 5839 [RFC5839]
Currently, a subscription refresh is needed in order to update the can also eliminate for the presence client to receive a (full-state)
maximum rate. However, this is highly inefficient, since each notification carrying the latest resource state after the
refresh automatically generates a (full-state) notification subscription refresh.
carrying the latest resource state. There is work
[I-D.ietf-sipcore-subnot-etags] ongoing to solve these
inefficiencies.
3.2. Use Case for setting a minimum rate for notifications 3.2. Use Case for setting a minimum rate for notifications
A location application is monitoring the movement of a target. A location application is monitoring the movement of a target.
In order to decrease the processing and network load, the location In order to decrease the processing and network load, the location
application has made a subscription with a set of location filters application has made a subscription with a set of location filters
[I-D.ietf-geopriv-loc-filters] that specify trigger criterias, for [I-D.ietf-geopriv-loc-filters] that specify trigger criterias, for
example, to send an update only when the target has moved at least n example, to send an update only when the target has moved at least n
meters. However, the application is also interested in receiving the meters. However, the application is also interested in receiving the
current state periodically even if the state of the target has not current state periodically even if the state of the target has not
changed enough to satisfy any of the trigger criteria, i.e. has not changed enough to satisfy any of the trigger criteria, i.e. has not
moved at least n meters within the period. moved at least n meters within the period.
In order to control the actual state, the location application sets a In order to control the actual state, the location application sets a
minimum rate ("max-interval" parameter), i.e. a maximum time interval minimum rate ("max-interval" parameter), i.e. a maximum time interval
between two notifications. between two notifications.
The location application can also modify the "max-interval" parameter The location application can also modify the "max-interval" parameter
during the lifetime of the subscription. When the subscription to during the lifetime of the subscription. When the subscription to
the movement of a target is made, the notifier does not typically the movement of a target is made, the notifier may not have the
have the location information available. Thus, the first location information available. Thus, the first notification might
notification might be empty, or certain values might be absent. An be empty, or certain values might be absent. An important use case
important use case is placing constraints on when complete state is placing constraints on when complete state should be provided
should be provided after creating the subscription. The "max- after creating the subscription. The "max-interval" parameter
interval" parameter indicates to the notifier the time when to indicates the time to the notifier when a complete state information
generate a notification containing complete state information. Once should be notified. Once state is acquired and the second
state is acquired and the second notification is sent, the subscriber notification is sent, the subscriber updates or changes the "max-
updates or changes the "max-interval" parameter to a more sensible interval" parameter to a more sensible value. This update can be
value. This update can be performed in the 200 OK response to the performed in the 200 OK response to the NOTIFY request that contains
NOTIFY request that contains the complete state information. the complete state information.
3.3. Use Case for specifying the average rate of notifications 3.3. Use Case for specifying the average rate of notifications
The previous mechanisms introduce a static and instantaneous rate The previous mechanisms introduce a static and instantaneous rate
control. However there are some applications that would work better control. However there are some applications that would work better
with an adaptive rate control. This section illustrates the tracking with an adaptive rate control. This section illustrates the tracking
scenario. scenario.
A tracking application is monitoring a target. A tracking application is monitoring a target.
In order to decrease the processing and network load, the tracking In order to decrease the processing and network load, the tracking
application wants to make a subscription that dynamically increases application wants to make a subscription that dynamically increases
the interval between notifications if the target has sent out several the interval between notifications if the target has sent out several
notifications recently. notifications recently.
In order to set an adaptive rate control, the application defines a In order to set an adaptive rate control, the application defines a
average cadence ("average-interval" parameter) at which notifications average cadence ("average-interval" parameter) at which notifications
are desired. The "average-interval" parameter value is used by the are desired. The "average-interval" parameter value is used by the
notifier to dynamically calculate the maximum time allowed between notifier to dynamically calculate the maximum time allowed between
two subscriptions. In order to dynamically calculate the maximum, two notifications. In order to dynamically calculate the maximum,
the Notifier takes into consideration the frequency at which the Notifier takes into consideration the frequency at which
notifications have been sent recently. notifications have been sent recently.
This type of rate control allows the notifier to dynamically increase This type of rate control allows the notifier to dynamically increase
or decrease the Notification frequency. or decrease the Notification frequency.
The tracking application can also modify the "average-interval" The tracking application can also modify the "average-interval"
parameter during the lifetime of the subscription. parameter during the lifetime of the subscription.
3.4. Requirements 3.4. Requirements
skipping to change at page 8, line 27 skipping to change at page 8, line 23
mechanisms together with any other event filtering mechanisms together with any other event filtering
mechanisms. mechanisms.
REQ7: The notifier must be allowed to use a policy in which the REQ7: The notifier must be allowed to use a policy in which the
minimum time period between two notifications is adjusted minimum time period between two notifications is adjusted
from the value given by the subscriber. from the value given by the subscriber.
For example, due to congestion reasons, local policy at For example, due to congestion reasons, local policy at
the notifier could temporarily dictate a policy that in the notifier could temporarily dictate a policy that in
effect increases the subscriber-configured minimum time effect increases the subscriber-configured minimum time
period between two notifications. period between two notifications. In another example, the
notifier can decrease the proposed minimum time by the
subscriber to match it with the remaining expiry time left
for the subscription.
REQ8: The different rate control mechanisms must discuss corner REQ8: The different rate control mechanisms must discuss corner
cases for setting the time periods between two notifications. cases for setting the time periods between two notifications.
At a minimum, the mechanisms must include discussion of the At a minimum, the mechanisms must include discussion of the
situation resulting from a minimum, maximum or average time situation resulting from a minimum, maximum or average time
period which exceeds the subscription duration, and should period which exceeds the subscription duration, and should
provide mechanisms for avoiding this situation. provide mechanisms for avoiding this situation.
REQ9: The different rate control mechanisms must be possible to be REQ9: The different rate control mechanisms must be possible to be
installed, modified, or removed in the course of an active installed, modified, or removed in the course of an active
subscription. subscription.
REQ10: The different rate control mechanisms must allow for the REQ10: The different rate control mechanisms must allow for the
application of authentication and integrity protection application of authentication and integrity protection
mechanisms to subscriptions invoking that mechanism. mechanisms to subscriptions invoking that mechanism.
Note that Section 10 contains further discussion on the security
implications of the different rate control mechanisms.
3.5. The maximum rate mechanism for Resource List Server 3.5. The maximum rate mechanism for Resource List Server
When applied to a list subscription, the maximum rate mechanism has When applied to a list subscription [RFC4662], the maximum rate
some additional considerations. Specifically, the maximum rate mechanism has some additional considerations. Specifically, the
applies to the aggregate notification stream resulting from the list maximum rate applies to the aggregate notification stream resulting
subscription, rather than explicitly controlling the notification of from the list subscription, rather than explicitly controlling the
each of the implied constituent events. Moreover, the list event notification of each of the implied constituent events. Moreover,
notifier can use the maximum rate mechanism on its own to control the the RLS can use the maximum rate mechanism on its own to control the
rate of the individual subscriptions to avoid overflowing its buffer. rate of the back-end subscriptions to avoid overflowing its buffer.
The notifier is responsible for sending out event notifications upon The notifier is responsible for sending out event notifications upon
state changes of the subscribed resource. We can model the notifier state changes of the subscribed resource. We can model the notifier
as consisting of three components: the event state resource(s), the as consisting of three components: the event state resource(s), the
Resource List Server (RLS) (or any other notifier), a notification Resource List Server (RLS) (or any other notifier), a notification
buffer, and finally the subscriber, or watcher of the event state, as buffer, and finally the subscriber, or watcher of the event state, as
shown in Figure 1. shown in Figure 1.
+--------+ +--------+
| Event | | Event |
skipping to change at page 11, line 13 skipping to change at page 11, line 11
"max-interval" or "average-interval" Event header parameter as part "max-interval" or "average-interval" Event header parameter as part
of a subsequent SUBSCRIBE request or a 200-class response to the of a subsequent SUBSCRIBE request or a 200-class response to the
NOTIFY request. NOTIFY request.
A notifier that supports the different rate control mechanisms will A notifier that supports the different rate control mechanisms will
comply with the value given in "min-interval", "max-interval" and comply with the value given in "min-interval", "max-interval" and
"average-interval" parameters and adjust its rate of notification "average-interval" parameters and adjust its rate of notification
accordingly. However, if the notifier needs to lower the accordingly. However, if the notifier needs to lower the
subscription expiration value or a local policy or other subscription expiration value or a local policy or other
implementation-determined constraint at the notifier can not satisfy implementation-determined constraint at the notifier can not satisfy
the rate control request, then the notifier can adjust opportunely the rate control request, then the notifier can adjust (i.e. increase
the subscriber requested rate control. or decrease) opportunely the subscriber requested rate control.
Rate controlled notifications will have exactly the same properties
as the ones without rate control, with the exception that they will
be generated within the timing constraints requested.
4. Operation of the maximum rate mechanism 4. Operation of the maximum rate mechanism
4.1. Subscriber Behavior 4.1. Subscriber Behavior
In general, the way in which a subscriber generates SUBSCRIBE In general, the way in which a subscriber generates SUBSCRIBE
requests and processes NOTIFY requests is according to RFC 3265 requests and processes NOTIFY requests is according to RFC 3265
[RFC3265]. [RFC3265].
A subscriber that wishes to apply a maximum rate to notifications in A subscriber that wishes to apply a maximum rate to notifications in
a subscription MUST construct a SUBSCRIBE request that includes a a subscription MUST construct a SUBSCRIBE request that includes a
minimum time interval between two consecutive notifications included minimum time interval between two consecutive notifications included
in the "min-interval" Event header field parameter. The value of in the "min-interval" Event header field parameter. The value of
this parameter is an integral number of seconds in decimal. this parameter is an integral number of seconds in decimal.
A subscriber that wishes to update the previously agreed maximum rate A subscriber that wishes to update the previously agreed maximum rate
of notifications MUST include the updated "min-interval" Event header of notifications MUST include the updated "min-interval" Event header
field parameter in a subsequent SUBSCRIBE request or a 200-class field parameter in a subsequent SUBSCRIBE request or a 200-class
response to the NOTIFY request. response to the NOTIFY request. If the Event header field of the
SUBSCRIBE request did not include the "min-interval" parameter, the
subscriber MUST NOT include an initial value of the "min-interval"
Event header field parameter in a 200-class response to the NOTIFY
request.
A subscriber that wishes to remove the maximum rate control from A subscriber that wishes to remove the maximum rate control from
notifications MUST indicate so by not including a "min-interval" notifications MUST indicate so by not including a "min-interval"
Event header field parameter in a subsequent SUBSCRIBE request or a Event header field parameter in a subsequent SUBSCRIBE request or a
200-class response to the NOTIFY request. 200-class response to the NOTIFY request.
There are two main consequences for the subscriber when applying the There are two main consequences for the subscriber when applying the
maximum rate mechanism: state transitions may be lost, and event maximum rate mechanism: state transitions may be lost, and event
notifications may be delayed. If either of these side effects notifications may be delayed. If either of these side effects
constitute a problem to the application that is to utilize event constitute a problem to the application that is to utilize event
skipping to change at page 12, line 14 skipping to change at page 12, line 9
4.2. Notifier Behavior 4.2. Notifier Behavior
In general, the way in which a notifier processes SUBSCRIBE requests In general, the way in which a notifier processes SUBSCRIBE requests
and generates NOTIFY requests is according to RFC 3265 [RFC3265]. and generates NOTIFY requests is according to RFC 3265 [RFC3265].
A notifier that supports the maximum rate mechanism MUST extract the A notifier that supports the maximum rate mechanism MUST extract the
value of the "min-interval" Event header parameter from a SUBSCRIBE value of the "min-interval" Event header parameter from a SUBSCRIBE
request or a 200-class response to the NOTIFY request and use it as request or a 200-class response to the NOTIFY request and use it as
the suggested time allowed between two notifications. This value can the suggested time allowed between two notifications. This value can
be adjusted by the notifier, as defined in Section 4.3. be adjusted by the notifier, as defined in Section 4.3. If the Event
header field of the SUBSCRIBE request did not include the "min-
interval" parameter, the notifier MUST ignore an initial value of the
"min-interval" Event header field parameter in a 200-class response
to the NOTIFY request, if present.
A compliant notifier MUST reflect back the possibly adjusted minimum A compliant notifier MUST reflect back the possibly adjusted minimum
time interval in a "min-interval" Subscription-State header field time interval in a "min-interval" Subscription-State header field
parameter of the subsequent NOTIFY requests. The indicated "min- parameter of the subsequent NOTIFY requests. The indicated "min-
interval" value is adopted by the notifier, and the notification rate interval" value is adopted by the notifier, and the notification rate
is adjusted accordingly. is adjusted accordingly.
A notifier that does not understand this extension will not reflect A notifier that does not understand this extension will not reflect
the "min-interval" Subscription-State header field parameter in the the "min-interval" Subscription-State header field parameter in the
NOTIFY requests; the absence of this parameter serves as a hint to NOTIFY requests; the absence of this parameter indicates to the
the subscriber that no rate control is supported by the notifier. subscriber that no rate control is supported by the notifier.
A compliant notifier MUST NOT generate notifications more frequently A compliant notifier MUST NOT generate notifications more frequently
than the maximum rate allows for, except when generating the than the maximum rate allows for, except when generating the
notification either upon receipt of a SUBSCRIBE request (the first notification either upon receipt of a SUBSCRIBE request (the first
notification), when the subscription state is changing from "pending" notification), when the subscription state is changing from "pending"
to "active" state or upon termination of the subscription (the last to "active" state or upon termination of the subscription (the last
notification). Such notifications reset the timer for the next notification). Such notifications reset the timer for the next
notification, even though they do not need to abide by it. notification, even though they do not need to abide by it.
When a local policy dictates a maximum rate for notifications, a When a local policy dictates a maximum rate for notifications, a
skipping to change at page 12, line 47 skipping to change at page 12, line 46
local policy maximum rate, even if the subscriber is not asking for local policy maximum rate, even if the subscriber is not asking for
maximum rate control. The notifier MAY inform the subscriber about maximum rate control. The notifier MAY inform the subscriber about
such local policy maximum rate using the "min-interval" Subscription- such local policy maximum rate using the "min-interval" Subscription-
State header field parameter included in the subsequent NOTIFY State header field parameter included in the subsequent NOTIFY
requests. requests.
Retransmissions of NOTIFY requests are not affected by the maximum Retransmissions of NOTIFY requests are not affected by the maximum
rate mechanism, i.e., the maximum rate mechanism only applies to the rate mechanism, i.e., the maximum rate mechanism only applies to the
generation of new transactions. In other words, the maximum rate generation of new transactions. In other words, the maximum rate
mechanism does not in any way break or modify the normal mechanism does not in any way break or modify the normal
retransmission mechanism. retransmission mechanism specified in RFC 3261 [RFC3261].
4.3. Selecting the maximum rate 4.3. Selecting the maximum rate
Special care needs to be taken when selecting the "min-interval" Special care needs to be taken when selecting the "min-interval"
value. Using the "min-interval" syntax it is possible to insist both value. Using the "min-interval" syntax it is possible to insist both
very short and very long intervals between notifications. very short and very long intervals between notifications.
For example, the maximum rate could potentially set a minimum time For example, the maximum rate could potentially set a minimum time
value between notifications that exceeds the subscription expiration value between notifications that exceeds the subscription expiration
value. Such a configuration would effectively quench the notifier, value. Such a configuration would effectively quench the notifier,
resulting in exactly two notifications to be generated. If the resulting in exactly two notifications to be generated. If the
subscriber requests a "min-interval" value greater than the subscriber requests a "min-interval" value greater than the
subscription expiration, the notifier MUST lower the "min-interval" subscription expiration, the notifier MUST lower the "min-interval"
value and set it to the expiration time left. According to RFC 3265 value and set it to the expiration time left. According to RFC 3265
[RFC3265] the notifier may also shorten the subscription expiry [RFC3265] the notifier may also shorten the subscription expiry
anytime during an active subscription. For such cases, the notifier anytime during an active subscription. If the subscription expiry is
MUST also lower the "min-interval" value and set it to the reduced shortened during an active subscription, the notifier MUST also lower
expiration time. the "min-interval" value and set it to the reduced expiration time.
In some cases it makes sense to pause the notification stream on an In some cases it makes sense to pause the notification stream on an
existing subscription dialog on a temporary basis without terminating existing subscription dialog on a temporary basis without terminating
the subscription, e.g. due to inactivity on the application UI. the subscription, e.g. due to inactivity on the application UI.
Whenever a subscriber discovers the need to perform the notification Whenever a subscriber discovers the need to perform the notification
pause operation, it SHOULD set the "min-interval" value to the pause operation, it SHOULD set the "min-interval" value to the
remaining subscription expiration value. This results in receiving remaining subscription expiration value. This results in receiving
no further notifications until the subscription expires, renewed or no further notifications until the subscription expires or the
notifications are resumed by the subscriber. subscriber sends a SUBSCRIBE request resuming notifications.
The notifier MAY decide to adjust the proposed maximum rate value
based on its local policy or other implementation-determined
constraints. The notifier MAY also choose a higher "min-interval"
value than the subscriber proposed one, e.g., because of static
configuration given by local policy.
The notifier MUST include the adjusted "min-interval" value in the The notifier MAY decide to increase or decrease the proposed maximum
rate value by the subscriber based on its local policy, static
configuration or other implementation-determined constraints. The
notifier MUST include the adjusted "min-interval" value in the
Subscription-State header field's "min-interval" parameter in each of Subscription-State header field's "min-interval" parameter in each of
the NOTIFY requests. In addition, different event packages MAY the NOTIFY requests. In addition, different event packages MAY
define additional constraints to the allowed "min-interval" define additional constraints to the allowed "min-interval"
intervals. Such constraints are out of the scope of this intervals. Such constraints are out of the scope of this
specification. specification.
4.4. Buffer Policy Description 4.4. Buffer Policy Description
4.4.1. Partial State Notifications 4.4.1. Partial State Notifications
skipping to change at page 15, line 6 skipping to change at page 15, line 4
It is also true that there are several compression schemes available It is also true that there are several compression schemes available
that have been designed to save bandwidth in SIP, e.g., SigComp that have been designed to save bandwidth in SIP, e.g., SigComp
[RFC3320] and TLS compression [RFC3943]. However, such compression [RFC3320] and TLS compression [RFC3943]. However, such compression
schemes are complementary rather than competing mechanisms to the schemes are complementary rather than competing mechanisms to the
maximum rate mechanism. After all, they can both be applied maximum rate mechanism. After all, they can both be applied
simultaneously, and in such a way that the compound savings are as simultaneously, and in such a way that the compound savings are as
good as the sum of applying each one alone. good as the sum of applying each one alone.
5. Operation of the minimum rate mechanism 5. Operation of the minimum rate mechanism
5.1. Subscriber Behavior 5.1. Subscriber Behavior
In general, the way in which a subscriber generates SUBSCRIBE In general, the way in which a subscriber generates SUBSCRIBE
requests and processes NOTIFY requests is according to RFC 3265 requests and processes NOTIFY requests is according to RFC 3265
[RFC3265]. [RFC3265].
A subscriber that wishes to apply a minimum rate to notifications in A subscriber that wishes to apply a minimum rate to notifications in
a subscription MUST construct a SUBSCRIBE request that includes a a subscription MUST construct a SUBSCRIBE request that includes a
maximum time interval between two consecutive notifications included maximum time interval between two consecutive notifications included
in the "max-interval" Event header field parameter. The value of in the "max-interval" Event header field parameter. The value of
this parameter is an integral number of seconds in decimal. this parameter is an integral number of seconds in decimal.
A subscriber that wishes to update the previously agreed minimum rate A subscriber that wishes to update the previously agreed minimum rate
of notifications MUST include the updated "max-interval" Event header of notifications MUST include the updated "max-interval" Event header
field parameter in a subsequent SUBSCRIBE request or a 200-class field parameter in a subsequent SUBSCRIBE request or a 200-class
response to the NOTIFY request. response to the NOTIFY request. If the Event header field of the
SUBSCRIBE request did not include the "max-interval" parameter, the
subscriber MUST NOT include an initial value of the "max-interval"
Event header field parameter in a 200-class response to the NOTIFY
request.
A subscriber that wishes to remove the minimum rate control from A subscriber that wishes to remove the minimum rate control from
notifications MUST indicate so by not including a "max-interval" notifications MUST indicate so by not including a "max-interval"
Event header field parameter in a subsequent SUBSCRIBE request or a Event header field parameter in a subsequent SUBSCRIBE request or a
200-class response to the NOTIFY request. 200-class response to the NOTIFY request.
The main consequence for the subscriber when applying the minimum The main consequence for the subscriber when applying the minimum
rate mechanism is that it can receive a notification even if nothing rate mechanism is that it can receive a notification even if nothing
has changed in the current state of the notifier. has changed in the current state of the notifier. However, RFC 5839
[RFC5839] defines a mechanism that allows sending only an etag
There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a instead of the full resource state in a notification if the state has
reference in a notification if nothing has changed. not changed.
5.2. Notifier Behavior 5.2. Notifier Behavior
In general, the way in which a notifier processes SUBSCRIBE requests In general, the way in which a notifier processes SUBSCRIBE requests
and generates NOTIFY requests is according to RFC 3265 [RFC3265]. and generates NOTIFY requests is according to RFC 3265 [RFC3265].
A notifier that supports the minimum rate mechanism MUST extract the A notifier that supports the minimum rate mechanism MUST extract the
value of the "max-interval" Event header parameter from a SUBSCRIBE value of the "max-interval" Event header parameter from a SUBSCRIBE
request or a 200-class response to the NOTIFY request and use it as request or a 200-class response to the NOTIFY request and use it as
the suggested maximum time allowed between two notifications. the suggested maximum time allowed between two notifications. If the
Event header field of the SUBSCRIBE request did not include the "max-
interval" parameter, the notifier MUST ignore an initial value of the
"max-interval" Event header field parameter in a 200-class response
to the NOTIFY request, if present.
The notifier MAY decide to adjust the proposed minimum rate value The notifier MAY decide to increase or decrease the proposed minimum
based on its local policy or other implementation-determined rate value based on its local policy, static configuration or other
constraints. A compliant notifier MUST reflect back the possibly implementation-determined constraints. A compliant notifier MUST
adjusted maximum time interval in a "max-interval" Subscription-State reflect back the possibly adjusted maximum time interval in a "max-
header field parameter of the subsequent NOTIFY requests. The interval" Subscription-State header field parameter of the subsequent
indicated "max-interval" value is adopted by the notifier, and the NOTIFY requests. The indicated "max-interval" value is adopted by
notification rate is adjusted accordingly. the notifier, and the notification rate is adjusted accordingly.
A notifier that does not understand this extension, will not reflect A notifier that does not understand this extension, will not reflect
the "max-interval" Subscription-State header field parameter in the the "max-interval" Subscription-State header field parameter in the
NOTIFY requests; the absence of this parameter serves as a hint to NOTIFY requests; the absence of this parameter indicates to the
the subscriber that no rate control is supported by the notifier. subscriber that no rate control is supported by the notifier.
A compliant notifier MUST generate notifications whenever the time A compliant notifier MUST generate notifications whenever the time
since the most recent notification exceeds the value in the "max- since the most recent notification exceeds the value in the "max-
interval" parameter. Depending on the event package and subscriber interval" parameter. Depending on the event package and subscriber
preferences indicated in the SUBSCRIBE request, the NOTIFY request preferences indicated in the SUBSCRIBE request, the NOTIFY request
MUST contain either the current full state or the partial state sent as a result of a max-interval expiration MUST contain either the
showing the difference between the current state and the last current full state or the partial state showing the difference
successfully communicated state. between the current state and the last successfully communicated
state.
Retransmissions of NOTIFY requests are not affected by the minimum Retransmissions of NOTIFY requests are not affected by the minimum
rate mechanism, i.e., the minimum rate mechanism only applies to the rate mechanism, i.e., the minimum rate mechanism only applies to the
generation of new transactions. In other words, the minimum rate generation of new transactions. In other words, the minimum rate
mechanism does not in any way break or modify the normal mechanism does not in any way break or modify the normal
retransmission mechanism. retransmission mechanism.
6. Operation of the average rate mechanism 6. Operation of the average rate mechanism
6.1. Subscriber Behavior 6.1. Subscriber Behavior
skipping to change at page 16, line 41 skipping to change at page 16, line 48
A subscriber that wishes to apply an average rate to notifications in A subscriber that wishes to apply an average rate to notifications in
a subscription MUST construct a SUBSCRIBE request that includes a a subscription MUST construct a SUBSCRIBE request that includes a
proposed average time interval between two consecutive notifications proposed average time interval between two consecutive notifications
included in a "average-interval" Event header field parameter. The included in a "average-interval" Event header field parameter. The
value of this parameter is an integral number of seconds in decimal. value of this parameter is an integral number of seconds in decimal.
A subscriber that wishes to update the previously agreed average rate A subscriber that wishes to update the previously agreed average rate
of notifications MUST include the updated "average-interval" Event of notifications MUST include the updated "average-interval" Event
header field parameter in a subsequent SUBSCRIBE request or a 200- header field parameter in a subsequent SUBSCRIBE request or a 200-
class response to the NOTIFY request. class response to the NOTIFY request. If the Event header field of
the SUBSCRIBE request did not include the "average-interval"
parameter, the subscriber MUST NOT include an initial value of the
"average-interval" Event header field parameter in a 200-class
response to the NOTIFY request.
A subscriber that wishes to remove the average rate control from A subscriber that wishes to remove the average rate control from
notifications MUST indicate so by not including a "average-interval" notifications MUST indicate so by not including a "average-interval"
Event header field parameter in a subsequent SUBSCRIBE request or a Event header field parameter in a subsequent SUBSCRIBE request or a
200-class response to the NOTIFY request. 200-class response to the NOTIFY request.
The main consequence for the subscriber when applying the average The main consequence for the subscriber when applying the average
rate mechanism is that it can receive a notification even if nothing rate mechanism is that it can receive a notification even if nothing
has changed in the current state of the notifier. has changed in the current state of the notifier. However, RFC 5839
[RFC5839] defines a mechanism that allows sending only an etag
There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a instead of the full resource state in a notification if the state has
reference in a notification if nothing has changed. not changed.
6.2. Notifier Behavior 6.2. Notifier Behavior
In general, the way in which a notifier processes SUBSCRIBE requests In general, the way in which a notifier processes SUBSCRIBE requests
and generates NOTIFY requests is according to RFC 3265 [RFC3265]. and generates NOTIFY requests is according to RFC 3265 [RFC3265].
A notifier that supports the average rate mechanism MUST extract the A notifier that supports the average rate mechanism MUST extract the
value of the "average-interval" Event header parameter from a value of the "average-interval" Event header parameter from a
SUBSCRIBE request or a 200-class response to the NOTIFY request and SUBSCRIBE request or a 200-class response to the NOTIFY request and
use it to calculate the maximum time allowed between two transactions use it to calculate the maximum time allowed between two transactions
as defined in Section 6.3. as defined in Section 6.3. If the Event header field of the
SUBSCRIBE request did not include the "average-interval" parameter,
the notifier MUST ignore an initial value of the "average-interval"
Event header field parameter in a 200-class response to the NOTIFY
request, if present.
The notifier MAY decide to adjust the proposed average time interval The notifier MAY decide to increase or decrease the proposed average
based on its local policy or other implementation-determined time interval based on its local policy, static configuration or
constraints. A compliant notifier MUST reflect back the possibly other implementation-determined constraints. A compliant notifier
adjusted average time interval in an "average-interval" Subscription- MUST reflect back the possibly adjusted average time interval in an
State header field parameter of the subsequent NOTIFY requests. The "average-interval" Subscription-State header field parameter of the
indicated "average-interval" value is adopted by the notifier, and subsequent NOTIFY requests. The indicated "average-interval" value
the notification rate is adjusted accordingly. is adopted by the notifier, and the notification rate is adjusted
accordingly.
A notifier that does not understand this extension will not reflect A notifier that does not understand this extension will not reflect
the "average-interval" Subscription-State header parameter in the the "average-interval" Subscription-State header parameter in the
NOTIFY requests; the absence of this parameter serves as a hint to NOTIFY requests; the absence of this parameter indicates to the
the subscriber that no rate control is supported by the notifier. subscriber that no rate control is supported by the notifier.
A compliant notifier SHOULD generate notifications whenever the time A compliant notifier SHOULD generate notifications whenever the time
since the most recent notification exceeds the value calculated using since the most recent notification exceeds the value calculated using
the formula defined in Section 6.3. the formula defined in Section 6.3.
The average rate mechanism is implemented as follows: The average rate mechanism is implemented as follows:
1) When a subscription is first created, the notifier creates a 1) When a subscription is first created, the notifier creates a
record that keeps track of the number of notifications that have record that keeps track of the number of notifications that have
been sent in the "period". This record is initialized to contain been sent in the "period". This record is initialized to contain
skipping to change at page 18, line 13 skipping to change at page 18, line 28
(subject to any filtering associated with the subscription). (subject to any filtering associated with the subscription).
4) Whenever a NOTIFY request is sent (regardless of whether due to a 4) Whenever a NOTIFY request is sent (regardless of whether due to a
timeout or a state change), the notifier updates the notification timeout or a state change), the notifier updates the notification
history record, recalculates the value of "timeout," and returns history record, recalculates the value of "timeout," and returns
to step 3. to step 3.
Retransmissions of NOTIFY requests are not affected by the timeout, Retransmissions of NOTIFY requests are not affected by the timeout,
i.e., the timeout only applies to the generation of new transactions. i.e., the timeout only applies to the generation of new transactions.
In other words, the timeout does not in any way break or modify the In other words, the timeout does not in any way break or modify the
normal retransmission mechanism. normal retransmission mechanism specified in RFC 3261 [RFC3261].
6.3. Calculating the timeout 6.3. Calculating the timeout
The formula used to vary the absolute pacing in a way that will meet The formula used to vary the absolute pacing in a way that will meet
the average rate requested over the period is given in equation (1): the average rate requested over the period is given in equation (1):
timeout = (average-interval ^ 2) * count / period (1) timeout = (average-interval ^ 2) * count / period (1)
The output of the formula, "timeout", is the time to the next The output of the formula, "timeout", is the time to the next
notification, expressed in seconds. The formula has three inputs: notification, expressed in seconds. The formula has three inputs:
average-interval: The value of the "average-interval" parameter average-interval: The value of the "average-interval" parameter
conveyed in the Event header field, in seconds. conveyed in the Subscription-State header field, in seconds.
period: The rolling average period, in seconds. A suggested period: The rolling average period, in seconds. The value of the
reasonable period is 60 seconds. "period" parameter MUST be greater than the value of the "average-
interval" parameter.
count: The number of notifications that have been sent during the count: The number of notifications that have been sent during the
last "period" of seconds. last "period" of seconds not including any retransmissions of
requests.
In case both the maximum rate and the average rate mechanisms are In case both the maximum rate and the average rate mechanisms are
used in the same subscription the formula used to dynamically used in the same subscription the formula used to dynamically
calculate the timeout is given in equation (2): calculate the timeout is given in equation (2):
timeout = MAX[min-interval, (average-interval ^ 2) * count / period] (2) timeout = MAX[min-interval, (average-interval ^ 2) * count / period] (2)
min-interval: The value of the "min-interval" parameter conveyed in min-interval: The value of the "min-interval" parameter conveyed in
the Event header field, in seconds. the Event header field, in seconds.
skipping to change at page 19, line 46 skipping to change at page 20, line 19
max-interval and average-interval: as both the parameters are max-interval and average-interval: as both the parameters are
designed as minimum rate mechanisms, this combination makes sense designed as minimum rate mechanisms, this combination makes sense
only in some corner cases. only in some corner cases.
A subscriber SHOULD choose a "max-interval" value higher than the A subscriber SHOULD choose a "max-interval" value higher than the
"average-interval" value, otherwise the notifier MUST NOT consider "average-interval" value, otherwise the notifier MUST NOT consider
the "max-interval" value. the "max-interval" value.
min-interval, max-interval and average-interval: this combination min-interval, max-interval and average-interval: this combination
makes little sense to be used. makes little sense to be used although not forbidden.
A subscriber SHOULD choose a "max-interval" and "average-interval"
values higher than the "min-interval" value, otherwise the
notifier MUST adjust the subscriber provided "max-interval" and
"average-interval" values to a value equivalent or higher than the
"min-interval" value.
A subscriber SHOULD choose a "max-interval" value higher than the
"average-interval" value, otherwise the notifier MUST NOT consider
the "max-interval" value.
8. Syntax 8. Syntax
This section describes the syntax extensions required for the This section describes the syntax extensions required for the
different rate control mechanisms. different rate control mechanisms.
8.1. "min-interval", "max-interval" and "average-interval" Header Field 8.1. "min-interval", "max-interval" and "average-interval" Header Field
Parameters Parameters
The "min-interval", "max-interval" and "average-interval" parameters The "min-interval", "max-interval" and "average-interval" parameters
are added to the rule definitions of the Event header field and the are added to the rule definitions of the Event header field and the
Subscription-State header field in the SIP Events [RFC3265] grammar. Subscription-State header field in RFC 3265 [RFC3265] grammar. Usage
Usage of this parameter is described in Section 4, Section 5 and of this parameter is described in Section 4, Section 5 and Section 6.
Section 6.
8.2. Augmented BNF Definitions 8.2. Augmented BNF Definitions
This section describes the Augmented BNF [RFC5234] definitions for This section describes the Augmented BNF [RFC5234] definitions for
the new syntax elements. Note that we derive here from the ruleset the new syntax elements. Note that we derive here from the ruleset
present in SIP Events [RFC3265], adding additional alternatives to present in RFC 3265 [RFC3265], adding additional alternatives to the
the alternative sets of "event-param" and "subexp-params" defined alternative sets of "event-param" and "subexp-params" defined
therein. therein.
event-param =/ min-interval-param event-param =/ min-interval-param
subexp-params =/ min-interval-param subexp-params =/ min-interval-param
min-interval-param = "min-interval" EQUAL delta-seconds min-interval-param = "min-interval" EQUAL delta-seconds
event-param =/ max-interval-param event-param =/ max-interval-param
subexp-params =/ max-interval-param subexp-params =/ max-interval-param
max-interval-param = "max-interval" EQUAL delta-seconds max-interval-param = "max-interval" EQUAL delta-seconds
event-param =/ average-interval-param event-param =/ average-interval-param
subexp-params =/ average-interval-param subexp-params =/ average-interval-param
average-interval-param = "average-interval" EQUAL delta-seconds average-interval-param = "average-interval" EQUAL delta-seconds
8.3. Event header field usage in responses to the NOTIFY request 8.3. Event header field usage in responses to the NOTIFY request
This table expands the table described in Section 7.2 of SIP Events This table expands the table described in Section 7.2 of RFC 3265
[RFC3265] allowing the Event header field to appear in a 200-class [RFC3265] allowing the Event header field to appear in a 200-class
response to a NOTIFY request. A UA that wishes to update the value response to a NOTIFY request. A UA that wishes to update the value
for minimum, maximum or average rate of notifications can do so by for minimum, maximum or average rate of notifications can do so by
including all desired values for the rate control parameters in an including all desired values for the rate control parameters in an
Event header field of the 200-class response to a NOTIFY request. Event header field of the 200-class response to a NOTIFY request.
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
----------------------------------------------------------------- -----------------------------------------------------------------
Event 2xx - - - - - - - - o Event 2xx - - - - - - - - o
skipping to change at page 21, line 27 skipping to change at page 22, line 7
Event max-interval No [RFCxxxx] Event max-interval No [RFCxxxx]
Subscription-State max-interval No [RFCxxxx] Subscription-State max-interval No [RFCxxxx]
Event average-interval No [RFCxxxx] Event average-interval No [RFCxxxx]
Subscription-State average-interval No [RFCxxxx] Subscription-State average-interval No [RFCxxxx]
(Note to the RFC Editor: please replace "xxxx" with the RFC number of (Note to the RFC Editor: please replace "xxxx" with the RFC number of
this specification, when assigned.) this specification, when assigned.)
10. Security Considerations 10. Security Considerations
Naturally, the security considerations listed in SIP events Naturally, the security considerations listed in RFC 3265 [RFC3265],
[RFC3265], which the rate control mechanisms described in this which the rate control mechanisms described in this document extends,
document extends, apply in entirety. In particular, authentication apply in entirety. In particular, authentication and message
and message integrity SHOULD be applied to subscriptions with this integrity SHOULD be applied to subscriptions with this extension.
extension.
RFC 3265 [RFC3265] recommends the integrity protection of the Event
header field of SUBSCRIBE requests. Implementations of this
extension SHOULD also provide integrity protection for the Event
header field included in the 200-class response to the NOTIFY
request.
When the maximum rate mechanism involves partial state notifications,
the security considerations listed in RFC 5263 [RFC5263] apply in
entirety.
11. Acknowledgments 11. Acknowledgments
Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander
Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham
Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston,
and Michael Procter for support and/or review of this work. Michael Procter and Janet Gunn for support and/or review of this
work.
Thanks to Brian Rosen for the idea of the minimum and average rate Thanks to Brian Rosen for the idea of the minimum and average rate
mechanisms, and Adam Roach for the work on the averaging algorithm mechanisms, and Adam Roach for the work on the averaging algorithm
and other feedback. and other feedback.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 22, line 20 skipping to change at page 23, line 9
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006. Resource Lists", RFC 4662, August 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H.
Khartabil, "Session Initiation Protocol (SIP) Extension
for Partial Notification of Presence Information",
RFC 5263, September 2008.
12.2. Informative References 12.2. Informative References
[I-D.ietf-geopriv-loc-filters] [I-D.ietf-geopriv-loc-filters]
Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Mahy, R., Rosen, B., and H. Tschofenig, "Filtering
Location Notifications in the Session Initiation Protocol Location Notifications in the Session Initiation Protocol
(SIP)", draft-ietf-geopriv-loc-filters-09 (work in (SIP)", draft-ietf-geopriv-loc-filters-11 (work in
progress), December 2009. progress), March 2010.
[I-D.ietf-sipcore-subnot-etags]
Niemi, A. and D. Willis, "An Extension to Session
Initiation Protocol (SIP) Events for Conditional Event
Notification", draft-ietf-sipcore-subnot-etags-04 (work in
progress), January 2010.
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
Liu, Z., and J. Rosenberg, "Signaling Compression Liu, Z., and J. Rosenberg, "Signaling Compression
(SigComp)", RFC 3320, January 2003. (SigComp)", RFC 3320, January 2003.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004. Package for Registrations", RFC 3680, March 2004.
[RFC3842] Mahy, R., "A Message Summary and Message Waiting [RFC3842] Mahy, R., "A Message Summary and Message Waiting
Indication Event Package for the Session Initiation Indication Event Package for the Session Initiation
skipping to change at page 23, line 10 skipping to change at page 23, line 47
Package for the Session Initiation Protocol (SIP)", Package for the Session Initiation Protocol (SIP)",
RFC 3857, August 2004. RFC 3857, August 2004.
[RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol
Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943,
November 2004. November 2004.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC5839] Niemi, A. and D. Willis, "An Extension to Session
Initiation Protocol (SIP) Events for Conditional Event
Notification", RFC 5839, May 2010.
Authors' Addresses Authors' Addresses
Aki Niemi Aki Niemi
Nokia Nokia
P.O. Box 407 P.O. Box 407
NOKIA GROUP, FIN 00045 NOKIA GROUP, FIN 00045
Finland Finland
Phone: +358 50 389 1644 Phone: +358 50 389 1644
Email: aki.niemi@nokia.com Email: aki.niemi@nokia.com
Krisztian Kiss Krisztian Kiss
Nokia Nokia
313 Fairchild Dr 323 Fairchild Dr
Mountain View, CA 94043 Mountain View, CA 94043
US US
Phone: +1 650 391 5969 Phone: +1 650 391 5969
Email: krisztian.kiss@nokia.com Email: krisztian.kiss@nokia.com
Salvatore Loreto Salvatore Loreto
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
 End of changes. 55 change blocks. 
146 lines changed or deleted 190 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/