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/ |