draft-ietf-sipcore-location-conveyance-08.txt   draft-ietf-sipcore-location-conveyance-09.txt 
Network Working Group James Polk Network Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expires: Nov 18, 2011 Brian Rosen Expires: Mar 4, 2012 Brian Rosen
Intended Status: Standards Track (PS) Jon Peterson Intended Status: Standards Track (PS) Jon Peterson
NeuStar NeuStar
May 18, 2011 Sept 4, 2011
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sipcore-location-conveyance-08.txt 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 (SIP) to convey geographic location information from one Protocol (SIP) to convey geographic location information from one
SIP entity to another SIP entity. The SIP extension covers SIP entity to another SIP entity. The SIP extension covers
end-to-end conveyance as well as location-based routing, where SIP end-to-end 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.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on Nov 18, 2011. This Internet-Draft will expire on Mar 4, 2012.
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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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. Conventions and Terminology used in this document . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . 4 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 . . . . . . . 5
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 Modifications 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 . . . . . . . . . . 10
4.2.1 Explaining Geolocation-Routing header-value States . . 11 4.2.1 Explaining Geolocation-Routing header-value States . . 11
4.3 424 (Bad Location Information) Response Code . . . . . . 12 4.3 424 (Bad Location Information) Response Code . . . . . . 13
4.4 The Geolocation-Error Header Field . . . . . . . . . . . 13 4.4 The Geolocation-Error Header Field . . . . . . . . . . . 14
4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 16 4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 17
4.6 Location Profile Negotiation . . . . . . . . . . . . . . 16 4.6 Location Profile Negotiation . . . . . . . . . . . . . . 17
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 17 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 18
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 17 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 18
5.2 Two Locations Composed in Same Location Object Example . 19 5.2 Two Locations Composed in Same Location Object Example . 20
6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 20 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
8.1 IANA Registration for New SIP Geolocation Header Field . 22 8.1 IANA Registration for New SIP Geolocation Header Field . 24
8.2 IANA Registration for New SIP Geolocation-Routing Header 8.2 IANA Registration for New SIP Geolocation-Routing Header
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.3 IANA Registration for New SIP Option Tags . . . . . . . . 23
8.4 IANA Registration for New 424 Response Code . . . . . . . 23
8.5 IANA Registration for New SIP Geolocation-Error Header
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.6 IANA Registration for New SIP Geolocation-Error Codes . . 24 8.3 IANA Registration for New SIP Option Tags . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 8.4 IANA Registration for New 424 Response Code . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.5 IANA Registration for New SIP Geolocation-Error Header
10.1 Normative References . . . . . . . . . . . . . . . . . 25 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.2 Informative References . . . . . . . . . . . . . . . . . 26 8.6 IANA Registration for New SIP Geolocation-Error Codes . . 26
Author Information . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Requirements for SIP Location Conveyance . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1 Normative References . . . . . . . . . . . . . . . . . 27
10.2 Informative References . . . . . . . . . . . . . . . . . 28
Author Information . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Requirements for SIP Location Conveyance . . . . 29
1. Conventions and Terminology used in this document 1. Conventions and Terminology used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. This document furthermore uses numerous terms defined in [RFC2119]. This document furthermore uses numerous terms defined
in RFC 3693 [RFC3693], including Location Object, Location in RFC 3693 [RFC3693], including Location Object, Location
Recipient, Location Server, Target, and Using Protocol. Recipient, Location Server, Target, Rulemaker and Using Protocol.
2. Introduction 2. 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 Target to a Location Recipient (LR). SIP acts as a Using Protocol a Target to a Location Recipient (LR). SIP acts as a Using Protocol
of location information, as defined in RFC 3693. of location information, as defined in RFC 3693.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
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 4
basic diagrams, with most applications falling under one of the 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 any of the diagrams the SIP intermediary receives the SIP therefore in any of the diagrams the SIP intermediary that receives
request is potentially an LR - though that does not mean such an a SIP request is potentially an LR - though that does not mean such
intermediary necessarily has to route the SIP request based on the an intermediary necessarily has to route the SIP request based on
location information. In some use cases, location information the location information. In some use cases, location information
passes through the LS on the right of each diagram. passes 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 | |
skipping to change at page 6, line 41 skipping to change at page 6, line 41
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 location recipient. It could be the case that routing in order to be a Location Recipient. It could be the case
a SIP intermediary which does not perform location-based routing but that a SIP intermediary which does not perform location-based
does care when Alice includes her location; for example, it could routing does care when Alice includes her location; for example,
care that the location information is complete or that it correctly it could care that the location information is complete or that it
identifies where Alice is. The best example of this is correctly 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, and forwards it. This secondary insertion is generally not request, and forwards it. This secondary insertion is generally not
advisable because downstream SIP entities will not be given any advisable because downstream SIP entities will not be given any
guidance about which location to believe is better, more reliable, guidance about which location to believe is better, more reliable,
less prone to error, more granular, worse than the other location or less prone to error, more granular, worse than the other location or
just plain wrong. just plain wrong.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
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, the SIP intermediary would in that
scenario act as a B2BUA and insert into the request by-value any scenario 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 emergency services personnel; thereby, minimizing any delay in the emergency services personnel; thereby, minimizing any delay in
call establishment time. The implementation of these specialized call 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 Modifications for Geolocation Conveyance 4. SIP Extensions for Geolocation Conveyance
The following sections detail the modifications 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 3261)
Geolocation-header = "Geolocation" HCOLON locationValue Geolocation-header = "Geolocation" HCOLON locationValue
*( COMMA locationValue ) *( COMMA locationValue )
skipping to change at page 9, line 4 skipping to change at page 9, line 4
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. Geolocation header, because it does not include retention and
re-transmission flags as part of the location information. Other URI
Other URI schemas used in the location URI MUST be reviewed against schemes used in the location URI MUST be reviewed against the RFC
the RFC 3693 [RFC3693] criteria for a Using Protocol. 3693 [RFC3693] criteria for a Using Protocol. Section 4.6 discusses
how URI schemes are communicated using this SIP extension, and what
to 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 mechanism for future extensions that might require parameters. a mechanism for future extensions that might require parameters.
This document defines no parameters for use with locationValue. If a This 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 can have one or more locationValues. A The Geolocation header field MUST have at least one locationValue.
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 field of the SIP request. header field of the SIP request.
skipping to change at page 10, line 5 skipping to change at page 10, line 6
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 3). Section 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 are not to view any direct or indirect location intermediaries MUST NOT view (i.e., process, inspect or actively
within this SIP message. dereference) any direct or indirect location within this SIP
message. This is for at least two fundamental reasons,
Any locationValue MUST be related to the original Target. This is 1) to make the possibility of retention of the Target's location
equally true the location information in a SIP response, i.e., from moot (because it was not viewed in the first place); and
a SIP intermediary back to the Target as explained in Section 3.4.
SIP intermediaries SHOULD NOT modify or delete any existing 2) to prevent a different treatment of this SIP request based on
locationValue(s). the contents of the Location Information in the SIP request.
Any locationValue MUST be related to the original Target. This is
equally true for the location information in a SIP response, i.e.,
from a SIP intermediary back to the Target as explained in Section
3.4. SIP intermediaries SHOULD NOT modify or delete any existing
locationValue(s). A use-case in which this would not apply would be
where the SIP intermediary is an anonymizer. The problem with this
scenario is that the geolocation included by the Target then becomes
useless for the purpose or service they wanted to use (include) it
for. For example, 911/emergency calling or finding the nearest
(towing company/pizza delivery/dry cleaning) service(s) will not
yield intended results if the Location Information were to be
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 registered by IANA, with the following ABNF [RFC5234]: field registered by IANA, with the following ABNF [RFC5234]:
message-header /= Georouting-header ; (message-header from 3261) message-header /= Georouting-header ; (message-header from 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)
skipping to change at page 10, line 52 skipping to change at page 11, line 16
means no locationValue (inserted by the originating UAC or any means no locationValue (inserted by the originating UAC or any
intermediary along the signaling path) can be used by any SIP 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 counter indication could end up routing the request improperly this counter indication could end up routing the request improperly
as a result. Section 4.4 describes the details on what a routing as a result. Section 4.4 describes the details on what a routing
intermediary does if it determines it needs to use the location in intermediary does if it determines it needs to use the location in
the SIP request in order to process the message further. The the SIP request in order to process the message further. The
practical implication is that when the Geolocation-Routing practical implication is that when the Geolocation-Routing
header-value is set to "no", if a cid:url is present in the SIP header-value is set to "no", if a cid:url is present in the SIP
request, intermediaries SHOULD NOT view the location (because it is request, intermediaries MUST NOT view the location (because it is
not for intermediaries to view), and if a location URI is present, not for intermediaries to consider when processing the request), and
intermediaries SHOULD NOT dereference it. UAs are allowed to view if a location URI is present, intermediaries MUST NOT dereference
location in the SIP request even when the Geolocation-Routing it. UAs are allowed to view location in the SIP request even when
header-value is set to "no". An LR MUST by default consider the the Geolocation-Routing header-value is set to "no". An LR MUST by
Geolocation-Routing header-value as set to "no", with no exceptions, default consider the Geolocation-Routing header-value as set to
unless the header field value is set to "yes". "no", with no exceptions, unless the header field value is set to
"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 security properties. It is at most a request for behavior special security properties. It is at most a request for behavior
within SIP intermediaries. That said, if the Geolocation-Routing within SIP intermediaries. That said, if the Geolocation-Routing
header-value is set to "no", SIP intermediaries are still to process header-value is set to "no", SIP intermediaries are still to process
the SIP request and send it further downstream within the signaling the SIP request and send it further downstream within the signaling
path if there are no errors present in this SIP request. path if 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
skipping to change at page 12, line 4 skipping to change at page 12, line 19
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-Routing header field is the same as if one were present Geolocation-Routing header field is the same as if one were present
and the header-value were set to "no". and the header-value were set to "no".
There are only 3 possible states regarding the Geolocation-Routing There are only 3 possible states regarding the Geolocation-Routing
header field 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:
If the Geolocation-Routing Only possible interpretations: If the Geolocation-Routing Only possible interpretations:
-------------------------- ----------------------------- -------------------------- -----------------------------
"no" Location viewing policy set already "no" SIP intermediaries MUST NOT process
such that no intermediaries can view included geolocation information
location inserted downstream. 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" Location viewing policy set already "yes" SIP intermediaries can process
such that if location is inserted included geolocation information
downstream, intermediaries can within this SIP request, and can
maintain an open viewing of location change the policy to "no" for
policy or can change policy to "no" intermediaries further downstream.
for 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 downstream entity 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
skipping to change at page 13, line 22 skipping to change at page 13, line 37
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 where the intermediary is willing to share location with cases where the intermediary is willing to share location with
recipients but not with a user agent, a reference might be recipients 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 information than the user agent; thus it will compose its location 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 message body in the SIP response (which element of the same PIDF-LO [RFC4119] message body in the SIP
also contains the Target's version of where it is). Therefore, both response (which also contains the Target's version of where it is).
locations are included - each with different <method> elements. The Therefore, both locations are included - each with different
proper reaction of the user agent is to generate a new SIP request <method> elements. The proper reaction of the user agent is to
that includes this composed location object, and send it towards the generate a new SIP request that includes this composed location
original LR. SIP intermediaries can verify that subsequent requests object, and send it towards the original LR. SIP intermediaries can
properly insert the suggested location information before forwarding verify that subsequent requests properly insert the suggested
said requests. 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
skipping to change at page 14, line 40 skipping to change at page 15, line 5
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261
HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is
defined in RFC5234 [RFC5234]. defined in RFC5234 [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 are 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 MUST
NOT change the meaning of the error code. Similar to how RFC 3261 NOT change the meaning of the error code. Similar to how RFC 3261
specifies, there MUST NOT be more than one string per error code. 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 one of the SIP Methods mentioned in Section 4.1, so long as a to one of the SIP Methods mentioned in Section 4.1, so long as a
skipping to change at page 15, line 15 skipping to change at page 15, line 29
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 to the
INVITE informing Alice the INVITE was accepted but the location 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) is sent. This
message flow is shown in Figures 1, 2 or 3 in Sections 3.1, 3.2 and message flow is shown in Figures 1, 2 or 3 in Sections 3.1, 3.2 and
3.3 respectively. 3.3 respectively.
If Alice is deliberately leaving location information out of the LO
because she does not want Bob to have this additional information,
implementations should be aware that Bob could error repeatedly in
order to receive more location information about Alice in a
subsequent SIP request. Implementations MUST be on guard for this,
by not allowing continually more information to be revealed unless
it 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
to learn more location information SHOULD be configurable, with a
RECOMMENDED maximum of 3 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 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.
skipping to change at page 15, line 54 skipping to change at page 16, line 27
where the Target was, 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
attempts within a few minutes. This number SHOULD be configurable,
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 will likely be sent before the dereference response has response will likely be sent before the dereference response has
been received. This document does not alter that SIP protocol been received. This document does not alter that SIP protocol
reality. This means the receiver of any non-INVITE response to a reality. This means the receiver of any non-INVITE response to a
request containing location SHOULD NOT consider a 200 OK to mean the request containing location SHOULD NOT consider a 200 OK 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.
skipping to change at page 16, line 26 skipping to change at page 17, line 4
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 an 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 Presence Information
Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set
to "no". This location error is stating it requires permission to "no". This location error is stating it requires permission
(i.e., PIDF-LO <retransmission-allowed> element set to "yes") to (i.e., PIDF-LO <retransmission-allowed> element set to "yes") to
process this SIP request further. If the LS sending the location process this SIP request further. If the LS sending the location
information does not want to give this permission, it will not reset information does not want to give this permission, it will not
this permission in a new request. If the LS wants this message change this permission in a new request. If the LS wants this
processed without this permission reset, it MUST choose another message processed with the <retransmission-allowed> element set to
logical path (if one exists) for this SIP request. "yes" it MUST choose another logical path (if one exists) for this
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 reset information does not want to give this permission, it will not
this permission in a new request. If the LS wants this message change this permission in a new request. If the LS wants this
processed without this permission reset, it MUST choose another message processed with the <retransmission-allowed> element set to
logical path (if one exists) for this SIP request. "yes" it MUST choose another logical path (if one exists) for this
SIP 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 by value, the
424 MUST include a content-indirection body per RFC 4483. 424 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
skipping to change at page 21, line 35 skipping to change at page 22, line 15
</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. [ID-GEO-ARCH] updates how a transport protocol meets those rules. [RFC6280] updates
the guidance in RFC3693 to include subsequently-introduced the guidance in RFC3693 to include subsequently introduced
entities and concepts in the geolocation architecture. entities and concepts in the geolocation architecture.
Implementations of this SIP location conveyance mechanism MUST RFC5606 explores the difficulties inherent in mapping the GEOPRIV
adhere to the guidance given in RFC3693 and its updates and/or architecture onto SIP elements. In particular, the difficulties of
successors, including (but not limited to) the handling of rules for defining and identifying recipients of location information are
retention and retransmission. given in that document, along with guidance in Section 3.3.2 on the
use of location by-reference mechanisms to preserve confidentiality
of location information from unauthorized recipients.
In a SIP deployment, location information may be added by any of
several elements, including the originating user agent or a proxy
server. In all cases, the Rule Maker associated with that location
information decides which entity adds location information and what
access control rules apply. For example, a SIP user agent that does
not support the Geolocation header may rely on a proxy server under
the direction of the Rule Maker adding a Geolocation header with a
reference to location information. The manner in which the Rule
Maker operates on these devices is outside the scope of this
document.
The manner in which SIP implementations honor the Rule Maker's
stipulations for access control rules (including retention and
retransmission) is application-specific and not within the scope of
SIP protocol operations. Entities in SIP networks that fulfill the
architectural roles of the Location Server or Location Recipient
treat the privacy rules associated with location information per
the guidance in [RFC6280] section 4.2.1. In particular, RFC4119
(especially 2.2.2) gives guidance for handling access control rules;
SIP implementations should furthermore consult the emendations in
RFC5606.
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 depending on use, there probably will be authentication and and depending on use, there probably will be authentication and
integrity concerns. This document calls for conveyance to integrity concerns. This document calls for conveyance to
be accomplished through secure mechanisms, like S/MIME encrypting be accomplished through secure mechanisms, like S/MIME encrypting
message bodies (although this is not widely deployed), TLS message bodies (although this is not widely deployed), TLS
protecting the overall signaling or conveyance location by-reference protecting the overall signaling or conveyance location by-reference
and requiring all entities that dereference location to authenticate and requiring all entities that dereference location to authenticate
skipping to change at page 22, line 50 skipping to change at page 23, line 54
of the location information referenced by SIP signaling. of the 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 view location while the SIP request is in transit. The default to process location while the SIP request is in transit. The
for this is set to "no". There is an error explicitly describing default for this is set to "no". There is an error explicitly
how an intermediary asks for permission to view the Target's describing how an intermediary asks for permission to view the
location, plus a rule stating the user has to be made aware of this Target's location, plus a rule stating the user has to be made aware
permission request. of this permission 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 field need to implicitly trust the header field contents, and header field need to implicitly trust the header field contents, and
take whatever precautions each entity deems appropriate given this take whatever precautions each entity deems appropriate given this
situation. situation.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 27, line 55 skipping to change at page 29, line 8
[RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of
'retransmission-allowed' for SIP Location Conveyance", 'retransmission-allowed' for SIP Location Conveyance",
RFC5606, Oct 2008 RFC5606, Oct 2008
[ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location
Notifications in SIP", draft-ietf-geopriv-loc-filters, "work Notifications in SIP", draft-ietf-geopriv-loc-filters, "work
in progress", March 2010 in progress", March 2010
[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.
Thomson, M. Dawson, "A Location Dereferencing Protocol Using Thomson, M. Dawson, "A Location Dereferencing Protocol Using
HELD", "work in progress", December 2010 HELD", "work in progress", June 2011
[ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. [RFC6280] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H.
Tschofenig, H. Schulzrinne, "An Architecture for Location Tschofenig, H. Schulzrinne, "An Architecture for Location
and Location Privacy in Internet Applications", and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch, "work in progress", October 2010 draft-ietf-geopriv-arch, "work in progress", October 2010
Authors' Addresses Authors' Addresses
James Polk James Polk
Cisco Systems Cisco Systems
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
skipping to change at page 28, line 43 skipping to change at page 29, line 48
Email: br@brianrosen.net Email: br@brianrosen.net
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
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, the UAS, as well as SIP proxies when conveying location. If a UAC, the UAS, as well as SIP proxies when conveying location. This
requirement is not obvious in intent, a motivational statement is is from the original requirements draft that has since evolved into
included below it. the solution document (that is above). This has been kept for
historical reasons.
If a requirement is not obvious in intent, a motivational statement
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
skipping to change at page 29, line 27 skipping to change at page 30, line 37
at any time in a dialog, including during dialog at any time in a dialog, including during dialog
establishment. establishment.
Motivation: if a UAC has moved prior to the establishment of a Motivation: if a UAC has moved prior to the establishment of a
dialog between UAs, the UAC must be able to send location dialog between UAs, the UAC must be able to send location
information. If location has been conveyed, and the UA information. If location has been conveyed, and the UA
moves, the UAC must be able to update the location previously 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.
 End of changes. 38 change blocks. 
108 lines changed or deleted 167 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/