One document matched: draft-rosen-simple-watcher-count-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2141 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml">
<!ENTITY rfc2648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2648.xml">
<!ENTITY rfc3023 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3023.xml">
<!ENTITY rfc3256 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3256.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml">
<!ENTITY rfc3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY rfc3856 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3856.xml">
<!ENTITY rfc3857 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3857.xml">
<!ENTITY rfc3903 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3903.xml">
<!ENTITY rfc4825 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4825.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-rosen-simple-watcher-count-00" ipr="full3978">
<front>
<title abbrev="Optimizing Notifications for PNAs">Optimizing Notifications for
Presence Network Agents</title>
<author fullname="Brian Rosen" initials="B.R." surname="Rosen">
<organization abbrev="NeuStar">NeuStar, Inc.</organization>
<address>
<postal>
<street>470 Conrad Dr</street>
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>US</country>
</postal>
<email>br@brianrosen.net</email>
</address>
</author>
<author fullname="Salvatore Loreto" initials="S.L."
surname="Loreto">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>Jorvas</city>
<code>02420</code>
<country>Finland</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<author fullname="Krisztian Kiss" initials="K.K." surname="Kiss">
<organization abbrev="Nokia">Nokia</organization>
<address>
<postal>
<street>313 Fairchild Dr</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>US</country>
</postal>
<email>krisztian.kiss@nokia.com</email>
</address>
</author>
<date day="18" month="February" year="2008" />
<area>rai</area>
<workgroup>simple</workgroup>
<abstract>
<t>In large presence systems deployed in multiservice networks, presence information is often known by the
network in addition to, or instead of the presentity's devices (endpoints). Examples of such information
include location and availability for various kinds of session establishment. Even if devices know the
information, the network often has more bandwidth and better scale to keep the presence server up to date.
A Presence Network Agent (PNA) can publish presence information to a Presence Server(PS). When done
large scale, the basic publish operation can be inefficient. When the network has millions of subscribers,
only some of which have watchers, blind Publish operations are unecessary. WINFO can be used to determine
watchers, but the efficiency of maintaining WINFO per subscriber, and the size of the messages involved,
make that solution unattractive. The PNA would prefer to have the Presence Server simply tell it when
there was at least one watcher.
</t><t>
This document describes an XML document stored on the PS by which the PNA maintains a list of subscribers
it can provide presence for as a SIP event package that tells the PNA when the number of watchers for a
presentity on the list (or a specific presence element for a presentity) goes from 0 to at least 1
or from 1 to 0.</t>
</abstract></front><middle>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"></xref>.</t>
</section><section title="Background">
<t>Presence systems <xref target="RFC3856"></xref> are being deployed in networks where the network itself has presence information. This
information may also be known to the endpoint, but the network is often in a better position to publish
<xref target="RFC3903"></xref> the
information to the presence server. Mobile networks are an example of a network where a presence system
can have a very large number of presentities and providers, and where bandwidth from the device to the
presence server is restricted such that volitile presence data would be much more efficient if the network
published some data elements to the presence server rather than the user agent itself. A "Presence Network
Agent" (PNA) is a server operated by an entity in the network that has some presence information and publishes
this information to the presence server on behalf of the presentity. Optimization techniques are available
which make the actual Publish operation reasonably efficient. However, in large networks, there could be
millions of presentities, and if interconnected with other networks, even more watchers, but at any point
in time, there may not be any watchers for a particular presentity. If there are no watchers, and presence
information that changes relatively often is published to the presence server anyway, there can be significant
wasted effort and bandwidth in both the presence server and the presence network agent.
</t><t>
If the PNA knew which presentities that it had presence information for had active watchers, then it could
optimize its publishing operations. The presence server knows that, but the only way for the PNA to get that
information is the WINFO package <xref target="RFC3857"></xref>. WINFO provides the requisite data, but inefficiently. All the PNA wants
to know is when the number of watchers goes from zero (no watchers) to at least 1, or from at least one to zero.
There is no efficient way to get that information.
</t><t>
PNAs provide information for a set of presentities, and the set of presentities the PNA serves may not match the
set of presentities a particular PS serves. The PS has to know which presentities the PNA serves in order
to send it the right watcher state information. This is simply a list of presentities that changes over time.
The list can be very long, so sending it in its entirety when something changes on the list is not desirable.
</t><t>
Editor Note: There is an opportunity for further optimization if the PS knows which elements the PNA can
publish. Because of filtering and presence rules, just because there is at least one watcher, it doesn't
mean that the elements the PNA publishes are visible to any watchers. The PS could optimize notification of watcher
counts to only show when at least on watcher was recieving at least one element the PNA publishes. This
could further be extended to have the actual watcher count for each element sent by the PS to the PNA.</t>
</section>
<section title="PNA Presentity List">
<t>This document defines a Presentity List document intended to be maintained on the PS by the PNS using
XCAP <xref target="RFC4825"></xref>.</t>
<section title="Application Unique ID (AUID)">
<t>This specification defines the "pna-presentity-list" AUID within the IETF tree,
via the IANA registration in <xref target="IANA"></xref>.</t>
</section>
<section title="XML Schema">
<t><figure><artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pna-presentity-list"
xmlns="urn:ietf:params:xml:ns:watcher-count-presentity-list"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="watcher-count-presentity-list">
<xs:annotation>
<xs:documentation>Root element for pna-presentity-list
</xs:documentation>
</xs:annotation>
<xs:simpleType name="PNA">
<xs:annotation>
<xs:documentation>PNA</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType>
<xs:sequence>
<xs:element name="PresentityList">
<xs:annotation>
<xs:documentation>List of Presentities</xs:documentation>
</xs:annotation>
<xs:simpleType name="Presentity">
<xs:annotation>
<xs:documentation>One Presentity on the list</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
</xs:schema>
]]></artwork></figure></t>
</section>
<section title="Default Document Namespace">
<t>The default document namespace used in evaluating a URI is
urn:ietf:params:xml:ns:pna-presentity-list.</t>
</section>
<section title="MIME Type">
<t>Documents conformant to this schema are known by the MIME type
"application/pna-presentity-list+xml", registered in <xref target="IANA"></xref>.</t>
</section>
<section title="Validation Constraints">
<t>The Presence Network Agent must be authorized to provide presence data for the presentities on
the list.</t>
</section>
<section title="Data Semantics">
<t>The PNA element defines the URI of the PNA maintaining the list. This URI must match the URI from which
the PNA subscribes to the watcher-count event package on the PS.</t>
<section title="Naming Conventions">
<t>The PS must maintain a document with the file name containing the PNA identity. Provisioning may
be used to connect the file name to the PNA URI.</t>
</section>
<section title="Resource Interdependencies">
<t>There are no resource interdependencies in this application usage
beyond those defined by the schema.</t>
</section>
<section title="Authorization Policies">
<t>This application usage does not change the default authorization
policy defined by XCAP.</t>
</section></section></section>
<section title="Watcher-Count Event Package">
<t>This section fills in the details needed to specify an event package
as defined in Section 4.4 of <xref target="RFC3265"></xref>.</t>
<section title="Event Package Name">
<t><xref target="RFC3265"></xref> requires package definitions to specify the name of
their package or template-package.</t>
<t>The name of this template-package is "watcher-count". It cannot be applied to
any other package. Recursive template-packaging is
not allowed.</t>
</section>
<section title="Event Package Parameters">
<t><xref target="RFC3265"></xref> requires package and template-package definitions to
specify any package specific parameters of the Event header field.</t>
<t>A single parameter "PNA" is defined. The parameter indicates pna-presentity-list URI.</t>
</section>
<section title="SUBSCRIBE Bodies">
<t><xref target="RFC3265"></xref> requires package or template-package definitions to
define the usage, if any, of bodies in SUBSCRIBE requests.</t>
<t>No bodies are defined for the watcher-count package.</t>
</section>
<section title="Subscription Duration">
<t><xref target="RFC3265"></xref> requires package definitions to define a default value
for subscription durations, and to discuss reasonable choices for
durations when they are explicitly specified.
</t><t>
The PNA typically supports a large number of presentities, which typically have
watchers come and go. The PNA wants notifications for any of the presentities on its
list. Therefore, the duration of the subscription is typically
long. The default value for the subscription duration is one day.
However, clients SHOULD use an
Expires header field to specify their preferred duration.</t>
</section>
<section title="NOTIFY Bodies">
<t><xref target="RFC3265"></xref> requires package definitions to describe the allowed set
of body types in NOTIFY requests, and to specify the default value to
be used when there is no Accept header field in the SUBSCRIBE
request.
</t><t>
The body of the watcher-count notification contains a watcher-count document.
This document contains a list of presentities in the
pna-presentity list whose watcher count went from 0 to 1 or 1 to 0 and the current
watcher count (which will always be zero or one). All watcher-count subscribers
and notifiers MUST support the application/watcher-count+xml format described
in herein, and MUST list its MIME type, application/watcher-count+xml, in any Accept
header field present in the SUBSCRIBE request.
</t><t>
Other watcher count formats might be defined in the future. In
that case, the watcher-count subscriptions MAY indicate support of
other formats. However, they MUST always support and list
application/watcher-count+xml as an allowed format.
</t><t>
Of course, the watcher-count notifications generated by the server MUST
be in one of the formats specified in the Accept header field in the
SUBSCRIBE request. If no Accept header field was present, the
notifications MUST use the application/watcher-count+xml format
described herein.</t>
</section>
<section title="Notifier Processing of SUBSCRIBE Requests">
<t><xref target="RFC3265"></xref> specifies that packages should define any package-
specific processing of SUBSCRIBE requests at a notifier, specifically
with regards to authentication and authorization.
</t><t>
Although the number of watchers is less sensitive than identification
of a watcher, watcher information is personal information.
Therefore, all watcher-count subscriptions MUST be
authenticated and then authorized before approval. Authentication
MAY be performed using any of the techniques available through SIP,
including digest, S/MIME, TLS or other transport specific mechanisms
<xref target="RFC3261"></xref>. Authorization policy is at the discretion of the administrator.</t>
<t>Editor Note: There is a timing problem. When a PS gets a SUBSCRIBE, it should
reply immediately with the presence state. However, if this causes watcher-count
to go from 0 to 1, the PS doesn't have good state. It has to NOTIFY the PNA
and wait for a response. That needs to be described here. There may be
further complications with a one time or short subscription.</t>
</section>
<section anchor="notify" title="Notifier Generation of NOTIFY Requests">
<t>The SIP Event framework requests that packages specify the conditions
under which notifications are sent for that package, and how such
notifications are constructed.
</t><t>
Each watcher-count subscription is associated with a set of "inner"
subscriptions being watched. This set is defined by the URI in the
pna-presentity-list. A watcher-count notifier MUST
generate a notification any time the count of watchers in any of the watched
subscriptions goes from zero to at least one, or from one to zero. To optimize the
notification, the PS may delay the issuance of the NOTIFY for a
provisioned period of time. 5 seconds is the suggested default time. The
delay gives the PS an opportunity to gather additional watcher count
changes and send one NOTIFY with all of them recieved in the delay
period. The PS MUST make certain that no watcher count change from zero to
at least one or one to zero is delayed by more than this period.
</t><t>It is RECOMMENDED that a given notification only mention a particular presentity once.
The PNA MUST NOT depend on this behavior. When the same presentity URI is encountered
in more than one wc element's "r" value, the "c" value in the last wc element
determines the watcher count of the presentity following processing in the PNA.
That means that the order of wc elements may matter. The recommended behavior would filter
multiple watcher changes from growing the size of the NOTIFY body.
</t><t>
Upon a successful SUBSCRIBE where no subscription for a particular
pna-presentity-list was extant at the time of the subscription, the initial
NOTIFY from the PS to the PNA MUST have all of the presentities for
which there is at least one watcher. That is, the PNA and PS behave
as if just before the subscription, all presentities on the list had no
watchers. Presentities that actually do have at least one watcher will
be listed in the initial NOTIFY. If at any time the PNA is concerned that
it has lost track of watcher count, it can reSUBSCRIBE, triggering a complete
notification of watcher count.
Note that the size of this initial NOTIFY can be quite large.</t>
</section>
<section anchor="subscriber" title="Subscriber Processing of NOTIFY Requests">
<t><xref target="RFC3265"></xref> expects packages to specify how a subscriber processes
NOTIFY requests in any package specific ways, and in particular, how
it uses the NOTIFY requests to construct a coherent view of the state
of the subscribed resource. The watcher-count NOTIFY will
only contain information about those presentities whose watcher count
changed from zero to at least one, or from one to zero. To construct
a coherent view of the total state of all presentities on the
pna-presentity-list, a watcher-count subscriber will need to combine NOTIFYs
received over time. See <xref target="notify"></xref> for a discussion of how the PNA can trigger
a complete state update from the PS.</t>
</section>
<section title="Handling of Forked Requests">
<t>The behavior of forked requests for watcher-count is not defined and
implementations MUST NOT fork SUBSCRIBE or NOTIFY requests.</t>
</section>
<section title="Rate of Notifications">
<t><xref target="RFC3265"></xref> mandates that packages define a maximum rate of
notifications for their package.
</t><t>
For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED
that the server not generate watcher-count notifications for a single
presentity at a rate faster than once every 5 seconds. See <xref target="subscriber"></xref>
for a discussion of pacing NOTIFY operations for changes to multiple
presentity's watcher count. It is RECOMMENDED that such a pacing mechanism
be used.</t>
</section>
<section title="State Agents">
<t><xref target="RFC3265"></xref> asks packages to consider the role of state agents in
their design.
</t><t>
State agents are not required for watcher-count.</t>
</section></section>
<section title="Watcher-count XML Document">
<section title="Structure of the watcher-count document">
<t>Watcher-count is an XML [ref] document that MUST be well-formed
and SHOULD be valid. Watcher-count documents MUST be based on
XML 1.0 and MUST be encoded using UTF-8. This specification makes
use of XML namespaces for identifying watcher-count documents and
document fragments. The namespace URI for elements defined by this
specification is a URN <xref target="RFC2141"></xref>, using the namespace identifier 'ietf'
defined by <xref target="RFC2648"></xref> and extended by <xref target="RFC3688"></xref>. This URN is:
urn:ietf:params:xml:ns:watcher-count
</t><t>
A watcher-count document begins with the root element tag
"watcher-count-list". It consists of any number of "wc" (for "watcher-count") sub-
elements, each of which is a presentity URI and a count of watchers for
that presentity. The count is either zero or one, where zero means no
watchers are presently receiving any form of presence updates for the
presentity and one means there is at least one active watcher.
Other elements from different namespaces MAY be present
for the purposes of extensibility; elements or attributes from
unknown namespaces MUST be ignored. There are two attributes
associated with the "watcher-count-list" element, both of which MUST be
present:
<list style="hanging">
<t hangText="PNA:">This element contains the URI of a pna-presence-list maintained on
the PS. The presentities in the watcher-count document MUST be on that
list</t>
<t hangText="version:"> This attribute allows the recipient of watcher-count documents
to properly order them. Versions start at 0, and increment by one
for each new document sent to a watcher-count subscriber. Versions
are scoped within a watcher-count subscription. Versions MUST be
representable using a 32 bit integer. However, versions do not
wrap.
</t></list></t>
<t>Each "wc" element contains a list of presentities whose
count of watchers has changed from zero to at least one or from one to
zero. Other
elements from different namespaces MAY be present for the purposes of
extensibility; elements or attributes from unknown namespaces MUST be
ignored. There are two attributes associated with the "wc"
element, both of which MUST be present:
<list style="hanging">
<t hangText="r:">This attribute contains a URI for the resource being
watched. It is mandatory.</t>
<t hangText="c:">This attribute contains an integer value of 0 or 1. Zero means
that there are presently no watchers for this resource. One means there
is at least one watcher.</t>
</list></t>
<t>The names "wc", "r" and "c" are deliberately short, as the document is expected to be long
and contain a great many such elements.</t>
</section>
<section title="Computing Watcher Counts from the Document">
<t>Typically, the watcher-count NOTIFY will only contain information about
those presentities whose state has changed. To construct a coherent view
of the total state of all presentities on the pna-presentity-list,
a watcher-count subscriber will
need to combine NOTIFYs received over time. The watcher-count
subscriber conceptually maintains a table for each presentity on the pna-presentity-list.
Each pna-presentity-list is uniquely identified by the
URI in the "PNA" attribute of the "watcher-count-list" element. Each
table contains a row for each presentity in that list. Each row
is indexed by the URI for that presentity. It is conveyed in the
"r" attribute of the "wc" element. The contents of each row
contain the count of watchers of that presentity as conveyed in the "wc"
element. Other implementations are possible. For example, the PNA
could maintain a list of presentities whose watcher-count is >1 and add/delete
presentities to its list based on notifications it recieves from the PS.
</t><t>
The tables are also associated with a version number. The
version number MUST be initialized with the value of the "version"
attribute from the "watcherinfo" element in the first document
received. Each time a new document is received, the value of the
local version number, and the "version" attribute in the new
document, are compared. If the value in the new document is one
higher than the local version number, the local version number is
increased by one, and the document is processed. If the value in the
document is more than one higher than the local version number, the
local version number is set to the value in the new document, the
document is processed, and the watcherinfo subscriber SHOULD generate
a refresh request to trigger a full state notification. If the value
in the document is less than the local version, the document is
discarded without processing.</t>
</section>
<section title="Example">
<t>The following is an example of watcher-count information.
<figure><artwork><![CDATA[
<?xml version="1.0"?>
<watcher-count-list xmlns="urn:ietf:params:xml:ns:watcher-count"
pna="http://www.example.com/west-pna-presence-list.xml
version="23">
<wc r="sip:+12125551212@example.net" c="1">
<wc r="sip:+12125553333@example.net" c="0">
</watcher-count-list>
]]></artwork></figure></t>
</section>
<section title="XML Schema">
<t>The following is the schema definition of the watcher-count document
format:
<figure><artwork><![CDATA[
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:watcher-count"
xmlns:tns="urn:ietf:params:xml:ns:watcher-count" >
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd" />
<xs:element name="watcher-count">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:watcher-count-list" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="resource" type="xs:anyURI" use="required"/>
<xs:attribute name="version" type="xs:nonNegativeInteger"
use="required"/>
<xs:element name="wc">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:wc" minOccurs="0" maxOccurs=
"unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="r" type="xs:anyURI" use="required"/>
<xs:attribute name="c" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
]]></artwork></figure></t>
</section></section>
<section anchor="IANA" title="IANA Considerations">
<t>This document registers a new MIME type, application/watcher-count+xml,
registers a new XML namespace and registers a new event package.</t>
<section title="application/watcher-count+xml MIME Registration">
<t><list style="hanging">
<t>MIME media type name: application
</t><t>
MIME subtype name: watcher-count+xml
</t><t>
Mandatory parameters: none
</t><t>
Optional parameters: Same as charset parameter application/xml
as specified in <xref target="RFC3023"></xref>.
</t><t>
Encoding considerations: Same as encoding considerations of
application/xml as specified in <xref target="RFC3023"></xref>.
</t><t>
Security considerations: See Section 10 of <xref target="RFC3023"></xref> and
<xref target="security"></xref> of this specification.
</t><t>
Interoperability considerations: none.
</t><t>
Published specification: This document.
</t><t>
Applications which use this media type: This document type is used to support optimization of
publishing operations from a Presence Network Agent to a Presence Server.
</t><t>
Additional Information:
<list style="hanging">
<t> Magic Number: None
</t><t>
File Extension: .wif or .xml
</t><t>
Macintosh file type code: "TEXT"
</t></list></t>
<t>Personal and email address for further information: Brian Rosen <br@brianrosen.net>
</t><t>
Intended usage: COMMON
</t><t>
Author/Change controller: The IETF.</t>
</list></t>
</section>
<section title="URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:watcher-count">
<t>This section registers a new XML namespace, as per the guidelines in
[?].
<list style="hanging">
<t>URI: The URI for this namespace is
urn:ietf:params:xml:ns:watcher-count.
</t><t>
Registrant Contact: IETF, SIMPLE working group,
<simple@ietf.org>, Brian Rosen
<br@brianrosen.net>.
</t><t>
XML:
<figure><artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Watcher Count Namespace</title>
</head>
<body>
<h1>Namespace for Watcher Count</h1>
<h2>urn:ietf:params:xml:ns:watcher-count</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc3858.txt">
RFC3858</a>.</p>
</body>
</html>
END
]]></artwork></figure></t>
</list></t>
</section>
<section title="Package Registration">
<t>This specification registers an event template package as specified
in Section 6.2 of <xref target="RFC3265"></xref>.
<list style="hanging">
<t>Package Name: watcher-count
</t><t>
Template Package: yes
</t><t>
Published Specification: This document
</t><t>
Person to Contact: Brian Rosen, br@brianrosen.net.</t>
</list></t>
</section></section>
<section anchor="security" title="Security Considerations">
<section title="Denial of Service Attacks">
<t>Watcher count generates notifications about changes in the
state of watchers for a particular resource. A single notification
could be extremely large, as in the initial state notification.
This makes a watcher-count
subscription a potential tool for denial of service attacks.
Preventing these can be done through a combination of sensible
authorization policies and good operating principles.
</t><t>
Watcher-count
subscriptions to that resource should only be allowed from explicitly
authorized entities, whose identity has been properly authenticated.
That prevents a watcher-count NOTIFY stream from being generated from
subscriptions made by an attacker.</t>
</section>
<section title="Divulging Sensitive Information">
<t>Watcher count indicates how many users are interested in a
particular resource. Depending on the package and the resource, this
can be very sensitive information.
One way in which this information can be revealed is eavesdropping.
An attacker can observe watcher-count notifications, and learn this
information. To prevent that, watchers MAY use the sips URI scheme
when subscribing to a watcherinfo resource. Notifiers for
watcher-count MUST support TLS and sips as if they were a proxy (see
Section 26.3.1 of <xref target="RFC3261"></xref>).
</t><t>
SIP encryption, using S/MIME, MAY be used end-to-end for the
transmission of both SUBSCRIBE and NOTIFY requests.
</t><t>
Another way in which this information can be revealed is through
spoofed subscriptions. These attacks can be prevented by
authenticating and authorizing all watcher-count subscriptions. In
order for the notifier to authenticate the subscriber, it MAY use
HTTP Digest (Section 22 of <xref target="RFC3261"></xref>). As a result, all watchers MUST
support HTTP Digest. This is a redundant requirement, however, since
all SIP user agents are mandated to support it by <xref target="RFC3261"></xref>.</t>
</section>
</section><section title="Acknowledgements">
<t>Guy Paradis and Fridy Sharon-Fridman of NeuStar contributed to the ideas in this
document and reviewed the text.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2141;
&rfc2648;
&rfc3023;
&rfc3256;
&rfc3261;
&rfc3265;
&rfc3688;
&rfc3856;
&rfc3857;
&rfc3903;
&rfc4825;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-20 23:59:50 |