< draft-ietf-sip-location-conveyance-11.txt   draft-ietf-sip-location-conveyance-12.txt >
SIP Working Group James Polk SIP Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expires: April 30, 2009 Brian Rosen Expires: May 19, 2009 Brian Rosen
Intended Status: Standards Track (PS) NeuStar Intended Status: Standards Track (PS) NeuStar
October 30, 2008 November 19, 2008
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sip-location-conveyance-11.txt draft-ietf-sip-location-conveyance-12.txt
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2009. This Internet-Draft will expire on May 19, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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 12 skipping to change at page 2, line 12
make routing decisions based on the location of the user agent make routing decisions based on the location of the user agent
clients. clients.
Table of Contents Table of Contents
1. Conventions and Terminology used in this document . . . . . . 2 1. Conventions and Terminology used in this document . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 5 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 5
4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7
4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7
4.2 424 (Bad Location Information) Response Code . . . . . . 9 4.2 424 (Bad Location Information) Response Code . . . . . . 10
4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 10 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11
4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 18 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 19
4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 18 4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 19
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 20 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 21
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 20 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 21
5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 22 5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 23
6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 23 6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 23
6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 23 6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 24
6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 26 6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 27
6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 31 6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 32
7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 34 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
9.1 IANA Registration for New SIP Geolocation Header . . . . 36 9.1 IANA Registration for New SIP Geolocation Header . . . . 38
9.2 IANA Registration for New SIP 'geolocation' Option Tag . 36 9.2 IANA Registration for New SIP 'geolocation' Option Tag . 38
9.3 IANA Registration for New 424 Response Code . . . . . . . 36 9.3 IANA Registration for New 424 Response Code . . . . . . . 38
9.4 IANA Registration for New SIP Geolocation-Error Header . 36 9.4 IANA Registration for New SIP Geolocation-Error Header . 38
9.5 IANA Registration for New SIP Geolocation-Error Codes . . 37 9.5 IANA Registration for New SIP Geolocation-Error Codes . . 38
9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 37 9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 39
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1 Normative References . . . . . . . . . . . . . . . . . 38 11.1 Normative References . . . . . . . . . . . . . . . . . 40
11.2 Informative References . . . . . . . . . . . . . . . . . 39 11.2 Informative References . . . . . . . . . . . . . . . . . 41
Author Information . . . . . . . . . . . . . . . . . . . . . 40 Author Information . . . . . . . . . . . . . . . . . . . . . 41
Appendix A. Requirements for SIP Location Conveyance . . . . 40 Appendix A. Requirements for SIP Location Conveyance . . . . 42
Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 42 Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 44
Intellectual Property and Copyright Statements . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . 45
1. Conventions and Terminology used in this document 1. Conventions and Terminology used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. in [RFC2119].
The following terms and acronyms used throughout this document are The following terms and acronyms used throughout this document are
defined here: defined here:
skipping to change at page 4, line 28 skipping to change at page 4, line 28
2. Introduction 2. 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
agent server (UAS), or intermediate SIP server where the UAC is. A agent server (UAS) or intermediate SIP server where the UAC is. A
superset of this can also be true as well, in which one UA(1) is superset of this can also be true as well, in which one UA (UA-1) is
telling another UA(2) where another Target is, meaning not telling another UA-2 where another Target is, meaning not
necessarily where UA(1) is. The key to this is whether UA(1) has necessarily where UA-1 is. The key to this is whether UA-1 has
permission to retransmit that other Target's location. If yes, then permission to retransmit that other Target's location. If yes, then
this is valid. If no, then this is breaking a fundamental rule this is valid. If no, then this is breaking a fundamental rule
within this extension. within this extension.
Location Conveyance is different from a UAC seeking the location the Location Conveyance is different from a UAC seeking the location the
UAS. Location conveyance is a 'sending location out in the request' UAS. Location conveyance is a 'sending location out in the request'
model, where 'asking that someone else's location be in a response' model, where 'asking that someone else's location be in a response'
is not discussed here. is not discussed here.
Geographic location in the IETF is discussed in RFC 3693 (Geopriv Geographic location in the IETF is discussed in RFC 3693 (Geopriv
skipping to change at page 7, line 8 skipping to change at page 7, line 7
This document creates a new option tag: geolocation, to indicate This document creates a new option tag: geolocation, to indicate
support for this extension by UAs. support for this extension by UAs.
A new error response (424 Bad Location Information) is also defined A new error response (424 Bad Location Information) is also defined
in this document. Within this response is a new header indicating in this document. Within this response is a new header indicating
location-based errors, call the Geolocation-Error header. This location-based errors, call the Geolocation-Error header. This
header has various codes that provide additional information about header has various codes that provide additional information about
the type of location error experienced by a Location Recipient. the type of location error experienced by a Location Recipient.
Both new headers, the header parameters, the new option tag, the new The new headers, the header parameters, the new option tag, the new
error response, and Geolocation-Error codes, which are defined in error response, and Geolocation-Error codes, which are defined in
Section 4., are IANA registered by this document. Section 4., are IANA registered by this document.
4. SIP Modifications for Geolocation Conveyance 4. SIP Modifications for Geolocation Conveyance
The following are sections detail the standards track modifications The following are sections detail the standards track modifications
to SIP for Location Conveyance. to SIP for Location Conveyance.
4.1 The Geolocation Header 4.1 The Geolocation Header
This document defines and IANA registers a new SIP header: This document defines and IANA registers a new SIP header:
Geolocation, with the following ABNF [RFC5234]: Geolocation, with the following ABNF [RFC5234]:
Geolocation = "Geolocation" HCOLON (locationValue *(COMMA Geolocation = "Geolocation" HCOLON (locationValue *(COMMA
locationValue)) locationValue)) (COMMA retrans-param)
locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param)
locationURI = sip-URI / sips-URI / pres-URI locationURI = sip-URI / sips-URI / pres-URI
/ cid-url ; (from RFC 2392) / cid-url ; (from RFC 2392)
/ absoluteURI ; (from RFC 3261) / absoluteURI ; (from RFC 3261)
geoloc-param = "inserted-by" EQUAL geoloc-inserter geoloc-param = "inserted-by" EQUAL geoloc-inserter
/ "used-for-routing" / "used-for-routing"
/ generic-param ; (from RFC 3261) / generic-param ; (from RFC 3261)
geoloc-inserter = DQUOTE hostport DQUOTE geoloc-inserter = DQUOTE hostport DQUOTE
/ gen-value ; (from RFC 3261) / gen-value ; (from RFC 3261)
retrans-param = "routing-allowed" EQUAL "yes" / "no"
sip-URI, sips-URI and absoluteURI are defined according to RFC 3261. sip-URI, sips-URI and absoluteURI are defined according to RFC 3261.
The pres-URI is defined in RFC 3859 [RFC3859]. The pres-URI is defined in RFC 3859 [RFC3859].
The cid-url is defined in [RFC2392] to locate message body The cid-url is defined in [RFC2392] to locate message body
parts. This URI type MUST be present in a SIP request if location parts. This URI type MUST be present in a SIP request if location
is transmitted LbyV only. is transmitted LbyV only.
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 in the header of the header value, such that the last locationValue in the header
is the most recent one added to the message. is the most recent one added to the message. Placement of the
"routing-allowed" parameter does not matter within the Geolocation
header.
A locationValue has the following independent header parameters, A locationValue has the following independent header parameters,
o the "inserted-by=" parameter provides the hostport o the "inserted-by=" parameter provides the hostport
(alice.example.com -- which is the same as the "sent-by" (alice.example.com -- which is the same as the "sent-by"
parameter in a Via header, with or without a port number) of the parameter in a Via header, with or without a port number) of the
SIP entity that inserted this locationValue into the request. If SIP entity that inserted this locationValue into the request. If
a Location Recipient has determined a supplied location is in a Location Recipient has determined a supplied location is in
error, as there can be more than one in any request, the error, as there can be more than one in any request, the
"inserted-by=" parameter is copied into the locationErrorValue in "inserted-by=" parameter is copied into the locationErrorValue in
the response indicating the location error, and to whom the error the response indicating the location error, and to whom the error
is for. Hence, this "inserted-by=" parameter MUST be present in is for. Hence, this "inserted-by=" parameter MUST be present in
each locationValue. If an entity receives an Geolocation-Error each locationValue. If an entity receives an Geolocation-Error
skipping to change at page 8, line 32 skipping to change at page 8, line 36
Each locationValue MUST contain exactly one "inserted-by" parameter, Each locationValue MUST contain exactly one "inserted-by" parameter,
indicating which SIP entity added the locationValue to the SIP indicating which SIP entity added the locationValue to the SIP
request. request.
There MUST NOT be more than one "inserted-by=" parameter or one There MUST NOT be more than one "inserted-by=" parameter or one
"used-for-routing" parameter in the same locationValue. However, "used-for-routing" parameter in the same locationValue. However,
there can be more than one locationValue in the same Geolocation there can be more than one locationValue in the same Geolocation
header. header.
The "routing-allowed" header parameter is a global parameter over
any (and all/each) locationValues in the Geolocation header. This
is the reason why the placement of the header parameter is outside
any locationValue, and appears only once in the header value.
This header parameter has values "=yes" or "=no" only. When this
parameter "=yes", any locationValue can be used for routing
decisions along the downstream signaling path by intermediaries.
When this parameter "=no", this means no locationValue (inserted by
the originating UAC or any (or subsequent) intermediary(ies) along
the signaling path) can be used by a SIP intermediary to make
routing decisions. This behavior MUST be adhered to.
The practical implication is that when the "routing-allowed"
parameter is set to "no", if an LbyV is present in the SIP request,
intermediaries needn't bother viewing the location (because they are
not to do anything with it), and if an LbyR is present, do not
bother to dereference it.
The default behavior when this header parameter is not present in a
message is to treat the SIP request as if the parameter were present
and its value is set to "no".
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], SUBSCRIBE [RFC3265], NOTIFY [RFC3265],
PUBLISH [RFC3903] and PRACK [RFC3262] PUBLISH [RFC3903] and PRACK [RFC3262]
skipping to change at page 9, line 4 skipping to change at page 9, line 28
for this document since it is part of Presence, therefore, for for this document since it is part of Presence, therefore, for
completeness, Table 1 shows PUBLISH is to support Location completeness, Table 1 shows PUBLISH is to support Location
Conveyance via this extension, but is not discussed further. Conveyance via this extension, but is not discussed further.
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 R ar o - - o o o o Geolocation R ar o - - o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB Header field where proxy SUB NOT UPD MSG REF INF PUB
---------------------------------------------------------------- ----------------------------------------------------------------
Geolocation R ar o o o o o o o Geolocation R ar o o o o o o o
Table 1: Summary of the Geolocation Header Table 1: Summary of the Geolocation Header
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 any associated NOT modify any pre-existing locationValue, including any associated
header parameters within an existing Geolocation header value, header parameters 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
6.3. 6.3.
[RFC3261] states message bodies cannot be added by proxies. [RFC3261] states message bodies cannot be added by proxies.
Therefore, any Geolocation header field added by a proxy MUST be in Therefore, any Geolocation header field added by a proxy MUST be in
the form of an LbyR URI, in its own locationValue header value. the form of an LbyR URI, in its own locationValue header value.
Adding a new locationValue to an in-transit request SHOULD NOT A SIP proxy MAY add a Geolocation header if one is not present, in
occur for at least two reasons the case that the "routing-allowed" parameter is not yet present in
the SIP request. The value of this parameter MUST be set to "no"
when added by a proxy.
Adding a new locationValue to an in-transit request SHOULD NOT
occur for at least two reasons,
#1 - SIP Servers are not the best Sighters, as defined by [RFC3693], #1 - SIP Servers are not the best Sighters, as defined by [RFC3693],
of geographically where a UAC can be; meaning the location of geographically where a UAC can be; meaning the location
information is not necessarily the greatest. There MAY be information is not necessarily the greatest. There MAY be
exceptions, but this SHOULD be the rule of thumb. exceptions, but this SHOULD be the rule of thumb.
#2 - without appropriate caution to the fact that Location #2 - without appropriate caution to the fact that Location
Recipients might not understand how to process more than one Recipients might not understand how to process more than one
location, given this document's limited guidance as to what a location, given this document's limited guidance as to what a
Location Recipient should do when receiving more than one Location Recipient should do when receiving more than one
location (i.e., currently no priority instructions are given location (i.e., currently no priority instructions are given
skipping to change at page 15, line 20 skipping to change at page 15, line 53
Geolocation-Error: 200; code="Retry Location Later"; Geolocation-Error: 200; code="Retry Location Later";
node="bob.example.com"; node="bob.example.com";
inserter="alice.example.com"; inserter="alice.example.com";
This category covers location errors 2XX; meaning there MAY be more This category covers location errors 2XX; meaning there MAY be more
specific errors added to this category in future effort(s). The specific errors added to this category in future effort(s). The
same basic actionable reaction is expected by a location "inserter=" same basic actionable reaction is expected by a location "inserter="
entity to any 2XX location error. entity to any 2XX location error.
If a SIP request has the "routing-allowed" header parameter set to
"no", and the SIP server believes it requires location within the
request in order to service the request properly, a 2XX location
error is sent towards the recipient. This error is the proper error
even when there is no location in the SIP request, but the SIP
request contains a policy statement that location is not to be
viewed during transit towards the ultimate destination.
4.3.3 Location Error: 300 "Retry Location Later" (device updated 4.3.3 Location Error: 300 "Retry Location Later" (device updated
location) location)
The location error 300 "Retry Location Later" (device updated The location error 300 "Retry Location Later" (device updated
location) indicates to a Geolocation-Error recipient that what they location) indicates to a Geolocation-Error recipient that what they
supplied in a request, as far as location is concerned, cannot be supplied in a request, as far as location is concerned, cannot be
processed at this time, but to retry this request, once the location processed at this time, but to retry this request, once the location
information has been updated, in a new SIP request. information has been updated, in a new SIP request.
Action(s) to be taken by Geolocation-Error receiver to a 3XX: Action(s) to be taken by Geolocation-Error receiver to a 3XX:
skipping to change at page 16, line 22 skipping to change at page 17, line 11
inserter="alice.example.com"; inserter="alice.example.com";
This category covers location errors 3XX; meaning there MAY be more This category covers location errors 3XX; meaning there MAY be more
specific errors added to this category in future effort(s). The specific errors added to this category in future effort(s). The
same basic actionable reaction is expected by a location "inserter=" same basic actionable reaction is expected by a location "inserter="
entity to any 3XX location error. entity to any 3XX location error.
4.3.4 Location Error: 400 "Permission Necessary" 4.3.4 Location Error: 400 "Permission Necessary"
The location error 400 "Permission Necessary" indicates to a The location error 400 "Permission Necessary" indicates to a
Geolocation-Error recipient that when they set a particular SIP Geolocation-Error recipient that when they sent a particular SIP
request, they included location in that request without giving request, they included location in that request without giving
permission in the request for a (or any) SIP server to look at that permission in the request for a (or any) SIP server to look at that
location information to route the message at the intended recipient location information (i.e., the <retransmission-allowed> was set to
(i.e., the UAS, or the called party). "no") to route the message at the intended recipient (i.e., the UAS,
or the called party).
Action(s) to be taken by Geolocation-Error receiver to a 4XX: Action(s) to be taken by Geolocation-Error receiver to a 4XX:
4XX location errors indicate to the UAC (i.e., the calling 4XX location errors indicate to the UAC (i.e., the calling
party) that they need to grant permission to a SIP party) that they need to grant permission to a SIP
intermediary server to look at the supplied location to intermediary server to look at the supplied location to
complete the message routing. This indication MUST require complete the message routing. This indication MUST require
human user intervention, as the rulemaker of the policy on human user intervention, as the rulemaker of the policy on
whether or not their location is to be revealed. whether or not their location is to be revealed.
The user of the location "inserter=" device can choose to grant The user of the location "inserter=" device can choose to grant
skipping to change at page 23, line 30 skipping to change at page 24, line 20
UAC wants to make sure only the destination UAS can read the UAC wants to make sure only the destination UAS can read the
PIDF-LO. S/MIME can be used for just signing, and not encrypting, a PIDF-LO. S/MIME can be used for just signing, and not encrypting, a
PIDF-LO message body to ensure the integrity of the PIDF-LO is PIDF-LO message body to ensure the integrity of the PIDF-LO is
maintained. maintained.
6.1 UAC Behavior 6.1 UAC Behavior
A UAC can send location in a SIP request, either because it is A UAC can send location in a SIP request, either because it is
expected to facilitate location-based routing of the request, or expected 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). Alice communicating to Bob her location in a SIP known to the UAC). Alice communicating her location to Bob in a SIP
Message request is a simple example of this. If Alice wanted to request is a simple example of this. If Alice wanted to include her
include her location as a message body in an INVITE that also has an location as a message body in an INVITE that also has an SDP message
SDP message body, the Content-Type: Multipart MUST be supported by body, the Content-Type: Multipart MUST be supported by both UAC and
both UAC and UAS. Multipart comes in many forms (/mixed, UAS. Multipart comes in many forms (/mixed, /alternative, etc), and
/alternative, etc), and this document does not limit which type of this document does not limit which type of Multipart is used, though
Multipart is used, though future documents MAY specify or limit future documents MAY specify or limit Multipart to a subset of all
Multipart to a subset of all the choices for a given use. the choices for a given use.
A UAC conveying location MUST include a locationValue in a A UAC conveying location MUST include a locationValue in a
Geolocation header (see section 4.1) with either an LbyV indication Geolocation header (see section 4.1) with either an LbyV indication
(a cid-URL), or an LbyR. An LbyV message body sent without a (a cid-URL), or an LbyR. An LbyV message body sent without a
Geolocation header field MUST NOT occur. The UAC supporting this 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'
option tag. option tag.
More than one location format (civic and coordinate) can be included More than one location format (civic and coordinate) can be included
in the same message body part, but all location parts of the same in the same message body part, but all location parts of the same
skipping to change at page 24, line 52 skipping to change at page 25, line 42
Geolocation: <cid:alice123@atlanta.example.com>; Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice@atlanta.example.com" inserted-by="alice@atlanta.example.com"
If a UAC does not learn and store its location locally (a GPS chip) If a UAC does not learn and store its location locally (a GPS chip)
or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR
URI (from DHCP for example). If the latter is the case, the UAC MAY URI (from DHCP for example). If the latter is the case, the UAC MAY
SUBSCRIBE to this LbyR URI, using the 'presence' event package, to SUBSCRIBE to this LbyR URI, using the 'presence' event package, to
get and store its own location. get and store its own location.
The act of dereferencing a Target's LbyR will be challenged by the The act of dereferencing a Target's LbyR will be challenged by the
LIS were this location record is - providing a good deal of LIS where this location record is - providing a good deal of
protection, SHOULD still be treated as equivalent to possession of protection, SHOULD still be treated as equivalent to possession of
the location information itself and thus TLS SHOULD be used when the location information itself and thus TLS SHOULD be used when
transmitting LbyR hop-by-hop along the path to the Location transmitting LbyR hop-by-hop along the path to the Location
Recipient, for protection reasons. This is not to be confused with Recipient, for protection reasons. This is not to be confused with
a possession model, in which possessing the LbyR grants a possession model, in which possessing the LbyR grants
authorization to dereference the URI. Any entity dereferencing the authorization to dereference the URI. Any entity dereferencing the
LbyR MUST pass whatever authentication and authorization rules are LbyR MUST pass whatever authentication and authorization rules are
on the LIS for this location record. The Rulemaker from [RFC3693] on the LIS for this location record. The Ruleholder from [RFC3693]
is still very much in control - for any entity possessing the LbyR. is still very much in control - for any entity possessing the LbyR.
If the Location Generator wishes to control whether any location
included in the SIP request, or added along the signaling path of
this request, can be viewed for routing decisions, the Location
Generator adds a Geolocation header value including the
"routing-allowed=no" parameter. This is header parameter provide
specific policy rules for each locationValue (if there is more than
one inserted along the signaling path) within the SIP request. A
UAC SHOULD include the "routing-allowed" header parameter, with or
without a locationValue, to each SIP request supporting this
specification to ensure the UAC's policy for intermediaries which
might add a locationValue of the Target downstream. The UAC
understands that the default behavior for SIP servers is to consider
this value to be present, and that it is set to "no".
The UAC MUST understand there is no feedback mechanism to inform the
Target if a SIP server has included a locationValue downstream.
If a UAC has already conveyed location in the original request of a If a UAC has already conveyed location in the original request of a
transaction, and wants to update its location information (for transaction, and wants to update its location information (for
whatever reason) after the original request is sent, or after a whatever reason) after the original request is sent, or after a
dialog is created (regardless of how the UAC conveyed location dialog is created (regardless of how the UAC conveyed location
previously, as an LbyV or LbyR) - this is done by a UAC sending an previously, as an LbyV or LbyR) - this is done by a UAC sending an
UPDATE request [RFC3311] containing the geolocation option tag and UPDATE request [RFC3311] containing the geolocation option tag and
Geolocation header with the new locationValue (LbyV or LbyR) to the Geolocation header with the new locationValue (LbyV or LbyR) to the
original destination UAS. original destination UAS.
A PIDF includes identity information. It is possible for the A PIDF includes identity information. It is possible for the
skipping to change at page 31, line 35 skipping to change at page 32, line 42
It is allowed, but NOT RECOMMENDED, for more than one SIP element to It is allowed, but NOT RECOMMENDED, for more than one SIP element to
insert location into a request along its path. As described earlier insert location into a request along its path. As described earlier
in this document, each insertion of location into a SIP request is in this document, each insertion of location into a SIP request is
accompanied by a new locationValue in a Geolocation header. Also accompanied by a new locationValue in a Geolocation header. Also
described earlier, each locationValue MUST contain an "inserted-by=" described earlier, each locationValue MUST contain an "inserted-by="
value indicating to a Location Recipient which host inserted value indicating to a Location Recipient which host inserted
location into a particular request. location into a particular request.
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 LbyR that identifies the same target in the SHOULD NOT add another LbyR that identifies the same target in the
PIDF-LO (in the <tuple-id> element) to the same request. This will PIDF-LO (in the <dm:device id> element) to the same request. This
likely cause confusion at the Location Recipient as to which to use. will likely cause confusion at the Location Recipient as to which to
use.
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 can use body, if not S/MIME protected, in transit if present, and can 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. Retargeting is defined in [RFC3261]. of that proxy. Retargeting is defined in [RFC3261]. However, if
the Geolocation header parameter "routing-allowed" is present and
set to "no", or is not present (knowing the default behavior is "no"
if not present, with or without a Geolocation header), SIP servers
MUST NOT view the contents of the LbyV message body. Further, SIP
servers MUST NOT attempt to dereference an LbyR. This is because
the SIP request, likely from the originating UAC did not give the
SIP server permission to view the location within the SIP request.
If the Geolocation header parameter "routing-allowed" is present in
a SIP request, the value MUST NOT be changed during processing of
the request. If the Geolocation header parameter "routing-allowed"
is not present, SIP servers are to treat the location within the
request as if the header parameter "routing-allowed" were present
and set to "no".
In the spirit of informing implementers of B2BUAs and SBCs, each
server type really should adhere to the above proxy guidance with
respect to the "Routing-allowed" header parameter, understanding
that there are no IETF police, and the specific behaviors of these
types of SIP servers cannot presently be defined. In other words, if
the particular type of SIP server mentioned here is not the ultimate
destination of this SIP request and supports this SIP extension,
each policy rule within the Geolocation header needs to remain
intact and unchanged.
No type of SIP server can delete a "Routing-allowed" header
parameter, but if one is not yet present, any SIP server MAY add a
"Routing-allowed" header parameter with the value set to "no" only.
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 is done to the header (after previous locationValue(s)). This is done to
create an order of insertion of locationValues along the path. create an order of insertion of locationValues along the path.
Proxies MUST NOT modify the order of locationValues in a geolocation Proxies MUST NOT modify the order of locationValues in a geolocation
header. header.
 End of changes. 25 change blocks. 
57 lines changed or deleted 142 lines changed or added

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