Internet DRAFT - draft-brok-simple-regulate-publish
draft-brok-simple-regulate-publish
SIPPING J. Brok
Internet-Draft Bell Labs/Lucent Technologies
Expires: September 7, 2006 March 6, 2006
Regulating Publication of Event State Information
draft-brok-simple-regulate-publish-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Session Initiation Protocol (SIP) Extension for Event State
Publication describes a mechanism for a User Agent Client (UAC) to
publish event state information to a User Agent Server (UAS).
Generally, the UAC is free to monitor certain resources at a certain
rate and publish changes of their event state, for instance with the
presence event package. However, for a UAC on a mobile device, this
can be very costly in terms of battery, computing, and network
resources. Although some mechnisms exist for a UAC to deduce whether
event state publication is needed and at what rate publish messages
Brok Expires September 7, 2006 [Page 1]
Internet-Draft Regulate-Publish March 2006
may be sent, these are rather coarse and reactive in nature. This
memo defines a solution for a UAS to regulate monitoring and
publications by providing detailed information to the UAC regarding
which resources to monitor, at what rate, whether urgent and with
what delta.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
1.2. Definitions and Document Conventions . . . . . . . . . . . 5
2. Problem description . . . . . . . . . . . . . . . . . . . . . 6
2.1. Existing mechanisms . . . . . . . . . . . . . . . . . . . 6
2.2. Quantitative example . . . . . . . . . . . . . . . . . . . 6
2.3. Usage scenarios . . . . . . . . . . . . . . . . . . . . . 7
3. Regulating publications . . . . . . . . . . . . . . . . . . . 9
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 10
4. Package Definition . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Event Package . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Event Package Name . . . . . . . . . . . . . . . . . . 12
4.1.2. Event Package Parameters . . . . . . . . . . . . . . . 12
4.1.3. ISSUE: template package? . . . . . . . . . . . . . . . 12
4.2. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. SUBSCRIBE messages . . . . . . . . . . . . . . . . . . 13
4.2.2. SUBSCRIBE behavior . . . . . . . . . . . . . . . . . . 13
4.2.3. Multiple presentities . . . . . . . . . . . . . . . . 14
4.3. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. NOTIFY messages . . . . . . . . . . . . . . . . . . . 14
4.3.2. NOTIFY behavior . . . . . . . . . . . . . . . . . . . 14
5. Regulate-publish format . . . . . . . . . . . . . . . . . . . 16
5.1. MIME type for regulate-publish document . . . . . . . . . 16
5.2. Example document . . . . . . . . . . . . . . . . . . . . . 16
5.3. The <regulate-set> Root Element . . . . . . . . . . . . . 17
5.4. The <ns-bindings> Element . . . . . . . . . . . . . . . . 17
5.5. The <ns-binding> Element . . . . . . . . . . . . . . . . . 17
5.6. The <regulate> Element . . . . . . . . . . . . . . . . . . 18
5.7. The <constraints> Element . . . . . . . . . . . . . . . . 18
5.8. The <subset> Element . . . . . . . . . . . . . . . . . . . 20
5.9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 20
5.10. Extending regulate-publish . . . . . . . . . . . . . . . . 23
6. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8.1. regulate-publish event package . . . . . . . . . . . . . . 29
8.2. application/regulate-publish+xml MIME type . . . . . . . . 29
Brok Expires September 7, 2006 [Page 2]
Internet-Draft Regulate-Publish March 2006
8.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:regulate-publish . . . . . . . . . 30
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
Brok Expires September 7, 2006 [Page 3]
Internet-Draft Regulate-Publish March 2006
1. Introduction
In accordance with the Event State Publication framework [RFC3903], a
User Agent Client (UAC) sends PUBLISH messages carrying event state
information to a User Agent Server (UAS). The UAS acts as a
compositor of published event state information and may distribute
the composed information, for instance using SIP-specific event
notification [RFC3265].
The formats and rules of published and subscribed information are
defined by event packages. For the presence event package [RFC3856],
the UAS is a Presence Agent (PA), allowing for watchers to receive
updates of presence information through notifications [RFC2778]. The
UAC is a Presence User Agent (PUA), which can be located on the
user's mobile device but also somewhere in the network. On a mobile
device, monitoring resources in order to publish changes of the
presence state can be costly in terms of battery and computing
resources. Even worse, publishing information regularly over a
cellular network can have a dramatic effect on the battery lifetime,
number of messages and transmitted data volume. Also for network
agents, monitoring presence information for large numbers of
presentities can be costly in terms of computing resources and
network traffic. This situation would be improved by a) monitoring
only what is needed, and b) publishing at a rate that is not higher
than necessary.
The Event State Publication framework does not define mechanisms for
a UAC to know whether event state publications are needed, what
subset and how often. Furthermore, it is important to handle
overload situations, as described in
[draft-rosenberg-sipping-overload-reqs-00].
This draft defines a solution for a UAS to regulate PUBLISH messages
by actively providing detailed information to the UAC regarding which
resources to monitor and with what rate limits. In addition, it
allows the UAS to specify the urgency of event state publications, as
well as the required delta of numerical values before publishing
changed event state. The UAC may use this information at its
descretion. This solution will be referred to as "regulate-publish"
in this document.
1.1. Requirements notation
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 [RFC2119].
Brok Expires September 7, 2006 [Page 4]
Internet-Draft Regulate-Publish March 2006
1.2. Definitions and Document Conventions
This document follows the definitions in [RFC3903] and [RFC3265]. In
addition, this document uses presence related definitions from
[RFC2778] and [RFC3856] for illustrative purposes.
Brok Expires September 7, 2006 [Page 5]
Internet-Draft Regulate-Publish March 2006
2. Problem description
2.1. Existing mechanisms
The UAC may use notifications from the watcher information (winfo)
event package [RFC3857] to deduce that there are watchers. This
approach has the following disadvantages.
o Using winfo, a UAC can learn that there is a watcher for presence
notifications, but it does not necessarily mean that the watcher
has access to the presence information (false positive). For
instance, policies or preferences may allow a watcher to
subscribe, but disallow notifications (polite blocking).
o Using winfo, the UAC will know that a watcher has subscribed for
presence notifications, but not the subset of presence information
that the watcher is interested in. Interestingly, watchers using
Event Filter Notification
[draft-ietf-simple-event-filter-funct-05] may provide a means to
give a Presence Agent (i.e. the UAS) this knowledge.
o Similar to above, the watcher may re-subscribe specifying another
event filter. The UAC will not receive winfo notifications in
this case.
In summary, the UAC has no information as to the need for publication
of event state. The UAC could use the winfo notifications for this
purpose, although it only sometimes gives an indication on event
package level and is subject to false positives.
The Event State Publication framework provides limited support for
controlling the rate of publications ([RFC3903], section 9). The
compositor can insist that the client chooses a longer expiration
value. Alternatively, it can respond to a PUBLISH request with a 503
(Service Unavailable) that includes a Retry-After header field. This
is a rather severe method and does not prevent PUBLISH messages in
the first place. Issues with this mechanism are clearly described in
[draft-rosenberg-sipping-overload-reqs-00].
At the time of writing, there has been some work on throttling SIP
Event Notifications. The commonality of all solutions is their
reactive nature: It is not possible for a UAS to actively indicate
that it wants to receive PUBLISH messages, which information they
should contain and with which rate they should be sent.
2.2. Quantitative example
The quantitative example in this section describes the effect of
Brok Expires September 7, 2006 [Page 6]
Internet-Draft Regulate-Publish March 2006
frequent periodic publications on battery lifetime, network behavior,
number of messages and data volume.
Consider a mobile device hosting a UAC and connected to a cellular
network, say CDMA2000/1X-EVDO. Assume for the sake of discussion
that the mobile device uses 5 mA when idle, 100 mA when receiving and
keeping the airlink open, and 500 mA when transmitting. It is easy
to see that with a battery of 1000 mAH, the standby time is about 200
hours, and the talk time is about 2 hours. Furthermore, every time
data is about to be exchanged over the network, the device needs some
time (sub-second) to establish an open airlink, and keeps it open for
as many as 10 seconds.
With these numbers, a periodic publication of once every 10 minutes
can decrease the battery lifetime from 200 to about 140 hours.
Publishing every 2 minutes decreases the battery lifetime to about 65
hours, and publishing every 15 seconds (default publication rate of a
GPS device) to as low as 11 hours! Note that the latter number
changes to 22 hours when the airlink stays open for only 3 seconds.
Clearly, it is in the interest of the UAC on a mobile device to know
whether event state publications are necessary at all, and, if so, at
what rate.
Another consideration is that each device with an open airlink
consumes resources (power control subchannels, walsh codes, MAC IDs).
If sufficient devices keep the airlink open for a number of seconds
after data exchange, eventually other devices may be denied.
Clearly, rate limiting periodic publications has a positive effect on
dimensioning a cellular network.
Without rate limiting, the number of messages and associated data
volume can be significant. Consider publication of location
information without retransmissions, using PIDF [RFC3863] and the
extensions RPID [draft-ietf-simple-rpid-10] and [RFC4119]. A device
with GPS support potentially publishes a new location every 15
seconds, causing 240 SIP messages per hour. As another example, a
device monitoring cell IDs to determine its location may see a change
of cell every 2 minutes, causing 60 SIP messages per hour.
When looking at the volume regarding the examples above, assume that
a PIDF document with location information is about 1300 bytes,
including SIP header. Add to that a PUBLISH response of about 240
bytes. The resulting volume for GPS-location is about 300 kB per
hour, and for cell ID-location about 30 kB per hour!
2.3. Usage scenarios
This section lists a number of use cases where the regulate-publish
Brok Expires September 7, 2006 [Page 7]
Internet-Draft Regulate-Publish March 2006
solution would be beneficial. All examples use the presence event
package. Note that some examples describe the use of XPath
expressions, as will be described in Section 5.
1. A mobile device is capable of monitoring its geographical
location using an embedded GPS device. GPS location can be
specified with the GEOPRIV format [RFC4119], which is an
extension of the PIDF format [RFC3863]. GPS location is
accurate, but requires significant battery power when used
continuously. The UAS can use regulate-publish to tell the
mobile device to do a measurement once every 15 minutes. This
may be useful when the user carrying the mobile device (hosting
the UAC) is a field worker, and his location should be tracked
during office hours. With the quantitative calculation from the
previous section, this results in a battery lifetime of about 156
hours compared to 200 hours idle time.
2. A watcher is particularly interested whether a person is in a
noisy or quiet environment. This event state can be expressed
using the 'place-is' parameter of the the RPID format
[draft-ietf-simple-rpid-10]. The watcher specifies the XPath
expression '//person/place-is/audio' in a subscription using
Event Filter Notification
[draft-ietf-simple-event-filter-funct-05]. The UAS forwards the
same XPath expression to the UAC. Since the UAC has a microphone
it can determine the sound level. The UAC then decides to send
PUBLISH messages only whenever the audio status changes.
3. The UAC on a mobile device contains voice-analysis software to
detect the user's mood. Since this is a computing intensive and
therefore battery power consuming process, it is disabled by
default. Whenever a watcher of the user's presence information
has specifically subscribed for mood information, the UAS sends a
message to the UAC containing the XPath expression: 'presence/
person/mood' (PIDF, RPID).
Brok Expires September 7, 2006 [Page 8]
Internet-Draft Regulate-Publish March 2006
3. Regulating publications
This section introduces the baseline functionality for regulating
publication of event state information. This section is
informational in nature. It does not contain any normative
statements.
3.1. Overview
This document defines a regulate-publish subscription model to be
used concurrently with the publication messages to be regulated. In
this model, the UAC subscribes with the UAS for notifications of the
"regulate-publish" event package. This event package is defined in
Section 4. The SUBSCRIBE message from the UAC includes the name of
the package for which the UAC publishes event state information, for
instance presence. Upon acceptance of the subscription, the UAS
sends NOTIFY messages to the UAC with regulation information. The
UAC may use the regulation information at its own discretion; it is
not a directive but a suggestion that helps the UAC to influence the
monitoring of resources and limit the number of PUBLISH messages.
A typical flow of messages would be (message 2xx responses omitted):
UAC UAS
|-----SUBSCRIBE---->| M1: regulate-publish
|<------NOTIFY------| M2: regulate-publish
|------PUBLISH----->| M3: presence
| |
|------PUBLISH----->| M4: presence
|<------NOTIFY------| M5: regulate-publish
|------PUBLISH----->| M6: presence
The PUBLISH messages use the presence event package as an example.
Figure 1
The UAC sends a SUBSCRIBE message (M1), subscribing for notifications
from UAS regarding regulation of publications. M1 also contains
information about the event package of the PUBLISH messages
('presence' in the example), and optionally more detailed information
(see Section 4.2.1). At successful subscription, M1 is followed by a
NOTIFY message M2, containing initial information to regulate PUBLISH
messages in terms of their rate and subset of the information. Based
on the NOTIFY message, the client can optimize its monitoring process
and send PUBLISH messages (M3 and M4) upon event state information
changes. Message M5 tells the client that the UAS requests a changed
regulation of publications, for instance at a lower rate (or even not
at all). M6 is the next PUBLISH message in response to M5.
Brok Expires September 7, 2006 [Page 9]
Internet-Draft Regulate-Publish March 2006
Note that the UAC is responsible for maintaining the subscription
dialog for regulation information by sending refresh SUBSCRIBE
messages. The UAC is free to adhere to the regulation information in
the NOTIFY messages.
As a consequence, the UAC may send PUBLISH messages at a higher rate
than suggested by a regulate-publish NOTIFY message. In accordance
with [RFC3903], the UAS has no reason to ignore or reject the PUBLISH
message. If the UAS cannot or is not willing to accept a PUBLISH
message due to too high a rate, it can can respond with a 503
(Service Unavailable) that includes a Retry-After header field.
3.2. Benefits
The regulate-publish subscription dialog does add extra overhead for
both UAC and UAS. However, with only one subscription dialog,
detailed information from one or more event packages can be
described. In essence, this implements a kind of 'control channel'
from the UAS towards the UAC. Given the fact that the UAS needs to
maintain state for each UAC anyway, we simply create a more symmetric
channel.
From Section 2.3 it is evident that the regulate-publish solution
results in less messages. With the extensions of the PIDF format for
presence, such as RPID [draft-ietf-simple-rpid-10] and GEOPRIV
[RFC4119], the UAC potentially monitors various resources and sends
PUBLISH messages frequently. Providing the UAC with feedback about
the subset, rate, urgency and required delta of publication updates
allows for cutting down on PUBLISH messages. Note that it is
straightforward for the UAS to send so many NOTIFY messages that the
gain is lost. The optimal rate depends on the targeted event
package, subset of the information, UAC, and sensors used by the UAC.
It is outside the scope of this document to specify the recommended
rate of NOTIFY messages.
Section 2.2 shows that decreasing the number of PUBLISH messages is
particularly beneficial for a UAC on a mobile device, connected with
the UAS through a wireless link.
Finally, a significant benefit of a decreased the number of PUBLISH
messages is a proportional decrease of event state composition in the
UAS.
3.3. Alternatives
_This section is included for discussion purposes and may be removed
at a later stage._
Brok Expires September 7, 2006 [Page 10]
Internet-Draft Regulate-Publish March 2006
An alternative approach of a 'reverse' subscription is not
considered. In this approach, a UAS would subscribe for information
updates with the UAC, thereby omitting the PUBLISH mechanism. This
would not be compliant with the model for Presence and Instant
Messaging [RFC2778], which states: "The presentity initiates changes
in the presence information to be distributed by the presence
service". Here, the presentity is represented by the UAC and the
presence service is the UAS. Furthermore, PUBLISH is designed as a
lightweight mechanism to make presence information from multiple
sources available to a UAS. A UAS subscribing with every presence
source does not scale well, and is difficult to configure and manage.
The advantage of the regulate-publish mechanism is that the UAS does
not need to have a preconfigured list of presence sources, and that
not every presence source needs to support regulate-publish (e.g.
only wireless devices).
Another disadvantage of a 'reverse' subscription is that it would not
provide a solution for indicating desired frequency of notifications,
although other aspects would be supported using the Event
Notification Filtering mechanism
[draft-ietf-simple-filter-format-05]. It is expected that for a UAC
with limited computing and memory capacity, the process of accepting
subscriptions and sending notifications is 'heavier' than the process
of publishing and initiating subscriptions. Adding Event
Notification Filtering or an extension of it would add even more
computing and memory overhead, which makes it less suitable for
mobile devices.
It is not considered to match the regulate-publish subscription with
the SIP-ETag value of the PUBLISH 2xx responses. Doing so would mean
that an initial PUBLISH message is required. It may be beneficial
for the UAC to first figure out whether publication of event state
information is needed at all, and allows for additional savings for a
mobile device in terms of startup time, battery power and computing
power.
Brok Expires September 7, 2006 [Page 11]
Internet-Draft Regulate-Publish March 2006
4. Package Definition
This section defines the regulate-publish event package and contains
normative statements.
4.1. Event Package
4.1.1. Event Package Name
The name of this package is 'regulate-publish'. As specified in
[RFC3265], this value MUST be defined in the Event header field of
SUBSCRIBE and NOTIFY requests. For an example, see next section.
4.1.2. Event Package Parameters
The event header field MUST contain a event package parameter named
'regulate'. This parameter indicates the package name of the PUBLISH
messages to be regulated. This parameter MAY include multiple
package names, separated by commas, to indicate regulation
publications of multiple event packages. Examples:
Event: regulate-publish; regulate='presence'
Event: regulate-publish; regulate='presence,xyz'
The Event header MAY also contain an "id" parameter, as mandated by
[RFC3265].
4.1.3. ISSUE: template package?
_This section is included for discussion purposes and may be removed
at a later stage._
Instead of defining 'regulate-publish' as a normal event package, it
may be possible to define it as a template event package. When
regulating presence publications, the Event header would look like
(see [RFC3265] section 4.2):
Event: presence.regulate-publish
Unsure if regulate-publish as a template event package can be applied
to any arbitrary package, as required. It seems this only makes
sense for packages that support publication of event state. Presence
seems to be the only package so far. Certainly, applying regulate-
publish to itself does not make any sense. A minor issue is that
this mechanism does not allow for regulating publications of multiple
event packages, as shown in the example of Section 4.1.2. Proposal:
NOT a template event package.
Brok Expires September 7, 2006 [Page 12]
Internet-Draft Regulate-Publish March 2006
4.2. SUBSCRIBE
SUBSCRIBE messages MUST follow the specification of [RFC3265].
4.2.1. SUBSCRIBE messages
The UAC sends a SUBSCRIBE message to the UAS specifying for which
event package(s) to regulate publications. The UAC MUST send
regulate-publish SUBSCRIBE messages to the same destination URI(s) it
would send regulated PUBLISH messages to (i.e. the UAS). The UAC
MUST NOT subscribe more than once to the same target URI (i.e. can
only have a single subscription dialog).
The SUBSCRIBE message MAY contain a body. Without a body, the UAS is
free to regulate any information carried by the event package(s)
specified with the 'regulate' parameter (i.e. used by the PUBLISH
messages). Without a body, and when applied to presence, the
guidelines defined in section 5 of [RFC3856] MUST be followed, which
provides a means to identify the presentity in the presence
publications (see also Section 4.2.3).
A SUBSCRIBE message containing a body provides the UAS with more
details on what information can be regulated. The UAS MAY ignore the
information in the body. SUBSCRIBE messages with a body SHOULD use
the 'regulate-publish' data format and specify 'application/
regulate-publish+xml' (see Section 5.1) in the Content-Type header
field. Other MIME types MAY be specified for future purposes.
_Issue: use the Accept field to define which MIME types the client
supports in the NOTIFY messages? (i.e. 'application/
regulate-publish+xml')_
4.2.2. SUBSCRIBE behavior
The UAS MUST apply the same access control policy to SUBSCRIBE
requests as PUBLISH messages for the targeted event package(s). In
other words, only UACs that are allowed to publish information are
also allowed to subscribe with regulate-publish.
In order to minimize the overhead, the UAC SHOULD specify a
subscription duration of 1 hour or longer. The UAS SHOULD use a
default 'Expires' value of 2 hours if the UAC does not specify a
value. The UAC and UAS MUST NOT specify a subscription duration of
less than 30 minutes.
The expiry parameter from SUBSCRIBE responses must be used to refresh
the subscription or invalidating the regulation information set by
the notification.
Brok Expires September 7, 2006 [Page 13]
Internet-Draft Regulate-Publish March 2006
The regulate-publish event package MUST support forking of SUBSCRIBE
messages. See further Section 4.3.2.
When using the regulate-publish data format for SUBSCRIBE messages,
the UAS can interpret the data to learn what subset of the
information of an event package (such as presence) the UAC allows to
be regulated. Furthermore, the <constraints> element (see
Section 5.7) may provide hints as to what minimum and maximum
interval the UAC can send PUBLISH messages. It is RECOMMENDED that
the UAS interprets the body of regulate-publish SUBSCRIBE messages.
In particular, it is RECOMMENDED that the UAS requests publications
at a rate that is not higher than indicated by the UAC in the
SUBSCRIBE body.
4.2.3. Multiple presentities
For UACs that publish information for a large number of presentities,
it may be useful to subscribe with regulate-publish to the UAS only
once, and not for every presentity. To support this, it is
RECOMMENDED that the UAS defines a URI representing multiple
presentities (all or just a subset), which is to be used in the
header and body (if present) of SUBSCRIBE and NOTIFY regulate-publish
messages. The specification of such a URI is outside the scope of
this document.
4.3. NOTIFY
NOTIFY messages MUST follow the specification of [RFC3265].
4.3.1. NOTIFY messages
The UAS sends a NOTIFY message to the UAC specifying for which event
package(s) to regulate publications, including detailed regulation
parameters. Like with the SUBSCRIBE message, the event package to
regulate ('regulate' parameter, see Section 4.1.2) MUST be defined.
The NOTIFY message MUST contain a body. NOTIFY messages SHOULD
specify 'application/regulate-publish+xml' (see Section 5.1) in the
Content-Type header field. Other MIME types MAY be specified for
future purposes.
4.3.2. NOTIFY behavior
The UAC MAY choose to ignore the regulation information from all
NOTIFY messages. (Note that at any time, the UAC may terminate the
regulate-publish subscription.) Interpretation of any information
carried in the NOTIFY bodies is outside the scope of this
specification.
Brok Expires September 7, 2006 [Page 14]
Internet-Draft Regulate-Publish March 2006
De UAC maintains no more than one subscription dialog per URI, other
than for reasons of forking (see further in this section). Each
NOTIFY message overrides the previous one (within a subscription
dialog), given by the compelling reason for a simpler state-machine
in the UAC. The UAS and UAC do not support incremental
notifications, unless defined in future specifications. The NOTIFY
body may support multiple regulation elements, for instance a single
request to publish GPS location once and a continuous detection for a
noisy environment. If multiple regulation elements conflict, the UAC
can decide to ignore one or all of them.
_Issue: the UAC could respond to a NOTIFY message with conflicting
information with an informative message in the body of the OK
response. This may be useful feedback for the UAS. Such a body
could contain one ore more sets of XPath expressions and error
codes._
[RFC3265] mandates that packages define a maximum rate of
notifications for their package. For reasons of congestion control,
it is important that the rate of notifications not become excessive.
Therefore, it is RECOMMENDED that the UAS does not generate regulate-
publish notifications for a single subscriber at an average rate
higher than every 15 minutes. The UAS MUST not generate regulate-
publish notifications for a single subscriber at an average rate
higher than every 5 minutes.
The regulate-publish event package MUST support forking of SUBSCRIBE
messages. As a result, the UAC MUST be prepared to support multiple
subscription dialogs, and support NOTIFY requests with "From:" tags
that differ from the "To:" tag received in the SUBSCRIBE 200-class
response, as mandated by [RFC3265]. The UAC MAY merge notifications
from multiple subscriptions. Also, the UAC MAY ignore notifications
from multiple subscriptions. The UAC is free to merge the regulation
information in any way. The UAC MUST be prepared to deal with
conflicting regulation information from multiple dialogs.
Brok Expires September 7, 2006 [Page 15]
Internet-Draft Regulate-Publish March 2006
5. Regulate-publish format
This section defines the 'regulate-publish' data format and contains
normative statements. The XML schema definition can be found in
Section 5.9.
The regulate-publish data format is an XML document [XML] that MUST
be well-formed and MUST be valid according to schemas, including
extension schemas, available to the validater and applicable to the
XML document. The regulate-publish documents MUST be based on XML
1.0 and MUST be encoded using UTF-8.
The namespace identifier for elements defined by this specification
is a URN [RFC2141], using the namespace identifier 'ietf' defined by
[RFC2648] and extended by [RFC3688]. This urn is:
'urn:ietf:params:xml:ns:regulate-publish'.
5.1. MIME type for regulate-publish document
The MIME type for the regulate-publish document is 'application/
regulate-publish+xml'. Any transport protocol (such as SIP
[RFC3261]) that is used to carry the regulation information and
payload type information MUST identify the payload as MIME type
'regulate-publish+xml' (for example: a Content-Type header field).
5.2. Example document
This section contains informative statements.
The regulate-publish data format can be used by both SUBSCRIBE and
NOTIFY messages of the regulate-publish event package. As a body of
a SUBSCRIBE message, the UAC suggests what can be regulated. As a
body of a NOTIFY message, the UAS suggests what to be regulated.
This data format provides a fine grained specification of the subset
of event state information to be regulated. It also allows to
specify subsets of multiple event packages and/or data formats
subject to regulation using XPath-based expressions.
Brok Expires September 7, 2006 [Page 16]
Internet-Draft Regulate-Publish March 2006
Example regulate-publish document as part of a NOTIFY message:
<?xml version="1.0" encoding="UTF-8"?>
<regulate-set xmlns="urn:ietf:params:xml:ns:regulate-publish">
<ns-bindings>
<ns-binding prefix="pidf" urn="pidf_urn"/>
<ns-binding prefix="gml" urn="gml_urn"/>
</ns-bindings>
<regulate id="123" uri="sip:presentity@domain.com"
package="presence">
<constraints occurrence="5" min-interval="60" urgent="true"/>
<subset type="xpath">
pidf:presence//gml:location
</subset>
</regulate>
</regulate-set>
Figure 2
5.3. The <regulate-set> Root Element
The root element of the regulate-publish format is <regulate-set>,
which MUST contain the namespace declaration
'urn:ietf:params:xml:ns:regulate-publish' as the value of a 'xmlns'
attribute.
The <regulate-set> element MAY contain a single <ns-bindings>
element.
The <regulate-set> element MUST contain at least one <regulate>
element.
5.4. The <ns-bindings> Element
The <ns-bindings> element is used to bind namespaces to local
prefixes used in expressions that select elements or attributes using
the syntax in section 4 of [draft-ietf-simple-filter-format-05].
These prefixes apply to the XPath data of the <subset> element. The
<ns-bindings> element MUST be defined if XPath expressions are
present in the XML document. The <ns-bindings> element SHOULD NOT be
defined if XPath expressions are not present in the XML document.
The <ns-bindings> element contains one or more <ns-binding> elements.
5.5. The <ns-binding> Element
The <ns-binding> element supports the following attributes:
Brok Expires September 7, 2006 [Page 17]
Internet-Draft Regulate-Publish March 2006
o Mandatory 'prefix' attribute, which is a prefix used to qualify
the elements pointed to by an expression.
o Mandatory 'urn' attribute, which identifies the namespace that the
prefix represents.
5.6. The <regulate> Element
The <regulate> element MAY contain a single <constraints> element.
The <regulate> element MAY contain zero or more <subset> elements.
The <regulate> element supports the following attributes:
o Mandatory 'id' attribute, which MUST be unique within each
regulate element. The value has no particular meaning.
o Mandatory 'uri' attribute, which is the URI of the resource that
the filter applies to. This URI MUST be the same as used in
PUBLISH messages to be regulated.
o Mandatory 'package' attribute, which MUST also be defined in the
regulate event package parameter (see Section 4.1.2).
Multiple <regulate> elements MAY contain different event packages to
be regulated. For instance, one element may suggest to regulate
'pidf:presence//pidf:contact' from the presence event package and a
second element may suggest to regulate 'weather[@sunshine="true"]'
from an imaginary weather event package.
When multiple <regulate> elements contain the same event package
specification, their <subset> elements MUST contain different XPath
specifications, and one of the <regulate> elements MAY omit the
<subset> element. Both UAC and UAS MUST interpret a <regulate>
element without a <subset> element to cover all information from the
target event package that is not covered by the preceding <regulate>
elements.
5.7. The <constraints> Element
The information in an <constraints> element applies to all <subset>
elements in a <regulate> element. The <constraints> element supports
the following attributes:
o Optional 'occurrence' attribute suggests the number of PUBLISH
messages, for instance 0 for no more messages and 1 for one-shot.
This attribute has no meaning when used in the body of SUBSCRIBE
messages. When omitted, the UAS does not specify how many PUBLISH
Brok Expires September 7, 2006 [Page 18]
Internet-Draft Regulate-Publish March 2006
messages are desired.
o Optional 'min-interval' attribute suggests that PUBLISH messages
are required repeatedly with specified minimum interval in seconds
('not sooner than') when used in the body of NOTIFY messages.
When omitted, the UAS does not specify the minimum interval
between PUBLISH messages. When used in the body of SUBSCRIBE
messages, it defines the minimum interval with which the UAC is
able or willing to send PUBLISH messages.
o Optional 'max-interval' attribute suggests that PUBLISH messages
are required repeatedly with specified maximum interval in seconds
('not later than') when used in the body of NOTIFY messages. This
value MUST be greater or equal to the 'min-interval' attribute, if
specified. When omitted, the UAS does not specify the maximum
interval between PUBLISH messages. This attribute has no meaning
when used in the body of SUBSCRIBE messages.
o Optional boolean 'urgent' attribute indicates how urgent the UAS
requires a PUBLISH message with the information specified with the
XPath expression. The value can be '0', 'false' (not urgent) or
'1', 'true' (urgent). This attribute provides a hint to the UAC
to monitor and send PUBLISH messages. It is RECOMMENDED that the
UAC sends a PUBLISH message immediately after a NOTIFY message
containing urgent=true, even if the data to be published has not
changed since the previous PUBLISH message. The priority field
from the SIP header (if present) should not be used for this
purpose since the NOTIFY body may contain multiple filters with
different urgency values. This attribute has no meaning when used
in the body of SUBSCRIBE messages.
The occurrence and min-interval attributes may be used together; a
good use case is to measure and publish just x locations y minutes
apart to calculate speed and direction. The UAC should normally not
send PUBLISH messages with unchanged data. The min-interval
attribute provides a good direction for the monitoring rate.
If the max-interval attribute has been defined, it is RECOMMENDED
that the UAC sends a PUBLISH message with the specified interval.
Note that even though the published information may not have changed,
the fact that it is sent at another moment in time makes them
different (i.e. a refresh). Since this feature may cause excessive
PUBLISH messages, it is recommended to use it sparingly, together
with a restrictive subset, and with a large value (e.g. 600 or more).
Note that the UAS cannot mandate a minimum or maximum publication
rate through the regulate-publish event packages. At all times, the
UAC is reponsible for deciding when to publish a change in event
Brok Expires September 7, 2006 [Page 19]
Internet-Draft Regulate-Publish March 2006
state. For instance, for integrity reasons, the UAC should publish
basic service state (/presence/tuple/status/basic) every time its
value changes. The interval specification is most useful for
continuous publications such as location measured with GPS. The same
applies to requested delta for numerical information. At all times,
the UAC MUST adhere to the maximum rate of publications as described
by [RFC3903] and the target event package (if any).
5.8. The <subset> Element
The <subset> element supports the following attributes and value:
o Mandatory 'type' attribute defining the format of the subset of
the regulate data. When used in the regulate-publish event
package, the UAC and UAS MUST support "xpath".
o Optional 'delta' attribute indicates the minimum change of a
numerical value before the UAC can (in SUBSCRIBE) or needs to (in
NOTIFY) send a PUBLISH message. The XPath expression must select
a numerical element or attribute.
o Optional 'uom' attribute indicates the units of measurement of the
numerical value specified by the XPath expression and, if present,
the 'delta' attribute. Note that the 'uom' attribute can also be
found in GML (see [RFC4119]). The XPath expression must select a
numerical element or attribute.
o Mandatory value, defining the subset of the regulate data, e.g. an
XPath expression. Expansion of namespaces is done according to
the given <ns-bindings> definitions. The XPath expression used in
the <subset> element MUST follow the definition in section 4 of
[draft-ietf-simple-filter-format-05].
Some example XPath expressions (namespace prefixes omitted):
o /presence/person/activities
o //place-is/audio
o /*/device[user-input="active"]
o //contact[@priority>0.7]
5.9. XML Schema
XML Schema Implementation (normative).
<?xml version="1.0" encoding="UTF-8"?>
Brok Expires September 7, 2006 [Page 20]
Internet-Draft Regulate-Publish March 2006
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:regulate-publish"
xmlns="urn:ietf:params:xml:ns:regulate-publish"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- 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/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition for regulate-publish.
</xs:documentation>
</xs:annotation>
<xs:element name="regulate-set" type="RegulateSetType"/>
<xs:complexType name="RegulateSetType">
<xs:sequence>
<xs:element name="ns-bindings" type="NSBindings"
minOccurs="0" maxOccurs="1"/>
<xs:element name="regulate" type="RegulateType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NSBindings">
<xs:sequence>
<xs:element name="ns-binding" type="NSBinding"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NSBinding">
<xs:attribute name="prefix" type="xs:string" use="required"/>
<xs:attribute name="urn" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="RegulateType">
<xs:sequence>
<xs:element name="constraints" type="ConstraintsType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="subset" type="SubsetType"
minOccurs="0" maxOccurs="unbounded"/>
Brok Expires September 7, 2006 [Page 21]
Internet-Draft Regulate-Publish March 2006
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:attribute name="package" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="ConstraintsType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="occurrence" type="xs:nonNegativeInteger"
use="optional"/>
<xs:attribute name="min-interval" type="xs:nonNegativeInteger"
use="optional"/>
<xs:attribute name="max-interval" type="xs:nonNegativeInteger"
use="optional"/>
<xs:attribute name="urgent" type="xs:boolean"
use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="SubsetType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="type" type="xs:string"
use="required"/>
<xs:attribute name="delta" type="xs:float"
use="optional"/>
<xs:attribute name="uom" type="xs:string"
use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:simpleType name="precentageType">
<xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Brok Expires September 7, 2006 [Page 22]
Internet-Draft Regulate-Publish March 2006
Figure 3
5.10. Extending regulate-publish
All elements of regulate-publish XML documents may be extended, with
the exception of <ns-bindings> and <ns-binding>. Such extensions
should use namespace designators such as
'urn:ietf:params:xml:ns:regulate-publish:ext', where 'ext' is the
name of the extension.
In addition to the XML Schema to validate the extension, and
registration of the extension name with IANA, RFCs defining
extensions MUST discuss the semantics of the extensions when used in
the body of SUBSCRIBE and NOTIFY regulate-publish messages.
Brok Expires September 7, 2006 [Page 23]
Internet-Draft Regulate-Publish March 2006
6. Example Usage
The following example shows the body of a SUBSCRIBE message from the
UAC. It indicates that it supports regulation of publishing the
location of the device hosting the UAC, in particular using GPS and
cellular network technology, with certain minimum intervals. The SIP
message header is not shown.
<?xml version="1.0" encoding="UTF-8"?>
<regulate-set xmlns="urn:ietf:params:xml:ns:regulate-publish">
<ns-bindings>
<ns-binding prefix="gp"
urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
<ns-binding prefix="gml"
urn="urn:opengis:specification:gml:schema-xsd:feature:v3.0"/>
</ns-bindings>
<regulate id="700" uri="sip:presentity@domain.com"
package="presence">
<constraints min-interval="15"/>
<subset type="xpath">
//gml:location[*/gp:geopriv/gp:method="GPS"]
</subset>
</regulate>
<regulate id="701" uri="sip:presentity@domain.com"
package="presence">
<constraints min-interval="300"/>
<subset type="xpath">
//gml:location[*/gp:geopriv/gp:method="Cell"]
</subset>
</regulate>
</regulate-set>
Figure 4
The following example is based on use case 1 of Section 2.3. The
UAS, a Presence Agent (PA), requests monitoring the geographical
location, indicating that it needs the location roughly every 15
minutes (900 seconds) in latitude/longitude coordinates. The UAS
does not specify regulation of any other presence information. The
XML document in this example is the body of the NOTIFY message from
the UAS to the UAC on the user's mobile device, the SIP message
header is not shown.
Brok Expires September 7, 2006 [Page 24]
Internet-Draft Regulate-Publish March 2006
<?xml version="1.0" encoding="UTF-8"?>
<regulate-set xmlns="urn:ietf:params:xml:ns:regulate-publish">
<ns-bindings>
<ns-binding prefix="pidf"
urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="gml"
urn="urn:opengis:specification:gml:schema-xsd:feature:v3.0"/>
</ns-bindings>
<regulate id="123" uri="sip:presentity@domain.com"
package="presence">
<constraints min-interval="800" max-interval="1000"/>
<subset type="xpath">
/pidf:presence//gml:location
</subset>
</regulate>
</regulate-set>
Figure 5
The following example is based on use case 2 of Section 2.3. A
watcher is particularly interested whether a person is currently in a
noisy or quiet environment and sends request containing a filter
[draft-ietf-simple-event-filter-funct-05] to the UAS, a Presence
Agent (PA). The UAS determines that the watcher may see this
information and sends a NOTIFY message to the UAC containing a
similar XPath expression and a request to send a single PUBLISH
message with the audio status. The UAS also specifies that the UAC
does not need to publish any other presence information. The XML
document in this example is the body of the NOTIFY message from the
UAS to the UAC on the user's mobile device, the SIP message header is
not shown.
Brok Expires September 7, 2006 [Page 25]
Internet-Draft Regulate-Publish March 2006
<?xml version="1.0" encoding="UTF-8"?>
<regulate-set xmlns="urn:ietf:params:xml:ns:regulate-publish">
<ns-bindings>
<ns-binding prefix="rpid"
urn="urn:ietf:params:xml:ns:pidf:rpid"/>
</ns-bindings>
<regulate id="456" uri="sip:presentity@domain.com"
package="presence">
<constraints occurrence="1" urgent="1"/>
<subset type="xpath">
//rpid:place-is/rpid:audio
</subset>
</regulate>
<regulate id="125" uri="sip:presentity@domain.com"
package="presence">
<constraints occurrence="0"/>
</regulate>
</regulate-set>
Figure 6
The following example shows that the UAS, a Presence Agent (PA),
requests the UAC to publish any presence data in any way appropriate.
Such a notification can be used to cancel previous notifications
where specific presence data has been regulated. The XML document in
this example is the body of the NOTIFY message from the UAS to the
UAC on the user's mobile device, the SIP message header is not shown.
<?xml version="1.0" encoding="UTF-8"?>
<regulate-set xmlns="urn:ietf:params:xml:ns:regulate-publish">
<regulate id="124" uri="sip:presentity@domain.com"
package="presence"/>
</regulate-set>
Figure 7
The following example shows that the UAS requests a UAC equipped with
a thermometer to send a new PUBLISH message with a temperature update
only if the change in temperature is at least 5 degrees Celsius since
the previous PUBLISH message. For this example, an imaginary
extension 'temp' of the RPID format [draft-ietf-simple-rpid-10] is
used. The XML document in this example is the body of the NOTIFY
message from the UAS to the UAC on the user's mobile device, the SIP
message header is not shown.
Brok Expires September 7, 2006 [Page 26]
Internet-Draft Regulate-Publish March 2006
<?xml version="1.0" encoding="UTF-8"?>
<regulate-set xmlns="urn:ietf:params:xml:ns:regulate-publish">
<ns-bindings>
<ns-binding prefix="rpid"
urn="urn:ietf:params:xml:ns:pidf:rpid"/>
<ns-binding prefix="temp"
urn="urn:ietf:params:xml:ns:pidf:rpid:temp"/>
</ns-bindings>
<regulate id="130" uri="sip:presentity@domain.com"
package="presence">
<subset type="xpath" delta="5" uom="#degreesCelsius">
//temp:temperature
</subset>
</regulate>
</regulate-set>
Figure 8
Brok Expires September 7, 2006 [Page 27]
Internet-Draft Regulate-Publish March 2006
7. Security Considerations
An important observation is the security and privacy aspects of a
mechanism to influence publication of event state information. One
could consider it a threat if an entity other than the user's device
has the ability to request for privacy sensitive information.
However, given the idea that the client must initiate publication of
information, the same security issues using PUBLISH according to
[RFC3903] apply. Furtermore, the UAC may choose to ignore the
regulation information. It would be a good practice to provide some
sort of feedback to the user whenever the compositor requests (more)
frequent information updates, as well as the possibility for the user
to block this.
The regulate-publish event package MUST follow the specification of
the Security Considerations in [RFC3265].
As specified in section Section 4.2.2, only UACs that are allowed to
publish information are also allowed to subscribe with regulate-
publish. This prevents DoS attacks by malicious subscribers.
[RFC3265] describes several mechanisms to mitigate DoS attacks.
Brok Expires September 7, 2006 [Page 28]
Internet-Draft Regulate-Publish March 2006
8. IANA Considerations
This document registers a new event package and two new MIME types
and XML namespaces.
This specification follows the guidelines of [RFC3023].
8.1. regulate-publish event package
This specification registers an event package as specified in Section
6.2 of [RFC3265].
Package Name: regulate-publish
Template Package: no
Published Specification: not yet determined
Person to Contact: Jacco Brok, brok@lucent.com.
8.2. application/regulate-publish+xml MIME type
MIME media type: application
MIME subtype name: regulate-publish+xml
Mandatory parameters: (none)
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023.
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023.
Security considerations: See section 10 of RFC 3023 and Section 7 of
this document.
Interoperability considerations: none.
Published specification: This document.
Applications which use this media type: This document type has been
used to support the SIP-based Event Notification framework [RFC3265],
the SIP-based Event State Publication framework [RFC3903] and its
packages.
Additional information:
Brok Expires September 7, 2006 [Page 29]
Internet-Draft Regulate-Publish March 2006
Magic number: (none)
File extension: .cl or .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Jacco Brok
(brok@lucent.com)
Intended Usage: LIMITED
Author/change controller: The IETF
8.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:regulate-publish
This section registers a new XML namespace, as per guidelines in URN
document [RFC3688].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:regulate-publish.
Registrant Contact: IETF, SIPPING working group, Jacco Brok
(brok@lucent.com)
XML:
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>Regulate-Publish Namespace</title>
</head>
<body>
<h1>Namespace for Regulate-Publish information</h1>
<h2>application/regulate-publish+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
Figure 9
Brok Expires September 7, 2006 [Page 30]
Internet-Draft Regulate-Publish March 2006
9. Acknowledgements
The author would like to thank Vijay Gurbani, Jeroen van Bemmel and
Arjan Peddemors for their valuable input. This work is part of the
Freeband AWARENESS project (<http://awareness.freeband.nl>).
Freeband is sponsored by the Dutch government under contract BSIK
03025.
Brok Expires September 7, 2006 [Page 31]
Internet-Draft Regulate-Publish March 2006
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "The URN Syntax", RFC 2141, May 1997.
[RFC2648] Moats, R., "The URN Namespace for IETF Documents",
RFC 2648, August 1999.
[RFC3023] Murata, M., St.Laurent, S., and D. Kohn, "Key words for
use in RFCs to Indicate Requirement Levels", RFC 3023,
January 2001.
[RFC3261] Rosenberg, J., "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688,
January 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[XML] Bray, T., "Exensible Markup Language (XML) 1.0 (Second
Edition)", W3C CR CR-xml11-20011006, October 2000.
[draft-ietf-simple-filter-format-05]
Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML) Based Format
for Event Notification Filtering", March 2005.
10.2. Informative References
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000.
[RFC3857] Rosenberg, J., "A Watcher Information Event Template-
Package for the Session Initiation Protocol (SIP)",
RFC 3857, August 2004.
Brok Expires September 7, 2006 [Page 32]
Internet-Draft Regulate-Publish March 2006
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, October 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[draft-ietf-simple-event-filter-funct-05]
Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "Functional Description of Event Notification
Filtering", March 2005.
[draft-ietf-simple-rpid-10]
Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the Presence
Information Data Format (PIDF)", December 2005.
[draft-rosenberg-sipping-overload-reqs-00]
Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol", February 2006.
Brok Expires September 7, 2006 [Page 33]
Internet-Draft Regulate-Publish March 2006
Author's Address
Jacco Brok
Bell Labs/Lucent Technologies
Capitool 5
Enschede 7521 PL
NL
Phone: +31 35 6875717
Email: brok@lucent.com
URI: http://www.lucent.com/
Brok Expires September 7, 2006 [Page 34]
Internet-Draft Regulate-Publish March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Brok Expires September 7, 2006 [Page 35]
