draft-ietf-sipcore-location-conveyance-01.txt   draft-ietf-sipcore-location-conveyance-02.txt 
SIPCORE Working Group James Polk SIPCORE Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expires: January 13, 2009 Brian Rosen Expires: August 12, 2010 Brian Rosen
Intended Status: Standards Track (PS) NeuStar Intended Status: Standards Track (PS) NeuStar
July 13, 2009 Feb 12, 2010
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sipcore-location-conveyance-01.txt draft-ietf-sipcore-location-conveyance-02.txt
Abstract
This document defines an extension to the Session Initiation
Protocol (SIP) to convey geographic location information from one
SIP entity to another SIP entity. The extension covers end-to-end
conveyance as well as location-based routing, where SIP servers
make routing decisions based upon the location of the user agent
client.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may contain the provisions of BCP 78 and BCP 79.
material from IETF Documents or IETF Contributions published or made
publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an
adequate license from the person(s) controlling the copyright in
such materials, this document may not be modified outside the IETF
Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for
publication as an RFC or to translate it into languages other than
English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 January 13, 2009. This Internet-Draft will expire on Aug 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your publication of this document. Please review these documents
rights and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
Legal document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
This documents and the information contained therein are provided on warranty as described in the BSD License.
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Abstract
This document defines an extension to the Session Initiation This document may contain material from IETF Documents or IETF
Protocol (SIP) to convey geographic location information from one Contributions published or made publicly available before November
SIP entity to another SIP entity. The extension covers end-to-end 10, 2008. The person(s) controlling the copyright in some of this
conveyance as well as location-based routing, where SIP servers material may not have granted the IETF Trust the right to allow
make routing decisions based on the location of the user agent modifications of such material outside the IETF Standards Process.
client. Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4 2.1 Scoping and Describing a Target verses a Device . . . . . 4
4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 5
4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 8
4.2 424 (Bad Location Information) Response Code . . . . . . 10 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 8
4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11 4.2 424 (Bad Location Information) Response Code . . . . . . 12
4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 20 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 12
4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 20 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 24
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 22 4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 24
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 22 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 25
5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 24 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 26
6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 24 5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 27
6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 25 6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 28
6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 29 6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 34 6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 33
7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 38 6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 38
8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43
9.1 IANA Registration for New SIP Geolocation Header . . . . 41 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45
9.2 IANA Registration for New SIP 'geolocation' Option Tag . 41 9.1 IANA Registration for New SIP Geolocation Header . . . . 45
9.3 IANA Registration for New 424 Response Code . . . . . . . 41 9.2 IANA Registration for New SIP 'geolocation' Option Tag . 45
9.4 IANA Registration for New SIP Geolocation-Error Header . 41 9.3 IANA Registration for New 424 Response Code . . . . . . . 45
9.5 IANA Registration for New SIP Geolocation-Error Codes . . 42 9.4 IANA Registration for New SIP Geolocation-Error Header . 45
9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 43 9.5 IANA Registration for New SIP Geolocation-Error Codes . . 46
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 9.6 IANA Registration of Location URI Schemes . . . . . . . . 47
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
11.1 Normative References . . . . . . . . . . . . . . . . . 43 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.2 Informative References . . . . . . . . . . . . . . . . . 45 11.1 Normative References . . . . . . . . . . . . . . . . . 48
Author Information . . . . . . . . . . . . . . . . . . . . . 45 11.2 Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Requirements for SIP Location Conveyance . . . . 45 Author Information . . . . . . . . . . . . . . . . . . . . . 49
Appendix A. Requirements for SIP Location Conveyance . . . . 50
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]. in [RFC2119].
The following terms and acronyms used throughout this document are The following terms and acronyms used throughout this document are
defined here: defined here:
LbyR = Location-by-Reference LbyV: Location-by-Value
LbyV = Location-by-Value
Location Generator (LG): The entity that initially determines or Location Generator (LG): The entity that initially determines or
gathers the location of the Target and creates Location gathers the location of the Target and creates Location
Objects describing the location of the Target [RFC3693]. Objects describing the location of the Target [RFC3693].
Location Inserter: a role created in this document describing the Location Inserter: a role created in this document describing the
entity that included location in a SIP request, either by-value entity that included location in a SIP request, either by-value
or by-reference (i.e., including a location URI). or by-reference (i.e., including a location URI).
Location Object (LO): An object conveying location information Location Object (LO): An object conveying location information
skipping to change at page 4, line 10 skipping to change at page 3, line 53
Target: A person or other entity whose location is communicated by Target: A person or other entity whose location is communicated by
a Geopriv Location Object [RFC3693]. a Geopriv Location Object [RFC3693].
Using Protocol: A protocol that carries a Location Object [RFC3693]. Using Protocol: A protocol that carries a Location Object [RFC3693].
2. Introduction 2. Introduction
This document describes how geolocation can be "conveyed" in a SIP This document describes how geolocation can be "conveyed" in a SIP
request from one SIP entity unsolicited to another entity using SIP request from one SIP entity unsolicited to another entity using SIP
[RFC3261]. Here, "Location" is a description of the physical [RFC3261]. Here, "Location" is a description of the physical
geographical area where something currently exists. Note that this geographical area where something currently exists. This
information is not solicited by the entity that receives it. The "something" is a Location Target. Note that this information is not
mechanism in this document does not allow one SIP user to request solicited (i.e., asked for or requested) by the entity that receives
the location of another SIP user to be returned in a response. it. The mechanism in this document does not define how one SIP
entity requests the location of another SIP entity to be returned in
a response.
Geographic location in the IETF is discussed in RFC 3693 (Geopriv Geographic location in the IETF is discussed in RFC 3693 (Geopriv
Requirements) [RFC3693]. It defines a "Target" as the entity whose Requirements) [RFC3693]. It defines a "Target" as the entity whose
location is being transmitted over IP. A [RFC3693]-defined "Using location is being transmitted over IP. A [RFC3693]-defined "Using
Protocol" describes how a "Location Server" transmits a "Location Protocol" describes how a "Location Server" transmits a "Location
Object" to a "Location Recipient" while maintaining the contained Object" to a "Location Recipient" while maintaining the contained
privacy intentions of the Target intact. This document describes a privacy intentions of the Target intact. This document describes a
SIP extension to carry a Location Object and how it complies with SIP extension to carry a Location Object and how it complies with
the Using Protocol requirements in RFC 3693. the Using Protocol requirements in RFC 3693.
Common terms are in Section 1. Section 3 provides an overview of SIP Common terms are in Section 1. Section 3 provides an overview of SIP
location conveyance. Section 4 details the extensions to SIP location conveyance. Section 4 details the extensions to SIP
necessary to accomplish location conveyance. Section 5 gives decode necessary to accomplish location conveyance. Section 5 gives decode
examples of geolocation within SIP requests, both LbyV and LbyR. examples of geolocation within SIP requests, both with a value and
Section 6 articulates the SIP element type behaviors for location with a reference. Section 6 articulates the SIP element type
conveyance. Section 7 discusses Geopriv privacy considerations. behaviors for location conveyance. Section 7 discusses Geopriv
Section 8 discusses security considerations. Section 9 IANA privacy considerations. Section 8 discusses security
registers the modifications made to SIP by this document in section considerations. Section 9 IANA registers the modifications made to
4. SIP by this document in section 4.
2.1 Scoping and Describing a Target verses a Device
Geographic location is related to a device, not to a user as far as
this document is concerned. When a user is logged onto a device,
the two entities are bound and can be said to be the same Location
Target - as far as this document is concerned. This document
specifies how one UA uses a SIP request to convey its whereabouts to
another UA.
Devices have a <device ID> element in a presence document for
identification, which is usually its MAC (or equivalent) address.
This element is not always present in the presence document. As
will be mentioned in Section 6.1, there are different ways to
identify a Target, including in the form of a SIP Contact address
(as defined by RFC 3261) or a pseudonym.
In SIP, we often interchangeably use the terms 'Alice' and '(the)
UA' to mean the same thing. Sometimes we refer to 'Alice the user',
which means the human, and not the SIP instance of an endpoint.
When we talk about 'Alice' without clarifying we are talking about
the human user, we implicitly bind Alice and the UA as the same
entity, even if she is identified with a pseudonym in SIP signaling.
This is common practice throughout most SIP documents. The Geopriv
architecture does not make this user-to-device binding very often in
its documentation.
The Geopriv architecture describes Location Targets (Target) and
Location Recipients (LR), which can easily fit into the SIP model by
having Alice send Bob her location. In this example, Alice is the
Target and Bob is the Location Recipient. Here, we are not
concerned with how a UA learns its location, either by being told
where it is or from an onboard GPS. This is exclusively within the
Geopriv architecture.
In this document, we allow SIP servers to insert the Target's
location while processing the SIP request towards the destination.
In this scenario, the originating UA (Alice) is always the Target.
The location inserting SIP server is not the Target.
We also allow SIP servers to be consumers of location, i.e., an LR,
for the purposes of making routing decisions based on the location
in a SIP request.
This document maintains the practice of other SIP documents by:
o a Target associated with a user has the inherited identity of
that user (i.e., Alice or Bob). The SIP-URI will generally be
similar to (or be) a Contact address, which could be a pseudonym
for the user; (see Section 6.1 for more on this)
o Alice is a UA, as is Bob. Understanding SIP signaling will
determine which is the UAC and which is the UAS. We specify
later that location can only be in a SIP request, even if that
request contains the location of more than one Target.
o a Target without an identifiable user associated with it is not
necessarily user-less, the binding is just not obvious or could
purposely be a pseudonym (for security reasons) . The SIP-URI
will be more like a fully qualified Call-ID (unique through space
and time, as defined by RFC 3261);
o a Target which is user-less will likely have a SIP-URI, where the
user-part of the address is the MAC (or equivalent) address of
the device, or a pseudo-string id, but still a URI for this
document's purpose;
The above is informative in nature.
3. Overview of SIP Location Conveyance 3. Overview of SIP Location Conveyance
The concept of conveying location in SIP is fairly straightforward. The concept of conveying location in SIP is fairly straightforward.
Location is conveyed directly or indirectly from a transmitting SIP Location is conveyed directly or indirectly from a transmitting SIP
entity to a receiving SIP entity. When location is conveyed entity to a receiving SIP entity. When location is conveyed
directly, it is conveyed as a value contained within the SIP directly, it is conveyed as a value contained within the SIP
request, as in Figure 1. request, as in Figure 1.
Alice Bob LIS Alice Bob LS
| | | | | |
| Request w/ Location | | | Request w/ Location | |
|------------------------>| | |------------------------>| |
| | | | | |
| Response | | | Response | |
|<------------------------| | |<------------------------| |
| | | | | |
Figure 1. Location Conveyed by Value Figure 1. Location Conveyed by Value
skipping to change at page 5, line 32 skipping to change at page 6, line 47
Many protocols can be used for this dereference transaction, but Many protocols can be used for this dereference transaction, but
this is usually determined by the scheme of the location URI in the this is usually determined by the scheme of the location URI in the
SIP request. In other words, if the location URI is a SIPS: URI, SIP request. In other words, if the location URI is a SIPS: URI,
then SIPS would be used to contact the LS to make the dereference. then SIPS would be used to contact the LS to make the dereference.
The location "value" in this SIP extension is in the form of a The location "value" in this SIP extension is in the form of a
"Presence Information Data Format - Location Object", or PIDF-LO, as "Presence Information Data Format - Location Object", or PIDF-LO, as
described in [RFC4119]. A PIDF-LO is an XML scheme specifically for described in [RFC4119]. A PIDF-LO is an XML scheme specifically for
carrying the geographic location of a Target. LbyV refers to a UA carrying the geographic location of a Target. LbyV refers to a UA
including a PIDF-LO as a message body part of a SIP request, sending including a PIDF-LO as a message body part of a SIP request, sending
that Location Object to another SIP element. LbyR refers to a UA that Location Object to another SIP element. A UA can included a
including a location URI in a SIP request header field which can be location URI in a SIP request header field, pointing at a Location
dereferenced by a Location Recipient to retrieve Alice's Location Server, which can be dereferenced by a Location Recipient of this
Object, in the form of a PIDF-LO. location URI to retrieve Alice's Location Object, always in the form
of a PIDF-LO.
To accomplish location conveyance in SIP, a new SIP header field, To accomplish location conveyance in SIP, a new SIP header field,
Geolocation, is created and described in this document. The Geolocation, is created and described in this document. The
Geolocation header field contains a URI that points to where the Geolocation header field contains a URI that points to where the
location is for the location target, either in the body of the SIP location is for the location Target, either in the body of the SIP
request itself (LbyV), or on a Location Server (LbyR). A location request itself, or on a Location Server. A URI to help entities
URI that points to a message body is always a "cid:" URI (Content parse for the location in a SIP request will (always) get this in
Identification), as defined in [RFC2392]. the form of a "cid:" URI (Content Identification), as defined in
[RFC2392].
If the URI in the Geolocation header field is a scheme other than If the URI in the Geolocation header field is a scheme other than
"cid:", a dereference transaction (see Figure 2) is necessary. This "cid:", a dereference transaction (see Figure 2) is necessary. This
document describes how a SIP presence subscription [RFC3856] can be document describes how a SIP presence subscription [RFC3856] can be
used as a dereference protocol. used as a dereference protocol to retrieve the PIDF-LO for the
Target (see Section 4.5).
Location can be inserted in a SIP request by a SIP server as well as Location can be inserted in a SIP request by a SIP server as well as
by a UA. This document offers guidance on this practice. This by a UA. This document offers guidance on this practice. This
document also describes how a location recipient can determine which document also describes how a location recipient can determine which
entity included a specific location, as more than one location can entity included a specific location, as more than one location can
be conveyed in a given SIP request. Section 4 gets into guidance and be conveyed in a given SIP request. Section 4 gets into guidance and
limitations of this behavior. limitations of this behavior.
A new error response (424 Bad Location Information) is also defined A new error response (424 Bad Location Information) is also defined
in this document. Within this response is a new header field in this document. Within this response is a new header field
skipping to change at page 6, line 19 skipping to change at page 7, line 36
additional information about the type of location error experienced additional information about the type of location error experienced
by a Location Recipient, separated into actionable categories to be by a Location Recipient, separated into actionable categories to be
taken by the UAC. taken by the UAC.
Because more than one SIP entity can insert location, when Because more than one SIP entity can insert location, when
considering SIP as an end-to-end protocol, there needs to be a means considering SIP as an end-to-end protocol, there needs to be a means
of identifying which location within a message of multiple locations of identifying which location within a message of multiple locations
was considered bad by a location recipient - if that were to occur. was considered bad by a location recipient - if that were to occur.
The ability to tell which entity (identified by host-id) inserted a The ability to tell which entity (identified by host-id) inserted a
specific location is extremely important. Not only does this allow specific location is extremely important. Not only does this allow
each location error to be targeted at a particular inserter of a each location error to be Targeted at a particular inserter of a
specific location object, but it also allows error recipients to specific location object, but it also allows error recipients to
understand when the location they inserted was not at fault, and understand when the location they inserted was not at fault, and
that a received error is not meant for them. This optimization is that a received error is not meant for them. This optimization is
necessary, otherwise each location error would be a blanket error to necessary, otherwise each location error would be a blanket error to
every entity upstream in the signaling path. every entity upstream in the signaling path.
Just as location can be conveyed by more than one entity about the Just as location can be conveyed by more than one entity about the
same target, there can be more than one location recipient along a same Target, there can be more than one location recipient along a
request's path. It is possible to route SIP requests based on the request's path. It is possible to route SIP requests based on the
location of the target (i.e., source based routing, instead of location of the Target (i.e., source based routing, instead of
normal destination based routing). This means SIP servers can be normal destination based routing). This means SIP servers can be
location recipients. If this is not desired by a Location Inserter, location recipients. If this is not desired by a Location Inserter,
then the Location Inserter can also include a separate indication in then the Location Inserter can also include a separate indication in
the Geolocation header field showing that this usage is not desired. the Geolocation header field showing that this usage is not desired.
Location Inserters have the ability to provide instructional Location Inserters have the ability to provide instructional
parameters about location it has inserted. These are hints to parameters about location it has inserted. These are hints to
downstream entities on how the location information in the message downstream entities on how the location information in the message
was originated, intended and is to be used. was originated, intended and is to be used.
Transport Layer Security is expected when a request contains a Transport Layer Security is expected when a request contains a
target's location. Some implementations will choose to have S/MIME Target's location. Some implementations will choose to have S/MIME
for integrity protection, or to encrypt message bodies from source for integrity protection, or to encrypt message bodies from source
to destination(s). to destination(s).
This document creates a new option tag: geolocation, to indicate This document creates a new option tag: geolocation, to indicate
support for this extension by UAs. support for this extension by UAs.
The new header field, the header parameters, the new option tag, the The new header field, the header parameters, the new option tag, the
new error response, and Geolocation-Error codes are defined in new error response, and Geolocation-Error codes are defined in
Section 4, each of which are IANA registered by this document. Section 4, each of which are IANA registered by this document.
RFC 3693 demands that a transmitted location be required to maintain RFC 3693 demands that a transmitted location be required to maintain
privacy considerations. This document maintains all of the privacy privacy considerations. This document maintains all of the privacy
considerations defined by RFC 3693, plus adds an intended usage considerations defined by RFC 3693, plus adds an intended usage
indication within the SIP Geolocation header field. This increases indication within the SIP Geolocation header field. This increases
the considerations for recipients not to inspect a target's location the considerations for recipients not to inspect a Target's location
when they are not the intended location recipient. when they are not the intended location recipient.
4. SIP Modifications for Geolocation Conveyance 4. SIP Modifications for Geolocation Conveyance
The following sections detail the standards track modifications The following sections detail the standards track modifications
to SIP for Location Conveyance. to SIP for Location 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]:
Geolocation = "Geolocation" HCOLON (locationValue *(COMMA Geolocation = "Geolocation" HCOLON (locationArg
locationValue)) (COMMA retrans-param) *COMMA locationArg)
locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationArg = locationValue / routing-param
locationValue = LAQUOT locationURI RAQUOT SEMI inserted-param
*(SEMI geoloc-param)
locationURI = sip-URI / sips-URI / pres-URI locationURI = sip-URI / sips-URI / pres-URI
/ cid-url ; (from RFC 2392) / cid-url ; (from RFC 2392)
/ absoluteURI ; (from RFC 3261) / absoluteURI ; (from RFC 3261)
geoloc-param = "inserted-by" EQUAL geoloc-inserter inserted-param = "inserted-by" EQUAL geoloc-inserter
/ "used-for-routing"
/ generic-param ; (from RFC 3261)
geoloc-inserter = DQUOTE hostport DQUOTE geoloc-inserter = DQUOTE hostport DQUOTE
/ gen-value ; (from RFC 3261) / gen-value ; (from RFC 3261)
retrans-param = "routing-allowed" EQUAL "yes" / "no" geoloc-param = "used-for-routing" / generic-param ;
(from RFC 3261)
routing-param = "routing-allowed" EQUAL "yes" / "no"
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].
The cid-url is defined in [RFC2392] to locate message body The cid-url is defined in [RFC2392] to locate message body
parts. This URI type is present in a SIP request where location parts. This URI type is present in a SIP request when location
is conveyed as a value. is conveyed as a value.
Other protocols used in the location URI MUST be reviewed against Other protocols used in the location URI MUST be reviewed against
the RFC 3693 criteria for a Using Protocol. the RFC 3693 [RFC 3693] criteria for a Using Protocol.
The Geolocation header field MAY have one or more locationValues. The Geolocation header field MAY have one or more locationValues.
SIP servers inserting a locationValue MUST add the new value as the SIP servers inserting a locationValue MUST add the new value as the
last locationValue in the Geolocation header field (i.e., the last last locationValue in the Geolocation header field (i.e., the last
locationValue in the header field is the most recent one added to locationValue in the header field is the most recent one added to
the message). Placement of the "routing-allowed" parameter, when the message). Placement of the "routing-allowed" parameter, when
present, MUST be the last header field value in the Geolocation present, MUST be the last header field value in the Geolocation
header field. header field.
A locationValue has the following independent header field A locationValue has the following independent header field
skipping to change at page 8, line 35 skipping to change at page 9, line 54
indicating which SIP entity added the locationValue to the SIP indicating which SIP entity added the locationValue to the SIP
request. request.
There MUST NOT be more than one "inserted-by=" parameter or one There MUST NOT be more than one "inserted-by=" parameter or one
"used-for-routing" parameter in the same locationValue. However, "used-for-routing" parameter in the same locationValue. However,
there can be more than one locationValue in the same Geolocation there can be more than one locationValue in the same Geolocation
header field. header field.
The "routing-allowed" header field parameter is a global parameter The "routing-allowed" header field parameter is a global parameter
over any (and all/each) locationValues in the Geolocation header over any (and all/each) locationValues in the Geolocation header
field. This is the reason why the placement of the header field field. The placement of the parameter is outside any locationValue,
parameter is outside any locationValue, appears only once, and is appears only once, and is always last in the header field value. The
always last in the header field value. routing-allowed parameter MAY be present when no locationValue is
present. This scenario sets the routing-allowed policy downstream
along the request's signaling path.
This header field parameter only has the values "=yes" or "=no". This header field parameter only has the values "=yes" or "=no".
When this parameter is "=yes", any locationValue can be used for When this parameter is "=yes", any locationValue can be used for
routing decisions along the downstream signaling path by routing decisions along the downstream signaling path by
intermediaries. When this parameter is "=no", this means no intermediaries.
locationValue (inserted by the originating UAC or any (or
subsequent) intermediary(ies) along the signaling path) can be used When this parameter is "=no", this means no locationValue (inserted
by any SIP intermediary to make routing decisions. This behavior by the originating UAC or any (or subsequent) intermediary(ies)
MUST be adhered to. Section 4.3 describes the details on what a along the signaling path) can be used by any SIP intermediary to
routing intermediary does if it believes it needs to use the make routing decisions. This behavior MUST be adhered to. Sections
location in the SIP request in order to process the message further. 4.3 and 6.3 describe the details on what a routing intermediary does
if it believes it needs to use the location in the SIP request in
order to process the message further.
The practical implication is that when the "routing-allowed" The practical implication is that when the "routing-allowed"
parameter is set to "no", if an LbyV is present in the SIP request, parameter is set to "no", if a cid:url is present in the SIP
intermediaries MUST NOT view the location (because it is not request, intermediaries MUST NOT view the location (because it is
for intermediaries to view), and if an LbyR is present, MUST NOT not for intermediaries to view), and if a location URI is present,
dereference it. UASs are allowed to view location in the SIP intermediaries MUST NOT dereference it. UAs are allowed to view
request even when the "routing-allowed" header field parameter is location in the SIP request even when the "routing-allowed"
set to "no". parameter is set to "no".
The default behavior when this header field parameter is not present There MUST not be more than one routing-allowed parameter in any SIP
in a message is to treat the SIP request as if the parameter were request, regardless of when there are cases of more than one
present and its value is set to "no". Geolocation header field row (i.e., more than one Geolocation
header in the SIP request, as defined in section 7.3.1 of RFC 3261).
There does not have to be any routing-allowed parameter present in a
Geolocation header value of a SIP request. However, the default
treatment of the absence of the routing-allowed parameter is as if
it were present, and set to "=no" without exception.
If a routing-allowed parameter is parsed as set to "=yes", an
implementation MUST parse the rest of the SIP header for another
instance of the Geolocation header value to determine if there is
another instance of the routing-allowed parameter set to "=no". If
this is the case, the behavior MUST be to process the "=no"
indication only, and ignore the "=yes".
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 [RFC2976],
MESSAGE [RFC3428], REFER [RFC3515], MESSAGE [RFC3428], REFER [RFC3515],
SUBSCRIBE [RFC3265], NOTIFY [RFC3265], SUBSCRIBE [RFC3265], NOTIFY [RFC3265],
PUBLISH [RFC3903] and PRACK [RFC3262] PUBLISH [RFC3903] and PRACK [RFC3262]
skipping to change at page 9, line 39 skipping to change at page 11, line 24
---------------------------------------------------------------- ----------------------------------------------------------------
Geolocation R ar o - - o o o o Geolocation R ar o - - o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB Header field where proxy SUB NOT UPD MSG REF INF PUB
---------------------------------------------------------------- ----------------------------------------------------------------
Geolocation R ar o o o o o o o Geolocation R ar o o o o o o o
Table 1: Summary of the Geolocation Header Field Table 1: Summary of the Geolocation Header Field
The Geolocation header field MAY be included in any one of the above The Geolocation header field MAY be included in any one of the above
requests by a UAC. A proxy MAY add the Geolocation header field, requests by a UA. A proxy MAY add the Geolocation header field,
but MUST NOT modify any pre-existing locationValue, including any but MUST NOT modify any pre-existing locationValue, including any
associated header field parameters within an existing Geolocation associated header field parameters within an existing Geolocation
header field value, unless one of the existing locationValues is header field value, unless one of the existing locationValues is
used to retarget the request towards a new destination UAS. This is used to retarget the request towards a new destination UAS. This is
discussed in section 6.3. discussed in section 6.3.
[RFC3261] states message bodies cannot be added by proxies. [RFC3261] states message bodies cannot be added by proxies.
Therefore, any Geolocation header field added by a proxy MUST be in Therefore, any Geolocation header field added by a proxy MUST be in
the form of an location URI, in its own locationValue header field the form of an location URI, in its own locationValue header field
value. value.
A SIP proxy MAY add a Geolocation header field if one is not A SIP proxy MAY add a Geolocation header field if one is not
present, and MAY add the "routing-allowed" parameter if not yet present, and MAY add the "routing-allowed" parameter if not yet
present in the SIP request. When a "routing-allowed" parameter is present in the SIP request. When a "routing-allowed" parameter is
already present in the SIP request, a SIP server MUST NOT change the already present in the SIP request, a SIP server MUST NOT change the
value of the parameter (i.e., from 'yes' to 'no', or from 'no' to value of the parameter (i.e., from 'yes' to 'no', or from 'no' to
'yes'). This would override the policy set by an upstream SIP 'yes'). This would override the policy set by an upstream SIP
entity (i.e., likely the UAC). entity (i.e., the UAC).
Adding a new locationValue to an in-transit request is NOT Adding a new locationValue to an in-transit request is NOT
RECOMMENDED for at least two reasons, RECOMMENDED for at least two reasons,
#1 SIP Servers are not the best locators geographically of where a #1 SIP Servers are not the best geographic locators of where a
UAC is; the location information that a SIP server knows may UA is; the location information that a SIP server knows might
not be the best location information available. not be the best location information available.
#2 this document gives limited guidance as to what a Location #2 this document gives limited guidance as to what a Location
Recipient should do when receiving more than one location (no Recipient should do when receiving more than one location (no
instructions are given about which locationValue to use when instructions are given about which locationValue to use when
more than one is present), so adding a new locationValue may more than one is present), so adding a new locationValue may
lead to undesirable results. lead to undesirable results.
Location Recipients receiving a location object, whether received Location Recipients receiving a location object, whether received
directly or as the result of a dereference, MUST honor the usage directly or as the result of a dereference, MUST honor the usage
element rules within that XML document, as defined in [RFC4119]. element rules within that XML document, as defined in [RFC4119].
Such entities MUST NOT alter the rule set. Such entities MUST NOT alter the rule set.
Other modifications of the Geolocation header field MUST NOT occur
without an update to this specification.
4.2 424 (Bad Location Information) Response Code 4.2 424 (Bad Location Information) Response Code
This SIP extension creates a new location specific response code, This SIP extension creates a new location specific response code,
defined as follows. defined as follows.
424 (Bad Location Information) 424 (Bad Location Information)
The 424 (Bad Location Information) response code is a rejection of The 424 (Bad Location Information) response code is a rejection of
the request due to its location contents, indicating the location the request due to its location contents, indicating the location
information was malformed or not satisfactory for the recipient's information was malformed or not satisfactory for the recipient's
purpose, or could not be dereferenced. purpose, or could not be dereferenced.
Section 4.3 creates the Geolocation-Error header field to provide Section 4.3 creates the 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 in the 424 response, the request. This header field MUST be in the 424 response,
containing a locationErrorValue for each invalid locationValue in containing a locationErrorValue for each invalid locationValue in
the request (i.e., and one-for-one matching if all locationValues the request (i.e., and one-for-one matching if all locationValues
in the request were bad). in the request were bad).
If more than one location is present in a request (LbyV or LbyR), If more than one location is present in a request (value or location
and the Location Recipient can process any of the locationValues, a URI), and the Location Recipient can process any of the
424 MUST NOT be sent. The 424 is only appropriate when the Location locationValues, a 424 MUST NOT be sent. The 424 is only appropriate
Recipient needs a locationValue and there are no locationValues when the Location Recipient needs a locationValue and there are no
included in a SIP request that are usable by a recipient. locationValues included in a SIP request that are usable by a
recipient.
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 does not terminate an existing dialog. a transaction, and does not terminate an existing dialog.
The UAC can use whatever means it knows of to verify/refresh its The UA can use whatever means it knows of to verify/refresh its
location information before attempting a new request that includes location information before attempting a new request that includes
location. There is no cross-transaction awareness expected by either location. There is no cross-transaction awareness expected by either
the UAS or any SIP intermediary as a result of this error message. the UA or any SIP intermediary as a result of this error message.
The new 424 (Bad Location Information) error code is registered with The new 424 (Bad Location Information) error code is registered with
IANA in Section 8 of this document. An initial set of IANA in Section 8 of this document. An initial set of
IANA-registered Geolocation-Error codes are in Section 4.3 of this IANA-registered Geolocation-Error codes are in Section 4.3 of this
document. document.
4.3 The Geolocation-Error Header Field 4.3 The Geolocation-Error Header Field
As discussed in Section 4.2, more granular error notifications, As discussed in Section 4.2, 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 UAC is to know what was wrong within the original request. if the UA is to know what was wrong within the original request.
The Geolocation-Error header field is used for this purpose. The Geolocation-Error header field is used for 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. Additional location-specific errors within a response. Additional
IANA-registered values must be defined in an RFC (this is the "RFC IANA-registered values must be defined in an RFC (this is the "RFC
Required" IANA policy defined in [RFC5226]). The Geolocation-Error Required" IANA policy defined in [RFC5226]). The Geolocation-Error
header field has the following ABNF [RFC5234]: header field has the following ABNF [RFC5234]:
Geolocation-Error = "Geolocation-Error" HCOLON Geolocation-Error = "Geolocation-Error" HCOLON
locationErrorValue locationErrorValue
*(COMMA locationErrorValue) *(COMMA locationErrorValue)
locationErrorValue = location-error-code *(SEMI locationErrorValue = location-error-arg SEMI
location-error-params) node-param SEMI inserter-param
location-error-arg = location-error-code
*(SEMI location-error-params)
location-error-code = 1*3DIGIT location-error-code = 1*3DIGIT
location-error-params = location-error-node-id location-error-params = location-error-code-text
/ location-error-host-id
/ location-error-code-text
/ generic-param ; from RFC3261 / generic-param ; from RFC3261
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261
node-param = location-error-node-id
location-error-node-id = "node" EQUAL location-error-node-id = "node" EQUAL
DQOUTE hostport DQOUTE ; from RFC3261 DQOUTE hostport DQOUTE ; from RFC3261
inserter-param = location-error-host-id
location-error-host-id = "inserter" EQUAL location-error-host-id = "inserter" EQUAL
DQOUTE hostport DQOUTE ; from RFC3261 DQOUTE hostport DQOUTE ; from RFC3261
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261
The Geolocation-Error header field MUST contain at least one The Geolocation-Error header field MUST contain at least one
locationErrorValue to indicate what was wrong with the locationValue locationErrorValue to indicate what was wrong with the locationValue
in the corresponding request the Location Recipient determined was in the corresponding request the Location Recipient determined was
bad. Each locationErrorValue contains a 3-digit error code bad. Each locationErrorValue contains a 3-digit error code
indicating what was wrong with the location in the request. Each indicating what was wrong with the location in the request. Each
error type has a corresponding quoted error text string that is error type has a corresponding quoted error text string that is
human understandable. human understandable. This text string is OPTIONAL, but RECOMMENDED
for easy understanding.
Each locationErrorValue contains the Location Recipient identifier Each locationErrorValue contains the Location Recipient identifier
(the "node=" parameter) which experienced the location error, as (the "node=" parameter) which experienced the location error, as
well as an identifier of which SIP entity (the "inserter=" well as an identifier of which SIP entity (the "inserter="
parameter) the Location Recipient is told (in the locationValue) parameter) the Location Recipient is told (in the locationValue)
added this problematic locationValue to the request. The "node=" added this problematic locationValue to the request. The "node="
and "inserter=" are the domain identifier of a SIP entity, with the and "inserter=" are the domain identifier of a SIP entity, with the
ability to have the same host communicate on different ports - and ability to have the same host communicate on different ports - and
have port specific identification. This is the same information that have port specific identification. This is the same information that
would be entered in the "sent-by" parameter of the Via header field would be entered in the "sent-by" parameter of the Via header field
skipping to change at page 12, line 13 skipping to change at page 14, line 4
added this problematic locationValue to the request. The "node=" added this problematic locationValue to the request. The "node="
and "inserter=" are the domain identifier of a SIP entity, with the and "inserter=" are the domain identifier of a SIP entity, with the
ability to have the same host communicate on different ports - and ability to have the same host communicate on different ports - and
have port specific identification. This is the same information that have port specific identification. This is the same information that
would be entered in the "sent-by" parameter of the Via header field would be entered in the "sent-by" parameter of the Via header field
for that entity [RFC3261]. As stated in section 18 of RFC 3261, for that entity [RFC3261]. As stated in section 18 of RFC 3261,
the usage of FQDN is RECOMMENDED. Here are examples of both the usage of FQDN is RECOMMENDED. Here are examples of both
locationErrorValue parameters, locationErrorValue parameters,
node="bob.example.com" node="bob.example.com"
inserter="alice.example.com" inserter="alice.example.com"
Both the "node=" and "inserter=" parameters MUST be present in all Both the "node=" and "inserter=" parameters MUST be present in all
locationErrorValues in a response, unless the locationValue of the locationErrorValues in a response, unless the locationValue of the
request did not include the "inserted-by=" parameter (which is a request did not include the "inserted-by=" parameter (which is a
violation of this document). The "inserter=" parameter value is violation of this document). The "inserter=" parameter value is
copied from the "inserted-by=" parameter within the locationValue of copied from the "inserted-by=" parameter within the locationValue of
the request. the request. This is required because a Location Recipient that
experienced a problem with the location included in a request needs
This is required because a Location Recipient that experienced a to tell the specific SIP entity which added the locationValue in
problem with the location included in a request needs to tell the error into the original request. Since more than one SIP entity can
specific SIP entity which added the locationValue in error into the insert location into a request in transit, all other SIP elements
original request. Since more than one SIP entity can insert may be confused by receiving this error header field, were it to
location into a request in transit, all other SIP elements may be remain generic to all entities in the response path. This
confused by receiving this error header field, were it to remain requirement means that the header field identifies the Location
generic to all entities in the response path. This requirement Inserter who inserted the problematic locationValue, so that all
means that the header field identifies the Location Inserter who other SIP entities that read the header field know to ignore it.
inserted the problematic locationValue, so that all other SIP This is of particular use if the original UAC did not include a
entities that read the header field know to ignore it. This is of locationValue in the original SIP request, but a SIP server along
particular use if the original UAC did not include a locationValue the path did insert a locationValue. The locationErrorValue would
in the original SIP request, but a SIP server along the path did be interpreted by each SIP entity along the original path upstream
insert a locationValue. The locationErrorValue would be interpreted and be processed by both the server that included the invalid
by each SIP entity along the original path upstream and be processed locationValue and the UAC that did not, resulting in confusion at
by both the server that included the invalid locationValue and the the UAC.
UAC that did not, resulting in confusion at the UAC.
A worse case is when both the original UAC and a SIP server along A worse case is when both the original UAC and a SIP server along
the path included a locationValue, but there was something the path included a locationValue, but there was something
wrong with only one of the locationValues. Without an wrong with only one of the locationValues. Without an
identification of the specific locationValue in error, both entities identification of the specific locationValue in error, both entities
would react, and one would react incorrectly. would react, and one would react incorrectly.
When more than one locationErrorValue is present in a When more than one locationErrorValue is present in a
Geolocation-Error header field, they are separated by commas. Geolocation-Error header field, they are separated by commas.
skipping to change at page 14, line 7 skipping to change at page 15, line 48
Figure 3. Basic Transaction with 424 and Geolocation-Error Header Figure 3. Basic Transaction with 424 and Geolocation-Error Header
Field Field
The following subsections provide an initial list of location The following subsections provide an initial list of location
based errors for any SIP non-100 response, including the new 424 based errors for any SIP non-100 response, including the new 424
(Bad Location Information) response. These error codes are divided (Bad Location Information) response. These error codes are divided
into 5 categories, based on how the response receiver should react into 5 categories, based on how the response receiver should react
to these errors. to these errors.
o 1XX "Cannot Process Location" We start with a general purpose location error, meaning we are not
being specific about what is wrong with the location provided, but
it has been determined to be bad.
o 2XX "Retry Location Later with same data" o 1XX "Cannot Process Location"
o 3XX "Retry Location Later with updated device location" We next have an error that indicates there is probably nothing wrong
with the location information provided, but the receiver cannot
process it at this time. A Retry-After header value will indicate
how long to wait until sending location again to this Location
Recipient and expect it to be processed.
o 4XX "Permission To Reveal Location Information to a Third Party" o 2XX "Retry Location Later with same data"
o 5XX "Location Information Denial" We next have an indication that something was wrong with the
location information supplied in the SIP request, and something on
the sender's side needs to be done to correct the bad information.
A Retry-After header value will indicate when to resend the location
information.
o 3XX "Retry Location Later with updated device location"
We next have a permission flag contained with this SIP request
indicating an LR need permission to reveal this information to a 3rd
party (retransmission-allowed flag) or permission to view the
contained location to properly process the SIP request
(routing-allowed flag). We will define two individual errors here to
facilitate informing the "inserter=" which flag needs to be adjusted
if they want this SIP request processed further by this SIP entity.
o 4XX "Permission To Use Location Information"
Finally, we create a general location denial error, for times when a
dereference was denied or timed-out.
o 5XX "Location Information Denial"
All 5 of the above error codes MUST be implemented to comply with All 5 of the above error codes MUST be implemented to comply with
this specification. Each of these actionable errors is given a 3 this specification. Each of these actionable errors is given a 3
digit error code category, meaning any future 1XX, 2XX, 3XX, 4XX, digit error code category, meaning any future 1XX, 2XX, 3XX, 4XX,
and 5XX error codes defined will have the same action expected by and 5XX error codes defined will have the same action expected by
X00 categories, although the future error code may provide more X00 categories, although the future error code may provide more
granular information. If another action is expected to occur with a granular information. If another action is expected to occur with a
newly defined error code, it MUST outside the 100-599 range. newly defined error code, it MUST outside the 100-599 range.
4.3.1 Location Error: 100 "Cannot Process Location" 4.3.1 Location Error: 100 "Cannot Process Location"
skipping to change at page 15, line 28 skipping to change at page 17, line 45
URI is dereferenced. URI is dereferenced.
Action(s) to be taken by Geolocation-Error receiver for a 2XX: Action(s) to be taken by Geolocation-Error receiver for a 2XX:
Reactions to a 2XX location error are to try again after some Reactions to a 2XX location error are to try again after some
period of time has elapsed. The "inserter=" has not identified period of time has elapsed. The "inserter=" has not identified
problems with the location provided in the original request, problems with the location provided in the original request,
so there is no need to update this location unless the so there is no need to update this location unless the
requestor moves. A Retry-After header field MUST be present in requestor moves. A Retry-After header field MUST be present in
the 424 response indicating after how long the LR thinks it the 424 response indicating after how long the LR thinks it
can process the location, the error recipient MUST obey this can process the location, the error recipient MUST obey this
instruction. instruction. A Retry-After header value of '0' indicates try
again immediately.
Implementations SHOULD choose to react by queuing another message Implementations SHOULD choose to react by queuing another message
with the same location information, unless the "inserter=" entity with the same location information, unless the "inserter=" entity
knows it has changed locations. knows it has changed locations.
Implementations MAY inform the user of this error. The text string Implementations MAY inform the user of this error. The text string
of "Retry Location Later same data" is RECOMMENDED, but not of "Retry Location Later same data" is RECOMMENDED, but not
mandatory for this error. Implementations MAY use another text mandatory for this error. Implementations MAY use another text
string to inform the user that location was not received by the UAS string to inform the user that location was not received by the UA
(i.e., the called party). (i.e., the called party).
An example 200 location error is: An example 200 location error is:
Geolocation-Error: 200; code="Retry Location Later same data"; Geolocation-Error: 200; code="Retry Location Later same data";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers all 2XX location errors. The same basic This category covers all 2XX location errors. The same basic
reaction is expected when a location "inserter=" entity receives any reaction is expected when a location "inserter=" entity receives any
skipping to change at page 16, line 28 skipping to change at page 18, line 46
necessary. necessary.
It is of particular importance is the emergency calling case, It is of particular importance is the emergency calling case,
described here [ID-PHONE]. The presence document has a <presence> described here [ID-PHONE]. The presence document has a <presence>
element containing an "entity=" attribute identifying who the element containing an "entity=" attribute identifying who the
presence document is about. The PIDF-LO is a presence document. presence document is about. The PIDF-LO is a presence document.
[RFC3693] allows unlinkable pseudonyms to be in the "entity=" [RFC3693] allows unlinkable pseudonyms to be in the "entity="
attribute. This is problematic for some (all?) source location based attribute. This is problematic for some (all?) source location based
call routing situations. call routing situations.
The node= routing intermediary makes this locationErrorValue a 201 The "node=" routing intermediary makes this locationErrorValue a 201
to resolve this problem. In the 424 response, the Retry-After header to resolve this problem. In the 424 response, the Retry-After header
value of '0' is REQUIRED, indicating the new request be sent value of '0' is REQUIRED, indicating the new request be sent
immediately, but with a target identification resolved in the immediately, but with a Target identification resolved in the
PIDF-LO and SIP request. In presence, the entity= attribute is PIDF-LO and SIP request. In presence, the "entity=" attribute is
typically the URI of the presentity, meaning something like the typically the URI of the presentity, meaning something like the
Contact address of the UAC here. Contact address of the UAC here.
If there is no Retry-After header value, the default is to resend If there is no Retry-After header value, the default is to resend
the SIP request immediately with the corrected entity= attribute the SIP request immediately with the corrected "entity=" attribute
(i.e., emulating a Retry-After: 0 header value). (i.e., emulating a Retry-After: 0 header value).
Action(s) to be taken by Geolocation-Error receiver for a 201: Action(s) to be taken by Geolocation-Error receiver for a 201:
201 location error indicate the "inserter=" did not properly 201 location error indicate the "inserter=" did not properly
identify the Target of this presence document. The identify the Target of this presence document. The
Retry-After has been received - or is assumed to be 0 - Retry-After has been received - or is assumed to be 0 -
meaning the new SIP request is to be sent immediately. meaning the new SIP request is to be sent immediately.
4.3.3 Location Error: 300 "Retry Location Later with device updated 4.3.3 Location Error: 300 "Retry Location Later with device updated
skipping to change at page 17, line 15 skipping to change at page 19, line 32
Action(s) to be taken by Geolocation-Error receiver for a 3XX: Action(s) to be taken by Geolocation-Error receiver for a 3XX:
3XX location errors indicate the "inserter=" SIP entity needs 3XX location errors indicate the "inserter=" SIP entity needs
to refresh its location, or make the location information to refresh its location, or make the location information
supplied more complete, without notifying the user of this supplied more complete, without notifying the user of this
error. 3XX errors may be resolved without user intervention. error. 3XX errors may be resolved without user intervention.
This document gives no guidance how this is accomplished, given the This document gives no guidance how this is accomplished, given the
number of ways a UAC can learn its location, or a SIP intermediary number of ways a UAC can learn its location, or a SIP intermediary
can Sight a UAC, as defined in [RFC3693]. can determine this UAC's location (with or without the help of a
Location Server.
This 300 location error currently does not indicate what exactly was This 300 location error currently does not indicate what exactly was
wrong with the location supplied, according to the Location wrong with the location supplied, according to the Location
Recipient. That is left for a future effort. Recipient. That is left for a future effort.
Implementations MAY choose whether or not to inform the user of this Implementations MAY choose whether or not to inform the user of this
error. The text string of "Retry Location Later with device updated error. The text string of "Retry Location Later with device updated
location" is RECOMMENDED, but not mandatory for usage in this location" is RECOMMENDED, but not mandatory for usage in this
error. Implementation MAY use another text string to inform the error. Implementation MAY use another text string to inform the
user that location was not received by the UAS (i.e., the called user that location was not received by the UA (i.e., the called
party). party).
A 3XX location error would be used where the Location Recipient A 3XX location error would be used where the Location Recipient
cannot find or cannot parse the location supplied. 3XX location cannot find or cannot parse the location supplied. 3XX location
errors should cause a requestor to retry with refreshed location errors should cause a requestor to retry with refreshed location
information, which might be sufficient to fix the problem. Also, a information, which might be sufficient to fix the problem. Also, a
3XX location error would be used when a Location Recipient was 3XX location error would be used when a Location Recipient was
expecting to find location in a SIP request, but did not find it - expecting to find location in a SIP request, but did not find it -
perhaps an emergency request was made that did not contain location. perhaps an emergency request was made that did not contain location.
The retry in this case would be in the form of an UPDATE Method The retry in this case would be in the form of an UPDATE Method
skipping to change at page 17, line 52 skipping to change at page 20, line 19
Geolocation-Error: 300; code="Retry Location Later with device Geolocation-Error: 300; code="Retry Location Later with device
updated location"; updated location";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers all 3XX location errors. The same basic This category covers all 3XX location errors. The same basic
reaction is expected when a location "inserter=" entity receives any reaction is expected when a location "inserter=" entity receives any
3XX location error. 3XX location error.
4.3.4 Location Error: 400 "Permission to Reveal Location Information to 4.3.4 Location Error: 400 "Permission To Use Location Information"
a Third Party"
The location error 400 "Permission to Reveal Location Information to The location error 400 "Permission To Use Location Information"
a Third Party" indicates to a Geolocation-Error recipient that they indicates to a Geolocation-Error recipient that they sent a
sent a particular SIP Request including location in that request, particular SIP Request including location in that request, without
without giving permission in the request for an intermediary SIP giving permission in the request for an intermediary SIP entity to
entity to look at that location information (i.e., the look at that location information (i.e., the
<retransmission-allowed> was set to "no" in the PIDF-LO for B2BUAs, <retransmission-allowed> was set to "no" in the PIDF-LO for B2BUAs,
or "routing-allowed=no" as a Geolocation header field parameter for or "routing-allowed=no" as a Geolocation header field parameter for
proxy servers) to route the request toward the intended recipient proxy servers) to route the request toward the intended recipient
(i.e., the UAS, or the called party). (i.e., the called party).
Action(s) to be taken by Geolocation-Error receiver for a 4XX: All 4XX level location errors are asking for permission from the
"inserter=" to set a flag differently in order to accomplish
something with the location.
4XX location errors indicate to the UAC (i.e., the calling An example 400 location error is:
party) that they need to grant permission to a SIP
intermediary server to look at the supplied location to Geolocation-Error: 400; code="Permission To Use Location
Information";
node="bob.example.com";
inserter="alice.example.com";
Because there are two completely separate flags known at this time,
one in the PIDF-LO (retransmission-allowed) and one as a Geolocation
header parameter (routing-allowed), two separate Locations Errors
are created to give the "inserter=" entity the specific choice to
reset the right flag.
4.3.4.1 Location Error: 401 "Permission To Retransmit Location
Information to a Third Party"
This location error is specific to having the PIDF-LO
<retransmission-allowed> element set to "=no". This location error
is asking for permission of the "inserter=" entity to resend the SIP
request with a PIDF-LO <retransmission-allowed> element set to
"=yes".
Action(s) to be taken by Geolocation-Error receiver for a 401:
The 401 location error indicates to the location "inserter="
that the LR (i.e., a UA or SIP intermediary server) needs to
have permission to transmit the supplied location information
to a third party. This indication MUST require human user
intervention, acting as the Ruleholder of the policy on
whether or not location is to be revealed.
The user of the location "inserter=" device can choose to grant
permission to the LR to allow this request to be sent on to another
entity, or the user can deny permission. It is the user's choice as
Ruleholder.
Implementations MUST provide the user, as Ruleholder, a clear
indication that permission to consume their location is sought by an
entity that is not the entity that the user is calling. The text
string of " Permission To Retransmit Location Information to a Third
Party " is RECOMMENDED, but not mandatory for this error.
Implementations MAY use another text string to inform the user that
location is being sought by an LR.
This document gives no guidance how the UA can seek permission from
the user, given the number of ways a UA can accomplish this (i.e.,
audio prompt or toggle or keystroke on the UA).
An example 401 location error is:
Geolocation-Error: 401; code="Permission To Retransmit Location
Information to a Third Party";
node="bob.example.com";
inserter="alice.example.com";
4.3.4.2 Location Error: 402 "Permission to Route based on Location
Information"
This location error is specific to having the locationValue header
parameter <routing-allowed> set to "=no". This location error is
asking for permission of the "inserter=" entity to resend the SIP
request with a locationValue header parameter <routing-allowed> set
to "=yes".
Action(s) to be taken by Geolocation-Error receiver for a 402:
The 402 location error indicates to the location "inserter="
that the LR (i.e., SIP intermediary server) needs to have
permission in to look at and use the supplied location to
complete the message routing. This indication MUST require complete the message routing. This indication MUST require
human user intervention, acting as the ruleholder of the human user intervention, acting as the Ruleholder of the
policy on whether or not location is to be revealed. policy on whether or not location is to be revealed.
The user of the location "inserter=" device can choose to grant The user of the location "inserter=" can choose to grant permission
permission to this SIP intermediary server to allow this request to to this SIP intermediary server to allow this request to be routed,
be routed, or the user can deny permission. It is the user's choice or the user can deny permission. It is the user's choice as
as ruleholder. Ruleholder.
Implementations MUST provide the user, as ruleholder, a clear Implementations MUST provide the user, as Ruleholder, a clear
indication that permission to consume their location is sought by an indication that permission to consume their location is sought by an
entity that is not the entity that the user is calling. The text entity that is not the entity that the user is calling. The text
string of "Permission To Reveal Location Information to a Third string of "Permission to Route based on Location Information" is
Party" is RECOMMENDED, but not mandatory for usage in this error. RECOMMENDED, but not mandatory for usage in this error.
Implementations MAY use another text string to inform the user that Implementations MAY use another text string to inform the user that
location is being sought by an intermediary (i.e., not the called location is being sought by an intermediary (i.e., not the called
party). party).
This document gives no guidance how the UAC can seek permission from This document gives no guidance how the UA can seek permission from
the user, given the number of ways a UAC can accomplish this (i.e., the user, given the number of ways a UA can accomplish this (i.e.,
audio prompt or toggle or keystroke on a UA). audio prompt or toggle or keystroke on the UA).
This 400 location error indicates exactly which SIP server indicates This 402 location error indicates which specific SIP server needs
that it needs the location by the "node=" FQDN address supplied, the location by the "node=" FQDN address supplied, perhaps telling
perhaps telling the user (via audio or video indication) which SIP the user (via audio or video indication) which SIP entity wants its
entity wants this location. Perhaps the user can know in some location learned for routing purposes. Perhaps the user can know in
circumstances whether this is an appropriate "node=" (domain). This some circumstances whether this is an appropriate "node=" (domain).
latter feature is not described in this document. This latter feature is not described in this document (just
mentioned here as a possibility).
An example 400 location error is: An example 402 location error is:
Geolocation-Error: 400; code="Permission to Reveal Location Geolocation-Error: 402; code="Permission to Route based on
Information to a Third Party"; Location Information";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers all 4XX location errors. The same resolution
is expected to be afforded to the UAC user, as ruleholder, to any
4XX location error.
4.3.5 Location Error: 500 "Location Information Denial" 4.3.5 Location Error: 500 "Location Information Denial"
The location error 500 "Location Information Denial" indicates to a The location error 500 "Location Information Denial" indicates to a
Geolocation-Error recipient that what they supplied in a request, as Geolocation-Error recipient that what they supplied in a request, as
far as location is concerned, has been denied at this time. far as location is concerned, has been denied at this time.
This only has to do with the location that the location "inserter=" This only has to do with the location that the location "inserter="
added to the request, and not about the overall request that was added to the request, and not about the overall request that was
sent. If this were applied to the SIP request itself, this would sent. If this were applied to the SIP request itself, this would
equate to a 6XX Global error. equate to a 6XX Global error.
skipping to change at page 19, line 44 skipping to change at page 23, line 26
denied, or even had an error, unless the response was a 424. denied, or even had an error, unless the response was a 424.
Otherwise, this only has to do with the location part of the Otherwise, this only has to do with the location part of the
request. request.
The difference between a 1XX and a 5XX location error is simple. A The difference between a 1XX and a 5XX location error is simple. A
1XX location error is appropriate when a Location Recipient either 1XX location error is appropriate when a Location Recipient either
does not know or cannot tell the "inserter=" entity what was wrong does not know or cannot tell the "inserter=" entity what was wrong
with the location supplied in a SIP request. A 5XX location error with the location supplied in a SIP request. A 5XX location error
is appropriate when the Location Recipient was purposely and is appropriate when the Location Recipient was purposely and
actively prevented from retrieving the location information. This actively prevented from retrieving the location information. This
could occur in a UAS or SIP server. could occur in a UA or SIP server.
If implementations choose to inform the UAC user of this error, the If implementations choose to inform the UA user of this error, the
text string of "Location Information Denial" is RECOMMENDED, but not text string of "Location Information Denial" is RECOMMENDED, but not
mandatory for usage in this error. Implementations MAY use another mandatory for usage in this error. Implementations MAY use another
text string. text string.
An example of this location error is here: An example of this location error is here:
Geolocation-Error: 500; code="Location Information Denial"; Geolocation-Error: 500; code="Location Information Denial";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers 5XX location errors. The same basic reaction This category covers 5XX location errors. The same basic reaction
is expected when a location "inserter=" entity receives any 5XX is expected when a location "inserter=" entity receives any 5XX
location error. location error.
4.3.6 Which Scenario Matches Which Error Code? 4.3.6 Which Scenario Matches Which Error Code?
The following scenario/error code mapping MUST be used for The following scenario/error code mapping MUST be used for
consistency, consistency,
- Scheme (sip:, or sips:, or pres:, etc.) of the location URI - Scheme (sip:, or sips:, or pres:, etc.) of the location URI
isn't supported - (100) is not supported - (100)
- Format (geo or civic) isn't supported - (100) - Format (geo or civic) is not supported - (100)
- Found where location should be, but do not understand what is - Found where location information should be in the request, but do
there -(300) not understand what is at that part of the request -(300)
- Cannot find LS in location URI (no access or no path) - (100) or - Cannot find LS in location URI (no access or no path) - (100) or
denied access - (500)) denied access - (500))
- Dereference failed (timeout) - (200) - Dereference failed (timeout) - (200)
- Insufficient location info supplied - (300) - Insufficient location info supplied - (300)
4.4 The 'geolocation' Option Tag 4.4 The 'geolocation' Option Tag
This document creates and IANA registers one new option tag: This document creates and IANA registers one new option tag:
"geolocation". This option tag is to be used, as defined in "geolocation". This option tag is to be used, as defined in
[RFC3261], in the Require, Supported and Unsupported header fields. [RFC3261], in the Require, Supported and Unsupported header fields.
4.5 Using sip/sips/pres as a Dereference Scheme 4.5 Using sip/sips/pres as a Dereference Scheme
skipping to change at page 20, line 36 skipping to change at page 24, line 16
- Insufficient location info supplied - (300) - Insufficient location info supplied - (300)
4.4 The 'geolocation' Option Tag 4.4 The 'geolocation' Option Tag
This document creates and IANA registers one new option tag: This document creates and IANA registers one new option tag:
"geolocation". This option tag is to be used, as defined in "geolocation". This option tag is to be used, as defined in
[RFC3261], in the Require, Supported and Unsupported header fields. [RFC3261], in the Require, Supported and Unsupported header fields.
4.5 Using sip/sips/pres as a Dereference Scheme 4.5 Using sip/sips/pres as a Dereference Scheme
If an LbyR URI is included in a SIP request, it MUST be a SIP-, If a location URI is included in a SIP request, it MUST be a SIP-,
SIPS- or PRES-URI. When PRES: is used, if the resulting resolution, SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if
as defined in [RFC3856], resolves to a SIP: or SIPS: URI, this the resulting resolution resolves to a SIP: or SIPS: URI, this
section applies. section applies.
This document IANA registers 3 mandatory-to-implement URI schemes This document IANA registers 3 mandatory-to-implement URI schemes
for LbyR: for a location URI:
o SIP: o SIP:
o SIPS: o SIPS:
o PRES: o PRES:
These 3 are registered with IANA in Section 9.6. These 3 are registered with IANA in Section 9.6.
These schemes MUST be implemented according to this document. These schemes MUST be implemented according to this document.
absoluteURI is not mandatory-to-implement. absoluteURI is not mandatory-to-implement, but allowed.
Dereferencing a Target's location using SIP- or SIPS-URI is Dereferencing a Target's location using SIP- or SIPS-URI is
accomplished by treating the URI as a PRES-URI and generating a accomplished by treating the URI as a PRES-URI and generating a
SUBSCRIBE request to a presence server as defined in [RFC3856] SUBSCRIBE request to a presence server as defined in [RFC3856]
using the 'presence' event package. The resulting NOTIFY MUST using the 'presence' event package. The resulting NOTIFY MUST
contain a PIDF-LO. See Figure 4 for a basic message flow for a contain a PIDF-LO. See Figure 4 for a basic message flow for a
dereference. The NOTIFY contains Alice's PIDF-LO in Figure 4. dereference. The NOTIFY contains Alice's PIDF-LO in Figure 4.
When used in this manner, SIP is a Using Protocol as defined in When used in this manner, SIP is a Using Protocol as defined in
[RFC3693] and elements receiving location MUST honor the [RFC3693] and elements receiving location MUST honor the
'usage-element' rules as defined in this specification. 'usage-element' rules as defined in this specification.
Alice Location Server Bob Alice Location Server Bob
| | | |
| INVITE w/ Location URI | | INVITE w/ Location URI |
|-------------------------------------------------------->| |-------------------------------------------------------->|
| | | | | |
| 200 (OK) |
|<--------------------------------------------------------|
| | |
| | SUBSCRIBE to location URI | | | SUBSCRIBE to location URI |
| |<-----------------------------| | |<-----------------------------|
| | 200 (OK) | | | 200 (OK) |
| |----------------------------->| | |----------------------------->|
| | | | | |
| | NOTIFY w/ PIDF-LO | | | NOTIFY w/ PIDF-LO |
| |----------------------------->| | |----------------------------->|
| | 200 (OK) | | | 200 (OK) |
| |<-----------------------------| | |<-----------------------------|
| | | | | |
| 200 (OK) |
|<--------------------------------------------------------|
| | |
Figure 4. Location-by-Reference and Dereferencing Figure 4. Location-by-Reference and Dereferencing
In Figure 4, Alice sends Bob her location in a location URI. Bob In Figure 4, Alice sends Bob her location as a location URI. Bob
receives this location URI in the INVITE and generates a new receives this location URI in the INVITE and generates a new
transaction (SUBSCRIBE) to retrieve Alice's PIDF-LO. If accepted, transaction (SUBSCRIBE) to retrieve Alice's PIDF-LO. If accepted,
the PIDF-LO will be returned in the NOTIFY request from the Location the PIDF-LO will be returned in the NOTIFY request from the Location
Server to Bob's UA. This is the first instance between Alice and Server to Bob's UA. This is the first instance between Alice and
Bob that Alice's location is in any message, therefore it is sent Bob that Alice's location is in any message.
only once, from the Location Server to Bob.
The SUBSCRIBE contains a geolocation option tag in either the The SUBSCRIBE contains a geolocation option tag in either the
Supported or Require header field (depending on what strength of Supported or Require header field (depending on what strength of
support the UAC requires). The NOTIFY MUST match the subscribing support the UA requires). The NOTIFY MUST match the subscribing
UAC's option-tag strength for geolocation. UA's option-tag strength for geolocation.
A dereference of an LbyR URI using SUBSCRIBE is not violating a A dereference of a location URI using SUBSCRIBE is not violating a
PIDF-LO 'retransmission-allowed' element value set to 'no', as the PIDF-LO 'retransmission-allowed' element value set to 'no', as the
NOTIFY is the only message in this multi-message set of transactions NOTIFY is the only message in this multi-message set of transactions
that contains the Target's location, with the location recipient that contains the Target's location, with the location recipient
being the only SIP element to receive this PIDF-LO. This is the being the only SIP element to receive this PIDF-LO. This is the
purpose of this extension to SIP - to convey location to a specific purpose of this extension to SIP - to convey location to a specific
destination. destination.
Certain nuances about this subscription exist that will not be
covered in this document. Instead these additional functions will be
described in the following document: [ID-GEO-FILTERS]. Here we
introduce the general concept; the "Filters" document has the
details. These two are consistent with each other.
5. Geolocation Examples 5. Geolocation Examples
This section contains are two examples of messages providing This section contains are two examples of messages providing
location. One shows LbyV with coordinates, the other shows location. One shows LbyV with coordinates, the other shows
dereferencable location URI. The example for (Coordinate format) is dereferencable location URI. The example for (Coordinate format) is
taken from [RFC3825]. A Civic-format example of the same position on taken from [RFC3825]. A Civic-format example of the same position on
the earth as is in the coordinate format example is in appendix B, the earth as is in the coordinate format example is in appendix B,
which is taken from [RFC4776]. The differences between the two which is taken from [RFC4776]. The differences between the two
formats appear within the <gp:location-info> in the examples. Other formats appear within the <gp:location-info> in the examples. Other
than this portion of each PIDF-LO, the rest is the same for both than this portion of each PIDF-LO, the rest is the same for both
location formats. location formats.
The key to the provided samples is in the Geolocation header field, The key to the provided samples is in the Geolocation header field,
which has a different type of URI, based on the different means of which has a different type of URI, based on the different means of
location conveyance. Section 5.1 shows a "cid:" URI, indicating location conveyance. Section 5.1 shows a "cid:" URI, indicating
this SIP request contains an LbyV message body - which is in the this SIP request contains an LbyV message body - which is in the
form of a PIDF-LO. Section 5.2 shows an LbyR URI indicating form of a PIDF-LO. Section 5.2 shows an location URI indicating
location is to be acquired via an indirection dereference mechanism, location is to be acquired via an indirection dereference mechanism,
which is determined by the scheme of URI supplied. which is determined by the scheme of URI supplied.
5.1 Location-by-value (Coordinate Format) 5.1 Location-by-value (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>
;inserted-by="alice@atlanta.example.com" ;inserted-by="alice@atlanta.example.com"
;routing-allowed=no ,routing-allowed=no
Supported: geolocation 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 23, line 16 skipping to change at page 26, line 51
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com> Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
<tuple id="target123"> <tuple id="target123">
<status> <status>
<timestamp>2009-07-13T09:00:00Z</timestamp>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:location> <gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>33.001111 -96.68142</gml:pos> <gml:pos>33.001111 -96.68142</gml:pos>
</gml:Point> </gml:Point>
</gml:location> </gml:location>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2009-07-29T18:00:00Z</gp:retention- <gp:retention-expiry>2010-02-12T06:00:00Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
<gp:method>802.11</gp:method> <gp:method>802.11</gp:method>
a </gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2010-02-12T04:00:00Z</timestamp>
</tuple> </tuple>
</presence> </presence>
--boundary1-- --boundary1--
The Geolocation header field from the above INVITE: The Geolocation header field from the above INVITE:
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <cid:target123@atlanta.example.com>
... indicates the content-ID location [RFC2392] within the multipart ... indicates the content-ID location [RFC2392] within the multipart
message body of where location information is, with SDP being the message body of where location information is, with SDP being the
other message body part. The "cid:" eases message body parsing. other message body part. The "cid:" eases message body parsing.
If the Geolocation header field did not contain a "cid:" scheme, for If the Geolocation header field did not contain a "cid:" scheme, for
example, like this location URI: example, like this location URI:
Geolocation: <sips:server5.atlanta.example.com/target123> Geolocation: <sips:server5.atlanta.example.com/target123>
... the existence of a non-"cid:" scheme indicates this is a ... the existence of a non-"cid:" scheme indicates this is a
location URI, to be dereferenced to learn the target's location. Any location URI, to be dereferenced to learn the Target's location. Any
node wanting to know where user "target123" is would subscribe to node wanting to know where user "target123" is would subscribe to
server5 to dereference the sips-URI (see Figure 4 for this message server5 to dereference the sips-URI (see Figure 4 for this message
flow, and Section 5.2 for this decoded example). The returning flow, and Section 5.2 for this decoded example). The returning
NOTIFY would contain Alice's location in a PIDF-LO, as if it were NOTIFY would contain Alice's location in a PIDF-LO, as if it were
included in a message body (part) of the original INVITE. included in a message body (part) of the original INVITE.
5.2 Location-by-reference 5.2 Location-by-reference
Below is an INVITE request with a location URI that is not a "cid:" Below is an INVITE request with a location URI that is not a "cid:"
- instead of an LbyV PIDF-LO message body part as shown in Section - instead of an LbyV PIDF-LO message body part as shown in Section
skipping to change at page 24, line 29 skipping to change at page 28, line 14
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK74bf9 ;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: <sips:3sdefrhy2jj7@lis.atlanta.example.com> Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>
;inserted-by="bigbox3.atlanta.example.com" ;inserted-by="bigbox3.atlanta.example.com"
;routing-allowed=no ,routing-allowed=no
Supported: geolocation Supported: geolocation
Accept: application/sdp, application/pidf+xml Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
(...SDP goes here as the only message body) (...SDP goes here as the only message body)
A Location Recipient would need to dereference the sips-URI in the A Location Recipient would need to dereference the sips-URI in the
Geolocation header field to retrieve Alice's location. If the Geolocation header field to retrieve Alice's location. If the
atlanta.example.com domain chooses to implement location conveyance atlanta.example.com domain chooses to implement location conveyance
skipping to change at page 25, line 33 skipping to change at page 29, line 18
A UAC conveying location MUST include a locationValue in a A UAC conveying location MUST include a locationValue in a
Geolocation header (see section 4.1) with either an LbyV indication Geolocation header (see section 4.1) with either an LbyV indication
(a cid-URL), or a dereferencable location URI. Requests containing (a cid-URL), or a dereferencable location URI. Requests containing
an LbyV message body sent MUST also contain a Geolocation header an LbyV message body sent MUST also contain a Geolocation header
field. The UAC supporting this extension MUST include a Supported field. The UAC supporting this extension MUST include a Supported
header with the 'geolocation' option tag. header with the 'geolocation' option tag.
More than one location format (civic and coordinate) can be included More than one location format (civic and coordinate) can be included
in the same message body part, but all location parts of the same in the same message body part, but all location parts of the same
PIDF-LO MUST point at the same position on the earth, identifying PIDF-LO MUST point at the same position on the earth, identifying
the same target. The same location in multiple formats, for the same Target. The same location in multiple formats, for
example, a partial or complete geodetic and a partial or complete example, a partial or complete geodetic and a partial or complete
civic, allows the recipient to select the most preferred format for civic, allows the recipient to select the most preferred format for
its use. Additional complementary location information can be in its use. Additional complementary location information can be in
the second format as well. the second format as well.
Multiple PIDF-LOs are allowed in the same request, with each allowed Multiple PIDF-LOs are allowed in the same request, with each allowed
to point at separate positions - however, each PIDF-LO MUST identify to point at separate positions - however, each PIDF-LO MUST identify
a different Target (i.e., in the entity= attribute in the <presence> a different Target (i.e., in the "entity=" attribute in the
element of the presence document). Therefore, there will be no <presence> element of the presence document). Therefore, there will
confusion by a Location Recipient receiving more than one PIDF-LO be no confusion by a Location Recipient receiving more than one
(in a message body or when dereferenced, or a combination). A SIP PIDF-LO (in a message body or when dereferenced, or a combination).
request SHOULD include only one location per target in a single SIP A SIP request SHOULD include only one location per Target in a
request. More than one will likely lead to confusion by a Location single SIP request. More than one will likely lead to confusion by
Recipient because this extension does not provide guidance on what a a Location Recipient because this extension does not provide
recipient is to do with more than one location for the same target guidance on what a recipient is to do with more than one location
(which could point to different positions), nor does it give any for the same Target (which could point to different positions), nor
preference regarding which location is more or less reliable than does it give any preference regarding which location is more or less
another location in the same request. reliable than another location in the same request.
The presence of the 'geolocation' option tag in a Supported header The presence of the 'geolocation' option tag in a Supported header
field without a Geolocation header field in the same message informs field without a Geolocation header field in the same message informs
a SIP element receiving this request that the UAC understands this a SIP element receiving this request that the UAC understands this
extension, but it does not know or wish to convey its location at extension, but it does not know or wish to convey its location at
this time. Certain scenarios exist (location-based retargeting) in this time. Certain scenarios exist (location-based retargeting) in
which location is required in a SIP request in order to retarget the which location is required in a SIP request in order to retarget the
message properly. Indicating support with a geolocation option tag message properly. Indicating support with a geolocation option tag
affects how a UAS or SIP server processes such a request. For affects how a UAS or SIP server processes such a request. For
example, it ought to understand that erroring the request because example, it ought to understand that erroring the request because
skipping to change at page 26, line 50 skipping to change at page 30, line 34
The Location Server will likely challenge requests to dereference a The Location Server will likely challenge requests to dereference a
Target's location URI. The location URI SHOULD be treated as Target's location URI. The location URI SHOULD be treated as
equivalent to possession of the location information itself and thus equivalent to possession of the location information itself and thus
TLS SHOULD be used when transmitting any location URI hop-by-hop TLS SHOULD be used when transmitting any location URI hop-by-hop
along the path to the Location Recipient, for protection reasons. along the path to the Location Recipient, for protection reasons.
This is not to be confused with a 'possession model', in which This is not to be confused with a 'possession model', in which
possessing the location URI grants authorization to dereference the possessing the location URI grants authorization to dereference the
URI. Any entity dereferencing the location URI MUST pass whatever URI. Any entity dereferencing the location URI MUST pass whatever
authentication and authorization rules are on the LS to acquire this authentication and authorization rules are on the LS to acquire this
location. The Ruleholder from [RFC3693] is still very much in location. The Ruleholder from [RFC3693] is still very much in
control - for any entity possessing the LbyR. control - for any entity possessing the location URI.
If the Location Generator wishes to control whether any location If the Location Generator wishes to control whether any location
included in the SIP request or added along the signaling path of included in the SIP request or added along the signaling path of
this request can be viewed for routing decisions, the Location this request can be viewed for routing decisions, the Location
Generator adds a Geolocation header field value including the Generator adds a Geolocation header field value including the
"routing-allowed=no" parameter. This header field parameter "routing-allowed=no" parameter. This header field parameter
provides specific policy rules for each locationValue (if more than provides specific policy rules for each locationValue (if more than
one locationValue is inserted along the signaling path) within the one locationValue is inserted along the signaling path) within the
SIP request. A UAC SHOULD include the "routing-allowed" header SIP request. A UAC SHOULD include the "routing-allowed" header
field parameter, with or without a locationValue, to each SIP field parameter, with or without a locationValue, to each SIP
request supporting this specification to ensure the UAC's policy for request supporting this specification to ensure the UAC's policy for
intermediaries which might add a locationValue of the Target intermediaries which might add a locationValue of the Target
downstream. The default behavior for SIP servers is to consider downstream. The default behavior for SIP servers is to consider
this value to be present, with a value of "no". this value to be present, with a value of "=no". A "=no" value in
this parameter indicates there can be no routing decisions derived
from the UAC's location. UACs MUST be prepared to receive an error
indicating a SIP intermediary needs to have this parameter set
to"=yes" in order to properly routing this message. The UAC can
make a local policy choice as to whether it wishes to set the
parameter to "=yes", thus allowing each SIP entity along the message
path to use the UAC's location when making routing decisions. There
is no way to indicate that only a subset of SIP intermediaries have
permission, while other intermediaries do not.
There is no feedback mechanism to inform the Target if a SIP server There is no feedback mechanism to inform the Target if a SIP server
has included a locationValue downstream. If a UAC has already has included a locationValue downstream. If a UAC has already
conveyed location in the original request of a transaction, and conveyed location in the original request of a transaction, and
wants to update its location information (for whatever reason) after wants to update its location information (for whatever reason) after
the original request is sent, or after a dialog is created, this is the original request is sent, or after a dialog is created, this is
done by sending an UPDATE request [RFC3311]. The UPDATE will include done by sending an UPDATE request [RFC3311]. The UPDATE will include
a geolocation option tag and Geolocation header field with the new a geolocation option tag and Geolocation header field with the new
locationValue to the original destination UAS. locationValue to the original destination UAS.
A presence document includes identity information (in the "entity=" A presence document includes identity information (in the "entity="
attribute of the <presence> element), although the identity could be attribute of the <presence> element), although the identity could be
an unlinkable pseudonym [RFC3693]. Implementations of this an unlinkable pseudonym [RFC3693]. Implementations of this
extension SHOULD consider the appropriateness of including an extension SHOULD consider the appropriateness of including an
unlinkable pseudonym as the identity in the location information unlinkable pseudonym as the identity in the location information
where a real identity is not required. See the concerns raised in where a real identity is not required. See the concerns raised in
section 4.3.2 about unlinkable pseudonyms in relation to their section 4.3.2 about unlinkable pseudonyms in relation to their
potential problems with requests that need to route based on the potential problems with requests that need to route based on the
location contained in the message. location contained in the message.
When using LbyR, the location URI MUST NOT contain any user A location URI MUST NOT contain any user identifying information.
identifying information. For example, use something unidentifiable For example, it is much more secure to use something unidentifiable
like like
3fg5T5yqWowhGLn54wg4NgHlkDsFn@example.atlanta.com 3fg5T5yqWowhGLn54wg4NgHlkDsFn@example.atlanta.com
rather than rather than something identifiable like
aliceishere@example.atlanta.com). aliceishere@example.atlanta.com.
Use of self-signed certificates is inappropriate for use in Use of self-signed certificates is inappropriate for use in
protecting a PIDF, as the sender does not have a secure identity of protecting a PIDF, as the sender does not have a secure identity of
the recipient. the recipient.
Although this is discussed in more detail in later in section 6.2, Although this is discussed in more detail in later in section 6.2,
SIP entities MUST NOT bypass rules and behaviors conveyed in a SIP entities MUST NOT bypass rules and behaviors conveyed in a
PIDF-LO. UACs SHOULD take care when setting their PIDF-LO. UACs SHOULD take care when setting their
<retransmission-allowed> flag to "yes". When Alice tells Bob her <retransmission-allowed> flag to "yes". When Alice tells Bob her
location with this flag set to "yes", Bob is free to tell Carol location with this flag set to "yes", Bob is free to tell Carol
where Alice is (as long as the <retention-expiry> time has not where Alice is (as long as the <retention-expiry> time has not
elapsed, indicating that the location information should be elapsed, indicating that the location information should have
deleted). This is an implicit byproduct of the PIDF-LO rule-set, as already been deleted, according to RFC 4119). This is an implicit
of this writing. This decision is a configuration issue, but is byproduct of the PIDF-LO rule-set, as of this writing. This decision
worth mentioning here. is a configuration issue, but is worth mentioning here.
6.1.1 UAC Receiving a Location Failure Indication 6.1.1 UAC Receiving a Location Failure Indication
Location Recipients that use the location information for Location Recipients that use the location information for
location-based routing decisions can be either destination UASs or location-based routing decisions can be either destination UAs or
intermediate servers. If a request fails based on the location intermediate servers. If a request fails based on the location
information in the request, a 424 (Bad Location Information) information in the request, a 424 (Bad Location Information)
response is sent back to the UAC. The 424 MUST have a response is sent back to the UAC. The 424 MUST have a
Geolocation-Error header field containing one or more Geolocation-Error header field containing one or more
locationErrorValues in the response message. A locationErrorValue locationErrorValues in the response message. A locationErrorValue
has a header field parameter indicating which entity inserted the has a header field parameter indicating which entity inserted the
locationValue correlated to this error, called the "inserter=" locationValue correlated to this error, called the "inserter="
parameter. This "inserter=" parameter (in the locationErrorValue) parameter. This "inserter=" parameter (in the locationErrorValue)
is copied from the "inserted-by=" parameter (from the locationValue) is copied from the "inserted-by=" parameter (from the locationValue)
by the Location Recipient (UAS or proxy) sending the error response. by the Location Recipient (UA or proxy) sending the error response.
A UAC receiving a Geolocation-Error in any response type MUST check A UAC receiving a Geolocation-Error in any response type MUST check
whether the "inserter=" parameter in the locationErrorValue whether the "inserter=" parameter in the locationErrorValue
indicates this UAC. indicates this UAC.
o If locationErrorValue does not match, the locationErrorValue o If locationErrorValue does not match, the locationErrorValue
MUST be ignored. MUST be ignored.
o If a locationErrorValue is in a 424, and the "inserter=" entity o If a locationErrorValue is in a 424, and the "inserter=" entity
is not this UAC, the response SHOULD be treated as a 400 is not this UAC, the response SHOULD be treated as a 400
response. response.
skipping to change at page 29, line 44 skipping to change at page 33, line 40
Unless stated otherwise by future standards-track publication(s), a Unless stated otherwise by future standards-track publication(s), a
location URI only has meaning within the Geolocation header field location URI only has meaning within the Geolocation header field
and MUST NOT appear in any other SIP header field. and MUST NOT appear in any other SIP header field.
There are 3 Geolocation header field parameters, There are 3 Geolocation header field parameters,
o "inserted-by=" o "inserted-by="
o "used-for-routing" o "used-for-routing"
o "routing-allowed" o "routing-allowed"
The "inserted-by=" and "used-for-routing" parameters are contained
within a locationValue, whereas the "routing-allowed" parameter is
outside any locationValue, and is to appear at most once in the SIP
request.
The "inserted-by=" parameter informs a Location Recipient which SIP The "inserted-by=" parameter informs a Location Recipient which SIP
entity added this locationValue to the SIP request. This parameter entity added this locationValue to the SIP request. This parameter
is mandatory for each locationValue in the request. The value in is mandatory for each locationValue in the request. The value in
the "inserted-by=" parameter is copied into the "inserter=" the "inserted-by=" parameter is copied into the "inserter="
parameter in each locationErrorValue if there is an error in the parameter in each locationErrorValue if there is an error in the
location to be reported back to the location sender. See section location to be reported back to the location sender. See section
6.2.1. 6.2.1.
The "used-for-routing" parameter is included in the locationValue if The "used-for-routing" parameter is included in the locationValue if
a SIP server used the location in the request to determine how to a SIP server used the location in the request to determine how to
skipping to change at page 30, line 39 skipping to change at page 34, line 38
or proxy server(s) cannot reply to a response with an error or proxy server(s) cannot reply to a response with an error
response. If the UAS wants to send its location to a UAC, it can do response. If the UAS wants to send its location to a UAC, it can do
so in a new request within a separate transaction. This document so in a new request within a separate transaction. This document
gives no recommendation about which SIP request to use, but SIP gives no recommendation about which SIP request to use, but SIP
MESSAGE is a viable choice. MESSAGE is a viable choice.
A UAS MAY include a 'geolocation' option tag in the Supported header A UAS MAY include a 'geolocation' option tag in the Supported header
field of a response, indicating it does understand this extension, field of a response, indicating it does understand this extension,
even if location was not included in a request to the UAS. even if location was not included in a request to the UAS.
A UAS wishing to dereference an location URI contained in a received A UAS wishing to dereference a location URI contained in a received
request will use the 'presence' event package in a SUBSCRIBE request request will use the 'presence' event package in a SUBSCRIBE request
to the URI. If accepted, the LS will return the PIDF-LO to the UAS to the URI. If accepted, the LS will return the PIDF-LO to the UAS
in a NOTIFY request. If there are any errors during dereferencing, in one or more NOTIFY requests - depending on the duration of the
subscription. If there are any errors during dereferencing,
or in the PIDF-LO itself, the UAS will respond to the original or in the PIDF-LO itself, the UAS will respond to the original
request with a locationErrorValue indicating what the UAS concluded request with a locationErrorValue indicating what the UAS concluded
was wrong with the location. This is to include any dereferencing was wrong with the location. This is to include any dereferencing
problems encountered. problems encountered.
Dereferencing for sip:, sips: and pres: URI schemes are Dereferencing for sip:, sips: and pres: URI schemes are
mandatory-to-implement. mandatory-to-implement.
A UAS MUST be prepared to receive subsequent location updates from A UAS MUST be prepared to receive subsequent location updates from
the UAC, either LbyV or LbyR (regardless of how the UAS received upstream entities (regardless of how the UAS received location
location previously from this UAC). The UAC will convey updated previously from this UAC). The UAC will convey updated location
location using the UPDATE [RFC3311] method to the UAS, and not a using the UPDATE [RFC3311] method to the UAS, and not a reINVITE.
reINVITE. The UAS MUST NOT reject updated location arriving in a The UAS MUST NOT reject updated location arriving in a reINVITE
reINVITE though, as other dialog parameters might be changing also though, as other dialog parameters might be changing also (in which
(in which a reINVITE is appropriate). a reINVITE is appropriate).
If there is more than one location (any combination of LbyV and If there is more than one location (any combination of PIDF-LOs or
LbyR), this document does not give guidance about what a Location location URIs), this document does not give guidance as to what a
Recipient does with each location. There are no priority or Location Recipient does with each location. There are no priority
more-trusted indications specified by this document. All this is or 'more-trusted' indications specified by this document. All this
considered application-specific, and out-of-scope for this document. is considered application-specific, and out-of-scope for this
If more than one location is present in the PIDF-LO, location document. If more than one location is present in the PIDF-LO,
elements in the same PIDF-LO MUST apply to the same Target location elements in the same PIDF-LO MUST apply to the same Target
(identified in the "entity=" attribute) and point at the same (identified in the "entity=" attribute) and MUST point at the same
position on the earth. If there is more than one PIDF-LO with position on the earth. If there is more than one PIDF-LO with
different Target identifiers, then the UAC is merely telling the UAS different Target identifiers, then the UAC is merely telling the UAS
where more than one Target is, and there should not be any conflict. where more than one Target is, and there SHOULD NOT be any conflict.
Within any PIDF-LO, there is a <retransmission-allowed> policy Within any PIDF-LO, there is a <retransmission-allowed> policy
element that can be set to "yes" or "no". These are the only element that can be set to "yes" or "no". These are the only
possibilities. If Alice conveys her location to Bob (as has been possibilities. If Alice conveys her location to Bob (as has been
described throughout this document) with a <retransmission-allowed> described throughout this document) with a <retransmission-allowed>
element set to "no", then Bob MUST NOT inform any other element element set to "no", then Bob MUST NOT inform any other element
where Alice is. If the <retransmission-allowed> element is set to where Alice is. If the <retransmission-allowed> element is set to
"yes", then Bob can inform other elements where Alice is, but only "yes", then Bob can inform other elements where Alice is, but only
as long as the <retention-expiry> policy element, also in the as long as the <retention-expiry> policy element, also in the
PIDF-LO, allows [RFC4119]. As a byproduct of this, that means that PIDF-LO, allows [RFC4119]. As a byproduct of this, that means that
if Alice conveys her location to Bob with a <retransmission-allowed> if Alice conveys her location to Bob with a <retransmission-allowed>
element set to "yes", and the <retention-expiry> time does not element set to "yes", and the <retention-expiry> time does not
require Bob to delete Alice's location yet, then Bob is free to tell require Bob to delete Alice's location yet, then Bob is free to tell
anyone else where Alice is. The entity= attribute in the <presence> anyone else where Alice is. The "entity=" attribute in the
element identifies who is the target of each location, preventing <presence> element identifies who is the Target of each location,
confusion. Whenever Bob conveys Alice's location, preventing confusion. Whenever Bob conveys Alice's location,
<retention-expiry> timer MUST be maintained as is (i.e., not changed <retention-expiry> timer MUST be maintained as is (i.e., not changed
from when Bob received it). RFC 4119 implicitly allows this from when Bob received it). RFC 4119 implicitly allows this
behavior, and the behavior does not change when SIP is the Using behavior, and the behavior does not change when SIP is the Using
Protocol. Protocol.
6.2.1 UAS Generating a Location Failure Indication 6.2.1 UAS Generating a Location Failure Indication
If a UAS receives location in a request, but determines there is a If a UAS receives location in a request, but determines there is a
problem with the location in the request, it is the responsibility problem with the location in the request, it is the responsibility
of the UAS to inform the entity that inserted the problematic of the UAS to inform the entity that inserted the problematic
skipping to change at page 32, line 16 skipping to change at page 36, line 16
Location Recipient (the UAS), in a response, when it wants to inform Location Recipient (the UAS), in a response, when it wants to inform
the location "inserter=" entity there was a problem with the the location "inserter=" entity there was a problem with the
location it received. location it received.
There can be more than one locationValue in a request. The There can be more than one locationValue in a request. The
"inserter=" parameter in the locationErrorValue will prevent "inserter=" parameter in the locationErrorValue will prevent
entities that did not insert the errored location from entities that did not insert the errored location from
misunderstanding whether the locationErrorValue applies to them. misunderstanding whether the locationErrorValue applies to them.
If there is one valid locationValue in a request, even if all the If there is one valid locationValue in a request, even if all the
others have errors with them, the Location Recipient MUST NOT send a others have errors associated with them, the Location Recipient MUST
424 (Bad Location Information) response. The Location Recipient NOT send a 424 (Bad Location Information) response. The Location
(the UAS) MUST send a locationErrorValue for each errored Recipient (the UAS) MUST send a locationErrorValue for each errored
locationValue, with unique "inserter=" parameters to make sure the locationValue, with unique "inserter=" parameters to make sure the
right entities know which locations were in error. right entities know which locations were in error.
As hinted at, a location "inserter=" can be a UAC or it can be an As hinted at, a location "inserter=" can be a UAC or it can be an
in-signaling-path SIP server acting as a UAC locator. This in-signaling-path SIP server acting as a UAC locator. This
means the SIP server is including its version of where it thinks the means the SIP server is including its version of where it thinks the
UAC is, geographically. This "inserter=" has to be in the form of UAC is, geographically. This "inserter=" has to be in the form of
an dereferencable location URI in a locationValue, because SIP an dereferencable location URI in a locationValue, because SIP
servers are not allowed to insert message bodies. servers are not allowed to insert message bodies.
skipping to change at page 33, line 47 skipping to change at page 37, line 47
Here is an example of a Geolocation-Error header field Here is an example of a Geolocation-Error header field
Geolocation-Error: 201; code="Linkable Target Identity Required"; Geolocation-Error: 201; code="Linkable Target Identity Required";
node="server42.example.com"; node="server42.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
The above example says that the Location Recipient is The above example says that the Location Recipient is
server42.example.com, and this entity cannot verify the Target's server42.example.com, and this entity cannot verify the Target's
identity within this message. This is typically needed in order to identity within this message. This is typically needed in order to
make routing decisions for the SIP request where the entity= make routing decisions for the SIP request where the "entity="
attribute has an unlinkable pseudonym obscuring a location target's attribute has an unlinkable pseudonym obscuring a location Target's
identity from the signaling. This is not desire because if Alice's identity from the signaling. This is not desire because if Alice's
message is to be routed based on the location in the SIP request, message is to be routed based on the location in the SIP request,
server42 has to verify that this is Alice's location. The server42 has to verify that this is Alice's location. The
appropriate action is to send a 424 (Bad Location Information) appropriate action is to send a 424 (Bad Location Information)
response with the above (201) Geolocation-Error header value. We do response with the above (201) Geolocation-Error header value. We do
not want Alice's request routed based on Bob's location. not want Alice's request routed based on Bob's location.
See Section 4.3 for further rules about the Geolocation-Error header See Section 4.3 for further rules about the Geolocation-Error header
field and the locationErrorValue. field and the locationErrorValue.
skipping to change at page 34, line 20 skipping to change at page 38, line 20
choose to use). This scenario MAY be addressed in a future effort. choose to use). This scenario MAY be addressed in a future effort.
Further, more than one error code is allowed in the Further, more than one error code is allowed in the
locationErrorValue - each having one "inserter=" parameter. locationErrorValue - each having one "inserter=" parameter.
6.3 Proxy Behavior 6.3 Proxy Behavior
[RFC3261] states message bodies cannot be added by proxies. [RFC3261] states message bodies cannot be added by proxies.
However, proxies are permitted to add a header field to a request. However, proxies are permitted to add a header field to a request.
This means that a proxy can add a Geolocation locationValue header This means that a proxy can add a Geolocation locationValue header
field with a dereferencable location URI, but not a LbyV message field with a dereferencable location URI, but not an LbyV message
body. body.
It is allowed, but NOT RECOMMENDED, for more than one SIP element to It is allowed, but NOT RECOMMENDED, for more than one SIP element to
insert location into a request along its path. As described earlier insert location into a request along its path. As described earlier
in this document, each insertion of location into a SIP request is in this document, each insertion of location into a SIP request is
accompanied by a new locationValue in a Geolocation header field. accompanied by a new locationValue in a Geolocation header field.
Also described earlier, each locationValue MUST contain an Also described earlier, each locationValue MUST contain an
"inserted-by=" value indicating to a Location Recipient the host "inserted-by=" value indicating to a Location Recipient the host
that inserted a specific location into a particular request. that inserted a specific location into a particular request.
If, however, location is already in a SIP request, a SIP server If, however, location is already in a SIP request, a SIP server
SHOULD NOT add another location URI that identifies the same target SHOULD NOT add another location URI that identifies the same Target
in the PIDF-LO (in the entity= attribute) to the same request. This in the PIDF-LO (in the "entity=" attribute) to the same request.
will likely cause confusion at the Location Recipient as to which to This will likely cause confusion at the Location Recipient as to
use. which to use.
More than one Geolocation locationValue in a message is permitted, More than one Geolocation locationValue in a message is permitted,
but can cause confusion at the recipient. If a proxy chooses to add but can cause confusion at the recipient. If a proxy chooses to add
a locationValue to a Geolocation header field, which would be a a locationValue to a Geolocation header field, which would be a
local policy decision, the new locationValue MUST be added to the local policy decision, the new locationValue MUST be added to the
end of the header field (after previous locationValue(s)). This is end of the header field (after previous locationValue(s)). This is
done to create an order of insertion of locationValues along the done to create an order of insertion of locationValues along the
path. Proxies MUST NOT modify the order of locationValues in a path. Proxies MUST NOT modify the order of locationValues in a
geolocation header field. geolocation header field. Section 4 covers more details with
respect to the rules of usage for the Geolocation header value(s).
Each rule MUST be obeyed as written there.
A proxy wishing to dereference a location URI contained in a A proxy wishing to dereference a location URI contained in a
received request will use the 'presence' event package in a received request will use the 'presence' event package in a
SUBSCRIBE request to the URI. If accepted, the LS will return the SUBSCRIBE request to the URI, but only if the "routing-allowed"
PIDF-LO to the proxy in a NOTIFY request. If there are any errors header parameter is set to "=yes". This transaction is described in
during dereferencing, or in the PIDF-LO itself, the proxy will send Section 4.5. If accepted, the LS will return the PIDF-LO to the
an error to the UAC with a locationErrorValue indicating what the proxy in a NOTIFY request. If there are any errors during
proxy concluded was wrong with the location. This is to include any dereferencing, or in the PIDF-LO itself, the proxy will send an
error to the UAC with a locationErrorValue indicating what the proxy
concluded was wrong with the location. This is to include any
dereferencing problems encountered. dereferencing problems encountered.
6.3.1 Proxy Behavior with Geolocation Header Field Parameters 6.3.1 Proxy Behavior with Geolocation Header Field Parameters
SIP servers MUST NOT delete any existing Geolocation locationValue SIP servers MUST NOT delete any existing Geolocation locationValue
(URI or header field parameter) from a request. An existing (URI or header field parameter) from a request. An existing
locationValue MAY be modified by adding a "used-for-routing" locationValue MAY be modified by adding a "used-for-routing"
parameter to an existing locationValue, if the request was parameter to an existing locationValue, if the request was
retargeted based on the location within that locationValue. retargeted based on the location within that locationValue.
According to this specification, the default value of any According to this specification, the default value of any
Geolocation header value "routing-allowed" is "no". This parameter Geolocation header value "routing-allowed" is "no". If a Geolocation
does not have to be present to deny SIP servers along the signaling header value is received by a SIP server with a "routing-allowed"
path the ability to view the target's location. This parameter MAY parameter set to "=no", the SIP server MUST NOT view or dereference
be added in transit by a SIP server, and MUST be with a value of the location in the SIP request. If there is no "routing-allowed"
"no". Other modifications of the Geolocation header field MUST NOT parameter in the SIP request (i.e., all instances of Geolocation
occur. header field rows (as defined in section 7.3.1 of RFC 3261), the
previously stated default is to treat the Geolocation header value
as if it contained a "routing-allowed=no" parameter, without
exception. Therefore, this parameter does not have to be present to
deny SIP servers along the signaling path the ability to view the
Target's location. This parameter MAY be added in transit by a SIP
server, and MUST be with a value of "no".
For example, an existing Geolocation locationValue in a request of: For example, an existing Geolocation locationValue in a request of:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice123@atlanta.example.com"; inserted-by="alice123@atlanta.example.com"
can be modified by a proxy to add the "used-for-routing" parameter, can be modified by a proxy to add the "used-for-routing" parameter,
like this: like this:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice123@atlanta.example.com"; inserted-by="alice123@atlanta.example.com",
used-for-routing used-for-routing
if this is the locationValue the proxy used to make a retargeting if this is the locationValue the proxy used to make a retargeting
decision based upon, but the proxy can make no other modification. decision based upon, but the proxy can make no other modification.
A SIP server MAY add a new Geolocation locationValue to a SIP A SIP server MAY add a new Geolocation locationValue to a SIP
request. The server SHOULD NOT insert a locationValue of a Target request. The server SHOULD NOT insert a locationValue of a Target
unless it is reasonably certain it knows the actual geographic unless it is reasonably certain it knows the actual geographic
location of the Location Target (for example, if it thoroughly location of the Location Target (for example, if it thoroughly
understands the topology of the underlying access network and it can understands the topology of the underlying access network and it can
skipping to change at page 36, line 12 skipping to change at page 41, line 21
locationValues. Proxies MUST add locationValue at the end of all locationValues. Proxies MUST add locationValue at the end of all
locationValues that are already present in the request. locationValues that are already present in the request.
If this request was then retargeted by an intermediary using the If this request was then retargeted by an intermediary using the
locationValue inserted by server "ls7", the intermediary would add a locationValue inserted by server "ls7", the intermediary would add a
"used-for-routing" parameter like this: "used-for-routing" parameter like this:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice123@atlanta.example.com", inserted-by="alice123@atlanta.example.com",
<sips:3sdefrhy2jj7@ls7.atlanta.example.com>; <sips:3sdefrhy2jj7@ls7.atlanta.example.com>;
inserted-by="ls7.atlanta.example.com"; used-for-routing inserted-by="ls7.atlanta.example.com", used-for-routing
It is conceivable that an initial routing decision is made on It is conceivable that an initial routing decision is made on
one locationValue, and subsequently another routing decision is one locationValue, and subsequently another routing decision is
made on a different locationValue further towards the ultimate made on a different locationValue further towards the ultimate
destination. This retargeting decision can be made on a newly destination. This retargeting decision can be made on a newly
inserted locationValue. While unusual, it can occur. In such a inserted locationValue. While unusual, it can occur. In such a
case, proxies MUST NOT remove any existing "used-for-routing" header case, proxies MUST NOT remove any existing "used-for-routing" header
field parameter. In this instance, the SIP server retargeting based field parameter. In this instance, the SIP server retargeting based
on another locationValue MUST add the "used-for-routing" header on another locationValue MUST add the "used-for-routing" header
field parameter to the locationValue used for retargeting by this field parameter to the locationValue used for retargeting by this
skipping to change at page 37, line 9 skipping to change at page 41, line 71
the location within the request as if the header field parameter the location within the request as if the header field parameter
"routing-allowed" were present and set to "no". "routing-allowed" were present and set to "no".
B2BUAs and SBCs should also adhere to the above proxy guidance with B2BUAs and SBCs should also adhere to the above proxy guidance with
respect to the "Routing-allowed" header field parameter. In other respect to the "Routing-allowed" header field parameter. In other
words, if the particular type of SIP server mentioned here supports words, if the particular type of SIP server mentioned here supports
this SIP extension and is not the ultimate destination of this SIP this SIP extension and is not the ultimate destination of this SIP
request, each policy rule within the Geolocation header field MUST request, each policy rule within the Geolocation header field MUST
remain intact and unchanged. remain intact and unchanged.
No SIP server can delete a "Routing-allowed" header field SIP server MUST NOT delete a "routing-allowed" header field
parameter, but if one is not yet present, any SIP server MAY add a parameter, but if one is not yet present, any SIP server MAY add a
"Routing-allowed" header field parameter with the value set to "no" "Routing-allowed" header field parameter with the value set to "no"
only. only.
6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues 6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues
For proxies that receive a SIP request that contains a location For proxies that receive a SIP request that contains a location
error, all the rules applicable to a UAS apply (see Section 6.2.1.). error, all the rules applicable to a UAS apply (see Section 6.2.1.).
The one point to add is that a proxy does not need to examine The one point to add is that a proxy does not need to examine
location contained in a request. Section 6.2.1. only applies to location contained in a request. Section 6.2.1. only applies to
skipping to change at page 37, line 45 skipping to change at page 42, line 4
supplied was in error. It SHOULD react according to the error code supplied was in error. It SHOULD react according to the error code
received. This document gives no guidance what the proxy should do received. This document gives no guidance what the proxy should do
to rectify the bad location information, since the proxy is not the to rectify the bad location information, since the proxy is not the
SIP response destination, but a future document could address this. SIP response destination, but a future document could address this.
The "routing-allowed" parameter's purpose is to indicate if SIP The "routing-allowed" parameter's purpose is to indicate if SIP
servers along the signaling path should bother looking at the servers along the signaling path should bother looking at the
location message body or dereferencing the location URI. There are location message body or dereferencing the location URI. There are
two values specified here for this parameter: "yes" and "no". If two values specified here for this parameter: "yes" and "no". If
the "routing-allowed" parameter is set to "yes", and the SIP server the "routing-allowed" parameter is set to "yes", and the SIP server
determines this SIP request should be routed based on the target's determines this SIP request should be routed based on the Target's
location, this parameter gives the server permission to look at the location, this parameter gives the server permission to look at the
location (or dereference it). If this parameter is set to "no", location (or dereference it). If this parameter is set to "no",
then the SIP server MUST NOT view the location message body or then the SIP server MUST NOT view the location message body or
dereference the location URI within this SIP request. If the SIP dereference the location URI within this SIP request. If the SIP
server believes it cannot process this message properly because it server believes it cannot process this message properly because it
needs to learn the target's location in order to route the message, needs to learn the Target's location in order to route the message,
then it MUST return a 424 (Bad Location Information) response, then it MUST return a 424 (Bad Location Information) response,
indicating it requires permission (error code 400) to view the indicating it requires permission (error code 402) to view the
location. location.
Here is an example of a Geolocation-Error header field Here is an example of a Geolocation-Error header field
Geolocation-Error: 400; code="Permission to Reveal Location Geolocation-Error: 402; code="Permission to Route based on
Information to a Third Party"; Location Information";
node="server42.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
The above example says that the Location Recipient is The above example says that the Location Recipient is
server42.example.com, and this entity believes it cannot route this server42.example.com, and this entity believes it cannot route this
message without knowing permission to view the Target's location. message without knowing permission to view the Target's location.
Regardless of whether there is a Geolocation header value parameter, Regardless of whether there is a Geolocation header value parameter,
such as such as
routing-allowed=no routing-allowed=no
or this parameter is not present in the SIP request (as shown 400 or this parameter is not present in the SIP request (as shown 402
error example above). The default behavior is to act as if the error example above). The default behavior is to act as if the
parameter is present and set to "no". Server42 MUST get permission parameter is present and set to "=no". Server42 MUST get permission
to view the Target's location by reading a routing-allowed header to view the Target's location by reading a routing-allowed header
parameter saying "yes", otherwise a 400 error is sent back to the parameter saying "=yes", otherwise a 402 error is sent back to the
inserter= entity to get permission. "inserter=" entity to get permission.
Section 4.3 highlights this example, stating the user, Alice, MUST Section 4.3 highlights this example, stating the user, Alice, MUST
be made aware of this location revelation request. This document be made aware of this location revelation request. This document
does not give any guidance how Alice is to be informed (i.e., audio, does not give any guidance how Alice is to be informed (i.e., audio,
visual, etc). Alice can grant permission or choose not to, knowing visual, etc). Alice can grant permission or choose not to, knowing
this SIP request attempt (to this destination, at this time) will this SIP request attempt (to this destination, at this time) will
fail. The problem might not recur if a future SIP request were to fail. The problem might not recur if a future SIP request were to
travel through a different server than server42 (or it might again). travel through a different server than server42 (or it might again).
7. Geopriv Privacy Considerations 7. Geopriv Privacy Considerations
skipping to change at page 39, line 29 skipping to change at page 43, line 39
message/packet transmission of location as a complete message/packet transmission of location as a complete
transaction." transaction."
When used for tracking, a simple NOTIFY or UPDATE normally is When used for tracking, a simple NOTIFY or UPDATE normally is
relatively small, although the PIDF itself can be large. Normal relatively small, although the PIDF itself can be large. Normal
RFC 3261 procedures of reverting to TCP when the MTU size is RFC 3261 procedures of reverting to TCP when the MTU size is
exceeded would be invoked. exceeded would be invoked.
8. Security Considerations 8. Security Considerations
Conveyance of physical location of a UAC 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 protecting be accomplished through secure mechanisms, like S/MIME protecting
message bodies (although this is not widely deployed) or TLS message bodies (although this is not widely deployed) or TLS
protecting the overall signaling. In cases where a session set-up protecting the overall signaling. In cases where a session set-up
is retargeted based on the location of the UAC initiating the call is retargeted based on the location of the UA initiating the call
or SIP MESSAGE, securing the LbyV location with an end-to-end or SIP MESSAGE, securing the LbyV location with an end-to-end
mechanism such as S/MIME is problematic, because one or more proxies mechanism such as S/MIME is problematic, because one or more proxies
on the path need the ability to read the location information to on the path need the ability to read the location information to
retarget the message to the appropriate new destination UAS. retarget the message to the appropriate new destination UAS.
Securing the location hop-by-hop, using TLS, protects the message Securing the location hop-by-hop, using TLS, protects the message
from eavesdropping and modification, but exposes the information to from eavesdropping and modification, but exposes the information to
all proxies on the path as well as the endpoint. In most cases, the all proxies on the path as well as the endpoint. In most cases, the
UAC does not know the identity of the proxy or proxies providing UA does not know the identity of the proxy or proxies providing
location-based routing services, so that end-to-middle solutions location-based routing services, so that end-to-middle solutions
might not be appropriate either. might not be appropriate either.
These same issues exist for basic SIP signaling, but SIP normally These same issues exist for basic SIP signaling, but SIP normally
does not carry information to physically track a user. This does not carry information to physically track a user. This
extension is especially sensitive. That said, there is the ability, extension is especially sensitive. That said, there is the ability,
according to [RFC3693] to have an anonymous identity for the according to [RFC3693] to have an anonymous identity for the
target's location. This is accomplished by use of an unlinkable Target's location. This is accomplished by use of an unlinkable
pseudonym in the entity= attribute of the <presence> element pseudonym in the "entity=" attribute of the <presence> element
[RFC4479]. Though, this can be problematic for routing messages [RFC4479]. Though, this can be problematic for routing messages
based on location (covered several times in the document above). based on location (covered several times in the document above).
When location is inserted by a UAC, which is RECOMMENDED, it can When a UA inserts location, the UA sets the policy on whether to
decide whether to reveal its location using hop-by-hop methods. UAC reveal its location along the signaling path - as discussed in
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 SHOULD alert a user that location is being user permission, and SHOULD alert the user that location is being
conveyed. Proxies inserting location for location-based routing are conveyed. Proxies inserting location for location-based routing are
unable to alert users, and such use is NOT RECOMMENDED. Proxies unable to alert users, and such use is NOT RECOMMENDED. Proxies
conveying location using this extension MUST have the permission of conveying location using this extension MUST have the permission of
the Target to do so. the Target to do so.
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 view location while the SIP request is in transit. The default
for this is set to "no", and there is an error explicitly describing for this is set to "no", and there is an error explicitly describing
how an intermediary asks for permission to view the Target's how an intermediary asks for permission to view the Target's
location. location.
Because target locations can be placed on a remote server, called a Because Target locations can be placed on a Location Server
Location Server accessible with the possession of a location URI, accessible with the possession of a location URI, this URI has its
this URI has its own security considerations. It is tempting to own security considerations. It is tempting to assume that the
assume that the dereference of this URI would have authentication, dereference of this URI would have authentication, authorization and
authorization and other security mechanisms that limit the access to other security mechanisms that limit the access to information.
information. Unfortunately, this might not be true. The access Unfortunately, this might not be true. The access network the UA is
network the UAC is connected to can be the source of location connected to can be the source of location reference, and it might
reference, and it might not have any credentialing mechanism not have any credentialing mechanism suitable for controlling access
suitable for controlling access to a target's location. Consider, to a Target's location. Consider, specifically, a nomadic user
specifically, a nomadic user connected to an access network in a connected to an access network in a hotel. The UA has no way to
hotel. The UAC has no way to provide a credential acceptable of the provide a credential acceptable of the hotel Location Server (LS) to
hotel Location Server (LS) to any of its intended Location any of its intended Location Recipients. The recipient of a
Recipients. The recipient of a reference does not know if a reference does not know if a reference has appropriate authorization
reference has appropriate authorization policies or not. policies or not.
Accordingly, possession of the reference should be considered Accordingly, possession of the reference should be considered
equivalent to possession of the value, and the reference should be equivalent to possession of the value, and the reference should be
treated with the same degree of care as the value. Specifically, treated with the same degree of care as the value. Specifically,
TLS MUST be used to protect the security of the reference. Notice TLS MUST be used to protect the security of the reference. Notice
that this specification does not constrain the dereference protocol that this specification does not constrain the dereference protocol
to use TLS. That specification is left entirely to the dereferencing to use TLS. That specification is left entirely to the dereferencing
protocol documents. protocol documents.
There is no end-to-end integrity on any locationValue or There is no end-to-end integrity on any locationValue or
skipping to change at page 42, line 34 skipping to change at page 44, line 144
processed at this time. No actionable guidance. processed at this time. No actionable guidance.
Can be treated as a 200 or 300 error by error Can be treated as a 200 or 300 error by error
recipient. recipient.
200 "Retry Location Later with same data" The location [this doc] 200 "Retry Location Later with same data" The location [this doc]
cannot be processed at this time. Error recipient cannot be processed at this time. Error recipient
should try again with same data. should try again with same data.
201 "Linkable Target Identity Required" [this doc] 201 "Linkable Target Identity Required" [this doc]
Target's identity cannot be unlinkable within Target's identity cannot be unlinkable within
the presence element's entity= attribute. This the presence element's "entity=" attribute. This
is necessary for routing SIP requests based is necessary for routing SIP requests based
on Target's location (and some other entity's). on Target's location (and some other entity's).
300 "Retry Location Later with device updated location" [this doc] 300 "Retry Location Later with device updated location" [this doc]
Location cannot be processed at this time. Error Location cannot be processed at this time. Error
recipient should try again with same data. recipient should try again with same data.
400 "Permission To Reveal Location Information to a Third Party" 400 "Permission To Use Location Information " [this doc]
Permission from calling user to reveal location [this doc] Permission is being requested from the calling
user to reveal and or use location in request
before request can be processed. This error
informs the "inserter=" entity that permission
is required to process this SIP request. Ruleholder
MUST be informed of permission request.
401 "Permission To Retransmit Location Information to a Third Party"
Permission from the calling user to send location [this doc]
information to a third party entity - not in the
signaling path. This flag is in the PIDF-LO. The
user MUST be informed of permission request.
402 "Permission to Route based on Location Information" [this doc]
Permission from calling user to reveal location
in request before request can be processed. This in request before request can be processed. This
is a routing by location error. User MUST be is a routing by location error. The user MUST be
informed of permission request. informed of permission request.
500 "Location Information Denial" Request was actively [this doc] 500 "Location Information Denial" Request has been [this doc]
denied because of the location in the request. Explicitly denied because of the location in
Recipient should not try again. the request. Sender should not try again.
9.6 IANA Registration of Location URI Schemes 9.6 IANA Registration of Location URI Schemes
This document directs IANA to create a new set of parameters in a This document directs IANA to create a new set of parameters in a
separate location from SIP and Geopriv, called the "Location separate location from SIP and Geopriv, called the "Location
Reference URI" registry, containing the URI scheme, the Reference URI" registry, containing the URI scheme, the
Content-Type, and the reference, as follows: Content-Type, and the reference, as follows:
URI Scheme Content-Type Reference URI Scheme Content-Type Reference
---------- ------------ --------- ---------- ------------ ---------
skipping to change at page 43, line 32 skipping to change at page 44, line 203
10. Acknowledgements 10. Acknowledgements
To Dave Oran for helping to shape this idea. To Dave Oran for helping to shape this idea.
To Jon Peterson and Dean Willis on guidance of the effort. To Jon Peterson and Dean Willis on 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 and Jacqueline Lee for constructive Barnes, Dan Wing, Matt Lepinski, John Elwell and Jacqueline Lee for
feedback and nits checking. 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.
11. References 11. References
skipping to change at page 44, line 69 skipping to change at page 44, line 291
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004 Configuration Information", RFC 3825, July 2004
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", RFC 4776, October 2006 Information ", RFC 4776, October 2006
[ID-PHONE] B. Rosen, J. Polk, "ECRIT Phone BCP", [ID-PHONE] B. Rosen, J. Polk, "ECRIT Phone BCP",
draft-ietf-ecrit-phonebcp, "work in progress", July 2009 draft-ietf-ecrit-phonebcp, "work in progress", Jan 2010
[ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location
Notifications in SIP", draft-ietf-geopriv-loc-filters, "work
in progress", December 2009
Author Information Author Information
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
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr. 470 Conrad Dr.
Mars, PA 16046 Mars, PA 16046
skipping to change at page 44, line 134 skipping to change at page 44, line 359
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, whether included LbyV or location conveyance within SIP.
LbyR.
Motivation: interoperability with other IETF location protocols and Motivation: interoperability with other IETF location protocols and
Mechanisms. Mechanisms.
UAC-9 There must be a mechanism for the UAC to request the UAS send UAC-9 There must be a mechanism for the UAC to request the UAS send
its location. its location.
UAC-9 has been DEPRECATED by the SIP WG, due to the many UAC-9 has been DEPRECATED by the SIP WG, due to the many
problems this requirement would have caused if implemented. problems this requirement would have caused if implemented.
The solution is for the above UAS to send a new request to The solution is for the above UAS to send a new request to
 End of changes. 146 change blocks. 
358 lines changed or deleted 588 lines changed or added

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