SIMPLE J. Brok Internet-Draft Bell Labs/Lucent Technologies Expires: August 14, 2005 February 10, 2005 Regulating Publication of Event State Information draft-brok-simple-regulate-publish-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 14, 2005. 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 a document based on the Presence Information Data Format (PIDF) for the presence event package. However, for a UAC on a mobile device, Brok Expires August 14, 2005 [Page 1] Internet-Draft Regulate-Publish February 2005 monitoring some resources can be costly in terms of battery and computing, for instance GPS or voice analysis. Although some mechnisms exist for a UAC to deduce whether event state publication is needed and at what rate publish messages may be sent, but 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, the urgency and the required probability. 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 messages . . . . . . . . . . . . . . . . . . . . 11 4.3 SUBSCRIBE behavior . . . . . . . . . . . . . . . . . . . . 11 4.4 NOTIFY messages . . . . . . . . . . . . . . . . . . . . . 12 4.5 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 . . . . . . . . . . . . . . . . . . 16 5.6 The Element . . . . . . . . . . . . . . . . . 16 5.7 The Element . . . . . . . . . . . . . . . . . . . 17 5.8 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8.1 regulate-publish event package . . . . . . . . . . . . . . 23 8.2 application/regulate-publish+xml MIME type . . . . . . . . 23 8.3 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:regulate-publish . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1 Normative References . . . . . . . . . . . . . . . . . . . 26 10.2 Informative References . . . . . . . . . . . . . . . . . . 26 Brok Expires August 14, 2005 [Page 2] Internet-Draft Regulate-Publish February 2005 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . 28 Brok Expires August 14, 2005 [Page 3] Internet-Draft Regulate-Publish February 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 publish messages. This can 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-04] 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. 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. Brok Expires August 14, 2005 [Page 4] Internet-Draft Regulate-Publish February 2005 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. At the time of this writing, work is ongoing 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, containing which info and at what rate. 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 at what rate. In addition, it allows the UAS to specify the urgency of event state publications, as well as the required minimal probability 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 August 14, 2005 [Page 5] Internet-Draft Regulate-Publish February 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. 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 user is in a noisy environment. This event state can be expressed using the place-type parameter of the the RPID format [draft-ietf-simple-rpid-04]. The watcher specifies the XPath expression '//person[place-type="noisy"]' in a subscription using Event Filter Notification [draft-ietf-simple-event-filter-funct-04]. The UAS forwards the same XPath expression to the UAC. The UAC then decides to send PUBLISH messages only whenever the 'noisy' place-type condition starts and ends. 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 containing the XPath expression: 'presence/person/mood' (PIDF, RPID). Brok Expires August 14, 2005 [Page 6] Internet-Draft Regulate-Publish February 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 in parallel 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 descretion; 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, and optionally more detailed information (see Section 4.2). 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 not at all. Brok Expires August 14, 2005 [Page 7] Internet-Draft Regulate-Publish February 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. 3.2 Benefits An extra subscription dialog does add extra overhead for both UAC and UAS. However, the UAC subscribes to 1 event (regulate-publish) with parameters indicating which publications are to be regulated. This could be seen as subscribing to multiple events, but they are all of the same type (content differs) and the subscription itself has a single lifetime. 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-04] 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 probability of publication updates allows for cutting down on PUBLISH messages. As an important advantage, the UAS has less composition of event state information to do. 3.3 Alternatives _This section is included for discussion purposes and may be removed at a later stage._ An alternative approach of a 'reverse' subscription is not considered. In this approach, a UAS would subscribe for information updates with the UAS, thereby omitting the PUBLISH mechanism. This would not be compliant with the model for Presence and Instant Messaging [RFC2778]. Furthermore, 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-04]. 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 Brok Expires August 14, 2005 [Page 8] Internet-Draft Regulate-Publish February 2005 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 August 14, 2005 [Page 9] Internet-Draft Regulate-Publish February 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 will 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 August 14, 2005 [Page 10] Internet-Draft Regulate-Publish February 2005 4.2 SUBSCRIBE messages SUBSCRIBE messages MUST follow the specification of [RFC3265]. 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 SHOULD NOT subscribe more than once to the same target URI. 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. A SUBSCRIBE message containing a body provides the UAS with more details on what information can be regulated. 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. When using the regulate-publish data format for SUBSCRIBE messages, it SHOULD NOT contain elements (see Section 5.6). _Issue: use the Accept field to define which MIME types the client supports in the NOTIFY messages? (i.e. 'application/regulate-publish+xml')_ 4.3 SUBSCRIBE behavior It is difficult to suggest a range of times considered reasonable for the duration of a subscription. However, values between 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. The regulate-publish event package MUST support forking of SUBSCRIBE messages. See further Section 4.5. When using the regulate-publish data format for SUBSCRIBE messages, the UAS SHOULD ignore elements (see Section 5.6). Brok Expires August 14, 2005 [Page 11] Internet-Draft Regulate-Publish February 2005 4.4 NOTIFY messages NOTIFY messages MUST follow the specification of [RFC3265]. 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.5 NOTIFY behavior The UAC MAY choose to ignore the regulation information from all NOTIFY messages. Interpretation of any information carried in the NOTIFY bodies is outside the scope of this specification. 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 does 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 conflictive information with an informative message. This may be useful feedback for the UAS. Example: "200 OK, xxx Conflicting regulations, choosing YYY"._ [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. As a result, it is RECOMMENDED that the UAS 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 Brok Expires August 14, 2005 [Page 12] Internet-Draft Regulate-Publish February 2005 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 August 14, 2005 [Page 13] Internet-Draft Regulate-Publish February 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.8. 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 August 14, 2005 [Page 14] Internet-Draft Regulate-Publish February 2005 Example regulate-publish document: 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-04]. These prefixes apply to the element. The element contains one or more elements. The element supports the following attributes: 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. Brok Expires August 14, 2005 [Page 15] Internet-Draft Regulate-Publish February 2005 5.5 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 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//gml:location' from the presence event package and a second element may suggest to regulate 'weather[@sunshine="true"]' from an imaginary weather event package. 5.6 The Element The element supports the following attributes: o Optional 'occurrence' attribute suggest the number of PUBLISH messages, for instance 0 for no more messages and 1 for one-shot. o Optional 'interval' attribute suggest that PUBLISH messages are required repeatedly with specified interval in seconds. 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 publish hasn't changed since the previous PUBLISH message. The priority field from the SIP header (if present) should not be used since the NOTIFY body may contain multiple filters with different urgency values. o Optional 'probability' attribute indicates the minimum required probability for certain information to be correct. The value can be between 0 (wild guess) and 100 (absolutely sure). The usefulness of this attribute depends on the requested information as specified with the XPath expression. For instance, it might be useful to publish activity, place-type and mood (RPID parameters, see [draft-ietf-simple-rpid-04]) only when the probability is at least 50%. Brok Expires August 14, 2005 [Page 16] Internet-Draft Regulate-Publish February 2005 The occurrence and interval attributes may be used together; a good use case for is to measure a few locations with GPS minute apart to detect speed and direction. Of course, if data is not changed, the UAC should not send PUBLISH messages. Rather, the interval attribute provides a hint for the monitoring rate. 5.7 The Element The element supports the following attribute 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 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-04]. 5.8 XML Schema XML Schema Implementation (normative). XML Schema Definition for Regulate Publish. Brok Expires August 14, 2005 [Page 18] Internet-Draft Regulate-Publish February 2005 Figure 3 Brok Expires August 14, 2005 [Page 19] Internet-Draft Regulate-Publish February 2005 6. Example Usage The following example is based on use case 1 of Section 2. A Presence Agent (PA) requests monitoring the geographical location, indicating that it needs the location every 15 minutes in latitude/longitude coordinates. The XML document is the body of the NOTIFY message from the PA to the mobile device, the SIP message header is not shown. pidf:presence//gml:location Figure 4 The following example is based on use case 2 of Section 2. A watcher is particularly interested whether a user is in a noisy environment and sends request containing an XPath expression to the Presence Agent (PA). The PA determines that the watcher may see this information and sends a NOTIFY message to the UAC containing the same XPath expression. Also here, the XML document is the body of the NOTIFY message from the PA to the mobile device, the SIP message header is not shown. Brok Expires August 14, 2005 [Page 20] Internet-Draft Regulate-Publish February 2005 //rpid:person[rpid:place-type="noisy"] Figure 5 Brok Expires August 14, 2005 [Page 21] Internet-Draft Regulate-Publish February 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-target event package MUST follow the specification of the Security Considerations in [RFC3265]. Brok Expires August 14, 2005 [Page 22] Internet-Draft Regulate-Publish February 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 August 14, 2005 [Page 23] Internet-Draft Regulate-Publish February 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 6 Brok Expires August 14, 2005 [Page 24] Internet-Draft Regulate-Publish February 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 August 14, 2005 [Page 25] Internet-Draft Regulate-Publish February 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-04] Khartabil, H., Leppanen, E., Lonnfors, M. and J. Costa-Requena, "An Extensible Markup Language (XML) Based Format for Event Notification Filtering", January 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 August 14, 2005 [Page 26] Internet-Draft Regulate-Publish February 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-04] Khartabil, H., Leppanen, E., Lonnfors, M. and J. Costa-Requena, "Functional Description of Event Notification Filtering", January 2005. [draft-ietf-simple-rpid-04] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", October 2004. 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 August 14, 2005 [Page 27] Internet-Draft Regulate-Publish February 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 August 14, 2005 [Page 28]