draft-ietf-sip-location-conveyance-08.txt   draft-ietf-sip-location-conveyance-09.txt 
SIP Working Group James Polk SIP Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration: Jan 9th, 2008 Brian Rosen Expiration: May 16th, 2008 Brian Rosen
Intended Status: Standards Track NeuStar Intended Status: Standards Track (PS) NeuStar
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sip-location-conveyance-08.txt draft-ietf-sip-location-conveyance-09.txt
July 9th, 2007 Nov 16th, 2007
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in reference material or to cite them other than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9th, 2008. This Internet-Draft will expire on May 16th, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 extension covers end to end
skipping to change at page 2, line 13 skipping to change at page 2, line 13
make routing decisions based on the location of the SIP user agents. make routing decisions based on the location of the SIP user agents.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Overview of SIP Location Conveyance . . . . . . . . . . . 4 3.1 Overview of SIP Location Conveyance . . . . . . . . . . . 4
3.2 The Geolocation Header . . . . . . . . . . . . . . . . . 5 3.2 The Geolocation Header . . . . . . . . . . . . . . . . . 5
3.3 424 (Bad Location Information) Response Code . . . . . . 8 3.3 424 (Bad Location Information) Response Code . . . . . . 8
3.4 The Geolocation-Error Header . . . . . . . . . . . . . . 8 3.4 The Geolocation-Error Header . . . . . . . . . . . . . . 9
3.5 The Geolocation Option Tag . . . . . . . . . . . . . . . 16 3.5 The Geolocation Option Tag . . . . . . . . . . . . . . . 18
3.6 Using sip/sips/pres as a Dereference Scheme . . . . . . . 17 3.6 Using sip/sips/pres as a Dereference Scheme . . . . . . . 19
4. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 17 4. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 20
4.1 Location-by-value (Coordinate Format) . . . . . . . . . . 18 4.1 Location-by-value (Coordinate Format) . . . . . . . . . . 20
4.2 Location-by-reference . . . . . . . . . . . . . . . . . . 19 4.2 Location-by-reference . . . . . . . . . . . . . . . . . . 22
5. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 20 5. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 23
5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 21 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 24
5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 23 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 25 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 29
6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 27 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
8.1 IANA Registration for New SIP Geolocation Header . . . . 30 8.1 IANA Registration for New SIP Geolocation Header . . . . 34
8.2 IANA Registration for New SIP Geolocation Option Tag . . 30 8.2 IANA Registration for New SIP Geolocation Option Tag . . 35
8.3 IANA Registration for New 424 Response Code . . . . . . . 30 8.3 IANA Registration for New 424 Response Code . . . . . . . 35
8.4 IANA Registration for New SIP Geolocation-Error Header . 30 8.4 IANA Registration for New SIP Geolocation-Error Header . 35
8.5 IANA Registration for New SIP Geolocation-Error Codes . . 30 8.5 IANA Registration for New SIP Geolocation-Error Codes . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1 Normative References . . . . . . . . . . . . . . . . . 32 10.1 Normative References . . . . . . . . . . . . . . . . . 37
10.2 Informative References . . . . . . . . . . . . . . . . . 33 10.2 Informative References . . . . . . . . . . . . . . . . . 38
Author Information . . . . . . . . . . . . . . . . . . . . . 33 Author Information . . . . . . . . . . . . . . . . . . . . . 38
Appendix A. Requirements for SIP Location Conveyance . . . . 34 Appendix A. Requirements for SIP Location Conveyance . . . . 39
Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 36 Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 41
Intellectual Property and Copyright Statements . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . 42
1. Introduction 1. Introduction
This document describes how Location can be "conveyed" (that is, This document describes how Location can be "conveyed" (that is,
transmitted over the Internet) from one SIP user agent (UA), or in transmitted over the Internet) from one SIP user agent (UA), or in
some circumstances, a proxy server acting in support of a UA, to some circumstances, a proxy server acting in support of a UA, to
another entity using SIP [RFC3261]. Here "Location" is a another entity using SIP [RFC3261]. Here "Location" is a
description of the physical geographical area where something description of the physical geographical area where something
currently exists. The phrase "location conveyance" describes currently exists. The phrase "location conveyance" describes
scenarios in which a SIP user agent client (UAC) is informing a user scenarios in which a SIP user agent client (UAC) is informing a user
skipping to change at page 6, line 19 skipping to change at page 6, line 19
The cid-url is defined in [RFC2392] to locate message body The cid-url is defined in [RFC2392] to locate message body
parts. This URI type MUST be present in a SIP message if location parts. This URI type MUST be present in a SIP message if location
is by-value in that same message. is by-value in that same message.
Other protocols used in the Location URI MUST be reviewed against Other protocols used in the Location URI MUST be reviewed against
the RFC 3693 criteria for a Using Protocol. the RFC 3693 criteria for a Using Protocol.
The Geolocation header MAY have one or more locationValues. SIP The Geolocation header MAY have one or more locationValues. SIP
servers inserting a locationValue MUST add the new value to the end servers inserting a locationValue MUST add the new value to the end
of the header value, such that the last locationValue is the most of the header value, such that the last locationValue in the header
recent one added to the message. is the most recent one added to the message.
A locationValue has the following header parameters. These A locationValue has the following independent header parameters,
header parameters include,
o the "inserted-by=" provides the host-id (alice.example.com) of o the "inserted-by=" parameter provides the host-id
the SIP entity that inserted this locationValue into the request. (alice.example.com -- which is the same as the "sent-by"
This is used to map to any Geolocation-Error message to determine parameter in a Via header) of the SIP entity that inserted this
which location, if there is more than one in a request, the error locationValue into the request. This is used to map to any
corresponds to. If an entity receives an Geolocation-Error with Geolocation-Error message to determine which location, if there
a host-id not of this entity, the Geolocation-Error SHOULD be is more than one in a request, the error corresponds to. If an
ignored. entity receives an Geolocation-Error with a host-id not of this
entity, the Geolocation-Error SHOULD be ignored.
o "used-for-routing" to inform recipients that the location in this o the "used-for-routing" parameter to inform recipients that the
locationValue was used to route the message towards the ultimate location in this locationValue was used to route the message
destination UAS. This can occur more than once along the towards the ultimate destination UAS. This can occur more than
request's path. Because locationValues are inserted as last once along the request's path. Because locationValues are
inserted is last in the header, the last locationValue is the inserted as last inserted is last in the header, the last
most recent one added to the message. This also gives the locationValue is the most recent one added to the message. This
"used-for-routing" header parameter added integrity - as the also gives the "used-for-routing" header parameter added
receiving SIP entity knows which locationURI the message was integrity - as the receiving SIP entity knows which locationURI
routed upon. the message was routed upon.
o the "recipient=" to allow recipients to infer what SIP element o the "recipient=" parameter to allow recipients to infer what SIP
type this locationValue was intended to be for. The types are element type this locationValue was intended to be for. The
"endpoint", meaning the ultimate destination UAS; types are
"routing-entity", meaning SIP servers; and "both" meaning this
locationValue is to be viewed by both types of SIP entities. o "endpoint" - meaning the ultimate destination UAS;
o "routing-entity" - meaning SIP servers that route messages
based on the location contents of requests; and
o "both" - meaning this locationValue is to be viewed by both
types of SIP entities.
Not all SIP entities have to read the locationValue within a
Geolocation header, therefore a parameter value of "both" does
not mean "every" SIP element receiving this request, it means all
that care to pay attention to a locationValue. The default
behavior of SIP entities reading the locationValue is that if
this header parameter is NOT present, the intended recipient is
the destination UAS.
Each locationValue MUST contain exactly one "inserted-by" parameter,
indicating which SIP entity added the locationValue to the SIP
request.
Each of the three types of header parameters listed here MAY appear Each of the three types of header parameters listed here MAY appear
in any locationValue once. There MUST NOT be more than one in any locationValue once. There MUST NOT be more than one
"inserted-by=" parameter or "used-for-routing" parameter or "inserted-by=" parameter or one "used-for-routing" parameter or one
"recipient=" parameter in the same locationValue. However, since "recipient=" parameter in the same locationValue. However, there
there can be more than one locationValue in the same Geolocation can be more than one locationValue in the same Geolocation header.
header, each can with their own set of these header parameters and
not violate this rule.
This document defines the Geolocation header as valid in the This document defines the Geolocation header 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] and SUBSCRIBE [RFC3265], NOTIFY [RFC3265],
PUBLISH [RFC3903] PUBLISH [RFC3903] and PRACK [RFC3262]
Discussing location using the PUBLISH Request Method is out of scope Discussing location using the PUBLISH Request Method is out of scope
for this document, but the Table 1 shows PUBLISH is to support for this document, but the Table 1 shows PUBLISH is to support
Location Conveyance via this extension. Location Conveyance via this extension.
The following table extends the values in Table 2&3 of RFC 3261 The following table extends the values in Table 2&3 of RFC 3261
[RFC3261]. [RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA Header field where proxy INV ACK CAN BYE REG OPT PRA
---------------------------------------------------------------- ----------------------------------------------------------------
skipping to change at page 7, line 42 skipping to change at page 8, line 8
The Geolocation header field MAY be included in any one of the above The Geolocation header field MAY be included in any one of the above
requests by a UAC. A proxy MAY add the Geolocation header, but MUST requests by a UAC. A proxy MAY add the Geolocation header, but MUST
NOT modify any pre-existing locationValue, including its associated NOT modify any pre-existing locationValue, including its associated
header parameters of within an existing Geolocation header value, header parameters of within an existing Geolocation header value,
unless one of the existing locationValues is used to retarget the unless one of the existing locationValues is used to retarget the
request towards a new destination UAS. This is discussed in section request towards a new destination UAS. This is discussed in section
5.3. 5.3.
[RFC3261] states message bodies cannot be added by proxies. [RFC3261] states message bodies cannot be added by proxies.
Therefore, any Geolocation header field added by a proxy MUST be in Therefore, any Geolocation header field added by a proxy MUST be in
the form of a location-by-reference URI. the form of a location-by-reference URI, in its own locationValue
header value.
Adding a locationValue to an existing Geolocation header SHOULD be Adding a new locationValue to an existing Geolocation header SHOULD
done with caution, given this document's limited guidance as to what NOT occur without appropriate caution to the fact that Location
a Location Recipient should do when receiving more than one Recipients might not understand how to process more than one
location. A Location Recipient can easily be confused by too much location, given this document's limited guidance as to what a
location information, producing undesirable results. Location Recipient should do when receiving more than one location
(i.e., currently no priority instructions are given for which
locationValue to use if there are more than one). A Location
Recipient can easily be confused by too much location information,
producing undesirable results. The <tuple id> element in the
PIDF-LO XML indicates whose location is contained in the PIDF-LO.
Location Recipients receiving a location object, received directly Location Recipients receiving a location object, received directly
or as the result of a dereference, MUST honor the usage element or as the result of a dereference, MUST honor the usage element
rules within that XML document, per RFC 4119. Such entities MUST rules within that XML document, per RFC 4119. Such entities MUST
NOT alter the rule set. NOT alter the rule set.
3.3 424 (Bad Location Information) Response Code 3.3 424 (Bad Location Information) Response Code
If a UAS or SIP intermediary detects an error in a request message If a UAS or SIP intermediary detects an error in a request message
specific to the location information supplied by-value or specific to the location information supplied by-value or
by-reference. The new 4XX level error is created here to indicate a by-reference. The new 4XX level error is created here to indicate a
problem with the location in the request message. This document problem with the location in the request message. This document
creates and IANA registers the new error code: creates and IANA registers the new error code:
424 (Bad Location Information) 424 (Bad Location Information)
The 424 (Bad Location Information) response code is a rejection of The 424 (Bad Location Information) response code is a rejection of
the request, due to its location contents, indicating the location the request, due to its location contents, indicating the location
information was malformed or not satisfactory for the recipient's information was malformed or not satisfactory for the recipient's
purpose or could not be dereferenced. purpose, or could not be dereferenced.
Section 3.4 creates the Geolocation-Error header to provide more Section 3.4 creates the Geolocation-Error header to provide more
detail about what was wrong with the location information in the detail about what was wrong with the location information in the
request. This header MUST be in the 424 response with the most request. This header MUST be in the 424 response, containing a
applicable code. locationErrorValue for each invalid locationValue in the request
(i.e., and one-for-one matching if all locationValues in the request
were bad).
If more than one location is present in a request (by-value or If more than one location is present in a request (by-value or
by-reference), and any of the locationValues is good for the by-reference), and any of the locationValues is good for the
Location Recipient to process, a 424 MUST NOT be sent. The 424 is Location Recipient to process, a 424 MUST NOT be sent. The 424 is
only appropriate when there are no locationValues included in a SIP only appropriate when the Location Recipient needs a locationValue
request that are usable by a recipient. and there are no locationValues included in a SIP request that are
usable by a recipient.
A 424 (Bad Location Information) response is a final response within A 424 (Bad Location Information) response is a final response within
a transaction, and does not terminate a dialog. a transaction, and does not terminate a dialog.
The UAC can use whatever means it knows of to verify/refresh its The UAC can use whatever means it knows of to verify/refresh its
location information before attempting a new request that includes location information before attempting a new request that includes
location. There is no cross-transaction awareness expected by either location. There is no cross-transaction awareness expected by either
the UAS or SIP intermediary as a result of this error message. the UAS or SIP intermediary as a result of this error message.
The new 424 (Bad Location Information) error code is IANA registered The new 424 (Bad Location Information) error code is IANA registered
in Section 8 of this document. An initial set of location error of in Section 8 of this document. An initial set of location error of
IANA registered Geolocation-Error codes are in Section 3.4 of this IANA registered Geolocation-Error codes are in Section 3.4 of this
document. document.
3.4 The Geolocation-Error Header for Error Granularity 3.4 The Geolocation-Error Header Providing Error Granularity
As discussed in Section 3.3, more granular error notifications, As discussed in Section 3.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 UAC is to know what was wrong within the original request. if the UAC is to know what was wrong within the original request.
The Geolocation-Error header is created here for this purpose. The Geolocation-Error header is created here for this purpose.
Geolocation-Error header is used to convey location specific errors Geolocation-Error header is used to convey location specific errors
within a response. Additions to this IANA registered header require within a response. Additions to this IANA registered header require
an RFC be published. an RFC be published.
Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue Geolocation-Error = "Geolocation-Error" HCOLON
*(COMMA locationErrorValue)) [locationErrorValue
locationErrorValue = numeric-code SEMI (error-node-id) *(COMMA locationErrorValue)]
SEMI (host-id) SEMI (geoloc-error-param) locationErrorValue = location-error-code *(SEMI
numeric-code = decimal-string location-error-params)
error-node-id = node-id location-error-code = 1*3DIGIT
host-id = "inserter" EQUAL host name location-error-params = location-error-node-id
geoloc-error-param = "code" EQUAL error-text-string / DQOUTE location-error-host-id DQOUTE
/ generic-param ; (from RFC 3261) / CAtype *(SEMI CAtype)
error-text-string = string / DQOUTE location-error-code-text DQOUTE
/ generic-param ; from RFC3261
location-error-node-id = "node" EQUAL hostname; from RFC3261
location-error-host-id = "inserter" EQUAL hostname ; from RFC3261
CAtype = "CAtype" EQUAL civic-code *(SEMI "CAtype"
EQUAL civic-code)
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261
civic-code = IANA registered CAtypes; from
[IANA-civic]
The Geolocation-Error header contains a locationErrorValue, which is The Geolocation-Error header MUST contain at least one
a numeric code of the error with its associated descriptive text, locationErrorValue to indicate what was wrong with the original
the error-text-string. The error-text-string is human understandable locationValue in the corresponding request. If a Location Recipient
text for each error code. The Geolocation-Error can have more than experienced more than one error in the locationValue of the
one locationErrorValue, separated by a comma. Included error codes corresponding SIP request, there can be one locationErrorValue per
SHOULD NOT conflict in meaning. Each locationErrorValue is targeted problem with the locationValue in the request (the except to this is
at a specific location inserter, which is learned from the involving CAtypes, which will be covered later here). If there was
"inserted-by=" parameter in the locationValue of the request. something wrong with more than one locationValue in a request, a
corresponding locationErrorValue would be sent, one per error, in
the response. Each locationErrorValue contains a 3-digit error code
(defined in subsections to this section of this doc) indicating what
was wrong with the location(s) in the request. Each error type has
a corresponding quoted error text string that is human
understandable.
The Numeric-code value is the number assigned to a particular error. Also within the locationErrorValue is the Location Recipient
These error codes start 1, and are not necessarily consecutively identifier (the "node=") who experienced the location error, as well
incremented. All Numeric-code values are IANA registered. as an identifier of which SIP entity (the "inserter=") the Location
Recipient is told (in the locationValue) added the locationValue to
this request. The "node=" and "inserter=" are domain identifier of
a SIP entity, the same as is entered in the "sent-by" parameter of
the Via header for that entity [RFC3261]. As stated in section 18
of RFC 3261, the usage of FQDN is RECOMMENDED. Here are examples of
both
The error-node-id is the node identification of the entity that node=bob.example.com
experienced the location-based error from the request, and MUST NOT
be an IP address for many reasons, including the presence of NATs.
This can be useful for troubleshooting. Here is an example of an
error-node-id
alice.example.com inserter=alice.example.com
The host-id has the same form as the error-node-id, but the host-id Both "node=" and "inserter=" parameters MUST be present in all
is the host name of the entity that inserted the location into the locationErrorValues in a response, unless the "inserted-by="
request. This value can be found in the "inserted-by=" parameter of parameter was not in the request. The "inserter=" parameter is
the Geolocation header in the request. If this is not present in copied from the "inserted-by=" parameter within the locationValue of
the request, the host-id cannot be in the response. This value, the request.
when present, gives the response recipients an indication as to
which location, therefore which entity, this particular error is
intended for. Here is an example of the host-id
bob.example.com Here's why, a Location Recipient that experienced the location
problem with the request needs to tell who added which location into
the original request. Since more than one SIP entity can insert
location into a request, all other SIP elements may be confused by
receiving this error header. So, the header has to identify who it
is for, so that all other SIP entities that read the header know to
ignore it, since it is not for them. This is of particular use if
the original UAC did not include a locationValue in the original SIP
request, but a SIP server along the path did insert a locationValue.
The locationErrorValue would travel to each SIP entity along the
original path and tell both the server that included the
locationValue what was wrong with the location and the UAC who
did not know what the error meant.
If an entity receives an Geolocation-Error with a host-id not of A worse case is when both the original UAC and a SIP server along
this entity, the Geolocation-Error SHOULD be ignored because the the path included a locationValue, but there was only something
error is not intended for this entity. wrong with one of the locationValues. Without this identification
of which locationValue was in error, both entities would react and
one would do so incorrectly.
The error-text-string is a natural language ASCII string that is Finally, there can be a list of one or more CAtype civic-codes that
intelligible to a human user reading the error message, which are determined to be in error by the Location Recipient. Perhaps
describes the type of error experienced. This string MUST appear in the Location Recipient believes one or more CAtypes are missing, and
each locationErrorValue of a response. required in order to fully process the locationValue in the request,
or perhaps data entered in one or more CAtypes is wrong, according
to the Location Recipient. The list of CAtypes is taken from those
that are IANA registered at [IANA-civic].
More than one locationErrorValue in a Geolocation-Error header is
separated by a comma.
If more than one locationErrorValue is in a response, and intended
for the same "inserter=", the error codes SHOULD NOT conflict in
meaning. In other words, two error codes (within separate
locationErrorValues of the same response) SHOULD NOT give misleading
or inconsistent indications to the location "inserter=".
Here is an example of a Geolocation-Error header Here is an example of a Geolocation-Error header
Geolocation-Error: 1; alice.example.com; code="Location Format not Geolocation-Error: 106; "node=bob.example.com";
supported" "inserter=alice.example.com";
CAtype=A3; CAtype=STS;
code="incomplete location supplied"
In this example, the Location Recipient (node=Bob) has determined
the location supplied by the "inserter=" (inserter=Alice) was not
enough to determine where (Alice) was. Specifically, Bob has
determined that CAtypes A3 (the city) and STS (the street type
(Street, Road, Avenue, etc)) were not present to form a complete
location of the Alice. A subsequent request by Alice that included
these two additional pieces of location information would tell Bob
where Alice was.
Notice the CAtypes that were in error are (in the above example
Geolocation-Error header), according to the Location Recipient,
listed in the locationErrorValue. The associated CAtype values MUST
NOT be listed in the locationErrorValue. This is for
privacy/security concerns. It is up to the Location Recipient to
determine which CAtypes were in error, and only list those CAtypes
in the response. The "inserter=" entity MUST determine what to do
about correcting each CAtype found in error for subsequent location
conveyance. Usually, this would involve either refreshing its
location information however it learned its location in the first
place, or merely listing what information is lacking/wrong to the
location sender (i.e., the user) or its network management.
The following table extends the values in Table 2&3 of RFC 3261 The following table extends the values in Table 2&3 of RFC 3261
[RFC3261]. [RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA Header field where proxy INV ACK CAN BYE REG OPT PRA
---------------------------------------------------------------- ----------------------------------------------------------------
Geolocation-Error r ar o - - o o o o Geolocation-Error r ar o - - o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB Header field where proxy SUB NOT UPD MSG REF INF PUB
---------------------------------------------------------------- ----------------------------------------------------------------
skipping to change at page 10, line 20 skipping to change at page 12, line 4
The following table extends the values in Table 2&3 of RFC 3261 The following table extends the values in Table 2&3 of RFC 3261
[RFC3261]. [RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA Header field where proxy INV ACK CAN BYE REG OPT PRA
---------------------------------------------------------------- ----------------------------------------------------------------
Geolocation-Error r ar o - - o o o o Geolocation-Error r ar o - - o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB Header field where proxy SUB NOT UPD MSG REF INF PUB
---------------------------------------------------------------- ----------------------------------------------------------------
Geolocation-Error r ar o o o o o o o Geolocation-Error r ar o o o o o o o
Table 2: Summary of the Geolocation-Error Header Table 2: Summary of the Geolocation-Error Header
The Geolocation-Error header field MAY be included in the response The Geolocation-Error header field MAY be included in any response
to one of the above SIP requests, so long as Geolocation was in the to one of the above SIP requests, so long as Geolocation was in the
request part of the transaction. The choice of which SIP requests request part of the transaction. The choice of which SIP requests
are in table 2 above come from which Methods can optionally have the are in table 2 above come from which Methods can optionally have the
Geolocation header (see section 3.2). Geolocation header (see section 3.2).
The Geolocation-Error header allows for multiple locationErrorValues Here is an example of a transaction that has a location error. In
to be returned in the same response. For instance, if a this case, Bob responds with a 424 (Bad Location Information)
location-by-reference is sent and the supplied scheme is not desired response, including a Geolocation-Error header, is in Figure 1.
or cannot be processed, but more than one other scheme can be, the
424 response can list more than one code from the 20-22 range in the
response. The UAC can subsequently retry the transaction with one of
the schemes supported or desired by the recipient.
To illustrate this, here is an example of Alice including
location-by-reference using an HTTP scheme. In this case, Bob
cannot dereference using HTTP, but can dereference using SIP, SIPS,
and PRES. An example of this transaction, with a 424 (Bad Location
Information) response, including a Geolocation-Error header, is in
Figure 1.
Alice Bob Alice Bob
| | | |
| Request w/ Location | | Request w/ Location |
| using http scheme | |--------------------------------------->|
|----------------------------------->|
| | | |
| | | |
| 424 (Bad Location Information) | | 424 (Bad Location Information) |
| with Geolocation-Error containing | | with Geolocation-Error containing |
| 20 (SIP), 21 (SIPS), 22 (PRES) | | 106 (Incomplete Location Information) |
|<-----------------------------------| |<---------------------------------------|
| | | |
Figure 1. Basic Transaction with 424 and Geolocation-Error Header Figure 1. Basic Transaction with 424 and Geolocation-Error Header
The following subsections provide an initial list of location The following subsections provide an initial list of location
specific granular codes for any SIP responses, including the new 424 specific granular codes for any SIP responses, including the new 424
(Bad Location Information) response. If more than one specific (Bad Location Information) response. If more than one specific
Geolocation-Error code is applicable for a response, each MUST be in Geolocation-Error code is applicable for a response, each MUST be in
the response. Geolocation-Error Code 1 is the generic 'location was the response. Geolocation-Error Code 100 is the generic 'location
supplied, but not understood' error. If a more specific code was supplied, but not understood' error. If a more specific code
applies, a code 1 is unnecessary. applies, a code 100 is unnecessary.
3.4.1 Geolocation-Error Code 1 Location Not Understood 3.4.1 Geolocation-Error Code 100 Location Not Understood
Geolocation-Error code 1 "Location Format not supported" means the Geolocation-Error code 100 "Location Format not supported" means the
location format supplied in the request, by-value or by-reference, location format supplied in the request, by-value or by-reference,
was not supported. was not supported.
This code means the recipient understood that location was included This code means the recipient understood that location was included
in the message, but the format is not supported. Perhaps the format in the message, but the format is not supported. Perhaps the format
was a freeform text format or data-URL and the recipient only was a freeform text format or data-URL and the recipient only
understood location in RFC 4119 PIDF-LO format (civic or understood location in RFC 4119 PIDF-LO format (civic or
x.y(.z) coordinate). This error code applies when a recipient has x.y(.z) coordinate). This error code applies when a recipient has
difficulty parsing the location supplied in the request. difficulty parsing the location supplied in the request.
If the format is understood, but not desired, an error code 2 or 3 If the format is understood, but not desired, an error code 101 or
MUST be returned in a 424 response, depending on which location 102 MUST be returned in a 424 response, depending on which location
format is desired. The Location Recipient returns an error code 2 or format is desired. The Location Recipient returns an error code 101
3 when it only understands one location format (coordinate or civic) or 102 when it only understands one location format (coordinate or
and did not receive that format. civic) and did not receive that format.
If a more specific error code is appropriate in a response, If a more specific error code is appropriate in a response,
including error code 1 is unnecessary. including error code 100 is unnecessary.
error-text-string: Location format not supported error-text-string: Location format not supported
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 1 alice.example.com "Location Format not Geolocation-Error: 100; "node=bob.example.com";
supported" "inserter=alice.example.com";
CAtype=A3; CAtype=STS;
code="Location Format not supported"
3.4.2 Geolocation-Error Code 2 Coordinate-location Format Desired 3.4.2 Geolocation-Error Code 101 Coordinate-location Format Desired
Geolocation-Error code 2 "Coordinate-location Format Desired" means Geolocation-Error code 101 "Coordinate-location Format Desired"
the location format supplied in the request (probably formatted in means the location format supplied in the request (probably
civic), by-value or by-reference, was understood and supported, but formatted in civic), by-value or by-reference, was understood and
that the recipient, or an application on the recipient, can or supported, but that the recipient, or an application on the
prefers to only process location in the coordinate-location format. recipient, can or prefers to only process location in the
coordinate-location format.
A typical reaction to receiving this code is to resend the A typical reaction to receiving this code is to resend the
original message with location formatted in coordinate instead. original message with location formatted in coordinate instead.
error-text-string: Coordinate-location Format Desired error-text-string: Coordinate-location Format Desired
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 2 node_alice.example.com "Coordinate-location Geolocation-Error: 101; "node=bob.example.com";
Format Desired" "inserter=alice.example.com";
code="Coordinate-location Format Desired"
3.4.3 Geolocation-Error Code 3 Civic-location Format Desired 3.4.3 Geolocation-Error Code 102 Civic-location Format Desired
Geolocation-Error code 3 "Civic-location Format Desired" means the Geolocation-Error code 102 "Civic-location Format Desired" means the
location format supplied in the request (probably formatted in location format supplied in the request (probably formatted in
coordinate), by-value or by-reference, was understood and supported, coordinate), by-value or by-reference, was understood and supported,
but that the recipient, or an application on the recipient, can or but that the recipient, or an application on the recipient, can or
prefers to only process location in the civic-location format. prefers to only process location in the civic-location format.
A typical reaction to receiving this code is to resend the A typical reaction to receiving this code is to resend the
original message with location formatted in civic instead. original message with location formatted in civic instead.
error-text-string: Civic-location Format Desired error-text-string: Civic-location Format Desired
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 3 alice.example.com "Civic-location Format Geolocation-Error: 102; "node=bob.example.com";
Desired" "inserter=alice.example.com";
code="Civic-location Format Desired"
3.4.4 Geolocation-Error Code 4 Cannot Parse Location Supplied 3.4.4 Geolocation-Error Code 103 Cannot Parse Location Supplied
Geolocation-Error code 4 "Cannot parse location supplied" means the Geolocation-Error code 103 "Cannot parse location supplied" means
location provided, whether by-value or by-reference, in a request is the location provided, whether by-value or by-reference, in a
not well formed. request is not well formed.
error-text-string: Cannot parse location supplied error-text-string: Cannot parse location supplied
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 4 alice.example.com "Cannot parse location Geolocation-Error: 103; "node=bob.example.com";
supplied" "inserter=alice.example.com";
code="Cannot parse location supplied"
3.4.5 Geolocation-Error Code 5 Cannot Find Location 3.4.5 Geolocation-Error Code 104 Cannot Find Location Information
Geolocation-Error code 5 "Cannot find location" means location was Geolocation-Error code 104 "Cannot find location" means location was
expected in the request, but the recipient cannot find it. expected in the request, but the recipient cannot find it.
This can be either because the cid: pointed to a message body part This can be either because the cid: pointed to a message body part
that is not present in the request, there was no location message that is not present in the request, there was no location message
body part, or what is dereferenced at the supplied locationURI did body part, or what is dereferenced at the supplied locationURI did
not return a PIDF-LO, or location is encrypted/opaque to the not return a PIDF-LO, or location is encrypted/opaque to the
recipient. recipient.
A typical reaction to receiving this code is for the location sender A typical reaction to receiving this code is for the location sender
to verify that it has indeed included location information in the to verify that it has indeed included location information in the
request in the properly indicated place and then to send the request request in the properly indicated place and then to send the request
again. again.
error-text-string: Cannot find location error-text-string: Cannot find location
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 5 alice.example.com "Cannot find location" Geolocation-Error: 104; "node=bob.example.com";
"inserter=alice.example.com";
code="Cannot find location"
3.4.6 Geolocation-Error Code 6 Conflicting Locations Supplied 3.4.6 Geolocation-Error Code 105 Conflicting Locations Supplied
Geolocation-Error code 6 "Conflicting Locations Supplied" means a Geolocation-Error code 105 "Conflicting Locations Supplied" means a
Location Recipient received more than one location describing where Location Recipient received more than one location describing where
the Target is, and is either unsure which whole location is true or the Target is, and is either unsure which whole location is true or
which parts of multiple locations make up where the Target is. which parts of multiple locations make up where the Target is.
This is generally a case of either too much information, and the This is generally a case of either too much information, and the
information is pointing towards at least two different positions, information is pointing towards at least two different positions,
confusing the recipient. confusing the recipient.
A possible scenario exists in which at least two locations are in A possible scenario exists in which at least two locations are in
the request, perhaps one or more were added by proxies along the the request, perhaps one or more were added by proxies along the
skipping to change at page 13, line 42 skipping to change at page 15, line 24
request. request.
A typical reaction to receiving this code is to reduce the number of A typical reaction to receiving this code is to reduce the number of
different locations supplied in the request, if under control by the different locations supplied in the request, if under control by the
Target, and send another message to the Location Recipient. Target, and send another message to the Location Recipient.
error-text-string: Conflicting Locations Supplied error-text-string: Conflicting Locations Supplied
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 6 alice.example.com "Conflicting Locations Geolocation-Error: 105; "node=bob.example.com";
Supplied" "inserter=alice.example.com";
code="Conflicting Locations Supplied"
3.4.7 Geolocation-Error Code 7 Incomplete Location Supplied 3.4.7 Geolocation-Error Code 106 Incomplete Location Supplied
Geolocation-Error code 7 "Incomplete Location Supplied" means there Geolocation-Error code 106 "Incomplete Location Supplied" means
is not enough location information, by-value or retrieved there is not enough location information, by-value or retrieved
by-reference, to determine where the location Target is. by-reference, to determine where the location Target is.
Perhaps the coordinate precision is not fine enough, or the civic Perhaps the coordinate precision is not fine enough, or the civic
address lacks the fields to inform the UAS or proxy where the Target address lacks the fields to inform the UAS or proxy where the Target
is. This might be true for request retargeting, or it might be true is. This might be true for request retargeting, or it might be true
for first responder dispatch or pizza delivery (for example, because for first responder dispatch or pizza delivery (for example, because
the street address is missing). the street address is missing).
A typical reaction to receiving this code is for the location sender A typical reaction to receiving this code is for the location sender
to convey more (precise) location information, if doing so is to convey more (precise) location information, if doing so is
allowed by local policy. allowed by local policy.
error-text-string: Incomplete location supplied error-text-string: Incomplete location supplied
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 7 alice.example.com "Incomplete location Geolocation-Error: 106; "node=bob.example.com";
supplied" "inserter=alice.example.com";
code="Incomplete location supplied"
3.4.8 Geolocation-Error Code 8 Cannot Dereference 3.4.8 Geolocation-Error Code 107 Cannot Dereference
Geolocation-Error code 8 "Cannot dereference" means the act of Geolocation-Error code 107 "Cannot dereference" means the act of
dereferencing failed to return the Target's location. This dereferencing failed to return the Target's location. This
generally means the supplied URI is bad. generally means the supplied URI is bad.
error-text-string: Cannot dereference error-text-string: Cannot dereference
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 8 alice.example.com "Cannot dereference" Geolocation-Error: 107; "node=bob.example.com";
"inserter=alice.example.com";
code="Cannot dereference"
3.4.9 Geolocation-Error Code 9 Dereference Denied 3.4.9 Geolocation-Error Code 108 Dereference Denied
Geolocation-Error code 9 "Dereference Denied" means there was Geolocation-Error code 108 "Dereference Denied" means there was
insufficient authorization to dereference the Target's location. insufficient authorization to dereference the Target's location.
error-text-string: Dereference Denied error-text-string: Dereference Denied
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 9 alice.example.com "Dereference Denied" Geolocation-Error: 108; "node=bob.example.com";
"inserter=alice.example.com";
code="Dereference Denied"
3.4.10 Geolocation-Error Code 10 Dereference Timeout 3.4.10 Geolocation-Error Code 109 Dereference Timeout
Geolocation-Error code 10 "Dereference Timeout" means the Geolocation-Error code 109 "Dereference Timeout" means the
dereferencing node has not received the Target's location within a dereferencing node has not received the Target's location within a
reasonable timeframe. reasonable timeframe.
error-text-string: Dereference Timeout error-text-string: Dereference Timeout
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 10 alice.example.com "Dereference Timeout" Geolocation-Error: 109; "node=bob.example.com";
"inserter=alice.example.com";
code="Dereference Timeout"
3.4.11 Geolocation-Error Code 11 Cannot Process Dereference 3.4.11 Geolocation-Error Code 110 Cannot Process Dereference
Geolocation-Error code 11 "Cannot process Dereference" means the Geolocation-Error code 110 "Cannot process Dereference" means the
dereference protocol has received an overload condition error, dereference protocol has received an overload condition error,
indicating the location cannot be accessed at this time. indicating the location cannot be accessed at this time.
If a SIP or SIPS scheme were used to dereference the Target's If a SIP or SIPS scheme were used to dereference the Target's
location, and a 503 (Service Unavailable) were the response to the location, and a 503 (Service Unavailable) were the response to the
dereference query, this Geolocation-Error code 11 would be placed in dereference query, this Geolocation-Error code 11 would be placed in
the 424 (Bad Location Information) response to the location sender. the 424 (Bad Location Information) response to the location sender.
error-text-string: Cannot process Dereference error-text-string: Cannot process Dereference
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 11 alice.example.com "Cannot process Dereference" Geolocation-Error: 110; "node=bob.example.com";
"inserter=alice.example.com";
code="Cannot process Dereference"
3.4.12 Geolocation-Error Code 20 Unsupported Scheme - SIP desired 3.4.12 Geolocation-Error Code 120 Unsupported Scheme - SIP desired
Geolocation-Error code 20 "Unsupported Scheme - SIP desired" means Geolocation-Error code 120 "Unsupported Scheme - SIP desired" means
the location dereferencer cannot dereference using the the location dereferencer cannot dereference using the
location-by-reference URI scheme supplied because it does not location-by-reference URI scheme supplied because it does not
support the necessary protocol to do this. support the necessary protocol to do this.
This code means the Location Recipient can dereference the Target's This code means the Location Recipient can dereference the Target's
location using a SIP-URI scheme. There can be more than one location using a SIP-URI scheme. There can be more than one
locationErrorValue in a Geolocation-Error header, indicating in this locationErrorValue in a Geolocation-Error header, indicating in this
context the recipient can dereference using each scheme protocol context the recipient can dereference using each scheme protocol
included in the Geolocation-Error header. included in the Geolocation-Error header.
skipping to change at page 15, line 48 skipping to change at page 17, line 41
An exception can be made for emergency calling, preferably after An exception can be made for emergency calling, preferably after
SIPS has been attempted, and failed. SIPS has been attempted, and failed.
A typical reaction to receiving this code would be for the location A typical reaction to receiving this code would be for the location
sender to send a URI with the sip scheme. sender to send a URI with the sip scheme.
error-text-string: unsupported scheme - SIP desired error-text-string: unsupported scheme - SIP desired
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 20 alice.example.com "unsupported scheme - SIP Geolocation-Error: 120; "node=bob.example.com";
desired" "inserter=alice.example.com";
code="unsupported scheme - SIP desired"
3.4.13 Geolocation-Error Code 21 Unsupported Scheme - SIPS desired 3.4.13 Geolocation-Error Code 121 Unsupported Scheme - SIPS desired
Geolocation-Error code 21 "Unsupported Scheme - SIPS desired" means Geolocation-Error code 121 "Unsupported Scheme - SIPS desired" means
the location dereferencer cannot dereference using the the location dereferencer cannot dereference using the
location-by-reference URI scheme supplied because it does not location-by-reference URI scheme supplied because it does not
support the necessary protocol to do this. support the necessary protocol to do this.
This code means the Location Recipient can dereference the Target's This code means the Location Recipient can dereference the Target's
location using a SIPS-URI scheme. There can be more than one location using a SIPS-URI scheme. There can be more than one
locationErrorValue in a Geolocation-Error header, indicating in this locationErrorValue in a Geolocation-Error header, indicating in this
context the recipient can dereference using each scheme protocol context the recipient can dereference using each scheme protocol
included in the Geolocation-Error header. included in the Geolocation-Error header.
error-text-string: unsupported scheme - SIPS desired error-text-string: unsupported scheme - SIPS desired
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 21 alice.example.com "unsupported scheme - SIPS Geolocation-Error: 121; "node=bob.example.com";
desired" "inserter=alice.example.com";
code="unsupported scheme - SIPS desired"
3.4.14 Geolocation-Error Code 22 Unsupported Scheme - pres desired 3.4.14 Geolocation-Error Code 122 Unsupported Scheme - pres desired
Geolocation-Error code 22 "Unsupported Scheme - pres desired" means Geolocation-Error code 122 "Unsupported Scheme - pres desired" means
the location dereferencer cannot dereference using the the location dereferencer cannot dereference using the
location-by-reference URI scheme supplied because it does not location-by-reference URI scheme supplied because it does not
support the necessary protocol to do this. support the necessary protocol to do this.
This code means the Location Recipient can dereference the Target's This code means the Location Recipient can dereference the Target's
location using a PRES-URI scheme. There can be more than one location using a PRES-URI scheme. There can be more than one
locationErrorValue in a Geolocation-Error header, indicating in this locationErrorValue in a Geolocation-Error header, indicating in this
context the recipient can dereference using each scheme protocol context the recipient can dereference using each scheme protocol
included in the Geolocation-Error header. included in the Geolocation-Error header.
error-text-string: unsupported scheme - pres desired error-text-string: unsupported scheme - pres desired
An example usage in a SIP 424 response: An example usage in a SIP 424 response:
Geolocation-Error: 22 alice.example.com "unsupported scheme - pres Geolocation-Error: 122; "node=bob.example.com";
desired" "inserter=alice.example.com";
code="unsupported scheme - pres desired"
3.5 The Geolocation Option Tag 3.5 The Geolocation Option Tag
This document creates and IANA registers one new option tag: This document creates and IANA registers one new option tag:
"geolocation". This option tag is to be used, per RFC 3261, in the "geolocation". This option tag is to be used, per RFC 3261, in the
Require, Supported and Unsupported headers. Whenever a UA wants to Require, Supported and Unsupported headers. Whenever a UA wants to
indicate support for this SIP extension, the geolocation option tag indicate support for this SIP extension, the geolocation option tag
is included in a Supported header of the SIP message. is included in a Supported header of the SIP message.
Including the geolocation option-tag within an Unsupported header of Including the geolocation option-tag within an Unsupported header of
a 420 (Bad Extension) response is appropriate when a UAS a 420 (Bad Extension) response is appropriate when a UAS
does not support this Geolocation extension. does not support this Geolocation extension.
A UAC adding this option-tag to a Require header field indicates to A UAC adding this option-tag to a Require header field indicates to
a UAS the UAS MUST support this extension in order to continue a UAS the UAS MUST support this extension in order to continue
processing the message, or send a 420 response back to the UAC. processing the message, or send a 420 response back to the UAC.
Some environments MAY use a Require header in this way, but it Some environments might use a Require header in this way, but it
SHOULD be used with caution to prevent unnecessary communications should be used with caution to prevent unnecessary communications
problems. problems.
A UAC SHOULD NOT include this option tag in a Proxy-Require header, A UAC SHOULD NOT include this option tag in a Proxy-Require header,
since a UAC is not likely to understand the topology of the since a UAC is not likely to understand the topology of the
infrastructure, and therefore would not understand which proxy will infrastructure, and therefore would not understand which proxy will
do the location-based routing function, if any. A potentially bad do the location-based routing function, if any. A potentially bad
scenario would have the first proxy not support this extension, but scenario would have the first proxy not support this extension, but
a subsequent proxy does. This would result in no communications a subsequent proxy does. This would result in no communications
past the first proxy, which MUST send the 420 back under these past the first proxy, which MUST send the 420 back under these
circumstances. circumstances.
3.6 Using sip/sips/pres as a Dereference Scheme 3.6 Using sip/sips/pres as a Dereference Scheme
If a location-by-reference URI is included in a SIP request, in MUST If a location-by-reference (LbyR) URI is included in a SIP request,
be in a locationValue in the Geolocation header and it MUST be a it MUST be in a locationValue in the Geolocation header and it MUST
SIP, SIPS or PRES-URI . When PRES: is used, if the resulting be a SIP, SIPS or PRES-URI . When PRES: is used, if the resulting
resolution, per [RFC3856], resolves to a SIP: or SIPS: URI, this resolution, per [RFC3856], resolves to a SIP: or SIPS: URI, this
section applies. Use of other protocols for dereferencing of a section applies. Use of other protocols for dereferencing of a
PRES: URI is not defined, and such use is subject to review against PRES: URI is not defined, and such use is subject to review against
RFC 3693 Using Protocol criteria. RFC 3693 Using Protocol criteria.
Dereferencing a Target's location using SIP or SIPS MUST be Dereferencing a Target's location using SIP or SIPS MUST be
accomplished by treating the URI as a presence URI and generating a accomplished by treating the URI as a presence URI and generating a
SUBSCRIBE request to a presence server as per [RFC3856]. The SUBSCRIBE request to a presence server as per [RFC3856] using the
resulting NOTIFY will contain a PIDF, which MUST contain a PIDF-LO. 'presence' event package. The resulting NOTIFY will contain a PIDF,
which MUST contain a PIDF-LO. See Figure 2. for a basic message flow
for a dereference.
When used in this manner, SIP is a Using Protocol per [RFC3693] and When used in this manner, SIP is a Using Protocol per [RFC3693] and
elements receiving location MUST honor the 'usage-element' rules as elements receiving location MUST honor the 'usage-element' rules as
defined in this extension. defined in this extension.
Alice Location Server Bob
| |
| INVITE w/ Location-by-Reference URI |
|-------------------------------------------------------->|
| | |
| 200 (OK) |
|<--------------------------------------------------------|
| | |
| | SUBSCRIBE to LbyR URI |
| |<-----------------------------|
| | 200 (OK) |
| |----------------------------->|
| | |
| | NOTIFY w/ PIDF-LO |
| |----------------------------->|
| | 200 (OK) |
| |<-----------------------------|
| | |
Figure 2. Location-by-Reference and Dereferencing
In Figure 2., Alice sends Bob her location in a LbyR URI. Bob
receives this LbyR URI in the INVITE and generates a new transaction
(SUBSCRIBE) to retrieve the PIDF-LO of Alice. If accepted, the
PIDF-LO will be in the NOTIFY request from the Location Server.
This is the first instance between Alice and Bob that Alice's
location is in any message, therefore it is sent only once, from the
Location Server to Bob.
A dereference of a location-by-reference URI using SUBSCRIBE is not A dereference of a location-by-reference URI using SUBSCRIBE is not
violating a PIDF-LO 'retransmission-allowed' element value set to violating a PIDF-LO 'retransmission-allowed' element value set to
'no', as the NOTIFY is the only message in this multi-message set 'no', as the NOTIFY is the only message in this multi-message set
of transactions that contains the Target's location, with the of transactions that contains the Target's location, with the
location recipient being the only SIP element to receive location - location recipient being the only SIP element to receive location -
which is the purpose of this extension: to convey location to a which is the purpose of this extension: to convey location to a
specific destination. specific destination.
4. Geolocation Examples 4. Geolocation Examples
skipping to change at page 19, line 5 skipping to change at page 21, line 31
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: alice123@atlanta.example.com Content-ID: alice123@atlanta.example.com
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<timestamp>2007-07-09T14:00:00Z</timestamp> <timestamp>2007-12-02T14:00:00Z</timestamp>
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:location> <gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>33.001111 -96.68142</gml:pos> <gml:pos>33.001111 -96.68142</gml:pos>
</gml:Point> </gml:Point>
</gml:location> </gml:location>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2007-07-27T18:00:00Z</gp:retention- <gp:retention-expiry>2007-12-07T18:00:00Z</gp:retention-
expiry> expiry>
</gp:usage-rules> </gp:usage-rules>
<gp:method>DHCP</gp:method> <gp:method>DHCP</gp:method>
<gp:provided-by>www.example.com</gp:provided-by> <gp:provided-by>www.example.com</gp:provided-by>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
</presence> </presence>
--boundary1-- --boundary1--
skipping to change at page 20, line 18 skipping to change at page 22, line 44
usage. usage.
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK74bf9 ;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com> Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>
;inserted-by=bigbox3.atlanta.example.com ;recipient=server ;inserted-by=bigbox3.atlanta.example.com ;recipient=both
Supported: geolocation Supported: geolocation
Accept: application/sdp, application/pidf+xml Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:alice@pc33.atlanta.example.com> Contact: <sips:alice@pc33.atlanta.example.com>
...SDP goes here as the only message body ...SDP goes here as the only message body
A Location Recipient would need to dereference the sips-URI in the A Location Recipient would need to dereference the sips-URI in the
Geolocation header field to retrieve Alice's location. If the Geolocation header field to retrieve Alice's location. If the
atlanta.example.com domain chooses to implement location conveyance atlanta.example.com domain chooses to implement location conveyance
skipping to change at page 21, line 6 skipping to change at page 23, line 31
Possession of a dereferenceable location URI can be equivalent to Possession of a dereferenceable location URI can be equivalent to
possession of the location information itself and thus TLS SHOULD be possession of the location information itself and thus TLS SHOULD be
used when transmitting location-by-reference hop-by-hop along the used when transmitting location-by-reference hop-by-hop along the
path to the Location Recipient. path to the Location Recipient.
A PIDF includes identity information. It is possible for the A PIDF includes identity information. It is possible for the
identity in the PIDF to be anonymous. Implementations of this identity in the PIDF to be anonymous. Implementations of this
extension should consider the appropriateness of including an extension should consider the appropriateness of including an
anonymous identity in the location information where a real identity anonymous identity in the location information where a real identity
is not required. When using location-by-reference, it is is not required. When using location-by-reference, it is
RECOMMENDED that the URI does not contain any identifying RECOMMENDED that the URI does not contain any user identifying
information (for example use 3fg5t5yqw@example.com rather than information (for example use 3fg5t5yqw@example.com rather than
alice@example.com). alice@example.com).
Location Recipients MUST obey the privacy and security rules in the Location Recipients MUST obey the privacy and security rules in the
PIDF-LO as described in RFC 4119 regarding retransmission and PIDF-LO as described in RFC 4119 regarding retransmission and
retention. retention.
Self-signed certificates SHOULD NOT be used for protecting a PIDF, Self-signed certificates SHOULD NOT be used for protecting a PIDF,
as the sender does not have a secure identity of the recipient. as the sender does not have a secure identity of the recipient.
More than one location format (civic and coordinate) MAY be included More than one location format (civic and coordinate) MAY be included
in the same message body part, but all location parts of the same in the same message body part, but all location parts of the same
PIDF-LO MUST point at the same position on the earth. The same PIDF-LO MUST point at the same position on the earth. The same
location in multiple formats can allow the recipient to use the most location in multiple formats can allow the recipient to use the most
convenient or preferable format for its use. Multiple PIDF-LOs are convenient or preferable format for its use. Multiple PIDF-LOs are
allowed in the same request, with each allowed to point at separate allowed in the same request, with each allowed to point at separate
positions. positions - because each PIDF-LO has a Target identifier in it.
Therefore, there will be no confusion by a Location Recipient
receiving more than one PIDF-LO (in a message body or when
dereferenced, or a combination).
It is RECOMMENDED there is only one "location" in a single SIP It is RECOMMENDED there is only one "location" in a single SIP
request. This means SIP servers SHOULD NOT add another Request for a given Target. This means SIP servers SHOULD NOT add
locationValue to a SIP request that already contains location. This another locationValue to a SIP request that already contains
will likely lead to confusion at the ultimate location recipient location. This will likely lead to confusion at the ultimate
because this extension does not provide guidance on what a recipient location recipient because this extension does not provide guidance
is to do with more than one location, nor does it give any on what a recipient is to do with more than one location, nor does
preference regarding which location is better or worse than another it give any preference regarding which location is better or worse
location in the same request. than another location in the same request.
It is allowed, but NOT RECOMMENDED, for more than one SIP element to
insert location into a request along its path. As described earlier
in this document, each insertion of location into a SIP request is
accompanied by a locationValue in a Geolocation header. Also
described earlier, each locationValue MUST contain an "inserted-by="
value indicated to a Location Recipient which host inserted location
into a particular request.
5.1 UAC Behavior 5.1 UAC Behavior
A UAC can send location in a SIP request, because it was requested, A UAC can send location in a SIP request, because it is expected
to facilitate location-based routing of the request, or to facilitate location-based routing of the request, or
spontaneously (i.e., a purpose not defined in this document but spontaneously (i.e., a purpose not defined in this document but
known to the UAC). known to the UAC).
A UAC conveying location MUST include a locationValue in a A UAC conveying location MUST include a locationValue in a
Geolocation header (see section 3.2) with either a location-by-value Geolocation header (see section 3.2) with either a location-by-value
indication (a cid-URL), or a location-by-reference indication (a indication (a cid-URL), or a location-by-reference indication (a
dereferenceable URI). A location-by-value message body sent without dereferenceable URI). A location-by-value message body sent without
a Geolocation header field MUST NOT occur. The UAC supporting this a Geolocation header field MUST NOT occur. The UAC supporting this
extension MUST include a Supported header with the geolocation extension MUST include a Supported header with the geolocation
skipping to change at page 22, line 36 skipping to change at page 25, line 21
The UAC MAY include an intended target of this location parameter by The UAC MAY include an intended target of this location parameter by
adding the "recipient=" parameter to the locationValue like this: adding the "recipient=" parameter to the locationValue like this:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by=alice@atlanta.example.com; inserted-by=alice@atlanta.example.com;
recipient=endpoint recipient=endpoint
See section 3.2 for further details about all the header parameters See section 3.2 for further details about all the header parameters
of a locationValue. of a locationValue.
A UAC MAY SUBSCRIBE to a LbyR URI, using the 'presence' event
package, for its own location. The obvious reason for this is for
the UAC to have its LbyV local to it. This document does not give a
reason why a UAC would want to do this.
5.1.1 UAC Receiving a Location Failure Indication
If a sent request failed based on the location in the original If a sent request failed based on the location in the original
request, a 424 (Bad Location Information) response is sent. The UAC request, a 424 (Bad Location Information) response is sent back to
should receive a Geolocation-Error header in any response message. the UAC. The 424 MUST have a Geolocation-Error header containing
The Geolocation-Error has a header parameter indicating which entity one or more locationErrorValues in the response message. A
inserted the location pertaining to this error. This is in the form locationErrorValue has a header parameter indicating which entity
of a host-id. A UAC receiving this 424 should review this inserted the location pertaining to this error, called the
"inserter=" locationErrorValue parameter to see if it indicates this "inserter=" parameter. This "inserter=" parameter is copied from
UAC. If it does not, the 424 should be ignored. If this value the "inserted-by=" parameter of the locationValue by the UAS or
does, 424 is intended for this UAC, and MUST process the response, proxy sending the error response. A UAC receiving this 424 should
including the Geolocation-Error code (defined in section 3.4). The review this "inserter=" parameter in the locationErrorValue to see
UAC SHOULD take correct steps to rectify future errors, based on the if it indicates this UAC. If locationErrorValue does not, the
received error code, to increase the possibility of less request locationErrorValue should be ignored, and the response SHOULD be
failures going forward. A UAC MAY reattempt a new request if it treated as a 4XX response. If locationErrorValue does indicate this
believes it can correct the stated failure in the Geolocation-Error UAC, this UAC MUST process the response, including the
header. Geolocation-Error code (defined in section 3.4).
In addition to the error code, there MAY be a list of CAtypes in the
locationErrorValue. If there are any, these are what the UAS or
proxy determined was wrong with the location contained in the
original response. The listed CAtypes will not contain the values
sent by the UAC in the request. This is for security/privacy
reasons.
The UAC SHOULD take correct steps to rectify future errors, based on
the received error code and any CAtypes listed, to increase the
probability of successful requests in the future. A UAC MAY
reattempt a new request if it believes it can correct the stated
failure in the Geolocation-Error header.
Any UAC that inserted location into a request should be prepared to Any UAC that inserted location into a request should be prepared to
receive the Geolocation-Error header in any response, looking to receive the Geolocation-Error header in any response, looking to
determine if the header is meant for the UAC, and to react determine if the header is meant for the UAC, and to react
accordingly. accordingly.
If a UAC includes location in a request, and either the UAS does not
determine errored location was critical to the transaction and
accept the request, or the request failed for another reason than
location, any response MAY contain a Geolocation-Error header
containing a locationErrorValue with the details of the location
error.
5.2 UAS Behavior 5.2 UAS Behavior
If the Geolocation header field is present in a received SIP If the Geolocation header field is present in a received SIP
request, the type of URI contained in the locationValue will request, the type of URI contained in the locationValue will
indicate if location has been conveyed by-value in a message body indicate if location has been conveyed by-value in a message body
(part) or by-reference, requiring an additional dereference (part) or by-reference, requiring an additional dereference
transaction. If the by-reference URI is sip:, sips: or pres:, the transaction. If the by-reference URI is sip:, sips: or pres:, the
UAS MUST initiate a SUBSCRIBE to the URI provided to retrieve the UAS MUST initiate a SUBSCRIBE to the URI provided to retrieve the
PIDF-LO being conveyed by the UAC per [RFC3856]. If successful, the PIDF-LO being conveyed by the UAC per [RFC3856]. If successful, the
PIDF-LO will be returned in the NOTIFY request from the server. PIDF-LO will be returned in the NOTIFY request from the remote host.
A Require header with the geolocation option tag indicates the A Require header with the geolocation option tag indicates the
UAC is requiring the UAS to understand this extension or else send UAC is requiring the UAS understand this extension or else send
an error response. A 420 (Bad Extension) with a geolocation option an error response. A 420 (Bad Extension) with a geolocation option
tag in a Unsupported header would be the appropriate response in tag in an Unsupported header would be the appropriate response in
this case. this case.
In the undesired situation in which location is conveyed without a It is possible, but undesirable, for a message to arrive with a body
Geolocation header, that contains the URI of where the location is, containing a location-by-value, but with no Geolocation header field
the UAS MUST be able to read a location-by-value message body. A value pointing to it (potentially no Geolocation header field at
Location-by-reference URI MUST NOT be placed in any other SIP header all). In this case, the recipient MAY still read and use the message
than Geolocation. body. Unless stated otherwise by future standards-track
publications, a Location-by-reference URI only has meaning within
If the UAC conveys location in a request, but the UAS has one or the Geolocation header field and MUST NOT appear in any other SIP
more problems with each location in the request (or while attempting header field.
to dereference the UAC's location), the UAS MUST indicate what
problem was experienced with the location in the request. A
Geolocation-Error header is how the UAS informs the UAC of a
location-based error within the request. Section 3.4 lists these
errors, which are all IANA registered.
The Geolocation-Error header is permitted in any response. For
example, Bob can reply to Alice with a 486 because he's not willing
to accept the call at this time, and inform Alice that the location
contained in the request was bad in some way. In this case, the 486
would contain a Geolocation-Error header indicating the specific
location error experienced
If the request had a Require header with a geolocation option-tag,
then a 424 (Bad Location Information) response would be an
appropriate response. This 424 would include a locationErrorValue
in a Geolocation-Error header.
Because this extension allows more than one locationValue,
potentially from more than SIP entity, there needs to be a means of
identifying which entity inserted a particular locationValue for
error response purposes. Also, there needs to be a means to inform
that entity what the Location Recipient considered in error with
that locationValue.
If a Geolocation locationValue is present in a request, it can There are 3 Geolocation header parameters,
contain as many as three header parameters, "inserted-by=",
"used-for-routing" and "recipient=" parameters.
The "inserted-by" parameter in the locationValue of the request that o "inserted-by="
had errors in it is copied into the "inserter=" parameter of the o "used-for-routing"
locationErrorValue of the Geolocation-Error header of the response. o "recipient="
This SHOULD happen for each location that was considered bad by the
UAS to ensure each location inserter understands which error code(s)
is intended for them.
Further, more than one error code is allowed in the The "inserted-by=" parameter informs a Location Recipient which SIP
locationErrorValue - each having an "inserter=" parameter. The element added this locationValue to the SIP request. This parameter
error codes destined for the same inserter MUST NOT contradict the is mandatory for each locationValue in the request. The value in
meaning of the problem the UAS had with a particular locationValue. the "inserted-by=" parameter is copied into the "inserter="
parameter in each locationErrorValue if there is an error in the
location to be reported back to the location sender. See section
5.2.1.
If a locationValue contains the "inserted-by=" parameter, the The "used-for-routing" parameter is included in the locationValue if
recipient will learn the SIP entity who added that locationValue. a SIP server used the location in the request to determine how to
route or forward the message towards the ultimate destination. If
there are more than one locationValue in the Geolocation header, and
it is possible that different locationValues were used to route the
message at different times of this request's journey. This is
allowed, as it is consistent with the rule that anytime a message is
routed based upon a locationValue, a "used-for-routing" parameter is
added to the applicable locationValue. This parameter should be
present in each locationValue used along the path.
If a Geolocation locationValue contains the "used-for-routing" More than one locationValue inserted in a request should be placed
parameter, the UAS will learn which location was used to retarget the order it was placed, and not rearranged. This informs a
this request towards this UAS. This parameter MAY be present in Location Recipient which was the last locationValue in the message
each locationValue within the Geolocation header (meaning up to one that was used to route the message. This is for troubleshooting and
per locationValue). locationValues are placed into the Geolocation management reasons.
header in an order. The location inserted first, remains first in
the header. A subsequence locationValue is placed next in the
header (and so on). The last locationValue in the header was the
most recently added locationValue to the request. From this
order, the more recent "used-for-routing" parameter, if present, was
the locationValue used for retargeting this request at this UAS. In
this case, a "used-for-routing" parameter on a previous
locationValue should be ignored, except perhaps in the case of
after-the-fact analysis of how a request took the whole path it
took.
The "recipient=" header parameter allow recipients to infer the SIP The "recipient=" header parameter allow recipients to infer the SIP
entity type this locationValue is intended to be for. The types are entity type this locationValue is intended to be for. The types are
"endpoint", meaning the ultimate destination UAS; "routing-entity", "endpoint", meaning the ultimate destination UAS; "routing-entity",
meaning SIP servers; and "both" meaning this locationValue is to be meaning SIP servers; and "both" meaning this locationValue is to be
viewed by both types of SIP entities. viewed by both types of SIP entities.
If there are any header parameters in a received locationValue, Individual header parameters in any received locationValue MUST NOT
they MUST NOT be modified or deleted in transit to the ultimate be modified or deleted in transit to the ultimate destination.
destination.
A UAS MUST NOT send location in a response message, as there can be
any number of issues/problems with receiving location, and the UAC
or proxy servers cannot error a response. Therefore, the UAS, if it
wants to send a UAC its location, SHOULD do so in a new request in a
separate transaction. This document gives no guidance which SIP
request to use.
A UAS MAY include a geolocation option-tag in the Supported header
of a response, indicating it does understand this extension, even if
location was not in a request to the UAS.
A UAS wishing to dereference a location-by-reference URI contained
in a received request will use the 'presence' event package in a
SUBSCRIBE request to the URI. If accepted, the PIDF-LO will return
to the UAS in a NOTIFY request. If there are any errors during
dereferencing, or in the PIDF-LO itself, the UAS will error the
original request to the UAC with a locationErrorValue indicating
what the UAS concluded was wrong with the location. This is to
include any dereferencing problems encountered.
5.2.1 UAS Generating a Location Failure Indication
If a received request conveys location, but the UAS has one or
more problems with a locationValue in the request (to include while
attempting to dereference the UAC's location), the UAS MUST indicate
each problem experienced with the location in the request in a
424 (Bad Location Information) response back to the inserting
entity if the UAS wants to reject the request because of the
location. A Geolocation-Error header is how the UAS informs the UAC
of a location-based error within the request. Section 3.4 lists
these errors, which are all IANA registered.
Because this extension to SIP allows more than one locationValue in
a Geolocation header, each from separate SIP entities, there
needs to be a means of identifying which entity inserted a
particular locationValue for single error response purposes. This
is further complicated because SIP sends a single rejection
response, that in this case, needs to go to more than one entity,
and be ignored by all other entities not identified in such a way as
to not confuse other SIP entities.
Each locationValue has an "inserted-by=" parameter identifying which
SIP entity added this locationValue to the request. This value is
copied to the locationErrorValue "inserter=" parameter if one needs
to be sent, thus identifying the intended target of this
locationErrorValue. This locationErrorValue is ignored by all other
receivers of this SIP response.
Each locationErrorValue can have more than one error code within it.
Each locationErrorValue is destined for one "inserter=" entity.
This gives a UAS one mechanism to tell each inserter what the
Location Recipient concluded was wrong with what the inserter
included (as far as location is concerned). Therefore,
o there MUST be a locationErrorValue for each locationValue that
was considered bad by the UAS to ensure each upstream location
inserter understands which error code(s)is intended for them (and
which to ignore).
o if the PIDF-LO (received by-value or after dereference) contains
civic CAtypes that the Location Recipient considers malformed or
bad, each CAtype SHOULD be listed in the locationErrorValue to
inform the "inserter=" entity what specifically was wrong with
the locationValue, in addition to the error code. Without these
details, the location inserter might not know what part was
malformed or incomplete about the information supplied in the
request.
o the CAtype values MUST NOT be sent along with the CAtype names
listed in the locationErrorValue. This is for privacy/security
reasons.
o there MUST NOT be more than one locationErrorValue in the
response per locationValue in the request.
o there MUST NOT be more than one locationErrorValue in the
response for the same locationValue in the request.
o there MUST NOT be a locationErrorValue in the response for a
locationValue in the request that was not in error, according to
the Location Recipient.
Here is an example of a Geolocation-Error header
Geolocation-Error: 106; "node=bob.example.com";
"inserter=alice.example.com";
CAtype=A3; CAtype=STS;
code="incomplete location supplied"
See Section 3.4 for further rules about the Geolocation-Error header
and the locationErrorValue.
The Geolocation-Error header is permitted in any response. For
example, Bob can reply to Alice with a 486 because he's not willing
to accept the call at this time, and inform Alice that the location
contained in the request was bad in some way. In this case, the 486
would contain a Geolocation-Error header indicating the specific
location error experienced
If there is more than one locationValue in a request, and any one of If there is more than one locationValue in a request, and any one of
them is valid (i.e., one contains enough information to not generate them is valid (i.e., one contains enough information to not generate
a 424 if that was the only location present in the request), all a 424 if that was the only location present in the request), all
other locations MAY be ignored, and a 424 MUST NOT be sent because other locations MAY be ignored, and a 424 MUST NOT be sent because
of these other locations in the request. Another response MAY be of these other locations in the request. Another response MAY be
sent, which includes a locationErrorValue. This document says sent, which includes a locationErrorValue. This document says
nothing about what a Location Recipient does with more than one nothing about what a Location Recipient does with more than one
'good' location in a request (i.e., which to choose to use). 'good' location in a request (i.e., which to choose to use).
Further, more than one error code is allowed in the
locationErrorValue - each having an "inserter=" parameter. The
error codes destined for the same inserter MUST NOT contradict the
meaning of the problem the UAS had with a particular locationValue.
A Geolocation-Error is permissible in a 200 OK response. This means A Geolocation-Error is permissible in a 200 OK response. This means
everything else in the request was acceptable, but the location was everything else in the request was acceptable, but the location was
not for a given error code(s). One exception to this set of rules not for a given error code(s). One exception to this set of rules
is if a geolocation option-tag was in the Require header in the is if a geolocation option-tag was in the Require header in the
request. This would necessitate a 424 response. request. This would necessitate a 424 response.
A UAS MUST NOT send location in a response message, as there can be
any number of issues/problems with receiving location, and the UAC
or proxy servers cannot error a response. Therefore, the UAS, if it
wants to send a UAC its location, SHOULD do so in a new request in a
separate transaction. This document give no guidance which request
to use.
A UAS MAY include a geolocation option-tag in the Supported header
of a response, indicating if does understand this extension.
5.3 Proxy Behavior 5.3 Proxy Behavior
[RFC3261] states message bodies cannot be added by proxies. [RFC3261] states message bodies cannot be added by proxies.
However, proxies are permitted to add a header to a request. This However, proxies are permitted to add a header to a request. This
implies that a proxy can add a Geolocation locationValue with implies that a proxy can add a Geolocation locationValue with
location-by-reference URI, but not location-by-value message body. location-by-reference URI, but not location-by-value message body.
However, if location is already in a SIP request, a SIP server However, if location is already in a SIP request, a SIP server
SHOULD NOT add another instance of the UAC's location to the same SHOULD NOT add another instance of the UAC's location to the same
request. This will likely cause confusion at the Location Recipient request. This will likely cause confusion at the Location Recipient
as to which to use. This document gives no guidance how a UAS is to as to which to use. This document gives no guidance how a UAS is to
skipping to change at page 25, line 48 skipping to change at page 30, line 26
A proxy is permitted to read any locationValue, and the associated A proxy is permitted to read any locationValue, and the associated
body, if not S/MIME protected, in transit if present, and MUST use body, if not S/MIME protected, in transit if present, and MUST use
the contents of the header field to make location-based retargeting the contents of the header field to make location-based retargeting
decisions, if retargeting requests based on location is a function decisions, if retargeting requests based on location is a function
of that proxy. of that proxy.
More than one Geolocation locationValue in a message is permitted, More than one Geolocation locationValue in a message is permitted,
but can cause confusion at the recipient. If a proxy chooses to add but can cause confusion at the recipient. If a proxy chooses to add
a locationValue to a Geolocation header, which would be a local a locationValue to a Geolocation header, which would be a local
policy decision, the new locationValue MUST be added to the end of policy decision, the new locationValue MUST be added to the end of
the header (after previous locationValue(s)). This to create an the header (after previous locationValue(s)). This is done to
order of insertion of locationValues along the path. Proxies MUST create an order of insertion of locationValues along the path.
NOT modify the order of locationValues in a geolocation header. Proxies MUST NOT modify the order of locationValues in a geolocation
header.
A proxy wishing to dereference a location-by-reference URI contained
in a received request will use the 'presence' event package in a
SUBSCRIBE request to the URI. If accepted, the PIDF-LO will return
to the proxy in a NOTIFY request. If there are any errors during
dereferencing, or in the PIDF-LO itself, the proxy will error the
original request to the UAC with a locationErrorValue indicating
what the proxy concluded was wrong with the location. This is to
include any dereferencing problems encountered.
5.3.1 Proxy Behavior with Geolocation Header Parameters 5.3.1 Proxy Behavior with Geolocation Header Parameters
SIP servers MUST NOT delete any existing Geolocation locationValue SIP servers MUST NOT delete any existing Geolocation locationValue
(URI or header parameter) from a request. A Geolocation (URI or header parameter) from a request. A Geolocation
locationValue (URI or header parameter) MAY only be modified to by locationValue (URI or header parameter) MAY only be modified to by
adding a "used-for-routing" parameter to an existing locationValue, adding a "used-for-routing" parameter to an existing locationValue,
if the request was retargeted based on the location within that if the request was retargeted based on the location within that
locationValue. Further modification of this Geolocation header locationValue. Further modification of this Geolocation header
field MUST NOT occur. For example, an existing Geolocation field MUST NOT occur. For example, an existing Geolocation
locationValue in a request of: locationValue in a request of:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by=alice123@atlanta.example.com; inserted-by=alice123@atlanta.example.com;
can be modified by a proxy to add the "used-for-routing" parameter, can be modified by a proxy to add the "used-for-routing" parameter,
like this: like this:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by=alice@atlanta.example.com; inserted-by=alice123@atlanta.example.com;
used-for-routing used-for-routing
if this is the locationValue the proxy used to make a retargeting if this is the locationValue the proxy used to make a retargeting
decision based upon, but make no other modification. decision based upon, but make no other modification.
A SIP server MAY add a new Geolocation locationValue to a SIP A SIP server MAY add a new Geolocation locationValue to a SIP
request. The proxy SHOULD NOT insert a locationValue of the UAC request. The proxy SHOULD NOT insert a locationValue of the UAC
unless it is reasonably certain it knows the actual location of the unless it is reasonably certain it knows the actual location of the
endpoint, for example, if it thoroughly understands the topology of endpoint, for example, if it thoroughly understands the topology of
the underlying access network and it can identify the device the underlying access network and it can identify the device
reliably (in the presence of, for example, NAT). reliably (in the presence of, for example, NAT).
B2BUAs MUST set the "inserted-by" header parameter with their
Host-ID. This is for error mapping reasons.
A server adding a locationValue to an existing Geolocation header A server adding a locationValue to an existing Geolocation header
would look like: would look like:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by=alice@atlanta.example.com, inserted-by=alice123@atlanta.example.com,
<sips:3sdefrhy2jj7@lis1.atlanta.example.com>; <sips:3sdefrhy2jj7@lis1.atlanta.example.com>;
inserted-by=lis1.atlanta.example.com; inserted-by=lis1.atlanta.example.com;
Notice the locationValue added by the proxy is last among Notice the locationValue added by the proxy is last among
locationValues. This practice MUST be done for all added locationValues. This practice MUST be done for all added
locationValues. locationValues.
If this request was then retargeted by an intermediary using the If this request was then retargeted by an intermediary using the
locationValue inserted by the server, the intermediary would add a locationValue inserted by the server, the intermediary would add a
"used-for-routing" parameter like this: "used-for-routing" parameter like this:
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by=alice@atlanta.example.com, inserted-by=alice123@atlanta.example.com,
<sips:3sdefrhy2jj7@lis1.atlanta.example.com>; <sips:3sdefrhy2jj7@lis1.atlanta.example.com>;
inserted-by=lis1.atlanta.example.com; used-for-routing inserted-by=lis1.atlanta.example.com; used-for-routing
It is conceivable that an initial routing decision is made on an It is conceivable that an initial routing decision is made on an
one locationValue, and subsequently another routing decision is one locationValue, and subsequently another routing decision is
made on a different locationValue. This retargeting decision can be made on a different locationValue. This retargeting decision can be
made on a newly inserted locationValue. While unusual, it can made on a newly inserted locationValue. While unusual, it can
occur. In such a case, proxies MUST NOT remove any existing occur. In such a case, proxies MUST NOT remove any existing
"used-for-routing" header parameter. In this instance, the SIP "used-for-routing" header parameter. In this instance, the SIP
server retargeting based on another locationValue MUST add the server retargeting based on another locationValue MUST add the
"used-for-routing" header parameter to the locationValue used for "used-for-routing" header parameter to the locationValue used for
retargeting by this server. This will result in a Geolocation retargeting by this server. This will result in a Geolocation
header looking as if it were retargeting more than once, which would header looking as if it were retargeting more than once, which would
be true - and is the desired outcome. be true - and is the desired outcome.
5.3.2 Proxy Error Behavior with Geolocation-Error Codes 5.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues
If a proxy determines there is an error within an existing For proxies that receive a SIP request that contains a location
locationValue, the proxy SHOULD provide a suitable error response. error, either in a contained message body or after the proxy does a
The 424 (Bad Location Information) is the appropriate location-based dereference of the LbyR URI, all the rules applicable to a UAS apply
error response here. The 424 MUST contain a Geolocation-Error here (see Section 5.2.1.), since in this case, the proxy is
header (see section 3.4). If a proxy errors a request for some considered a Location Recipient. Therefore, there is no reason to
other reason than location, and there is a location error also in restate them here, and potentially have the two section be
the request, the Geolocation-Error (see section 3.4) SHOULD be added inconsistent. The one thing to add is that a proxy does not need to
to the response, to inform the UAC of all the errors in the request. examine location contained in a request. Section 5.2.1. only applies
to proxies that are monitoring or policing location within requests
(for whatever reason).
The proxy making the error decision copies the host-id value from If a proxy inserted a locationValue into a request, it SHOULD be
the "inserted-by=" locationValue of the Geolocation header into the ready to examine the response to that request, in case there is one
host-id value of the "inserter=" locationErrorValue of the or more location errors in the response. To a great degree, this
Geolocation-Error header. This ensures the error is targeted at the scenario has the proxy behaving as a UAC (see section 5.1.1.) that
entity that inserted the bad location. More than one error can be included a locationValue a request, which then receives an error to
present for each locationValue. These error are in the that locationValue.
locationErrorValue of the response. Each locationErrorValue will
have one "inserter=" value. Thus, the number of locationErrorValues If there is one or more locationErrorValues in the response, the
in a response cannot exceed the number of locationValues in the proxy SHOULD examine each "inserter=" parameter in each
request - all within the same transaction. This ensures each error locationErrorValue - looking for one that identifies the proxy. If
type is received properly by the offending location inserter. one matches the proxy's "inserted-by" value, that locationErrorValue
is for only that proxy. This locationErrorValue needs to be reviewed
for each error code and CAtype contained in the value. The proxy
SHOULD attempt to correct for the error reported to it for future
insertion of location into requests. This document gives no
guidance what the proxy should do to rectify the bad location
information, but a future document MAY address this.
6. Geopriv Privacy Considerations 6. Geopriv Privacy Considerations
Transmitting location information is considered by most to be highly Transmitting location information is considered by most to be highly
sensitive information, requiring protection from eavesdropping, sensitive information, requiring protection from eavesdropping,
tracking, and altering in transit. [RFC3693] articulates rules to tracking, and altering in transit. [RFC3693] articulates rules to
be followed by any protocol wishing to be considered a Geopriv be followed by any protocol wishing to be considered a Geopriv
"Using Protocol", specifying how a transport protocol meetings "Using Protocol", specifying how a transport protocol meetings
those rules. This section describes how SIP as a Using Protocol those rules. This section describes how SIP as a Using Protocol
meets those requirements. meets those requirements.
skipping to change at page 28, line 55 skipping to change at page 33, line 47
mechanism such as S/MIME is problematic, because one or more proxies mechanism such as S/MIME is problematic, because one or more proxies
on the path need the ability to read the location information to on the path need the ability to read the location information to
retarget the message to the appropriate new destination UAS. retarget the message to the appropriate new destination UAS.
Securing the location hop-by-hop, using TLS, protects the message Securing the location hop-by-hop, using TLS, protects the message
from eavesdropping and modification, but exposes the information to from eavesdropping and modification, but exposes the information to
all proxies on the path as well as the endpoint. In most cases, the all proxies on the path as well as the endpoint. In most cases, the
UAC does not know the identity of the proxy or proxies providing UAC does not know the identity of the proxy or proxies providing
location-based routing services, so that end-to-middle solutions location-based routing services, so that end-to-middle solutions
might not be appropriate either. might not be appropriate either.
These same issue exist for basic SIP signaling, but SIP normally These same issues exist for basic SIP signaling, but SIP normally
does not carry information to physically track a user; making this does not carry information to physically track a user; making this
extension especially sensitive, unfortunately. extension especially sensitive.
When location is inserted by a UAC, which is RECOMMENDED, it can When location is inserted by a UAC, which is RECOMMENDED, it can
decide whether to reveal its location using hop-by-hop methods. UAC decide whether to reveal its location using hop-by-hop methods. UAC
implementations MUST make such capabilities conditional on explicit implementations MUST make such capabilities conditional on explicit
user permission, and SHOULD alert a user that location is being user permission, and SHOULD alert a user that location is being
conveyed. Proxies inserting location for location-based routing are conveyed. Proxies inserting location for location-based routing are
unable to meet this requirement, and such use is NOT RECOMMENDED. unable to meet this requirement, and such use is NOT RECOMMENDED.
Proxies conveying location using this extension MUST have the Proxies conveying location using this extension MUST have the
permission of the Target to do so. permission of the Target to do so.
skipping to change at page 29, line 35 skipping to change at page 34, line 27
Consider, specifically, a nomadic user connected to an access Consider, specifically, a nomadic user connected to an access
network in a hotel. The UAC has no way to provide a credential network in a hotel. The UAC has no way to provide a credential
acceptable to the hotel Location Server (LS) to any of its intended acceptable to the hotel Location Server (LS) to any of its intended
Location Recipients. The recipient of a reference does not know if Location Recipients. The recipient of a reference does not know if
a reference has appropriate authorization policies or not. The LS a reference has appropriate authorization policies or not. The LS
should provide location to any requestor. should provide location to any requestor.
Accordingly, possession of the reference should be considered Accordingly, possession of the reference should be considered
equivalent to possession of the value, and the reference should be equivalent to possession of the value, and the reference should be
treated with the same degree of care as the value. Specifically, treated with the same degree of care as the value. Specifically,
TLS MUST be used to protect the security of the reference. TLS MUST be used to protect the security of the reference. Notice
that this does not constrain the dereference protocol to use TLS.
That specification is left entirely to the dereferencing protocol
Because SIP servers can add location in transit, made more easy of Because SIP servers can add location in transit, made more easy of
the server is a Session Border Controller or B2BUA, this might cause the server is a Session Border Controller or B2BUA, this might cause
there to be conflicting location information (error-code=6), which there to be conflicting location information (error-code=6), which
could be purposeful to error the request or just cause operation could be purposeful to error the request or just cause operation
problems. This problem might be inadvertent, compounded by the fact problems. This problem might be inadvertent, compounded by the fact
that there will likely be some SIP servers that add location on that there will likely be some SIP servers that add location on
every call set-up. every call set-up.
There is no integrity on any locationValue or locationErrorValue There is no integrity on any locationValue or locationErrorValue
header parameter, so recipients of either header need to implicitly header parameter, so recipients of either header need to implicitly
trust the header contents, and take whatever precautions each entity trust the header contents, and take whatever precautions each entity
deems appropriate give these facts. deems appropriate give these facts.
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 these registrations
require a standards track RFC. require a standards track RFC (Standards Action).
8.1 IANA Registration for the SIP Geolocation Header 8.1 IANA Registration for the SIP Geolocation Header
The SIP Geolocation header is created by this document, with its The SIP Geolocation header is created by this document, with its
definition and rules in Section 3.2 of this document, to be added to definition and rules in Section 3.2 of this document, to be added to
the sip-parameters. the sip-parameters.
The Geolocation Header has the following header parameters to be The Geolocation Header has the following header parameters to be
Registered in a new table: Registered in a new table:
Geolocation Header parameters Geolocation Header parameters
Header Parameters Parameter-values Reference Header Parameters Parameter-values Reference
---------------- ---------------- -------------- ---------------- ---------------- --------------
inserted-by (string) RFC XXXX (this document)
used-for-routing N/A RFC XXXX (this document)
recipient endpoint RFC XXXX (this document) recipient endpoint RFC XXXX (this document)
recipient routing-entity RFC XXXX (this document) recipient routing-entity RFC XXXX (this document)
recipient both RFC XXXX (this document) recipient both RFC XXXX (this document)
8.2 IANA Registration for New SIP Option Tag 8.2 IANA Registration for New SIP Option Tag
The SIP option-tag "geolocation" is created by this document, with The SIP option-tag "geolocation" is created by this document, with
the definition and rule in Section 3.5 of this document, to be added the definition and rule in Section 3.5 of this document, to be added
to sip-parameters within IANA. to sip-parameters within IANA.
skipping to change at page 31, line 13 skipping to change at page 35, line 51
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, to place into SIP response messages to inform Location Recipients, to place into SIP response messages to inform
the location inserter of the error. the location inserter of the error.
Code Description Reference Code Description Reference
---- --------------------------------------------------- --------- ---- --------------------------------------------------- ---------
1 Location Format Not Supported: the location format [this doc] 100 Location Format Not Supported: the location format [this doc]
supplied in the request, by-value or by-reference, supplied in the request, by-value or by-reference,
was not supported. was not supported.
2 Coordinate-location Format Desired: the location [this doc] 101 Coordinate-location Format Desired: the location [this doc]
format supplied in the request was understood format supplied in the request was understood
and supported, but that the recipient, or an and supported, but that the recipient, or an
application on the recipient, can or prefers to application on the recipient, can or prefers to
only process location in the coordinate-location only process location in the coordinate-location
format. format.
3 Civic-location Format Desired: the location [this doc] 102 Civic-location Format Desired: the location [this doc]
format supplied in the request was understood format supplied in the request was understood
and supported, but that the recipient, or an and supported, but that the recipient, or an
application on the recipient, can or prefers to application on the recipient, can or prefers to
only process location in the civic-location only process location in the civic-location
format. format.
4 Cannot Parse Location Supplied: the location [this doc] 103 Cannot Parse Location Supplied: the location [this doc]
provided, whether by-value or by-reference, in a provided, whether by-value or by-reference, in a
request is not well formed. request is not well formed.
5 Cannot Find Location: the location was expected in [this doc] 104 Cannot Find Location: the location was expected in [this doc]
the request, but the recipient cannot find it. the request, but the recipient cannot find it.
6 Conflicting Locations Supplied: a Location Recipient [this doc] 105 Conflicting Locations Supplied: a Location Recipient [this doc]
received more than one location describing where the received more than one location describing where the
Target is, and is either unsure which whole location Target is, and is either unsure which whole location
is true or which parts of multiple locations make up is true or which parts of multiple locations make up
where the Target is. where the Target is.
7 Incomplete Location Supplied: there is not enough [this doc] 106 Incomplete Location Supplied: there is not enough [this doc]
location information in the request to determine location information in the request to determine
where the location Target is. where the location Target is.
8 Cannot Dereference: the act of dereferencing failed [this doc] 107 Cannot Dereference: the act of dereferencing failed [this doc]
to return the Target's location. This generally to return the Target's location. This generally
means the supplied URI is bad. means the supplied URI is bad.
9 Dereference Denied: there was insufficient [this doc] 108 Dereference Denied: there was insufficient [this doc]
authorization to dereference the Target's location. authorization to dereference the Target's location.
10 Dereference Timeout: the dereferencing node has not [this doc] 109 Dereference Timeout: the dereferencing node has not [this doc]
received the Target's location within a reasonable. received the Target's location within a reasonable.
timeframe timeframe
11 Cannot Process Dereference: the dereference protocol [this doc] 110 Cannot Process Dereference: the dereference protocol [this doc]
has received an overload condition error, indicating has received an overload condition error, indicating
the location cannot be accessed at this time. the location cannot be accessed at this time.
20 Unsupported Scheme - sip desired: the location [this doc] 120 Unsupported Scheme - sip desired: the location [this doc]
dereferencer cannot dereference using the dereferencer cannot dereference using the
location-by-reference URI scheme supplied, and location-by-reference URI scheme supplied, and
prefers a sip-uri. prefers a sip-uri.
21 Unsupported Scheme - sips desired: the location [this doc] 121 Unsupported Scheme - sips desired: the location [this doc]
dereferencer cannot dereference using the dereferencer cannot dereference using the
location-by-reference URI scheme supplied, and location-by-reference URI scheme supplied, and
prefers a sips-uri. prefers a sips-uri.
22 Unsupported Scheme - pres desired: the location [this doc] 122 Unsupported Scheme - pres desired: the location [this doc]
dereferencer cannot dereference using the dereferencer cannot dereference using the
location-by-reference URI scheme supplied, and location-by-reference URI scheme supplied, and
prefers a pres-uri. prefers a pres-uri.
9. Acknowledgements 9. Acknowledgements
To Dave Oran for helping to shape this idea. To Jon Peterson and To Dave Oran for helping to shape this idea. To Jon Peterson and
Dean Willis on guidance of the effort. To Allison Mankin, Dick Dean Willis on guidance of the effort. To Allison Mankin, Dick
Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom,
Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith
Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat, Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat,
Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie, Robert Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie and Matt
Sparks and Matt Lepinski for constructive feedback. A special Lepinski for constructive feedback. A special thanks to Dan Wing
thanks to Dan Wing for help with the S/MIME example. for help with the S/MIME example, and to Robert Sparks for many
helpful comments and the proper building of the Geolocation-Error
header.
10. References 10. References
10.1 References - Normative 10.1 References - Normative
[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
skipping to change at page 33, line 24 skipping to change at page 38, line 17
[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging" , RFC 3428, December 2002 Instant Messaging" , RFC 3428, December 2002
[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002 Method", RFC 3311, October 2002
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol (SIP)",
RFC 3262, June 2002.
[IANA-civic] http://www.iana.org/assignments/civic-address-types-
registry
10.2 References - Informative 10.2 References - Informative
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004 "Geopriv Requirements", RFC 3693, February 2004
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", draft-ietf-geopriv-dhcp-civil-09, "work in Information ", draft-ietf-geopriv-dhcp-civil-09, "work in
skipping to change at page 35, line 4 skipping to change at page 40, line 5
UAC-8 The PIDF-LO [RFC 4119] is a mandatory to implement format for UAC-8 The PIDF-LO [RFC 4119] is a mandatory to implement format for
location conveyance within SIP, whether included by-value or location conveyance within SIP, whether included by-value or
by-reference. by-reference.
Motivation: interoperability with other IETF location protocols and Motivation: interoperability with other IETF location protocols and
mechanisms mechanisms
UAC-9 There must be a mechanism for the UAC to request the UAS send UAC-9 There must be a mechanism for the UAC to request the UAS send
its location its location
UAC-9 has been DEPRECATED by the SIP WG, due to the many
problems this requirement would have caused if implemented.
The solution is for the above UAS to send a new request to
the original UAC with the UAS's location.
UAC-10 There must be a mechanism to differentiate the ability of the UAC-10 There must be a mechanism to differentiate the ability of the
UAC to convey location from the UACs lack of knowledge of its UAC to convey location from the UACs lack of knowledge of its
location location
Motivation: Failure to receive location when it is expected can be Motivation: Failure to receive location when it is expected can be
because the UAC does not implement this extension, or it can because the UAC does not implement this extension, or it can
be that the UAC implements the extension, but does not know be that the UAC implements the extension, but does not know
where it is. This may be, for example, due to the failure of where it is. This may be, for example, due to the failure of
the access network to provide a location acquisition the access network to provide a location acquisition
mechanisms the UAC understands. These cases must be mechanisms the UAC understands. These cases must be
skipping to change at page 35, line 27 skipping to change at page 40, line 34
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,
due to the many problems this requirement would have caused
if implemented. The solution is for the above UAS to send a
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
not provide applicable location information. not provide applicable location information.
In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS
A.3 Requirements for SIP Proxies and Intermediaries A.3 Requirements for SIP Proxies and Intermediaries
The following are the requirements for location conveyance by a SIP The following are the requirements for location conveyance by a SIP
proxies and intermediaries: proxies and intermediaries:
skipping to change at page 37, line 41 skipping to change at page 42, line 52
--boundary1-- --boundary1--
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; nor does it represent that it has rights might or might not be available; nor does it represent that
made any independent effort to identify any such rights. Information it has made any independent effort to identify any such rights.
on the procedures with respect to rights in RFC documents can be Information on the procedures with respect to rights in RFC
found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
 End of changes. 140 change blocks. 
392 lines changed or deleted 656 lines changed or added

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