SIP WG James Polk Internet-Draft Cisco Systems Expires: January 7, 2009 July 7, 2008 Intended Status: Standards Track (PS) Updates: [ID-SIP-CON] (if published as an RFC) Session Initiation Protocol (SIP) Location Get Function draft-polk-sip-location-get-00 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 January 7, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines how a watcher seeks the geographic location information from presentity. SIP Location Conveyance defines how location is sent from one entity to another unsolicited. This document specifies how a watcher, i.e., a Location Target, requests for specific geolocation state information of a presentity, in addition to the details within the subscription such as the format (geo or civic) returned and the frequency of updated location from the presentity. Polk Expires January 7, 2009 [Page 1] Internet-Draft SIP Get Location Function July 2008 Table of Contents 1. Conventions and Terminology used in this Document . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Location Get Operation . . . . . . . . . . . . . 7 4. Life of Subscription verses Number of NOTIFYs within Subscription. . . 10 5. Location Get Defined . . . . . . . . . . . . . . . . . . . . 11 5.1 Subscribing for Location . . . . . . . . . . . . . . . . 11 5.2 Notifications of Location . . . . . . . . . . . . . . . . 12 5.3 Sending and Receiving Response Codes to Location Subscriptions. . . 13 6. Presence Filters for the Subscription Get Function . . . . . 14 6.1 Filters for the Subscription Get Function . . . . . . . . 17 6.2 Filters Examples for the Subscription Get Function . . . 17 7. Security considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement and Intellectual Property . . . . . 18 1. Conventions and Terminology used in this Document 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]. The following terms and acronyms used throughout this document are defined here: LbyR = Location-by-Reference LbyV = Location-by-Value locationValue - contains a URI pointing to a Location Target's location (as a PIDF-LO), and one or more header parameters about that URI. There can be one or more locationValues within a Geolocation header in a SIP request. Location Generator - the first IP enabled device that builds the IP packet that transmits the PIDF-LO containing the Target's location Location Information Server (LIS) - a logical server that stores geolocation records, which correspond to LbyR URIs, which point to those records. A LIS responds to location queries from Polk Expires January 7, 2009 [Page 2] Internet-Draft SIP Get Location Function July 2008 location seekers, making the LIS a superset of a LS. Location Object - Defined in RFC 4119 as the PIDF-LO (XML scheme) format which includes the geolocation of Location Target in either civic address or coordinate form. Location Recipient - Defined in RFC3693 as any entity that understands geolocation (LbyR or LbyV) along a message path. Does not include entities that process a message containing geolocation that do not understand geolocation (i.e., layer 3 routers). Location Server - a logical IP server that transmits a PIDF-LO. This can be logically combined with the Location Generator, or could be an intermediary element. An LS is a subset of a LIS, because an LS does not receive location requests from location seekers. Location Target - The entity whose location is being sought, whether or not this entity is aware of this inquiry or is even an IP device. Location-by-Reference (more than one meaning) - a general purpose term meaning a message containing a URI that points to a PIDF-LO (geolocation of a Location Target) not within this same message - a URI that logically locates a geolocation record of a Location Target. The URI does not point to location within the same message as the URI. Location-by-Value - when a message contains the actual location of a Location Target, in the form of a PIDF-LO. Presence Information Data Format (PIDF), as defined in RFC 3683 Presence Information Data Format - Location Object (PIDF-LO), as defined in RFC 4119 Seeker (or Location Seeker) - the active watcher of a Target, wanting its location, as defined in RFC 3693 Using Protocol - as defined in [RFC3693], a protocol that is deemed to be in compliance with the security and privacy aspects of the Geopriv Requirements RFC [RFC3693], with good community verification. Instead of using the terms Location-by-Reference (or just by-reference) and Location-by-Value (or just by-value), this document will herein use the acronyms LbyR and LbyV, respectively. Polk Expires January 7, 2009 [Page 3] Internet-Draft SIP Get Location Function July 2008 2. Introduction This document describes how an entity, in Presence terminology - called a watcher, in Geopriv terminology - called a seeker, can request the geographic location state information of another entity (Presentity Agent or PA in Presence, a Target in Geopriv terminology). In other words, how Alice can ask Bob's presentity for its current geographic location. It can be the case that Bob's geolocation is on a server that contains Bob's geolocation state information. Said another way, Bob's PA might not be contacted directly, while Alice is still able to ask for Bob's location. By contrast, SIP Location Conveyance [ID-SIP-LOC] describes a different geolocation function altogether. That document describes how Alice can send her geolocation to Bob unsolicited (by Bob). Conveyance defines how a location is sent directly to another entity, in a message body part, and indirectly via a locationURI, by having this URI point at a location record on a remote server. Conveyance states a locationURI is a sip:, sips: or pres: URI, with the seeker subscribing to the Presence event package at the locationURI for the PIDF-LO at that record. This is how an entity dereferences a locationURI. Possessing a locationURI is also called LbyR, shorthand for Location-by-reference. A PIDF-LO is location-by-value, or LbyV. If location is conveyed indirectly, the seeker (or Location Recipient) will have to fetch the LbyV from the (LbyR) location record it has a pointer to (i.e., the locationURI). Conveyance does not, however, define the set of presence filters the location seeker uses to request what it wants within that event package, in other words, the details about the location subscription - such as in which format does the seeker want location to be returned (civic or geo coordinates), or whether this is a one-time only subscription for the Target's location at that moment only, or does the seeker want updates to the Target's location periodically or upon some trigger. This document defines what Alice is asking for (w.r.t. geolocation) of Bob's presentity. Fortuitously, the mechanism this document defines for dereferencing a locationURI is the same mechanism used to merely ask a presentity for its location, right down to the filters used. Therefore, this document is an extension to [ID-SIP-LOC], but satisfying how a dereference is defined. Some background is necessary here; RFC 3693 [RFC3693] very clearly describes the idea of a seeker wanting the location of a Location Target. The following (slightly) modified figure is from [RFC3693]: Polk Expires January 7, 2009 [Page 4] Internet-Draft SIP Get Location Function July 2008 +----------+ | Rule | | Holder | | | +----+-----+ | rule|interface V +----------+ +----------+ +----------+ |Location | publication | Location | notification |Location | |Generator +-------------->| Server +-------------->|Recipient | | | interface | | interface | | +----------+ +----------+ +----------+ ^ ^ | | +-------------------------------------+ Can be part of a single entity Figure 1. Functional Description of Seeker and Target The Location Generator (LG), Location Server (LS) and Rule Holder (RH) are 3 separate logical functions that can be separate entities, in the case where Bob's presentity published its location up to his presence server. The LG in Figure 1. is the first IP entity to create the Presence Information Data Format - Location Object, or PIDF-LO, as defined in RFC 4119 [RFC4119]. A PIDF-LO is the location-by-value (LbyV) form, to be included within a message (body part) and transmitted towards a Location Recipient (LR). A PIDF-LO is a modification of the PIDF XML Scheme specifically for carrying geographic location of a Target. The LG can publish its state information, including its location in PIDF-LO form, to an LS. If this entity is the one contacted for the location state information of the location presentity, instead of contacting the presentity directly, this LS is defined as a Location Information Server, or LIS (see below). Using Figure 1 as is, as defined in RFC 3693, the LS typically challenges any request for location information, the RH rules/policies are applied to any/all requests, and once the appropriate authorization (i.e., perhaps credentials) is granted to the location requestor, an answer given. If the LG and LS are the same entity, the RH, sometimes called a Rulemaker, can also be, and likely is, within the same entity. This model necessitates there not be any content indirection, for obvious reasons. If the LG and LS are the same entity, but the RH is a separate entity, perhaps in a dual mode where the Target and the location provider coordinate/aggregate setting the rules for a (i.e., each) Target, there still can be indirection with the Target publishing its locationURI to another LS that is a LIS, that may or may not be a Presence server also. If separate, the LIS and Presence server coordinate all location requests (perhaps the LIS Polk Expires January 7, 2009 [Page 5] Internet-Draft SIP Get Location Function July 2008 and presence server are collocated, perhaps there is communications between them whenever a location request is received by a presence server). This part is out of scope of this document. If Bob's presentity is asked for its geolocation, making him the Target, he is functioning both as an LG and LS. If Bob's server is asked for his presentity's geolocation, these logical entities are separate logical entities as well. In the case where Alice is seeking Bob's location, she is the LR if Bob's rules allow her watcher to learn his geolocation state information. RFC 3693 [RFC3693] also defines what constitutes a "Using Protocol". A protocol that meets a specific set of security requirements by safeguarding its privacy concerns for retransmissions of location, and how long a location is to be stored or considered valid. This document complies with the "Using Protocol" requirements by extension of how [ID-SIP-CON] accomplishes this qualification, since the same protocol is used in both documents, with no new vulnerabilities created within this document. [Editor's note: I think the following text is needed, but am soliciting how this can be done without creating a new 4XX error code. "This document also defines an extension to the Session Initiation Protocol (SIP) specifically for when these conditions cannot or will not be met by the presentity, necessitating a new SIP error code that is location request specific."] This extension does not change any rules about subscriptions, meaning they can be modified, extended or terminated. One feature that simple subscription expiry does not address is how often NOTIFYs are sent back to the subscriber, in non-one-time-only subscriptions. Consequently, a set of filters need to be created that address within any given (non 1 second) subscription, how frequently are NOTIFYs sent, and is this frequency merely periodic or does some trigger event occur to cause a new NOTIFY to be sent? Movement of a presentity is a great example of a trigger worthy of new a new NOTIFY that cannot be anticipated by any timed (periodic) interval. One usecase that can be mentioned in [ID-SIP-CON] is the 9-1-1/1-1-2 style (local) "emergency case", in which an emergency response center wants to learn if the caller, who is IP based, therefore mobile in nature, moves during the call. Location conveyance uses the location in the INVITE to both determine call routing (to the emergency call center closest (appropriate) to the caller's location) and for dispatching of emergency responders. Therefore, learning a caller has moved is a necessity. This document describes implicitly how a call taker can subscribe to a caller to track their movement. This has to be allowed by the caller (rulemaker Polk Expires January 7, 2009 [Page 6] Internet-Draft SIP Get Location Function July 2008 permissions), but this can be done. This capability is enabled with this extension to SIP, but the details are for another document (probably out of the ECRIT WG). Common terms are in Section 1. Section 3 provides an overview of the SIP location GET function. Section 4 discusses the difference between the life of a subscription and the number of notifies within a subscription. Section 5 defines this location 'get' function, including the roles of the subscriber and that of the notifier. Section 6 describes the filters necessary in this extension. The filters themselves are to be created once there is consensus on what the filters should accomplish. Section 7 is security considerations. Section 8 is IANA considerations (and so on). 3. Overview of Location Get Operation When a watcher wants to learn the location of a presentity, it subscribes to the sip:, sips: or pres: URI of that presentity, to the presence event package specifically, as defined in RFC 3265 [RFC3265] and RFC 3856 [RFC3856]. The filters (shown later in this document) contained in the message body of the SUBSCRIBE request indicate exactly what is wanted in the NOTIFY from the presentity, and how often the presentity is to send new NOTIFYs (if this is not a one-time-only subscription). When Alice wants to learn Bob's location, she subscribes to Bob's sip:, sips: or pres: locationURI. This URI is either pointing to Bob's PA, Bob's presence server or Bob's LIS. If towards Bob's presence server, then his PA has published the PIDF-LO to this server already. Ultimately, Bob is (supposed to be) in charge of which locationURI (pointing towards which entity) is given to Alice for her to contact to get Bob's location. Whichever destination Alice's watcher subscribes to, using this geolocation 'get' extension, this subscription can be to get location once, or by creating a dialog, more than once. In other words, Alice could be asking for Bob's location: A) one time only, or B) more than once, but for a limited number of updates (which results in a short duration dialog), or C) creating a dialog that last over a period of time. The dialog described in (B) is for a use-case, for example, in which location may be more coarse when given in the initial NOTIFY, but once a location Sighter system such as 802.11, cellular or WiMAX actively triangulates a more precise fix on the location Target, a second NOTIFY is sent with more precise location. Section 4 describes how this does not easily translate into a periodic location refresh with a limited subscription duration, necessitating a more creative solution (i.e., filters). Polk Expires January 7, 2009 [Page 7] Internet-Draft SIP Get Location Function July 2008 This lasting dialog of location notifications (C) can be - periodic in nature (having a specified time interval), or - can be triggered by something the Target does (i.e., it senses it has changed rooms, and needs to update its location with whomever is subscribed to this event package). Filters are contained in the XML message body of the SUBSCRIBE to indicate exactly what Alice wants returned in the PIDF-LO, and what other characteristics she wants to specify about that subscription (until it is modified, extended or terminated). If Bob chooses to reject what Alice wants, he does so with a new Bad Location Request error, or another error that his UA considers appropriate. [Editor's note: this error response could be a new use of the [ID-SIP-CON] defined 417 (Bad Location Information) just for when it is received when using a SUBSCRIBE). Below is the one time subscription for location example. Alice Bob | | | SUBSCRIBE (includes Geoloc Get filters) | | -------------------------------------------------> | | | | 200 OK | | <------------------------------------------------- | | | | | | NOTIFY (w/ PIDF-LO) | | <------------------------------------------------- | | | | 200 OK | | -------------------------------------------------> | | | Figure 2. UA seeks one time location from another UA In Figure 2., Alice subscribes to Bob's presentity using the Presence event package, requesting a single reply with Bob's location (Expires=0). Later in this document, we define the filters necessary to request what Alice wants (i.e., does she want whatever location Bob has about himself, or does Alice only want location to be returned to her in a certain format, for example, civic vs. geo). Following the basic subscription message flow, the 200 OK (to the SUBSCRIBE) does not contain the PIDF-LO with Bob's location, it acknowledges (i.e., accepts) the subscription attempt by Alice only. The PIDF-LO is in the NOTIFY from Bob to Alice. Polk Expires January 7, 2009 [Page 8] Internet-Draft SIP Get Location Function July 2008 Figure 3. below shows a subscription for location lasting over a period of time. Alice Bob | | | SUBSCRIBE (includes Geoloc Get filters) | | -------------------------------------------------> | | | | 200 OK | | <------------------------------------------------- | | | | | | NOTIFY (w/ PIDF-LO) | | <------------------------------------------------- | | | | 200 OK | | -------------------------------------------------> | | | | **************************************** | | * some time occurs between NOTIFYs * | | **************************************** | | | | NOTIFY (w/ PIDF-LO) | | <------------------------------------------------- | | | | 200 OK | | -------------------------------------------------> | | | | **************************************** | | * some time occurs between NOTIFYs * | | **************************************** | | | | | | NOTIFY (w/ PIDF-LO) | | <------------------------------------------------- | | | | 200 OK | | -------------------------------------------------> | | | Figure 3. UA seeks Location over Time from another UA In the example within Figure 3., Alice subscribes to Bob's presentity for his location, and wishes it to last over a period of time. The duration is set by the Expires header within the 200 OK of the SUBSCRIBE. Further, within the filters contained in the XML message body, there is an indication of exactly what Alice wants in each reply - in addition to how often she wants Bob to send a NOTIFY (periodic or triggered, see section 4 about this requirement). This extension does not change any rules about subscriptions, Polk Expires January 7, 2009 [Page 9] Internet-Draft SIP Get Location Function July 2008 meaning they can be modified, extended or terminated. 4. Life of Subscription verses Number of NOTIFYs within Subscription There is a disconnect between how long a subscription lasts, i.e., what is set by the Expires value in the 200 OK to the SUBSCRIBE, and how often within a subscription a NOTIFY is sent with a new (or merely refreshed) location of a presentity. To highlight the disconnect, here is an example of the differences. Take four different scenarios involving a subscription that last for 3600 seconds (1 hour): Example #1 - a subscription for 3600 seconds that only sends 1 NOTIFY Example #2 - a subscription for 3600 seconds that sends 2 NOTIFYs Example #3 - a subscription for 3600 seconds that sends 3600 NOTIFYs Example #4 - a subscription for 3600 seconds that sends some number n of NOTIFYs depending on how many times a Location Target moves a certain minimum distance. Example #1 has a 3600 second subscription, and had a filter defining how often location was asked for (once in this example). The very first NOTIFY sent back to the Location Seeker satisfied the goal of the subscription (i.e., to learn the Location Target's location). The subscription remained in place until it timed out or was terminated. Example #2 has a 3600 second subscription, and had a filter defining how often location was asked for (once an hour in this example). The subscription lasted for only 2 NOTIFYs to be sent before the unmodified subscription expired. The subscription remained in place until it timed out or was terminated. Example #3 has a 3600 second subscription, and had a filter defining how often location was asked for (once a second in this example). The subscription lasted for 3600 NOTIFYs because that is how many can be sent within the 3600 second subscription. The subscription remained in place, providing periodic NOTIFYs, until it timed out or was terminated. Example #4 has a 3600 second subscription, and had a filter defining how often location was asked for (each time the Target moves a minimum distance in this example). The subscription lasted for 3600 seconds, with n number of NOTIFYs sent, based on the movement of the Target. The subscription remained in place until it timed out or was terminated. Polk Expires January 7, 2009 [Page 10] Internet-Draft SIP Get Location Function July 2008 The Target in Example #4 could have been told to send a NOTIFY every time the Sighter (meaning the Location Target itself or the system determining when the Location Target moves) detected the Target had moved X number of feet from the last time it sent a NOTIFY. How often can this occur within an hour? For a wired phone, probably not often; perhaps even 0 times. For a wireless phone, traveling in a car - the number of NOTIFYs sent will be quite a bit higher. All that said, each of the 4 scenarios is consistent with the rules of RFC 3265 for how long a subscription will last (based on the Expires header value), yet this example has clearly shown the need for a new filter capability to set the duration between NOTIFYs, or what triggers the NOTIFYs within a subscription. All of this will be set within the filters of the SUBSCRIBE. 5. Location Get Defined When subscribing to the locationURI for a presentity's geolocation, the event package in both the SUBSCRIBE and NOTIFY requests is "presence", which appears in the Event header field of either request. 5.1 Subscribing for Location This locationURI is the Request-URI of the SUBSCRIBE request, and need to be learned somehow. This document does not define how a locationURI is learned. As defined in RFC 3265 [RFC3265], a SUBSCRIBE MAY contain a body. To request location of another entity, the SUBSCRIBE MUST contain a message body. This message body MUST contain a filter document. Filter documents restrict what is to be returned in notifications. In this extension, these filters are specific to location (what format should be in the notifications) and frequency of notifications. Location can take one of two standard forms, as defined in RFC 4119 [RFC4119], geo (or x/y/z coordinates lie GPS) or civic (similar to postal addressing). Other forms should be possible, as long as they are within an accepted PIDF-LO document (i.e., there can be other formats, so this is extensible). According to [RFC3863], all subscriptions MUST be authenticated before being authorized. Authorization is up to the rulemaker policies within the presentity (i.e., Location Target). The presentity needs to make a policy decision once a subscription is authenticated. [RFC3265] states lists the appropriate response codes for conveying a successful, a rejected, or a pending subscription request are a 200 OK, a 403 Forbidden, a 603 Decline and a 202 Acceptable response, respectively. Polk Expires January 7, 2009 [Page 11] Internet-Draft SIP Get Location Function July 2008 The watcher (or seeker) MUST support the default Accept header value of "application/pidf+xml", according to [RFC3863]. All subscriptions will be challenged, so a watcher/seeker SHOULD be prepared for this to occur. A watcher/seeker receiving a NOTIFY SHOULD consider the PIDF-LO to be the current state of the presentity. Further, within a dialog, the PIDF-LO containing the highest CSeq value is the most current location of the presentity. A refreshed location subscription, within a dialog, does not have to contain a filter document, as the presentity agent MUST assume the existing filters are to continue unchanged. If a subscription for location is modified, then a new filter document MUST be in the new SUBSCRIBE request. This filter document MUST become the new set of filters used within this subscription. 5.2 Notifications of Location The NOTIFY will transport the PIDF-LO with the requested location state information in the default format value of "application/pidf+xml" (which is listed in the Content-Type header), according to [RFC3863]. Additional state information MAY be contained in the PIDF part of this document. The NOTIFY MUST contain that which was requested within the filters of the SUBSCRIBE or it SHOULD error the SUBSCRIBE if it knows it cannot return what is being asked of it within the filters. [Editor's note: is this a new 4XX error code or a redefined use of the 417 (Bad Location Information) code defined in [ID-SIP-CON]?] If the NOTIFY has an Expires set to 0, this subscription (regardless of what was requested in the SUBSCRIBE) is for a single return of a NOTIFY containing the presentity's location. If the NOTIFY has an Expires set to a non-zero value, the filters will determine the frequency of the notifications, and the interval between notifications. The server MUST comply with the SUBSCRIBE filters for periodic, as well as for triggered notifications. The server MUST continue sending agreed upon notifications until the subscription is modified (including refreshed), terminated or just ends. A presentity agent SHOULD return a current PIDF-LO in a NOTIFY to the watcher/seeker - because that is the current information it will have for the location of the presentity. It really has little choice but to trust the NOTIFY is telling the truth. According to [RFC3265], a presentity should not have a NOTIFY Polk Expires January 7, 2009 [Page 12] Internet-Draft SIP Get Location Function July 2008 interval rate faster than once over 5 seconds. This extension specifically oversteps this requirement by allowing the interval between location NOTIFYs to be no faster than once every 500ms. The reason for this is easy, location can change faster than once every 5 seconds, and this needs to be conveyed if within the parameters of the acceptable filters within a dialog. That said, periodic interval filters SHOULD NOT be set to less than once every 5 seconds. Triggered filters MAY NOT be set to less than once every 500ms (unless someone comes up with a viable use-case involving aircraft before this document is published as an RFC). A refreshed location subscription, within a dialog, does not have to contain a filter document, as the presentity agent MUST assume the existing filters are to continue unchanged. If a subscription for location is modified, then a new filter document MUST be in the new SUBSCRIBE request. This filter document MUST become the new set of filters used within this subscription, as reflected in the altered notifications sent by the presentity agent. 5.3 Sending and Receiving Response Codes to Location Subscriptions According to [RFC3863], all subscriptions MUST be authenticated before being authorized. Authorization is up to the rulemaker policies within the presentity (i.e., Location Target). The presentity needs to make a policy decision once a subscription is authenticated. [RFC3265] states lists the appropriate response codes for conveying a successful, a rejected, or a pending subscription request are a 200 OK, a 403 Forbidden, a 603 Decline and a 202 Acceptable response. According to [RFC4660], a 202 (Acceptable) response just means that the filter in the SUBSCRIBE was understood, but the entity has not engaged in filtering the notifications according to these filters. This is especially true for modified filters within an exiting dialog (for location). A 200 OK response is necessary for the subscriber to understand the new filters are now being applied to the notifications. RFC 4660 states further that a 415 () response is appropriate if the MIME type 'application/simple-filter+xml' is not understood by the notifier; and if understood, but something was not acceptable by the presentity agent then a 488 (Not Acceptable Here) response is appropriate. Both the subscriber and the subscribed to MUST understand this rule-set of why each response code is used, and under what conditions each are used in - to comply with this specification. Polk Expires January 7, 2009 [Page 13] Internet-Draft SIP Get Location Function July 2008 6. Presence Filters for the Subscription Get Function In order to utilize the SUBSCRIBE method and get location in return (i.e., in the NOTIFY), the SUBSCRIBE needs to have [RFC4660] defined filters as a message body. The purpose of these filters are to specifically ask for certain things be in the NOTIFY. What is understood by this document, and continued on from [ID-SIP-CON] is that the answer will be in a PIDF-LO format. Assumed here is the understanding that a subscription is authorized. If not, the SUBSCRIBE will be rejected. With regards to location, the following could be asked for (in no particular order in this rev), There needs to be the ability to subscribe to an entity that knows more than one presentity's location. Therefore an optional filter is a list of locationURIs the subscriber wants. This will most likely be between a presence server and a LIS, but it is not limited to this scenario. Filter #1 - specifies that a watcher wants location from a specific presentity/target, or a group of presentities/targets (i.e., a bulk transfer). Filter #1 will specify a single presentity or group of presentities. How this latter scenario is consistent with the privacy rules within RFC 3693 [RFC3693] is, for example, between a LIS and a Presence server. Instead of having the Presence server make a series of individual requests for locations from individual location targets, this is optimized to have a single subscription encompass this transfer of location information for each identified target in the filter document. Warning: Any filter specifying more than one locationURI will have all other filters applied to it within a dialog. In other words, within the same dialog, a watcher/seeker cannot locationURI-A's format in geodetic only and locationURI-B's in civic only. If different specifics are desired by the subscriber for different presentities, then each unique set of desires MUST be in separate dialogs, even if to the same destination. Filter #2 - specifies which location format the watcher wants returned in the NOTIFY (coordinate, civic, or future location format). The watcher can place a wildcard 'any' format that is available to the presentity Any filter specifying more than one locationURI will have all other filters applied to it within a dialog. In other words, within the same dialog, a watcher/seeker cannot locationURI-A's format in geodetic only and locationURI-B's in civic only. The choices likely will be 'geo-only', 'civic-only', 'all' or Polk Expires January 7, 2009 [Page 14] Internet-Draft SIP Get Location Function July 2008 'any' - unless there are any new location formats agree to before this document is published as an RFC. 'all' means any location information the notifier has it MUST send in the next notification. With filter#2, if a subscriber wants a location in a format that the presentity knows it cannot provide, or does not have access to a geocoder to convert what it does have, it the subscribed to entity MUST error the SUBSCRIBE. Filter #3 - a watcher could want to specify that it wants the subscription to last over a period of time, or for a specific number of updates. This would be creating a dialog, to have the subscription last longer than a one_time_only location reply. This will take some coordination with the Expires header, both in the SUBSCRIBE and the 200 OK to the SUBSCRIBE. The presentity MUST NOT accept a subscription that wants more than one location update and set the Expires to 0. If can be the case that a watcher wants a location subscription to last exactly for 2 NOTIFYs. The first NOTIFY could have a very coarse location in it. The subsequent NOTIFY can have a very precise location update. This is problematic under the current subscription policy within SIP, given that subscriptions last N number of seconds determined by the Expires header in the 200 OK to the SUBSCRIBE. It SHOULD be possible for exactly 2 different location updates to be sent to the watcher, yet not have to guess how long it will take the presentity to get the more precise location. Perhaps the presentity needs to request of the network where en entity really is, which can take a varying amount of time depending on the network type. Cellular networks call this a rebid, and can take as long as 30 seconds. Within Filter #3 is also the means by which a presentity sends the watcher a triggered update of location information, based on some knowledge of movement by the presentity (not defined here). Filter #4 - a watcher could specify exactly which elements of location it needs to have in the reply. This could be a case in which the watcher is saying "unless I get at least all these pieces of location information in the reply, I want an error, and I want that error to list which location parts are not available, or I (the watcher) do not have permission to access". In other words, which location elements are mandatory to include in the notification, or an error is sent. Using filter#4, if the location is for call routing, and the resolution of the location is not below the country or state/province level, this might result in a routing failure. If this location is being used for dispatch of emergency personnel, and Polk Expires January 7, 2009 [Page 15] Internet-Draft SIP Get Location Function July 2008 the resolution is only to the city level, the first responders cannot be expected to find the caller that is having a heart attack. In either case, location resolution to the city and street address level, respectively are probably a minimum to be successful. Filter #5 - a watcher could add specifically which elements of location it wants to have in the reply, in other words, which location elements are optional to include (based on availability and permissions), but not mandatory to include in the notification. For both 4 and 5, an example of this request might be either: if the watcher wants coordinate location, it might specify it must have latitude and longitude, and optionally have altitude; or if the watcher wants civic location, it might specify it must learn the country, state/province, city, street, street number of the presentity, and it would be nice if the presentity also includes its floor, landmark, building name, postal code and room in the notification . Filter #6 - filter for periodic intervals Filter #7 - filter for triggered notifications Filter #8 - filter for what constitutes 'movement' in Filter#7, for example, how many feet did a target move since the last notification, or how many fractions of a degree did a target move since the last notification. For filter#8, this needs to be something the subscriber conveys to the subscribed, because this subscription is looking for what he subscriber wants, and in what form. For example, one subscriber might want to know every time a target moves 10 feet; whereas another might want to know not hear from the notifier until it has detected moving more than a kilometer. If the presentity does not have the ability to discover when it moves, and receives a 'detect-movement' filter, then the subscriber MUST receive an error - because it cannot fulfill one of the filters in the SUBSCRIBE. Filters#6 & 7 need to be able to coexist, in such a way that there is not silence from the presentity if it has not moved in a while. Polk Expires January 7, 2009 [Page 16] Internet-Draft SIP Get Location Function July 2008 6.1 Filters for the Subscription Get Function This section will be completed at a later date (i.e., once (at least most of) the filter descriptions are agreed to). 6.2 Filters Examples for the Subscription Get Function TBD 7. Security considerations This document introduces no additional security considerations from that covered in RFC 3856 [RFC3856], RFC 3863 [RFC3863], RFC 4119 [RFC4119], and "SIP Location Conveyance" [ID-SIP-CON]. 8. IANA considerations This document does not have any IANA actions (at this time). 9. Acknowledgments Your name here... or if you contribute a fair amount of text, you can be a co-author. 10. References 10.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf-sip-location-conveyance-10.txt, "work in progress", Feb 2008 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 Polk Expires January 7, 2009 [Page 17] Internet-Draft SIP Get Location Function July 2008 10.2. Informative References [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Polk Expires January 7, 2009 [Page 18] Internet-Draft SIP Get Location Function July 2008 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Polk Expires January 7, 2009 [Page 19]