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]