SIMPLE J. Brok Internet-Draft Bell Labs/Lucent Technologies Expires: June 13, 2006 December 10, 2005 Regulating Publication of Event State Information draft-brok-simple-regulate-publish-01.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 June 13, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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, monitoring some resources can be costly in terms of battery and computing, think of GPS or voice analysis. Although some mechnisms exist for a UAC to deduce whether event state publication is needed Brok Expires June 13, 2006 [Page 1] Internet-Draft Regulate-Publish December 2005 and at what rate publish messages 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, with what urgency and what delta. Brok Expires June 13, 2006 [Page 2] Internet-Draft Regulate-Publish December 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 1.2. Definitions and Document Conventions . . . . . . . . . . . 5 2. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 3. Regulating publications . . . . . . . . . . . . . . . . . . . 7 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 8 4. Package Definition . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Event Package . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Event Package Name . . . . . . . . . . . . . . . . . . 10 4.1.2. Event Package Parameters . . . . . . . . . . . . . . . 10 4.1.3. ISSUE: template package? . . . . . . . . . . . . . . . 10 4.2. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. SUBSCRIBE messages . . . . . . . . . . . . . . . . . . 11 4.2.2. SUBSCRIBE behavior . . . . . . . . . . . . . . . . . . 11 4.2.3. Multiple presentities . . . . . . . . . . . . . . . . 12 4.3. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.1. NOTIFY messages . . . . . . . . . . . . . . . . . . . 12 4.3.2. NOTIFY behavior . . . . . . . . . . . . . . . . . . . 12 5. Regulate-publish format . . . . . . . . . . . . . . . . . . . 14 5.1. MIME type for regulate-publish document . . . . . . . . . 14 5.2. Example document . . . . . . . . . . . . . . . . . . . . . 14 5.3. The Root Element . . . . . . . . . . . . . 15 5.4. The Element . . . . . . . . . . . . . . . . 15 5.5. The Element . . . . . . . . . . . . . . . . . 15 5.6. The Element . . . . . . . . . . . . . . . . . . 16 5.7. The Element . . . . . . . . . . . . . . . . 16 5.8. The Element . . . . . . . . . . . . . . . . . . . 17 5.9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 18 5.10. Extending regulate-publish . . . . . . . . . . . . . . . . 20 6. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8.1. regulate-publish event package . . . . . . . . . . . . . . 26 8.2. application/regulate-publish+xml MIME type . . . . . . . . 26 8.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:regulate-publish . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Brok Expires June 13, 2006 [Page 3] Internet-Draft Regulate-Publish December 2005 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, as well as the number of published messages. Also for network agents, monitoring presence information for large numbers of presentities can be costly in terms of computing resources, network traffic and even accounting. This situation would be improved by a) monitoring only what is needed, and b) at a rate that is not higher than necessary. Both mechanisms are described below. The Event State Publication framework does not define mechanisms for a UAC to know whether event state publications are needed, typically when there are subscribed watchers. 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] does 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. Brok Expires June 13, 2006 [Page 4] Internet-Draft Regulate-Publish December 2005 In summary, the UAC has no information as to the need for publication of event state. The UAC can 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. 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. This document 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]. 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 June 13, 2006 [Page 5] Internet-Draft Regulate-Publish December 2005 2. Usage scenarios This section lists a number of use cases where the regulate-publish 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 [draft-ietf-geopriv-pidf-lo-03], 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. 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-09]. 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. 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 June 13, 2006 [Page 6] Internet-Draft Regulate-Publish December 2005 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 June 13, 2006 [Page 7] Internet-Draft Regulate-Publish December 2005 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. It is expected 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-09] and GEOPRIV [draft-ietf-geopriv-pidf-lo-03], 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. Decreasing the number of PUBLISH messages is particularly beneficial for a UAC on a mobile device, connected with the UAS through a wireless link with limited bandwidth and high usage cost. 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 June 13, 2006 [Page 8] Internet-Draft Regulate-Publish December 2005 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. Another disadvantage is that it would not provide a solution for indicating desired frequency with a subscription, 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 June 13, 2006 [Page 9] Internet-Draft Regulate-Publish December 2005 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 June 13, 2006 [Page 10] Internet-Draft Regulate-Publish December 2005 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. It is difficult to suggest a range considered reasonable for the duration of a subscription. However, values of 15 to 60 minutes seem reasonable. The default 'Expires' value to be used if none is specified is 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 June 13, 2006 [Page 11] Internet-Draft Regulate-Publish December 2005 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 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 regulate event package 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 June 13, 2006 [Page 12] Internet-Draft Regulate-Publish December 2005 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 deltas for 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 a rate faster than once every 5 minutes. The UAS MUST not generate regulate-publish notifications for a single subscriber at a rate faster than once every 1 minute. 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 June 13, 2006 [Page 13] Internet-Draft Regulate-Publish December 2005 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 June 13, 2006 [Page 14] Internet-Draft Regulate-Publish December 2005 Example regulate-publish document as part of a NOTIFY message: pidf:presence//gml:location Figure 2 5.3. The Root Element The root element of the regulate-publish format is , which MUST contain the namespace declaration 'urn:ietf:params:xml:ns:regulate-publish' as the value of a 'xmlns' attribute. The element MAY contain a single element. The element MUST contain at least one element. 5.4. The Element The 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 element. The element MUST be defined if XPath expressions are present in the XML document. The element SHOULD NOT be defined if XPath expressions are not present in the XML document. The element contains one or more elements. 5.5. The Element The element supports the following attributes: Brok Expires June 13, 2006 [Page 15] Internet-Draft Regulate-Publish December 2005 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 Element The element MAY contain a single element. The element MAY contain a single element. The 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 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 elements contain the same event package specification, their elements MUST contain different XPath specifications, and one of the elements MAY omit the element. Both UAC and UAS MUST interpret the element without the element to cover all information from the target event package that is not covered by the other elements. 5.7. The Element The 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 messages are desired. Brok Expires June 13, 2006 [Page 16] Internet-Draft Regulate-Publish December 2005 o Optional 'min-interval' attribute suggests that PUBLISH messages are required repeatedly with specified minimum interval in seconds 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 can or is willing to send PUBLISH messages. o Optional 'max-interval' attribute suggests that PUBLISH messages are required repeatedly with specified maximum interval in seconds when used in the body of NOTIFY messages. 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 'urgency' attribute indicates how urgent the UAS requires a PUBLISH message with the information specified with the XPath expression. The value can be between 0 (not urgent at all) and 100 (very urgent). This attribute provides a hint to the UAC to monitor and send PUBLISH messages. It is RECOMMENDED that the UAC send a PUBLISH message immediately after a NOTIFY message with urgency of 100, 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, min-interval and max-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. Of course, if data is not changed, the UAC should normally not send PUBLISH messages. Rather, the interval attributes provide a hint for the monitoring rate. 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 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. 5.8. The Element The element supports the following attributes and value: Brok Expires June 13, 2006 [Page 17] Internet-Draft Regulate-Publish December 2005 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 Mandatory value, defining the subset of the regulate data, e.g. an XPath expression. Expansion of namespaces is done according to the given definitions. The XPath expression used in the 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 Schema Definition for regulate-publish. Brok Expires June 13, 2006 [Page 18] Internet-Draft Regulate-Publish December 2005 Figure 3 5.10. Extending regulate-publish All elements of regulate-publish XML documents may be extended, with the exception of and . 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 June 13, 2006 [Page 20] Internet-Draft Regulate-Publish December 2005 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. //gml:location[*/gp:geopriv/gp:method="GPS"] //gml:location[*/gp:geopriv/gp:method="Cell"] Figure 4 The following example is based on use case 1 of Section 2. 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 June 13, 2006 [Page 21] Internet-Draft Regulate-Publish December 2005 /pidf:presence//gml:location Figure 5 The following example is based on use case 2 of Section 2. 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 June 13, 2006 [Page 22] Internet-Draft Regulate-Publish December 2005 //rpid:place-is/rpid:audio 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. 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 since the previous PUBLISH message. For this example, an imaginary extension 'temp' of the RPID format [draft-ietf-simple-rpid-09] 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 June 13, 2006 [Page 23] Internet-Draft Regulate-Publish December 2005 //temp:temperature Figure 8 Brok Expires June 13, 2006 [Page 24] Internet-Draft Regulate-Publish December 2005 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 June 13, 2006 [Page 25] Internet-Draft Regulate-Publish December 2005 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 June 13, 2006 [Page 26] Internet-Draft Regulate-Publish December 2005 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, SIMPLE working group, Jacco Brok (brok@lucent.com) XML: BEGIN Regulate-Publish Namespace

Namespace for Regulate-Publish information

application/regulate-publish+xml

See RFCXXXX.

END Figure 9 Brok Expires June 13, 2006 [Page 27] Internet-Draft Regulate-Publish December 2005 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 (). Freeband is sponsored by the Dutch government under contract BSIK 03025. Brok Expires June 13, 2006 [Page 28] Internet-Draft Regulate-Publish December 2005 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 June 13, 2006 [Page 29] Internet-Draft Regulate-Publish December 2005 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, October 2004. [draft-ietf-geopriv-pidf-lo-03] Peterson, J., "A Presence-based GEOPRIV Location Object Format", September 2004. [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-09] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", July 2005. Brok Expires June 13, 2006 [Page 30] Internet-Draft Regulate-Publish December 2005 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 June 13, 2006 [Page 31] Internet-Draft Regulate-Publish December 2005 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 (2005). 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 June 13, 2006 [Page 32]