draft-ietf-sipcore-location-conveyance-09.txt   rfc6442.txt 
Network Working Group James Polk Internet Engineering Task Force (IETF) J. Polk
Internet Draft Cisco Systems Request for Comments: 6442 Cisco Systems
Expires: Mar 4, 2012 Brian Rosen Category: Standards Track B. Rosen
Intended Status: Standards Track (PS) Jon Peterson ISSN: 2070-1721 J. Peterson
NeuStar NeuStar
Sept 4, 2011 December 2011
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sipcore-location-conveyance-09.txt
Abstract Abstract
This document defines an extension to the Session Initiation This document defines an extension to the Session Initiation Protocol
Protocol (SIP) to convey geographic location information from one (SIP) to convey geographic location information from one SIP entity
SIP entity to another SIP entity. The SIP extension covers to another SIP entity. The SIP extension covers end-to-end
end-to-end conveyance as well as location-based routing, where SIP conveyance as well as location-based routing, where SIP
intermediaries make routing decisions based upon the location of the intermediaries make routing decisions based upon the location of the
Location Target. Location Target.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and 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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on Mar 4, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6442.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Conventions and Terminology used in this document . . . . . . 3 1. Introduction ....................................................3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology Used in This Document ...............4
3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4 3. Overview of SIP Location Conveyance .............................4
3.1 Location Conveyed by Value . . . . . . . . . . . . . . . 4 3.1. Location Conveyed by Value .................................4
3.2 Location Conveyed as a Location URI . . . . . . . . . . . 5 3.2. Location Conveyed as a Location URI ........................5
3.3 Location Conveyed though a SIP Intermediary . . . . . . . 5 3.3. Location Conveyed though a SIP Intermediary ................6
3.4 SIP Intermediary Replacing Bad Location . . . . . . . . . 7 3.4. SIP Intermediary Replacing Bad Location ....................7
4. SIP Modifications for Geolocation Conveyance . . . . . . . . 8 4. SIP Extensions for Geolocation Conveyance .......................8
4.1 The Geolocation Header Field . . . . . . . . . . . . . . 8 4.1. The Geolocation Header Field ...............................8
4.2 The Geolocation-Routing Header Field . . . . . . . . . . 10 4.2. The Geolocation-Routing Header Field ......................11
4.2.1 Explaining Geolocation-Routing header-value States . . 11 4.2.1. Explaining Geolocation-Routing Header-Value
4.3 424 (Bad Location Information) Response Code . . . . . . 13 States .............................................12
4.4 The Geolocation-Error Header Field . . . . . . . . . . . 14 4.3. 424 (Bad Location Information) Response Code ..............14
4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 17 4.4. The Geolocation-Error Header Field ........................15
4.6 Location Profile Negotiation . . . . . . . . . . . . . . 17 4.5. Location URIs in Message Bodies ...........................19
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 18 4.6. Location Profile Negotiation ..............................19
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 18 5. Geolocation Examples ...........................................20
5.2 Two Locations Composed in Same Location Object Example . 20 5.1. Location-by-Value (in Coordinate Format) ..................20
6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 22 5.2. Two Locations Composed in Same Location Object Example ....21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Geopriv Privacy Considerations .................................23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations ........................................24
8.1 IANA Registration for New SIP Geolocation Header Field . 24 8. IANA Considerations ............................................26
8.2 IANA Registration for New SIP Geolocation-Routing Header 8.1. IANA Registration for the SIP Geolocation Header Field ....26
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. IANA Registration for the SIP Geolocation-Routing
8.3 IANA Registration for New SIP Option Tags . . . . . . . . 25 Header Field ..............................................26
8.4 IANA Registration for New 424 Response Code . . . . . . . 25 8.3. IANA Registration for Location Profiles ...................27
8.5 IANA Registration for New SIP Geolocation-Error Header 8.4. IANA Registration for 424 Response Code ...................27
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.5. IANA Registration of New Geolocation-Error Header Field ...28
8.6 IANA Registration for New SIP Geolocation-Error Codes . . 26 8.6. IANA Registration for the SIP Geolocation-Error Codes .....28
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements ...............................................29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References ....................................................29
10.1 Normative References . . . . . . . . . . . . . . . . . 27 10.1. Normative References .....................................29
10.2 Informative References . . . . . . . . . . . . . . . . . 28 10.2. Informative References ...................................31
Author Information . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Requirements for SIP Location Conveyance ..............32
Appendix A. Requirements for SIP Location Conveyance . . . . 29
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]. This document furthermore uses numerous terms defined
in RFC 3693 [RFC3693], including Location Object, Location
Recipient, Location Server, Target, Rulemaker and Using Protocol.
2. Introduction 1. Introduction
Session Initiation Protocol (SIP) [RFC3261] creates, modifies and Session Initiation Protocol (SIP) [RFC3261] creates, modifies and
terminates multimedia sessions. SIP carries certain information terminates multimedia sessions. SIP carries certain information
related to a session while establishing or maintaining calls. This related to a session while establishing or maintaining calls. This
document defines how SIP conveys geographic location information of document defines how SIP conveys geographic location information of a
a Target to a Location Recipient (LR). SIP acts as a Using Protocol Target to a Location Recipient (LR). SIP acts as a Using Protocol of
of location information, as defined in RFC 3693. location information, as defined in RFC 3693.
In order to convey location information, this document specifies In order to convey location information, this document specifies
three new SIP header fields, Geolocation, Geolocation-Routing and three new SIP header fields, Geolocation, Geolocation-Routing, and
Geolocation-Error, which carry a reference to a Location Object Geolocation-Error, which carry a reference to a Location Object (LO),
(LO), grant permission to route a SIP request based on the grant permission to route a SIP request based on the location-value
location-value and provide error notifications specific to location and provide error notifications specific to location errors,
errors respectively. The Location Object (LO) may appear in a MIME respectively. The Location Object (LO) may appear in a MIME body
body attached to the SIP request, or it may be a remote resource in attached to the SIP request, or it may be a remote resource in the
the network. network.
A Target is an entity whose location is being conveyed, per RFC A Target is an entity whose location is being conveyed, per RFC 3693.
3693. Thus, a Target could be a SIP user agent (UA), some other IP Thus, a Target could be a SIP user agent (UA), some other IP device
device (a router or a PC) that does not have a SIP stack, a non-IP (a router or a PC) that does not have a SIP stack, a non-IP device (a
device (a person or a black phone) or even a non-communications person or a black phone), or even a non-communications device (a
device (a building or store front). In no way does this document building or store front). In no way does this document assume that
assume that the SIP user agent client which sends a request the SIP user agent client that sends a request containing a location
containing a location object is necessarily the Target. The location object is necessarily the Target. The location of a Target conveyed
of a Target conveyed within SIP typically corresponds to that of a within SIP typically corresponds to that of a device controlled by
device controlled by the Target, for example, a mobile phone, but the Target, for example, a mobile phone, but such devices can be
such devices can be separated from their owners, and moreover, in separated from their owners, and moreover, in some cases, the user
some cases the user agent may not know its own location. agent may not know its own location.
In the SIP context, a location recipient will most likely be a SIP In the SIP context, a location recipient will most likely be a SIP
UA, but due to the mediated nature of SIP architectures, location UA, but due to the mediated nature of SIP architectures, location
information conveyed by a single SIP request may have multiple information conveyed by a single SIP request may have multiple
recipients, as any SIP proxy server in the signaling path that recipients, as any SIP proxy server in the signaling path that
inspects the location of the Target must also be considered a inspects the location of the Target must also be considered a
Location Recipient. In presence-like architectures, an intermediary Location Recipient. In presence-like architectures, an intermediary
that receives publications of location information and distributes that receives publications of location information and distributes
them to watchers acts as a Location Server per RFC 3693. This them to watchers acts as a Location Server per RFC 3693. This
location conveyance mechanism can also be used to deliver URIs location conveyance mechanism can also be used to deliver URIs
pointing to such Location Servers where prospective Location pointing to such Location Servers where prospective Location
Recipients can request Location Objects. Recipients can request Location Objects.
2. 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].
Furthermore, this document uses numerous terms defined in [RFC3693],
including: Location Object, Location Recipient, Location Server,
Target, Rule Maker, and Using Protocol.
3. Overview of SIP Location Conveyance 3. Overview of SIP Location Conveyance
An operational overview of SIP location conveyance can be shown in 4 An operational overview of SIP location conveyance can be shown in
basic diagrams, with most applications falling under one of the four basic diagrams, with most applications falling under one of the
following basic use cases. Each is separated into its own subsection following basic use cases. Each is separated into its own subsection
here in section 3. here in Section 3.
Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob
is an LR. A SIP intermediary appears in some of the diagrams. Any is an LR. A SIP intermediary appears in some of the diagrams. Any
SIP entity that receives and inspects location information is an LR, SIP entity that receives and inspects location information is an LR;
therefore in any of the diagrams the SIP intermediary that receives therefore, in any of the diagrams, the SIP intermediary that receives
a SIP request is potentially an LR - though that does not mean such a SIP request is potentially an LR -- though that does not mean such
an intermediary necessarily has to route the SIP request based on an intermediary necessarily has to route the SIP request based on the
the location information. In some use cases, location information location information. In some use cases, location information passes
passes through the LS on the right of each diagram. through the LS on the right of each diagram.
3.1 Location Conveyed by Value 3.1. Location Conveyed by Value
We start with the simplest diagram of Location Conveyance, Alice to We start with the simplest diagram of Location Conveyance, Alice to
Bob, where no other layer 7 entities are involved. Bob, where no other Layer 7 entities are involved.
Alice SIP Intermediary Bob LS Alice SIP Intermediary Bob LS
| | | | | | | |
| Request w/Location | | | Request w/Location | |
|----------------------------------->| | |----------------------------------->| |
| | | | | |
| Response | | | Response | |
|<-----------------------------------| | |<-----------------------------------| |
| | | | | | | |
Figure 1. Location Conveyed by Value Figure 1. Location Conveyed by Value
In Figure 1, Alice is both the Target and the LS that is conveying In Figure 1, Alice is both the Target and the LS that is conveying
her location directly to Bob, who acts as an LR. This conveyance is her location directly to Bob, who acts as an LR. This conveyance is
point-to-point - it does not pass through any SIP-layer point-to-point: it does not pass through any SIP-layer intermediary.
intermediary. A Location Object appears by-value in the initial SIP A Location Object appears by-value in the initial SIP request as a
request as a MIME body, and Bob responds to that SIP request as MIME body, and Bob responds to that SIP request as appropriate.
appropriate. There is a 'Bad Location Information' response code There is a 'Bad Location Information' response code introduced within
introduced within this document to specifically inform Alice if she this document to specifically inform Alice if she conveys bad
conveys bad location to Bob (e.g., Bob "cannot parse the location location to Bob (e.g., Bob "cannot parse the location provided", or
provided", or "there is not enough location information to determine "there is not enough location information to determine where Alice
where Alice is"). is").
3.2 Location Conveyed as a Location URI 3.2. Location Conveyed as a Location URI
Here we make Figure 1 a little more complicated by showing a Here we make Figure 1 a little more complicated by showing a diagram
diagram of indirect Location Conveyance from Alice to Bob, where of indirect Location Conveyance from Alice to Bob, where Bob's entity
Bob's entity has to retrieve the location object from a 3rd party has to retrieve the location object from a third party server.
server.
Alice SIP Intermediary Bob LS Alice SIP Intermediary Bob LS
| | | | | | | |
| Request w/Location URI | | | Request w/Location URI | |
|----------------------------------->| | |----------------------------------->| |
| | Dereference | | | Dereference |
| | Request | | | Request |
| (To: Location URI) | | (To: Location URI) |
| |---------------->| | |---------------->|
| | | | | |
| | Dereference | | | Dereference |
| | Response | | | Response |
| (includes location) | | (includes Location Object) |
| |<----------------| | |<----------------|
| Response | | | Response | |
|<-----------------------------------| | |<-----------------------------------| |
| | | | | | | |
Figure 2. Location Conveyed as a Location URI Figure 2. Location Conveyed as a Location URI
In Figure 2, location is conveyed indirectly, via a Location URI In Figure 2, location is conveyed indirectly, via a Location URI
carried in the SIP request (more of those details later). If Alice carried in the SIP request (more of those details later). If Alice
sends Bob this Location URI, Bob will need to dereference the URI - sends Bob this Location URI, Bob will need to dereference the URI --
analogous to Content Indirection [RFC4483] - in order to request the analogous to Content Indirection [RFC4483] -- in order to request the
location information. In general, the LS provides the location value location information. In general, the LS provides the location value
to Bob instead of Alice directly for conveyance to Bob. From a user to Bob instead of Alice directly for conveyance to Bob. From a user
interface perspective, Bob the user won't know that this information interface perspective, Bob the user won't know that this information
was gathered from an LS indirectly rather than culled from the SIP was gathered from an LS indirectly rather than culled from the SIP
request, and practically this does not impact the operation of request; practically, this does not impact the operation of location-
location-based applications. based applications.
The example given in this section is only illustrative, not The example given in this section is only illustrative, not
normative. In particular, applications can choose to dereference a normative. In particular, applications can choose to dereference a
location URI at any time, possibly several times, or potentially not location URI at any time, possibly several times, or potentially not
at all. Applications receiving a Location URI in a SIP transaction at all. Applications receiving a Location URI in a SIP transaction
need to be mindful of timers used by different transactions. In need to be mindful of timers used by different transactions. In
particular, if the means of dereferencing the Location URI might particular, if the means of dereferencing the Location URI might take
take longer than the SIP transaction timeout (Timer C for INVITE longer than the SIP transaction timeout (Timer C for INVITE
transactions, Timer F for non-INVITE transactions), then it needs to transactions, Timer F for non-INVITE transactions), then it needs to
rely on mechanisms other than the transaction's response code to rely on mechanisms other than the transaction's response code to
convey location errors, if returning such errors are necessary. convey location errors, if returning such errors are necessary.
3.3 Location Conveyed though a SIP Intermediary 3.3. Location Conveyed though a SIP Intermediary
In Figure 3, we introduce the idea of a SIP intermediary into the In Figure 3, we introduce the idea of a SIP intermediary into the
example to illustrate the role of proxying in the location example to illustrate the role of proxying in the location
architecture. This intermediary can be a SIP proxy or it can be architecture. This intermediary can be a SIP proxy or it can be a
a back-to-back-user-agent (B2BUA). In this message flow, the SIP back-to-back user agent (B2BUA). In this message flow, the SIP
intermediary could act as a LR, in addition to Bob. The primary use intermediary could act as an LR, in addition to Bob. The primary use
case for intermediaries consuming location information is case for intermediaries consuming location information is location-
location-based routing. In this case, the intermediary chooses a based routing. In this case, the intermediary chooses a next hop for
next hop for the SIP request by consulting a specialized location the SIP request by consulting a specialized location service that
service which selects forwarding destinations based on geographical selects forwarding destinations based on the geographical location
location. information contained in the SIP request.
Alice SIP Intermediary Bob LS Alice SIP Intermediary Bob LS
| | | | | | | |
| Request | | | | Request | | |
| w/Location | | | | w/Location | | |
|--------------->| | | |--------------->| | |
| | Request | | | | Request | |
| | w/Location | | | | w/Location | |
| |------------------>| | | |------------------>| |
| | | | | | | |
| | Response | | | | Response | |
| |<------------------| | | |<------------------| |
| Response | | | | Response | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 3. Location Conveyed though a SIP Intermediary Figure 3. Location Conveyed though a SIP Intermediary
However, the most common case will be one in which the SIP However, the most common case will be one in which the SIP
intermediary receives a request with location information (conveyed intermediary receives a request with location information (conveyed
either by-value or by-reference) and does not know or care about either by-value or by-reference) and does not know or care about
Alice's location, or support this extension, and merely passes it on Alice's location, or support this extension, and merely passes it on
to Bob. In this case, the intermediary does not act as a Location to Bob. In this case, the intermediary does not act as a Location
Recipient. When the intermediary is not an LR, this use case is the Recipient. When the intermediary is not an LR, this use case is the
same as the one described in Section 3.1. same as the one described in Section 3.1.
Note that an intermediary does not have to perform location-based Note that an intermediary does not have to perform location-based
routing in order to be a Location Recipient. It could be the case routing in order to be a Location Recipient. It could be the case
that a SIP intermediary which does not perform location-based that a SIP intermediary that does not perform location-based routing
routing does care when Alice includes her location; for example, does care when Alice includes her location; for example, it could
it could care that the location information is complete or that it care that the location information is complete or that it correctly
correctly identifies where Alice is. The best example of this is identifies where Alice is. The best example of this is
intermediaries that verify location information for emergency intermediaries that verify location information for emergency
calling, but it could also be for any location based routing - e.g., calling, but it could also be for any location based routing, e.g.,
contacting your favorite local pizza delivery service, making sure contacting your favorite local pizza delivery service, making sure
that organization has Alice's proper location in the initial SIP that organization has Alice's proper location in the initial SIP
request. request.
There is another scenario in which the SIP intermediary cares about There is another scenario in which the SIP intermediary cares about
location and is not an LR, one in which the intermediary inserts location and is not an LR, one in which the intermediary inserts
another location of the Target, Alice in this case, into the another location of the Target, Alice in this case, into the request,
request, and forwards it. This secondary insertion is generally not and forwards it. This secondary insertion is generally not advisable
advisable because downstream SIP entities will not be given any because downstream SIP entities will not be given any guidance about
guidance about which location to believe is better, more reliable, which location to believe is better, more reliable, less prone to
less prone to error, more granular, worse than the other location or error, more granular, worse than the other location or just plain
just plain wrong. wrong.
This document takes a "you break it, you bought it" approach to This document takes a "you break it, you bought it" approach to
dealing with second locations placed into a SIP request by an dealing with second locations placed into a SIP request by an
intermediary entity. That entity becomes completely responsible for intermediary entity. That entity becomes completely responsible for
all location within that SIP request (more on this in Section 4). all location within that SIP request (more on this in Section 4).
3.4 SIP Intermediary Replacing Bad Location 3.4. SIP Intermediary Replacing Bad Location
If the SIP intermediary rejects the message due to unsuitable If the SIP intermediary rejects the message due to unsuitable
location information, the SIP response will indicate there was 'Bad location information, the SIP response will indicate there was 'Bad
Location Information' in the SIP request, and provide a location Location Information' in the SIP request and provide a location-
specific error code indicating what Alice needs to do to send an specific error code indicating what Alice needs to do to send an
acceptable request (see Figure 4 for this scenario). acceptable request (see Figure 4 for this scenario).
Alice SIP Intermediary Bob LS Alice SIP Intermediary Bob LS
| | | | | | | |
| Request | | | | Request | | |
| w/Location | | | | w/Location | | |
|--------------->| | | |--------------->| | |
| | | | | | | |
| Rejected | | | | Rejected | | |
skipping to change at page 7, line 40 skipping to change at page 7, line 50
|<---------------| | | |<---------------| | |
| | | | | | | |
| Request | | | | Request | | |
| w/New Location | | | | w/New Location | | |
|--------------->| | | |--------------->| | |
| | Request | | | | Request | |
| | w/New Location | | | | w/New Location | |
| |------------------>| | | |------------------>| |
| | | | | | | |
Figure 4. SIP Intermediary Replacing Bad Location Figure 4. SIP Intermediary Replacing Bad Location
In this last use case, the SIP intermediary wishes to include a In this last use case, the SIP intermediary wishes to include a
Location Object indicating where it understands Alice to be. Thus, Location Object indicating where it understands Alice to be. Thus,
it needs to inform her user agent what location it will include in it needs to inform her user agent of what location it will include in
any subsequent SIP request that contains her location. In this any subsequent SIP request that contains her location. In this case,
case, the intermediary can reject Alice's request and, through the the intermediary can reject Alice's request and, through the SIP
SIP response, convey to her the best way to repair the request in response, convey to her the best way to repair the request in order
order for the intermediary to accept it. for the intermediary to accept it.
Overriding location information provided by the user requires a Overriding location information provided by the user requires a
deployment where an intermediary necessarily knows better than an deployment where an intermediary necessarily knows better than an end
end user - after all, it could be that Alice has an on-board GPS, user -- after all, it could be that Alice has an on-board GPS, and
and the SIP intermediary only knows her nearest cell tower. Which is the SIP intermediary only knows her nearest cell tower. Which is
more accurate location information? Currently, there is no way to more accurate location information? Currently, there is no way to
tell which entity is more accurate, or which is wrong - for that tell which entity is more accurate or which is wrong, for that
matter. This document will not specify how to indicate which matter. This document will not specify how to indicate which
location is more accurate than another. location is more accurate than another.
As an aside, it is not envisioned that any SIP-based emergency As an aside, it is not envisioned that any SIP-based emergency
services request (i.e., IP-911, or 112 type of call attempt) will services request (i.e., IP-911 or 112 type of call attempt) will
receive a corrective 'Bad Location Information' response from an receive a corrective 'Bad Location Information' response from an
intermediary. Most likely, the SIP intermediary would in that intermediary. Most likely, in that scenario, the SIP intermediary
scenario act as a B2BUA and insert into the request by-value any would act as a B2BUA and insert into the request by-value any
appropriate location information for the benefit of Public Safety appropriate location information for the benefit of Public Safety
Answering Point (PSAP) call centers to expedite call reception by Answering Point (PSAP) call centers to expedite call reception by the
the emergency services personnel; thereby, minimizing any delay in emergency services personnel; thereby, minimizing any delay in call
call establishment time. The implementation of these specialized establishment time. The implementation of these specialized
deployments is, however, outside the scope of this document. deployments is, however, outside the scope of this document.
4. SIP Extensions for Geolocation Conveyance 4. SIP Extensions for Geolocation Conveyance
The following sections detail the extensions to SIP for location The following sections detail the extensions to SIP for location
conveyance. conveyance.
4.1 The Geolocation Header Field 4.1. The Geolocation Header Field
This document defines "Geolocation" as a new SIP header field This document defines "Geolocation" as a new SIP header field
registered by IANA, with the following ABNF [RFC5234]: registered by IANA, with the following ABNF [RFC5234]:
message-header /= Geolocation-header ; (message-header from 3261) message-header =/ Geolocation-header
; (message-header from RFC 3261)
Geolocation-header = "Geolocation" HCOLON locationValue Geolocation-header = "Geolocation" HCOLON locationValue
*( COMMA locationValue ) *( COMMA locationValue )
locationValue = LAQUOT locationURI RAQUOT locationValue = LAQUOT locationURI RAQUOT
*(SEMI geoloc-param) *(SEMI geoloc-param)
locationURI = sip-URI / sips-URI / pres-URI locationURI = sip-URI / sips-URI / pres-URI
/ http-URI / https-URI / http-URI / https-URI
/ cid-url ; (from RFC 2392) / cid-url ; (from RFC 2392)
/ absoluteURI ; (from RFC 3261) / absoluteURI ; (from RFC 3261)
geoloc-param = generic-param; (from RFC 3261)
HCOLON, COMMA, LAQUOT, RAQUOT, and SEMI are defined in RFC3261 geoloc-param = generic-param ; (from RFC 3261)
[RFC3261].
sip-URI, sips-URI and absoluteURI are defined according to [RFC3261]. HCOLON, COMMA, LAQUOT, RAQUOT, and SEMI are defined in [RFC3261].
sip-URI, sips-URI, and absoluteURI are defined according to
[RFC3261].
The pres-URI is defined in [RFC3859]. The pres-URI is defined in [RFC3859].
http-URI and https-URI are defined according to [RFC2616] and http-URI and https-URI are defined according to [RFC2616] and
[RFC2818], respectively. [RFC2818], respectively.
The cid-url is defined in [RFC2392] to locate message body parts. The cid-url is defined in [RFC2392] to locate message body parts.
This URI type is present in a SIP request when location is conveyed This URI type is present in a SIP request when location is conveyed
as a MIME body in the SIP message. as a MIME body in the SIP message.
GEO-URIs [RFC5870] are not appropriate for usage in the SIP GEO-URIs [RFC5870] are not appropriate for usage in the SIP
Geolocation header, because it does not include retention and Geolocation header because it does not include retention and
re-transmission flags as part of the location information. Other URI re-transmission flags as part of the location information. Other URI
schemes used in the location URI MUST be reviewed against the RFC schemes used in the location URI MUST be reviewed against the
3693 [RFC3693] criteria for a Using Protocol. Section 4.6 discusses criteria in [RFC3693] for a Using Protocol. Section 4.6 discusses
how URI schemes are communicated using this SIP extension, and what how URI schemes are communicated using this SIP extension and what to
to do if a URI scheme is received that cannot be supported. do if a URI scheme is received that cannot be supported.
The generic-param in the definition of locationValue is included as The generic-param in the definition of locationValue is included as a
a mechanism for future extensions that might require parameters. mechanism for future extensions that might require parameters. This
This document defines no parameters for use with locationValue. If a document defines no parameters for use with locationValue. If a
Geolocation header field is received that contains generic-params, Geolocation header field is received that contains generic-params,
each parameter SHOULD be ignored, and SHOULD NOT be removed when each parameter SHOULD be ignored, and SHOULD NOT be removed when
forwarding the locationValue. If a need arises to define parameters forwarding the locationValue. If a need arises to define parameters
for use with locationValue, a revision/extension to this document is for use with locationValue, a revision/extension to this document is
required. required.
The Geolocation header field MUST have at least one locationValue. The Geolocation header field MUST have at least one locationValue. A
A SIP intermediary SHOULD NOT add location to a SIP request that SIP intermediary SHOULD NOT add location to a SIP request that
already contains location. This will quite often lead to confusion already contains location. This will quite often lead to confusion
within LRs. However, if a SIP intermediary adds location, even if within LRs. However, if a SIP intermediary adds location, even if
location was not previously present in a SIP request, that SIP location was not previously present in a SIP request, that SIP
intermediary is fully responsible for addressing the concerns of any intermediary is fully responsible for addressing the concerns of any
424 (Bad Location Information) SIP response it receives about this 424 (Bad Location Information) SIP response it receives about this
location addition, and MUST NOT pass on (upstream) the 424 response. location addition and MUST NOT pass on (upstream) the 424 response.
A SIP intermediary that adds a locationValue MUST position the new A SIP intermediary that adds a locationValue MUST position the new
locationValue as the last locationValue within the Geolocation locationValue as the last locationValue within the Geolocation header
header field of the SIP request. field of the SIP request.
This document defines the Geolocation header field as valid in the This document defines the Geolocation header field as valid in the
following SIP requests: following SIP requests:
INVITE [RFC3261], REGISTER [RFC3261], INVITE [RFC3261] REGISTER [RFC3261]
OPTIONS [RFC3261], BYE [RFC3261], OPTIONS [RFC3261] BYE [RFC3261]
UPDATE [RFC3311], INFO [RFC6086], UPDATE [RFC3311] INFO [RFC6086]
MESSAGE [RFC3428], REFER [RFC3515], MESSAGE [RFC3428] REFER [RFC3515]
SUBSCRIBE [RFC3265], NOTIFY [RFC3265], SUBSCRIBE [RFC3265] NOTIFY [RFC3265]
PUBLISH [RFC3903] PUBLISH [RFC3903]
The Geolocation header field MAY be included in any one of the The Geolocation header field MAY be included in any one of the above
above listed requests by a UA, and a 424 response to any one of the listed requests by a UA and a 424 response to any one of the requests
requests sent above. Fully appreciating the caveats/warnings sent above. Fully appreciating the caveats/warnings mentioned above,
mentioned above, a SIP intermediary MAY add the Geolocation header a SIP intermediary MAY add the Geolocation header field.
field.
A SIP intermediary MAY add a Geolocation header field if one is not A SIP intermediary MAY add a Geolocation header field if one is not
present - for example, when a user agent does not support the present -- for example, when a user agent does not support the
Geolocation mechanism but their outbound proxy does and knows the Geolocation mechanism but their outbound proxy does and knows the
Target's location, or any of a number of other use cases (see Target's location, or any of a number of other use cases (see Section
Section 3). 3).
The Geolocation header field MAY be present in a SIP request or The Geolocation header field MAY be present in a SIP request or
response without the presence of a Geolocation-Routing header response without the presence of a Geolocation-Routing header
(defined in Section 4.2). As stated in Section 4.2, the default (defined in Section 4.2). As stated in Section 4.2, the default
value of Geolocation-Routing header-value is "no", meaning SIP value of Geolocation-Routing header-value is "no", meaning SIP
intermediaries MUST NOT view (i.e., process, inspect or actively intermediaries MUST NOT view (i.e., process, inspect, or actively
dereference) any direct or indirect location within this SIP dereference) any direct or indirect location within this SIP message.
message. This is for at least two fundamental reasons, This is for at least two fundamental reasons:
1) to make the possibility of retention of the Target's location 1) to make the possibility of retention of the Target's location
moot (because it was not viewed in the first place); and moot (because it was not viewed in the first place); and
2) to prevent a different treatment of this SIP request based on 2) to prevent a different treatment of this SIP request based on
the contents of the Location Information in the SIP request. the contents of the Location Information in the SIP request.
Any locationValue MUST be related to the original Target. This is Any locationValue MUST be related to the original Target. This is
equally true for the location information in a SIP response, i.e., equally true for the location information in a SIP response, i.e.,
from a SIP intermediary back to the Target as explained in Section from a SIP intermediary back to the Target as explained in Section
3.4. SIP intermediaries SHOULD NOT modify or delete any existing 3.4. SIP intermediaries SHOULD NOT modify or delete any existing
locationValue(s). A use-case in which this would not apply would be locationValue(s). A use case in which this would not apply would be
where the SIP intermediary is an anonymizer. The problem with this where the SIP intermediary is an anonymizer. The problem with this
scenario is that the geolocation included by the Target then becomes scenario is that the geolocation included by the Target then becomes
useless for the purpose or service they wanted to use (include) it useless for the purpose or service for which they wanted to use
for. For example, 911/emergency calling or finding the nearest (include) it. For example, 911/emergency calling or finding the
(towing company/pizza delivery/dry cleaning) service(s) will not nearest (towing company/pizza delivery/dry cleaning) service(s) will
yield intended results if the Location Information were to be not yield intended results if the Location Information were to be
modified or deleted from the SIP request. modified or deleted from the SIP request.
4.2 The Geolocation-Routing Header Field 4.2. The Geolocation-Routing Header Field
This document defines "Geolocation-Routing" as a new SIP header This document defines "Geolocation-Routing" as a new SIP header field
field registered by IANA, with the following ABNF [RFC5234]: registered by IANA, with the following ABNF [RFC5234]:
message-header /= Georouting-header ; (message-header from 3261) message-header =/ Georouting-header
; (message-header from RFC 3261)
Georouting-header = "Geolocation-Routing" HCOLON Georouting-header = "Geolocation-Routing" HCOLON
( "yes" / "no" / generic-value ) ( "yes" / "no" / generic-value )
generic-value = generic-param; (from RFC 3261) generic-value = generic-param; (from RFC 3261)
HCOLON is defined in RFC3261 [RFC3261]. HCOLON is defined in [RFC3261].
The only defined values for the Geolocation-Routing header field are The only defined values for the Geolocation-Routing header field are
"yes" or "no". When the value is "yes", the locationValue can be "yes" or "no". When the value is "yes", the locationValue can be
used for routing decisions along the downstream signaling path by used for routing decisions along the downstream signaling path by
intermediaries. Values other than "yes" or "no" are permitted for intermediaries. Values other than "yes" or "no" are permitted for
future extensions. Implementations not aware of an extension MUST future extensions. Implementations not aware of an extension MUST
treat any other received value the same as "no". treat any other received value the same as "no".
If no Geolocation-Routing header field is present in a SIP request, If no Geolocation-Routing header field is present in a SIP request, a
a SIP intermediary MAY insert this header. Without knowledge from a SIP intermediary MAY insert this header. Without knowledge from a
Rulemaker, the SIP intermediary inserting this header-value SHOULD Rule Maker, the SIP intermediary inserting this header-value SHOULD
NOT set the value to "yes", as this may be more permissive than the NOT set the value to "yes", as this may be more permissive than the
originating party intends. An easy way around this is to have the originating party intends. An easy way around this is to have the
Target always insert this header-value as "no". Target always insert this header-value as "no".
When this Geolocation-Routing header-value is set to "no", this When this Geolocation-Routing header-value is set to "no", this means
means no locationValue (inserted by the originating UAC or any no locationValue (inserted by the originating User Agent Client (UAC)
intermediary along the signaling path) can be used by any SIP or any intermediary along the signaling path) can be used by any SIP
intermediary to make routing decisions. Intermediaries that attempt intermediary to make routing decisions. Intermediaries that attempt
to use the location information for routing purposes in spite of to use the location information for routing purposes in spite of this
this counter indication could end up routing the request improperly counter indication could end up routing the request improperly as a
as a result. Section 4.4 describes the details on what a routing result. Section 4.4 gives the details on what a routing intermediary
intermediary does if it determines it needs to use the location in does if it determines it needs to use the location in the SIP request
the SIP request in order to process the message further. The in order to process the message further. The practical implication
practical implication is that when the Geolocation-Routing is that when the Geolocation-Routing header-value is set to "no", if
header-value is set to "no", if a cid:url is present in the SIP a cid:url is present in the SIP request, intermediaries MUST NOT view
request, intermediaries MUST NOT view the location (because it is the location (because it is not for intermediaries to consider when
not for intermediaries to consider when processing the request), and processing the request); if a location URI is present, intermediaries
if a location URI is present, intermediaries MUST NOT dereference MUST NOT dereference it. UAs are allowed to view location in the SIP
it. UAs are allowed to view location in the SIP request even when request even when the Geolocation-Routing header-value is set to
the Geolocation-Routing header-value is set to "no". An LR MUST by "no". An LR MUST by default consider the Geolocation-Routing header-
default consider the Geolocation-Routing header-value as set to value as set to "no", with no exceptions, unless the header field
"no", with no exceptions, unless the header field value is set to value is set to "yes".
"yes".
A Geolocation-Routing header-value that is set to "no" has no A Geolocation-Routing header-value that is set to "no" has no special
special security properties. It is at most a request for behavior security properties. At most, it is a request for behavior within
within SIP intermediaries. That said, if the Geolocation-Routing SIP intermediaries. That said, if the Geolocation-Routing header-
header-value is set to "no", SIP intermediaries are still to process value is set to "no", SIP intermediaries are still to process the SIP
the SIP request and send it further downstream within the signaling request and send it further downstream within the signaling path if
path if there are no errors present in this SIP request. there are no errors present in this SIP request.
The Geolocation-Routing header field satisfies the recommendations The Geolocation-Routing header field satisfies the recommendations
made in section 3.5 of RFC 5606 [RFC5606] regarding indication of made in Section 3.5 of RFC 5606 [RFC5606] regarding indication of
permission to use location-based routing in SIP. permission to use location-based routing in SIP.
SIP implementations are advised to pay special attention to the SIP implementations are advised to pay special attention to the
policy elements for location retransmission and retention described policy elements for location retransmission and retention described
in RFC 4119. in RFC 4119.
The Geolocation-Routing header field cannot appear without a The Geolocation-Routing header field cannot appear without a header-
header-value in a SIP request or response (i.e., a null value is not value in a SIP request or response (i.e., a null value is not
allowed). The absence of a Geolocation-Routing header-value in a SIP allowed). The absence of a Geolocation-Routing header-value in a SIP
request is always the same as the following header field: request is always the same as the following header field:
Geolocation-Routing: no Geolocation-Routing: no
The Geolocation-Routing header field MAY be present without a The Geolocation-Routing header field MAY be present without a
Geolocation header field in the same SIP request. This concept is Geolocation header field in the same SIP request. This concept is
further explored in Section 4.2.1. further explored in Section 4.2.1.
4.2.1 Explaining Geolocation-Routing header-value States 4.2.1. Explaining Geolocation-Routing Header-Value States
The Geolocation header field contains a Target's location, and MUST The Geolocation header field contains a Target's location, and it
NOT be present if there is no location information in this SIP MUST NOT be present if there is no location information in this SIP
request. The location information is contained in one or more request. The location information is contained in one or more
locationValues. These locationValues MAY be contained in a single locationValues. These locationValues MAY be contained in a single
Geolocation header field, or distributed among multiple Geolocation Geolocation header field or distributed among multiple Geolocation
header fields. (See section 7.3.1 of RFC3261.) header fields. (See Section 7.3.1 of RFC 3261.)
The Geolocation-Routing header field indicates whether or not SIP The Geolocation-Routing header field indicates whether or not SIP
intermediaries can view and then route this SIP request based on the intermediaries can view and then route this SIP request based on the
included (directly or indirectly) location information. The included (directly or indirectly) location information. The
Geolocation-Routing header field MUST NOT appear more than once in Geolocation-Routing header field MUST NOT appear more than once in
any SIP request, and MUST NOT lack a header-value. The default or any SIP request, and MUST NOT lack a header-value. The default or
implied policy of a SIP request that does not have a implied policy of a SIP request that does not have a Geolocation-
Geolocation-Routing header field is the same as if one were present Routing header field is the same as if one were present and the
and the header-value were set to "no". header-value were set to "no".
There are only 3 possible states regarding the Geolocation-Routing There are only three possible states regarding the Geolocation-
header field Routing header field:
- "no" - "no"
- "yes" - "yes"
- no header-field present in this SIP request - no header-field present in this SIP request
The expected results in each state are: The expected results in each state are as follows:
If the Geolocation-Routing Only possible interpretations: If the Geolocation-Routing Only possible interpretations:
-------------------------- ----------------------------- -------------------------- -----------------------------
"no" SIP intermediaries MUST NOT process "no" SIP intermediaries MUST NOT process
included geolocation information included geolocation information
within this SIP request. within this SIP request.
SIP intermediaries inserting a SIP intermediaries inserting a
locationValue into a Geolocation locationValue into a Geolocation
header field (whether adding to an header field (whether adding to an
existing header-value or inserting the existing header-value or inserting the
Geolocation header field for the first Geolocation header field for the first
time) MUST NOT modify or delete the time) MUST NOT modify or delete the
received "no" header-value. received "no" header-value.
"yes" SIP intermediaries can process "yes" SIP intermediaries can process
included geolocation information included geolocation information
within this SIP request, and can within this SIP request and can
change the policy to "no" for change the policy to "no" for
intermediaries further downstream. intermediaries further downstream.
Geolocation-Routing absent If a Geolocation header field exists Geolocation-Routing absent If a Geolocation header field exists
(meaning a locationValue is already (meaning a locationValue is already
present), a SIP intermediary MUST present), a SIP intermediary MUST
interpret the lack of a interpret the lack of a
Geolocation-Routing header field as if Geolocation-Routing header field as if
there were one present and the there were one present and the
header-value is set to "no". header-value is set to "no".
If there is no Geolocation header If there is no Geolocation header
field in this SIP request, the default field in this SIP request, the default
Geolocation-Routing is open and can be Geolocation-Routing is open and can be
set by a SIP intermediary or not at set by a SIP intermediary or not at
all. all.
4.3 424 (Bad Location Information) Response Code 4.3. 424 (Bad Location Information) Response Code
This SIP extension creates a new location-specific response code, This SIP extension creates a new location-specific response code,
defined as follows, defined as follows:
424 (Bad Location Information) 424 (Bad Location Information)
The 424 (Bad Location Information) response code is a rejection of The 424 (Bad Location Information) response code is a rejection of
the request due to its location contents, indicating location the request due to its location contents, indicating location
information that was malformed or not satisfactory for the information that was malformed or not satisfactory for the
recipient's purpose, or could not be dereferenced. recipient's purpose or could not be dereferenced.
A SIP intermediary can also reject a location it receives from a A SIP intermediary can also reject a location it receives from a
Target when it understands the Target to be in a different location. Target when it understands the Target to be in a different location.
The proper handling of this scenario, described in Section 3.4, is The proper handling of this scenario, described in Section 3.4, is
for the SIP intermediary to include the proper location in the 424 for the SIP intermediary to include the proper location in the 424
Response. This SHOULD be included in the response as a MIME message response. This SHOULD be included in the response as a MIME message
body (i.e., a location value), rather than as a URI; however, in body (i.e., a location value) rather than as a URI; however, in cases
cases where the intermediary is willing to share location with where the intermediary is willing to share location with recipients
recipients but not with a user agent, a reference might be but not with a user agent, a reference might be necessary.
necessary.
As mentioned in Section 3.4, it might be the case that the As mentioned in Section 3.4, it might be the case that the
intermediary does not want to chance providing less accurate intermediary does not want to chance providing less accurate location
location information than the user agent; thus it will compose its information than the user agent; thus, it will compose its
understanding of where the user agent is in a separate <geopriv> understanding of where the user agent is in a separate <geopriv>
element of the same PIDF-LO [RFC4119] message body in the SIP element of the same Presence Information Data Format Location Object
response (which also contains the Target's version of where it is). (PIDF-LO) [RFC4119] message body in the SIP response (which also
Therefore, both locations are included - each with different contains the Target's version of where it is). Therefore, both
<method> elements. The proper reaction of the user agent is to locations are included -- each with different <method> elements. The
generate a new SIP request that includes this composed location proper reaction of the user agent is to generate a new SIP request
object, and send it towards the original LR. SIP intermediaries can that includes this composed location object, and send it towards the
verify that subsequent requests properly insert the suggested original LR. SIP intermediaries can verify that subsequent requests
location information before forwarding said requests. properly insert the suggested location information before forwarding
said requests.
SIP intermediaries that are forwarding (as opposed to generating) a SIP intermediaries that are forwarding (as opposed to generating) a
424 response MUST NOT add, modify, or delete any location appearing 424 response MUST NOT add, modify, or delete any location appearing
in that response. This specifically applies to intermediaries that in that response. This specifically applies to intermediaries that
are between the 424 response generator and the original UAC. are between the 424 response generator and the original UAC.
Geolocation and Geolocation-Error header fields and PIDF-LO body Geolocation and Geolocation-Error header fields and PIDF-LO body
parts MUST remain unchanged, never added to or deleted. parts MUST remain unchanged, never added to or deleted.
Section 4.4 describes a Geolocation-Error header field to provide Section 4.4 describes a Geolocation-Error header field to provide
more detail about what was wrong with the location information in more detail about what was wrong with the location information in the
the request. This header field MUST be included in the 424 response. request. This header field MUST be included in the 424 response.
It is only appropriate to generate a 424 response when the It is only appropriate to generate a 424 response when the responding
responding entity needs a locationValue and there are no values in entity needs a locationValue and there are no values in the request
the request that are usable by the responder, or when the responder that are usable by the responder, or when the responder has
has additional location information to provide. The latter case is additional location information to provide. The latter case is shown
shown in Figure 4 of section 3.4. There, a SIP intermediary is in Figure 4 of Section 3.4. There, a SIP intermediary is informing
informing the upstream UA which location to include in the next SIP the upstream UA which location to include in the next SIP request.
request.
A 424 MUST NOT be sent in response to a request that lacks a A 424 response MUST NOT be sent in response to a request that lacks a
Geolocation header entirely, as the user agent in that case may not Geolocation header entirely, as the user agent in that case may not
support this extension at all. If a SIP intermediary inserted a support this extension at all. If a SIP intermediary inserted a
locationValue into a SIP request where one was not previously locationValue into a SIP request where one was not previously
present, it MUST take any and all responsibility for the corrective present, it MUST take any and all responsibility for the corrective
action if it receives a 424 to a SIP request it sent. action if it receives a 424 response to a SIP request it sent.
A 424 (Bad Location Information) response is a final response within A 424 (Bad Location Information) response is a final response within
a transaction, and MUST NOT terminate an existing dialog. a transaction and MUST NOT terminate an existing dialog.
4.4 The Geolocation-Error Header Field 4.4. The Geolocation-Error Header Field
As discussed in Section 4.3, more granular error notifications As discussed in Section 4.3, more granular error notifications
specific to location errors within a received request are required specific to location errors within a received request are required if
if the location inserting entity is to know what was wrong within the location inserting entity is to know what was wrong within the
the original request. The Geolocation-Error header field is used for original request. The Geolocation-Error header field is used for
this purpose. this purpose.
The Geolocation-Error header field is used to convey The Geolocation-Error header field is used to convey location-
location-specific errors within a response. The Geolocation-Error specific errors within a response. The Geolocation-Error header
header field has the following ABNF [RFC5234]: field has the following ABNF [RFC5234]:
message-header /= Geolocation-Error message-header =/ Geolocation-Error
; (message-header from 3261) ; (message-header from RFC 3261)
Geolocation-Error = "Geolocation-Error" HCOLON Geolocation-Error = "Geolocation-Error" HCOLON
locationErrorValue locationErrorValue
locationErrorValue = location-error-code locationErrorValue = location-error-code
*(SEMI location-error-params) *(SEMI location-error-params)
location-error-code = 1*3DIGIT location-error-code = 1*3DIGIT
location-error-params = location-error-code-text location-error-params = location-error-code-text
/ generic-param ; from RFC3261 / generic-param ; from RFC 3261
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 location-error-code-text = "code" EQUAL quoted-string
; from RFC 3261
HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is HCOLON, SEMI, and EQUAL are defined in [RFC3261]. DIGIT is defined
defined in RFC5234 [RFC5234]. in [RFC5234].
The Geolocation-Error header field MUST contain only one The Geolocation-Error header field MUST contain only one
locationErrorValue to indicate what was wrong with the locationValue locationErrorValue to indicate what was wrong with the locationValue
the Location Recipient determined was bad. The locationErrorValue the Location Recipient determined was bad. The locationErrorValue
contains a 3-digit error code indicating what was wrong with the contains a 3-digit error code indicating what was wrong with the
location in the request. This error code has a corresponding quoted location in the request. This error code has a corresponding quoted
error text string that is human understandable. The text string is error text string that is human understandable. The text string is
OPTIONAL, but RECOMMENDED for human readability, similar to the OPTIONAL, but RECOMMENDED for human readability, similar to the
string phrase used for SIP response codes. That said, the strings string phrase used for SIP response codes. That said, the strings
are complete enough for rendering to the user, if so desired. The are complete enough for rendering to the user, if so desired. The
strings in this document are recommendations, and are not strings in this document are recommendations, and are not
standardized - meaning an operator can change the strings - but MUST standardized -- meaning an operator can change the strings -- but
NOT change the meaning of the error code. Similar to how RFC 3261 MUST NOT change the meaning of the error code. Similar to how RFC
specifies, there MUST NOT be more than one string per error code. 3261 specifies, there MUST NOT be more than one string per error
code.
The Geolocation-Error header field MAY be included in any response The Geolocation-Error header field MAY be included in any response to
to one of the SIP Methods mentioned in Section 4.1, so long as a one of the SIP Methods mentioned in Section 4.1, so long as a
locationValue was in the request part of the same transaction. For locationValue was in the request part of the same transaction. For
example, Alice includes her location in an INVITE to Bob. Bob can example, Alice includes her location in an INVITE to Bob. Bob can
accept this INVITE, thus creating a dialog, even though his UA accept this INVITE, thus creating a dialog, even though his UA
determined the location contained in the INVITE was bad. Bob merely determined the location contained in the INVITE was bad. Bob merely
includes a Geolocation-Error header value in the 200 OK to the includes a Geolocation-Error header value in the 200 OK response to
INVITE informing Alice the INVITE was accepted but the location the INVITE informing Alice the INVITE was accepted but the location
provided was bad. provided was bad.
If, on the other hand, Bob cannot accept Alice's INVITE without a If, on the other hand, Bob cannot accept Alice's INVITE without a
suitable location, a 424 (Bad Location Information) is sent. This suitable location, a 424 (Bad Location Information) response is sent.
message flow is shown in Figures 1, 2 or 3 in Sections 3.1, 3.2 and This message flow is shown in Figures 1, 2, or 3 in Sections 3.1,
3.3 respectively. 3.2, and 3.3, respectively.
If Alice is deliberately leaving location information out of the LO If Alice is deliberately leaving location information out of the LO
because she does not want Bob to have this additional information, because she does not want Bob to have this additional information,
implementations should be aware that Bob could error repeatedly in implementations should be aware that Bob could repeatedly error in
order to receive more location information about Alice in a order to receive more location information about Alice in a
subsequent SIP request. Implementations MUST be on guard for this, subsequent SIP request. Implementations MUST be on guard for this,
by not allowing continually more information to be revealed unless by not allowing continually more information to be revealed unless it
it is clear that any LR is permitted by Alice to know all that Alice is clear that any LR is permitted by Alice to know all that Alice
knows about her location. A limit on the number of such rejections knows about her location. A limit on the number of such rejections
to learn more location information SHOULD be configurable, with a to learn more location information SHOULD be configurable, with a
RECOMMENDED maximum of 3 times for each related transaction. RECOMMENDED maximum of three times for each related transaction.
A SIP intermediary that requires Alice's location in order to A SIP intermediary that requires Alice's location in order to
properly process Alice's INVITE also sends a 424 with a properly process Alice's INVITE also sends a 424 response with a
Geolocation-Error code. This message flow is shown in Figure 4 of Geolocation-Error code. This message flow is shown in Figure 4 of
Section 3.4. Section 3.4.
If more than one locationValue is present in a SIP request and at If more than one locationValue is present in a SIP request and at
least one locationValue is determined to be valid by the LR, the least one locationValue is determined to be valid by the LR, the
location in that SIP request MUST be considered good as far as location in that SIP request MUST be considered good as far as
location is concerned, and no Geolocation-Error is to be sent. location is concerned, and no Geolocation-Error is to be sent.
Here is an initial list of location based error code ranges for any Here is an initial list of location-based error code ranges for any
SIP response, including provisional responses (other than 100 SIP response, including provisional responses (other than 100 Trying)
Trying) and the new 424 (Bad Location Information) response. These and the new 424 (Bad Location Information) response. These error
error codes are divided into 3 categories, based on how the response codes are divided into three categories, based on how the response
receiver should react to these errors. There MUST be no more than receiver should react to these errors. There MUST be no more than
one Geolocation-Error code in a SIP response, regardless of how many one Geolocation-Error code in a SIP response, regardless of how many
locationValues there are in the correlating SIP request. There is no locationValues there are in the correlating SIP request. When more
guidance given in this document as to which locationValue, when more than one locationValue is present in a SIP request, this mechanism
than one was present in the SIP request, is related to the provides no indication to which one the Geolocation-Error code
Geolocation-Error code; meaning that, somehow not defined here, the corresponds. If multiple errors are present, the LR applies local
LR just picks one to error. policy to select one.
o 1XX errors mean the LR cannot process the location within the o 1XX errors mean the LR cannot process the location within the
request request:
A non-exclusive list of reasons for returning a 1XX is A non-exclusive list of reasons for returning a 1XX is as follows:
- the location was not present or could not be found in the SIP
request,
- there was not enough location information to determine where the
Target was,
- the location was not present or could not be found,
- there was not enough location information to determine
where the Target was,
- the location information was corrupted or known to be - the location information was corrupted or known to be
inaccurate, inaccurate.
o 2XX errors mean some specific permission is necessary to process o 2XX errors mean some specific permission is necessary to process
the included location information. the included location information.
o 3XX errors mean there was trouble dereferencing the Location URI o 3XX errors mean there was trouble dereferencing the Location URI
sent. sent.
Dereference attempts to the same request SHOULD be limited to 10 Dereference attempts to the same request SHOULD be limited to 10
attempts within a few minutes. This number SHOULD be configurable, attempts within a few minutes. This number SHOULD be configurable,
but result in a Geolocation-Error: 300 error once reached. but result in a Geolocation-Error: 300 error once reached.
It should be noted that for non-INVITE transactions, the SIP It should be noted that for non-INVITE transactions, the SIP response
response will likely be sent before the dereference response has will likely be sent before the dereference response has been
been received. This document does not alter that SIP protocol received. This document does not alter that SIP protocol reality.
reality. This means the receiver of any non-INVITE response to a This means the receiver of any non-INVITE response to a request
request containing location SHOULD NOT consider a 200 OK to mean the containing location SHOULD NOT consider a 200 OK response to mean the
act of dereferencing has concluded and the dereferencer (i.e., the act of dereferencing has concluded and the dereferencer (i.e., the
LR) has successfully received and parsed the PIDF-LO for errors and LR) has successfully received and parsed the PIDF-LO for errors and
found none. The end of section 3.2 discusses how transaction timing found none. The end of Section 3.2 discusses how transaction timing
considerations lead to this requirement. considerations lead to this requirement.
Additionally, if an LR cannot or chooses not to process location Additionally, if an LR cannot or chooses not to process location from
from a SIP request, a 500 (Server Internal Error) SHOULD be used a SIP request, a 500 (Server Internal Error) SHOULD be used with or
with or without a configurable Retry-After header field. There is no without a configurable Retry-After header field. There is no special
special location error code for what already exists within SIP location error code for what already exists within SIP today.
today.
Within each of these ranges, there is a top level error as follows: Within each of these ranges, there is a top-level error as follows:
Geolocation-Error: 100 ; code="Cannot Process Location" Geolocation-Error: 100 ; code="Cannot Process Location"
Geolocation-Error: 200 ; code="Permission To Use Location Geolocation-Error: 200 ; code="Permission To Use Location
Information" Information"
Geolocation-Error: 300 ; code="Dereference Failure" Geolocation-Error: 300 ; code="Dereference Failure"
If an error recipient cannot process a specific error code (such as If an error recipient cannot process a specific error code (such as
the 201 or 202 below), perhaps because it does not understand that the 201 or 202 below), perhaps because it does not understand that
specific error code, the error recipient SHOULD process the error specific error code, the error recipient SHOULD process the error
code as if it originally were a top level error code where the X in code as if it originally were a top-level error code where the X in
X00 matches the specific error code. If the error recipient cannot X00 matches the specific error code. If the error recipient cannot
process a non-100 error code, for whatever reason, then the error process a non-100 error code, for whatever reason, then the error
code 100 MUST be processed. code 100 MUST be processed.
There are two specific Geolocation-Error codes necessary to include There are two specific Geolocation-Error codes necessary to include
in this document, both have to do with permissions necessary to in this document, both have to do with permissions necessary to
process the SIP request; they are process the SIP request; they are
Geolocation-Error: 201 ; code="Permission To Retransmit Location Geolocation-Error: 201 ; code="Permission To Retransmit Location
Information to a Third Party" Information to a Third Party"
This location error is specific to having the Presence Information This location error is specific to having the PIDF-LO [RFC4119]
Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set <retransmission-allowed> element set to "no". This location error is
to "no". This location error is stating it requires permission stating it requires permission (i.e., PIDF-LO <retransmission-
(i.e., PIDF-LO <retransmission-allowed> element set to "yes") to allowed> element set to "yes") to process this SIP request further.
process this SIP request further. If the LS sending the location If the LS sending the location information does not want to give this
information does not want to give this permission, it will not permission, it will not change this permission in a new request. If
change this permission in a new request. If the LS wants this the LS wants this message processed with the <retransmission-allowed>
message processed with the <retransmission-allowed> element set to element set to "yes", it MUST choose another logical path (if one
"yes" it MUST choose another logical path (if one exists) for this exists) for this SIP request.
SIP request.
Geolocation-Error: 202 ; code="Permission to Route based on Location Geolocation-Error: 202 ; code="Permission to Route based on Location
Information" Information"
This location error is specific to having the Geolocation-Routing This location error is specific to having the Geolocation-Routing
header value set to "no". This location error is stating it requires header value set to "no". This location error is stating it requires
permission (i.e., the Geolocation-Routing header value set to "yes") permission (i.e., the Geolocation-Routing header value set to "yes")
to process this SIP request further. If the LS sending the location to process this SIP request further. If the LS sending the location
information does not want to give this permission, it will not information does not want to give this permission, it will not change
change this permission in a new request. If the LS wants this this permission in a new request. If the LS wants this message
message processed with the <retransmission-allowed> element set to processed with the <retransmission-allowed> element set to "yes", it
"yes" it MUST choose another logical path (if one exists) for this MUST choose another logical path (if one exists) for this SIP
SIP request. request.
4.5 Location URIs in Message Bodies 4.5. Location URIs in Message Bodies
In the case where an LR sends a 424 response and wishes to In the case where an LR sends a 424 response and wishes to
communicate suitable location by reference rather than by value, the communicate suitable location-by-reference rather than location-by-
424 MUST include a content-indirection body per RFC 4483. value, the 424 response MUST include a content-indirection body per
RFC 4483.
4.6 Location Profile Negotiation 4.6. Location Profile Negotiation
The following is part of the discussion started in Section 3, Figure The following is part of the discussion started in Section 3, Figure
2, which introduced the concept of sending location indirectly. 2, which introduced the concept of sending location indirectly.
If a location URI is included in a SIP request, the sending user If a location URI is included in a SIP request, the sending user
agent MUST also include a Supported header field indicating which agent MUST also include a Supported header field indicating which
location profiles it supports. Two option tags for location profiles location profiles it supports. Two option tags for location profiles
are defined by this document: "geolocation-sip" and are defined by this document: "geolocation-sip" and "geolocation-
"geolocation-http". Future specifications MAY define further http". Future specifications MAY define further location profiles
location profiles per the IANA policy described in Section 8.3. per the IANA policy described in Section 8.3.
The "geolocation-sip" option tag signals support for acquiring The "geolocation-sip" option tag signals support for acquiring
location information via the presence event package of SIP location information via the presence event package of SIP [RFC3856].
([RFC3856]). A location recipient who supports this option can send A location recipient who supports this option can send a SUBSCRIBE
a SUBSCRIBE request and parse a resulting NOTIFY containing a request and parse a resulting NOTIFY containing a PIDF-LO object.
PIDF-LO object. The URI schemes supported by this option include The URI schemes supported by this option include "sip", "sips", and
"sip", "sips" and "pres". "pres".
The "geolocation-http" option tag signals support for acquiring The "geolocation-http" option tag signals support for acquiring
location information via an HTTP ([RFC2616]). A location recipient location information via HTTP [RFC2616]. A location recipient who
who supports this option can request location with an HTTP GET and supports this option can request location with an HTTP GET and parse
parse a resulting 200 response containing a PIDF-LO object. The URI a resulting 200 response containing a PIDF-LO object. The URI
schemes supported by this option include "http" and "https". A schemes supported by this option include "http" and "https". A
failure to parse the 200 response, for whatever reason, will return failure to parse the 200 response, for whatever reason, will return a
a "Dereference Failure" indication to the original location sending "Dereference Failure" indication to the original location sending
user agent to inform it that location was not delivered as intended. user agent to inform it that location was not delivered as intended.
If the location URI receiver does not understand the URI scheme sent If the location URI receiver does not understand the URI scheme sent
to it, it will return an Unsupported header value of the option-tag to it, it will return an Unsupported header value of the option tag
from the SIP request, and include the option-tag of the preferred from the SIP request, and include the option tag of the preferred URI
URI scheme in the response's Supported header field. scheme in the response's Supported header field.
See [ID-GEO-FILTERS] or [ID-HELD-DEREF] for more details on See [GEO-FILTERS] or [HELD-DEREF] for more details on dereferencing
dereferencing location information. location information.
5. Geolocation Examples 5. Geolocation Examples
5.1 Location-by-value (in Coordinate Format) 5.1. Location-by-Value (in Coordinate Format)
This example shows an INVITE message with a coordinate location. In This example shows an INVITE message with a coordinate location. In
this example, the SIP request uses a sips-URI [RFC3261], meaning this example, the SIP request uses a sips-URI [RFC3261], meaning this
this message is protected using TLS on a hop-by-hop basis. message is protected using Transport Layer Security (TLS) on a hop-
by-hop basis.
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <cid:target123@atlanta.example.com>
Geolocation-Routing: no Geolocation-Routing: no
Accept: application/sdp, application/pidf+xml Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:alice@atlanta.example.com> Contact: <sips:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
...SDP goes here ...Session Description Protocol (SDP) goes here
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com> Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence <presence
xmlns="urn:ietf:params:xml:ns:pidf" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
skipping to change at page 19, line 53 skipping to change at page 21, line 27
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
--boundary1-- --boundary1--
The Geolocation header field from the above INVITE: The Geolocation header field from the above INVITE:
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <cid:target123@atlanta.example.com>
... indicates the content-ID location [RFC2392] within the multipart ... indicates the content-ID location [RFC2392] within the multipart
message body of where location information is. The other message message body of where location information is. The other message
body part is SDP. The "cid:" eases message body parsing and body part is SDP. The "cid:" eases message body parsing and
disambiguates multiple parts of the same type. disambiguates multiple parts of the same type.
If the Geolocation header field did not contain a "cid:" scheme, for If the Geolocation header field did not contain a "cid:" scheme, for
example, it could look like this location URI: example, it could look like this location URI:
Geolocation: <sips:target123@server5.atlanta.example.com> Geolocation: <sips:target123@server5.atlanta.example.com>
... the existence of a non-"cid:" scheme indicates this is a ... the existence of a non-"cid:" scheme indicates this is a
location URI, to be dereferenced to learn the Target's location. Any location URI, to be dereferenced to learn the Target's location. Any
node wanting to know where the target is located would subscribe to node wanting to know where the target is located would subscribe to
the SIP presence event package [RFC3856] at the SIP presence event package [RFC3856] at:
sips:target123@server5.atlanta.example.com sips:target123@server5.atlanta.example.com
(see Figure 2 in Section 3.2 for this message flow). (see Figure 2 in Section 3.2 for this message flow).
5.2 Two Locations Composed in Same Location Object Example 5.2. Two Locations Composed in Same Location Object Example
This example shows the INVITE message after a SIP intermediary This example shows the INVITE message after a SIP intermediary
rejected the original INVITE (say, the one in section 5.1). This rejected the original INVITE (say, the one in Section 5.1). This
INVITE contains the composed LO sent by the SIP intermediary which INVITE contains the composed LO sent by the SIP intermediary that
includes where the intermediary understands Alice to be. The rules includes where the intermediary understands Alice to be. The rules
of RFC 5491 [RFC5491] are followed in this construction. of RFC 5491 [RFC5491] are followed in this construction.
This example is here, but ought not be taken as occurring very This example is here, but ought not be taken as occurring very often.
often. In fact, this example is believed to be a corner case of In fact, this example is believed to be a corner case of location
location conveyance applicability. conveyance applicability.
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188512@atlanta.example.com Call-ID: 3848276298220188512@atlanta.example.com
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <cid:target123@atlanta.example.com>
Geolocation-Routing: no Geolocation-Routing: no
Accept: application/sdp, application/pidf+xml Accept: application/sdp, application/pidf+xml
skipping to change at page 22, line 15 skipping to change at page 23, line 47
</dm:person> </dm:person>
</presence> </presence>
--boundary1-- --boundary1--
6. Geopriv Privacy Considerations 6. Geopriv Privacy Considerations
Location information is considered by most to be highly sensitive Location information is considered by most to be highly sensitive
information, requiring protection from eavesdropping and altering in information, requiring protection from eavesdropping and altering in
transit. [RFC3693] originally articulated rules to be followed by transit. [RFC3693] originally articulated rules to be followed by
any protocol wishing to be considered a "Using Protocol", specifying any protocol wishing to be considered a "Using Protocol", specifying
how a transport protocol meets those rules. [RFC6280] updates how a transport protocol meets those rules. [RFC6280] updates the
the guidance in RFC3693 to include subsequently introduced guidance in RFC 3693 to include subsequently introduced entities and
entities and concepts in the geolocation architecture. concepts in the geolocation architecture.
RFC5606 explores the difficulties inherent in mapping the GEOPRIV RFC 5606 explores the difficulties inherent in mapping the GEOPRIV
architecture onto SIP elements. In particular, the difficulties of architecture onto SIP elements. In particular, the difficulties of
defining and identifying recipients of location information are defining and identifying recipients of location information are given
given in that document, along with guidance in Section 3.3.2 on the in that document, along with guidance in Section 3.3.2 on the use of
use of location by-reference mechanisms to preserve confidentiality location-by-reference mechanisms to preserve confidentiality of
of location information from unauthorized recipients. location information from unauthorized recipients.
In a SIP deployment, location information may be added by any of In a SIP deployment, location information may be added by any of
several elements, including the originating user agent or a proxy several elements, including the originating user agent or a proxy
server. In all cases, the Rule Maker associated with that location server. In all cases, the Rule Maker associated with that location
information decides which entity adds location information and what information decides which entity adds location information and what
access control rules apply. For example, a SIP user agent that does access control rules apply. For example, a SIP user agent that does
not support the Geolocation header may rely on a proxy server under not support the Geolocation header may rely on a proxy server under
the direction of the Rule Maker adding a Geolocation header with a the direction of the Rule Maker adding a Geolocation header with a
reference to location information. The manner in which the Rule reference to location information. The manner in which the Rule
Maker operates on these devices is outside the scope of this Maker operates on these devices is outside the scope of this
document. document.
The manner in which SIP implementations honor the Rule Maker's The manner in which SIP implementations honor the Rule Maker's
stipulations for access control rules (including retention and stipulations for access control rules (including retention and
retransmission) is application-specific and not within the scope of retransmission) is application specific and not within the scope of
SIP protocol operations. Entities in SIP networks that fulfill the SIP protocol operations. Entities in SIP networks that fulfill the
architectural roles of the Location Server or Location Recipient architectural roles of the Location Server or Location Recipient
treat the privacy rules associated with location information per treat the privacy rules associated with location information per the
the guidance in [RFC6280] section 4.2.1. In particular, RFC4119 guidance in [RFC6280], Section 4.2.1. In particular, RFC 4119
(especially 2.2.2) gives guidance for handling access control rules; (especially Section 2.2.2) gives guidance for handling access control
SIP implementations should furthermore consult the emendations in rules; SIP implementations should furthermore consult the
RFC5606. recommendations in RFC 5606.
7. Security Considerations 7. Security Considerations
Conveyance of physical location of a UA raises privacy concerns, Conveyance of physical location of a UA raises privacy concerns, and
and depending on use, there probably will be authentication and depending on use, there probably will be authentication and integrity
integrity concerns. This document calls for conveyance to concerns. This document calls for conveyance to be accomplished
be accomplished through secure mechanisms, like S/MIME encrypting through secure mechanisms, like Secure/Multipurpose Internet Mail
message bodies (although this is not widely deployed), TLS Extensions (S/MIME) encrypting message bodies (although this is not
protecting the overall signaling or conveyance location by-reference widely deployed), TLS protecting the overall signaling or conveyance
and requiring all entities that dereference location to authenticate location-by-reference and requiring all entities that dereference
themselves. In location-based routing cases, encrypting the location to authenticate themselves. In location-based routing
location payload with an end-to-end mechanism such as S/MIME is cases, encrypting the location payload with an end-to-end mechanism
problematic, because one or more proxies on the path need the such as S/MIME is problematic because one or more proxies on the path
ability to read the location information to retarget the message to need the ability to read the location information to retarget the
the appropriate new destination UAS. Data can only be encrypted to a message to the appropriate new destination User Agent Server (UAS).
particular, anticipated target, and thus if multiple recipients need Data can only be encrypted to a particular, anticipated target, and
to inspect a piece of data, and those recipients cannot be predicted thus if multiple recipients need to inspect a piece of data, and
by the sender of data, encryption is not a very feasible choice. those recipients cannot be predicted by the sender of data,
Securing the location hop-by-hop, using TLS, protects the message encryption is not a very feasible choice. Securing the location hop-
from eavesdropping and modification in transit, but exposes the by-hop, using TLS, protects the message from eavesdropping and
information to all proxies on the path as well as the endpoint. In modification in transit, but exposes the information to all proxies
most cases, the UA has no trust relationship with the proxy or on the path as well as the endpoint. In most cases, the UA has no
proxies providing location-based routing services, so such trust relationship with the proxy or proxies providing location-based
end-to-middle solutions might not be appropriate either. routing services, so such end-to-middle solutions might not be
appropriate either.
When location information is conveyed by reference, however, one can When location information is conveyed by reference, however, one can
properly authenticate and authorize each entity that wishes to properly authenticate and authorize each entity that wishes to
inspect location information. This does not require that the sender inspect location information. This does not require that the sender
of data anticipate who will receive data, and it does permit of data anticipate who will receive data, and it does permit multiple
multiple entities to receive it securely, but it does not however entities to receive it securely; however, it does not obviate the
obviate the need for pre-association between the sender of data and need for pre-association between the sender of data and any
any prospective recipients. Obviously, in some contexts this prospective recipients. Obviously, in some contexts, this pre-
pre-association cannot be presumed; when it is not, effectively association cannot be presumed; when it is not, effectively
unauthenticated access to location information must be permitted. In unauthenticated access to location information MUST be permitted. In
this case, choosing pseudo-random URIs for location by-reference, this case, choosing pseudorandom URIs for location-by-reference,
coupled with path encryption like SIPS, can help to ensure that only coupled with path encryption like Session Initiation Protocol Secure
entities on the SIP signaling path learn the URI, and thus restores (SIPS), can help to ensure that only entities on the SIP signaling
rough parity with sending location by-value. path learn the URI, and thus restores rough parity with sending
location-by-value.
Location information is especially sensitive when the identity of Location information is especially sensitive when the identity of its
its Target is obvious. Note that there is the ability, according to Target is obvious. Note that there is the ability, according to
[RFC3693] to have an anonymous identity for the Target's location. [RFC3693], to have an anonymous identity for the Target's location.
This is accomplished by use of an unlinkable pseudonym in the This is accomplished by the use of an unlinkable pseudonym in the
"entity=" attribute of the <presence> element [RFC4479]. Though, "entity=" attribute of the <presence> element [RFC4479]. Though,
this can be problematic for routing messages based on location this can be problematic for routing messages based on location
(covered in the document above). Moreover, anyone fishing for (covered in [RFC4479]). Moreover, anyone fishing for information
information would correlate the identity at the SIP layer with that would correlate the identity at the SIP layer with that of the
of the location information referenced by SIP signaling. location information referenced by SIP signaling.
When a UA inserts location, the UA sets the policy on whether to When a UA inserts location, the UA sets the policy on whether to
reveal its location along the signaling path - as discussed in reveal its location along the signaling path -- as discussed in
Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC
implementations MUST make such capabilities conditional on explicit implementations MUST make such capabilities conditional on explicit
user permission, and MUST alert the user that location is being user permission, and MUST alert the user that location is being
conveyed. conveyed.
This SIP extension offers the default ability to require permission This SIP extension offers the default ability to require permission
to process location while the SIP request is in transit. The to process location while the SIP request is in transit. The default
default for this is set to "no". There is an error explicitly for this is set to "no". There is an error explicitly describing how
describing how an intermediary asks for permission to view the an intermediary asks for permission to view the Target's location,
Target's location, plus a rule stating the user has to be made aware plus a rule stating the user has to be made aware of this permission
of this permission request. request.
There is no end-to-end integrity on any locationValue or There is no end-to-end integrity on any locationValue or
locationErrorValue header field parameter (or middle-to-end if the locationErrorValue header field parameter (or middle-to-end if the
value was inserted by a intermediary), so recipients of either value was inserted by a intermediary), so recipients of either header
header field need to implicitly trust the header field contents, and field need to implicitly trust the header field contents, and take
take whatever precautions each entity deems appropriate given this whatever precautions each entity deems appropriate given this
situation. situation.
8. IANA Considerations 8. IANA Considerations
The following are the IANA considerations made by this SIP The following are the IANA considerations made by this SIP extension.
extension. Modifications and additions to all these registrations Modifications and additions to all these registrations require a
require a standards track RFC (Standards Action). Standards Track RFC (Standards Action).
[Editor's Note: RFC-Editor - within the IANA section, please
replace "this doc" with the assigned RFC number,
if this document reaches publication.]
8.1 IANA Registration for the SIP Geolocation Header Field 8.1. IANA Registration for the SIP Geolocation Header Field
The SIP Geolocation Header Field is created by this document, with The SIP Geolocation header field is created by this document, with
its definition and rules in Section 4.1 of this document, and should its definition and rules in Section 4.1 of this document, and it has
be added to the IANA sip-parameters registry with the following been added to the IANA sip-parameters registry as follows:
actions
1. Update the Header Fields registry with The Header Fields registry has been updated with:
Registry: Header Name Compact Reference
Header Name compact Reference
----------------- ------- --------- ----------------- ------- ---------
Geolocation [this doc] Geolocation [RFC6442]
8.2 IANA Registration for the SIP Geolocation-Routing Header Field 8.2. IANA Registration for the SIP Geolocation-Routing Header Field
The SIP Geolocation-Routing Header Field is created by this document, The SIP Geolocation-Routing header field is created by this document,
with its definition and rules in Section 4.2 of this document, and with its definition and rules in Section 4.2 of this document, and it
should be added to the IANA sip-parameters registry with the has been added to the IANA sip-parameters registry as follows.
following action
1. Update the Header Fields registry with The Header Fields registry has been updated with:
Registry: Header Name Compact Reference
Header Name compact Reference
----------------- ------- --------- ----------------- ------- ---------
Geolocation-Routing [this doc] Geolocation-Routing [RFC6442]
8.3 IANA Registration for Location Profiles 8.3. IANA Registration for Location Profiles
This document defines two new SIP option tags: "geolocation-sip" and This document defines two new SIP option tags: "geolocation-sip" and
"geolocation-http" to be added to the IANA sip-parameters Options "geolocation-http" that have been added to the IANA sip-parameters
Tags registry. Options Tags registry as follows.
Name Description Reference Name Description Reference
----------- ------------------------------------------ --------- ----------- ------------------------------------------ ---------
geolocation-sip The "geolocation-sip" option tag signals [this doc] geolocation-sip The "geolocation-sip" option tag signals [RFC6442]
support for acquiring location information support for acquiring location information
via the presence event package of SIP via the presence event package of SIP
(RFC 3856). A location recipient who (RFC 3856). A location recipient who
supports this option can send a SUBSCRIBE supports this option can send a SUBSCRIBE
request and parse a resulting NOTIFY request and parse a resulting NOTIFY
containing a PIDF-LO object. The URI containing a PIDF-LO object. The URI
schemes supported by this option include schemes supported by this option include
"sip", "sips" and "pres". "sip", "sips", and "pres".
geolocation-http The "geolocation-http" option tag signals [this doc] geolocation-http The "geolocation-http" option tag signals [RFC6442]
support for acquiring location information support for acquiring location information
via an HTTP ([RFC2616]). A location via HTTP (RFC 2616). A location
recipient who supports this option can recipient who supports this option can
request location with an HTTP GET and request location with an HTTP GET and
parse a resulting 200 response containing parse a resulting 200 response containing
a PIDF-LO object. The URI schemes a PIDF-LO object. The URI schemes
supported by this option include "http" supported by this option include "http"
and "https". and "https".
The names of profiles are SIP option-tags, and the guidance in this The names of profiles are SIP option tags, and the guidance in this
document does not supersede the option-tag assignment guidance in document does not supersede the option tag assignment guidance in
[RFC3261] (which requires a Standards Action for the assignment of a [RFC3261] (which requires a Standards Action for the assignment of a
new option tag). This document does however stipulate that new option tag). However, this document does stipulate that option
option-tags included to convey the name of a location profile per tags included to convey the name of a location profile per this
this definition MUST begin with the string "geolocation" followed by definition MUST begin with the string "geolocation" followed by a
a dash. All such option tags should describe protocols used to dash. All such option tags should describe protocols used to acquire
acquire location by reference: these tags have no relevance to location by reference: these tags have no relevance to location
location carried in SIP requests by value, which use standard MIME carried in SIP requests by value, which use standard MIME typing and
typing and negotiation. negotiation.
8.4 IANA Registration for 424 Response Code 8.4. IANA Registration for 424 Response Code
In the SIP Response Codes registry, the following is added In the SIP Response Codes registry, the following is added
Reference: RFC-XXXX (i.e., this document) Reference: RFC 6442
Response code: 424 (recommended number to assign) Response code: 424 (recommended number to assign)
Default reason phrase: Bad Location Information Default reason phrase: Bad Location Information
Registry: Registry:
Response Code Reference Response Code Reference
------------------------------------------ --------- ------------------------------------------ ---------
Request Failure 4xx Request Failure 4xx
424 Bad Location Information [this doc] 424 Bad Location Information [RFC6442]
This SIP Response code is defined in section 4.3 of this document. This SIP Response code is defined in Section 4.3 of this document.
8.5 IANA Registration of New Geolocation-Error Header Field 8.5. IANA Registration of New Geolocation-Error Header Field
The SIP Geolocation-error header field is created by this document, The SIP Geolocation-Error header field is created by this document,
with its definition and rules in Section 4.4 of this document, to be with its definition and rules in Section 4.4 of this document, to be
added to the IANA sip-parameters registry with two actions added to the IANA sip-parameters registry with two actions
1. Update the Header Fields registry with 1. Update the Header Fields registry with:
Registry: Registry:
Header Name compact Reference Header Name Compact Reference
----------------- ------- --------- ----------------- ------- ---------
Geolocation-Error [this doc] Geolocation-Error [RFC6442]
2. In the portion titled "Header Field Parameters and Parameter
Values", add
2. In the portion titled "Header Field Parameters and Parameter
Values", add:
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
----------------- ------------------- ---------- --------- ----------------- ------------------- ---------- ---------
Geolocation-Error code yes [this doc] Geolocation-Error code yes [RFC6442]
8.6 IANA Registration for the SIP Geolocation-Error Codes 8.6. IANA Registration for the SIP Geolocation-Error Codes
This document creates a new registry for SIP, called This document creates a new registry for SIP, called "Geolocation-
"Geolocation-Error Codes." Geolocation-Error codes provide reason Error Codes". Geolocation-Error codes provide reason for the error
for the error discovered by Location Recipients, categorized by discovered by Location Recipients, categorized by action to be taken
action to be taken by error recipient. The initial values for this by error recipient. The initial values for this registry are shown
registry are shown below. below.
Registry Name: Geolocation-Error Codes Registry Name: Geolocation-Error Codes
Reference: [this doc] Reference: [RFC6442]
Registration Procedures: Specification Required Registration Procedures: Specification Required
Code Default Reason Phrase Reference Code Default Reason Phrase Reference
---- --------------------------------------------------- --------- ---- --------------------------------------------------- ---------
100 "Cannot Process Location" [this doc] 100 "Cannot Process Location" [RFC6442]
200 "Permission To Use Location Information" [this doc] 200 "Permission To Use Location Information" [RFC6442]
201 "Permission To Retransmit Location Information to a Third Party" 201 "Permission To Retransmit Location Information
[this doc] to a Third Party" [RFC6442]
202 "Permission to Route based on Location Information" [this doc] 202 "Permission to Route based on Location Information" [RFC6442]
300 "Dereference Failure" [this doc] 300 "Dereference Failure" [RFC6442]
Details of these error codes are in Section 4.4 of this
document. Details of these error codes are in Section 4.4 of this document.
9. Acknowledgements 9. Acknowledgements
To Dave Oran for helping to shape this idea. To Dave Oran for helping to shape this idea.
To Dean Willis for guidance of the effort. To Dean Willis for guidance of the effort.
To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning
Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois
Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson,
Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard Barnes,
Barnes, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach, Jacqueline Lee,
Jacqueline Lee and Adam Roach for constructive feedback and nits and Adam Roach for constructive feedback and nit checking.
checking.
Special thanks to Paul Kyzivat for his help with the ABNF in this Special thanks to Paul Kyzivat for his help with the ABNF in this
document and to Robert Sparks for many helpful comments and the document and to Robert Sparks for many helpful comments and the
proper construction of the Geolocation-Error header field. proper construction of the Geolocation-Error header field.
And finally, to Spencer Dawkins for giving this doc a good scrubbing And finally, to Spencer Dawkins for giving this document a good
to make it more readable. scrubbing to make it more readable.
10. References
10.1 Normative References
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC2392] E. Levinson, "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998
[RFC3856] J. Rosenberg, "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004
[RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859,
August 2004
[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging" , RFC 3428, December 2002
[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002
[RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific 10. References
Event Notification", RFC 3265, June 2002.
[RFC6086] C. Holmberg, E. Burger, H. Kaplan, "Session Initiation 10.1. Normative References
Protocol (SIP) INFO Method and Package Framework", RFC 6086,
January 2011
[RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Method", RFC 3515, April 2003 A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
for Event State Publication", RFC 3903, October 2004. Format", RFC 4119, December 2005.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Specifications: ABNF", STD 68, RFC 5234, January 2008. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
2006 Locators", RFC 2392, August 1998.
[RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC [RFC3856] Rosenberg, J., "A Presence Event Package for the Session
4483, May 2006 Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC
Usage Clarification, Considerations, and Recommendations ", 3859, August 2004.
RFC 5491, March 2009
[RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H.,
for Geographic Locations ('geo' URI)", RFC 5870, June 2010 Huitema, C., and D. Gurle, "Session Initiation Protocol
(SIP) Extension for Instant Messaging", RFC 3428, December
2002.
[RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer UPDATE Method", RFC 3311, October 2002.
Protocol - HTTP/1.1", RFC 2616, June 1999
10.2 Informative References [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
"Geopriv Requirements", RFC 3693, February 2004 Initiation Protocol (SIP) INFO Method and Package
Framework", RFC 6086, January 2011.
[RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of [RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP)
'retransmission-allowed' for SIP Location Conveyance", Extension for Event State Publication", RFC 3903, October
RFC5606, Oct 2008 2004.
[ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Notifications in SIP", draft-ietf-geopriv-loc-filters, "work Syntax Specifications: ABNF", STD 68, RFC 5234, January
in progress", March 2010 2008.
[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July
Thomson, M. Dawson, "A Location Dereferencing Protocol Using 2006.
HELD", "work in progress", June 2011
[RFC6280] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. [RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in
Tschofenig, H. Schulzrinne, "An Architecture for Location Session Initiation Protocol (SIP) Messages", RFC 4483, May
and Location Privacy in Internet Applications", 2006.
draft-ietf-geopriv-arch, "work in progress", October 2010
Authors' Addresses [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
James Polk [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
Cisco Systems Identifier for Geographic Locations ('geo' URI)", RFC
3913 Treemont Circle 5870, June 2010.
Colleyville, Texas 76034
33.00111N [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
96.68142W Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Phone: +1-817-271-3552 10.2. Informative References
Email: jmpolk@cisco.com [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
Brian Rosen [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
NeuStar, Inc.
470 Conrad Dr.
Mars, PA 16046
40.70497N [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of
80.01252W 'retransmission-allowed' for SIP Location Conveyance", RFC
5606, August 2009.
Phone: +1 724 382 1051 [GEO-FILTERS]
Email: br@brianrosen.net Mahy, R., Rosen, B., and H. Tschofenig, "Filtering
Location Notifications in SIP", Work in Progress, March
2010.
Jon Peterson [HELD-DEREF]
NeuStar, Inc. Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "A Location Dereferencing
Protocol Using HELD", Work in Progress, October 2011.
Email: jon.peterson@neustar.biz [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 2011.
Appendix A. Requirements for SIP Location Conveyance Appendix A. Requirements for SIP Location Conveyance
The following subsections address the requirements placed on the The following subsections address the requirements placed on the UAC,
UAC, the UAS, as well as SIP proxies when conveying location. This the UAS, as well as SIP proxies when conveying location. This text
is from the original requirements draft that has since evolved into is from a draft version of the location conveyance requirements that
the solution document (that is above). This has been kept for has since evolved into this document (RFC 6442). It has been kept
historical reasons. for historical reasons.
If a requirement is not obvious in intent, a motivational statement If a requirement is not obvious in intent, a motivational statement
is included below it. is included below it.
A.1 Requirements for a UAC Conveying Location A.1. Requirements for a UAC Conveying Location
UAC-1 The SIP INVITE Method [RFC3261] must support location UAC-1 The SIP INVITE Method [RFC3261] must support location
conveyance. conveyance.
UAC-2 The SIP MESSAGE method [RFC3428] must support location UAC-2 The SIP MESSAGE method [RFC3428] must support location
conveyance. conveyance.
UAC-3 SIP Requests within a dialog should support location UAC-3 SIP Requests within a dialog should support location
conveyance. conveyance.
UAC-4 Other SIP Requests may support location conveyance. UAC-4 Other SIP Requests may support location conveyance.
UAC-5 There must be one, mandatory to implement means of UAC-5 There must be one, mandatory-to-implement means of
transmitting location confidentially. transmitting location confidentially.
Motivation: to guarantee interoperability. Motivation:
To guarantee interoperability.
UAC-6 It must be possible for a UAC to update location conveyed UAC-6 It must be possible for a UAC to update location conveyed at
at any time in a dialog, including during dialog any time in a dialog, including during dialog establishment.
establishment.
Motivation: if a UAC has moved prior to the establishment of a Motivation:
dialog between UAs, the UAC must be able to send location If a UAC has moved prior to the establishment of a dialog
information. If location has been conveyed, and the UA between UAs, the UAC must be able to send location
moves, the UAC must be able to update the location previously information. If location has been conveyed, and the UA moves,
the UAC must be able to update the location previously
conveyed to other parties. conveyed to other parties.
UAC-7 The privacy and security rules established within [RFC3693] UAC-7 The privacy and security rules established within [RFC3693]
that would categorize SIP as a 'Using Protocol' MUST be met. that would categorize SIP as a 'Using Protocol' MUST be met.
UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for UAC-8 The PIDF-LO [RFC4119] is a mandatory-to-implement format for
location conveyance within SIP. location conveyance within SIP.
Motivation: interoperability with other IETF location protocols and Motivation:
Interoperability with other IETF location protocols and
Mechanisms. Mechanisms.
UAC-9 There must be a mechanism for the UAC to request the UAS send UAC-9 There must be a mechanism for the UAC to request the UAS send
its location. its location.
UAC-9 has been DEPRECATED by the SIP WG, due to the many UAC-9 has been DEPRECATED by the SIP WG, due to the many
problems this requirement would have caused if implemented. problems this requirement would have caused if implemented.
The solution is for the above UAS to send a new request to The solution is for the above UAS to send a new request to the
the original UAC with the UAS's location. original UAC with the UAS's location.
UAC-10 There must be a mechanism to differentiate the ability of the UAC-10 There must be a mechanism to differentiate the ability of the
UAC to convey location from the UACs lack of knowledge of its UAC to convey location from the UACs lack of knowledge of its
location location.
Motivation: Failure to receive location when it is expected can Motivation:
happen because the UAC does not implement this extension, or Failure to receive location when it is expected can happen
because the UAC implements the extension, but does not know because the UAC does not implement this extension, or because
where the Target is. This may be, for example, due to the the UAC implements the extension, but does not know where the
failure of the access network to provide a location Target is. This may be, for example, due to the failure of
acquisition mechanism the UAC supports. These cases must be the access network to provide a location acquisition mechanism
differentiated. the UAC supports. These cases must be differentiated.
UAC-11 It must be possible to convey location to proxy servers UAC-11 It must be possible to convey location to proxy servers along
along the path. the path.
Motivation: Location-based routing. Motivation:
Location-based routing.
A.2 Requirements for a UAS Receiving Location A.2. Requirements for a UAS Receiving Location
The following are the requirements for location conveyance by a UAS: The following are the requirements for location conveyance by a UAS:
UAS-1 SIP Responses must support location conveyance. UAS-1 SIP Responses must support location conveyance.
The SIPCORE WG reached consensus that this be allowed, but The SIPCORE WG reached consensus that this be allowed, but not
not to communicate the UAS's location; rather for a SIP to communicate the UAS's location; rather for a SIP
intermediary to inform the UAC which location to include in intermediary to inform the UAC which location to include in
its next SIP request (as a matter of correcting what was its next SIP request (as a matter of correcting what was
originally sent by the UAC). originally sent by the UAC).
UAS-2 There must be a unique 4XX response informing the UAC it did UAS-2 There must be a unique 4XX response informing the UAC it did
not provide applicable location information. not provide applicable location information.
In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS. In addition, requirements UAC-5, 6, 7, and 8 also apply to the UAS.
A.3 Requirements for SIP Proxies and Intermediaries A.3. Requirements for SIP Proxies and Intermediaries
The following are the requirements for location conveyance by a SIP The following are the requirements for location conveyance by a SIP
proxies and intermediaries: proxies and intermediaries:
Proxy-1 Proxy servers must be capable of adding a Location header Proxy-1 Proxy servers must be capable of adding a Location header
field during processing of SIP requests. field during processing of SIP requests.
Motivation: Provide network assertion of location Motivation:
when UACs are unable to do so, or when network assertion is Provide network assertion of location when UACs are unable
more reliable than UAC assertion of location to do so, or when network assertion is more reliable than
UAC assertion of location
Note: Because UACs connected to SIP signaling networks can have Note: Because UACs connected to SIP signaling networks can have
widely varying access network arrangements, including VPN widely varying access network arrangements, including VPN
tunnels and roaming mechanisms, it can be difficult for a tunnels and roaming mechanisms, it can be difficult for a
network to reliably know the location of the endpoint. network to reliably know the location of the endpoint.
Proxies SHOULD NOT assert location of an endpoint unless the Proxies SHOULD NOT assert location of an endpoint unless the
SIP signaling network has reliable knowledge of the actual SIP signaling network has reliable knowledge of the actual
location of the Targets. location of the Targets.
Proxy-2 There must be a unique 4XX response informing the UAC it Proxy-2 There must be a unique 4XX response informing the UAC it did
did not provide applicable location information. not provide applicable location information.
Authors' Addresses
James Polk
Cisco Systems
3913 Treemont Circle
Colleyville, Texas 76034
33.00111N
96.68142W
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Brian Rosen
NeuStar, Inc.
470 Conrad Dr.
Mars, PA 16046
40.70497N
80.01252W
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Jon Peterson
NeuStar, Inc.
EMail: jon.peterson@neustar.biz
 End of changes. 257 change blocks. 
744 lines changed or deleted 713 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/