draft-ietf-sipcore-location-conveyance-05.txt   draft-ietf-sipcore-location-conveyance-06.txt 
Network Working Group James Polk Network Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expires: September 8, 2011 Brian Rosen Expires: August 23, 2011 Brian Rosen
Intended Status: Standards Track (PS) Jon Peterson Intended Status: Standards Track (PS) Jon Peterson
NeuStar NeuStar
Feb 8, 2011 Feb 23, 2011
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sipcore-location-conveyance-05.txt draft-ietf-sipcore-location-conveyance-06.txt
Abstract Abstract
This document defines an extension to the Session Initiation This document defines an extension to the Session Initiation
Protocol (SIP) to convey geographic location information from one Protocol (SIP) to convey geographic location information from one
SIP entity to another SIP entity. The SIP extension covers SIP entity to another SIP entity. The SIP extension covers
end-to-end conveyance as well as location-based routing, where SIP end-to-end conveyance as well as location-based routing, where SIP
intermediaries make routing decisions based upon the location of the intermediaries make routing decisions based upon the location of the
Location Target. Location Target.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2011. This Internet-Draft will expire on August 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
than English. than English.
Table of Contents Table of Contents
1. Conventions and Terminology used in this document . . . . . . 3 1. Conventions and Terminology used in this document . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4
3.1 Location Conveyed by Value . . . . . . . . . . . . . . . 4 3.1 Location Conveyed by Value . . . . . . . . . . . . . . . 4
3.2 Location Conveyed as a Location URI . . . . . . . . . . . 4 3.2 Location Conveyed as a Location URI . . . . . . . . . . . 4
3.3 Location Conveyed though a SIP Intermediary . . . . . . . 5 3.3 Location Conveyed though a SIP Intermediary . . . . . . . 5
3.4 SIP Intermediary Replacing Bad Location . . . . . . . . . 6 3.4 SIP Intermediary Replacing Bad Location . . . . . . . . . 7
4. SIP Modifications for Geolocation Conveyance . . . . . . . . 8 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 8
4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 8 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 8
4.2 424 (Bad Location Information) Response Code . . . . . . 10 4.2 The Geolocation-Routing Header . . . . . . . . . . . . . 10
4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11 4.2.1 Explaining Geolocation-Routing header-value States . . 11
4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 14 4.3 424 (Bad Location Information) Response Code . . . . . . 12
4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 14 4.4 The Geolocation-Error Header . . . . . . . . . . . . . . 13
4.6 Location URIs Allowed . . . . . . . . . . . . . . . . . . 14 4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 16
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 14 4.6 Location Profile Negotiation . . . . . . . . . . . . . . 16
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 14 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 17
5.2 Two Locations Composed in Same Location Object Example . 16 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 17
6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 18 5.2 Two Locations Composed in Same Location Object Example . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1 IANA Registration for New SIP Geolocation Header . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
8.2 IANA Registration for New SIP 'geolocation' Option Tag . 20 8.1 IANA Registration for New SIP Geolocation Header . . . . 22
8.3 IANA Registration for New 424 Response Code . . . . . . . 20 8.2 IANA Registration for New SIP Geolocation-Routing Header 22
8.4 IANA Registration for New SIP Geolocation-Error Header . 20 8.3 IANA Registration for New SIP Option Tags . . . . . . . . 23
8.5 IANA Registration for New SIP Geolocation-Error Codes . . 20 8.4 IANA Registration for New 424 Response Code . . . . . . . 23
8.6 IANA Registration of Location URI Schemes . . . . . . . . 21 8.5 IANA Registration for New SIP Geolocation-Error Header . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8.6 IANA Registration for New SIP Geolocation-Error Codes . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
10.1 Normative References . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.2 Informative References . . . . . . . . . . . . . . . . . 23 10.1 Normative References . . . . . . . . . . . . . . . . . 25
Author Information . . . . . . . . . . . . . . . . . . . . . 24 10.2 Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Requirements for SIP Location Conveyance . . . . 24 Author Information . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Requirements for SIP Location Conveyance . . . . 27
1. Conventions and Terminology used in this document 1. Conventions and Terminology used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. This document furthermore uses numerous terms defined in [RFC2119]. This document furthermore uses numerous terms defined
in RFC 3693 [RFC3693], including Location Object, Location in RFC 3693 [RFC3693], including Location Object, Location
Recipient, Location Server, Target, and Using Protocol. Recipient, Location Server, Target, and Using Protocol.
skipping to change at page 8, line 18 skipping to change at page 8, line 20
intermediary. Most likely, the SIP intermediary would in that intermediary. Most likely, the SIP intermediary would in that
scenario act as a B2BUA and insert into the request by-value any scenario act as a B2BUA and insert into the request by-value any
appropriate location information for the benefit of Public Safety appropriate location information for the benefit of Public Safety
Answering Point (PSAP) call centers to expedite call reception by Answering Point (PSAP) call centers to expedite call reception by
the emergency services personnel; thereby, minimizing any delay in the emergency services personnel; thereby, minimizing any delay in
call establishment time. The implementation of these specialized call establishment time. The implementation of these specialized
deployments is, however, outside the scope of this document. deployments is, however, outside the scope of this document.
4. SIP Modifications for Geolocation Conveyance 4. SIP Modifications for Geolocation Conveyance
The following sections detail the modifications The following sections detail the modifications to SIP for location
to SIP for location conveyance. conveyance.
4.1 The Geolocation Header 4.1 The Geolocation Header
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-header = "Geolocation" HCOLON Geolocation-value message-header /= Geolocation-header ; (message-header from 3261)
Geolocation-value = ( locationValue [ COMMA locationValue ] ) Geolocation-header = "Geolocation" HCOLON locationValue
/ routing-param *( COMMA locationValue )
locationValue = LAQUOT locationURI RAQUOT locationValue = LAQUOT locationURI RAQUOT
*(SEMI geoloc-param) *(SEMI geoloc-param)
locationURI = sip-URI / sips-URI / pres-URI locationURI = sip-URI / sips-URI / pres-URI
/ http-URI / HTTPS-URI / http-URI / HTTPS-URI
/ cid-url ; (from RFC 2392) / cid-url ; (from RFC 2392)
/ absoluteURI ; (from RFC 3261) / absoluteURI ; (from RFC 3261)
geoloc-param = generic-param; (from RFC 3261) geoloc-param = generic-param; (from RFC 3261)
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].
HTTP-URI and HTTPS-URI are defined according to [RFC2616] and HTTP-URI and HTTPS-URI are defined according to [RFC2616] and
[RFC2818], respectively. [RFC2818], respectively.
The cid-url is defined in [RFC2392] to locate message body parts. The cid-url is defined in [RFC2392] to locate message body parts.
This URI type is present in a SIP request when location is conveyed This URI type is present in a SIP request when location is conveyed
as a MIME body in the SIP message. as a MIME body in the SIP message.
GEO-URIs [RFC5870] are not appropriate for usage in the SIP GEO-URIs [RFC5870] are not appropriate for usage in the SIP
Geolocation header. Geolocation header.
Other URI schemas used in the location URI MUST be reviewed against Other URI schemas used in the location URI MUST be reviewed against
the RFC 3693 [RFC3693] criteria for a Using Protocol. the RFC 3693 [RFC3693] criteria for a Using Protocol.
The Geolocation header field can have zero or more locationValues. A The generic-param in the definition of locationValue is included as
a mechanism for future extensions that might require parameters.
This document defines no parameters for use with locationValue. If a
Geolocation header field is received that contains generic-params,
each SHOULD be ignored, and SHOULD NOT be removed when forwarding
the locationValue. If a need arises to define parameters for use
with locationValue, a revision/extension to this document is
required.
The Geolocation header field can have one or more locationValues. A
Geolocation header field MUST have at least one header-value. A
SIP intermediary SHOULD NOT add location to a SIP request that SIP intermediary SHOULD NOT add location to a SIP request that
already contains location. This will quite often lead to confusion already contains location. This will quite often lead to confusion
within LRs. However, if a SIP intermediary were to add location, within LRs. However, if a SIP intermediary adds 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 Additionally, the first SIP intermediary to add a locationValue adds
locationValue adds it as the last locationValue in the header value. it as the last locationValue in the header value. A SIP intermediary
The next SIP intermediary to add a locationValue adds it as the last that adds a locationValue MUST position it as the last locationValue
locationValue in the header value - and so on. of the last Geolocation header field of the message.
The placement of the "routing-allowed" header field parameter,
strongly encouraged by [RFC5606], is outside the locationValue, and
MUST always be last in the header field value. The routing-allowed
parameter MUST be present, even 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". When this parameter is "=yes", the
locationValue can be used for routing decisions along the downstream
signaling path by intermediaries. If no routing-allowed parameter
is present in a SIP request, a SIP intermediary MAY insert this
value with a RECOMMENDED value of "no" by default.
When this parameter is "=no", this means no locationValue (inserted
by the originating UAC or any intermediary along the signaling path)
can be used by any SIP intermediary to make routing decisions.
Intermediaries that attempt to use the location information for
routing purposes in spite of this counter indication may end up
routing the request improperly as a result. Sections 4.3 describes
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
message further. The practical implication is that when the
"routing-allowed" parameter is set to "no", if a cid:url is present
in the SIP request, intermediaries MUST NOT view the location
(because it is not for intermediaries to view), and if a location
URI is present, intermediaries MUST NOT dereference it. UAs are
allowed to view location in the SIP request even when the
"routing-allowed" parameter is set to "no". An LR MUST by default
consider the "routing-allowed" header parameter as set to "no", with
no exceptions, unless the header field value is set to "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 Geolocation header field MAY be included in any one of the The Geolocation header field MAY be included in any one of the
above listed requests by a UA, and a 424 response to any one of the above listed requests by a UA, and a 424 response to any one of the
requests sent above. Fully appreciating the caveats/warnings requests sent above. Fully appreciating the caveats/warnings
mentioned above, a SIP intermediary MAY add the Geolocation header mentioned above, a SIP intermediary MAY add the Geolocation header
field, but MUST NOT modify any pre-existing locationValue, or any field.
"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 the
location, or any of a number of other use cases (see Section 3). Target's location, or any of a number of other use cases (see
When adding a Geolocation header value, a SIP intermediary MAY Section 3).
supply a "routing-allowed" parameter only if not yet present in the
SIP request. The Geolocation header field MAY be present in a SIP request or
response without the presence of a Geolocation-Routing header
(defined in Section 4.2). As stated in Section 4.2, the default
value of Geolocation-Routing header-value is "no", meaning SIP
intermediaries are not to view any direct or indirect location
within this SIP message.
Any locationValue MUST be related to the original Target. This is
equally true the location information in a SIP response, i.e., from
a SIP intermediary back to the Target explained in Section 3.4.
SIP intermediaries are NOT RECOMMENDED to modify existing
locationValue(s), and further not to delete any either.
4.2 The Geolocation-Routing Header
This document defines "Geolocation-Routing" as a new SIP header
field registered by IANA, with the following ABNF [RFC5234]:
message-header /= Georouting-header ; (message-header from 3261)
Georouting-header = "Geolocation-Routing" HCOLON
( "yes" / "no" / generic-value )
The only defined values for the Geolocation-Routing header field are
"yes" or "no". When the value is "yes", the locationValue can be
used for routing decisions along the downstream signaling path by
intermediaries. Values other than "yes" or "no" are permitted as a
mechanism for future extensions, and should be treated the same as
"no".
If no Geolocation-Routing header field is present in a SIP request,
a SIP intermediary MAY insert this header field with a RECOMMENDED
value of "no" by default.
When this Geolocation-Routing header-value is set to "no", this
means no locationValue (inserted by the originating UAC or any
intermediary along the signaling path) can be used by any SIP
intermediary to make routing decisions. Intermediaries that attempt
to use the location information for routing purposes in spite of
this counter indication could end up routing the request improperly
as a result. Section 4.4 describes the details on what a routing
intermediary does if it determines it needs to use the location in
the SIP request in order to process the message further. The
practical implication is that when the Geolocation-Routing
header-value is set to "no", if a cid:url is present in the SIP
request, intermediaries SHOULD NOT view the location (because it is
not for intermediaries to view), and if a location URI is present,
intermediaries SHOULD NOT dereference it. UAs are allowed to view
location in the SIP request even when the Geolocation-Routing
header-value is set to "no". An LR MUST by default consider the
Geolocation-Routing header-value as set to "no", with no exceptions,
unless the header field value is set to "yes".
A Geolocation-Routing header-value is set to "no" has no special
security properties, this is at most a request for behavior within
SIP intermediaries. That said, if the Geolocation-Routing
header-value is set to "no", SIP intermediaries are still to
process the SIP request and send it further downstream within the
signaling path if there are no errors present in this SIP request.
The Geolocation-Routing header field satisfies the recommendations
made in section 3.5 of RFC 5606 [RFC5606] regarding indication of
permission to use location-based routing in SIP.
SIP implementations are advised to pay special attention to the SIP implementations are advised to pay special attention to the
policy elements for location retransmission and retention described policy elements for location retransmission and retention described
in RFC 4119. in RFC 4119.
4.2 424 (Bad Location Information) Response Code The Geolocation-Routing header field cannot appear without a
header-value in a SIP request or response (i.e., a null value is not
allowed). The absence of a Geolocation-Routing header-value in a SIP
request is always the same as the following header field:
Geolocation-Routing: no
The Geolocation-Routing header field MAY be present without a
Geolocation header field in the same SIP request. This concept is
further explored in Section 4.2.1.
4.2.1 Explaining Geolocation-Routing header-value States
The Geolocation header field contains a Target's location, and MUST
NOT be present if there is no location information in this SIP
request. The location information is contained in a one or more
locationValues. These locationValues MAY be contained in a single
Geolocation header field, or distributed among multiple Geolocation
header fields. (See section 7.3.1 of RFC3261.)
The Geolocation-Routing header field indicates whether or not SIP
intermediaries can view and then route this SIP request based on the
included (directly or indirectly) location information. The
Geolocation-Routing header field MUST NOT appear more than once in
any SIP request, and MUST NOT lack a header-value. The default or
implied policy of a SIP request that does not have a
Geolocation-Routing header field is the same as if one were present
and the header-value were set to "no".
There are only 3 possible states regarding the Geolocation-Routing
header field
- "no"
- "yes"
- no header-field present in this SIP request
The expected results in each state are:
If the Geolocation-Routing Only possible interpretations:
-------------------------- -----------------------------
"no" Location viewing policy set already
such that no intermediaries can view
location inserted downstream.
SIP intermediaries inserting a
locationValue into a Geolocation
header field (whether adding to an
existing header-value or inserting the
Geolocation header field for the first
time) MUST NOT modify or delete the
received "no" header-value.
"yes" Location viewing policy set already
such that if location is inserted
downstream, intermediaries can
maintain an open viewing of location
policy or can change policy to "no"
for intermediaries further downstream.
Geolocation-Routing absent If a Geolocation header field exists
(meaning a locationValue is already
present), MUST interpret the lack of a
Geolocation-Routing header field by
default as if there were one present
and the header-value is set to "no".
If there is no Geolocation header
field in this SIP request, the default
Geolocation-Routing is open and can be
set by a downstream entity or not at
all.
4.3 424 (Bad Location Information) Response Code
This SIP extension creates a new location-specific response code, This SIP extension creates a new location-specific response code,
defined as follows, defined as follows,
424 (Bad Location Information) 424 (Bad Location Information)
The 424 (Bad Location Information) response code is a rejection of The 424 (Bad Location Information) response code is a rejection of
the request due to its location contents, indicating location the request due to its location contents, indicating location
information that was malformed or not satisfactory for the information that was malformed or not satisfactory for the
recipient's purpose, or could not be dereferenced. recipient's purpose, or could not be dereferenced.
skipping to change at page 11, line 15 skipping to change at page 13, line 27
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. Geolocation between the 424 response generator and the original UAC. Geolocation
and Geolocation-Error header fields and PIDF-LO body parts MUST and Geolocation-Error header fields and PIDF-LO body parts 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.4 describes a Geolocation-Error header field to provide
more detail about what was wrong with the location information in more detail about what was wrong with the location information in
the request. This header field MUST be included in the 424 response. the request. This header field MUST be included in the 424 response.
It is only appropriate to generate a 424 response when the It is only appropriate to generate a 424 response when the
responding entity needs a locationValue and there are no responding entity needs a locationValue and there are no
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 the latter recipient, or as shown in Figure 4 of section 3.4. In the latter
scenario, a SIP intermediary is informing the upstream UA which scenario, a SIP intermediary is informing the upstream UA which
location to 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.4 The Geolocation-Error Header
As discussed in Section 4.2, more granular error notifications As discussed in Section 4.3, more granular error notifications
specific to location errors within a received request are required specific to location errors within a received request are required
if the location inserting entity is to know what was wrong within if the location inserting entity is to know what was wrong within
the original request. The Geolocation-Error header field is used for the original request. The Geolocation-Error header field is used for
this purpose. this purpose.
The Geolocation-Error header field is used to convey The Geolocation-Error header field is used to convey
location-specific errors within a response. The Geolocation-Error location-specific errors within a response. The Geolocation-Error
header field has the following ABNF [RFC5234]: header field has the following ABNF [RFC5234]:
message-header /= Geolocation-Error-header ;
(message-header from 3261)
Geolocation-Error = "Geolocation-Error" HCOLON Geolocation-Error = "Geolocation-Error" HCOLON
locationErrorValue locationErrorValue
locationErrorValue = location-error-code locationErrorValue = location-error-code
*(SEMI location-error-params) *(SEMI location-error-params)
location-error-code = 1*3DIGIT location-error-code = 1*3DIGIT
location-error-params = location-error-code-text location-error-params = location-error-code-text
/ generic-param ; from RFC3261 / generic-param ; from RFC3261
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261
The Geolocation-Error header field MUST contain only one The Geolocation-Error header field MUST contain only one
skipping to change at page 13, line 42 skipping to change at page 16, line 4
is no special location error code for what already exists within SIP is no special location error code for what already exists within SIP
today. today.
Within each of these ranges, there is a top level error as follows: Within each of these ranges, there is a top level error as follows:
Geolocation-Error: 100 "Cannot Process Location" Geolocation-Error: 100 "Cannot Process Location"
Geolocation-Error: 200 "Permission To Use Location Information" Geolocation-Error: 200 "Permission To Use Location Information"
Geolocation-Error: 300 "Dereference Failure" Geolocation-Error: 300 "Dereference Failure"
There are two specific Geolocation-Error codes necessary to include There are two specific Geolocation-Error codes necessary to include
in this document, both have to do with permissions necessary to in this document, both have to do with permissions necessary to
process the SIP request; they are process the SIP request; they are
Geolocation-Error: 201 "Permission To Retransmit Location Geolocation-Error: 201 "Permission To Retransmit Location
Information to a Third Party" Information to a Third Party"
This location error is specific to having the Presence Information This location error is specific to having the Presence Information
Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set
to "=no". This location error is stating it requires permission to "no". This location error is stating it requires permission
(i.e., PIDF-LO <retransmission-allowed> element set to "=yes") to (i.e., PIDF-LO <retransmission-allowed> element set to "yes") to
process this SIP request further. If the LS sending the location process this SIP request further. If the LS sending the location
information does not want to give this permission, it will not reset information does not want to give this permission, it will not reset
this permission in a new request. If the LS wants this message this permission in a new request. If the LS wants this message
processed without this permission reset, it MUST choose another processed without this permission reset, it MUST choose another
logical path (if one exists) for this SIP request. logical path (if one exists) for this SIP request.
Geolocation-Error: 202 "Permission to Route based on Location Geolocation-Error: 202 "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 Geolocation-Routing
parameter <routing-allowed> set to "=no". This location error is header value set to "no". This location error is stating it requires
stating it requires permission (i.e., a <routing-allowed> set to permission (i.e., the Geolocation-Routing header value set to "yes")
"=yes") to process this SIP request further. If the LS sending the to process this SIP request further. If the LS sending the location
location information does not want to give this permission, it will information does not want to give this permission, it will not reset
not reset this permission in a new request. If the LS wants this this permission in a new request. If the LS wants this message
message processed without this permission reset, it MUST choose processed without this permission reset, it MUST choose another
another logical path (if one exists) for this SIP request. logical path (if one exists) for this SIP request.
4.4 Location URIs in Message Bodies 4.5 Location URIs in Message Bodies
In the case where an LR sends a 424 response and wishes to In the case where an LR sends a 424 response and wishes to
communicate suitable location by reference rather than by value, the communicate suitable location by reference rather than by value, the
424 MUST include a content-indirection body per RFC 4483. 424 MUST include a content-indirection body per RFC 4483.
4.5 Location Profile Negotiation 4.6 Location Profile Negotiation
The following is part of the discussion started in Section 3, Figure The following is part of the discussion started in Section 3, Figure
2, which introduced the concept of sending location indirectly. 2, which introduced the concept of sending location indirectly.
If a location URI is included in a SIP request, the sending user If a location URI is included in a SIP request, the sending user
agent MUST also include a Supported header field indicating which agent MUST also include a Supported header field indicating which
location profiles it supports. Two option tags for location profiles location profiles it supports. Two option tags for location profiles
are defined by this document: "geolocation-sip" and are defined by this document: "geolocation-sip" and
"geolocation-http". Future specifications may define further "geolocation-http". Future specifications may define further
location profiles per the IANA policy described in Section 8.2. location profiles per the IANA policy described in Section 8.3.
The "geolocation-sip" option tag signals support for acquiring The "geolocation-sip" option tag signals support for acquiring
location information via the presence event package of SIP location information via the presence event package of SIP
([RFC3856]). A location recipient who supports this option can send ([RFC3856]). A location recipient who supports this option can send
a SUBSCRIBE request and parse a resulting NOTIFY containing a a SUBSCRIBE request and parse a resulting NOTIFY containing a
PIDF-LO object. The URI schemes supported by this option include PIDF-LO object. The URI schemes supported by this option include
"sip", "sips" and "pres". "sip", "sips" and "pres".
The "geolocation-http" option tag signals support for acquiring The "geolocation-http" option tag signals support for acquiring
location information via an HTTP ([RFC2616]). A location recipient location information via an HTTP ([RFC2616]). A location recipient
skipping to change at page 15, line 23 skipping to change at page 17, line 35
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>
;routing-allowed=no Geolocation-Routing: 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 16, line 53 skipping to change at page 19, line 13
(see Figure 2 in Section 3.2 for this message flow). (see Figure 2 in Section 3.2 for this message flow).
5.2 Two Locations Composed in Same Location Object Example 5.2 Two Locations Composed in Same Location Object Example
This example shows the INVITE message after a SIP intermediary This example shows the INVITE message after a SIP intermediary
rejected the original INVITE (say, the one in section 5.1). This rejected the original INVITE (say, the one in section 5.1). This
INVITE contains the composed LO sent by the SIP intermediary which INVITE contains the composed LO sent by the SIP intermediary 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 ought not be taken as occurring very
often. In fact, this is believed to be a corner case of location often. In fact, this example is believed to be a corner case of
conveyance applicability. location conveyance applicability.
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188512@atlanta.example.com Call-ID: 3848276298220188512@atlanta.example.com
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <cid:target123@atlanta.example.com>
;routing-allowed=no Geolocation-Routing: no
Supported: geolocation Supported: geolocation
Accept: application/sdp, application/pidf+xml Accept: application/sdp, application/pidf+xml
CSeq: 31863 INVITE CSeq: 31863 INVITE
Contact: <sips:alice@atlanta.example.com> Contact: <sips:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
skipping to change at page 20, line 40 skipping to change at page 22, line 50
its definition and rules in Section 4.1 of this document, and should its definition and rules in Section 4.1 of this document, and should
be added to the IANA sip-parameters registry with two actions be added to the IANA sip-parameters registry with two actions
1. Update the Header Fields registry with 1. Update the Header Fields registry with
Registry: Registry:
Header Name compact Reference Header Name compact Reference
----------------- ------- --------- ----------------- ------- ---------
Geolocation [this doc] Geolocation [this doc]
2. In the portion titled "Header Field Parameters and Parameter 8.2 IANA Registration for the SIP Geolocation Header Field
Values", add
Predefined The SIP Geolocation-Routing Header Field is created by this document,
Header Field Parameter Name Values Reference with its definition and rules in Section 4.2 of this document, and
---------------- ------------------- ---------- --------- should be added to the IANA sip-parameters registry with the
Geolocation routing-allowed yes [this doc] following action
8.2 IANA Registration for Location Profiles 1. Update the Header Fields registry with
Registry:
Header Name compact Reference
----------------- ------- ---------
Geolocation-Routing [this doc]
8.3 IANA Registration for Location Profiles
This document defines two new SIP option tags: "geolocation-sip" and This document defines two new SIP option tags: "geolocation-sip" and
"geolocation-http." with the definition and rule in Section 4.5 of "geolocation-http." with the definition and rule in Section 4.6 of
this document, to be added to the IANA sip-parameters Options Tags this document, to be added to the IANA sip-parameters Options Tags
registry. registry.
Name Valid Scheme(S) Reference Name Valid Scheme(S) Reference
geolocation-sip See 4.5 [this doc] geolocation-sip See 4.6 [this doc]
geolocation-http See 4.5 [this doc] geolocation-http See 4.6 [this doc]
The names of profiles are SIP option-tags, and the guidance in this The names of profiles are SIP option-tags, and the guidance in this
document does not supersede the option-tag assignment guidance in document does not supersede the option-tag assignment guidance in
[RFC3261] (which requires a Standards Action for the assignment of a [RFC3261] (which requires a Standards Action for the assignment of a
new option tag). This document does however stipulate that new option tag). This document does however stipulate that
option-tags included to convey the name of a location profile per option-tags included to convey the name of a location profile per
this definition MUST begin with the string "geolocation" followed by this definition MUST begin with the string "geolocation" followed by
a dash. All such option tags should describe protocols used to a dash. All such option tags should describe protocols used to
acquire location by reference: these tags have no relevance to acquire location by reference: these tags have no relevance to
location carried in SIP requests by value, which use standard MIME location carried in SIP requests by value, which use standard MIME
typing and negotiation. typing and negotiation.
8.3 IANA Registration for 424 Response Code 8.4 IANA Registration for 424 Response Code
In the SIP Response Codes registry, the following is added In the SIP Response Codes registry, the following is added
Reference: RFC-XXXX (i.e., this document) Reference: RFC-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: Registry:
Response Code Reference Response Code Reference
------------------------------------------ --------- ------------------------------------------ ---------
Request Failure 4xx Request Failure 4xx
424 Bad Location Information [this doc] 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.3 of this document.
8.4 IANA Registration of New Geolocation-Error Header Field 8.5 IANA Registration of New Geolocation-Error Header Field
The SIP Geolocation-error header field is created by this document, The SIP Geolocation-error header field is created by this document,
with its definition and rules in Section 4.3 of this document, to be with its definition and rules in Section 4.4 of this document, to be
added to the IANA sip-parameters registry with two actions added to the IANA sip-parameters registry with two actions
1. Update the Header Fields registry with 1. Update the Header Fields registry with
Registry: Registry:
Header Name compact Reference Header Name compact Reference
----------------- ------- --------- ----------------- ------- ---------
Geolocation-Error [this doc] Geolocation-Error [this doc]
2. In the portion titled "Header Field Parameters and Parameter 2. In the portion titled "Header Field Parameters and Parameter
Values", add Values", add
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
----------------- ------------------- ---------- --------- ----------------- ------------------- ---------- ---------
Geolocation-Error code= yes* [this doc] Geolocation-Error code= yes* [this doc]
* see section 8.5 for the newly created values. * see section 8.6 for the newly created values.
8.5 IANA Registration for the SIP Geolocation-Error Codes 8.6 IANA Registration for the SIP Geolocation-Error Codes
New location specific Geolocation-Error codes are created by this New location specific Geolocation-Error codes are created by this
document, and registered in a new table in the IANA sip-parameters document, and registered in a new table in the IANA sip-parameters
registry. Details of these error codes are in Section 4.3 of this registry. Details of these error codes are in Section 4.4 of this
document. document.
Geolocation-Error codes Geolocation-Error codes
----------------------- -----------------------
Geolocation-Error codes provide reason for the error discovered by Geolocation-Error codes provide reason for the error discovered by
Location Recipients, categorized by action to be taken by error Location Recipients, categorized by action to be taken by error
recipient. recipient.
Code Description Reference Code Description Reference
---- --------------------------------------------------- --------- ---- --------------------------------------------------- ---------
 End of changes. 39 change blocks. 
123 lines changed or deleted 241 lines changed or added

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