draft-ietf-sipcore-location-conveyance-06.txt   draft-ietf-sipcore-location-conveyance-07.txt 
Network Working Group James Polk Network Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expires: August 23, 2011 Brian Rosen Expires: Nov 4, 2011 Brian Rosen
Intended Status: Standards Track (PS) Jon Peterson Intended Status: Standards Track (PS) Jon Peterson
NeuStar NeuStar
Feb 23, 2011 May 4, 2011
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sipcore-location-conveyance-06.txt draft-ietf-sipcore-location-conveyance-07.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 August 23, 2011. This Internet-Draft will expire on Nov 4, 2011.
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 33 skipping to change at page 2, line 33
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 . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . 8 4.1 The Geolocation Header Field . . . . . . . . . . . . . . 8
4.2 The Geolocation-Routing Header . . . . . . . . . . . . . 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 . . . . . . 12
4.4 The Geolocation-Error Header . . . . . . . . . . . . . . 13 4.4 The Geolocation-Error Header Field . . . . . . . . . . . 13
4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 16 4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 16
4.6 Location Profile Negotiation . . . . . . . . . . . . . . 16 4.6 Location Profile Negotiation . . . . . . . . . . . . . . 16
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 17 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 17
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 17 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 17
5.2 Two Locations Composed in Same Location Object Example . 19 5.2 Two Locations Composed in Same Location Object Example . 19
6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 20 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
8.1 IANA Registration for New SIP Geolocation Header . . . . 22 8.1 IANA Registration for New SIP Geolocation Header Field . 22
8.2 IANA Registration for New SIP Geolocation-Routing Header 22 8.2 IANA Registration for New SIP Geolocation-Routing Header
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.3 IANA Registration for New SIP Option Tags . . . . . . . . 23 8.3 IANA Registration for New SIP Option Tags . . . . . . . . 23
8.4 IANA Registration for New 424 Response Code . . . . . . . 23 8.4 IANA Registration for New 424 Response Code . . . . . . . 23
8.5 IANA Registration for New SIP Geolocation-Error Header . 24 8.5 IANA Registration for New SIP Geolocation-Error Header
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.6 IANA Registration for New SIP Geolocation-Error Codes . . 24 8.6 IANA Registration for New SIP Geolocation-Error Codes . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1 Normative References . . . . . . . . . . . . . . . . . 25 10.1 Normative References . . . . . . . . . . . . . . . . . 25
10.2 Informative References . . . . . . . . . . . . . . . . . 26 10.2 Informative References . . . . . . . . . . . . . . . . . 26
Author Information . . . . . . . . . . . . . . . . . . . . . 27 Author Information . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Requirements for SIP Location Conveyance . . . . 27 Appendix A. Requirements for SIP Location Conveyance . . . . 27
1. Conventions and Terminology used in this document 1. Conventions and Terminology used in this document
skipping to change at page 3, line 23 skipping to change at page 3, line 25
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, 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 (Target) to a Location Recipient (LR). SIP acts as a Using a Target to a Location Recipient (LR). SIP acts as a Using Protocol
Protocol of location information, as defined in RFC 3693. of location information, as defined in RFC 3693.
In order to convey location information, this document specifies a In order to convey location information, this document specifies
new SIP header, the Geolocation header, which carries a reference to three new SIP header fields, Geolocation, Geolocation-Routing and
a Location Object. That Location Object may appear in a MIME body Geolocation-Error, which carry a reference to a Location Object
attached to the SIP request, or it may be a remote resource in the (LO), grant permission to route a SIP request based on the
network. location-value and provide error notifications specific to location
errors respectively. The Location Object (LO) may appear in a MIME
body attached to the SIP request, or it may be a remote resource in
the network.
Note that per RFC 3693, a Target is an entity whose location is A Target is an entity whose location is being conveyed, per RFC
being conveyed. Thus, a Target could be a SIP user agent (UA), some 3693. Thus, a Target could be a SIP user agent (UA), some other IP
other IP device (a router or a PC) that does not have a SIP stack, a device (a router or a PC) that does not have a SIP stack, a non-IP
non-IP device (a person or a black phone) or even a device (a person or a black phone) or even a non-communications
non-communications device (a building or store front). In no way device (a building or store front). In no way does this document
does this document assume that the SIP user agent client which sends assume that the SIP user agent client which sends a request
a request containing a location object is necessarily the Target. containing a location object is necessarily the Target. The location
The location of a Target conveyed within SIP typically corresponds of a Target conveyed within SIP typically corresponds to that of a
to that of a device controlled by the Target, for example, a mobile device controlled by the Target, for example, a mobile phone, but
phone, but such devices can be separated from their owners, and such devices can be separated from their owners, and moreover, in
moreover, in some cases the user agent may not know its own some cases the user agent may not know its own location.
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
skipping to change at page 6, line 44 skipping to change at page 6, line 48
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 location recipient. It could be the case that
a SIP intermediary which does not perform location-based routing but a SIP intermediary which does not perform location-based routing but
does care when Alice includes her location; for example, it could does care when Alice includes her location; for example, it could
care that the location information is complete or that it correctly care that the location information is complete or that it 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 Pizza Hut, making sure that organization has Alice's contacting your favorite local pizza delivery service, making sure
proper location in the initial SIP request. that organization has Alice's proper location in the initial SIP
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.
The only conceivable way forward, when a second location is placed This document takes a "you break it, you bought it" approach to
into the same SIP request by a SIP intermediary is to dealing with second locations placed into a SIP request by an
take a "you break it, you bought it" philosophy with respect to the intermediary entity. That entity becomes completely responsible for
inserting SIP intermediary. That entity becomes completely all location within that SIP request (more on this in Section 4).
responsible for 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 (we are not going to discuss any other reasons location information, the SIP response will indicate there was 'Bad
in this document, and there are many), the SIP response will Location Information' in the SIP request, and provide a location
indicate there was 'Bad Location Information' in the SIP request, specific error code indicating what Alice needs to do to send an
and provide a location specific error code indicating what Alice acceptable request (see Figure 4 for this scenario).
needs to do to send an 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 | | |
| w/New Location | | | | w/New Location | | |
|<---------------| | | |<---------------| | |
skipping to change at page 8, line 23 skipping to change at page 8, line 24
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 Modifications for Geolocation Conveyance
The following sections detail the modifications to SIP for location The following sections detail the modifications to SIP for location
conveyance. conveyance.
4.1 The Geolocation Header 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 )
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) geoloc-param = generic-param; (from RFC 3261)
HCOLON, COMMA, LAQUOT, RAQUOT, and SEMI are defined in RFC3261
[RFC3261].
sip-URI, sips-URI and absoluteURI are defined according to [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. Geolocation header.
Other URI schemas used in the location URI MUST be reviewed against Other URI schemas used in the location URI MUST be reviewed against
the RFC 3693 [RFC3693] criteria for a Using Protocol. the RFC 3693 [RFC3693] criteria for a Using Protocol.
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 SHOULD be ignored, and SHOULD NOT be removed when forwarding each parameter SHOULD be ignored, and SHOULD NOT be removed when
the locationValue. If a need arises to define parameters for use forwarding the locationValue. If a need arises to define parameters
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 can have one or more locationValues. A
Geolocation header field MUST have at least one header-value. A Geolocation header field MUST have at least one locationValue. 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.
Additionally, the first SIP intermediary to add a locationValue adds A SIP intermediary that adds a locationValue MUST position the new
it as the last locationValue in the header value. A SIP intermediary locationValue as the last locationValue within the Geolocation
that adds a locationValue MUST position it as the last locationValue header field of the SIP request.
of the last Geolocation header field of the message.
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 [RFC2976], UPDATE [RFC3311], INFO [RFC6086],
MESSAGE [RFC3428], REFER [RFC3515], MESSAGE [RFC3428], REFER [RFC3515],
SUBSCRIBE [RFC3265], NOTIFY [RFC3265], SUBSCRIBE [RFC3265], NOTIFY [RFC3265],
PUBLISH [RFC3903], PRACK [RFC3262] 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 listed requests by a UA, and a 424 response to any one of the above listed requests by a UA, and a 424 response to any one of the
requests sent above. Fully appreciating the caveats/warnings requests sent above. Fully appreciating the caveats/warnings
mentioned above, a SIP intermediary MAY add the Geolocation header mentioned above, 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
skipping to change at page 10, line 7 skipping to change at page 10, line 10
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 are not to view any direct or indirect location
within this SIP message. within this SIP message.
Any locationValue MUST be related to the original Target. This is Any locationValue MUST be related to the original Target. This is
equally true the location information in a SIP response, i.e., from equally true the location information in a SIP response, i.e., from
a SIP intermediary back to the Target explained in Section 3.4. a SIP intermediary back to the Target as explained in Section 3.4.
SIP intermediaries are NOT RECOMMENDED to modify existing SIP intermediaries SHOULD NOT modify or delete any existing
locationValue(s), and further not to delete any either. locationValue(s).
4.2 The Geolocation-Routing Header 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)
HCOLON is defined in RFC3261 [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 as a intermediaries. Values other than "yes" or "no" are permitted for
mechanism for future extensions, and should be treated the same as future extensions. Implementations not aware of an extension MUST
"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 SIP intermediary MAY insert this header field with a RECOMMENDED a SIP intermediary MAY insert this header. Without knowledge from a
value of "no" by default. Rulemaker, the SIP intermediary inserting this header-value SHOULD
NOT set the value to "yes", as this could allow the Target's
location to be forwarded to third parties without the Target's
explicit permission. An easy way around this is to have the 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 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 SHOULD NOT view the location (because it is
not for intermediaries to view), and if a location URI is present, not for intermediaries to view), and if a location URI is present,
intermediaries SHOULD NOT dereference it. UAs are allowed to view intermediaries SHOULD NOT dereference it. UAs are allowed to view
location in the SIP request even when the Geolocation-Routing location in the SIP request even when the Geolocation-Routing
header-value is set to "no". An LR MUST by default consider the header-value is set to "no". An LR MUST by default consider the
Geolocation-Routing header-value as set to "no", with no exceptions, Geolocation-Routing header-value as set to "no", with no exceptions,
unless the header field value is set to "yes". unless the header field value is set to "yes".
A Geolocation-Routing header-value is set to "no" has no special A Geolocation-Routing header-value that is set to "no" has no
security properties, this is at most a request for behavior within special security properties. It is at most a request for behavior
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 header-value is set to "no", SIP intermediaries are still to process
process the SIP request and send it further downstream within the the SIP request and send it further downstream within the signaling
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
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
skipping to change at page 11, line 29 skipping to change at page 11, line 40
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 MUST
NOT be present if there is no location information in this SIP NOT be present if there is no location information in this SIP
request. The location information is contained in a 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 RFC3261.)
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
skipping to change at page 12, line 24 skipping to change at page 12, line 35
"yes" Location viewing policy set already "yes" Location viewing policy set already
such that if location is inserted such that if location is inserted
downstream, intermediaries can downstream, intermediaries can
maintain an open viewing of location maintain an open viewing of location
policy or can change policy to "no" policy or can change policy to "no"
for 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), MUST interpret the lack of a present), a SIP intermediary MUST
Geolocation-Routing header field by interpret the lack of a
default as if there were one present Geolocation-Routing header field as if
and the header-value is set to "no". there were one present and the
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 downstream entity 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,
skipping to change at page 13, line 21 skipping to change at page 13, line 33
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 message body in the SIP response (which
also contains the Target's version of where it is). Therefore, both also contains the Target's version of where it is). Therefore, both
locations are included - each with different <method> elements. The locations are included - each with different <method> elements. The
proper reaction of the user agent is to generate a new SIP request proper reaction of the user agent is to generate a new SIP request
that includes this composed location object, and send it towards the that includes this composed location object, and send it towards the
original LR. SIP intermediaries can verify that subsequent requests original LR. SIP intermediaries can verify that subsequent requests
properly insert the suggested location information before forwarding properly insert the suggested location information before forwarding
said requests. said requests.
SIP intermediaries MUST NOT add, modify or delete the location in a SIP intermediaries that are forwarding (as opposed to generating) a
424 response. This specifically applies to intermediaries that are 424 response MUST NOT add, modify, or delete any location appearing
between the 424 response generator and the original UAC. Geolocation in that response. This specifically applies to intermediaries that
and Geolocation-Error header fields and PIDF-LO body parts MUST are between the 424 response generator and the original UAC.
remain unchanged, never added to or deleted. Geolocation and Geolocation-Error header fields and PIDF-LO body
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 request. This header field MUST be included in the 424 response. the 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 entity needs a locationValue and there are no responding entity needs a locationValue and there are no values in
locationValues included in the SIP request that are usable by that the request that are usable by the responder, or when the responder
recipient, or as shown in Figure 4 of section 3.4. In the latter has additional location information to provide. The latter case is
scenario, a SIP intermediary is informing the upstream UA which shown in Figure 4 of section 3.4. There, a SIP intermediary is
location to include in the next SIP request. informing the upstream UA which location to include in the next SIP
request.
A 424 MUST NOT be sent in response to a request that lacks a A 424 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 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 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 the location inserting entity is to know what was wrong within if the location inserting entity is to know what was wrong within
the original request. The Geolocation-Error header field is used for the 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-specific errors within a response. The Geolocation-Error location-specific errors within a response. The Geolocation-Error
header field has the following ABNF [RFC5234]: header field has the following ABNF [RFC5234]:
message-header /= Geolocation-Error-header ; message-header /= Geolocation-Error ;
(message-header from 3261) (message-header from 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 RFC3261
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
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. This text string is error text string that is human understandable. The text string are
OPTIONAL, but RECOMMENDED for human readability. OPTIONAL, but RECOMMENDED for human readability, similar to the
string phrase used for SIP response codes. That said, the strings
are complete enough for rendering to the user, if so desired. The
strings in this document are recommendations, and are not
standardized - meaning an operator can change the strings - but MUST
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.
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
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 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.
skipping to change at page 14, line 51 skipping to change at page 15, line 24
3.3 respectively. 3.3 respectively.
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 sent. This is a location is concerned, and no Geolocation-Error is to be sent.
compromise of complexity vs. accurate information conveyance with
respect to informing each location inserter of every bad location.
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 non-100 response, including the new 424 (Bad Location SIP response, including provisional responses (other than 100
Information) response. These error codes are divided into 3 Trying) and the new 424 (Bad Location Information) response. These
categories, based on how the response receiver should react to these error codes are divided into 3 categories, based on how the response
errors. There MUST be no more than one Geolocation-Error code in a receiver should react to these errors. There MUST be no more than
SIP response, regardless of how many locationValues there are in the one Geolocation-Error code in a SIP response, regardless of how many
correlating SIP request. There is no guidance given in this document locationValues there are in the correlating SIP request. There is no
as to which locationValue, when more than one was present in the SIP guidance given in this document as to which locationValue, when more
request, is related to the Geolocation-Error code; meaning that, than one was present in the SIP request, is related to the
somehow not defined here, the LR just picks one to error. Geolocation-Error code; meaning that, somehow not defined here, the
LR just picks one to error.
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
- the location was not present or could not be found, - the location was not present or could not be found,
- there was not enough location information to determine - there was not enough location information to determine
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,
- etc...
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.
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. At this time, this document does not alter that SIP been received. This document does not alter that SIP protocol
protocol reality. This means the receiver of any non-INVITE response reality. This means the receiver of any non-INVITE response to a
to a request containing location SHOULD NOT consider a 200 OK to request containing location SHOULD NOT consider a 200 OK to mean the
mean the act of dereferencing has concluded and the dereferencer act of dereferencing has concluded and the dereferencer (i.e., the
(i.e., the LR) has successfully received and parsed the PIDF-LO for LR) has successfully received and parsed the PIDF-LO for errors and
errors and found none. This was first brought up in Section 3.2. found none. The end of section 3.2 discusses how transaction timing
considerations lead to this requirement.
Additionally, if a SIP entity cannot or chooses not to process Additionally, if an LR cannot or chooses not to process location
location or the SIP request containing location, the existing from a SIP request, a 500 (Server Internal Error) SHOULD be used
mechanism of responding with a 503 (Service Unavailable) SHOULD be with or without a configurable Retry-After header field. There is no
used with or without a configurable Retry-After header field. There special location error code for what already exists within SIP
is no special 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 "Cannot Process Location" Geolocation-Error: 100 ; code="Cannot Process Location"
Geolocation-Error: 200 "Permission To Use Location Information" Geolocation-Error: 200 ; code="Permission To Use Location
Information"
Geolocation-Error: 300 ; code="Dereference Failure"
If an error recipient cannot process an specific error code (such as
the 201 or 202 below), perhaps because it does not understand that
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
X00 matches the specific error code. If the error recipient cannot
process a non-100 error code, for whatever reason, then the error
code 100 MUST be processed.
Geolocation-Error: 300 "Dereference Failure"
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 "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 reset
this permission in a new request. If the LS wants this message this permission in a new request. If the LS wants this message
processed without this permission reset, it MUST choose another processed without this permission reset, it MUST choose another
logical path (if one exists) for this SIP request. logical path (if one exists) for this SIP request.
Geolocation-Error: 202 "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 reset
this permission in a new request. If the LS wants this message this permission in a new request. If the LS wants this message
processed without this permission reset, it MUST choose another processed without this permission reset, it MUST choose another
logical path (if one exists) for this SIP request. logical path (if one exists) for this SIP request.
skipping to change at page 16, line 48 skipping to change at page 17, line 29
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-http". Future specifications may define further "geolocation-http". Future specifications MAY define further
location profiles per the IANA policy described in Section 8.3. location profiles 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]). A location recipient who supports this option can send ([RFC3856]). A location recipient who supports this option can send
a SUBSCRIBE request and parse a resulting NOTIFY containing a a SUBSCRIBE request and parse a resulting NOTIFY containing a
PIDF-LO object. The URI schemes supported by this option include PIDF-LO object. The URI schemes supported by this option include
"sip", "sips" and "pres". "sip", "sips" and "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 an HTTP ([RFC2616]). A location recipient
who supports this option can request location with an HTTP GET and who supports this option can request location with an HTTP GET and
parse a resulting 200 response containing a PIDF-LO object. The URI parse 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 "Dereference Failure" indication to the original location sending a "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
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
URI scheme in the response's Supported header field.
See [ID-GEO-FILTERS] or [ID-HELD-DEREF] for more details on See [ID-GEO-FILTERS] or [ID-HELD-DEREF] for more details on
dereferencing location information. dereferencing 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 message is protected using TLS on a hop-by-hop basis. this message is protected using 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
Supported: geolocation
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
skipping to change at page 19, line 25 skipping to change at page 20, line 8
location conveyance applicability. location 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
Supported: geolocation
Accept: application/sdp, application/pidf+xml Accept: application/sdp, application/pidf+xml
CSeq: 31863 INVITE CSeq: 31863 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
skipping to change at page 20, line 53 skipping to change at page 21, line 35
</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-GEOPRIV-ARCH] how a transport protocol meets those rules. [ID-GEO-ARCH] updates
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 Implementations of this SIP location conveyance mechanism MUST
adhere to the guidance given in RFC3693 and its updates and/or adhere to the guidance given in RFC3693 and its updates and/or
successors, including (but not limited to) the handling of rules for successors, including (but not limited to) the handling of rules for
retention and retransmission. retention and retransmission.
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,
skipping to change at page 22, line 41 skipping to change at page 23, line 26
require a standards track RFC (Standards Action). require a standards track RFC (Standards Action).
[Editor's Note: RFC-Editor - within the IANA section, please [Editor's Note: RFC-Editor - within the IANA section, please
replace "this doc" with the assigned RFC number, replace "this doc" with the assigned RFC number,
if this document reaches publication.] 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 should
be added to the IANA sip-parameters registry with two actions be added to the IANA sip-parameters registry with the following
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 [this doc] Geolocation [this doc]
8.2 IANA Registration for the SIP Geolocation 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
should be added to the IANA sip-parameters registry with the should be added to the IANA sip-parameters registry with the
following action following action
1. Update the Header Fields registry with 1. Update the Header Fields registry with
Registry: Registry:
Header Name compact Reference Header Name compact Reference
skipping to change at page 24, line 24 skipping to change at page 25, line 9
Header Name compact Reference Header Name compact Reference
----------------- ------- --------- ----------------- ------- ---------
Geolocation-Error [this doc] Geolocation-Error [this doc]
2. In the portion titled "Header Field Parameters and Parameter 2. In the portion titled "Header Field Parameters and Parameter
Values", add 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 [this doc]
* see section 8.6 for the newly created values.
8.6 IANA Registration for the SIP Geolocation-Error Codes 8.6 IANA Registration for the SIP Geolocation-Error Codes
New location specific Geolocation-Error codes are created by this New location specific Geolocation-Error codes are created by this
document, and registered in a new table in the IANA sip-parameters document, and registered in a new table in the IANA sip-parameters
registry. Details of these error codes are in Section 4.4 of this registry. Details of these error codes are in Section 4.4 of this
document. document.
Geolocation-Error codes Geolocation-Error codes
----------------------- -----------------------
Geolocation-Error codes provide reason for the error discovered by Geolocation-Error codes provide reason for the error discovered by
Location Recipients, categorized by action to be taken by error Location Recipients, categorized by action to be taken by error
recipient. recipient.
Code Description Reference Code Default Reason Phrase Reference
---- --------------------------------------------------- --------- ---- --------------------------------------------------- ---------
100 "Cannot Process Location" [this doc] 100 "Cannot Process Location" [this doc]
200 "Permission To Use Location Information" [this doc] 200 "Permission To Use Location Information" [this doc]
201 "Permission To Retransmit Location Information to a Third Party" 201 "Permission To Retransmit Location Information to a Third Party"
[this doc] [this doc]
202 "Permission to Route based on Location Information" [this doc] 202 "Permission to Route based on Location Information" [this doc]
skipping to change at page 25, line 4 skipping to change at page 25, line 38
200 "Permission To Use Location Information" [this doc] 200 "Permission To Use Location Information" [this doc]
201 "Permission To Retransmit Location Information to a Third Party" 201 "Permission To Retransmit Location Information to a Third Party"
[this doc] [this doc]
202 "Permission to Route based on Location Information" [this doc] 202 "Permission to Route based on Location Information" [this doc]
300 "Dereference Failure" [this doc] 300 "Dereference Failure" [this doc]
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, Dan Wing, Matt Lepinski, John Elwell and Jacqueline Lee for Barnes, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach and
constructive feedback and nits checking. Jacqueline Lee for constructive feedback and nits 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 doc a good scrubbing
to make it more readable. to make it more readable.
10. References 10. References
skipping to change at page 26, line 5 skipping to change at page 26, line 41
[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging" , RFC 3428, December 2002 Instant Messaging" , RFC 3428, December 2002
[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002 Method", RFC 3311, October 2002
[RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC6086] C. Holmberg, E. Burger, H. Kaplan, "Session Initiation
Provisional Responses in Session Initiation Protocol (SIP)", Protocol (SIP) INFO Method and Package Framework", RFC 6086,
RFC 3262, June 2002. January 2011
[RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000
[RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003 Method", RFC 3515, April 2003
[RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension [RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008
[RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July
2006 2006
[RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with
Session Description Protocol", RFC 3264, June 2002
[RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC
4483, May 2006 4483, May 2006
[RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO [RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO
Usage Clarification, Considerations, and Recommendations ", Usage Clarification, Considerations, and Recommendations ",
RFC 5491, March 2009 RFC 5491, March 2009
[RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier [RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier
for Geographic Locations ('geo' URI)", RFC 5870, June 2010 for Geographic Locations ('geo' URI)", RFC 5870, June 2010
skipping to change at page 27, line 16 skipping to change at page 27, line 43
[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", December 2010
[ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. [ID-GEO-ARCH] 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
Author Addresses Authors' Addresses
James Polk James Polk
Cisco Systems Cisco Systems
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
33.00111N 33.00111N
96.68142W 96.68142W
Phone: +1-817-271-3552 Phone: +1-817-271-3552
skipping to change at page 29, line 19 skipping to change at page 29, line 47
along the path. along 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.
Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, The SIPCORE WG reached consensus that this be allowed, but
due to the many problems this requirement would have caused not to communicate the UAS's location; rather for a SIP
if implemented. The solution is for the above UAS to send a intermediary to inform the UAC which location to include in
new request to the original UAC with the UAS's location. its next SIP request (as a matter of correcting what was
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: Provide network assertion of location
when UACs are unable to do so, or when network assertion is when UACs are unable to do so, or when network assertion is
more reliable than UAC assertion of location more reliable than UAC assertion of location
Note: Because UACs connected to SIP signaling networks may 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 may be difficult for a tunnels and roaming mechanisms, it can be difficult for a
network to reliably know the location of the endpoint. Proxy network to reliably know the location of the endpoint.
assertion of location is NOT RECOMMENDED unless the SIP Proxies SHOULD NOT assert location of an endpoint unless the
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 not provide applicable location information. did not provide applicable location information.
 End of changes. 66 change blocks. 
155 lines changed or deleted 181 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/