wdiff draft-ietf-sip-location-conveyance-09.txt draft-ietf-sip-location-conveyance-10.txt

SIP Working Group James Polk
Internet Draft Cisco Systems
Expiration: May 16th, Aug 24, 2008 Brian Rosen
Intended Status: Standards Track (PS) NeuStar
February 24, 2008

Location Conveyance for the Session Initiation Protocol
draft-ietf-sip-location-conveyance-09.txt
Nov 16th, 2007
draft-ietf-sip-location-conveyance-10.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 16th, August 24, 2008.

Abstract

This document defines an extension to the Session Initiation
Protocol (SIP) to convey geographic location information from one
SIP entity to another SIP entity. The extension covers end to end
conveyance as well as location-based routing, where proxy servers
make routing decisions based on the location of the SIP user agents.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology used in this document . . . . . . 2
2. Introduction . . . . . . . . 4
3. Mechanisms . . . . . . . . . . . . . . . . 4
3. Overview of SIP Location Conveyance . . . . . . . . . . 4
3.1 Overview of SIP Location Conveyance . . . 5
4. SIP Modifications for Geolocation Conveyance . . . . . . . . 4
3.2 7
4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 5
3.3 7
4.2 424 (Bad Location Information) Response Code . . . . . . 8
3.4 9
4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 9
3.5 10
4.4 The Geolocation 'geolocation' Option Tag . . . . . . . . . . . . . . . 18
3.6
4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 19
4. 18
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 20
4.1
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 20
4.2
5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 22
5.
6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 23
5.1 22
6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 24
5.2 23
6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 26
5.3
6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 29
6. 30
7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 32
7. 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
8.1 35
9.1 IANA Registration for New SIP Geolocation Header . . . . 34
8.2 35
9.2 IANA Registration for New SIP Geolocation 'geolocation' Option Tag . . 35
8.3 36
9.3 IANA Registration for New 424 Response Code . . . . . . . 35
8.4 36
9.4 IANA Registration for New SIP Geolocation-Error Header . 35
8.5 36
9.5 IANA Registration for New SIP Geolocation-Error Codes . . 35
9. 36
9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 37
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
10.
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1 38
11.1 Normative References . . . . . . . . . . . . . . . . . 37
10.2 38
11.2 Informative References . . . . . . . . . . . . . . . . . 38 39
Author Information . . . . . . . . . . . . . . . . . . . . . 38 39
Appendix A. Requirements for SIP Location Conveyance . . . . 39
Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 41
Intellectual Property and Copyright Statements . . . . . . . 42 43

1. Introduction

This Conventions and Terminology used in this document describes how Location can

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be "conveyed" (that is,
transmitted over interpreted as described
in [RFC2119].

The following terms and acronyms used throughout this document are
defined here:

"cid=" = content-ID URI. See Section 4.1 for more details.

Content-ID - Defined in RFC 2392 as a URL reference to find message
body parts within the Internet) same message, to ease parsing.

LbyR = Location-by-Reference
LbyV = Location-by-Value

locationErrorValue - contains an actionable error code from a
Location Recipient, identifying the location "inserter=", and
optionally a test string describing the type of error. There can
be one SIP user agent (UA), or in
some circumstances, more locationErrorValues within a proxy server acting Geolocation-Error
header in support of a UA, to
another entity using SIP [RFC3261]. Here "Location" is response. See Section 4.3 for more details.

locationValue - contains a
description of the physical geographical area where something
currently exists. The phrase "location conveyance" describes
scenarios in which URI pointing to a SIP user agent client (UAC) is informing Location Target's
location (as a user
agent server (UAS), PIDF-LO), and one or intermediate SIP server where the UAC is. A
superset of this more header parameters about
that URI. There can also be true as well, in which one UA(1) is
telling another UA(2) where another Target is, meaning not
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
this is valid. If no, then this is breaking a fundamental rule or more locationValues within this extension.

Location Conveyance is different from a UAC seeking the location the
UAS. Location conveyance is a 'sending location out
Geolocation header in a SIP request. See Section 4.1 for more
details.

Location Generator - the request'
model, where 'asking first IP enabled device that someone else's builds the IP
packet that transmits the PIDF-LO containing the Target's
location be in

Location Information Server (LIS) - a response'
is not discussed here.

Geographic location in the IETF is discussed logical server that stores
geolocation records, which correspond to LbyR URIs, which point
to those records.

Location Object - Defined in RFC 3693 (Geopriv
Requirements) [RFC3693]. It defines a "Target" 4119 as the entity whose
location is being sought. In this case, this is the UA's
(UA) location. A [RFC3693] "Using Protocol" defines how a "location
Server" transmits a "Location Object" to a "Location Recipient"
while maintaining PIDF-LO (XML scheme)
format which includes the contained privacy intentions geolocation of the Location Target
intact. This document describes the extension to SIP for how it
complies with the Using Protocol requirements, where the location
server is a UA in
either civic address or Proxy Server and the coordinate form.

Location Recipient is
another UA - Defined in RFC3693 as any entity that
understands geolocation (LbyR or Proxy Server. LbyV) along a message path.
Does not include entities that process a message containing
geolocation that do not understand geolocation (i.e., layer 3
routers).

Location Server - a logical IP server that transmits a PIDF-LO. This
can be transmitted by-value logically combined with the Location Generator, or by-reference. could
be an intermediary element - such as a LIS.

Location Target - The entity whose location
"value" in is being sought, whether
or not this SIP extension entity is in the form aware of a Presence
Information Data Format - Location Object, this inquiry or PIDF-LO, as described
in [RFC4119]. A PIDF-LO is even an XML Scheme specifically for carrying
geographic location of IP
device.

Location-by-Reference (more than one meaning)

- a Target. Location-by-value refers to general purpose term meaning a UA
including message containing a PIDF-LO as URI that
points to a body part PIDF-LO (geolocation of a SIP message, sending that Location Object to another SIP element. Location-by-reference
refers to a UA or proxy server including Target) not within
this same message

- a URI in that logically locates a SIP message
header field which can be dereferenced by geolocation record of a Location Recipient for
Target. The URI does not point to location within the same
message as the URI.

Location-by-Value - when a message contains the actual location of a
Location Object, Target, in the form of a PIDF-LO. Dereferencing can be PIDF-LO, within a part of the
same message, usually pointed to by a SIP UA or "cid=" URI in a SIP server.

As recited Geolocation
header.

Using Protocol - as defined in RFC 3693, location often must be kept private. The
Location Object (PIDF-LO) contains rules which provides guidance [RFC3693], a protocol that is deemed
to
the Location Recipient and controls onward distribution and
retention of the location. This document describes be in compliance with the security and privacy considerations that must be applied to location conveyed
with SIP.

Another use for location is location-based routing aspects of a
SIP request, where the choice
Geopriv Requirements RFC [RFC3693], with good community
verification.

Instead of using the next hop (and usually, the
outgoing Request-URI) is determined by terms Location-by-Reference (or just
by-reference) and Location-by-Value (or just by-value), this
document will herein use the location acronyms LbyR and LbyV, respectively.
The use of "cid=" implies LbyV, therefore, the UAC use of a "cid="
Reference URL, which is in the message by-value or by-reference. *not* a Location-by-Reference (LbyR).

2. Introduction

This document describes how location Location can be conveyed from "conveyed" (that is,
transmitted over the UAC, Internet) from one SIP user agent (UA), or in
some circumstances, a proxy server acting on its
behalf, to in support of a routing proxy. How the location is actually used UA, to
determine the next hop or Request-URI
another entity using SIP [RFC3261]. Here "Location" is beyond the scope a
description of this
document.

We refer to the "emergency case". This refers to physical geographical area where something
currently exists. The phrase "location conveyance" describes
scenarios in which a specific,
important use of SIP location conveyance user agent client (UAC) is informing a user
agent server (UAS), or intermediate SIP server where the location UAC is. A
superset of the
caller this can also be true as well, in which one UA(1) is used
telling another UA(2) where another Target is, meaning not
necessarily where UA(1) is. The key to determine which Public Safety Answering Point
(PSAP) this is expected whether UA(1) has
permission to receive an emergency call request for help
(e.g., a call to 1-1-2 or 9-1-1). This retransmit that other Target's location. If yes, then
this is an example of
location-based routing. The location conveyed valid. If no, then this is also used by the
PSAP to dispatch first responders to the caller's location. There
are special security considerations, which make the emergency case
unique, compared to breaking a normal location conveyance fundamental rule
within SIP.

2. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in [RFC2119].

3. Mechanisms

3.1 Overview of SIP extension.

Location Conveyance

This document defines a new SIP header: Geolocation. The
Geolocation header field contains a URI which can either be a "cid:"
URI (Content Identification), per [RFC2392], or a
location-by-reference URI to be dereferenced by is different from a Location Recipient
to retrieve UAC seeking the location of the Target UA.

Where the Geolocation header contains a "cid:", the URI points to a
message body that
UAS. Location conveyance is a 'sending location out in the form of a PIDF [RFC3863], which was
extended request'
model, where 'asking that someone else's location be in [RFC4119] to include location, as a PIDF-LO. This response'
is
location-by-value, the actual not discussed here.

Geographic location information in the PIDF-LO IETF is
included in the body of the message.

If the URI discussed in the Geolocation header field is RFC 3693 (Geopriv
Requirements) [RFC3693]. It defines a scheme other than
"cid:", another protocol operation is needed by the SIP message
recipient to obtain "Target" as the entity whose
location of the Target (UA). This is
location-by-reference. This document describes being sought. In this case, this is the UA's
(UA) location. A [RFC3693] "Using Protocol" defines how a "location
Server" transmits a "Location Object" to a "Location Recipient"
while maintaining the contained privacy intentions of the Target
intact. This document describes the extension to SIP presence
subscription [RFC3856] for how it
complies with the Using Protocol requirements, where the location
server is a UA or Proxy Server and the Location Recipient is
another UA or Proxy Server.

Location can be used as a dereference protocol. transmitted by-value or by-reference. The Geolocation header, either with the PIDF-LO location
"value" in this SIP extension is in the form of a body Presence
Information Data Format - Location Object, or PIDF-LO, as described
in [RFC4119]. A PIDF-LO is an XML Scheme specifically for carrying
geographic location of a
location-by-reference URI, can be included by Target. LbyV refers to a UA in including a
PIDF-LO as a body part of a SIP message. A request, sending that Location
Object to another SIP element. LbyR refers to a UA or proxy server may assert location of the UA by
inserting the header field, which must specify
including a
location-by-reference URI. Since body parts cannot be inserted by URI in a SIP proxy server, location-by-value message body cannot request header field which can be inserted
dereferenced by a proxy.

The Geolocation header can have parameters that are associated
with Location Recipient for a URI Location Object, in the header field. The "inserted-by" parameter has
values
form of "endpoint" a PIDF-LO. Dereferencing can be by a SIP UA or "server", indicating which entry added a SIP
server.

As recited in RFC 3693, location often must be kept private. The
Location Object (PIDF-LO) contains rules which provides guidance to
the message. Location Recipient and controls onward distribution and
retention of the location. This header parameter MAY document describes the security and
privacy considerations that must be added every
time a new applied to location conveyed
with SIP.

Another use for location is added into a message.

Retargeting means the Request-URI location-based routing of the request has changed to
point at a new destination UAS. This is different than message
routing, that all SIP proxies do. If a
SIP request is retargeted
based on request, where the location contained or referenced within that message, choice of the "used-for-routing" parameter MUST be added as a header parameter
within next hop (and usually, the appropriate locationValue.

There
outgoing Request-URI) is no mechanism determined by which the veracity location of these parameters can
be verified. They are hints to downstream entities on how the
location information UAC which
is in the message was originated and used. by-value or by-reference. This document creates describes
how location can be conveyed from the UAC, or a new option tag: geolocation, proxy acting on its
behalf, to indicate
support for a routing proxy. How the this extension by UAs.

A new error message (424 Bad Location Information) location is also defined
in actually used to
determine the next hop or Request-URI is beyond the scope of this
document. Within this response is a new header indicating
location-based errors, call

We refer to the Geolocation-Error header. "emergency case". This
header has various codes that provide additional information about
the type refers to a specific,
important use of SIP location error experienced by a Location Recipient.

Both new headers, the header parameters, conveyance where the new option-tag, location of the new
error response, and Geolocation-Error codes are IANA registered by
this document.

3.2 The Geolocation Header
caller is used to determine which Public Safety Answering Point
(PSAP) is expected to receive an emergency call request for help
(e.g., a call to 1-1-2 or 9-1-1). This document defines is an example of
location-based routing. The location conveyed is also used by the
PSAP to dispatch first responders to the caller's location. There
are special security considerations, which make the emergency case
unique, compared to a normal location conveyance within SIP.

Common terms are in Section 1. Section 3 provides an overview of SIP
location conveyance. Section 4 details the modifications necessary
to accomplish location conveyance. Section 5 gives decode examples
of geolocation within SIP requests, both LbyV and LbyR. Section 6
articulates the SIP element type behaviors for location conveyance.
Section 7 discusses Geopriv privacy considerations. Section 8
discusses security considerations. Section 9 IANA registers the
modifications made to SIP by this document from section 4.

3. Overview of SIP Location Conveyance

This document defines a new SIP header: Geolocation. The
Geolocation header field MUST contain at least one
of two types of URIs:

o contains a location-by-reference URI, URI which can either be a "cid:"
URI (Content Identification), as defined in [RFC2392], or

o an LbyR
-- to be dereferenced by a content-ID indicating where Location Recipient to retrieve the
location is within of the Target UA.

Where the Geolocation header contains a "cid:", the URI points to a
message body
of this message

A location-by-reference URI that is in the form of a pointer PIDF [RFC3863], which was
extended in [RFC4119] to include location, as a record on a remote
node containing location of PIDF-LO. This is
LbyV, the actual location Target, typically information in the
UA PIDF-LO is included in this transaction.

A location-by-value content-ID (cid-url) [RFC2392] indicates which
message
the body part contains location for this UA.

The of the message.

If the URI in the Geolocation header has field is a scheme other than
"cid:", another protocol operation is needed by the following BNF syntax:

Geolocation = "Geolocation" HCOLON (locationValue *(COMMA
locationValue))
locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param)
locationURI = sip-URI / sips-URI / pres-URI
/ cid-url ; (from RFC 2392)
/ absoluteURI ; (from RFC 3261)
geoloc-param = "inserted-by" EQUAL geoloc-inserter
/ "used-for-routing"
/ "recipient" EQUAL recipient-type
/ generic-param ; (from RFC 3261)
geoloc-inserter = host-id
/ gen-value ; (from RFC 3261)
recipient-type = "endpoint" / "routing-entity" / "both"
/ gen-value ; (from RFC 3261)

sip-URI, sips-URI and absoluteURI are defined according SIP message
recipient to RFC 3261.
The pres-URI obtain the location of the Target (UA). This is defined in RFC 3859 [RFC3859].
LbyR. This document describes how a SIP presence subscription
[RFC3856] can be used as a dereference protocol.

The cid-url is defined Geolocation header, either with the PIDF-LO in [RFC2392] to locate message a body
parts. This URI type MUST or as a
LbyR URI, can be present included by a UA in a SIP message if request. A SIP proxy
server can assert location
is by-value in that same message.

Other protocols used in of the Location UA by inserting the header field,
by adding an LbyR URI MUST be reviewed against into the RFC 3693 criteria for Geolocation header value, even if
there is a Using Protocol. locationValue already there. Since body parts cannot be
inserted by a SIP proxy server, LbyV message body cannot be inserted
by a proxy.

The Geolocation header MAY can have one or more locationValues. SIP
servers inserting parameters that are associated
with a locationValue MUST add the new value to the end
of the header value, such that the last locationValue URI in the header
is the most recent one added to the message.

A locationValue has the following independent header parameters,

o the "inserted-by=" field. The "inserted-by" parameter provides
indicates the host-id
(alice.example.com -- which is the same as the "sent-by"
parameter in a Via header) of the SIP entity that inserted which specific element added this
locationValue into
particular location to the request. This header parameter is used to map to any
Geolocation-Error message to determine which location, if there
included in every locationValue, and does not appear more than once
per locationValue. The "inserted-by" parameter is especially useful
for Location Recipients that receive more than one in locationValue
within a request, the error corresponds to. If an
entity receives an Geolocation-Error with SIP request. Since implementations of a host-id UA or SIP Server
do not of this
entity, the Geolocation-Error SHOULD know they will be ignored.

o the "used-for-routing" parameter to inform recipients that the
location in last entity before a Location
Recipient, this locationValue was used to route optional parameter is necessary within each
locationValue.

Retargeting means the message
towards Request-URI of the ultimate request has changed to
point at a new destination UAS. This can occur more than
once along the request's path. Because locationValues are
inserted as last inserted is last in the header, the last
locationValue different than message
routing, that all SIP proxies do. If a SIP request is retargeted
based on the most recent one added to the message. This
also gives location contained or referenced within that message,
the "used-for-routing" header parameter is added
integrity - as a header parameter
within the receiving SIP entity knows appropriate locationValue.

There is no mechanism by which locationURI the message was routed upon.

o the "recipient=" parameter to allow recipients to infer what SIP
element type this locationValue was intended to veracity of these parameters can
be for. The
types verified. They are

o "endpoint" - meaning the ultimate destination UAS;

o "routing-entity" - meaning SIP servers that route messages
based hints to downstream entities on how the
location contents of requests; information in the message was originated and

o "both" - meaning this locationValue used.
Transport Layer Security is to be viewed by both
types of SIP entities.

Not all SIP entities have to read the locationValue within expected when a
Geolocation header, therefore request contains a parameter value of "both" does
not mean "every" SIP element receiving this request, it means all
that care
user's location. Some implementations will choose to pay attention have S/MIME to
encrypt message bodies from source to destination.

This document creates a locationValue. The default
behavior of SIP entities reading new option tag: geolocation, to indicate
support for the locationValue is that if this header parameter extension by UAs.

A new error response (424 Bad Location Information) is NOT present, the intended recipient also defined
in this document. Within this response is
the destination UAS.

Each locationValue MUST contain exactly one "inserted-by" parameter, a new header indicating which SIP entity added
location-based errors, call the locationValue to Geolocation-Error header. This
header has various codes that provide additional information about
the SIP
request.

Each type of location error experienced by a Location Recipient.

Both new headers, the three types of header parameters listed here MAY appear
in any locationValue once. There MUST NOT be more than one
"inserted-by=" parameter or one "used-for-routing" parameter or one
"recipient=" parameter in parameters, the same locationValue. However, there
can be more than one locationValue in new option tag, the same Geolocation header.

This document defines the Geolocation header as valid new
error response, and Geolocation-Error codes, which are defined in the
following
Section 4., are IANA registered by this document.

4. SIP requests:

INVITE [RFC3261], REGISTER [RFC3261],
OPTIONS [RFC3261], BYE [RFC3261],
UPDATE [RFC3311], INFO [RFC2976],
MESSAGE [RFC3428], REFER [RFC3515],
SUBSCRIBE [RFC3265], NOTIFY [RFC3265],
PUBLISH [RFC3903] and PRACK [RFC3262]

Discussing location using the PUBLISH Request Method is out of scope Modifications for this document, but the Table 1 shows PUBLISH is to support
Location Geolocation Conveyance via this extension.

The following table extends are sections detail the values in Table 2&3 of RFC 3261
[RFC3261].

Header field where proxy INV ACK CAN BYE REG OPT PRA
---------------------------------------------------------------- standards track modifications
to SIP for Location Conveyance.

4.1 The Geolocation R ar o - - o o o o Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Geolocation R ar o o o o o o o

Table 1: Summary of

This document defines and IANA registers a new SIP header:
Geolocation, with the following ABNF [RFC5234]:

Geolocation Header = "Geolocation" HCOLON (locationValue *(COMMA
locationValue))
locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param)
locationURI = sip-URI / sips-URI / pres-URI
/ cid-url ; (from RFC 2392)
/ absoluteURI ; (from RFC 3261)
geoloc-param = "inserted-by" EQUAL geoloc-inserter
/ "used-for-routing"
/ generic-param ; (from RFC 3261)
geoloc-inserter = DQUOTE hostport DQUOTE
/ gen-value ; (from RFC 3261)

sip-URI, sips-URI and absoluteURI are defined according to RFC 3261.
The Geolocation header field MAY pres-URI is defined in RFC 3859 [RFC3859].

The cid-url is defined in [RFC2392] to locate message body
parts. This URI type MUST be included present in any one of the above
requests by a UAC. A proxy MAY add SIP request if location
is transmitted LbyV only.

Other protocols used in the Geolocation header, but Location URI MUST
NOT modify any pre-existing locationValue, including its associated
header parameters of within an existing be reviewed against
the RFC 3693 criteria for a Using Protocol.

The Geolocation header value,
unless MAY have one of or more locationValues. SIP
servers inserting a locationValue MUST add the existing locationValues is used new value to retarget the
request towards a new destination UAS. This is discussed end
of the header value, such that the last locationValue in section
5.3.

[RFC3261] states message bodies cannot be added by proxies.
Therefore, any Geolocation the header field
is the most recent one added by a proxy MUST be in to the form of a location-by-reference URI, in its own message.

A locationValue has the following independent header value.

Adding parameters,

o the "inserted-by=" parameter provides the hostport
(alice.example.com -- which is the same as the "sent-by"
parameter in a new locationValue to an existing Geolocation header SHOULD
NOT occur Via header, with or without appropriate caution to a port number) of the fact
SIP entity that Location
Recipients might not understand how to process more than one
location, given inserted this document's limited guidance as to what locationValue into the request. If
a Location Recipient should do when receiving more than one has determined a supplied location
(i.e., currently no priority instructions are given for which
locationValue to use if is in
error, as there are more than one). A Location
Recipient can easily be confused by too much location information,
producing undesirable results. The <tuple id> element more than one in any request, the
PIDF-LO XML indicates whose location is contained in the PIDF-LO.

Location Recipients receiving a location object, received directly
or as the result of a dereference, MUST honor the usage element
rules within that XML document, per RFC 4119. Such entities MUST
NOT alter
"inserted-by=" parameter is copied into the rule set.

3.3 424 (Bad Location Information) Response Code

If a UAS or SIP intermediary detects an error locationErrorValue in a request message
specific to
the location information supplied by-value or
by-reference. The new 4XX level error is created here to indicate a
problem with response indicating the location in the request message. This document
creates error, and IANA registers to whom the new error code:

424 (Bad Location Information)

The 424 (Bad Location Information) response code
is for. Hence, this "inserted-by=" parameter MUST be present in
each locationValue. If an entity receives an Geolocation-Error
with a rejection of
the request, due to its location contents, indicating the location
information was malformed or hostport not satisfactory for identifying this entity, the recipient's
purpose, or could not
Geolocation-Error MUST be dereferenced.

Section 3.4 creates ignored.

o the Geolocation-Error header "used-for-routing" parameter to provide more
detail about what was wrong with inform recipients that the
location information in the
request. This header MUST be in the 424 response, containing a
locationErrorValue for each invalid this locationValue in was used to route the request
(i.e., and one-for-one matching if all locationValues in message
towards the request
were bad).

If ultimate destination UAS. "used-for-routing" can
occur more than one location once along the request's path. Because
locationValues are inserted as last inserted is present last in a request (by-value or
by-reference), and any of the locationValues
header, the last locationValue is good for the
Location Recipient most recent one added to process, a 424
the message. This also gives the "used-for-routing" header
parameter added meaning - as the receiving SIP entity knows which
locationURI the message was routed upon.

Each locationValue MUST contain exactly one "inserted-by" parameter,
indicating which SIP entity added the locationValue to the SIP
request.

There MUST NOT be sent. The 424 is
only appropriate when more than one "inserted-by=" parameter or one
"used-for-routing" parameter in the Location Recipient needs a locationValue
and same locationValue. However,
there are no locationValues included can be more than one locationValue in a the same Geolocation
header.

This document defines the Geolocation header as valid in the
following SIP request that are
usable by a recipient.

A 424 (Bad Location Information) response is a final response within
a transaction, requests:

The UAC can use whatever means it knows of to verify/refresh its PRACK [RFC3262]

Discussing location information before attempting a new using the PUBLISH request that includes
location. There is no cross-transaction awareness expected by either
the UAS or SIP intermediary as a result out of scope
for this error message.

The new 424 (Bad Location Information) error code document since it is IANA registered
in Section 8 part of Presence, therefore, for
completeness, Table 1 shows PUBLISH is to support Location
Conveyance via this document. An initial set of location error of
IANA registered Geolocation-Error codes are extension, but is not discussed further.

The following table extends the values in Section 3.4 Table 2&3 of this
document.

3.4 The Geolocation-Error RFC 3261
[RFC3261].

Header Providing Error Granularity

As discussed field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Geolocation R ar o - - o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Geolocation R ar o o o o o o o

Table 1: Summary of the Geolocation Header

The Geolocation header field MAY be included in Section 3.3, more granular error notifications,
specific to location errors within a received request, are required
if any one of the UAC is to know what was wrong within above
requests by a UAC. A proxy MAY add the original request.
The Geolocation-Error Geolocation header, but MUST
NOT modify any pre-existing locationValue, including its associated
header is created here for this purpose.
Geolocation-Error parameters of within an existing Geolocation header value,
unless one of the existing locationValues is used to convey location specific errors
within retarget the
request towards a response. Additions to this IANA registered header require
an RFC new destination UAS. This is discussed in section
6.3.

[RFC3261] states message bodies cannot be published.

Geolocation-Error = "Geolocation-Error" HCOLON
[locationErrorValue
*(COMMA locationErrorValue)]
locationErrorValue = location-error-code *(SEMI
location-error-params)
location-error-code = 1*3DIGIT
location-error-params = location-error-node-id
/ DQOUTE location-error-host-id DQOUTE
/ CAtype *(SEMI CAtype)
/ 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 added by proxies.
Therefore, any Geolocation header field added by a proxy MUST contain at least one
locationErrorValue to indicate what was wrong with the original
locationValue be in
the corresponding request. If form of a Location Recipient
experienced more than one error LbyR URI, in the its own locationValue of the
corresponding header value.

Adding a new locationValue to an an in-transit request SHOULD NOT
occur for at least two reasons

#1 - SIP request, there Servers are not the best Sighters, as defined by [RFC3693],
of geographically where a UAC can be one locationErrorValue per
problem with be; meaning the locationValue in location
information is not necessarily the request (the except to greatest. There MAY be
exceptions, but this is
involving CAtypes, which will SHOULD be covered later here). If there was
something wrong with the rule of thumb.

#2 - without appropriate caution to the fact that Location
Recipients might not understand how to process 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
location, given this doc) indicating document's limited guidance as to what
was wrong with the location(s) in the request. Each error type has a corresponding quoted error text string that is human
understandable.

Also within the locationErrorValue is the
Location Recipient
identifier (the "node=") who experienced the should do when receiving more than one
location error, as well
as an identifier of (i.e., currently no priority instructions are given
for which SIP entity (the "inserter=") the Location
Recipient is told (in the locationValue) added the locationValue to
this request. The "node=" and "inserter=" use if there are domain identifier of
a SIP entity, more than one). A
Location Recipient can easily be confused by too much location
information, producing undesirable results. The <tuple id>
element in the same as PIDF-LO XML indicates whose location is entered
contained in the "sent-by" parameter of
the Via header for that entity [RFC3261]. As stated in section 18
of RFC 3261, PIDF-LO.

Location Recipients receiving a location object, received directly
or as the usage of FQDN is RECOMMENDED. Here are examples result of
both

node=bob.example.com

inserter=alice.example.com

Both "node=" and "inserter=" parameters MUST be present in all
locationErrorValues in a response, unless dereference, MUST honor the "inserted-by="
parameter was not usage element
rules within that XML document, as defined in RFC 4119. Such
entities MUST NOT alter the request. rule set.

4.2 424 (Bad Location Information) Response Code

This SIP extension creates a new Location specific response code,
defined as follows.

424 (Bad Location Information)

The "inserter=" parameter 424 (Bad Location Information) response code is
copied from the "inserted-by=" parameter within the locationValue of
the request.

Here's why, a Location Recipient that experienced the location
problem with rejection of
the request needs request, due to tell who added which its location into contents, indicating 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
information was malformed or not satisfactory for them. This is of particular use if the original UAC did recipient's
purpose, or could not include a locationValue in the original SIP
request, but a SIP server along be dereferenced.

Section 4.3 creates the path did insert a locationValue.
The locationErrorValue would travel Geolocation-Error header to each SIP entity along the
original path and tell both the server that included the
locationValue provide more
detail about what was wrong with the location and the UAC who
did not know what the error meant.

A worse case is when both information in the original UAC and a SIP server along
request. This header MUST be in the path included 424 response, containing a locationValue, but there was only something
wrong with one of the locationValues. Without this identification
of which
locationErrorValue for each invalid locationValue was in error, both entities would react the request
(i.e., and
one would do so incorrectly.

Finally, there can be a list of one or more CAtype civic-codes that
are determined to be one-for-one matching if all locationValues in error by the Location Recipient. Perhaps the Location Recipient believes request
were bad).

If more than one location is present in a request (LbyV or more CAtypes are missing, LbyR),
and
required in order to fully process the locationValue in any of the request,
or perhaps data entered in one or more CAtypes locationValues is wrong, according
to good for the Location Recipient. Recipient to
process, a 424 MUST NOT be sent. The list of CAtypes 424 is taken from those
that only appropriate when
the Location Recipient needs a locationValue and there are IANA registered at [IANA-civic].

More than one locationErrorValue no
locationValues included in a Geolocation-Error header is
separated SIP request that are usable by a comma.

If more than one locationErrorValue
recipient.

A 424 (Bad Location Information) response is in a response, final response within
a transaction, 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 does not terminate a usage or inconsistent indications a dialog.

The UAC can use whatever means it knows of to the verify/refresh its
location "inserter=".

Here is an example of information before attempting a Geolocation-Error header

Geolocation-Error: 106; "node=bob.example.com";
"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 new request that includes
location. There is no cross-transaction awareness expected by either
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 UAS or any SIP intermediary as a complete
location result of the Alice. A subsequent request by Alice that included
these two additional pieces this error message.

The new 424 (Bad Location Information) error code is IANA registered
in Section 8 of this document. An initial set of location information would tell Bob
where Alice was.

Notice the CAtypes that were in error are (in the above example of
IANA registered Geolocation-Error header), according to the Location Recipient,
listed codes are in the locationErrorValue. Section 4.3 of this
document.

4.3 The associated CAtype values MUST
NOT be listed Geolocation-Error Header

As discussed in the locationErrorValue. This is for
privacy/security concerns. It is up Section 4.2, more granular error notifications,
specific to location errors within a received request, are required
if the Location Recipient UAC is to
determine which CAtypes were in error, and only list those CAtypes
in know what was wrong within the response. original request.
The "inserter=" entity MUST determine what to do
about correcting each CAtype found in error Geolocation-Error header is created here 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 purpose.
Geolocation-Error header is lacking/wrong used to the convey location sender (i.e., the user) or its network management. specific errors
within a response. Additions to this IANA registered header require
an RFC be published. The following table extends the values in Table 2&3 of RFC 3261
[RFC3261].

Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Geolocation-Error r ar o - - o o o o

Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Geolocation-Error r ar o o o o o o o
Table 2: Summary of Geolocation-Error header has the following
ABNF [RFC5234]:

Geolocation-Error Header = "Geolocation-Error" HCOLON
locationErrorValue
*(COMMA locationErrorValue)
locationErrorValue = location-error-code *(SEMI
location-error-params)
location-error-code = 1*3DIGIT
location-error-params = location-error-node-id
/ location-error-host-id
/ location-error-code-text
/ generic-param ; from RFC3261
location-error-node-id = "node" EQUAL
DQOUTE hostport DQOUTE ; from RFC3261
location-error-host-id = "inserter" EQUAL
DQOUTE hostport DQOUTE ; from RFC3261
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261

The Geolocation-Error header field MAY be included in any response MUST contain at least one
locationErrorValue to indicate what was wrong with the original
locationValue in the corresponding request. If a Location Recipient
experienced more than one error a particular locationValue of the above
corresponding SIP requests, so long as Geolocation was request, there can be one locationErrorValue per
problem with the locationValue in the
request part of request. Each
locationErrorValue contains one 3-digit error code indicating what
was wrong with the transaction. The choice of which SIP requests
are location in table 2 above come from which Methods can optionally have the
Geolocation header (see section 3.2).

Here is an example of a transaction that request. Each error type has a location error. In
this case, Bob responds
corresponding quoted error text string that is human
understandable. If there was something wrong with more than one
locationValue in a 424 (Bad Location Information)
response, including request, a Geolocation-Error header, is in Figure 1.

Each locationErrorValue contains the Location Information) |
|<---------------------------------------|
| |

Figure 1. Basic Transaction with 424 and Geolocation-Error Header

The following subsections provide Recipient identifier
(the "node=" parameter) which experienced the location error, as
well as an initial list identifier of location
specific granular codes for any which SIP responses, including entity (the "inserter="
parameter) the new 424
(Bad Location Information) response. If more than one specific
Geolocation-Error code Recipient is applicable for a response, each MUST be in told (in the response. Geolocation-Error Code 100 is locationValue)
added this problematic locationValue to the generic 'location
was supplied, but not understood' error. If request. The "node="
and "inserter=" are the domain identifier of a more SIP entity, with the
ability to have the same host communicate on different ports - and
have port specific code
applies, a code 100 identification. This is unnecessary.

3.4.1 Geolocation-Error Code 100 Location Not Understood

Geolocation-Error code 100 "Location Format not supported" means the
location format supplied same as is entered in
the request, by-value or by-reference,
was not supported.

This code means "sent-by" parameter of the recipient understood Via header for that location was included entity
[RFC3261]. As stated in section 18 of RFC 3261, the message, but the format usage of FQDN
is not supported. Perhaps RECOMMENDED. Here are examples of both locationErrorValue
parameters

node="bob.example.com"

inserter="alice.example.com"

Both the format
was a freeform text format or data-URL "node=" and the recipient only
understood location "inserter=" parameters MUST be present in RFC 4119 PIDF-LO format (civic or
x.y(.z) coordinate). This error code applies when a recipient has
difficulty parsing the location supplied all
locationErrorValues in a response, unless the request.

If the format is understood, but "inserted-by="
parameter was not desired, an error code 101 or
102 MUST be returned in the locationValue of a 424 response, depending on which location
format is desired. The Location Recipient returns an error code 101
or 102 when it only understands one location format (coordinate or
civic) and did not receive that format.

If a more specific error code request (which is appropriate in a response,
including error code 100
violation of this document). The "inserter=" parameter value is unnecessary.

error-text-string: Location format not supported

An example usage in a SIP 424 response:

Geolocation-Error: 100; "node=bob.example.com";
"inserter=alice.example.com";
CAtype=A3; CAtype=STS;
code="Location Format not supported"

3.4.2 Geolocation-Error Code 101 Coordinate-location Format Desired

Geolocation-Error code 101 "Coordinate-location Format Desired"
means the location format supplied in
copied from the request (probably
formatted in civic), by-value or by-reference, was understood and
supported, but that "inserted-by=" parameter within the recipient, or an application on locationValue of
the
recipient, can request. No manipulation or prefers to only process location in the
coordinate-location format.

A typical reaction calculation is necessary to receiving
accomplish this.

Here's why this code is to resend the
original message with location formatted in coordinate instead.

error-text-string: Coordinate-location Format Desired

An example usage in necessary, a SIP 424 response:

Geolocation-Error: 101; "node=bob.example.com";
"inserter=alice.example.com";
code="Coordinate-location Format Desired"

3.4.3 Geolocation-Error Code 102 Civic-location Format Desired

Geolocation-Error code 102 "Civic-location Format Desired" means Location Recipient that experienced
the location format supplied in problem with the request (probably formatted in
coordinate), by-value or by-reference, was understood and supported,
but that needs to tell the recipient, or an application on specific SIP
entity which added the recipient, can or
prefers to only process location locationValue in the civic-location format.

A typical reaction to receiving this code is to resend error into the original message with location formatted in civic instead.

error-text-string: Civic-location Format Desired

An example usage in a
request. Since more than one SIP 424 response:

Geolocation-Error: 102; "node=bob.example.com";
"inserter=alice.example.com";
code="Civic-location Format Desired"

3.4.4 Geolocation-Error Code 103 Cannot Parse Location Supplied

Geolocation-Error code 103 "Cannot parse location supplied" means
the entity can insert location provided, whether by-value or by-reference, in into a
request is not well formed.

error-text-string: Cannot parse location supplied

An example usage in a transit, all other SIP 424 response:

Geolocation-Error: 103; "node=bob.example.com";
"inserter=alice.example.com";
code="Cannot parse location supplied"

3.4.5 Geolocation-Error Code 104 Cannot Find Location Information

Geolocation-Error code 104 "Cannot find location" means location was
expected elements may be confused by
receiving this error header, were it to remain generic to all
entities in the request, but the recipient cannot find it.

This can be either because response path. So, the cid: pointed header has to a message body part identify who
it is for, so that all other SIP entities that read the header know
to ignore it, since it is not present for them. This is of particular use
if the original UAC did not include a locationValue in the original
SIP request, there was no location message
body part, or what is dereferenced at but a SIP server along the supplied locationURI path did
not return insert a PIDF-LO, or location is encrypted/opaque
locationValue. The locationErrorValue would travel to each SIP
entity along the
recipient.

A typical reaction to receiving this code is for original path and tell both the location sender
to verify server that it has indeed
included location information in the
request in locationValue what was wrong with the properly indicated place location and then to send the request
again.

error-text-string: Cannot find location

An example usage in
UAC who did not know what the error meant. This will cause
confusion if left without this indication.

A worse case is when both the original UAC and a SIP 424 response:

Geolocation-Error: 104; "node=bob.example.com";
"inserter=alice.example.com";
code="Cannot find location"

3.4.6 Geolocation-Error Code 105 Conflicting Locations Supplied

Geolocation-Error code 105 "Conflicting Locations Supplied" means server along
the path included a
Location Recipient received more than locationValue, but there was only something
wrong with one location describing where
the Target is, and is either unsure which whole location is true or
which parts of multiple locations make up where the Target is.

This is generally a case locationValues. Without this identification
of either too much information, and the
information is pointing towards at least two different positions,
confusing the recipient.

A possible scenario exists in which at least two locations are locationValue was in
the request, perhaps error, both entities would react and
one or more were added would do so incorrectly.

More than one locationErrorValue in a Geolocation-Error header is
separated by proxies along the
path of the request, each pointing to where the UAC is. If these
are pointing at different positions - the UAS does not know which to
trust. This error code unfortunately means the UAS cannot solve for
which location needs to be ignored to make up a complete location,
or how to prioritize comma.

If more than one location over all others locationErrorValue is in a response, and intended
for the same
request.

A typical reaction to receiving this "inserter=", each error code is MUST be unique to reduce this
"inserter=" entity, and the number of
different locations supplied error codes SHOULD NOT conflict in
meaning. In other words, two error codes (within separate
locationErrorValues of the request, if under control by the
Target, and send another message same response) SHOULD NOT give misleading
or inconsistent indications to the Location Recipient.

error-text-string: Conflicting Locations Supplied

An location "inserter=".

Here is an example usage in of a SIP 424 response:

Geolocation-Error: 105; "node=bob.example.com";
"inserter=alice.example.com";
code="Conflicting Locations Supplied"

3.4.7 Geolocation-Error Code 106 Incomplete Location Supplied Geolocation-Error code 106 "Incomplete header

Geolocation-Error: 200; code="Retry Location Supplied" means
there is not enough location information, by-value or retrieved
by-reference, to determine where the location Target is.

Perhaps the coordinate precision is not fine enough, or the civic
address lacks the fields to inform Later";
node="bob.example.com";
inserter="alice.example.com";

The following table extends the UAS or proxy values in Table 2&3 of RFC 3261
[RFC3261].

Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Geolocation-Error r ar o - - o o o o

Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Geolocation-Error r ar o o o o o o o

Table 2: Summary of the Target
is. This might be true for request retargeting, or it might be true
for first responder dispatch or pizza delivery (for example, because
the street address is missing).

A typical reaction Geolocation-Error Header

The Geolocation-Error header field MAY be included in any response
to receiving this code is for one of the location sender
to convey more (precise) location information, if doing above SIP requests, so is
allowed by local policy.

error-text-string: Incomplete location supplied

An example usage long as Geolocation was in a SIP 424 response:

Geolocation-Error: 106; "node=bob.example.com";
"inserter=alice.example.com";
code="Incomplete location supplied"

3.4.8 Geolocation-Error Code 107 Cannot Dereference

Geolocation-Error code 107 "Cannot dereference" means the act
request part of
dereferencing failed to return the Target's location. This
generally means the supplied URI is bad.

error-text-string: Cannot dereference

An example usage transaction. The choice of which SIP requests
are in table 2 above come from which Methods can optionally have the
Geolocation header (see section 4.1). That said, a UAC MUST ignore
a SIP 424 response:

Geolocation-Error: 107; "node=bob.example.com";
"inserter=alice.example.com";
code="Cannot dereference"

3.4.9 Geolocation-Error Code 108 Dereference Denied Geolocation-Error code 108 "Dereference Denied" means there was
insufficient authorization to dereference header value if it did not include a Geolocation
header value in the Target's location.

error-text-string: Dereference Denied

An request part of the transaction.

Here is an example usage in of a SIP 424 response:

Geolocation-Error: 108; "node=bob.example.com";
"inserter=alice.example.com";
code="Dereference Denied"

3.4.10 Geolocation-Error Code 109 Dereference Timeout

Geolocation-Error code 109 "Dereference Timeout" means the
dereferencing node transaction that has not received the Target's location within a
reasonable timeframe.

error-text-string: Dereference Timeout

An example usage in location error. In
this case, Bob responds with a SIP 424 response:

Geolocation-Error: 109; "node=bob.example.com";
"inserter=alice.example.com";
code="Dereference Timeout"

3.4.11 Geolocation-Error Code 110 Cannot Process Dereference (Bad Location Information)
response, including a Geolocation-Error code 110 "Cannot process Dereference" means the
dereference protocol has received header, is in Figure 1.

Alice Bob
| |
| Request w/ Location |
|------------------------------------------------>|
| |
| |
| 424 (Bad Location Information) |
| with Geolocation-Error containing |
| 200 ("Retry Location Later" (with same data)) |
|<------------------------------------------------|
| |

Figure 1. Basic Transaction with 424 and Geolocation-Error Header

The following subsections provide an overload condition error,
indicating the initial list of location cannot be accessed at this time.

If a
based errors for any SIP or SIPS scheme were used to dereference the Target's
location, and a 503 (Service Unavailable) were the response to the
dereference query, this Geolocation-Error code 11 would be placed in non-100 response, including the new 424
(Bad Location Information) response response. These error codes are divided
into 5 categories, each based on receiver (of the response)
actionable reactions to these errors.

o 100 "Cannot Process Location"

o 200 "Retry Location Later" (with same data)

o 300 "Retry Location Later" (with device updated location)

o 400 "Permission Necessary"

o 500 "Location Information Denial"

All 5 of the location sender.

error-text-string: Cannot process Dereference

An example usage in above error codes MUST be implemented to comply with
this specification. Each of these actionable errors is given a SIP 424 response:

Geolocation-Error: 110; "node=bob.example.com";
"inserter=alice.example.com";
code="Cannot process Dereference"

3.4.12 Geolocation-Error Code 120 Unsupported Scheme - SIP desired

Geolocation-Error 3
digit error code 120 "Unsupported Scheme - SIP desired" means
the location dereferencer cannot dereference using the
location-by-reference URI scheme supplied because it does not
support category, meaning any future 1XX, 2XX, 3XX, 4XX,
and 5XX error codes defined will have the necessary protocol same action expected by
X00 categories. If another action is expected to do this.

This code means occur with a newly
defined error code, it MUST outside the 100-599 range. 100 unit
ranges are OPTIONAL for future error codes, but they apply here.

4.3.1 Location Recipient can dereference the Target's Error: 100 "Cannot Process Location"

The location using a SIP-URI scheme. There can be more than one
locationErrorValue in error 100 "Cannot Process Location" indicates to a
Geolocation-Error header, indicating recipient that what they supplied in a request, as
far as location is concerned, cannot be processed at this
context time.
This only has to do with the recipient can dereference using each scheme protocol
included in location that the Geolocation-Error header.

Note location "inserter="
added to the request, and not about the overall request that indicating SIP was
sent.

Action(s) to be used taken by Geolocation-Error receiver to dereference location is
requesting the transmission a 1XX:
This error gives no guidance on what to be in cleartext, which do next. It is a security
risk. Therefore,
general information indication to a SIP "inserter=" entity
that there was an unspecific problem with the location
supplied in the SIP scheme SHOULD request.

Implementations MAY choose to react in a way as if this "inserter="
entity received a 2XX or 3XX location error. A 4XX error MUST NOT be used
misunderstood here, as that error category involves human
intervention to dereference.
An exception can be made for emergency calling, preferably after
SIPS has been attempted, and failed.

A typical reaction grant, or not, permission to receiving reveal "inserter="
location when this code would be is likely not desired.

The text string of "Cannot Process Location" is RECOMMENDED, but not
mandatory for the location
sender to send a URI with the sip scheme.

error-text-string: unsupported scheme - SIP desired

An example usage in a SIP 424 response:

Geolocation-Error: 120; "node=bob.example.com";
"inserter=alice.example.com";
code="unsupported scheme - SIP desired"

3.4.13 Geolocation-Error Code 121 Unsupported Scheme - SIPS desired

Geolocation-Error code 121 "Unsupported Scheme - SIPS desired" means
the this error. Implementations MAY use another
text string.

An example of this location dereferencer cannot dereference using the
location-by-reference URI scheme supplied because it does not
support the necessary protocol to do this. error is here:

Geolocation-Error: 100; code="Cannot Process Location";
node="bob.example.com";
inserter="alice.example.com";

This code means the Location Recipient can dereference the Target's category covers location using a SIPS-URI scheme. There can errors 1XX; meaning there MAY be more than one
locationErrorValue in a Geolocation-Error header, indicating in
specific errors added to this
context the recipient can dereference using each scheme protocol
included in the Geolocation-Error header.

error-text-string: unsupported scheme - SIPS desired

An example usage category in future effort(s). The
same basic actionable reaction is expected by a SIP 424 response:

Geolocation-Error: 121; "node=bob.example.com";
"inserter=alice.example.com";
code="unsupported scheme - SIPS desired"

3.4.14 Geolocation-Error Code 122 Unsupported Scheme - pres desired

Geolocation-Error code 122 "Unsupported Scheme - pres desired" means
the location dereferencer cannot dereference using the
location-by-reference URI scheme supplied because it does not
support the necessary protocol "inserter="
entity to do this.

This code means the any 1XX location error.

4.3.2 Location Recipient can dereference the Target's Error: 200 "Retry Location Later" (same data)

The location using a PRES-URI scheme. There can be more than one
locationErrorValue in error 200 "Retry Location Later" (same data) indicates
to a Geolocation-Error header, indicating in this
context the recipient can dereference using each scheme protocol
included that what they supplied in a
request, as far as location is concerned, cannot be processed at
this time, but to retry this request, without changing the Geolocation-Error header.

error-text-string: unsupported scheme location
information, at a later time - pres desired

An example usage in a SIP 424 response:

Geolocation-Error: 122; "node=bob.example.com";
"inserter=alice.example.com";
code="unsupported scheme - pres desired"

3.5 The Geolocation Option Tag

This document creates and IANA registers one new option tag:
"geolocation". This option tag SIP request. It is possible
that the Location Recipient cannot process location at this time, or
there was a timeout during dereferencing, if a LbyR were sent.

Action(s) to be used, per RFC 3261, in the
Require, Supported and Unsupported headers. Whenever taken by Geolocation-Error receiver to a UA wants 2XX:
Reactions to
indicate support for this SIP extension, a 2XX location error are to try again, without
having to update the geolocation option tag location supplied originally. There is
no constraints on how long this new try has to wait, unless
there is included in a Supported Retry-After header of the SIP message.

Including the geolocation option-tag within an Unsupported header of
a 420 (Bad Extension) response is appropriate when in a UAS 424 response.

Implementations SHOULD choose to react by preparing, however this
"inserter=" does or can, to queue another message with the same
location information, provided the "inserter=" does not support move between
the time of the original request and the transmission time of the
new request.

Implementations MAY choose whether or not to inform the user of this Geolocation extension.

A UAC adding
error. The text string of "Retry Location Later" is RECOMMENDED,
but not mandatory for usage in this option-tag to a Require header field indicates error. Implementations MAY use
another text string to
a UAS inform the user that location was not
received by the UAS MUST support (i.e., the called party).

An example of this extension in order location error is here:

Geolocation-Error: 200; code="Retry Location Later";
node="bob.example.com";
inserter="alice.example.com";

This category covers location errors 2XX; meaning there MAY be more
specific errors added to continue
processing the message, or send this category in future effort(s). The
same basic actionable reaction is expected by a 420 response back location "inserter="
entity to any 2XX location error.

4.3.3 Location Error: 300 "Retry Location Later" (device updated
location)

The location error 300 "Retry Location Later" (device updated
location) indicates to the UAC.
Some environments might use a Require header Geolocation-Error recipient that what they
supplied in a request, as far as location is concerned, cannot be
processed at this way, time, but it
should be used with caution to prevent unnecessary communications
problems.

A UAC SHOULD NOT include retry this option tag request, once the location
information has been updated, in a Proxy-Require header,
since new SIP request.

Action(s) to be taken by Geolocation-Error receiver to a UAC is not likely 3XX:
3XX location errors indicate the "inserter=" SIP entity needs
to understand refresh its location, or make the topology of location information
supplied more complete, without notifying the
infrastructure, and therefore would not understand which proxy will
do user of this
error. 3XX error are to be solved by without user
intervention.

This document gives no guidance how this is accomplished, given the location-based routing function, if any. A potentially bad
scenario would have
number of ways a UAC can learn its location, or a SIP intermediary
can Sight a UAC, as defined in [RFC3693].

This 300 location error currently does not indicate what exactly was
wrong with the first proxy location supplied, according to the Location
Recipient. That is left for a future effort.

Implementations MAY choose whether or not support to inform the user of this extension,
error. The text string of "Retry Location Later" is RECOMMENDED,
but
a subsequent proxy does. This would result not mandatory for usage in no communications
past this error. Implementation MAY use
another text string to inform the first proxy, which MUST send user that location was not
received by the 420 back under these
circumstances.

3.6 Using sip/sips/pres as UAS (i.e., the called party).

A 3XX location error would be used where the Location Recipient
cannot find or cannot parse the location supplied, believing that a Dereference Scheme

If
automated refresh and retry could fix the problem. Also, a location-by-reference (LbyR) URI is included 3XX
location error would be used when a Location Recipient did not find
any location in a SIP request,
it MUST but was expecting it. Perhaps an
emergency request was made that did not contain location. The retry
in this case would be in a locationValue the form of an UPDATE Method request,
containing location (LbyV or LbyR).

An example of this location error is here:

Geolocation-Error: 300; code="Retry Location Later";
node="bob.example.com";
inserter="alice.example.com";

This category covers location errors 3XX; meaning there MAY be more
specific errors added to this category in future effort(s). The
same basic actionable reaction is expected by a location "inserter="
entity to any 3XX location error.

4.3.4 Location Error: 400 "Permission Necessary"

The location error 400 "Permission Necessary" indicates to a
Geolocation-Error recipient that when they set a particular SIP
request, they included location in that request without giving
permission in the request for a (or any) SIP server to look at that
location information 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:
4XX location errors indicate to the UAC (i.e., the calling
party), that they need to grant permission to a SIP
intermediary server to look at the supplied location to
complete the message routing. This indication MUST require
human user intervention, as the rulemaker of the policy on
whether or not their location is to be revealed.

The user of the location "inserter=" device can choose to grant
permission to this SIP intermediary server to allow this request to
be routed, or the user can deny this location revelation (request by
the server). It is the user's choice as rulemaker.

Implementations MUST provide the user, as rulemaker, a clear
indication that permission to consume their location is sought by an
entity other than who that user is calling. The text string of
"Permission Necessary" is RECOMMENDED, but not mandatory for usage
in this error. Implementation MAY use another text string to inform
the user that location is being sought by an intermediary (i.e., not
the called party).

This document gives no guidance how this intervention is
accomplished, given the number of ways a UAC can accomplish this
(i.e., audio prompt or toggle or keystroke on their UA).

This 400 location error currently does not indicate exactly which
SIP server indicates it needs the location revealed. That said, the
"node=" FQDN address could be supplied, telling the user (via audio
or video indication) which SIP entity wants this location. Perhaps
the user can know in some circumstances whether this is an
appropriate "node=" (domain). All of this is left for a future
effort(s).

An example of this location error is here:

Geolocation-Error: 400; code="Permission Necessary";
node="bob.example.com";
inserter="alice.example.com";

This category covers location errors 4XX; meaning there MAY be more
specific errors added to this category in future effort(s). The
same actionable solution is expected to be afforded to the UAC user,
as rulemaker, to any 4XX location error.

4.3.5 Location Error: 500 "Location Information Denial"

The location error 500 "Location Information Denial" indicates to a
Geolocation-Error recipient that what they supplied in a request, as
far as location is concerned, has been denied at this time.
This only has to do with the location that the location "inserter="
added to the request, and not about the overall request that was
sent. If this were applied to the SIP request itself, this would
equate to a 6XX Global error.

Action(s) to be taken by Geolocation-Error receiver to a 1XX:
This error gives no guidance on what to do next, other than to
not try again with this same location supplied.

If the Location Recipient believed that merely refreshing, or in
some other way alter or augment the location supplied would work in
a new request, then a 3XX location error SHOULD have been returned
(to the "inserter="). An example of why this 5XX could have been
returned is if location were sent as an LbyR, and the LIS denied the
dereference request from the Location (reference) Recipient, this is
the expected location error returned to the "inserter=" entity.

Implementations MUST NOT interpret anything else into this location
error other than it is considered a location based denial error.
This does not mean the SIP request was denied, or even had an error,
unless the response was a 424. Otherwise, this only has to do with
the location part of the request.

The difference between a 1XX and a 5XX location error is simple. A
1XX location error is a case of a Location Recipient either not
knowing or not being able to tell the "inserter=" entity what was
wrong with the location supplied in a SIP request. Whereas, a 5XX
location error is where the location was purposely, and actively
denied (or declined) from being received by the Location Recipient
entity, or its user. This could occur in a UAS or SIP server.

If implementations choose to inform the UAC user of this error, the
text string of "Location Information Denial" is RECOMMENDED, but not
mandatory for usage in this error. Implementations MAY use another
text string.

An example of this location error is here:

Geolocation-Error: 500; code="Location Information Denial";
node="bob.example.com";
inserter="alice.example.com";

This category covers location errors 5XX; meaning there MAY be more
specific errors added to this category in future effort(s). The
same basic actionable reaction is expected by a location "inserter="
entity to any 5XX location error.

The following are some additional failure scenarios, with which
error code is to be used for each at the time of this document:

- Scheme (sip:, or sips:, or pres:, or another one) of the LbyR URI
isn't supported (100)
- Format (geo or civic) isn't supported (100)
- Cannot parse location (100)
- Can't find LIS (no access or no path (100) or denied access(500))
- Dereference failed (timeout) (200)
- Insufficient location info supplied (300)
- Cannot find location in message (300)

4.4 The 'geolocation' Option Tag

This document creates and IANA registers one new option tag:
"geolocation". This option tag is to be used, as defined in RFC
3261, in the Require, Supported and Unsupported headers. Whenever a
UA wants to indicate support for this SIP extension, the geolocation
option tag is included in a Supported header of the SIP request.

4.5 Using sip/sips/pres as a Dereference Scheme

If a LbyR (LbyR) URI is included in a SIP request, it MUST be a SIP,
SIPS or PRES-URI. When PRES: is used, if the resulting resolution,
as defined in [RFC3856], resolves to a SIP: or SIPS: URI, this
section applies.

This document IANA registers 3 mandatory to implement URI schemes
for LbyR:

o SIP:
o SIPS:
o PRES:

These 3 are IANA registered in Section 9.6.

These schemes MUST be implemented according to this document.
absoluteURI is not mandatory to implement.

Dereferencing a Target's location using SIP or SIPS MUST be
accomplished by treating the URI as a presence URI and generating a
SUBSCRIBE request to a presence server as defined in [RFC3856]
using the '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 as defined in
[RFC3693] and elements receiving location MUST honor the
'usage-element' rules as defined in this extension.

Alice Location Server Bob
| |
| INVITE w/ LbyR 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 LbyR URI using SUBSCRIBE is not violating a
PIDF-LO 'retransmission-allowed' element value set to 'no', as the
NOTIFY is the only message in this multi-message set of transactions
that contains the Target's location, with the location recipient
being the only SIP element to receive location - which is the
purpose of this extension: to convey location to a specific
destination.

5. Geolocation Examples

This section contains are two examples of messages providing
location. One shows LbyV with coordinates, the other shows LbyR.
The example for (Coordinate format) is taken from [RFC3825]. A
civic format example of the same position on the earth as is in the
coordinate format example is in appendix B, which is taken from
[RFC4776]. The differences between the two formats are within the
<gp:location-info> of the examples. Other than this portion of each
PIDF-LO, the rest is the same for both location formats.

The key to the provided samples is in the Geolocation header, which
has a different type of URI, based on the different means of
location conveyance. Section 5.1 shows a "cid:" URI, indicating
this SIP request contains a LbyV message body - which is in the form
of a PIDF-LO. Section 5.2 shows a LbyR URI indicating location is
to be acquired via an indirection dereference mechanism, which is
determined by the scheme of URI supplied.

5.1 Location-by-value (Coordinate Format)

This example shows an INVITE message with a coordinate, or
coordinate location. In this example, the SIP request uses a
sips-URI [RFC3261], meaning this message is TLS protected on a
hop-by-hop basis all the way to Bob's domain.

INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@atlanta.example.com>
;inserted-by="alice@atlanta.example.com"
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE
Contact: <sips:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...

--boundary1

Content-Type: application/sdp
...SDP goes here

--boundary1

Content-Type: application/pidf+xml
Content-ID: alice123@atlanta.example.com

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
entity="pres:alice@atlanta.example.com">
<tuple id="sg89ae">
<timestamp>2007-12-02T14:00:00Z</timestamp>
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>33.001111 -96.68142</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2007-12-07T18:00:00Z</gp:retention-
expiry>
</gp:usage-rules>
<gp:method>DHCP</gp:method>
<gp:provided-by>www.example.com</gp:provided-by>
</gp:geopriv>
</status>
</tuple>
</presence>
--boundary1--

The Geolocation header field from the above INVITE...

Geolocation: <cid:target123@atlanta.example.com>

...indicates the content-ID location [RFC2392] within the multipart
message body of where location information is, with SDP being the
other message body part. The "cid:" eases parsing of message
bodies.

If the Geolocation header and it MUST
be a SIP, SIPS or PRES-URI . When PRES: is used, if the resulting
resolution, per [RFC3856], resolves to a SIP: or SIPS: URI, field were this
section applies. Use instead:

Geolocation: <sips:server5.atlanta.example.com/target123>

...the presence of something other protocols for dereferencing of a
PRES: URI than "cid:" indicates an LbyR is not defined, and such use
included in this message. It is subject expected that any node wanting to review against
RFC 3693 Using Protocol criteria.

Dereferencing a Target's location using SIP or SIPS MUST be
accomplished by treating the URI as a presence URI and generating a
SUBSCRIBE request
know where user target123 is would subscribe to a presence server as per [RFC3856] using server5 to
dereference the
'presence' event package. The resulting NOTIFY will contain a PIDF,
which MUST contain a PIDF-LO. See sips-URI (see Figure 2. for a basic this message flow flow, and
Section 5.2 for a dereference.

When used in this manner, SIP is a Using Protocol per [RFC3693] and
elements receiving decoded example). The returning NOTIFY would
contain Alice's location MUST honor the 'usage-element' rules in a PIDF-LO, as
defined if it were included in this extension.

Alice Location Server Bob
| |
| a
message body (part) of the original 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 here.

5.2 Location-by-reference

Below is an INVITE request with a LbyR URI. Bob
receives this LbyR URI instead of a LbyV PIDF-LO
message body part shown in Section 5.1. It is up to the INVITE and generates a new transaction
(SUBSCRIBE) location
recipient to retrieve dereference Alice's location at the PIDF-LO of Alice. If accepted, Atlanta LIS server
containing the
PIDF-LO will be in location record. Dereferencing, if done with SIP, is
accomplished by the NOTIFY Location Recipient sending a SUBSCRIBE request from
to the Location Server.
This URI reference for Alice's location. The received NOTIFY is
the first instance between Alice and Bob that SIP request containing Alice's
location is UA location, as a PIDF-LO
message body (see Figure 2 for this message flow example). The
NOTIFY, in any message, therefore it this case, is sent only once, from the
Location Server to Bob.

A dereference of a location-by-reference URI using SUBSCRIBE SIP request that is conveying location,
and not
violating a PIDF-LO 'retransmission-allowed' element value set to
'no', as the NOTIFY INVITE. There is no retransmission of location in this
usage.

INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>
;inserted-by="bigbox3.atlanta.example.com"
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>

...SDP goes here as the only message body

A Location Recipient would need to dereference the sips-URI in this multi-message set
of transactions that contains the Target's location, with
Geolocation header field to retrieve Alice's location. If the
atlanta.example.com domain chooses to implement location recipient being conveyance
and delivery in this fashion (i.e., LbyR), it is RECOMMENDED that
entities outside this domain be able to reach the dereference
server, otherwise this model of implementation is only viable within
the atlanta.example.com domain.

6. SIP element to receive Element Behavior

Because a device's location -
which is the purpose of this extension: generally considered to convey be sensitive
in nature, location information needs to a
specific destination.

4. Geolocation Examples be protected when
transmitted. This section contains are two examples can be addressed through securing the location
information to prevent either viewing or changing the PIDF-LO.

Section 26 of [RFC3261] defines the security functionality SIPS by
transporting SIP messages providing
location. One shows location-by-value with coordinates, the other
shows location-by-reference. The example for (Coordinate format)
is taken either TLS or IPSec protection
between SIP entities.

If a SIP entity wants to prevent all SIP entities in a request path
from [RFC3825]. A civic format example viewing or just changing the contents of the same position
on PIDF-LO, save
those that possess decryption key, the earth message body needs to be
secure by a means such as is in S/MIME. This would be the coordinate format example is case in appendix
B, which is taken from [RFC4776]. The differences between a
UAC wants to make sure only the two
formats are within destination UAS can read the <gp:location-info> of
PIDF-LO. S/MIME can be used for just signing, and not encrypting, a
PIDF-LO message body to ensure the examples. Other
than this portion integrity of each PIDF-LO, the rest PIDF-LO is the same for both
maintained.

6.1 UAC Behavior

A UAC can send location formats.

The key to the provided samples is in the Geolocation header, which
has a different type SIP request, either because it is
expected to facilitate location-based routing of URI, based on the different means of
location conveyance. Section 4.1 shows request, or
spontaneously (i.e., a "cid:" URI, indicating purpose not defined in this document but
known to the UAC). Alice communicating to Bob her location in a SIP
Message request contains is a simple example of this. If Alice wanted to
include her location as a location-by-value message body - which
is in the form of a PIDF-LO. Section 4.2 shows a
location-by-reference URI indicating location is to be acquired via
an indirection dereference mechanism, which is determined by the
scheme of URI supplied.

4.1 Location-by-value (Coordinate Format)

This example shows an INVITE that also has an
SDP message with a coordinate, or
coordinate location. In this example, body, the SIP request uses a
sips-URI [RFC3261], meaning Content-Type: Multipart MUST be supported by
both UAC and UAS. Multipart comes in many forms (/mixed,
/alternative, etc), and this message document does not limit which type of
Multipart is TLS protected on used, though future documents MAY specify or limit
Multipart to a
hop-by-hop basis subset of all the way to Bob's domain.

INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@atlanta.example.com>
;inserted-by=alice@atlanta.example.com ;recipient=endpoint
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE
Contact: <sips:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...

--boundary1

Content-Type: application/sdp

...SDP goes here

--boundary1

Content-Type: application/pidf+xml
Content-ID: alice123@atlanta.example.com

The choices for a given use.

A UAC conveying location MUST include a locationValue in a
Geolocation header (see section 4.1) with either an LbyV indication
(a cid-URL), or an LbyR. An LbyV message body sent without a
Geolocation header field from the above INVITE...

Geolocation: <cid:target123@atlanta.example.com>

...indicates MUST NOT occur. The UAC supporting this
extension MUST include a Supported header with the content-ID 'geolocation'
option tag.

More than one location [RFC2392] within format (civic and coordinate) can be included
in the multipart same message body of where part, but all location information is, with SDP being parts of the
other message body part.

If same
PIDF-LO MUST point at the Geolocation header field were this instead:

Geolocation: <sips:server5.atlanta.example.com/target123>

...this would indicate same position on the earth, identifying
the same target. The same location by-reference was included in this
message. multiple formats, for
example, a partial or complete geodetic and a partial or complete
civic, can allow the recipient to use the most convenient or
preferable format for its use.

Multiple PIDF-LOs are allowed in the same request, with each allowed
to point at separate positions - however, each PIDF-LO MUST identify
a different Target. 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 expected that any node wanting to know where user
target123 RECOMMENDED
there is would subscribe only one locationValue in a single SIP request for the same
Target. More than one will likely lead to server5 confusion by a Location
Recipient because this extension does not provide guidance on what a
recipient is to dereference do with more than one location, nor does it give any
preference regarding which location is better or worse than another
location in the sips-URI. same request.

The returning NOTIFY would contain Alice's location 'geolocation' option tag is inserted in a PIDF-LO, as
if it were included in Supported header by a message body (part)
UAC to provide an indication of support for this extension. The
presence of the original INVITE
here.

4.2 Location-by-reference

Below is an INVITE request with 'geolocation' option tag in a location-by-reference URI instead
of Supported header
without a location-by-value PIDF-LO message body part shown Geolocation header field in Sections
4.1. It is up to the location recipient same message informs a SIP
element receiving this request that the UAC understands this
extension, but it does not know or wish to dereference Alice's convey its location at the Atlanta server containing the
this time. Certain scenarios exist (location-based retargeting) in
which location record.
Dereferencing, if done with SIP, is accomplished by the Location
Recipient sending required in a SUBSCRIBE SIP request in order to retarget the URI reference for
Alice's location. The received NOTIFY is the first SIP
message
containing Alice's UA location, as properly. This affects how a PIDF-LO message body. UAS or SIP server processes
such a request.

The
NOTIFY, 'geolocation' option tag SHOULD NOT be used in this case, is the SIP Proxy-Require
Header, because the UAC often will not know the underlying topology
to know which proxy will do the retargeting, thus increasing the
likelihood of a request failure by the first hop proxy that is conveying location,
and does not the INVITE. There
understand this extension, but is no retransmission required to by inclusion of location the
option tag in this
usage.

INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>
;inserted-by=bigbox3.atlanta.example.com ;recipient=both
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>

...SDP goes here as the only message body header.

A Location Recipient would need UAC inserting a locationValue MUST include an "inserted-by="
parameter to dereference the sips-URI in the
Geolocation header field indicate its hostport. This is copied to retrieve Alice's location. If the
atlanta.example.com domain chooses to implement location conveyance
and delivery
"inserter=" parameter of the Geolocation-Error header in this fashion (i.e., location-by-reference), it a response
if a Location Recipient determines there is
RECOMMENDED that entities outside something wrong with the
locationValue in this domain request. Because more than one locationValue
can be able to reach inserted along the
dereference server, otherwise this model path of implementation is
only viable within the atlanta.example.com domain.

5. SIP Element Behavior

Because a device's location request, this indication is generally considered
necessary to be sensitive show which locationValue had the problem in nature, privacy of the location information needs to be protected
when transmitting such information. Section 26 of [RFC3261] defines
response, and who the security functionality SIPS for transporting SIP messages with
either TLS or IPSec, locationErrorValue is for. For example:

Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by="alice@atlanta.example.com"

If a UAC does not learn and S/MIME for encrypting message bodies store its location locally (a GPS chip)
or from
SIP intermediaries that would otherwise have access to reading the
clear-text bodies. SIP endpoints SHOULD implement S/MIME to encrypt network (DHCP or LLDP-MED), the PIDF-LO message body (part) end-to-end when UAC MAY learn its LbyR
URI (from DHCP for example. If the Location
Recipient latter is intended the case, the UAC MAY
SUBSCRIBE to be another UA. The SIPS-URI from [RFC3261]
MUST be implemented for message protection (message integrity and
confidentiality) this LbyR URI, using the 'presence' event package, to
get and SHOULD be used when S/MIME is store its own location. This document does not used. give a
reason why a UAC would want to do this.

Possession of a dereferenceable location Target's LbyR, even though the act of dereferencing
this URI can will be challenged by a LIS were this location record is -
providing a good deal of protection, SHOULD still be treated as
equivalent to possession of the location information itself and thus
TLS SHOULD be used when transmitting location-by-reference LbyR hop-by-hop along the path
to the Location Recipient.

A PIDF includes identity information. It is possible for the
identity in the PIDF to be anonymous. Implementations of this
extension should SHOULD consider the appropriateness of including an
anonymous identity in the location information where a real identity
is not required. When using location-by-reference, it is
RECOMMENDED that the URI does identity
is not required. When using LbyR, the LbyR MUST NOT contain any
user identifying
information (for example information. For example, use 3fg5t5yqw@example.com something
unidentifiable like
3fg5t5yqw@example.atlanta.com

rather than
alice@example.com).

Location Recipients MUST obey the privacy and security rules in the
PIDF-LO as described in RFC 4119 regarding retransmission and
retention.

Self-signed

aliceishere@example.atlanta.com).

Use of elf-signed certificates SHOULD NOT be used is inappropriate for used in
protecting a PIDF, as the sender does not have a secure identity of
the recipient.

More than one location format (civic and coordinate) MAY be included
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
location in multiple formats can allow the recipient to use the most
convenient or preferable format for its use. Multiple PIDF-LOs are
allowed in the same request, with each allowed to point at separate
positions - because each PIDF-LO has a Target identifier in it.
Therefore, there will be no confusion by

6.1.1 UAC Receiving 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
Request for a given Target. This means SIP servers SHOULD NOT add
another locationValue to a SIP request that already contains
location. This will likely lead to confusion at the ultimate
location recipient because this extension does not provide guidance
on what a recipient is to do with more than one location, nor does
it give any preference regarding which location is better Failure Indication

Location Recipients can be either, or worse
than another location in the same request.

It is allowed, but NOT RECOMMENDED, for more than one SIP element to
insert both, destination UASs and
intermediate servers that use the location into information for
location-based routing decisions. If a sent request along its path. As described earlier
in this document, each insertion of fails based on
the location into information in the request, a SIP request 424 (Bad Location
Information) response is
accompanied by sent back to the UAC. The 424 MUST have a locationValue
Geolocation-Error header containing one or more locationErrorValues
in the response message. A locationErrorValue has a Geolocation header. Also
described earlier, each header
parameter indicating which entity inserted the locationValue MUST contain an "inserted-by="
value indicated
correlated to a this error, called the "inserter=" parameter. This
"inserter=" parameter (in the locationErrorValue) is copied from the
"inserted-by=" parameter (from the locationValue) by the Location
Recipient which host inserted location
into a particular request.

5.1 UAC Behavior (UAS or proxy) sending the error response. A UAC can send location in
receiving a SIP request, because it is expected
to facilitate location-based routing of Geolocation-Error in any response type MUST review the request, or
spontaneously (i.e., a purpose not defined
"inserter=" parameter in this document but
known the locationErrorValue to see if it
indicates this UAC. If locationErrorValue does not match, the UAC).

A UAC conveying location
locationErrorValue MUST include be ignored. If a locationValue locationErrorValue is in a
Geolocation header (see section 3.2) with either a location-by-value
indication (a cid-URL), or a location-by-reference indication (a
dereferenceable URI). A location-by-value message body sent without
424, and the "inserter=" entity is not this UAC, the response SHOULD
be treated as a Geolocation header field MUST NOT occur. The UAC supporting 400 response. If locationErrorValue does indicate
this
extension UAC, this UAC MUST include a Supported header with process the geolocation
option tag.

The geolocation option-tag is inserted response, including the
Geolocation-Error code (defined in section 4.3). Further, UAC MUST
ignore a Supported Geolocation-Error header by a
UAC to provide an indication of support value, even for this extension. The
presence of the geolocation option tag UAC, even in
a Supported header without 424 response if the UAC did not include a Geolocation header field value
(with locationValue) in the same message informs a receiving
SIP element request part of the transaction.

A UAC understands this extension, but MAY reattempt a new request if it does not know
or wish to convey its location at this time. Certain scenarios
exist (location-based retargeting) believes it can correct the
stated failure in which the Geolocation-Error header, unless the location
error is required in a SIP request 5XX level error - which clearly states in order Section 4.3 not
to retarget do this. A UAC MUST follow all the message properly. This
affects how a UAS or SIP server processes guidance that pertains to such a request.

The geolocation option tag SHOULD NOT be used
UACs from Section 4.3 (Geolocation-Error header), heeding what to do
in case it receives any of the Proxy-Require
Header, because the error codes articulated in that
section.

Any UAC often will not know the underlying topology that inserted location into a request SHOULD be prepared to know which proxy will do
receive the retargeting, thus increasing Geolocation-Error header in any response, looking to
determine if a locationErrorValue is meant for the
likelihood of UAC, and to react
accordingly.

If a request failure by UAC includes location in a request, and either the first hop proxy that UAS does not
understand this extension, but is required
determine errored location was critical to by inclusion of the
option-tag in this header.

A UAC inserting a locationValue MUST include an "inserted-by="
parameter to indicate its host-id. This is copied to transaction and
accept the
"inserter=" parameter of request, or the request failed for reason other than
location, any response MAY contain a Geolocation-Error header in
containing a response
if there is something wrong locationErrorValue with the details of the location in
error.

6.2 UAS Behavior

If the original
request. Because more than one locationValue can be inserted along Geolocation header field is present in a received SIP
request, the path type of URI contained in the request, this indication is necessary to show which locationValue had the problem will
indicate if location is an LbyV in the response. For example:

Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by=alice@atlanta.example.com

The UAC MAY include a message body (part) or LbyR,
requiring an intended target of this location parameter by
adding additional dereference transaction. If the "recipient=" parameter LbyR URI is
sip:, sips: or pres:, and the UAS wants to leran the locationValue like this:

Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by=alice@atlanta.example.com;
recipient=endpoint

See section 3.2 for further details about all UAC's location,
the header parameters
of UAS MUST initiate 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 URI provided to retrieve
the PIDF-LO being conveyed by the UAC as defined in [RFC3856]. If
successful, the PIDF-LO will be returned in the NOTIFY request from
the remote host. The UAS is not REQUIRED to have its LbyV local to it. This document dereference the LbyR if
it does not give a
reason why a UAC would want to (by configuration or user choice). It is
RECOMMENDED the UAS render the location sent to it, however it is
configured to do this.

5.1.1 so.

A Require header with the 'geolocation' option tag indicates the
UAC Receiving a Location Failure Indication

If is requiring the UAS understand this extension or else send
an error response. A 420 (Bad Extension) with a sent request failed based on the location 'geolocation'
option tag in an Unsupported header would be the original
request, a 424 (Bad Location Information) appropriate
response in this case.

It is sent back possible, but undesirable, for a message to
the UAC. The 424 MUST have arrive with a Geolocation-Error header body
containing
one or more locationErrorValues in a LbyV, but with no Geolocation header field value
pointing to it (potentially no Geolocation header field at all). In
this case, the response message. A
locationErrorValue has recipient MAY still read and use the message body.
Unless stated otherwise by future standards-track publication(s), a
LbyR URI only has meaning within the Geolocation header field and
MUST NOT appear in any other SIP header field.

There are 2 Geolocation header parameters,

o "inserted-by="
o "used-for-routing"

The "inserted-by=" parameter indicating informs a Location Recipient which entity
inserted the location pertaining to SIP
element added this error, called locationValue to the
"inserter=" parameter. SIP request. This "inserter=" parameter
is copied from mandatory for each locationValue in the request. The value in
the "inserted-by=" parameter of the locationValue by the UAS or
proxy sending is copied into the error response. A UAC receiving this 424 should
review this "inserter="
parameter in the each locationErrorValue to see if it indicates this UAC. If locationErrorValue does not, the
locationErrorValue should be ignored, and there is an error in the response SHOULD
location to be
treated as a 4XX response. If locationErrorValue does indicate this
UAC, this UAC MUST process the response, including the
Geolocation-Error code (defined in section 3.4).

In addition reported back to the error code, there MAY be a list of CAtypes location sender. See section
6.2.1.

The "used-for-routing" parameter is included in the
locationErrorValue. If there are any, these are what the UAS or
proxy determined was wrong with locationValue if
a SIP server used the location contained in the
original response. The listed CAtypes will not contain request to determine how to
route or forward the values
sent by message towards the UAC ultimate destination. If
there are more than one locationValues in the request. This Geolocation header,
and it is for security/privacy
reasons.

The UAC SHOULD take correct steps possible that different locationValues were used to rectify future errors, based on route
the received error code and any CAtypes listed, 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 increase the
probability of successful requests applicable locationValue. This parameter should be
present in each locationValue used along the future. path. A UAC MAY
reattempt
"used-for-routing" parameter MUST NOT ever be removed from a new request if it believes it can correct the stated
failure
locationValue in the Geolocation-Error header.

Any UAC that a request.

Additional locationValues inserted location into a request should SHOULD be prepared to
receive placed
the Geolocation-Error header order they were generated, and not rearranged. This informs a
Location Recipient which was the last locationValue in any response, looking the message
that was used to
determine if route the header message. This is meant for the UAC, troubleshooting and to react
accordingly.

If a UAC includes location
management reasons.

Individual header parameters in a request, and either any received locationValue MUST NOT
be modified or deleted in transit to the ultimate destination.

A UAS does not
determine errored MUST NOT send location was critical to the transaction in a response message, as there can be
any number of issues/problems with receiving location, and
accept the request, UAC
or proxy servers cannot error a response. Therefore, the request failed for another reason than
location, any response MAY contain UAS, if it
wants to send a Geolocation-Error header
containing UAC its location, SHOULD do so in a locationErrorValue with the details of the location
error.

5.2 UAS Behavior

If the Geolocation header field is present new request in a received
separate transaction. This document gives no guidance which SIP
request, the type of URI contained
request to use, but SIP MESSAGE is a viable choice.

A UAS MAY include a 'geolocation' option tag in the locationValue will
indicate Supported header
of a response, indicating it does understand this extension, even if
location has been conveyed by-value was not in a message body
(part) or by-reference, requiring an additional dereference
transaction. If request to the by-reference UAS.

A UAS wishing to dereference a LbyR URI is sip:, sips: or pres:, contained in a received
request will use the
UAS MUST initiate 'presence' event package in a SUBSCRIBE request
to the URI provided to retrieve the
PIDF-LO being conveyed by the UAC per [RFC3856]. URI. If successful, accepted, the PIDF-LO will be returned in return to the UAS in a
NOTIFY request from the remote host.

A Require header with the geolocation option tag indicates request. If there are any errors during dereferencing, or in
the
UAC is requiring PIDF-LO itself, the UAS understand this extension or else send
an will error response. A 420 (Bad Extension) with a geolocation option
tag in an Unsupported header would be the appropriate response in
this case.

It is possible, but undesirable, for a message original request to arrive the
UAC with a body
containing a location-by-value, but locationErrorValue indicating what the UAS concluded was
wrong with no Geolocation header field
value pointing the location. This is to it (potentially no Geolocation header field at
all). In include any dereferencing
problems encountered.

Section 4.5 of this case, the recipient MAY still read and use document called for the message
body. Unless stated otherwise by future standards-track
publications, a Location-by-reference IANA registration of 3
URI only has meaning within
the Geolocation header field schemes (sip:, sips:, and MUST NOT appear in any other SIP
header field.

There pres:) that are 3 Geolocation header parameters,

o "inserted-by="
o "used-for-routing"
o "recipient="

The "inserted-by=" parameter informs mandatory to implement
for dereferencing.

If there is more than one location (any combination of LbyV and
LbyR), this document does not give guidance what a Location
Recipient which SIP
element added does with each location. There are no priority or
more-trusted indications given by this document. All this locationValue to the SIP request. This parameter is mandatory for
considered application specific, and out-of-scope of this document.
This document makes it clear that if when there are more than one
location, each locationValue in the request. The value in same PIDF-LO MUST be about the "inserted-by=" parameter same Target
(identifier) and point at the same position on the earth. If there
are more than one PIDF-LOs with different Target identifiers, then
the UAC is copied into merely telling the "inserter="
parameter UAS where more than one Target is, and
there should not be any conflict.

6.2.1 UAS Generating a Location Failure Indication

If a UAS receives location in each locationErrorValue if a request, but determines there is an error in a
problem with the location to be reported back to in the request, it is the responsibility
of the UAS to inform whomever inserted location sender. See section
5.2.1. into that request
there was a problem experienced. The "used-for-routing" parameter is included Geolocation header in the locationValue if
request has a SIP server used locationValue, providing the UAS a URI indicating
where the Target's location is. The Location Target identified in
the request to determine how to
route PIDF-LO may or forward may not be the message towards location inserter, or the ultimate destination. If
there are more than one locationValue in
generator of the Geolocation header, and
it request (the UAC or SIP server). Ultimately,
location is possible that different locationValues were used to route the
message at different times of this request's journey. in a PIDF-LO. This is
allowed, as it is consistent with either in the rule that anytime request as a
message is
routed based upon a locationValue, a "used-for-routing" parameter is
added body (LbyV), or it has to the applicable locationValue. This parameter should be
present dereferenced from the LbyR in each locationValue used along
the path.

More than one locationValue inserted in a request should be placed the order it was placed, and not rearranged. This informs request. LbyR records are typically kept
on a
Location Recipient LIS, which was can challenge all dereference requests. All
PIDF-LOs have a Location Target identifier. This is who the
location is about. The "inserted-by=" parameter of the last
locationValue in tells the message UAS who inserted that was used to route the message. locationValue. This
"inserted-by=" parameter is for troubleshooting and
management reasons.

The "recipient=" header copied into the "inserter=" parameter allow recipients of
the locationErrorValue generated by the Location Recipient (the
UAS), in a response, when it wants to infer inform the SIP location
"inserter=" entity type this locationValue is intended to there was a problem with the location it
received.

There can be for. more than one locationValues in a request. The types are
"endpoint", meaning
"inserter=" parameter in the locationErrorValue will distinguish it
from being misunderstood by entities that did not insert the ultimate destination UAS; "routing-entity",
meaning SIP servers; and "both" meaning this locationValue errored
location.

If there is to be
viewed by both types of SIP entities.

Individual header parameters in any received one valid locationValue MUST NOT
be modified or deleted in transit to a request, even if all the ultimate destination.

A UAS
others have errors with them, a 424 (Bad Location Information)
response MUST NOT be sent. The Location Recipient (the UAS) is
RECOMMENDED to send location a locationErrorValue for each errored
locationValue, with unique "inserter=" parameters to make sure the
right entities know which locations were in error.

As hinted at, a response message, as there location "inserter=" can be
any number of issues/problems with receiving location, and the a UAC or proxy servers cannot error a response. Therefore, the UAS, if it
wants to send can be an
in-signaling-path SIP server, who is acting as a UAC its location, SHOULD do so in a new request Sighter, as
defined in a
separate transaction. RFC3693. This document gives no guidance which SIP
request to use.

A UAS MAY include a geolocation option-tag in means the Supported header SIP server is including its
version of a response, indicating where it does understand this extension, even if
location was not in a request to thinks the UAS.

A UAS wishing UAC is, geographically. This
"inserter=" has to dereference a location-by-reference URI contained be in a received request will use the 'presence' event package in form of a
SUBSCRIBE request to the URI. If accepted, the PIDF-LO will return
to the UAS LbyR URI in a NOTIFY request. If there locationValue,
because SIP servers are any errors during
dereferencing, or in the PIDF-LO itself, not allowed to insert message bodies, as of
the UAS will error time of this publication, from all the
original request way back to the UAC with a RFC3261.

Each locationErrorValue indicating
what has a error code, letting the UAS concluded location
"inserter=" entity know what was wrong with the location. This is to
include any dereferencing problems encountered.

5.2.1 UAS Generating location supplied.
See Section 4.3 for the 5 actionable responses a Location Failure Indication

If UAC can take from
a received request conveys location, but locationErrorValue.

If the UAS has one location "inserted-by=" entity, meaning either the UAC or
more problems with a locationValue
proxy in the request (to include while
attempting message path, chose to dereference the UAC's location), the UAS MUST indicate
each problem experienced with the that location was so
important in the request to include a 'geolocation' option tag in a
Require header, the response SHOULD be a 424 (Bad Location
Information) response back to the inserting "inserter=" entity if (knowing the UAS wants response
will ultimately go to reject the request UAC regardless) if there needs to be a
locationErrorValue sent because of the
location. A location was bad. Only entities
identified in a locationErrorValue as the "inserter=" entity will
pay attention to this locationErrorValue. All other entities MUST
ignore any locationErrorValue not directed towards them. See
section 4.3 for more information on this, including all the location
specific errors and Geolocation-Error header is how parameters.

In the UAS informs above scenario ('geolocation' option tag in a Require
header), the UAC
of only other response can be a location-based error within 420, but only if the request. Section 3.4 lists
these errors, which are all IANA registered.

Because UAS
does not support this Geolocation extension to SIP allows more than one locationValue SIP, else the 424 is
sent.

If the location "inserted-by=" entity placed the 'geolocation'
option tag in a Geolocation Supported header, each from separate SIP entities, there
needs to be a means of identifying which entity inserted a
particular locationValue for single error the response purposes. This
is further complicated because SIP sends can be a single rejection
response, that in this case, needs to go to more than one entity,
and 424 if it
chooses, but also can be ignored by all any other entities SIP response, including a 200
OK. A locationErrorValue in a Geolocation-Error header that is not identified
in such a way as
to 424 (Bad Location Information) response is considered
informational by the Location Recipient, and not confuse other SIP entities.

Each locationValue has an "inserted-by=" parameter identifying which
SIP entity added this locationValue considered
important enough to reject the request. This value is
copied request based solely on bad location
information.

For example, Alice INVITEs Bob to a dialog, and includes geolocation
in the locationErrorValue "inserter=" parameter if one needs
to be sent, thus identifying request. Bob can accept the intended target of this
locationErrorValue. This INVITE with a 200 OK and still
add a locationErrorValue in the 200 OK indicating "yes, I accept
your request, and btw, something was wrong with the location you
provided (in the INVITE)". What was wrong with the location is ignored
indicated by all other
receivers of the Geolocation-Error code. Who this SIP response.

Each
locationErrorValue can have more than one error code within it. is for is indicated by the "inserter=" parameter.

Each locationErrorValue is destined for one "inserter=" entity.
This gives a UAS Location Recipient 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 concluded 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.
"inserter=" included (as far as location is concerned). Therefore,

o the CAtype values there MUST NOT be sent along with the CAtype names
listed in a locationErrorValue for each locationValue that
was considered bad by the locationErrorValue. This UAS to ensure each upstream location
inserter understands which error code(s) is intended for privacy/security
reasons. them
(and which to ignore).

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 to the same locationValue
"inserter=" 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. 400; code="Permission Necessary";
node="server42.example2.com";
inserter="alice.example.com";

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 above example says that the call at this time, Location Recipient is
server42.example.com, and inform Alice that this entity believes it cannot route this
message without knowing the "inserter="'s location. This location
contained
may be in the request, or it may need to be in the request and was bad
not. If location is encrypted, server42 doesn't know it is in some way. In this case, the 486
would contain
request. server42.example.com sends a Geolocation-Error header 424 (Bad Location
Information) response with a locationErrorValue indicating a 400
location error, which means it requires permission to view Alice's
location to proceed with processing her signaling. Section 4.3
highlights this example, stating the specific user, Alice, MUST be made aware
of this location error experienced

If there is more than one locationValue in a request, and revelation request. This document does not give
any one of
them guidance how Alice is valid to be informed (i.e., one contains enough information audio, visual,
etc). Alice can grant permission or choose not to, knowing this SIP
request attempt (to this destination, at this time) will fail. The
problem could be corrected if a future SIP request were to not generate travel
through a 424 if that was the only location present in different server than server42 (or it might not).

See Section 4.3 for further rules about the request), all
other locations MAY be ignored, Geolocation-Error header
and a 424 MUST NOT be sent because
of these other locations in the request. Another response MAY be
sent, which includes a locationErrorValue.

This document says nothing about what a Location Recipient does with
more than one 'good' location locationValue in a request (i.e., which to
choose to use). This scenario MAY be addressed in a future effort.

Further, more than one error code is allowed in the
locationErrorValue - each having an one "inserter=" parameter. The
error codes destined for the same inserter MUST NOT contradict the
meaning of the problem the UAS Location Recipient had with a particular
locationValue.

A Geolocation-Error is permissible in a 200 OK response. This means
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
is if a geolocation option-tag was in the Require header in the
request. This would necessitate a 424 response.

5.3

6.3 Proxy Behavior

[RFC3261] states message bodies cannot be added by proxies.
However, proxies are permitted to add a header to a request. This
implies that a proxy can add a Geolocation locationValue with
location-by-reference
LbyR URI, but not location-by-value LbyV message body.

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 new locationValue in a Geolocation header. Also
described earlier, each locationValue MUST contain an "inserted-by="
value indicating to a Location Recipient which host inserted
location into a particular request.

However, if location is already in a SIP request, a SIP server
SHOULD NOT add another instance of the UAC's location to LbyR that identifies the same
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
deal with more than one location in a SIP request, other than the
intended "recipient=" parameter, which has no integrity protection
in transit. If more than one locationValue states
"recipient=endpoint", this document gives no guidance what target in the UAS
is
PIDF-LO (in the <tuple-id> element) to do. the same request. This will
likely cause confusion at the Location Recipient as to which to use.

A proxy is permitted to read any locationValue, and the associated
body, if not S/MIME protected, in transit if present, and MUST can use
the contents of the header field to make location-based retargeting
decisions, if retargeting requests based on location is a function
of that proxy. Retargeting is defined in [RFC3261].

More than one Geolocation locationValue in a message is permitted,
but can cause confusion at the recipient. If a proxy chooses to add
a locationValue to a Geolocation header, which would be a local
policy decision, the new locationValue MUST be added to the end of
the header (after previous locationValue(s)). This is done to
create an order of insertion of locationValues along the path.
Proxies MUST NOT modify the order of locationValues in a geolocation
header.

A proxy wishing to dereference a location-by-reference LbyR 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

6.3.1 Proxy Behavior with Geolocation Header Parameters

SIP servers MUST NOT delete any existing Geolocation locationValue
(URI or header parameter) from a request. A Geolocation An existing locationValue
(URI or header parameter) MAY only be modified to by adding a
"used-for-routing" parameter to an existing locationValue, if the
request was retargeted based on the location within that
locationValue. Further modification of this Geolocation header
field MUST NOT occur. For example, an existing Geolocation
locationValue in a request of:

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,
like this:

Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by=alice123@atlanta.example.com;
inserted-by="alice123@atlanta.example.com";
used-for-routing
if this is the locationValue the proxy used to make a retargeting
decision based upon, but make no other modification.

A SIP server MAY add a new Geolocation locationValue to a SIP
request. The proxy SHOULD NOT insert a locationValue of the UAC a Location
Target unless it is reasonably certain it knows the actual location
of the
endpoint, Location Target, for example, if it thoroughly understands
the topology of the underlying access network and it can identify
the device reliably (in the presence of, for example, NAT). NAT or VPN).

A server adding a locationValue to an existing Geolocation header
would look like:

Geolocation: <cid:alice123@atlanta.example.com>;
inserted-by=alice123@atlanta.example.com,
inserted-by="alice123@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
locationValues. This practice MUST be done for all added
locationValues.

If this request was then retargeted by an intermediary using the
locationValue inserted by the server, the intermediary would add a
"used-for-routing" parameter like this:

It is conceivable that an initial routing decision is made on an
one locationValue, and subsequently another routing decision is
made on a different locationValue. locationValue further towards the ultimate
destination. This retargeting decision can be made on a newly
inserted locationValue. While unusual, it can occur. In such a
case, proxies MUST NOT remove any existing "used-for-routing" header
parameter. In this instance, the SIP server retargeting based on
another locationValue MUST add the "used-for-routing" header
parameter to the locationValue used for retargeting by this server.
This will result in a Geolocation header looking as if it were
retargeting more than once, which would be true - and is the desired
outcome.

5.3.2

A Proxy that inserts or adds locationValue into a request MAY move a
'geolocation' option that is in a Supported header into a Require
header if this proxy deems geolocation to be that important to
Location Recipient(s) of this request.

6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues

For proxies that receive a SIP request that contains a location
error, either in a contained message body or after the proxy does a
dereference of the LbyR URI, all the rules applicable to a UAS apply
here (see Section 5.2.1.), 6.2.1.), since in this case, the proxy is
considered a Location Recipient. Therefore, there is no reason to
restate them here, and potentially have the two section sections be
inconsistent. The one thing to add is that a proxy does not need to
examine location contained in a request. Section 5.2.1. 6.2.1. only applies
to proxies that are needing, monitoring or policing location within
requests (for whatever reason).

If a proxy inserted a locationValue into a request, it SHOULD be
ready to examine the response to that request, in case there is one
or more location errors in the response. To a great degree, this
scenario has the proxy behaving as a UAC (see section 5.1.1.) 6.1.1.) that
included a locationValue a request, which then receives an error to
that locationValue.

If there is one or more locationErrorValues in the response, the

This location inserting proxy SHOULD examine each "inserter=" parameter in each
locationErrorValue - looking be transaction stateful for one that identifies the proxy.
response. If
one matches the proxy's "inserted-by" value, that locationErrorValue proxy is configured as a stateless proxy, and it
inserts location, it MUST process and monitor all SIP responses,
looking for only locationErrorValues that proxy. This locationErrorValue needs indicate it was the "inserter="
to be reviewed
for each error code and CAtype contained learn that location it supplied was in the value. The proxy error. It SHOULD attempt react
accordingly to correct for the error reported to it for future
insertion of location into requests. code received. This document gives no
guidance what the proxy should do to rectify the bad location
information, but a future document MAY address this.

7. Geopriv Privacy Considerations

Transmitting location

Location information is considered by most to be highly
sensitive information, requiring protection from eavesdropping,
tracking,
and altering in transit. [RFC3693] articulates rules to
be followed by any protocol wishing to be considered a Geopriv "Using
Protocol", specifying how a transport protocol meetings meets those rules.
This section describes how SIP as a Using Protocol meets those
requirements.

Quoting requirement #4 of [RFC3693]:

"The Using Protocol has to obey the privacy and security
instructions coded in the Location Object and in the
corresponding Rules regarding the transmission and storage
of the LO."

This document requires that SIP entities sending or receiving
location MUST obey such instructions.

Quoting requirement #5 of [RFC3693]:

"The Using Protocol will typically facilitate that the keys
associated with the credentials are transported to the
respective parties, that is, key establishment is the
responsibility of the Using Protocol."

[RFC3261] and the documents it references define the key
establishment mechanisms.

Quoting requirement #6 of [RFC3693]:

"(Single Message Transfer) In particular, for tracking of
small Target devices, the design should allow a single
message/packet transmission of location as a complete
transaction."

When used for tracking, a simple NOTIFY or UPDATE normally is
relatively small, although the PIDF itself can get large. Normal
RFC 3261 procedures of reverting to TCP when the MTU size is
exceeded would be invoked.

8. Security Considerations

Conveyance of physical location of a UAC raises privacy concerns,
and depending on use, there probably will be authentication and
integrity concerns. This document calls for conveyance to normally
be accomplished through secure mechanisms, like S/MIME protecting
message bodies (but this is not widely deployed) or TLS protecting
the overall signaling. In cases where a session set-up is
retargeted based on the location of the UAC initiating the call or
SIP MESSAGE, securing the by-value LbyV location with an end-to-end
mechanism such as S/MIME is problematic, because one or more proxies
on the path need the ability to read the location information to
retarget the message to the appropriate new destination UAS.
Securing the location hop-by-hop, using TLS, protects the message
from eavesdropping and modification, but exposes the information to
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
location-based routing services, so that end-to-middle solutions
might not be appropriate either.

These same issues exist for basic SIP signaling, but SIP normally
does not carry information to physically track a user; making this
extension especially sensitive.

When location is inserted by a UAC, which is RECOMMENDED, it can
decide whether to reveal its location using hop-by-hop methods. UAC
implementations MUST make such capabilities conditional on explicit
user permission, and SHOULD alert a user that location is being
conveyed. Proxies inserting location for location-based routing are
unable to meet this requirement, and such use is NOT RECOMMENDED.
Proxies conveying location using this extension MUST have the
permission of the Target to do so.

One facet within this extension is such that locations can be placed
on a remote server, accessible with the possession of a URI. The
concept of a location-by-reference LbyR URI has its own security considerations. It is
tempting to assume that the dereference would have authentication,
authorization and other security mechanisms that limit the access to
information. Unfortunately, this might not be true. The access
network the UAC is connected to can be the source of location
reference, and it might not have any credentialing mechanism
suitable for controlling access to location. Consider,
specifically, a nomadic user connected to an access 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 Location
Recipients. The recipient of a reference does not know if a
reference has appropriate authorization policies or not. The LS
should provide location to any requestor.

Accordingly, possession of the reference should be considered
equivalent to possession of the value, and the reference should be
treated with the same degree of care as the value. Specifically,
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
the server is a Session Border Controller or B2BUA, this might cause
there to be conflicting location information (error-code=6), which
could Specifically,
TLS MUST be purposeful used to error protect the request or just cause operation
problems. This problem might be inadvertent, compounded by security of the fact
that there will likely be some SIP servers reference. Notice
that add location on
every call set-up. this does not constrain the dereference protocol to use TLS.
That specification is left entirely to the dereferencing protocol
documents.

There is no integrity on any locationValue or locationErrorValue
header parameter, parameter end-to-end (or middle-to-end if the value was
inserted by a intermediary), so recipients of either header need to
implicitly trust the header contents, and take whatever precautions
each entity deems appropriate give these facts.

9. IANA Considerations

The following are the IANA considerations made by this SIP
extension. Modifications and additions to these registrations
require a standards track RFC (Standards Action).

8.1

9.1 IANA Registration for the SIP Geolocation Header

The SIP Geolocation header is created by this document, with its
definition and rules in Section 3.2 4.1 of this document, to be added to
the sip-parameters.

The Geolocation Header has the following header parameters to be
Registered sip-parameters, in a new table:

Geolocation Header parameters

Header the portion titled "Header Field Parameters Parameter-values
and Parameter Values".

Predefined
Header Field Parameter Name Values Reference
---------------- ---------------- --------------
recipient endpoint RFC XXXX (this document)
recipient routing-entity RFC XXXX (this document)
recipient both RFC XXXX (this document)

8.2 ------------------- ---------- ---------
Geolocation inserted-by= no [this doc]
Geolocation used-for-routing no [this doc]

9.2 IANA Registration for New SIP Option Tag

The SIP option-tag option tag "geolocation" is created by this document, with
the definition and rule in Section 3.5 4.4 of this document, to be added
to sip-parameters within IANA.

8.3

9.3 IANA Registration for Response Code 424

Reference: RFC-XXXX (i.e., this document)
Response code: 424 (recommended number to assign)
Default reason phrase: Bad Location Information

This SIP Response code is defined in section 3.3 4.2 of this document.

8.4

9.4 IANA Registration of New Geolocation-Error Header

The SIP Geolocation-error header is created by this document, with
its definition and rules in Section 3.4 4.3 of this document, to be
added to the sip-parameters.

8.5 sip-parameters, in the portion titled "Header Field
Parameters and Parameter Values".

Predefined
Header Field Parameter Name Values Reference
----------------- ------------------- ---------- ---------
Geolocation-Error inserter= no [this doc]
Geolocation-Error node= no [this doc]
Geolocation-Error code= no [this doc]

9.5 IANA Registration for the SIP Geolocation-Error Codes

New location specific Geolocation-Error codes are created by this
document, and registered in a new table at sip-parameters within
IANA. Details of these error codes are in Section 3.4 4.3 of this
document.

Geolocation-Error codes
-----------------------
Geolocation-Error codes provide reason for the error discovered by
Location Recipients, categorized by action to be taken by error
recipient to place be placed into SIP response messages responses to inform the location
inserter of the error.

Code Description Reference
---- --------------------------------------------------- ---------
100 Location Format Not Supported: the location format [this doc]
supplied in the request, by-value or by-reference,
was not supported.

101 Coordinate-location Format Desired: the "Cannot Process Location" General location error, [this doc]
format supplied in the request was understood
and supported, but that the recipient, or an
application on the recipient, can or prefers to
only process location in the coordinate-location
format.

102 Civic-location Format Desired: the
meaning location [this doc]
format supplied in the request was understood
and supported, but that the recipient, or an
application on the recipient, can cannot be
processed at this time. No actionable guidance.
Can be treated as a 200 or prefers to
only process location in the civic-location
format.

103 Cannot Parse 300 error by error
recipient.

200 "Retry Location Later" (with same data) Location Supplied: the location [this doc]
provided, whether by-value or by-reference, in a
request is not well formed.

104 Cannot Find Location: the location was expected in [this doc]
the request, but the
cannot be processed at this time. Error recipient cannot find it.

105 Conflicting Locations Supplied: a
should try again with same data.

300 "Retry Location Recipient Later" (with device updated location) [this doc]
received more than one location describing where the
Target is, and is either unsure which whole location
is true or which parts of multiple locations make up
where the Target is.

106 Incomplete
Location Supplied: there is not enough cannot be processed at this time. Error
recipient should try again with same data.

400 "Permission Necessary" Permission from calling user [this doc]
to reveal location information in the request to determine
where before request can
be processed. This is a routing by location error.
User MUST be informed of permission request.

500 "Location Information Denial" Request was actively
denied because of the location Target is.

107 Cannot Dereference: in the act request.
Recipient should not try again.

9.6 IANA Registration of dereferencing failed [this doc]
to return the Target's location. LbyR Schemes

This generally
means the supplied URI is bad.

108 Dereference Denied: there was insufficient [this doc]
authorization document directs IANA to dereference create a new set of parameters in a
separate location from SIP and Geopriv, called the Target's location.

109 Dereference Timeout: "Location
Reference URI" registry, containing the dereferencing node has not [this doc]
received URI scheme, the Target's location within a reasonable.
timeframe

110 Cannot Process Dereference:
Content-Type, and the dereference protocol [this doc]
has received reference. Below is an overload condition error, indicating
the location cannot be accessed at this time.

120 Unsupported example of how it
could look

URI Scheme - sip desired: the location Content-Type Reference
---------- ------------ ---------
SIP: [this doc]
dereferencer cannot dereference using the
location-by-reference URI scheme supplied, and
prefers a sip-uri.

121 Unsupported Scheme - sips desired: the location
SIPS: [this doc]
dereferencer cannot dereference using the
location-by-reference URI scheme supplied, and
prefers a sips-uri.

122 Unsupported Scheme - pres desired: the location
PRES: [this doc]
dereferencer cannot dereference using the
location-by-reference URI scheme supplied, and
prefers a pres-uri.

Additions to this registry require an industry specification.

10. Acknowledgements

To Dave Oran for helping to shape this idea. To Jon Peterson and
Dean Willis on guidance of the effort. To Allison Mankin, Dick
Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom,
Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith
Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat,
Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie and Matt
Lepinski for constructive feedback. A special thanks to Dan Wing
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.

11. References

10.1

11.1 References - Normative

[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.

[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005

[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
[RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource
Locators", RFC 2393, August 1998

[RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J.
Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004

[RFC3856] J. Rosenberg, " A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004

[RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859,
August 2004

[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging" , RFC 3428, December 2002

[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002

[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
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.

[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.

[IANA-civic] http://www.iana.org/assignments/civic-address-types-
registry

10.2

11.2 References - Informative

[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004

[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", draft-ietf-geopriv-dhcp-civil-09, "work in
progress", January RFC 4776, October 2006

Author Information

James Polk
Cisco Systems
3913 Treemont Circle 33.00111N
Colleyville, Texas 76034 96.68142W

Phone: +1-817-271-3552
Email: jmpolk@cisco.com

Brian Rosen
NeuStar, Inc.
470 Conrad Dr. 40.70497N
Mars, PA 16046 80.01252W
US

Phone: +1 724 382 1051
Email: br@brianrosen.net

Appendix A. Requirements for SIP Location Conveyance

The following subsections address the requirements placed on the
UAC, the UAS, as well as SIP proxies when conveying location. There
is a motivational statement below each requirements that is not
obvious in intent

A.1 Requirements for a UAC Conveying Location

UAC-1 The SIP INVITE Method [RFC3261] must support location
conveyance.

UAC-2 The SIP MESSAGE method [RFC3428] must support location
conveyance.

UAC-3 SIP Requests within a dialog should support location
conveyance.

UAC-4 Other SIP Requests may support location conveyance.

UAC-5 There must be one, mandatory to implement means of
transmitting location confidentially.

Motivation: interoperability

UAC-6 It must be possible for a UAC to update location conveyed
at any time in a dialog, including during dialog
establishment.

Motivation: in case a UAC has moved prior to the establishment of a
dialog between UAs, the UAC must be able to send new location
information. In the case of location having been conveyed,
and the UA moves, it needs a means to update the conveyed to
party of this location change.

UAC-7 The privacy and security rules established within [RFC3693]
that would categorize SIP as a 'Using Protocol' must be met.

UAC-8 The PIDF-LO [RFC 4119] is a mandatory to implement format for
location conveyance within SIP, whether included by-value LbyV or
by-reference.
LbyR.

Motivation: interoperability with other IETF location protocols and
mechanisms

UAC-9 There must be a mechanism for the UAC to request the UAS send
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 to convey location from the UACs lack of knowledge of its
location

Motivation: Failure to receive location when it is expected can be
because the UAC does not implement this extension, or it can
be that the UAC implements the extension, but does not know
where it is. This may be, for example, due to the failure of
the access network to provide a location acquisition
mechanisms the UAC understands. These cases must be
differentiated.

UAC-11 It must be possible to convey location to proxy servers
along the path.

Motivation: Location-based routing.

A.2 Requirements for a UAS Receiving Location

The following are the requirements for location conveyance by a UAS:

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
not provide applicable location information.

In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS

A.3 Requirements for SIP Proxies and Intermediaries

The following are the requirements for location conveyance by a SIP
proxies and intermediaries:

Proxy-1 Proxy servers must be capable of adding a Location header
field during processing of SIP requests.

Motivation: Provide the capability of network assertion of location
when UACs are unable to do so, or when network assertion is
more reliable than UAC assertion of location

Note: Because UACs connected to sip signaling networks may have
widely varying access network arrangements, including VPN
tunnels and roaming mechanisms, it may be difficult for a
network to reliably know the location of the endpoint. Proxy
assertion of location is NOT RECOMMENDED unless the sip
signaling network has reliable knowledge of the actual
location of the Targets.

Proxy-2 There must be a unique 4XX response informing the UAC it
did not provide applicable location information.

Appendix B. Example of INVITE with S/MIME encrypted Civic PIDF-LO

This appendix gives an *EXAMPLE* (meaning this might contain errors
based on future review) of a SIP INVITE request that points to the
same position on the earth as the coordinate based example that's in
section 4.1 5.1 in the body of this document:

The INVITE request is TLS hop-by-hop encrypted, and the
location-by-value
LbyV message body is S/MIME encrypted. This example
shows the location message body in its unencrypted form for clarity.
The message body lines below that have the '$' signs are S/MIME
encrypted. In this example, the SDP is not S/MIME encrypted.

INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com
;branch=z9hG4bK74bf9
Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:alice123@atlanta.example.com>
;inserted-by=alice@atlanta.example.com ;recipient=endpoint
;inserted-by="alice@atlanta.example.com"
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 31862 INVITE
Contact: <sips:alice@pc33.atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...

--boundary1

Content-Type: application/sdp

...SDP goes here

--boundary1

Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-ID: alice123@atlanta.example.com

$ Content-Type: application/pidf+xml
$
$ <?xml version="1.0" encoding="UTF-8"?>
$ <presence xmlns="urn:ietf:params:xml:ns:pidf"
$ xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
$ xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
$ entity="pres:alice@atlanta.example.com">
$ <tuple id="sg89ae">
$ <timestamp>2007-07-09T14:00:00Z</timestamp>
$ <status>
$ <gp:geopriv>
$ <gp:location-info>
$ <cl:civicAddress>
$ <cl:country>US</cl:country>
$ <cl:A1>Texas</cl:A1>
$ <cl:A3>Colleyville</cl:A3>
$ <cl:HNO>3913</cl:HNO>
$ <cl:A6>Treemont</cl:A6>
$ <cl:STS>Circle</cl:STS>
$ <cl:PC>76034</cl:PC>

$ <cl:NAM>Haley's Place</cl:NAM>
$ <cl:FLR>1</cl:FLR>
$ <cl:civicAddress>
$ </gp:location-info>
$ <gp:usage-rules>
$ <gp:retransmission-allowed>no</gp:retransmission-allowed>
$ <gp:retention-expiry>2007-07-27T18:00:00Z</gp:retention-
$ expiry>
$ </gp:usage-rules>
$ <gp:method>DHCP</gp:method>
$ <gp:provided-by>www.example.com</gp:provided-by>
$ </gp:geopriv>
$ </status>
$ </tuple>
$ </presence>
--boundary1--

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
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 such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).