draft-ietf-sipcore-location-conveyance-04.txt   draft-ietf-sipcore-location-conveyance-05.txt 
Network Working Group James Polk Network Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expires: April 25, 2011 Brian Rosen Expires: September 8, 2011 Brian Rosen
Intended Status: Standards Track (PS) Jon Peterson Intended Status: Standards Track (PS) Jon Peterson
NeuStar NeuStar
Oct 25, 2010 Feb 8, 2011
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sipcore-location-conveyance-04.txt draft-ietf-sipcore-location-conveyance-05.txt
Abstract Abstract
This document defines an extension to the Session Initiation This document defines an extension to the Session Initiation
Protocol (SIP) to convey geographic location information from one Protocol (SIP) to convey geographic location information from one
SIP entity to another SIP entity. The extension covers end-to-end SIP entity to another SIP entity. The SIP extension covers
conveyance as well as location-based routing, where SIP end-to-end conveyance as well as location-based routing, where SIP
intermediaries make routing decisions based upon the location of the intermediaries make routing decisions based upon the location of the
user agent client. Location Target.
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. the provisions of BCP 78 and BCP 79.
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.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2011. This Internet-Draft will expire on September 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 3, line 13 skipping to change at page 3, line 13
10.2 Informative References . . . . . . . . . . . . . . . . . 23 10.2 Informative References . . . . . . . . . . . . . . . . . 23
Author Information . . . . . . . . . . . . . . . . . . . . . 24 Author Information . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Requirements for SIP Location Conveyance . . . . 24 Appendix A. Requirements for SIP Location Conveyance . . . . 24
1. Conventions and Terminology used in this document 1. Conventions and Terminology used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. This document furthermore uses numerous terms defined in [RFC2119]. This document furthermore uses numerous terms defined
in RFC 3693 [RFC3693], including Location Objection, Location in RFC 3693 [RFC3693], including Location Object, Location
Recipient, Location Server, Target, and Using Protocol. Recipient, Location Server, Target, and Using Protocol.
2. Introduction 2. Introduction
Session Initiation Protocol (SIP) [RFC3261] creates, modifies and Session Initiation Protocol (SIP) [RFC3261] creates, modifies and
terminates multimedia sessions. SIP carries certain information terminates multimedia sessions. SIP carries certain information
related to a session while establishing or maintaining calls. This related to a session while establishing or maintaining calls. This
document defines how SIP conveys geographic location information of document defines how SIP conveys geographic location information of
a Target (Target) to a Location Recipient (LR). SIP acts as a Using a Target (Target) to a Location Recipient (LR). SIP acts as a Using
Protocol of location information, as defined in RFC 3693. Protocol of location information, as defined in RFC 3693.
skipping to change at page 3, line 52 skipping to change at page 3, line 52
location. location.
In the SIP context, a location recipient will most likely be a SIP In the SIP context, a location recipient will most likely be a SIP
UA, but due to the mediated nature of SIP architectures, location UA, but due to the mediated nature of SIP architectures, location
information conveyed by a single SIP request may have multiple information conveyed by a single SIP request may have multiple
recipients, as any SIP proxy server in the signaling path that recipients, as any SIP proxy server in the signaling path that
inspects the location of the Target must also be considered a inspects the location of the Target must also be considered a
Location Recipient. In presence-like architectures, an intermediary Location Recipient. In presence-like architectures, an intermediary
that receives publications of location information and distributes that receives publications of location information and distributes
them to watchers acts as a Location Server per RFC 3693. This them to watchers acts as a Location Server per RFC 3693. This
location conveyance mechanism can also be used to deliver URIs point location conveyance mechanism can also be used to deliver URIs
to such Location Servers where prospective Location Recipients can pointing to such Location Servers where prospective Location
request Location Objects. Recipients can request Location Objects.
3. Overview of SIP Location Conveyance 3. Overview of SIP Location Conveyance
An operational overview of SIP location conveyance can be shown in 4 An operational overview of SIP location conveyance can be shown in 4
basic diagrams, with most applications falling under one of the basic diagrams, with most applications falling under one of the
following basic use cases. Each is separated into its own subsection following basic use cases. Each is separated into its own subsection
here in section 3. here in section 3.
Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob
is an LR. A SIP intermediary appears in some of the diagrams. Any is an LR. A SIP intermediary appears in some of the diagrams. Any
skipping to change at page 5, line 25 skipping to change at page 5, line 25
| | Response | | | Response |
| (includes location) | | (includes location) |
| |<----------------| | |<----------------|
| Response | | | Response | |
|<-----------------------------------| | |<-----------------------------------| |
| | | | | | | |
Figure 2. Location Conveyed as a Location URI Figure 2. Location Conveyed as a Location URI
In Figure 2, location is conveyed indirectly, via a Location URI In Figure 2, location is conveyed indirectly, via a Location URI
carried in the SIP message (more of those details later). If Alice carried in the SIP request (more of those details later). If Alice
sends Bob this Location URI, Bob will need to dereference the URI - sends Bob this Location URI, Bob will need to dereference the URI -
analogous to Content Indirection [RFC4483] - in order to request the analogous to Content Indirection [RFC4483] - in order to request the
location information. In general, the LS provides the location value location information. In general, the LS provides the location value
to Bob instead of Alice directly. From a user interface to Bob instead of Alice directly for conveyance to Bob. From a user
perspective, Bob the user won't know that this information was interface perspective, Bob the user won't know that this information
gathered from an LS indirectly rather than culled from the SIP was gathered from an LS indirectly rather than culled from the SIP
request, and practically this does not impact the operation of request, and practically this does not impact the operation of
location-based applications. location-based applications.
The example given in this section is only illustrative, not
normative. In particular, applications can choose to dereference a
location URI at any time, possibly several times, or potentially not
at all. Applications receiving a Location URI in a SIP transaction
need to be mindful of timers used by different transactions. In
particular, if the means of dereferencing the Location URI might
take longer than the SIP transaction timeout (Timer C for INVITE
transactions, Timer F for non-INVITE transactions), then it needs to
rely on mechanisms other than the transaction's response code to
convey location errors, if returning such errors are necessary.
3.3 Location Conveyed though a SIP Intermediary 3.3 Location Conveyed though a SIP Intermediary
In Figure 3, we introduce the idea of a SIP intermediary into the In Figure 3, we introduce the idea of a SIP intermediary into the
example to illustrate the role of proxying in the location example to illustrate the role of proxying in the location
architecture. This intermediary could be a SIP proxy or it could be architecture. This intermediary can be a SIP proxy or it can be
a back-to-back-user-agent (B2BUA). In this message flow, the SIP a back-to-back-user-agent (B2BUA). In this message flow, the SIP
intermediary could act as a LR, in addition to Bob. The primary use intermediary could act as a LR, in addition to Bob. The primary use
case for intermediaries consuming location information is case for intermediaries consuming location information is
location-based routing. In this case, the intermediary chooses a location-based routing. In this case, the intermediary chooses a
next hop for the SIP request by consulting a specialized location next hop for the SIP request by consulting a specialized location
service which selects forwarding destinations based on geographical service which selects forwarding destinations based on geographical
location. In this case, the intermediary acts as a Location location.
Recipient.
Alice SIP Intermediary Bob LS Alice SIP Intermediary Bob LS
| | | | | | | |
| Request | | | | Request | | |
| w/Location | | | | w/Location | | |
|--------------->| | | |--------------->| | |
| | Request | | | | Request | |
| | w/Location | | | | w/Location | |
| |------------------>| | | |------------------>| |
| | | | | | | |
skipping to change at page 6, line 21 skipping to change at page 6, line 30
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 3. Location Conveyed though a SIP Intermediary Figure 3. Location Conveyed though a SIP Intermediary
However, the most common case will be one in which the SIP However, the most common case will be one in which the SIP
intermediary receives a request with location information (conveyed intermediary receives a request with location information (conveyed
either by-value or by-reference) and does not know or care about either by-value or by-reference) and does not know or care about
Alice's location, or support this extension, and merely passes it on Alice's location, or support this extension, and merely passes it on
to Bob. In this case, the intermediary does not act as a Location to Bob. In this case, the intermediary does not act as a Location
Recipient. Recipient. When the intermediary is not an LR, this use case is the
same as the one described in Section 3.1.
Note that an intermediary does not have to perform location-based Note that an intermediary does not have to perform location-based
routing in order to be location recipient. It could be the case that routing in order to be location recipient. It could be the case that
a SIP intermediary which does not perform location-based routing but a SIP intermediary which does not perform location-based routing but
does care when Alice includes her location; for example, it could does care when Alice includes her location; for example, it could
care that the location information is complete or that it correctly care that the location information is complete or that it correctly
identifies where Alice is. The best example of this is identifies where Alice is. The best example of this is
intermediaries that verify location information for emergency intermediaries that verify location information for emergency
calling, but it could also be for any location based routing - e.g., calling, but it could also be for any location based routing - e.g.,
contacting Pizza Hut, making sure that organization has Alice's contacting Pizza Hut, making sure that organization has Alice's
skipping to change at page 7, line 31 skipping to change at page 7, line 40
|--------------->| | | |--------------->| | |
| | Request | | | | Request | |
| | w/New Location | | | | w/New Location | |
| |------------------>| | | |------------------>| |
| | | | | | | |
Figure 4. SIP Intermediary Replacing Bad Location Figure 4. SIP Intermediary Replacing Bad Location
In this last use case, the SIP intermediary wishes to include a In this last use case, the SIP intermediary wishes to include a
Location Object indicating where it understands Alice to be. Thus, Location Object indicating where it understands Alice to be. Thus,
it must inform her user agent what location she should include in it needs to inform her user agent what location it will include in
any subsequent SIP request that contains her location. In these any subsequent SIP request that contains her location. In this
cases, the intermediary can reject Alice's request, through the SIP case, the intermediary can reject Alice's request and, through the
response, convey to her the best way to repair the request in order SIP response, convey to her the best way to repair the request in
for the intermediary to accept it. order for the intermediary to accept it.
Overriding location information provided by the user requires a Overriding location information provided by the user requires a
deployment where an intermediary necessarily knows better than an deployment where an intermediary necessarily knows better than an
end user - after all, it could be that Alice has an on-board GPS, end user - after all, it could be that Alice has an on-board GPS,
and the SIP intermediary only knows her nearest cell tower. Which is and the SIP intermediary only knows her nearest cell tower. Which is
more accurate location information? Currently, there is no way to more accurate location information? Currently, there is no way to
tell which entity is more accurate, or which is wrong - for that tell which entity is more accurate, or which is wrong - for that
matter. This document will not specify how to indicate which matter. This document will not specify how to indicate which
location is more accurate than another. If desired, intermediaries location is more accurate than another.
may furthermore allow both Alice's internally generated location, as
well as the SIP intermediary's determination of where Alice, to
appear in the same SIP request (the resubmitted one), and permit
that to be forwarded to Bob. This case is discussed in more detail
in section 4.2 of this document.
As an aside, it is not envisioned that any SIP-based emergency As an aside, it is not envisioned that any SIP-based emergency
services request (i.e., IP-911, or 112 type of call attempt) will services request (i.e., IP-911, or 112 type of call attempt) will
receive a corrective 'Bad Location Information' response from an receive a corrective 'Bad Location Information' response from an
intermediary. Most likely, the SIP intermediary would in that intermediary. Most likely, the SIP intermediary would in that
scenario act a B2BUA and insert into the request by-value any scenario act as a B2BUA and insert into the request by-value any
appropriate location information for the benefit of Public Safety appropriate location information for the benefit of Public Safety
Answering Point (PSAP) call centers to expedite call reception by Answering Point (PSAP) call centers to expedite call reception by
the emergency services personnel; thereby, minimizing any delay in the emergency services personnel; thereby, minimizing any delay in
call establishment time. The implementation of these specialized call establishment time. The implementation of these specialized
deployments is, however, outside the scope of this document. deployments is, however, outside the scope of this document.
4. SIP Modifications for Geolocation Conveyance 4. SIP Modifications for Geolocation Conveyance
The following sections detail the modifications The following sections detail the modifications
to SIP for location conveyance. to SIP for location conveyance.
skipping to change at page 8, line 43 skipping to change at page 8, line 49
The pres-URI is defined in [RFC3859]. The pres-URI is defined in [RFC3859].
HTTP-URI and HTTPS-URI are defined according to [RFC2616] and HTTP-URI and HTTPS-URI are defined according to [RFC2616] and
[RFC2818], respectively. [RFC2818], respectively.
The cid-url is defined in [RFC2392] to locate message body parts. The cid-url is defined in [RFC2392] to locate message body parts.
This URI type is present in a SIP request when location is conveyed This URI type is present in a SIP request when location is conveyed
as a MIME body in the SIP message. as a MIME body in the SIP message.
GEO-URIs [RFC5870] are not appropriate for usage the SIP Geolocation GEO-URIs [RFC5870] are not appropriate for usage in the SIP
header. Geolocation header.
Other URI schemas used in the location URI MUST be reviewed against Other URI schemas used in the location URI MUST be reviewed against
the RFC 3693 [RFC3693] criteria for a Using Protocol. the RFC 3693 [RFC3693] criteria for a Using Protocol.
The Geolocation header field has zero, one or two locationValues, The Geolocation header field can have zero or more locationValues. A
but MUST NOT contain more than two locationValue. A SIP intermediary SIP intermediary SHOULD NOT add location to a SIP request that
SHOULD NOT add location to a SIP request that already contains already contains location. This will quite often lead to confusion
location. This will quite often lead to confusion within LRs. within LRs. However, if a SIP intermediary were to add location,
However, if a SIP intermediary were to add location, even if even if location was not previously present in a SIP request, that
location was not previously present in a SIP request, that SIP SIP intermediary is fully responsible for addressing the concerns of
intermediary is fully responsible for addressing the concerns of any any 424 (Bad Location Information) SIP response it receives about
424 (Bad Location Information) SIP response it receives about this this location addition, and MUST NOT pass on (upstream) the 424
location addition, and MUST NOT pass on (upstream) the 424 response. response. Additionally, the first SIP intermediary to add a
locationValue adds it as the last locationValue in the header value.
The next SIP intermediary to add a locationValue adds it as the last
locationValue in the header value - and so on.
The placement of the "routing-allowed" header field parameter, The placement of the "routing-allowed" header field parameter,
strongly encouraged by [RFC5606], is outside the locationValue, and strongly encouraged by [RFC5606], is outside the locationValue, and
MUST always be last in the header field value. The routing-allowed MUST always be last in the header field value. The routing-allowed
parameter MUST be present, even when no locationValue is present. parameter MUST be present, even when no locationValue is present.
This scenario sets the routing-allowed policy downstream along the This scenario sets the routing-allowed policy downstream along the
request's signaling path. This header field parameter only has the request's signaling path. This header field parameter only has the
values "=yes" or "=no". When this parameter is "=yes", the values "=yes" or "=no". When this parameter is "=yes", the
locationValue can be used for routing decisions along the downstream locationValue can be used for routing decisions along the downstream
signaling path by intermediaries. If no routing-allowed parameter signaling path by intermediaries. If no routing-allowed parameter
is present in a SIP request, a SIP intermediary MAY insert this is present in a SIP request, a SIP intermediary MAY insert this
value with a RECOMMENDED value of "no" by default. value with a RECOMMENDED value of "no" by default.
When this parameter is "=no", this means no locationValue (inserted When this parameter is "=no", this means no locationValue (inserted
by the originating UAC or any intermediary along the signaling path by the originating UAC or any intermediary along the signaling path)
can be used by any SIP intermediary to make routing decisions. can be used by any SIP intermediary to make routing decisions.
Intermediaries that attempt to use the location information for Intermediaries that attempt to use the location information for
routing purposes in spite of this counter indication may end up routing purposes in spite of this counter indication may end up
routing the request improperly as a result. Sections 4.3 describes routing the request improperly as a result. Sections 4.3 describes
the details on what a routing intermediary does if it determines it the details on what a routing intermediary does if it determines it
needs to use the location in the SIP request in order to process the needs to use the location in the SIP request in order to process the
message further. message further. The practical implication is that when the
"routing-allowed" parameter is set to "no", if a cid:url is present
The practical implication is that when the "routing-allowed" in the SIP request, intermediaries MUST NOT view the location
parameter is set to "no", if a cid:url is present in the SIP (because it is not for intermediaries to view), and if a location
request, intermediaries MUST NOT view the location (because it is URI is present, intermediaries MUST NOT dereference it. UAs are
not for intermediaries to view), and if a location URI is present, allowed to view location in the SIP request even when the
intermediaries MUST NOT dereference it. UAs are allowed to view "routing-allowed" parameter is set to "no". An LR MUST by default
location in the SIP request even when the "routing-allowed" consider the "routing-allowed" header parameter as set to "no", with
parameter is set to "no". An LR MUST by default consider the no exceptions, unless the header field value is set to "yes".
"routing-allowed" header parameter as set to "no", with no
exceptions, unless the header field value is set to "yes".
If a routing-allowed parameter is parsed as set to "=yes", an
implementation MUST parse the rest of the SIP headers 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], PRACK [RFC3262] PUBLISH [RFC3903], PRACK [RFC3262]
The following table extends the values in Tables 2 and 3 of RFC 3261
[RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Geolocation R ar o - - o o o o
Geolocation 424 r o - - o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Geolocation R ar o o o o o o o
Geolocation 424 r o o o o o o o
Table 1: Summary of the Geolocation Header Field
The Geolocation header field MAY be included in any one of the The Geolocation header field MAY be included in any one of the
optional requests by a UA. A proxy MAY add the Geolocation header above listed requests by a UA, and a 424 response to any one of the
field, but MUST NOT modify any pre-existing locationValue, including requests sent above. Fully appreciating the caveats/warnings
the "routing-allowed" header field value. mentioned above, a SIP intermediary MAY add the Geolocation header
field, but MUST NOT modify any pre-existing locationValue, or any
"routing-allowed" header field value in the SIP request or response.
SIP intermediaries can also read any locationValue in which the
routing-allowed field is set to "=yes".
A SIP intermediary MAY add a Geolocation header field if one is not A SIP intermediary MAY add a Geolocation header field if one is not
present - for example, when a user agent does not support the present - for example, when a user agent does not support the
Geolocation mechanism but their outbound proxy does and knows their Geolocation mechanism but their outbound proxy does and knows their
location, or any of a number of other use cases (see Section 3). location, or any of a number of other use cases (see Section 3).
When adding a Geolocation header, a SIP intermediary MAY supply the When adding a Geolocation header value, a SIP intermediary MAY
"routing-allowed" parameter if not yet present in the SIP request, supply a "routing-allowed" parameter only if not yet present in the
but MUST NOT add a "routing-allowed" parameter if one is already SIP request.
present in this SIP request.
SIP implementations are advised to pay special attention to the SIP implementations are advised to pay special attention to the
policy elements for location retransmission and retention described policy elements for location retransmission and retention described
in RFC 4119. in RFC 4119.
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,
skipping to change at page 11, line 24 skipping to change at page 11, line 11
also contains the Target's version of where it is). Therefore, both also contains the Target's version of where it is). Therefore, both
locations are included - each with different <method> elements. The locations are included - each with different <method> elements. The
proper reaction of the user agent is to generate a new SIP request proper reaction of the user agent is to generate a new SIP request
that includes this composed location object, and send it towards the that includes this composed location object, and send it towards the
original LR. SIP intermediaries can verify that subsequent requests original LR. SIP intermediaries can verify that subsequent requests
properly insert the suggested location information before forwarding properly insert the suggested location information before forwarding
said requests. said requests.
SIP intermediaries MUST NOT add, modify or delete the location in a SIP intermediaries MUST NOT add, modify or delete the location in a
424 response. This specifically applies to intermediaries that are 424 response. This specifically applies to intermediaries that are
between the 424 response generator and the original UAC. All between the 424 response generator and the original UAC. Geolocation
respects of the Geolocation and Geolocation-Error headers and and Geolocation-Error header fields and PIDF-LO body parts MUST
PIDF-LO(s) MUST remain unchanged, never added to or deleted. remain unchanged, never added to or deleted.
Section 4.3 describes a Geolocation-Error header field to provide Section 4.3 describes a Geolocation-Error header field to provide
more detail about what was wrong with the location information in more detail about what was wrong with the location information in
the request. This header field MUST be included in the 424 response. the request. This header field MUST be included in the 424 response.
It is only appropriate to generate a 424 response when the It is only appropriate to generate a 424 response when the
responding entity needs a locationValue and there are no responding entity needs a locationValue and there are no
locationValues included in the SIP request that are usable by that locationValues included in the SIP request that are usable by that
recipient, or as shown in Figure 4 of section 3.4. In this scenario, recipient, or as shown in Figure 4 of section 3.4. In the latter
a SIP intermediary is informing the upstream UA which location to scenario, a SIP intermediary is informing the upstream UA which
include in the next SIP request. location to include in the next SIP request.
A 424 MUST NOT be sent in response to a request that lacks a A 424 MUST NOT be sent in response to a request that lacks a
Geolocation header entirely, as the user agent in that case may not Geolocation header entirely, as the user agent in that case may not
support this extension at all. If a SIP intermediary inserted a support this extension at all. If a SIP intermediary inserted a
locationValue into a SIP request where one was not previously locationValue into a SIP request where one was not previously
present, it MUST take any and all responsibility for the corrective present, it MUST take any and all responsibility for the corrective
action if it receives a 424 to a SIP request it sent. action if it receives a 424 to a SIP request it sent.
A 424 (Bad Location Information) response is a final response within A 424 (Bad Location Information) response is a final response within
a transaction, and MUST NOT terminate an existing dialog. a transaction, and MUST NOT terminate an existing dialog.
4.3 The Geolocation-Error Header 4.3 The Geolocation-Error Header
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 UA is to know what was wrong within the original request. if the location inserting entity is to know what was wrong within
The Geolocation-Error header field is used for this purpose. the original request. 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. The Geolocation-Error location-specific errors within a response. The Geolocation-Error
header field has the following ABNF [RFC5234]: header field has the following ABNF [RFC5234]:
Geolocation-Error = "Geolocation-Error" HCOLON Geolocation-Error = "Geolocation-Error" HCOLON
locationErrorValue locationErrorValue
locationErrorValue = location-error-arg locationErrorValue = location-error-code
location-error-arg = location-error-code
*(SEMI location-error-params) *(SEMI location-error-params)
location-error-code = 1*3DIGIT location-error-code = 1*3DIGIT
location-error-params = location-error-code-text location-error-params = location-error-code-text
/ generic-param ; from RFC3261 / generic-param ; from RFC3261
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261
The Geolocation-Error header field MUST contain only one The Geolocation-Error header field MUST contain only one
locationErrorValue to indicate what was wrong with the locationValue locationErrorValue to indicate what was wrong with the locationValue
the Location Recipient determined was bad. The locationErrorValue the Location Recipient determined was bad. The locationErrorValue
contains a 3-digit error code indicating what was wrong with the contains a 3-digit error code indicating what was wrong with the
location in the request. Each error code has a corresponding quoted location in the request. This error code has a corresponding quoted
error text string that is human understandable. This text string is error text string that is human understandable. This text string is
OPTIONAL, but RECOMMENDED for human readability. OPTIONAL, but RECOMMENDED for human readability.
The following table extends the values in Table 2&3 of RFC 3261
[RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Geolocation-Error r ar o - - o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Geolocation-Error r ar o o o o o o o
Table 2: Summary of the Geolocation-Error Header Field
The Geolocation-Error header field MAY be included in any response The Geolocation-Error header field MAY be included in any response
to one of the above SIP requests, so long as a Geolocation to one of the SIP Methods mentioned in Section 4.1, so long as a
locationValue was in the request part of the transaction. For locationValue was in the request part of the same transaction. For
example, Alice includes her location in an INVITE to Bob. Bob can example, Alice includes her location in an INVITE to Bob. Bob can
accept this INVITE, thus creating a dialog, even though his UA accept this INVITE, thus creating a dialog, even though his UA
determined the location contained in the INVITE was bad. Bob merely determined the location contained in the INVITE was bad. Bob merely
includes a Geolocation-Error header value in the 200 OK to the includes a Geolocation-Error header value in the 200 OK to the
INVITE informing Alice the INVITE was accepted but the location INVITE informing Alice the INVITE was accepted but the location
provided was bad. The SIP requests included in table 2 above are the provided was bad.
ones allowed to optionally contain the Geolocation header field (see
section 4.1).
If, on the other hand, Bob cannot accept Alice's INVITE without a If, on the other hand, Bob cannot accept Alice's INVITE without a
suitable location, a 424 (Bad Location Information) is sent. This suitable location, a 424 (Bad Location Information) is sent. This
message flow is shown in Figures 1, 2 or 3 in Section 3. message flow is shown in Figures 1, 2 or 3 in Sections 3.1, 3.2 and
3.3 respectively.
The following subsections provide an initial list of location A SIP intermediary that requires Alice's location in order to
based errors for any SIP non-100 response, including the new 424 properly process Alice's INVITE also sends a 424 with a
(Bad Location Information) response. These error codes are divided Geolocation-Error code. This message flow is shown in Figure 4 of
into 4 categories, based on how the response receiver should react Section 3.4.
to these errors.
If more than one locationValue is present in a SIP request and at
least one locationValue is determined to be valid by the LR, the
location in that SIP request MUST be considered good as far as
location is concerned, and no Geolocation-Error is sent. This is a
compromise of complexity vs. accurate information conveyance with
respect to informing each location inserter of every bad location.
Here is an initial list of location based error code ranges for any
SIP non-100 response, including the new 424 (Bad Location
Information) response. These error codes are divided into 3
categories, based on how the response receiver should react to these
errors. There MUST be no more than one Geolocation-Error code in a
SIP response, regardless of how many locationValues there are in the
correlating SIP request. There is no guidance given in this document
as to which locationValue, when more than one was present in the SIP
request, is related to the Geolocation-Error code; meaning that,
somehow not defined here, the LR just picks one to error.
o 1XX errors mean the LR cannot process the location within the o 1XX errors mean the LR cannot process the location within the
request. request
A non-exclusive list of reasons for returning a 1XX is
o 2XX errors mean the LR wants the LS to send new or updated - the location was not present or could not be found,
location information, perhaps with a delay associated with when - there was not enough location information to determine
to send the request. where the Target was,
- the location information was corrupted or known to be
inaccurate,
- etc...
o 3XX errors mean some specific permission is necessary to process o 2XX errors mean some specific permission is necessary to process
the included location information. the included location information.
o 4XX errors mean there was trouble dereferencing the Location URI o 3XX errors mean there was trouble dereferencing the Location URI
sent. sent.
Within these 4 number ranges, there is a top level error as follows: It should be noted that for non-INVITE transactions, the SIP
response will likely be sent before the dereference response has
been received. At this time, this document does not alter that SIP
protocol reality. This means the receiver of any non-INVITE response
to a request containing location SHOULD NOT consider a 200 OK to
mean the act of dereferencing has concluded and the dereferencer
(i.e., the LR) has successfully received and parsed the PIDF-LO for
errors and found none. This was first brought up in Section 3.2.
Geolocation-Error: 100 "Cannot Process Location" Additionally, if a SIP entity cannot or chooses not to process
location or the SIP request containing location, the existing
mechanism of responding with a 503 (Service Unavailable) SHOULD be
used with or without a configurable Retry-After header field. There
is no special location error code for what already exists within SIP
today.
Geolocation-Error: 200 "Retry Location Later with device updated Within each of these ranges, there is a top level error as follows:
location"
Geolocation-Error: 300 "Permission To Use Location Information" Geolocation-Error: 100 "Cannot Process Location"
Geolocation-Error: 400 "Dereference Failure" Geolocation-Error: 200 "Permission To Use Location Information"
Geolocation-Error: 300 "Dereference Failure"
There are two specific Geolocation-Error codes necessary to include There are two specific Geolocation-Error codes necessary to include
in this document, both have to do with permissions necessary to in this document, both have to do with permissions necessary to
process the SIP request; they are process the SIP request; they are
Geolocation-Error: 301 "Permission To Retransmit Location Geolocation-Error: 201 "Permission To Retransmit Location
Information to a Third Party" Information to a Third Party"
This location error is specific to having the Presence Information This location error is specific to having the Presence Information
Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set
to "=no". This location error is stating it requires permission to "=no". This location error is stating it requires permission
(i.e., PIDF-LO <retransmission-allowed> element set to "=yes") to (i.e., PIDF-LO <retransmission-allowed> element set to "=yes") to
process this SIP request further. If the LS sending the location process this SIP request further. If the LS sending the location
information does not want to give this permission, it will not reset information does not want to give this permission, it will not reset
this permission in a new request. If the LS wants this message this permission in a new request. If the LS wants this message
processed without this permission reset, it MUST choose another processed without this permission reset, it MUST choose another
logical path (if one exists). logical path (if one exists) for this SIP request.
Geolocation-Error: 302 "Permission to Route based on Location Geolocation-Error: 202 "Permission to Route based on Location
Information" Information"
This location error is specific to having the locationValue header This location error is specific to having the locationValue header
parameter <routing-allowed> set to "=no". This location error is parameter <routing-allowed> set to "=no". This location error is
stating it requires permission (i.e., a <routing-allowed> set to stating it requires permission (i.e., a <routing-allowed> set to
"=yes") to process this SIP request further. If the LS sending the "=yes") to process this SIP request further. If the LS sending the
location information does not want to give this permission, it will location information does not want to give this permission, it will
not reset this permission in a new request. If the LS wants this not reset this permission in a new request. If the LS wants this
message processed without this permission reset, it MUST choose message processed without this permission reset, it MUST choose
another logical path (if one exists). another logical path (if one exists) for this SIP request.
4.4 The 'geolocation' Option Tag
This document creates and registers with the IANA one new option
tag: "geolocation". This option tag is to be used, as defined in
[RFC3261], in the Require, Supported and Unsupported header fields.
4.5 Location URIs in Message Bodies 4.4 Location URIs in Message Bodies
In the case where a location recipient sends a 424 response and In the case where an LR sends a 424 response and wishes to
wishes to communicate suitable location by reference rather than by communicate suitable location by reference rather than by value, the
value, the 424 MUST include a content-indirection body per RFC 4483. 424 MUST include a content-indirection body per RFC 4483.
4.6 Location URIs Allowed 4.5 Location Profile Negotiation
The following is part of the discussion started in Section 3, Figure The following is part of the discussion started in Section 3, Figure
2, which introduced the concept of sending location indirectly. 2, which introduced the concept of sending location indirectly.
If a location URI is included in a SIP request, it SHOULD be a SIP-, If a location URI is included in a SIP request, the sending user
SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if agent MUST also include a Supported header field indicating which
the resulting resolution resolves to a SIP: or SIPS: URI, this location profiles it supports. Two option tags for location profiles
section applies. These schemes MUST be implemented according to are defined by this document: "geolocation-sip" and
this document. "geolocation-http". Future specifications may define further
location profiles per the IANA policy described in Section 8.2.
See [ID-GEO-FILTERS] for more details on dereferencing location. The "geolocation-sip" option tag signals support for acquiring
location information via the presence event package of SIP
([RFC3856]). A location recipient who supports this option can send
a SUBSCRIBE request and parse a resulting NOTIFY containing a
PIDF-LO object. The URI schemes supported by this option include
"sip", "sips" and "pres".
An HTTP: [RFC2616] or HTTPS: URI [RFC2818] are also allowed, and The "geolocation-http" option tag signals support for acquiring
SHOULD be dereferenced according to [ID-HELD-DEREF]. location information via an HTTP ([RFC2616]). A location recipient
who supports this option can request location with an HTTP GET and
parse a resulting 200 response containing a PIDF-LO object. The URI
schemes supported by this option include "http" and "https". A
failure to parse the 200 response, for whatever reason, will return
a "Dereference Failure" indication to the original location sending
user agent to inform it that location was not delivered as intended.
See [ID-GEO-FILTERS] or [ID-HELD-DEREF] for more details on
dereferencing location information.
5. Geolocation Examples 5. Geolocation Examples
5.1 Location-by-value (in Coordinate Format) 5.1 Location-by-value (in Coordinate Format)
This example shows an INVITE message with a coordinate location. In This example shows an INVITE message with a coordinate location. In
this example, the SIP request uses a sips-URI [RFC3261], meaning this example, the SIP request uses a sips-URI [RFC3261], meaning
this message is protected using TLS on a hop-by-hop basis. this message is protected using TLS on a hop-by-hop basis.
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
skipping to change at page 16, line 4 skipping to change at page 16, line 21
<gbp:retention-expiry>2010-11-14T20:00:00Z <gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry> </gbp:retention-expiry>
</gp:usage-rules> </gp:usage-rules>
<gp:method>802.11</gp:method> <gp:method>802.11</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
--boundary1-- --boundary1--
The Geolocation header field from the above INVITE: The Geolocation header field from the above INVITE:
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <cid:target123@atlanta.example.com>
... indicates the content-ID location [RFC2392] within the multipart ... indicates the content-ID location [RFC2392] within the multipart
message body of where location information is. An assumption can be message body of where location information is. The other message
made that SDP is the other message body part. The "cid:" eases body part is SDP. The "cid:" eases message body parsing and
message body parsing by disambiguating the MIME body that contains disambiguates multiple parts of the same type.
the location information associated with this request.
If the Geolocation header field did not contain a "cid:" scheme, for If the Geolocation header field did not contain a "cid:" scheme, for
example, it could look like this location URI: example, it could look like this location URI:
Geolocation: <sips:target123@server5.atlanta.example.com> Geolocation: <sips:target123@server5.atlanta.example.com>
... the existence of a non-"cid:" scheme indicates this is a ... the existence of a non-"cid:" scheme indicates this is a
location URI, to be dereferenced to learn the Target's location. Any location URI, to be dereferenced to learn the Target's location. Any
node wanting to know where user "target123" is would subscribe to node wanting to know where the target is located would subscribe to
that user at server5 to dereference the sips-URI (see Figure 3 in the SIP presence event package [RFC3856] at
section 3 for this message flow).
sips:target123@server5.atlanta.example.com
(see Figure 2 in Section 3.2 for this message flow).
5.2 Two Locations Composed in Same Location Object Example 5.2 Two Locations Composed in Same Location Object Example
This example shows the INVITE message after a SIP intermediary This example shows the INVITE message after a SIP intermediary
rejected the original INVITE (say, the one in section 5.1). This rejected the original INVITE (say, the one in section 5.1). This
INVITE contains the composed LO sent by the SIP intermediary which INVITE contains the composed LO sent by the SIP intermediary which
includes where the intermediary understands Alice to be. The rules includes where the intermediary understands Alice to be. The rules
of RFC 5491 [RFC5491] are followed in this construction. of RFC 5491 [RFC5491] are followed in this construction.
This example is here, but should not be taken as occurring very This example is here, but should not be taken as occurring very
skipping to change at page 17, line 31 skipping to change at page 17, line 52
<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>32.86726 -97.16054</gml:pos> <gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point> </gml:Point>
</gml:location> </gml:location>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gbp:retransmission-allowed>false <gbp:retransmission-allowed>false
</gbp:retransmission-allowed> </gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z <gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry> </gbp:retention-expiry>
</gp:usage-rules> </gp:usage-rules>
<gp:method>802.11</gp:method> <gp:method>802.11</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
<dm:person id="target123"> <dm:person id="target123">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<cl:civicAddress> <cl:civicAddress>
<cl:country>US</cl:country> <cl:country>US</cl:country>
<cl:A1>Texas</cl:A1> <cl:A1>Texas</cl:A1>
skipping to change at page 18, line 26 skipping to change at page 18, line 47
6. Geopriv Privacy Considerations 6. Geopriv Privacy Considerations
Location information is considered by most to be highly sensitive Location information is considered by most to be highly sensitive
information, requiring protection from eavesdropping and altering in information, requiring protection from eavesdropping and altering in
transit. [RFC3693] originally articulated rules to be followed by transit. [RFC3693] originally articulated rules to be followed by
any protocol wishing to be considered a "Using Protocol", specifying any protocol wishing to be considered a "Using Protocol", specifying
how a transport protocol meets those rules. [ID-GEOPRIV-ARCH] how a transport protocol meets those rules. [ID-GEOPRIV-ARCH]
updates the guidance in RFC3693 to include subsequently-introduced updates the guidance in RFC3693 to include subsequently-introduced
entities and concepts in the geolocation architecture. entities and concepts in the geolocation architecture.
Implementations of this SIP location conveyance mechanism MUST Implementations of this SIP location conveyance mechanism MUST
adhere to the guidance given in RFC3693 and its successors, adhere to the guidance given in RFC3693 and its updates and/or
including (but not limited to) the handling of rules for retention successors, including (but not limited to) the handling of rules for
and retransmission. retention and retransmission.
7. Security Considerations 7. Security Considerations
Conveyance of physical location of a UA raises privacy concerns, Conveyance of physical location of a UA raises privacy concerns,
and depending on use, there probably will be authentication and and depending on use, there probably will be authentication and
integrity concerns. This document calls for conveyance to integrity concerns. This document calls for conveyance to
be accomplished through secure mechanisms, like S/MIME encrypting be accomplished through secure mechanisms, like S/MIME encrypting
message bodies (although this is not widely deployed), TLS message bodies (although this is not widely deployed), TLS
protecting the overall signaling or conveyance location by-reference protecting the overall signaling or conveyance location by-reference
and requiring all entities that dereference location to authenticate and requiring all entities that dereference location to authenticate
skipping to change at page 19, line 53 skipping to change at page 20, line 20
There is no end-to-end integrity on any locationValue or There is no end-to-end integrity on any locationValue or
locationErrorValue header field parameter (or middle-to-end if the locationErrorValue header field parameter (or middle-to-end if the
value was inserted by a intermediary), so recipients of either value was inserted by a intermediary), so recipients of either
header field need to implicitly trust the header field contents, and header field need to implicitly trust the header field contents, and
take whatever precautions each entity deems appropriate given this take whatever precautions each entity deems appropriate given this
situation. situation.
8. IANA Considerations 8. IANA Considerations
The following are the IANA considerations made by this SIP The following are the IANA considerations made by this SIP
extension. Modifications and additions to these registrations extension. Modifications and additions to all these registrations
require a standards track RFC (Standards Action). require a standards track RFC (Standards Action).
[Editor's Note: RFC-Editor - within the IANA section, please [Editor's Note: RFC-Editor - within the IANA section, please
replace "this doc" with the assigned RFC number, replace "this doc" with the assigned RFC number,
if this document reaches publication.] if this document reaches publication.]
8.1 IANA Registration for the SIP Geolocation Header Field 8.1 IANA Registration for the SIP Geolocation Header Field
The SIP Geolocation Header Field is created by this document, with The SIP Geolocation Header Field is created by this document, with
its definition and rules in Section 4.1 of this document, and should its definition and rules in Section 4.1 of this document, and should
be added to the IANA sip-parameters registry, in the portion titled be added to the IANA sip-parameters registry with two actions
"Header Field Parameters and Parameter Values".
1. Update the Header Fields registry with
Registry:
Header Name compact Reference
----------------- ------- ---------
Geolocation [this doc]
2. In the portion titled "Header Field Parameters and Parameter
Values", add
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------- ------------------- ---------- --------- ---------------- ------------------- ---------- ---------
Geolocation routing-allowed yes [this doc] Geolocation routing-allowed yes [this doc]
8.2 IANA Registration for New SIP 'geolocation' Option Tag 8.2 IANA Registration for Location Profiles
The SIP option tag "geolocation" is created by this document, with This document defines two new SIP option tags: "geolocation-sip" and
the definition and rule in Section 4.4 of this document, to be added "geolocation-http." with the definition and rule in Section 4.5 of
to the IANA sip-parameters registry. this document, to be added to the IANA sip-parameters Options Tags
registry.
Name Valid Scheme(S) Reference
geolocation-sip See 4.5 [this doc]
geolocation-http See 4.5 [this doc]
The names of profiles are SIP option-tags, and the guidance in this
document does not supersede the option-tag assignment guidance in
[RFC3261] (which requires a Standards Action for the assignment of a
new option tag). This document does however stipulate that
option-tags included to convey the name of a location profile per
this definition MUST begin with the string "geolocation" followed by
a dash. All such option tags should describe protocols used to
acquire location by reference: these tags have no relevance to
location carried in SIP requests by value, which use standard MIME
typing and negotiation.
8.3 IANA Registration for 424 Response Code 8.3 IANA Registration for 424 Response Code
In the SIP Response Codes registry, the following is added
Reference: RFC-XXXX (i.e., this document) Reference: RFC-XXXX (i.e., this document)
Response code: 424 (recommended number to assign) Response code: 424 (recommended number to assign)
Default reason phrase: Bad Location Information Default reason phrase: Bad Location Information
Registry:
Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
424 Bad Location Information [this doc]
This SIP Response code is defined in section 4.2 of this document. This SIP Response code is defined in section 4.2 of this document.
8.4 IANA Registration of New Geolocation-Error Header Field 8.4 IANA Registration of New Geolocation-Error Header Field
The SIP Geolocation-error header field is created by this document, The SIP Geolocation-error header field is created by this document,
with its definition and rules in Section 4.3 of this document, to be with its definition and rules in Section 4.3 of this document, to be
added to the IANA sip-parameters registry, in the portion titled added to the IANA sip-parameters registry with two actions
"Header Field Parameters and Parameter Values".
1. Update the Header Fields registry with
Registry:
Header Name compact Reference
----------------- ------- ---------
Geolocation-Error [this doc]
2. In the portion titled "Header Field Parameters and Parameter
Values", add
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
----------------- ------------------- ---------- --------- ----------------- ------------------- ---------- ---------
Geolocation-Error code= yes* [this doc] Geolocation-Error code= yes* [this doc]
* see section 8.5 for the newly created values. * see section 8.5 for the newly created values.
8.5 IANA Registration for the SIP Geolocation-Error Codes 8.5 IANA Registration for the SIP Geolocation-Error Codes
skipping to change at page 21, line 17 skipping to change at page 22, line 32
Geolocation-Error codes Geolocation-Error codes
----------------------- -----------------------
Geolocation-Error codes provide reason for the error discovered by Geolocation-Error codes provide reason for the error discovered by
Location Recipients, categorized by action to be taken by error Location Recipients, categorized by action to be taken by error
recipient. recipient.
Code Description Reference Code Description Reference
---- --------------------------------------------------- --------- ---- --------------------------------------------------- ---------
100 "Cannot Process Location" [this doc] 100 "Cannot Process Location" [this doc]
200 "Retry Location Later with device updated location" [this doc] 200 "Permission To Use Location Information" [this doc]
300 "Permission To Use Location Information" [this doc]
301 "Permission To Retransmit Location Information to a Third Party" 201 "Permission To Retransmit Location Information to a Third Party"
[this doc] [this doc]
302 "Permission to Route based on Location Information" [this doc] 202 "Permission to Route based on Location Information" [this doc]
400 "Dereference Failure" [this doc]
8.6 IANA Registration of Location URI Schemes
This document directs IANA to create a new set of parameters in a
separate location from SIP and Geopriv, called the "Location
Reference URI" registry, containing the URI scheme, the
Content-Type, and the reference, as follows:
URI Scheme Content-Type Reference
---------- ------------ ---------
SIP: [this doc]
SIPS: [this doc]
PRES: [this doc]
HTTP: [this doc]
HTTPS: [this doc]
Additions to this registry must be defined in a permanent and 300 "Dereference Failure" [this doc]
readily available specification (this is the "Specification
Required" IANA policy defined in [RFC5226]).
9. Acknowledgements 9. Acknowledgements
To Dave Oran for helping to shape this idea. To Dave Oran for helping to shape this idea.
To Dean Willis for guidance of the effort. To Dean Willis for guidance of the effort.
To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning
Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois
Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson,
skipping to change at page 22, line 31 skipping to change at page 23, line 26
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002. Session Initiation Protocol", RFC 3261, May 2002.
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005 Format", RFC 4119, December 2005
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997 Requirement Levels", RFC 2119, March 1997
[RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource [RFC2392] E. Levinson, "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998 Locators", RFC 2392, August 1998
[RFC3856] J. Rosenberg, " A Presence Event Package for the Session [RFC3856] J. Rosenberg, "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004 Initiation Protocol (SIP)", RFC 3856, August 2004
[RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859,
August 2004 August 2004
[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging" , RFC 3428, December 2002 Instant Messaging" , RFC 3428, December 2002
[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
skipping to change at page 23, line 54 skipping to change at page 24, line 48
"Geopriv Requirements", RFC 3693, February 2004 "Geopriv Requirements", RFC 3693, February 2004
[RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000 [RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000
[ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location
Notifications in SIP", draft-ietf-geopriv-loc-filters, "work Notifications in SIP", draft-ietf-geopriv-loc-filters, "work
in progress", March 2010 in progress", March 2010
[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.
Thomson, M. Dawson, "A Location Dereferencing Protocol Using Thomson, M. Dawson, "A Location Dereferencing Protocol Using
HELD", "work in progress", September 2010 HELD", "work in progress", December 2010
[ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. [ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H.
Tschofenig, H. Schulzrinne, "An Architecture for Location Tschofenig, H. Schulzrinne, "An Architecture for Location
and Location Privacy in Internet Applications", and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch, "work in progress", October 2010 draft-ietf-geopriv-arch, "work in progress", October 2010
Author Addresses Author Addresses
James Polk James Polk
Cisco Systems Cisco Systems
skipping to change at page 26, line 4 skipping to change at page 26, line 48
Motivation: Failure to receive location when it is expected can Motivation: Failure to receive location when it is expected can
happen because the UAC does not implement this extension, or happen because the UAC does not implement this extension, or
because the UAC implements the extension, but does not know because the UAC implements the extension, but does not know
where the Target is. This may be, for example, due to the where the Target is. This may be, for example, due to the
failure of the access network to provide a location failure of the access network to provide a location
acquisition mechanism the UAC supports. These cases must be acquisition mechanism the UAC supports. These cases must be
differentiated. differentiated.
UAC-11 It must be possible to convey location to proxy servers UAC-11 It must be possible to convey location to proxy servers
along the path. along the path.
Motivation: Location-based routing. Motivation: Location-based routing.
A.2 Requirements for a UAS Receiving Location A.2 Requirements for a UAS Receiving Location
The following are the requirements for location conveyance by a UAS: The following are the requirements for location conveyance by a UAS:
UAS-1 SIP Responses must support location conveyance. UAS-1 SIP Responses must support location conveyance.
Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG,
due to the many problems this requirement would have caused due to the many problems this requirement would have caused
if implemented. The solution is for the above UAS to send a if implemented. The solution is for the above UAS to send a
new request to the original UAC with the UAS's location. new request to the original UAC with the UAS's location.
UAS-2 There must be a unique 4XX response informing the UAC it did UAS-2 There must be a unique 4XX response informing the UAC it did
 End of changes. 76 change blocks. 
207 lines changed or deleted 248 lines changed or added

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