draft-ietf-sipcore-location-conveyance-03.txt   draft-ietf-sipcore-location-conveyance-04.txt 
Network Working Group James Polk Network Working Group James Polk
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expires: January 12, 2011 Brian Rosen Expires: April 25, 2011 Brian Rosen
Intended Status: Standards Track (PS) Jon Peterson Intended Status: Standards Track (PS) Jon Peterson
NeuStar NeuStar
July 12, 2010 Oct 25, 2010
Location Conveyance for the Session Initiation Protocol Location Conveyance for the Session Initiation Protocol
draft-ietf-sipcore-location-conveyance-03.txt draft-ietf-sipcore-location-conveyance-04.txt
Abstract Abstract
This document defines an extension to the Session Initiation This document defines an extension to the Session Initiation
Protocol (SIP) to convey geographic location information from one Protocol (SIP) to convey geographic location information from one
SIP entity to another SIP entity. The extension covers end-to-end SIP entity to another SIP entity. The extension covers end-to-end
conveyance as well as location-based routing, where SIP conveyance as well as location-based routing, where SIP
intermediaries make routing decisions based upon the location of the intermediaries make routing decisions based upon the location of the
user agent client. user agent client.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on Jan 12, 2011. This Internet-Draft will expire on April 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Conventions and Terminology used in this document . . . . . . 3 1. Conventions and Terminology used in this document . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 3 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4
4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 3.1 Location Conveyed by Value . . . . . . . . . . . . . . . 4
4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 3.2 Location Conveyed as a Location URI . . . . . . . . . . . 4
4.2 424 (Bad Location Information) Response Code . . . . . . 9 3.3 Location Conveyed though a SIP Intermediary . . . . . . . 5
4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 10 3.4 SIP Intermediary Replacing Bad Location . . . . . . . . . 6
4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 12 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 8
4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 12 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 8
4.6 Location URIs Allowed . . . . . . . . . . . . . . . . . . 12 4.2 424 (Bad Location Information) Response Code . . . . . . 10
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 13 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 13 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 14
5.2 Two Locations Composed in Same Location Object Example . 14 4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 14
6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 16 4.6 Location URIs Allowed . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 14
8.1 IANA Registration for New SIP Geolocation Header . . . . 19 5.2 Two Locations Composed in Same Location Object Example . 16
8.2 IANA Registration for New SIP 'geolocation' Option Tag . 19 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 18
8.3 IANA Registration for New 424 Response Code . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.4 IANA Registration for New SIP Geolocation-Error Header . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
8.5 IANA Registration for New SIP Geolocation-Error Codes . . 19 8.1 IANA Registration for New SIP Geolocation Header . . . . 20
8.6 IANA Registration of Location URI Schemes . . . . . . . . 20 8.2 IANA Registration for New SIP 'geolocation' Option Tag . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8.3 IANA Registration for New 424 Response Code . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.4 IANA Registration for New SIP Geolocation-Error Header . 20
10.1 Normative References . . . . . . . . . . . . . . . . . 21 8.5 IANA Registration for New SIP Geolocation-Error Codes . . 20
10.2 Informative References . . . . . . . . . . . . . . . . . 22 8.6 IANA Registration of Location URI Schemes . . . . . . . . 21
Author Information . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Requirements for SIP Location Conveyance . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1 Normative References . . . . . . . . . . . . . . . . . 22
10.2 Informative References . . . . . . . . . . . . . . . . . 23
Author Information . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Requirements for SIP Location Conveyance . . . . 24
1. Conventions and Terminology used in this document 1. Conventions and Terminology used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. This document furthermore uses numerous terms defined in [RFC2119]. This document furthermore uses numerous terms defined
in RFC 3693 [RFC3693], including Location Objection, Location in RFC 3693 [RFC3693], including Location Objection, Location
Recipient, Location Server, Target, and Using Protocol. Recipient, Location Server, Target, and Using Protocol.
skipping to change at page 4, line 4 skipping to change at page 4, line 6
recipients, as any SIP proxy server in the signaling path that recipients, as any SIP proxy server in the signaling path that
inspects the location of the Target must also be considered a inspects the location of the Target must also be considered a
Location Recipient. In presence-like architectures, an intermediary Location Recipient. In presence-like architectures, an intermediary
that receives publications of location information and distributes that receives publications of location information and distributes
them to watchers acts as a Location Server per RFC 3693. This them to watchers acts as a Location Server per RFC 3693. This
location conveyance mechanism can also be used to deliver URIs point location conveyance mechanism can also be used to deliver URIs point
to such Location Servers where prospective Location Recipients can to such Location Servers where prospective Location Recipients can
request Location Objects. request Location Objects.
3. Overview of SIP Location Conveyance 3. Overview of SIP Location Conveyance
An operational overview of SIP location conveyance can be shown in 4 An operational overview of SIP location conveyance can be shown in 4
basic diagrams, with most applications falling under one of these basic diagrams, with most applications falling under one of the
basic use cases. following basic use cases. Each is separated into its own subsection
here in section 3.
Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob
is an LR. A SIP intermediary appears in some of the diagrams. Any is an LR. A SIP intermediary appears in some of the diagrams. Any
SIP entity that receives and inspects location information is an LR, SIP entity that receives and inspects location information is an LR,
therefore any of the diagrams the SIP intermediary receives the SIP therefore any of the diagrams the SIP intermediary receives the SIP
request is potentially an LR - though that does not mean such an request is potentially an LR - though that does not mean such an
intermediary necessarily has to route the SIP request based on the intermediary necessarily has to route the SIP request based on the
location information. In some use cases, location information location information. In some use cases, location information
passes through the LS on the right of each diagram. passes through the LS on the right of each diagram.
3.1 Location Conveyed by Value
We start with the simplest diagram of Location Conveyance, Alice to
Bob, where no other layer 7 entities are involved.
Alice SIP Intermediary Bob LS Alice SIP Intermediary Bob LS
| | | | | | | |
| Request w/Location | | | Request w/Location | |
|----------------------------------->| | |----------------------------------->| |
| | | | | |
| Response | | | Response | |
|<-----------------------------------| | |<-----------------------------------| |
| | | | | | | |
Figure 1. Location Conveyed by Value Figure 1. Location Conveyed by Value
In Figure 1, Alice is both the Target and the LS that is conveying In Figure 1, Alice is both the Target and the LS that is conveying
her location directly to Bob, who acts as an LR. This conveyance is her location directly to Bob, who acts as an LR. This conveyance is
point-to-point - it does not pass through any SIP-layer point-to-point - it does not pass through any SIP-layer
intermediary. A Location Object appears by-value in the initial SIP intermediary. A Location Object appears by-value in the initial SIP
request as a MIME body, and Bob responds to that SIP request as request as a MIME body, and Bob responds to that SIP request as
appropriate. There is a 'Bad Location Information' response code appropriate. There is a 'Bad Location Information' response code
introduced within this document to specifically inform Alice if she introduced within this document to specifically inform Alice if she
conveys bad location to Bob (i.e., Bob "cannot parse the location conveys bad location to Bob (e.g., Bob "cannot parse the location
provided", or "there is not enough location information to determine provided", or "there is not enough location information to determine
where Alice is"). where Alice is").
3.2 Location Conveyed as a Location URI
Here we make Figure 1 a little more complicated by showing a
diagram of indirect Location Conveyance from Alice to Bob, where
Bob's entity has to retrieve the location object from a 3rd party
server.
Alice SIP Intermediary Bob LS Alice SIP Intermediary Bob LS
| | | | | | | |
| Request w/Location URI | | | Request w/Location URI | |
|----------------------------------->| | |----------------------------------->| |
| | Dereference | | | Dereference |
| | Request | | | Request |
| (To: Location URI) | | (To: Location URI) |
| |---------------->| | |---------------->|
| | | | | |
| | Dereference | | | Dereference |
skipping to change at page 5, line 19 skipping to change at page 5, line 35
carried in the SIP message (more of those details later). If Alice carried in the SIP message (more of those details later). If Alice
sends Bob this Location URI, Bob will need to dereference the URI - sends Bob this Location URI, Bob will need to dereference the URI -
analogous to Content Indirection [RFC4483] - in order to request the analogous to Content Indirection [RFC4483] - in order to request the
location information. In general, the LS provides the location value location information. In general, the LS provides the location value
to Bob instead of Alice directly. From a user interface to Bob instead of Alice directly. From a user interface
perspective, Bob the user won't know that this information was perspective, Bob the user won't know that this information was
gathered from an LS indirectly rather than culled from the SIP gathered from an LS indirectly rather than culled from the SIP
request, and practically this does not impact the operation of request, and practically this does not impact the operation of
location-based applications. location-based applications.
3.3 Location Conveyed though a SIP Intermediary
In Figure 3, we introduce the idea of a SIP intermediary into the
example to illustrate the role of proxying in the location
architecture. This intermediary could be a SIP proxy or it could be
a back-to-back-user-agent (B2BUA). In this message flow, the SIP
intermediary could act as a LR, in addition to Bob. The primary use
case for intermediaries consuming location information is
location-based routing. In this case, the intermediary chooses a
next hop for the SIP request by consulting a specialized location
service which selects forwarding destinations based on geographical
location. In this case, the intermediary acts as a Location
Recipient.
Alice SIP Intermediary Bob LS Alice SIP Intermediary Bob LS
| | | | | | | |
| Request | | | | Request | | |
| w/Location | | | | w/Location | | |
|--------------->| | | |--------------->| | |
| | Request | | | | Request | |
| | w/Location | | | | w/Location | |
| |------------------>| | | |------------------>| |
| | | | | | | |
| | Response | | | | Response | |
| |<------------------| | | |<------------------| |
| Response | | | | Response | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 3. Location Conveyed though a SIP Intermediary Figure 3. Location Conveyed though a SIP Intermediary
In Figure 3, we introduce the idea of a SIP intermediary into the However, the most common case will be one in which the SIP
example to illustrate the role of proxying in the location intermediary receives a request with location information (conveyed
architecture. This intermediary could be a SIP proxy or it could be either by-value or by-reference) and does not know or care about
a back-to-back-user-agent (B2BUA). In this message flow, the SIP Alice's location, or support this extension, and merely passes it on
intermediary may act as a LR, in addition to Bob. The primary use to Bob. In this case, the intermediary does not act as a Location
case for intermediaries consuming location information is
location-based routing. In this case, the intermediary chooses a
next hop for the SIP request by consulting a specialized location
service which selects forwarding destinations based on geographical
location. In this case, the intermediary acts as a Location
Recipient. Recipient.
However, it can be the case that the SIP intermediary receives a
request with location information (conveyed either by-value or
by-reference) and does not know or care about Alice's location, or
support this extension, and merely passes it on to Bob - in this
case, the intermediary does not act as a Location Recipient.
Note that an intermediary does not have to perform location-based Note that an intermediary does not have to perform location-based
routing in order to be location recipient. It could be the case that routing in order to be location recipient. It could be the case that
a SIP intermediary which does not perform location-based routing but a SIP intermediary which does not perform location-based routing but
does care when Alice includes her location; for example, it could does care when Alice includes her location; for example, it could
care that the location information is complete or that it correctly care that the location information is complete or that it correctly
identifies where Alice is. The best example of this is identifies where Alice is. The best example of this is
intermediaries that verify location information for emergency intermediaries that verify location information for emergency
calling, but it could also be for any location based routing - e.g., calling, but it could also be for any location based routing - e.g.,
contacting Pizza Hut, making sure that organization has Alice's contacting Pizza Hut, making sure that organization has Alice's
proper location in the initial SIP request. proper location in the initial SIP request.
There is another scenario in which the SIP intermediary cares about
location and is not an LR, one in which the intermediary inserts
another location of the Target, Alice in this case, into the
request, and forwards it. This secondary insertion is generally not
advisable because downstream SIP entities will not be given any
guidance about which location to believe is better, more reliable,
less prone to error, more granular, worse than the other location or
just plain wrong.
The only conceivable way forward, when a second location is placed
into the same SIP request by a SIP intermediary is to
take a "you break it, you bought it" philosophy with respect to the
inserting SIP intermediary. That entity becomes completely
responsible for all location within that SIP request (more on this
in Section 4).
3.4 SIP Intermediary Replacing Bad Location
If the SIP intermediary rejects the message due to unsuitable If the SIP intermediary rejects the message due to unsuitable
location information (we are not going to discuss any other reasons location information (we are not going to discuss any other reasons
in this document, and there are many), the SIP response will in this document, and there are many), the SIP response will
indicate there was 'Bad Location Information' in the SIP request, indicate there was 'Bad Location Information' in the SIP request,
and provide a location specific error code indicating what Alice and provide a location specific error code indicating what Alice
needs to do to send an acceptable request. needs to do to send an acceptable request (see Figure 4 for this
scenario).
Alice SIP Intermediary Bob LS Alice SIP Intermediary Bob LS
| | | | | | | |
| Request | | | | Request | | |
| w/Location | | | | w/Location | | |
|--------------->| | | |--------------->| | |
| | | | | | | |
| Rejected | | | | Rejected | | |
| w/New Location | | | | w/New Location | | |
|<---------------| | | |<---------------| | |
skipping to change at page 7, line 33 skipping to change at page 8, line 20
4. SIP Modifications for Geolocation Conveyance 4. SIP Modifications for Geolocation Conveyance
The following sections detail the modifications The following sections detail the modifications
to SIP for location conveyance. to SIP for location conveyance.
4.1 The Geolocation Header 4.1 The Geolocation Header
This document defines "Geolocation" as a new SIP header field This document defines "Geolocation" as a new SIP header field
registered by IANA, with the following ABNF [RFC5234]: registered by IANA, with the following ABNF [RFC5234]:
Geolocation = "Geolocation" HCOLON locationArg Geolocation-header = "Geolocation" HCOLON Geolocation-value
(*COMMA locationArg) Geolocation-value = ( locationValue [ COMMA locationValue ] )
locationArg = locationValue / routing-param / routing-param
locationValue = LAQUOT locationURI RAQUOT locationValue = LAQUOT locationURI RAQUOT
*(SEMI geoloc-param) *(SEMI geoloc-param)
locationURI = sip-URI / sips-URI / pres-URI locationURI = sip-URI / sips-URI / pres-URI
/ http-URI / HTTPS-URI
/ cid-url ; (from RFC 2392) / cid-url ; (from RFC 2392)
/ absoluteURI ; (from RFC 3261) / absoluteURI ; (from RFC 3261)
geoloc-param = generic-param; (from RFC 3261) geoloc-param = generic-param; (from RFC 3261)
routing-param = "routing-allowed" EQUAL "yes" / "no" routing-param = "routing-allowed" EQUAL "yes" / "no"
sip-URI, sips-URI and absoluteURI are defined according to [RFC3261]. sip-URI, sips-URI and absoluteURI are defined according to [RFC3261].
The pres-URI is defined in [RFC3859]. The pres-URI is defined in [RFC3859].
HTTP-URI and HTTPS-URI are defined according to [RFC2616] and
[RFC2818], respectively.
The cid-url is defined in [RFC2392] to locate message body parts. The cid-url is defined in [RFC2392] to locate message body parts.
This URI type is present in a SIP request when location is conveyed This URI type is present in a SIP request when location is conveyed
as a MIME body in the SIP message. as a MIME body in the SIP message.
GEO-URIs [RFC5870] are not appropriate for usage the SIP Geolocation
header.
Other URI schemas used in the location URI MUST be reviewed against Other URI schemas used in the location URI MUST be reviewed against
the RFC 3693 [RFC3693] criteria for a Using Protocol. the RFC 3693 [RFC3693] criteria for a Using Protocol.
The Geolocation header field has zero or one locationValue, but The Geolocation header field has zero, one or two locationValues,
MUST NOT contain more than one locationValue. but MUST NOT contain more than two locationValue. A SIP intermediary
SHOULD NOT add location to a SIP request that already contains
location. This will quite often lead to confusion within LRs.
However, if a SIP intermediary were to add location, even if
location was not previously present in a SIP request, that SIP
intermediary is fully responsible for addressing the concerns of any
424 (Bad Location Information) SIP response it receives about this
location addition, and MUST NOT pass on (upstream) the 424 response.
The placement of the "routing-allowed" header field parameter is The placement of the "routing-allowed" header field parameter,
outside the locationValue, and MUST always be last in the header strongly encouraged by [RFC5606], is outside the locationValue, and
field value. The routing-allowed parameter MAY be present when no MUST always be last in the header field value. The routing-allowed
locationValue is present. This scenario sets the routing-allowed parameter MUST be present, even when no locationValue is present.
policy downstream along the request's signaling path. This header This scenario sets the routing-allowed policy downstream along the
field parameter only has the values "=yes" or "=no". When this request's signaling path. This header field parameter only has the
parameter is "=yes", the locationValue can be used for routing values "=yes" or "=no". When this parameter is "=yes", the
decisions along the downstream signaling path by intermediaries. locationValue can be used for routing decisions along the downstream
signaling path by intermediaries. If no routing-allowed parameter
is present in a SIP request, a SIP intermediary MAY insert this
value with a RECOMMENDED value of "no" by default.
When this parameter is "=no", this means no locationValue (inserted When this parameter is "=no", this means no locationValue (inserted
by the originating UAC or any intermediary along the signaling path by the originating UAC or any intermediary along the signaling path
can be used by any SIP intermediary to make routing decisions. can be used by any SIP intermediary to make routing decisions.
Intermediaries that attempt to use the location information for Intermediaries that attempt to use the location information for
routing purposes in spite of this counter indication may end up routing purposes in spite of this counter indication may end up
routing the request improperly as a result. Sections 4.3 describes routing the request improperly as a result. Sections 4.3 describes
the details on what a routing intermediary does if it determines it the details on what a routing intermediary does if it determines it
needs to use the location in the SIP request in order to process the needs to use the location in the SIP request in order to process the
message further. message further.
skipping to change at page 9, line 8 skipping to change at page 10, line 11
MESSAGE [RFC3428], REFER [RFC3515], MESSAGE [RFC3428], REFER [RFC3515],
SUBSCRIBE [RFC3265], NOTIFY [RFC3265], SUBSCRIBE [RFC3265], NOTIFY [RFC3265],
PUBLISH [RFC3903], PRACK [RFC3262] PUBLISH [RFC3903], PRACK [RFC3262]
The following table extends the values in Tables 2 and 3 of RFC 3261 The following table extends the values in Tables 2 and 3 of RFC 3261
[RFC3261]. [RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA Header field where proxy INV ACK CAN BYE REG OPT PRA
---------------------------------------------------------------- ----------------------------------------------------------------
Geolocation R ar o - - o o o o Geolocation R ar o - - o o o o
Geolocation 424 r o - - o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB Header field where proxy SUB NOT UPD MSG REF INF PUB
---------------------------------------------------------------- ----------------------------------------------------------------
Geolocation R ar o o o o o o o Geolocation R ar o o o o o o o
Geolocation 424 r o o o o o o o
Table 1: Summary of the Geolocation Header Field Table 1: Summary of the Geolocation Header Field
The Geolocation header field MAY be included in any one of the The Geolocation header field MAY be included in any one of the
optional requests by a UA. A proxy MAY add the Geolocation header optional requests by a UA. A proxy MAY add the Geolocation header
field, but MUST NOT modify any pre-existing locationValue, including field, but MUST NOT modify any pre-existing locationValue, including
the "routing-allowed" header field value. the "routing-allowed" header field value.
A SIP intermediary MAY add a Geolocation header field if one is not A SIP intermediary MAY add a Geolocation header field if one is not
present - for example, when a user agent does not support the present - for example, when a user agent does not support the
Geolocation mechanism but their outbound proxy does and knows their Geolocation mechanism but their outbound proxy does and knows their
location, or any of a number of other use cases (see Figure 4 in location, or any of a number of other use cases (see Section 3).
section 3). When adding a Geolocation header, a SIP intermediary When adding a Geolocation header, a SIP intermediary MAY supply the
MAY supply the "routing-allowed" parameter if not yet present in the "routing-allowed" parameter if not yet present in the SIP request,
SIP request. but MUST NOT add a "routing-allowed" parameter if one is already
present in this SIP request.
SIP implementations are advised to pay special attention to the SIP implementations are advised to pay special attention to the
policy elements for location retransmission and retention described policy elements for location retransmission and retention described
in RFC 4119. in RFC 4119.
4.2 424 (Bad Location Information) Response Code 4.2 424 (Bad Location Information) Response Code
This SIP extension creates a new location-specific response code, This SIP extension creates a new location-specific response code,
defined as follows, defined as follows,
424 (Bad Location Information) 424 (Bad Location Information)
The 424 (Bad Location Information) response code is a rejection of The 424 (Bad Location Information) response code is a rejection of
the request due to its location contents, indicating location the request due to its location contents, indicating location
information that was malformed or not satisfactory for the information that was malformed or not satisfactory for the
recipient's purpose, or could not be dereferenced. recipient's purpose, or could not be dereferenced.
A SIP intermediary can also reject a location it receives from a A SIP intermediary can also reject a location it receives from a
Target when it understands the Target to be in a different location. Target when it understands the Target to be in a different location.
The proper handling of this scenario is for the SIP intermediary to The proper handling of this scenario, described in Section 3.4, is
include the proper location in the 424 Response. This SHOULD be for the SIP intermediary to include the proper location in the 424
included in the response as a MIME message body (i.e., a location Response. This SHOULD be included in the response as a MIME message
value), rather than as a URI; however, in cases where the body (i.e., a location value), rather than as a URI; however, in
intermediary is willing to share location with recipients but not cases where the intermediary is willing to share location with
with a user agent, a reference might be necessary. recipients but not with a user agent, a reference might be
necessary.
As mentioned in section 3 (below Figure 4), it might be the case As mentioned in Section 3.4, it might be the case that the
that the intermediary does not want to chance providing less intermediary does not want to chance providing less accurate
accurate location information than the user agent; thus it will location information than the user agent; thus it will compose its
compose its understanding of where the user agent is in a separate understanding of where the user agent is in a separate <geopriv>
<geopriv> element of the same PIDF-LO message body of the SIP element of the same PIDF-LO message body in the SIP response (which
response (which also contains the Target's version of where it is). also contains the Target's version of where it is). Therefore, both
Therefore, both locations are included - each potentially with locations are included - each with different <method> elements. The
different <method> elements. The proper reaction of the user agent proper reaction of the user agent is to generate a new SIP request
is to generate a new SIP request that includes this composed that includes this composed location object, and send it towards the
location object, and send it towards the original LR. SIP original LR. SIP intermediaries can verify that subsequent requests
intermediaries can verify that subsequent requests properly insert properly insert the suggested location information before forwarding
the suggested location information before forwarding said requests. said requests.
SIP intermediaries MUST NOT add, modify or delete the location in a
424 response. This specifically applies to intermediaries that are
between the 424 response generator and the original UAC. All
respects of the Geolocation and Geolocation-Error headers and
PIDF-LO(s) MUST remain unchanged, never added to or deleted.
Section 4.3 describes a Geolocation-Error header field to provide Section 4.3 describes a Geolocation-Error header field to provide
more detail about what was wrong with the location information in more detail about what was wrong with the location information in
the request. This header field MUST be included in the 424 response. the request. This header field MUST be included in the 424 response.
The 424 is only appropriate when the Location Recipient needs a It is only appropriate to generate a 424 response when the
locationValue and there are no locationValues included in a SIP responding entity needs a locationValue and there are no
request that are usable by a recipient, or as shown in Figure 4 of locationValues included in the SIP request that are usable by that
section 3, a SIP intermediary is informing the UA which location to recipient, or as shown in Figure 4 of section 3.4. In this scenario,
include in the next SIP request. A 424 MUST NOT be sent in response a SIP intermediary is informing the upstream UA which location to
to a request that lacks a Geolocation header entirely, as the user include in the next SIP request.
agent in that case may not support this extension at all.
A 424 MUST NOT be sent in response to a request that lacks a
Geolocation header entirely, as the user agent in that case may not
support this extension at all. If a SIP intermediary inserted a
locationValue into a SIP request where one was not previously
present, it MUST take any and all responsibility for the corrective
action if it receives a 424 to a SIP request it sent.
A 424 (Bad Location Information) response is a final response within A 424 (Bad Location Information) response is a final response within
a transaction, and does not terminate an existing dialog. a transaction, and MUST NOT terminate an existing dialog.
4.3 The Geolocation-Error Header 4.3 The Geolocation-Error Header
As discussed in Section 4.2, more granular error notifications As discussed in Section 4.2, more granular error notifications
specific to location errors within a received request are required specific to location errors within a received request are required
if the UA is to know what was wrong within the original request. if the UA is to know what was wrong within the original request.
The Geolocation-Error header field is used for this purpose. The Geolocation-Error header field is used for this purpose.
The Geolocation-Error header field is used to convey The Geolocation-Error header field is used to convey
location-specific errors within a response. The Geolocation-Error location-specific errors within a response. The Geolocation-Error
skipping to change at page 12, line 5 skipping to change at page 13, line 25
o 2XX errors mean the LR wants the LS to send new or updated o 2XX errors mean the LR wants the LS to send new or updated
location information, perhaps with a delay associated with when location information, perhaps with a delay associated with when
to send the request. to send the request.
o 3XX errors mean some specific permission is necessary to process o 3XX errors mean some specific permission is necessary to process
the included location information. the included location information.
o 4XX errors mean there was trouble dereferencing the Location URI o 4XX errors mean there was trouble dereferencing the Location URI
sent. sent.
All 4 of these error groups have a top level error code with the Within these 4 number ranges, there is a top level error as follows:
meaning as stated above (i.e., a Location Error: 100 is "Cannot
Process Location", etc). There are two exceptions necessary to
include in this document, both have to do with permissions necessary
to process the SIP request; they are
Location Error: 301 "Permission To Retransmit Location Geolocation-Error: 100 "Cannot Process Location"
Geolocation-Error: 200 "Retry Location Later with device updated
location"
Geolocation-Error: 300 "Permission To Use Location Information"
Geolocation-Error: 400 "Dereference Failure"
There are two specific Geolocation-Error codes necessary to include
in this document, both have to do with permissions necessary to
process the SIP request; they are
Geolocation-Error: 301 "Permission To Retransmit Location
Information to a Third Party" Information to a Third Party"
This location error is specific to having the Presence Information This location error is specific to having the Presence Information
Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set
to "=no". This location error is stating it requires permission to "=no". This location error is stating it requires permission
(i.e., PIDF-LO <retransmission-allowed> element set to "=yes") to (i.e., PIDF-LO <retransmission-allowed> element set to "=yes") to
process this SIP request further. If the LS sending the location process this SIP request further. If the LS sending the location
information does not want to give this permission, it will not reset information does not want to give this permission, it will not reset
this permission in a new request. If the LS wants this message this permission in a new request. If the LS wants this message
processed without this permission reset, it MUST choose another processed without this permission reset, it MUST choose another
logical path (if one exists). logical path (if one exists).
Location Error: 302 "Permission to Route based on Location Geolocation-Error: 302 "Permission to Route based on Location
Information" Information"
This location error is specific to having the locationValue header This location error is specific to having the locationValue header
parameter <routing-allowed> set to "=no". This location error is parameter <routing-allowed> set to "=no". This location error is
stating it requires permission (i.e., a <routing-allowed> set to stating it requires permission (i.e., a <routing-allowed> set to
"=yes") to process this SIP request further. If the LS sending the "=yes") to process this SIP request further. If the LS sending the
location information does not want to give this permission, it will location information does not want to give this permission, it will
not reset this permission in a new request. If the LS wants this not reset this permission in a new request. If the LS wants this
message processed without this permission reset, it MUST choose message processed without this permission reset, it MUST choose
another logical path (if one exists). another logical path (if one exists).
skipping to change at page 12, line 51 skipping to change at page 14, line 29
4.5 Location URIs in Message Bodies 4.5 Location URIs in Message Bodies
In the case where a location recipient sends a 424 response and In the case where a location recipient sends a 424 response and
wishes to communicate suitable location by reference rather than by wishes to communicate suitable location by reference rather than by
value, the 424 MUST include a content-indirection body per RFC 4483. value, the 424 MUST include a content-indirection body per RFC 4483.
4.6 Location URIs Allowed 4.6 Location URIs Allowed
The following is part of the discussion started in Section 3, Figure The following is part of the discussion started in Section 3, Figure
2, which initiated the concept of sending location indirectly. 2, which introduced the concept of sending location indirectly.
If a location URI is included in a SIP request, it MUST be a SIP-, If a location URI is included in a SIP request, it SHOULD be a SIP-,
SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if
the resulting resolution resolves to a SIP: or SIPS: URI, this the resulting resolution resolves to a SIP: or SIPS: URI, this
section applies. These schemes MUST be implemented according to section applies. These schemes MUST be implemented according to
this document. this document.
absoluteURI is not mandatory-to-implement, but allowed.
See [ID-GEO-FILTERS] for more details on dereferencing location. See [ID-GEO-FILTERS] for more details on dereferencing location.
5. Geolocation Example An HTTP: [RFC2616] or HTTPS: URI [RFC2818] are also allowed, and
SHOULD be dereferenced according to [ID-HELD-DEREF].
5. Geolocation Examples
5.1 Location-by-value (in Coordinate Format) 5.1 Location-by-value (in Coordinate Format)
This example shows an INVITE message with a coordinate location. In This example shows an INVITE message with a coordinate location. In
this example, the SIP request uses a sips-URI [RFC3261], meaning this example, the SIP request uses a sips-URI [RFC3261], meaning
this message is protected using TLS on a hop-by-hop basis. this message is protected using TLS on a hop-by-hop basis.
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 13, line 46 skipping to change at page 15, line 26
Content-Type: application/sdp Content-Type: application/sdp
...SDP goes here ...SDP goes here
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com> Content-ID: <target123@atlanta.example.com>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com"> entity="pres:alice@atlanta.example.com">
<tuple id="target123"> <dm:device id="target123-1">
<dm:device id="target123-1">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:location> <gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos> <gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point> </gml:Point>
</gml:location> </gml:location>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gbp:retransmission-allowed>false
<gp:retention-expiry>2010-07-30T20:00:00Z</gp:retention- </gbp:retransmission-allowed>
expiry> <gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules> </gp:usage-rules>
<gp:method>802.11</gp:method> <gp:method>802.11</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</tuple>
</presence> </presence>
--boundary1-- --boundary1--
The Geolocation header field from the above INVITE: The Geolocation header field from the above INVITE:
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <cid:target123@atlanta.example.com>
... indicates the content-ID location [RFC2392] within the multipart ... indicates the content-ID location [RFC2392] within the multipart
message body of where location information is. An assumption can be message body of where location information is. An assumption can be
made that SDP is the other message body part. The "cid:" eases made that SDP is the other message body part. The "cid:" eases
message body parsing by disambiguating the MIME body that contains message body parsing by disambiguating the MIME body that contains
the location information associated with this request. the location information associated with this request.
skipping to change at page 15, line 24 skipping to change at page 17, line 4
Supported: geolocation Supported: geolocation
Accept: application/sdp, application/pidf+xml Accept: application/sdp, application/pidf+xml
CSeq: 31863 INVITE CSeq: 31863 INVITE
Contact: <sips:alice@atlanta.example.com> Contact: <sips:alice@atlanta.example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
...SDP goes here ...SDP goes here
--boundary1 --boundary1
<?xml version="1.0" encoding="UTF-8"?> Content-Type: application/pidf+xml
<presence xmlns="urn:ietf:params:xml:ns:pidf" Content-ID: <target123@atlanta.example.com>
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" <?xml version="1.0" encoding="UTF-8"?>
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" <presence
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gml="http://www.opengis.net/gml" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
entity="pres:alice@atlanta.example.com"> xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
<tuple id="target123"> xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
<dm:device id="target123-1"> xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
<gp:geopriv> xmlns:gml="http://www.opengis.net/gml"
entity="pres:alice@atlanta.example.com">
<dm:device id="target123-1">
<gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:location> <gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos> <gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point> </gml:Point>
</gml:location> </gml:location>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gbp:retransmission-allowed>false
<gp:retention-expiry>2010-07-30T20:00:00Z</gp:retention- </gbp:retransmission-allowed>
expiry> <gbp:retention-expiry>2010-11-14T20:00:00Z
</gp:usage-rules> </gbp:retention-expiry>
<gp:method>802.11</gp:method> </gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
<dm:person id="target123"> <dm:person id="target123">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<cl:civilAddress> <cl:civicAddress>
<cl:country>US</cl:country> <cl:country>US</cl:country>
<cl:A1>Texas</cl:A1> <cl:A1>Texas</cl:A1>
<cl:A3>Colleyville</cl:A3> <cl:A3>Colleyville</cl:A3>
<cl:HNO>3913</cl:HNO> <cl:RD>Treemont</cl:RD>
<cl:A6>Treemont</cl:A6> <cl:STS>Circle</cl:STS>
<cl:STS>Circle</cl:STS> <cl:HNO>3913</cl:HNO>
<cl:PC>76034</cl:PC> <cl:FLR>1</cl:FLR>
<cl:NAM>Haley's Place</cl:NAM> <cl:NAM>Haley's Place</cl:NAM>
<cl:FLR>1</cl:FLR> <cl:PC>76034</cl:PC>
<cl:civilAddress> </cl:civicAddress>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed> <gbp:retransmission-allowed>false
<gp:retention-expiry>2010-07-30T20:00:00Z</gp:retention- </gbp:retransmission-allowed>
expiry> <gbp:retention-expiry>2010-11-14T20:00:00Z
<gp:method>triangulation</gp:method> </gbp:retention-expiry>
</gp:usage-rules> </gp:usage-rules>
</geopriv> <gp:method>triangulation</gp:method>
<dm:timestamp>2010-07-28T12:28:04Z</dm:timestamp> </gp:geopriv>
</dm:person> <dm:timestamp>2010-11-04T12:28:04Z</dm:timestamp>
</tuple> </dm:person>
</presence> </presence>
--boundary1-- --boundary1--
6. Geopriv Privacy Considerations 6. Geopriv Privacy Considerations
Location information is considered by most to be highly Location information is considered by most to be highly sensitive
sensitive information, requiring protection from eavesdropping, information, requiring protection from eavesdropping and altering in
and altering in transit. [RFC3693] articulates rules to transit. [RFC3693] originally articulated rules to be followed by
be followed by any protocol wishing to be considered a "Using any protocol wishing to be considered a "Using Protocol", specifying
Protocol", specifying how a transport protocol meets those rules. how a transport protocol meets those rules. [ID-GEOPRIV-ARCH]
This section describes how SIP as a Using Protocol meets those updates the guidance in RFC3693 to include subsequently-introduced
requirements. entities and concepts in the geolocation architecture.
Implementations of this SIP location conveyance mechanism MUST
Quoting requirement #4 of [RFC3693]: adhere to the guidance given in RFC3693 and its successors,
including (but not limited to) the handling of rules for retention
"The Using Protocol has to obey the privacy and security and retransmission.
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 be large. Normal
RFC 3261 procedures of reverting to TCP when the MTU size is
exceeded would be invoked.
7. Security Considerations 7. Security Considerations
Conveyance of physical location of a UA raises privacy concerns, Conveyance of physical location of a UA raises privacy concerns,
and depending on use, there probably will be authentication and and depending on use, there probably will be authentication and
integrity concerns. This document calls for conveyance to integrity concerns. This document calls for conveyance to
be accomplished through secure mechanisms, like S/MIME encrypting be accomplished through secure mechanisms, like S/MIME encrypting
message bodies (although this is not widely deployed), TLS message bodies (although this is not widely deployed), TLS
protecting the overall signaling or conveyance location by-reference protecting the overall signaling or conveyance location by-reference
and requiring all entities that dereference location to authenticate and requiring all entities that dereference location to authenticate
skipping to change at page 19, line 38 skipping to change at page 20, line 45
The SIP Geolocation-error header field is created by this document, The SIP Geolocation-error header field is created by this document,
with its definition and rules in Section 4.3 of this document, to be with its definition and rules in Section 4.3 of this document, to be
added to the IANA sip-parameters registry, in the portion titled added to the IANA sip-parameters registry, in the portion titled
"Header Field Parameters and Parameter Values". "Header Field Parameters and Parameter Values".
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
----------------- ------------------- ---------- --------- ----------------- ------------------- ---------- ---------
Geolocation-Error code= yes* [this doc] Geolocation-Error code= yes* [this doc]
* see section 9.5 for the newly created values. * see section 8.5 for the newly created values.
8.5 IANA Registration for the SIP Geolocation-Error Codes 8.5 IANA Registration for the SIP Geolocation-Error Codes
New location specific Geolocation-Error codes are created by this New location specific Geolocation-Error codes are created by this
document, and registered in a new table in the IANA sip-parameters document, and registered in a new table in the IANA sip-parameters
registry. Details of these error codes are in Section 4.3 of this registry. Details of these error codes are in Section 4.3 of this
document. document.
Geolocation-Error codes Geolocation-Error codes
----------------------- -----------------------
skipping to change at page 20, line 18 skipping to change at page 21, line 26
200 "Retry Location Later with device updated location" [this doc] 200 "Retry Location Later with device updated location" [this doc]
300 "Permission To Use Location Information" [this doc] 300 "Permission To Use Location Information" [this doc]
301 "Permission To Retransmit Location Information to a Third Party" 301 "Permission To Retransmit Location Information to a Third Party"
[this doc] [this doc]
302 "Permission to Route based on Location Information" [this doc] 302 "Permission to Route based on Location Information" [this doc]
400 "Location Information Denial" [this doc] 400 "Dereference Failure" [this doc]
8.6 IANA Registration of Location URI Schemes 8.6 IANA Registration of Location URI Schemes
This document directs IANA to create a new set of parameters in a This document directs IANA to create a new set of parameters in a
separate location from SIP and Geopriv, called the "Location separate location from SIP and Geopriv, called the "Location
Reference URI" registry, containing the URI scheme, the Reference URI" registry, containing the URI scheme, the
Content-Type, and the reference, as follows: Content-Type, and the reference, as follows:
URI Scheme Content-Type Reference URI Scheme Content-Type Reference
---------- ------------ --------- ---------- ------------ ---------
SIP: [this doc] SIP: [this doc]
SIPS: [this doc] SIPS: [this doc]
PRES: [this doc] PRES: [this doc]
HTTP: [this doc]
HTTPS: [this doc]
Additions to this registry must be defined in a permanent and Additions to this registry must be defined in a permanent and
readily available specification (this is the "Specification readily available specification (this is the "Specification
Required" IANA policy defined in [RFC5226]). Required" IANA policy defined in [RFC5226]).
9. Acknowledgements 9. Acknowledgements
To Dave Oran for helping to shape this idea. To Dave Oran for helping to shape this idea.
To Dean Willis for guidance of the effort. To Dean Willis for guidance of the effort.
skipping to change at page 22, line 21 skipping to change at page 23, line 30
[RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with [RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with
Session Description Protocol", RFC 3264, June 2002 Session Description Protocol", RFC 3264, June 2002
[RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC
4483, May 2006 4483, May 2006
[RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO [RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO
Usage Clarification, Considerations, and Recommendations ", Usage Clarification, Considerations, and Recommendations ",
RFC 5491, March 2009 RFC 5491, March 2009
[RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier
for Geographic Locations ('geo' URI)", RFC 5870, June 2010
[RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of
'retransmission-allowed' for SIP Location Conveyance",
RFC5606, Oct 2008
[RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L.,
Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer
Protocol - HTTP/1.1", RFC 2616, June 1999
10.2 Informative References 10.2 Informative References
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004 "Geopriv Requirements", RFC 3693, February 2004
[RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000
[ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location
Notifications in SIP", draft-ietf-geopriv-loc-filters, "work Notifications in SIP", draft-ietf-geopriv-loc-filters, "work
in progress", March 2010 in progress", March 2010
Authors' Addresses [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.
Thomson, M. Dawson, "A Location Dereferencing Protocol Using
HELD", "work in progress", September 2010
[ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H.
Tschofenig, H. Schulzrinne, "An Architecture for Location
and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch, "work in progress", October 2010
Author Addresses
James Polk James Polk
Cisco Systems Cisco Systems
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
33.00111N 33.00111N
96.68142W 96.68142W
Phone: +1-817-271-3552 Phone: +1-817-271-3552
 End of changes. 56 change blocks. 
206 lines changed or deleted 288 lines changed or added

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