draft-ietf-sipcore-location-conveyance-06.txt | draft-ietf-sipcore-location-conveyance-07.txt | |||
---|---|---|---|---|
Network Working Group James Polk | Network Working Group James Polk | |||
Internet Draft Cisco Systems | Internet Draft Cisco Systems | |||
Expires: August 23, 2011 Brian Rosen | Expires: Nov 4, 2011 Brian Rosen | |||
Intended Status: Standards Track (PS) Jon Peterson | Intended Status: Standards Track (PS) Jon Peterson | |||
NeuStar | NeuStar | |||
Feb 23, 2011 | May 4, 2011 | |||
Location Conveyance for the Session Initiation Protocol | Location Conveyance for the Session Initiation Protocol | |||
draft-ietf-sipcore-location-conveyance-06.txt | draft-ietf-sipcore-location-conveyance-07.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 SIP extension covers | SIP entity to another SIP entity. The SIP extension covers | |||
end-to-end conveyance as well as location-based routing, where SIP | end-to-end 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 | |||
Location Target. | Location Target. | |||
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 August 23, 2011. | This Internet-Draft will expire on Nov 4, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 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 33 | skipping to change at page 2, line 33 | |||
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 . . . . . . . . . . . . . 4 | 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4 | |||
3.1 Location Conveyed by Value . . . . . . . . . . . . . . . 4 | 3.1 Location Conveyed by Value . . . . . . . . . . . . . . . 4 | |||
3.2 Location Conveyed as a Location URI . . . . . . . . . . . 4 | 3.2 Location Conveyed as a Location URI . . . . . . . . . . . 4 | |||
3.3 Location Conveyed though a SIP Intermediary . . . . . . . 5 | 3.3 Location Conveyed though a SIP Intermediary . . . . . . . 5 | |||
3.4 SIP Intermediary Replacing Bad Location . . . . . . . . . 7 | 3.4 SIP Intermediary Replacing Bad Location . . . . . . . . . 7 | |||
4. SIP Modifications for Geolocation Conveyance . . . . . . . . 8 | 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 8 | |||
4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 8 | 4.1 The Geolocation Header Field . . . . . . . . . . . . . . 8 | |||
4.2 The Geolocation-Routing Header . . . . . . . . . . . . . 10 | 4.2 The Geolocation-Routing Header Field . . . . . . . . . . 10 | |||
4.2.1 Explaining Geolocation-Routing header-value States . . 11 | 4.2.1 Explaining Geolocation-Routing header-value States . . 11 | |||
4.3 424 (Bad Location Information) Response Code . . . . . . 12 | 4.3 424 (Bad Location Information) Response Code . . . . . . 12 | |||
4.4 The Geolocation-Error Header . . . . . . . . . . . . . . 13 | 4.4 The Geolocation-Error Header Field . . . . . . . . . . . 13 | |||
4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 16 | 4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 16 | |||
4.6 Location Profile Negotiation . . . . . . . . . . . . . . 16 | 4.6 Location Profile Negotiation . . . . . . . . . . . . . . 16 | |||
5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 17 | 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 17 | |||
5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 17 | 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 17 | |||
5.2 Two Locations Composed in Same Location Object Example . 19 | 5.2 Two Locations Composed in Same Location Object Example . 19 | |||
6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 20 | 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 20 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 | |||
8.1 IANA Registration for New SIP Geolocation Header . . . . 22 | 8.1 IANA Registration for New SIP Geolocation Header Field . 22 | |||
8.2 IANA Registration for New SIP Geolocation-Routing Header 22 | 8.2 IANA Registration for New SIP Geolocation-Routing Header | |||
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
8.3 IANA Registration for New SIP Option Tags . . . . . . . . 23 | 8.3 IANA Registration for New SIP Option Tags . . . . . . . . 23 | |||
8.4 IANA Registration for New 424 Response Code . . . . . . . 23 | 8.4 IANA Registration for New 424 Response Code . . . . . . . 23 | |||
8.5 IANA Registration for New SIP Geolocation-Error Header . 24 | 8.5 IANA Registration for New SIP Geolocation-Error Header | |||
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | ||||
8.6 IANA Registration for New SIP Geolocation-Error Codes . . 24 | 8.6 IANA Registration for New SIP Geolocation-Error Codes . . 24 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
10.1 Normative References . . . . . . . . . . . . . . . . . 25 | 10.1 Normative References . . . . . . . . . . . . . . . . . 25 | |||
10.2 Informative References . . . . . . . . . . . . . . . . . 26 | 10.2 Informative References . . . . . . . . . . . . . . . . . 26 | |||
Author Information . . . . . . . . . . . . . . . . . . . . . 27 | Author Information . . . . . . . . . . . . . . . . . . . . . 27 | |||
Appendix A. Requirements for SIP Location Conveyance . . . . 27 | Appendix A. Requirements for SIP Location Conveyance . . . . 27 | |||
1. Conventions and Terminology used in this document | 1. Conventions and Terminology used in this document | |||
skipping to change at page 3, line 23 | skipping to change at page 3, line 25 | |||
in [RFC2119]. This document furthermore uses numerous terms defined | in [RFC2119]. This document furthermore uses numerous terms defined | |||
in RFC 3693 [RFC3693], including Location Object, Location | in RFC 3693 [RFC3693], including Location Object, Location | |||
Recipient, Location Server, Target, and Using Protocol. | Recipient, Location Server, Target, and Using Protocol. | |||
2. Introduction | 2. Introduction | |||
Session Initiation Protocol (SIP) [RFC3261] creates, modifies and | Session Initiation Protocol (SIP) [RFC3261] creates, modifies and | |||
terminates multimedia sessions. SIP carries certain information | terminates multimedia sessions. SIP carries certain information | |||
related to a session while establishing or maintaining calls. This | related to a session while establishing or maintaining calls. This | |||
document defines how SIP conveys geographic location information of | document defines how SIP conveys geographic location information of | |||
a Target (Target) to a Location Recipient (LR). SIP acts as a Using | a Target to a Location Recipient (LR). SIP acts as a Using Protocol | |||
Protocol of location information, as defined in RFC 3693. | of location information, as defined in RFC 3693. | |||
In order to convey location information, this document specifies a | In order to convey location information, this document specifies | |||
new SIP header, the Geolocation header, which carries a reference to | three new SIP header fields, Geolocation, Geolocation-Routing and | |||
a Location Object. That Location Object may appear in a MIME body | Geolocation-Error, which carry a reference to a Location Object | |||
attached to the SIP request, or it may be a remote resource in the | (LO), grant permission to route a SIP request based on the | |||
network. | location-value and provide error notifications specific to location | |||
errors respectively. The Location Object (LO) may appear in a MIME | ||||
body attached to the SIP request, or it may be a remote resource in | ||||
the network. | ||||
Note that per RFC 3693, a Target is an entity whose location is | A Target is an entity whose location is being conveyed, per RFC | |||
being conveyed. Thus, a Target could be a SIP user agent (UA), some | 3693. Thus, a Target could be a SIP user agent (UA), some other IP | |||
other IP device (a router or a PC) that does not have a SIP stack, a | device (a router or a PC) that does not have a SIP stack, a non-IP | |||
non-IP device (a person or a black phone) or even a | device (a person or a black phone) or even a non-communications | |||
non-communications device (a building or store front). In no way | device (a building or store front). In no way does this document | |||
does this document assume that the SIP user agent client which sends | assume that the SIP user agent client which sends a request | |||
a request containing a location object is necessarily the Target. | containing a location object is necessarily the Target. The location | |||
The location of a Target conveyed within SIP typically corresponds | of a Target conveyed within SIP typically corresponds to that of a | |||
to that of a device controlled by the Target, for example, a mobile | device controlled by the Target, for example, a mobile phone, but | |||
phone, but such devices can be separated from their owners, and | such devices can be separated from their owners, and moreover, in | |||
moreover, in some cases the user agent may not know its own | some cases the user agent may not know its own location. | |||
location. | ||||
In the SIP context, a location recipient will most likely be a SIP | In the SIP context, a location recipient will most likely be a SIP | |||
UA, but due to the mediated nature of SIP architectures, location | UA, but due to the mediated nature of SIP architectures, location | |||
information conveyed by a single SIP request may have multiple | information conveyed by a single SIP request may have multiple | |||
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 | location conveyance mechanism can also be used to deliver URIs | |||
skipping to change at page 6, line 44 | skipping to change at page 6, line 48 | |||
same as the one described in Section 3.1. | same as the one described in Section 3.1. | |||
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 your favorite local pizza delivery service, making sure | |||
proper location in the initial SIP request. | that organization has Alice's proper location in the initial SIP | |||
request. | ||||
There is another scenario in which the SIP intermediary cares about | There is another scenario in which the SIP intermediary cares about | |||
location and is not an LR, one in which the intermediary inserts | location and is not an LR, one in which the intermediary inserts | |||
another location of the Target, Alice in this case, into the | another location of the Target, Alice in this case, into the | |||
request, and forwards it. This secondary insertion is generally not | request, and forwards it. This secondary insertion is generally not | |||
advisable because downstream SIP entities will not be given any | advisable because downstream SIP entities will not be given any | |||
guidance about which location to believe is better, more reliable, | guidance about which location to believe is better, more reliable, | |||
less prone to error, more granular, worse than the other location or | less prone to error, more granular, worse than the other location or | |||
just plain wrong. | just plain wrong. | |||
The only conceivable way forward, when a second location is placed | This document takes a "you break it, you bought it" approach to | |||
into the same SIP request by a SIP intermediary is to | dealing with second locations placed into a SIP request by an | |||
take a "you break it, you bought it" philosophy with respect to the | intermediary entity. That entity becomes completely responsible for | |||
inserting SIP intermediary. That entity becomes completely | all location within that SIP request (more on this in Section 4). | |||
responsible for all location within that SIP request (more on this | ||||
in Section 4). | ||||
3.4 SIP Intermediary Replacing Bad Location | 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, the SIP response will indicate there was 'Bad | |||
in this document, and there are many), the SIP response will | Location Information' in the SIP request, and provide a location | |||
indicate there was 'Bad Location Information' in the SIP request, | specific error code indicating what Alice needs to do to send an | |||
and provide a location specific error code indicating what Alice | acceptable request (see Figure 4 for this scenario). | |||
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 8, line 23 | skipping to change at page 8, line 24 | |||
Answering Point (PSAP) call centers to expedite call reception by | Answering Point (PSAP) call centers to expedite call reception by | |||
the emergency services personnel; thereby, minimizing any delay in | the emergency services personnel; thereby, minimizing any delay in | |||
call establishment time. The implementation of these specialized | call establishment time. The implementation of these specialized | |||
deployments is, however, outside the scope of this document. | deployments is, however, outside the scope of this document. | |||
4. SIP Modifications for Geolocation Conveyance | 4. SIP Modifications for Geolocation Conveyance | |||
The following sections detail the modifications to SIP for location | The following sections detail the modifications to SIP for location | |||
conveyance. | conveyance. | |||
4.1 The Geolocation Header | 4.1 The Geolocation Header Field | |||
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]: | |||
message-header /= Geolocation-header ; (message-header from 3261) | message-header /= Geolocation-header ; (message-header from 3261) | |||
Geolocation-header = "Geolocation" HCOLON locationValue | Geolocation-header = "Geolocation" HCOLON locationValue | |||
*( COMMA locationValue ) | *( COMMA locationValue ) | |||
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 | / 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) | |||
HCOLON, COMMA, LAQUOT, RAQUOT, and SEMI are defined in RFC3261 | ||||
[RFC3261]. | ||||
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 | http-URI and https-URI are defined according to [RFC2616] and | |||
[RFC2818], respectively. | [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 in the SIP | GEO-URIs [RFC5870] are not appropriate for usage in the SIP | |||
Geolocation header. | 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 generic-param in the definition of locationValue is included as | The generic-param in the definition of locationValue is included as | |||
a mechanism for future extensions that might require parameters. | a mechanism for future extensions that might require parameters. | |||
This document defines no parameters for use with locationValue. If a | This document defines no parameters for use with locationValue. If a | |||
Geolocation header field is received that contains generic-params, | Geolocation header field is received that contains generic-params, | |||
each SHOULD be ignored, and SHOULD NOT be removed when forwarding | each parameter SHOULD be ignored, and SHOULD NOT be removed when | |||
the locationValue. If a need arises to define parameters for use | forwarding the locationValue. If a need arises to define parameters | |||
with locationValue, a revision/extension to this document is | for use with locationValue, a revision/extension to this document is | |||
required. | required. | |||
The Geolocation header field can have one or more locationValues. A | The Geolocation header field can have one or more locationValues. A | |||
Geolocation header field MUST have at least one header-value. A | Geolocation header field MUST have at least one locationValue. A | |||
SIP intermediary SHOULD NOT add location to a SIP request that | SIP intermediary SHOULD NOT add location to a SIP request that | |||
already contains location. This will quite often lead to confusion | already contains location. This will quite often lead to confusion | |||
within LRs. However, if a SIP intermediary adds location, even if | within LRs. However, if a SIP intermediary adds location, even if | |||
location was not previously present in a SIP request, that SIP | location was not previously present in a SIP request, that SIP | |||
intermediary is fully responsible for addressing the concerns of any | intermediary is fully responsible for addressing the concerns of any | |||
424 (Bad Location Information) SIP response it receives about this | 424 (Bad Location Information) SIP response it receives about this | |||
location addition, and MUST NOT pass on (upstream) the 424 response. | location addition, and MUST NOT pass on (upstream) the 424 response. | |||
Additionally, the first SIP intermediary to add a locationValue adds | A SIP intermediary that adds a locationValue MUST position the new | |||
it as the last locationValue in the header value. A SIP intermediary | locationValue as the last locationValue within the Geolocation | |||
that adds a locationValue MUST position it as the last locationValue | header field of the SIP request. | |||
of the last Geolocation header field of the message. | ||||
This document defines the Geolocation header field as valid in the | This document defines the Geolocation header field as valid in the | |||
following SIP requests: | following SIP requests: | |||
INVITE [RFC3261], REGISTER [RFC3261], | INVITE [RFC3261], REGISTER [RFC3261], | |||
OPTIONS [RFC3261], BYE [RFC3261], | OPTIONS [RFC3261], BYE [RFC3261], | |||
UPDATE [RFC3311], INFO [RFC2976], | UPDATE [RFC3311], INFO [RFC6086], | |||
MESSAGE [RFC3428], REFER [RFC3515], | MESSAGE [RFC3428], REFER [RFC3515], | |||
SUBSCRIBE [RFC3265], NOTIFY [RFC3265], | SUBSCRIBE [RFC3265], NOTIFY [RFC3265], | |||
PUBLISH [RFC3903], PRACK [RFC3262] | PUBLISH [RFC3903] | |||
The Geolocation header field MAY be included in any one of the | The Geolocation header field MAY be included in any one of the | |||
above listed requests by a UA, and a 424 response to any one of the | above listed requests by a UA, and a 424 response to any one of the | |||
requests sent above. Fully appreciating the caveats/warnings | requests sent above. Fully appreciating the caveats/warnings | |||
mentioned above, a SIP intermediary MAY add the Geolocation header | mentioned above, a SIP intermediary MAY add the Geolocation header | |||
field. | field. | |||
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 the | Geolocation mechanism but their outbound proxy does and knows the | |||
skipping to change at page 10, line 7 | skipping to change at page 10, line 10 | |||
The Geolocation header field MAY be present in a SIP request or | The Geolocation header field MAY be present in a SIP request or | |||
response without the presence of a Geolocation-Routing header | response without the presence of a Geolocation-Routing header | |||
(defined in Section 4.2). As stated in Section 4.2, the default | (defined in Section 4.2). As stated in Section 4.2, the default | |||
value of Geolocation-Routing header-value is "no", meaning SIP | value of Geolocation-Routing header-value is "no", meaning SIP | |||
intermediaries are not to view any direct or indirect location | intermediaries are not to view any direct or indirect location | |||
within this SIP message. | within this SIP message. | |||
Any locationValue MUST be related to the original Target. This is | Any locationValue MUST be related to the original Target. This is | |||
equally true the location information in a SIP response, i.e., from | equally true the location information in a SIP response, i.e., from | |||
a SIP intermediary back to the Target explained in Section 3.4. | a SIP intermediary back to the Target as explained in Section 3.4. | |||
SIP intermediaries are NOT RECOMMENDED to modify existing | SIP intermediaries SHOULD NOT modify or delete any existing | |||
locationValue(s), and further not to delete any either. | locationValue(s). | |||
4.2 The Geolocation-Routing Header | 4.2 The Geolocation-Routing Header Field | |||
This document defines "Geolocation-Routing" as a new SIP header | This document defines "Geolocation-Routing" as a new SIP header | |||
field registered by IANA, with the following ABNF [RFC5234]: | field registered by IANA, with the following ABNF [RFC5234]: | |||
message-header /= Georouting-header ; (message-header from 3261) | message-header /= Georouting-header ; (message-header from 3261) | |||
Georouting-header = "Geolocation-Routing" HCOLON | Georouting-header = "Geolocation-Routing" HCOLON | |||
( "yes" / "no" / generic-value ) | ( "yes" / "no" / generic-value ) | |||
generic-value = generic-param; (from RFC 3261) | ||||
HCOLON is defined in RFC3261 [RFC3261]. | ||||
The only defined values for the Geolocation-Routing header field are | The only defined values for the Geolocation-Routing header field are | |||
"yes" or "no". When the value is "yes", the locationValue can be | "yes" or "no". When the value is "yes", the locationValue can be | |||
used for routing decisions along the downstream signaling path by | used for routing decisions along the downstream signaling path by | |||
intermediaries. Values other than "yes" or "no" are permitted as a | intermediaries. Values other than "yes" or "no" are permitted for | |||
mechanism for future extensions, and should be treated the same as | future extensions. Implementations not aware of an extension MUST | |||
"no". | treat any other received value the same as "no". | |||
If no Geolocation-Routing header field is present in a SIP request, | If no Geolocation-Routing header field is present in a SIP request, | |||
a SIP intermediary MAY insert this header field with a RECOMMENDED | a SIP intermediary MAY insert this header. Without knowledge from a | |||
value of "no" by default. | Rulemaker, the SIP intermediary inserting this header-value SHOULD | |||
NOT set the value to "yes", as this could allow the Target's | ||||
location to be forwarded to third parties without the Target's | ||||
explicit permission. An easy way around this is to have the Target | ||||
always insert this header-value as "no". | ||||
When this Geolocation-Routing header-value is set to "no", this | When this Geolocation-Routing header-value is set to "no", this | |||
means no locationValue (inserted by the originating UAC or any | means no locationValue (inserted by the originating UAC or any | |||
intermediary along the signaling path) can be used by any SIP | intermediary along the signaling path) can be used by any SIP | |||
intermediary to make routing decisions. Intermediaries that attempt | intermediary to make routing decisions. Intermediaries that attempt | |||
to use the location information for routing purposes in spite of | to use the location information for routing purposes in spite of | |||
this counter indication could end up routing the request improperly | this counter indication could end up routing the request improperly | |||
as a result. Section 4.4 describes the details on what a routing | as a result. Section 4.4 describes the details on what a routing | |||
intermediary does if it determines it needs to use the location in | intermediary does if it determines it needs to use the location in | |||
the SIP request in order to process the message further. The | the SIP request in order to process the message further. The | |||
practical implication is that when the Geolocation-Routing | practical implication is that when the Geolocation-Routing | |||
header-value is set to "no", if a cid:url is present in the SIP | header-value is set to "no", if a cid:url is present in the SIP | |||
request, intermediaries SHOULD NOT view the location (because it is | request, intermediaries SHOULD NOT view the location (because it is | |||
not for intermediaries to view), and if a location URI is present, | not for intermediaries to view), and if a location URI is present, | |||
intermediaries SHOULD NOT dereference it. UAs are allowed to view | intermediaries SHOULD NOT dereference it. UAs are allowed to view | |||
location in the SIP request even when the Geolocation-Routing | location in the SIP request even when the Geolocation-Routing | |||
header-value is set to "no". An LR MUST by default consider the | header-value is set to "no". An LR MUST by default consider the | |||
Geolocation-Routing header-value as set to "no", with no exceptions, | Geolocation-Routing header-value as set to "no", with no exceptions, | |||
unless the header field value is set to "yes". | unless the header field value is set to "yes". | |||
A Geolocation-Routing header-value is set to "no" has no special | A Geolocation-Routing header-value that is set to "no" has no | |||
security properties, this is at most a request for behavior within | special security properties. It is at most a request for behavior | |||
SIP intermediaries. That said, if the Geolocation-Routing | within SIP intermediaries. That said, if the Geolocation-Routing | |||
header-value is set to "no", SIP intermediaries are still to | header-value is set to "no", SIP intermediaries are still to process | |||
process the SIP request and send it further downstream within the | the SIP request and send it further downstream within the signaling | |||
signaling path if there are no errors present in this SIP request. | path if there are no errors present in this SIP request. | |||
The Geolocation-Routing header field satisfies the recommendations | The Geolocation-Routing header field satisfies the recommendations | |||
made in section 3.5 of RFC 5606 [RFC5606] regarding indication of | made in section 3.5 of RFC 5606 [RFC5606] regarding indication of | |||
permission to use location-based routing in SIP. | permission to use location-based routing in SIP. | |||
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. | |||
The Geolocation-Routing header field cannot appear without a | The Geolocation-Routing header field cannot appear without a | |||
skipping to change at page 11, line 29 | skipping to change at page 11, line 40 | |||
Geolocation-Routing: no | Geolocation-Routing: no | |||
The Geolocation-Routing header field MAY be present without a | The Geolocation-Routing header field MAY be present without a | |||
Geolocation header field in the same SIP request. This concept is | Geolocation header field in the same SIP request. This concept is | |||
further explored in Section 4.2.1. | further explored in Section 4.2.1. | |||
4.2.1 Explaining Geolocation-Routing header-value States | 4.2.1 Explaining Geolocation-Routing header-value States | |||
The Geolocation header field contains a Target's location, and MUST | The Geolocation header field contains a Target's location, and MUST | |||
NOT be present if there is no location information in this SIP | NOT be present if there is no location information in this SIP | |||
request. The location information is contained in a one or more | request. The location information is contained in one or more | |||
locationValues. These locationValues MAY be contained in a single | locationValues. These locationValues MAY be contained in a single | |||
Geolocation header field, or distributed among multiple Geolocation | Geolocation header field, or distributed among multiple Geolocation | |||
header fields. (See section 7.3.1 of RFC3261.) | header fields. (See section 7.3.1 of RFC3261.) | |||
The Geolocation-Routing header field indicates whether or not SIP | The Geolocation-Routing header field indicates whether or not SIP | |||
intermediaries can view and then route this SIP request based on the | intermediaries can view and then route this SIP request based on the | |||
included (directly or indirectly) location information. The | included (directly or indirectly) location information. The | |||
Geolocation-Routing header field MUST NOT appear more than once in | Geolocation-Routing header field MUST NOT appear more than once in | |||
any SIP request, and MUST NOT lack a header-value. The default or | any SIP request, and MUST NOT lack a header-value. The default or | |||
implied policy of a SIP request that does not have a | implied policy of a SIP request that does not have a | |||
skipping to change at page 12, line 24 | skipping to change at page 12, line 35 | |||
"yes" Location viewing policy set already | "yes" Location viewing policy set already | |||
such that if location is inserted | such that if location is inserted | |||
downstream, intermediaries can | downstream, intermediaries can | |||
maintain an open viewing of location | maintain an open viewing of location | |||
policy or can change policy to "no" | policy or can change policy to "no" | |||
for intermediaries further downstream. | for intermediaries further downstream. | |||
Geolocation-Routing absent If a Geolocation header field exists | Geolocation-Routing absent If a Geolocation header field exists | |||
(meaning a locationValue is already | (meaning a locationValue is already | |||
present), MUST interpret the lack of a | present), a SIP intermediary MUST | |||
Geolocation-Routing header field by | interpret the lack of a | |||
default as if there were one present | Geolocation-Routing header field as if | |||
and the header-value is set to "no". | there were one present and the | |||
header-value is set to "no". | ||||
If there is no Geolocation header | If there is no Geolocation header | |||
field in this SIP request, the default | field in this SIP request, the default | |||
Geolocation-Routing is open and can be | Geolocation-Routing is open and can be | |||
set by a downstream entity or not at | set by a downstream entity or not at | |||
all. | all. | |||
4.3 424 (Bad Location Information) Response Code | 4.3 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, | |||
skipping to change at page 13, line 21 | skipping to change at page 13, line 33 | |||
understanding of where the user agent is in a separate <geopriv> | understanding of where the user agent is in a separate <geopriv> | |||
element of the same PIDF-LO message body in the SIP response (which | element of the same PIDF-LO message body in the SIP response (which | |||
also contains the Target's version of where it is). Therefore, both | also contains the Target's version of where it is). Therefore, both | |||
locations are included - each with different <method> elements. The | locations are included - each with different <method> elements. The | |||
proper reaction of the user agent is to generate a new SIP request | proper reaction of the user agent is to generate a new SIP request | |||
that includes this composed location object, and send it towards the | that includes this composed location object, and send it towards the | |||
original LR. SIP intermediaries can verify that subsequent requests | original LR. SIP intermediaries can verify that subsequent requests | |||
properly insert the suggested location information before forwarding | properly insert the suggested location information before forwarding | |||
said requests. | said requests. | |||
SIP intermediaries MUST NOT add, modify or delete the location in a | SIP intermediaries that are forwarding (as opposed to generating) a | |||
424 response. This specifically applies to intermediaries that are | 424 response MUST NOT add, modify, or delete any location appearing | |||
between the 424 response generator and the original UAC. Geolocation | in that response. This specifically applies to intermediaries that | |||
and Geolocation-Error header fields and PIDF-LO body parts MUST | are between the 424 response generator and the original UAC. | |||
remain unchanged, never added to or deleted. | Geolocation and Geolocation-Error header fields and PIDF-LO body | |||
parts MUST remain unchanged, never added to or deleted. | ||||
Section 4.4 describes a Geolocation-Error header field to provide | Section 4.4 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. | |||
It is only appropriate to generate a 424 response when the | It is only appropriate to generate a 424 response when the | |||
responding entity needs a locationValue and there are no | responding entity needs a locationValue and there are no values in | |||
locationValues included in the SIP request that are usable by that | the request that are usable by the responder, or when the responder | |||
recipient, or as shown in Figure 4 of section 3.4. In the latter | has additional location information to provide. The latter case is | |||
scenario, a SIP intermediary is informing the upstream UA which | shown in Figure 4 of section 3.4. There, a SIP intermediary is | |||
location to include in the next SIP request. | informing the upstream UA which location to include in the next SIP | |||
request. | ||||
A 424 MUST NOT be sent in response to a request that lacks a | 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 | Geolocation header entirely, as the user agent in that case may not | |||
support this extension at all. If a SIP intermediary inserted a | support this extension at all. If a SIP intermediary inserted a | |||
locationValue into a SIP request where one was not previously | locationValue into a SIP request where one was not previously | |||
present, it MUST take any and all responsibility for the corrective | present, it MUST take any and all responsibility for the corrective | |||
action if it receives a 424 to a SIP request it sent. | 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 MUST NOT terminate an existing dialog. | a transaction, and MUST NOT terminate an existing dialog. | |||
4.4 The Geolocation-Error Header | 4.4 The Geolocation-Error Header Field | |||
As discussed in Section 4.3, more granular error notifications | As discussed in Section 4.3, more granular error notifications | |||
specific to location errors within a received request are required | specific to location errors within a received request are required | |||
if the location inserting entity is to know what was wrong within | if the location inserting entity is to know what was wrong within | |||
the original request. The Geolocation-Error header field is used for | the original request. The Geolocation-Error header field is used for | |||
this purpose. | 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 | |||
header field has the following ABNF [RFC5234]: | header field has the following ABNF [RFC5234]: | |||
message-header /= Geolocation-Error-header ; | message-header /= Geolocation-Error ; | |||
(message-header from 3261) | (message-header from 3261) | |||
Geolocation-Error = "Geolocation-Error" HCOLON | Geolocation-Error = "Geolocation-Error" HCOLON | |||
locationErrorValue | locationErrorValue | |||
locationErrorValue = location-error-code | locationErrorValue = location-error-code | |||
*(SEMI location-error-params) | *(SEMI location-error-params) | |||
location-error-code = 1*3DIGIT | location-error-code = 1*3DIGIT | |||
location-error-params = location-error-code-text | location-error-params = location-error-code-text | |||
/ generic-param ; from RFC3261 | / generic-param ; from RFC3261 | |||
location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 | location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 | |||
HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is | ||||
defined in RFC5234 [RFC5234]. | ||||
The Geolocation-Error header field MUST contain only one | The Geolocation-Error header field MUST contain only one | |||
locationErrorValue to indicate what was wrong with the locationValue | locationErrorValue to indicate what was wrong with the locationValue | |||
the Location Recipient determined was bad. The locationErrorValue | the Location Recipient determined was bad. The locationErrorValue | |||
contains a 3-digit error code indicating what was wrong with the | contains a 3-digit error code indicating what was wrong with the | |||
location in the request. This error code has a corresponding quoted | location in the request. This error code has a corresponding quoted | |||
error text string that is human understandable. This text string is | error text string that is human understandable. The text string are | |||
OPTIONAL, but RECOMMENDED for human readability. | OPTIONAL, but RECOMMENDED for human readability, similar to the | |||
string phrase used for SIP response codes. That said, the strings | ||||
are complete enough for rendering to the user, if so desired. The | ||||
strings in this document are recommendations, and are not | ||||
standardized - meaning an operator can change the strings - but MUST | ||||
NOT change the meaning of the error code. Similar to how RFC 3261 | ||||
specifies, there MUST NOT be more than one string per error code. | ||||
The Geolocation-Error header field MAY be included in any response | The Geolocation-Error header field MAY be included in any response | |||
to one of the SIP Methods mentioned in Section 4.1, so long as a | to one of the SIP Methods mentioned in Section 4.1, so long as a | |||
locationValue was in the request part of the same transaction. For | locationValue was in the request part of the same transaction. For | |||
example, Alice includes her location in an INVITE to Bob. Bob can | example, Alice includes her location in an INVITE to Bob. Bob can | |||
accept this INVITE, thus creating a dialog, even though his UA | accept this INVITE, thus creating a dialog, even though his UA | |||
determined the location contained in the INVITE was bad. Bob merely | determined the location contained in the INVITE was bad. Bob merely | |||
includes a Geolocation-Error header value in the 200 OK to the | includes a Geolocation-Error header value in the 200 OK to the | |||
INVITE informing Alice the INVITE was accepted but the location | INVITE informing Alice the INVITE was accepted but the location | |||
provided was bad. | provided was bad. | |||
skipping to change at page 14, line 51 | skipping to change at page 15, line 24 | |||
3.3 respectively. | 3.3 respectively. | |||
A SIP intermediary that requires Alice's location in order to | A SIP intermediary that requires Alice's location in order to | |||
properly process Alice's INVITE also sends a 424 with a | properly process Alice's INVITE also sends a 424 with a | |||
Geolocation-Error code. This message flow is shown in Figure 4 of | Geolocation-Error code. This message flow is shown in Figure 4 of | |||
Section 3.4. | Section 3.4. | |||
If more than one locationValue is present in a SIP request and at | If more than one locationValue is present in a SIP request and at | |||
least one locationValue is determined to be valid by the LR, the | least one locationValue is determined to be valid by the LR, the | |||
location in that SIP request MUST be considered good as far as | location in that SIP request MUST be considered good as far as | |||
location is concerned, and no Geolocation-Error is sent. This is a | location is concerned, and no Geolocation-Error is to be sent. | |||
compromise of complexity vs. accurate information conveyance with | ||||
respect to informing each location inserter of every bad location. | ||||
Here is an initial list of location based error code ranges for any | Here is an initial list of location based error code ranges for any | |||
SIP non-100 response, including the new 424 (Bad Location | SIP response, including provisional responses (other than 100 | |||
Information) response. These error codes are divided into 3 | Trying) and the new 424 (Bad Location Information) response. These | |||
categories, based on how the response receiver should react to these | error codes are divided into 3 categories, based on how the response | |||
errors. There MUST be no more than one Geolocation-Error code in a | receiver should react to these errors. There MUST be no more than | |||
SIP response, regardless of how many locationValues there are in the | one Geolocation-Error code in a SIP response, regardless of how many | |||
correlating SIP request. There is no guidance given in this document | locationValues there are in the correlating SIP request. There is no | |||
as to which locationValue, when more than one was present in the SIP | guidance given in this document as to which locationValue, when more | |||
request, is related to the Geolocation-Error code; meaning that, | than one was present in the SIP request, is related to the | |||
somehow not defined here, the LR just picks one to error. | Geolocation-Error code; meaning that, somehow not defined here, the | |||
LR just picks one to error. | ||||
o 1XX errors mean the LR cannot process the location within the | o 1XX errors mean the LR cannot process the location within the | |||
request | request | |||
A non-exclusive list of reasons for returning a 1XX is | A non-exclusive list of reasons for returning a 1XX is | |||
- the location was not present or could not be found, | - the location was not present or could not be found, | |||
- there was not enough location information to determine | - there was not enough location information to determine | |||
where the Target was, | where the Target was, | |||
- the location information was corrupted or known to be | - the location information was corrupted or known to be | |||
inaccurate, | inaccurate, | |||
- etc... | ||||
o 2XX errors mean some specific permission is necessary to process | o 2XX errors mean some specific permission is necessary to process | |||
the included location information. | the included location information. | |||
o 3XX errors mean there was trouble dereferencing the Location URI | o 3XX errors mean there was trouble dereferencing the Location URI | |||
sent. | sent. | |||
It should be noted that for non-INVITE transactions, the SIP | It should be noted that for non-INVITE transactions, the SIP | |||
response will likely be sent before the dereference response has | response will likely be sent before the dereference response has | |||
been received. At this time, this document does not alter that SIP | been received. This document does not alter that SIP protocol | |||
protocol reality. This means the receiver of any non-INVITE response | reality. This means the receiver of any non-INVITE response to a | |||
to a request containing location SHOULD NOT consider a 200 OK to | request containing location SHOULD NOT consider a 200 OK to mean the | |||
mean the act of dereferencing has concluded and the dereferencer | act of dereferencing has concluded and the dereferencer (i.e., the | |||
(i.e., the LR) has successfully received and parsed the PIDF-LO for | LR) has successfully received and parsed the PIDF-LO for errors and | |||
errors and found none. This was first brought up in Section 3.2. | found none. The end of section 3.2 discusses how transaction timing | |||
considerations lead to this requirement. | ||||
Additionally, if a SIP entity cannot or chooses not to process | Additionally, if an LR cannot or chooses not to process location | |||
location or the SIP request containing location, the existing | from a SIP request, a 500 (Server Internal Error) SHOULD be used | |||
mechanism of responding with a 503 (Service Unavailable) SHOULD be | with or without a configurable Retry-After header field. There is no | |||
used with or without a configurable Retry-After header field. There | special location error code for what already exists within SIP | |||
is no special location error code for what already exists within SIP | ||||
today. | today. | |||
Within each of these ranges, there is a top level error as follows: | Within each of these ranges, there is a top level error as follows: | |||
Geolocation-Error: 100 "Cannot Process Location" | Geolocation-Error: 100 ; code="Cannot Process Location" | |||
Geolocation-Error: 200 "Permission To Use Location Information" | Geolocation-Error: 200 ; code="Permission To Use Location | |||
Information" | ||||
Geolocation-Error: 300 ; code="Dereference Failure" | ||||
If an error recipient cannot process an specific error code (such as | ||||
the 201 or 202 below), perhaps because it does not understand that | ||||
specific error code, the error recipient SHOULD process the error | ||||
code as if it originally were a top level error code where the X in | ||||
X00 matches the specific error code. If the error recipient cannot | ||||
process a non-100 error code, for whatever reason, then the error | ||||
code 100 MUST be processed. | ||||
Geolocation-Error: 300 "Dereference Failure" | ||||
There are two specific Geolocation-Error codes necessary to include | There are two specific Geolocation-Error codes necessary to include | |||
in this document, both have to do with permissions necessary to | in this document, both have to do with permissions necessary to | |||
process the SIP request; they are | process the SIP request; they are | |||
Geolocation-Error: 201 "Permission To Retransmit Location | Geolocation-Error: 201 ; code="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) for this SIP request. | logical path (if one exists) for this SIP request. | |||
Geolocation-Error: 202 "Permission to Route based on Location | Geolocation-Error: 202 ; code="Permission to Route based on Location | |||
Information" | Information" | |||
This location error is specific to having the Geolocation-Routing | This location error is specific to having the Geolocation-Routing | |||
header value set to "no". This location error is stating it requires | header value set to "no". This location error is stating it requires | |||
permission (i.e., the Geolocation-Routing header value set to "yes") | permission (i.e., the Geolocation-Routing header value set to "yes") | |||
to process this SIP request further. If the LS sending the location | to 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) for this SIP request. | logical path (if one exists) for this SIP request. | |||
skipping to change at page 16, line 48 | skipping to change at page 17, line 29 | |||
4.6 Location Profile Negotiation | 4.6 Location Profile Negotiation | |||
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 introduced 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, the sending user | If a location URI is included in a SIP request, the sending user | |||
agent MUST also include a Supported header field indicating which | agent MUST also include a Supported header field indicating which | |||
location profiles it supports. Two option tags for location profiles | location profiles it supports. Two option tags for location profiles | |||
are defined by this document: "geolocation-sip" and | are defined by this document: "geolocation-sip" and | |||
"geolocation-http". Future specifications may define further | "geolocation-http". Future specifications MAY define further | |||
location profiles per the IANA policy described in Section 8.3. | location profiles per the IANA policy described in Section 8.3. | |||
The "geolocation-sip" option tag signals support for acquiring | The "geolocation-sip" option tag signals support for acquiring | |||
location information via the presence event package of SIP | location information via the presence event package of SIP | |||
([RFC3856]). A location recipient who supports this option can send | ([RFC3856]). A location recipient who supports this option can send | |||
a SUBSCRIBE request and parse a resulting NOTIFY containing a | a SUBSCRIBE request and parse a resulting NOTIFY containing a | |||
PIDF-LO object. The URI schemes supported by this option include | PIDF-LO object. The URI schemes supported by this option include | |||
"sip", "sips" and "pres". | "sip", "sips" and "pres". | |||
The "geolocation-http" option tag signals support for acquiring | The "geolocation-http" option tag signals support for acquiring | |||
location information via an HTTP ([RFC2616]). A location recipient | location information via an HTTP ([RFC2616]). A location recipient | |||
who supports this option can request location with an HTTP GET and | who supports this option can request location with an HTTP GET and | |||
parse a resulting 200 response containing a PIDF-LO object. The URI | parse a resulting 200 response containing a PIDF-LO object. The URI | |||
schemes supported by this option include "http" and "https". A | schemes supported by this option include "http" and "https". A | |||
failure to parse the 200 response, for whatever reason, will return | failure to parse the 200 response, for whatever reason, will return | |||
a "Dereference Failure" indication to the original location sending | a "Dereference Failure" indication to the original location sending | |||
user agent to inform it that location was not delivered as intended. | user agent to inform it that location was not delivered as intended. | |||
If the location URI receiver does not understand the URI scheme sent | ||||
to it, it will return an Unsupported header value of the option-tag | ||||
from the SIP request, and include the option-tag of the preferred | ||||
URI scheme in the response's Supported header field. | ||||
See [ID-GEO-FILTERS] or [ID-HELD-DEREF] for more details on | See [ID-GEO-FILTERS] or [ID-HELD-DEREF] for more details on | |||
dereferencing location information. | dereferencing location information. | |||
5. Geolocation Examples | 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 | |||
To: Bob <sips:bob@biloxi.example.com> | To: Bob <sips:bob@biloxi.example.com> | |||
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl | From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl | |||
Call-ID: 3848276298220188511@atlanta.example.com | Call-ID: 3848276298220188511@atlanta.example.com | |||
Geolocation: <cid:target123@atlanta.example.com> | Geolocation: <cid:target123@atlanta.example.com> | |||
Geolocation-Routing: no | Geolocation-Routing: no | |||
Supported: geolocation | ||||
Accept: application/sdp, application/pidf+xml | Accept: application/sdp, application/pidf+xml | |||
CSeq: 31862 INVITE | CSeq: 31862 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 | |||
skipping to change at page 19, line 25 | skipping to change at page 20, line 8 | |||
location conveyance applicability. | location conveyance applicability. | |||
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=z9hG4bK74bf0 | Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 | |||
Max-Forwards: 70 | Max-Forwards: 70 | |||
To: Bob <sips:bob@biloxi.example.com> | To: Bob <sips:bob@biloxi.example.com> | |||
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl | From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl | |||
Call-ID: 3848276298220188512@atlanta.example.com | Call-ID: 3848276298220188512@atlanta.example.com | |||
Geolocation: <cid:target123@atlanta.example.com> | Geolocation: <cid:target123@atlanta.example.com> | |||
Geolocation-Routing: no | Geolocation-Routing: no | |||
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 | |||
skipping to change at page 20, line 53 | skipping to change at page 21, line 35 | |||
</dm:person> | </dm:person> | |||
</presence> | </presence> | |||
--boundary1-- | --boundary1-- | |||
6. Geopriv Privacy Considerations | 6. Geopriv Privacy Considerations | |||
Location information is considered by most to be highly sensitive | Location information is considered by most to be highly sensitive | |||
information, requiring protection from eavesdropping and altering in | information, requiring protection from eavesdropping and altering in | |||
transit. [RFC3693] originally articulated rules to be followed by | transit. [RFC3693] originally articulated rules to be followed by | |||
any protocol wishing to be considered a "Using Protocol", specifying | any protocol wishing to be considered a "Using Protocol", specifying | |||
how a transport protocol meets those rules. [ID-GEOPRIV-ARCH] | how a transport protocol meets those rules. [ID-GEO-ARCH] updates | |||
updates the guidance in RFC3693 to include subsequently-introduced | the guidance in RFC3693 to include subsequently-introduced | |||
entities and concepts in the geolocation architecture. | entities and concepts in the geolocation architecture. | |||
Implementations of this SIP location conveyance mechanism MUST | Implementations of this SIP location conveyance mechanism MUST | |||
adhere to the guidance given in RFC3693 and its updates and/or | adhere to the guidance given in RFC3693 and its updates and/or | |||
successors, including (but not limited to) the handling of rules for | successors, including (but not limited to) the handling of rules for | |||
retention and retransmission. | retention and retransmission. | |||
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, | |||
skipping to change at page 22, line 41 | skipping to change at page 23, line 26 | |||
require a standards track RFC (Standards Action). | require a standards track RFC (Standards Action). | |||
[Editor's Note: RFC-Editor - within the IANA section, please | [Editor's Note: RFC-Editor - within the IANA section, please | |||
replace "this doc" with the assigned RFC number, | replace "this doc" with the assigned RFC number, | |||
if this document reaches publication.] | if this document reaches publication.] | |||
8.1 IANA Registration for the SIP Geolocation Header Field | 8.1 IANA Registration for the SIP Geolocation Header Field | |||
The SIP Geolocation Header Field is created by this document, with | The SIP Geolocation Header Field is created by this document, with | |||
its definition and rules in Section 4.1 of this document, and should | its definition and rules in Section 4.1 of this document, and should | |||
be added to the IANA sip-parameters registry with two actions | be added to the IANA sip-parameters registry with the following | |||
actions | ||||
1. Update the Header Fields registry with | 1. Update the Header Fields registry with | |||
Registry: | Registry: | |||
Header Name compact Reference | Header Name compact Reference | |||
----------------- ------- --------- | ----------------- ------- --------- | |||
Geolocation [this doc] | Geolocation [this doc] | |||
8.2 IANA Registration for the SIP Geolocation Header Field | 8.2 IANA Registration for the SIP Geolocation-Routing Header Field | |||
The SIP Geolocation-Routing Header Field is created by this document, | The SIP Geolocation-Routing Header Field is created by this document, | |||
with its definition and rules in Section 4.2 of this document, and | with its definition and rules in Section 4.2 of this document, and | |||
should be added to the IANA sip-parameters registry with the | should be added to the IANA sip-parameters registry with the | |||
following action | following action | |||
1. Update the Header Fields registry with | 1. Update the Header Fields registry with | |||
Registry: | Registry: | |||
Header Name compact Reference | Header Name compact Reference | |||
skipping to change at page 24, line 24 | skipping to change at page 25, line 9 | |||
Header Name compact Reference | Header Name compact Reference | |||
----------------- ------- --------- | ----------------- ------- --------- | |||
Geolocation-Error [this doc] | Geolocation-Error [this doc] | |||
2. In the portion titled "Header Field Parameters and Parameter | 2. In the portion titled "Header Field Parameters and Parameter | |||
Values", add | Values", add | |||
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 8.6 for the newly created values. | ||||
8.6 IANA Registration for the SIP Geolocation-Error Codes | 8.6 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.4 of this | registry. Details of these error codes are in Section 4.4 of this | |||
document. | document. | |||
Geolocation-Error codes | Geolocation-Error codes | |||
----------------------- | ----------------------- | |||
Geolocation-Error codes provide reason for the error discovered by | Geolocation-Error codes provide reason for the error discovered by | |||
Location Recipients, categorized by action to be taken by error | Location Recipients, categorized by action to be taken by error | |||
recipient. | recipient. | |||
Code Description Reference | Code Default Reason Phrase Reference | |||
---- --------------------------------------------------- --------- | ---- --------------------------------------------------- --------- | |||
100 "Cannot Process Location" [this doc] | 100 "Cannot Process Location" [this doc] | |||
200 "Permission To Use Location Information" [this doc] | 200 "Permission To Use Location Information" [this doc] | |||
201 "Permission To Retransmit Location Information to a Third Party" | 201 "Permission To Retransmit Location Information to a Third Party" | |||
[this doc] | [this doc] | |||
202 "Permission to Route based on Location Information" [this doc] | 202 "Permission to Route based on Location Information" [this doc] | |||
skipping to change at page 25, line 4 | skipping to change at page 25, line 38 | |||
200 "Permission To Use Location Information" [this doc] | 200 "Permission To Use Location Information" [this doc] | |||
201 "Permission To Retransmit Location Information to a Third Party" | 201 "Permission To Retransmit Location Information to a Third Party" | |||
[this doc] | [this doc] | |||
202 "Permission to Route based on Location Information" [this doc] | 202 "Permission to Route based on Location Information" [this doc] | |||
300 "Dereference Failure" [this doc] | 300 "Dereference Failure" [this doc] | |||
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. | |||
To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning | To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning | |||
Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois | Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois | |||
Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, | Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, | |||
Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard | Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard | |||
Barnes, Dan Wing, Matt Lepinski, John Elwell and Jacqueline Lee for | Barnes, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach and | |||
constructive feedback and nits checking. | Jacqueline Lee for constructive feedback and nits checking. | |||
Special thanks to Paul Kyzivat for his help with the ABNF in this | Special thanks to Paul Kyzivat for his help with the ABNF in this | |||
document and to Robert Sparks for many helpful comments and the | document and to Robert Sparks for many helpful comments and the | |||
proper construction of the Geolocation-Error header field. | proper construction of the Geolocation-Error header field. | |||
And finally, to Spencer Dawkins for giving this doc a good scrubbing | And finally, to Spencer Dawkins for giving this doc a good scrubbing | |||
to make it more readable. | to make it more readable. | |||
10. References | 10. References | |||
skipping to change at page 26, line 5 | skipping to change at page 26, line 41 | |||
[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, | [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, | |||
D. Gurle, "Session Initiation Protocol (SIP) Extension for | D. Gurle, "Session Initiation Protocol (SIP) Extension for | |||
Instant Messaging" , RFC 3428, December 2002 | Instant Messaging" , RFC 3428, December 2002 | |||
[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE | [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE | |||
Method", RFC 3311, October 2002 | Method", RFC 3311, October 2002 | |||
[RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific | [RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific | |||
Event Notification", RFC 3265, June 2002. | Event Notification", RFC 3265, June 2002. | |||
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of | [RFC6086] C. Holmberg, E. Burger, H. Kaplan, "Session Initiation | |||
Provisional Responses in Session Initiation Protocol (SIP)", | Protocol (SIP) INFO Method and Package Framework", RFC 6086, | |||
RFC 3262, June 2002. | January 2011 | |||
[RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000 | ||||
[RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer | [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer | |||
Method", RFC 3515, April 2003 | Method", RFC 3515, April 2003 | |||
[RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension | [RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension | |||
for Event State Publication", RFC 3903, October 2004. | for Event State Publication", RFC 3903, October 2004. | |||
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
[RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA | ||||
Considerations Section in RFCs", RFC 5226, May 2008 | ||||
[RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July | [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July | |||
2006 | 2006 | |||
[RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with | ||||
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 | [RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier | |||
for Geographic Locations ('geo' URI)", RFC 5870, June 2010 | for Geographic Locations ('geo' URI)", RFC 5870, June 2010 | |||
skipping to change at page 27, line 16 | skipping to change at page 27, line 43 | |||
[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. | [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. | |||
Thomson, M. Dawson, "A Location Dereferencing Protocol Using | Thomson, M. Dawson, "A Location Dereferencing Protocol Using | |||
HELD", "work in progress", December 2010 | HELD", "work in progress", December 2010 | |||
[ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. | [ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. | |||
Tschofenig, H. Schulzrinne, "An Architecture for Location | Tschofenig, H. Schulzrinne, "An Architecture for Location | |||
and Location Privacy in Internet Applications", | and Location Privacy in Internet Applications", | |||
draft-ietf-geopriv-arch, "work in progress", October 2010 | draft-ietf-geopriv-arch, "work in progress", October 2010 | |||
Author Addresses | Authors' 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 | |||
skipping to change at page 29, line 19 | skipping to change at page 29, line 47 | |||
along the path. | along the path. | |||
Motivation: Location-based routing. | Motivation: Location-based routing. | |||
A.2 Requirements for a UAS Receiving Location | A.2 Requirements for a UAS Receiving Location | |||
The following are the requirements for location conveyance by a UAS: | The following are the requirements for location conveyance by a UAS: | |||
UAS-1 SIP Responses must support location conveyance. | UAS-1 SIP Responses must support location conveyance. | |||
Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, | The SIPCORE WG reached consensus that this be allowed, but | |||
due to the many problems this requirement would have caused | not to communicate the UAS's location; rather for a SIP | |||
if implemented. The solution is for the above UAS to send a | intermediary to inform the UAC which location to include in | |||
new request to the original UAC with the UAS's location. | its next SIP request (as a matter of correcting what was | |||
originally sent by the UAC). | ||||
UAS-2 There must be a unique 4XX response informing the UAC it did | UAS-2 There must be a unique 4XX response informing the UAC it did | |||
not provide applicable location information. | not provide applicable location information. | |||
In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS. | In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS. | |||
A.3 Requirements for SIP Proxies and Intermediaries | A.3 Requirements for SIP Proxies and Intermediaries | |||
The following are the requirements for location conveyance by a SIP | The following are the requirements for location conveyance by a SIP | |||
proxies and intermediaries: | proxies and intermediaries: | |||
Proxy-1 Proxy servers must be capable of adding a Location header | Proxy-1 Proxy servers must be capable of adding a Location header | |||
field during processing of SIP requests. | field during processing of SIP requests. | |||
Motivation: Provide network assertion of location | Motivation: Provide network assertion of location | |||
when UACs are unable to do so, or when network assertion is | when UACs are unable to do so, or when network assertion is | |||
more reliable than UAC assertion of location | more reliable than UAC assertion of location | |||
Note: Because UACs connected to SIP signaling networks may have | Note: Because UACs connected to SIP signaling networks can have | |||
widely varying access network arrangements, including VPN | widely varying access network arrangements, including VPN | |||
tunnels and roaming mechanisms, it may be difficult for a | tunnels and roaming mechanisms, it can be difficult for a | |||
network to reliably know the location of the endpoint. Proxy | network to reliably know the location of the endpoint. | |||
assertion of location is NOT RECOMMENDED unless the SIP | Proxies SHOULD NOT assert location of an endpoint unless the | |||
signaling network has reliable knowledge of the actual | SIP signaling network has reliable knowledge of the actual | |||
location of the Targets. | location of the Targets. | |||
Proxy-2 There must be a unique 4XX response informing the UAC it | Proxy-2 There must be a unique 4XX response informing the UAC it | |||
did not provide applicable location information. | did not provide applicable location information. | |||
End of changes. 66 change blocks. | ||||
155 lines changed or deleted | 181 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |