--- 1/draft-ietf-sip-location-conveyance-10.txt 2008-10-30 20:12:03.000000000 +0100 +++ 2/draft-ietf-sip-location-conveyance-11.txt 2008-10-30 20:12:03.000000000 +0100 @@ -1,19 +1,19 @@ SIP Working Group James Polk Internet Draft Cisco Systems -Expiration: Aug 24, 2008 Brian Rosen +Expires: April 30, 2009 Brian Rosen Intended Status: Standards Track (PS) NeuStar - February 24, 2008 + October 30, 2008 Location Conveyance for the Session Initiation Protocol - draft-ietf-sip-location-conveyance-10.txt + draft-ietf-sip-location-conveyance-11.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,69 +24,70 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 24, 2008. + This Internet-Draft will expire on April 30, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end - conveyance as well as location-based routing, where proxy servers - make routing decisions based on the location of the SIP user agents. + conveyance as well as location-based routing, where SIP servers + make routing decisions based on the location of the user agent + clients. Table of Contents 1. Conventions and Terminology used in this document . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 5 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 4.2 424 (Bad Location Information) Response Code . . . . . . 9 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 10 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 18 4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 18 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 20 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 20 5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 22 - 6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 22 + 6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 23 6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 23 6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 26 - 6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 30 - 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 33 + 6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 31 + 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 - 9.1 IANA Registration for New SIP Geolocation Header . . . . 35 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 36 + 9.1 IANA Registration for New SIP Geolocation Header . . . . 36 9.2 IANA Registration for New SIP 'geolocation' Option Tag . 36 9.3 IANA Registration for New 424 Response Code . . . . . . . 36 9.4 IANA Registration for New SIP Geolocation-Error Header . 36 - 9.5 IANA Registration for New SIP Geolocation-Error Codes . . 36 + 9.5 IANA Registration for New SIP Geolocation-Error Codes . . 37 9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 37 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1 Normative References . . . . . . . . . . . . . . . . . 38 11.2 Informative References . . . . . . . . . . . . . . . . . 39 - Author Information . . . . . . . . . . . . . . . . . . . . . 39 - Appendix A. Requirements for SIP Location Conveyance . . . . 39 - Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 41 - Intellectual Property and Copyright Statements . . . . . . . 43 + Author Information . . . . . . . . . . . . . . . . . . . . . 40 + Appendix A. Requirements for SIP Location Conveyance . . . . 40 + Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 42 + Intellectual Property and Copyright Statements . . . . . . . 44 1. Conventions and Terminology used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The following terms and acronyms used throughout this document are defined here: @@ -181,21 +182,21 @@ within this extension. Location Conveyance is different from a UAC seeking the location the UAS. Location conveyance is a 'sending location out in the request' model, where 'asking that someone else's location be in a response' is not discussed here. Geographic location in the IETF is discussed in RFC 3693 (Geopriv Requirements) [RFC3693]. It defines a "Target" as the entity whose location is being sought. In this case, this is the UA's - (UA) location. A [RFC3693] "Using Protocol" defines how a "location + (UA) location. A [RFC3693] "Using Protocol" defines how a "Location Server" transmits a "Location Object" to a "Location Recipient" while maintaining the contained privacy intentions of the Target intact. This document describes the extension to SIP for how it complies with the Using Protocol requirements, where the location server is a UA or Proxy Server and the Location Recipient is another UA or Proxy Server. Location can be transmitted by-value or by-reference. The location "value" in this SIP extension is in the form of a Presence Information Data Format - Location Object, or PIDF-LO, as described @@ -291,21 +292,21 @@ within the appropriate locationValue. There is no mechanism by which the veracity of these parameters can be verified. They are hints to downstream entities on how the location information in the message was originated and used. Transport Layer Security is expected when a request contains a user's location. Some implementations will choose to have S/MIME to encrypt message bodies from source to destination. This document creates a new option tag: geolocation, to indicate - support for the this extension by UAs. + support for this extension by UAs. A new error response (424 Bad Location Information) is also defined in this document. Within this response is a new header indicating location-based errors, call the Geolocation-Error header. This header has various codes that provide additional information about the type of location error experienced by a Location Recipient. Both new headers, the header parameters, the new option tag, the new error response, and Geolocation-Error codes, which are defined in Section 4., are IANA registered by this document. @@ -403,52 +404,52 @@ ---------------------------------------------------------------- Geolocation R ar o - - o o o o Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Geolocation R ar o o o o o o o Table 1: Summary of the Geolocation Header The Geolocation header field MAY be included in any one of the above requests by a UAC. A proxy MAY add the Geolocation header, but MUST - NOT modify any pre-existing locationValue, including its associated - header parameters of within an existing Geolocation header value, + NOT modify any pre-existing locationValue, including any associated + header parameters within an existing Geolocation header value, unless one of the existing locationValues is used to retarget the request towards a new destination UAS. This is discussed in section 6.3. [RFC3261] states message bodies cannot be added by proxies. Therefore, any Geolocation header field added by a proxy MUST be in - the form of a LbyR URI, in its own locationValue header value. + the form of an LbyR URI, in its own locationValue header value. - Adding a new locationValue to an an in-transit request SHOULD NOT + Adding a new locationValue to an in-transit request SHOULD NOT occur for at least two reasons #1 - SIP Servers are not the best Sighters, as defined by [RFC3693], of geographically where a UAC can be; meaning the location information is not necessarily the greatest. There MAY be exceptions, but this SHOULD be the rule of thumb. #2 - without appropriate caution to the fact that Location Recipients might not understand how to process more than one location, given this document's limited guidance as to what a Location Recipient should do when receiving more than one location (i.e., currently no priority instructions are given for which locationValue to use if there are more than one). A Location Recipient can easily be confused by too much location information, producing undesirable results. The element in the PIDF-LO XML indicates whose location is contained in the PIDF-LO. Location Recipients receiving a location object, received directly or as the result of a dereference, MUST honor the usage element - rules within that XML document, as defined in RFC 4119. Such + rules within that XML document, as defined in [RFC4119]. Such entities MUST NOT alter the rule set. 4.2 424 (Bad Location Information) Response Code This SIP extension creates a new Location specific response code, defined as follows. 424 (Bad Location Information) The 424 (Bad Location Information) response code is a rejection of @@ -687,21 +688,21 @@ entity to any 1XX location error. 4.3.2 Location Error: 200 "Retry Location Later" (same data) The location error 200 "Retry Location Later" (same data) indicates to a Geolocation-Error recipient that what they supplied in a request, as far as location is concerned, cannot be processed at this time, but to retry this request, without changing the location information, at a later time - in a new SIP request. It is possible that the Location Recipient cannot process location at this time, or - there was a timeout during dereferencing, if a LbyR were sent. + there was a timeout during dereferencing, if an LbyR were sent. Action(s) to be taken by Geolocation-Error receiver to a 2XX: Reactions to a 2XX location error are to try again, without having to update the location supplied originally. There is no constraints on how long this new try has to wait, unless there is a Retry-After header in a 424 response. Implementations SHOULD choose to react by preparing, however this "inserter=" does or can, to queue another message with the same location information, provided the "inserter=" does not move between @@ -779,21 +780,21 @@ The location error 400 "Permission Necessary" indicates to a Geolocation-Error recipient that when they set a particular SIP request, they included location in that request without giving permission in the request for a (or any) SIP server to look at that location information to route the message at the intended recipient (i.e., the UAS, or the called party). Action(s) to be taken by Geolocation-Error receiver to a 4XX: 4XX location errors indicate to the UAC (i.e., the calling - party), that they need to grant permission to a SIP + party) that they need to grant permission to a SIP intermediary server to look at the supplied location to complete the message routing. This indication MUST require human user intervention, as the rulemaker of the policy on whether or not their location is to be revealed. The user of the location "inserter=" device can choose to grant permission to this SIP intermediary server to allow this request to be routed, or the user can deny this location revelation (request by the server). It is the user's choice as rulemaker. @@ -873,45 +874,47 @@ Geolocation-Error: 500; code="Location Information Denial"; node="bob.example.com"; inserter="alice.example.com"; This category covers location errors 5XX; meaning there MAY be more specific errors added to this category in future effort(s). The same basic actionable reaction is expected by a location "inserter=" entity to any 5XX location error. +4.3.6 Which Scenario Matches Which Error Code? + The following are some additional failure scenarios, with which - error code is to be used for each at the time of this document: + error code SHOULD be used for consistency, - Scheme (sip:, or sips:, or pres:, or another one) of the LbyR URI isn't supported (100) - Format (geo or civic) isn't supported (100) - Cannot parse location (100) - Can't find LIS (no access or no path (100) or denied access(500)) - Dereference failed (timeout) (200) - Insufficient location info supplied (300) - Cannot find location in message (300) 4.4 The 'geolocation' Option Tag This document creates and IANA registers one new option tag: "geolocation". This option tag is to be used, as defined in RFC 3261, in the Require, Supported and Unsupported headers. Whenever a UA wants to indicate support for this SIP extension, the geolocation option tag is included in a Supported header of the SIP request. 4.5 Using sip/sips/pres as a Dereference Scheme - If a LbyR (LbyR) URI is included in a SIP request, it MUST be a SIP, - SIPS or PRES-URI. When PRES: is used, if the resulting resolution, - as defined in [RFC3856], resolves to a SIP: or SIPS: URI, this + If an LbyR URI is included in a SIP request, it MUST be a SIP, SIPS + or PRES-URI. When PRES: is used, if the resulting resolution, as + defined in [RFC3856], resolves to a SIP: or SIPS: URI, this section applies. This document IANA registers 3 mandatory to implement URI schemes for LbyR: o SIP: o SIPS: o PRES: These 3 are IANA registered in Section 9.6. @@ -944,54 +947,59 @@ | |----------------------------->| | | | | | NOTIFY w/ PIDF-LO | | |----------------------------->| | | 200 (OK) | | |<-----------------------------| | | | Figure 2. Location-by-Reference and Dereferencing - In Figure 2., Alice sends Bob her location in a LbyR URI. Bob + In Figure 2., Alice sends Bob her location in an LbyR URI. Bob receives this LbyR URI in the INVITE and generates a new transaction (SUBSCRIBE) to retrieve the PIDF-LO of Alice. If accepted, the - PIDF-LO will be in the NOTIFY request from the Location Server. - This is the first instance between Alice and Bob that Alice's - location is in any message, therefore it is sent only once, from the - Location Server to Bob. + PIDF-LO will be in the NOTIFY request from the Location Server back + to Bob's UA. This is the first instance between Alice and Bob that + Alice's location is in any message, therefore it is sent only once, + from the Location Server to Bob. - A dereference of a LbyR URI using SUBSCRIBE is not violating a + The SUBSCRIBE contains a geolocation option tag in either the + Supported or Require header (depending on what strength of support + the UAC wants to apply). The NOTIFY MUST match the subscribing + UAC's option-tag strength for geolocation. + + A dereference of an LbyR URI using SUBSCRIBE is not violating a PIDF-LO 'retransmission-allowed' element value set to 'no', as the NOTIFY is the only message in this multi-message set of transactions that contains the Target's location, with the location recipient - being the only SIP element to receive location - which is the - purpose of this extension: to convey location to a specific + being the only SIP element to receive this PIDF-LO. This is the + purpose of this extension to SIP - to convey location to a specific destination. 5. Geolocation Examples This section contains are two examples of messages providing location. One shows LbyV with coordinates, the other shows LbyR. The example for (Coordinate format) is taken from [RFC3825]. A civic format example of the same position on the earth as is in the coordinate format example is in appendix B, which is taken from [RFC4776]. The differences between the two formats are within the of the examples. Other than this portion of each PIDF-LO, the rest is the same for both location formats. The key to the provided samples is in the Geolocation header, which has a different type of URI, based on the different means of location conveyance. Section 5.1 shows a "cid:" URI, indicating - this SIP request contains a LbyV message body - which is in the form - of a PIDF-LO. Section 5.2 shows a LbyR URI indicating location is - to be acquired via an indirection dereference mechanism, which is - determined by the scheme of URI supplied. + this SIP request contains an LbyV message body - which is in the + form of a PIDF-LO. Section 5.2 shows an LbyR URI indicating + location is to be acquired via an indirection dereference mechanism, + which is determined by the scheme of URI supplied. 5.1 Location-by-value (Coordinate Format) This example shows an INVITE message with a coordinate, or coordinate location. In this example, the SIP request uses a sips-URI [RFC3261], meaning this message is TLS protected on a hop-by-hop basis all the way to Bob's domain. INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 @@ -1004,53 +1012,55 @@ Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp + ...SDP goes here --boundary1 Content-Type: application/pidf+xml - Content-ID: alice123@atlanta.example.com + Content-ID: target123@atlanta.example.com - + 2007-12-02T14:00:00Z 33.001111 -96.68142 no 2007-12-07T18:00:00Z DHCP www.example.com - + --boundary1-- The Geolocation header field from the above INVITE... Geolocation: ...indicates the content-ID location [RFC2392] within the multipart message body of where location information is, with SDP being the other message body part. The "cid:" eases parsing of message @@ -1063,47 +1073,47 @@ ...the presence of something other than "cid:" indicates an LbyR is included in this message. It is expected that any node wanting to know where user target123 is would subscribe to server5 to dereference the sips-URI (see Figure 2. for this message flow, and Section 5.2 for this decoded example). The returning NOTIFY would contain Alice's location in a PIDF-LO, as if it were included in a message body (part) of the original INVITE here. 5.2 Location-by-reference - Below is an INVITE request with a LbyR URI instead of a LbyV PIDF-LO - message body part shown in Section 5.1. It is up to the location - recipient to dereference Alice's location at the Atlanta LIS server - containing the location record. Dereferencing, if done with SIP, is - accomplished by the Location Recipient sending a SUBSCRIBE request - to the URI reference for Alice's location. The received NOTIFY is - the first SIP request containing Alice's UA location, as a PIDF-LO - message body (see Figure 2 for this message flow example). The - NOTIFY, in this case, is the SIP request that is conveying location, - and not the INVITE. There is no retransmission of location in this - usage. + Below is an INVITE request with an LbyR URI instead of an LbyV + PIDF-LO message body part shown in Section 5.1. It is up to the + location recipient to dereference Alice's location at the Atlanta + LIS server containing the location record. Dereferencing, if done + with SIP, is accomplished by the Location Recipient sending a + SUBSCRIBE request to the URI reference for Alice's location. The + received NOTIFY is the first SIP request containing Alice's UA + location, as a PIDF-LO message body (see Figure 2 for this message + flow example). The NOTIFY, in this case, is the SIP request that is + conveying location, and not the INVITE. There is no retransmission + of location in this usage. INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com ;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob From: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: ;inserted-by="bigbox3.atlanta.example.com" Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: - ...SDP goes here as the only message body + (...SDP goes here as the only message body) A Location Recipient would need to dereference the sips-URI in the Geolocation header field to retrieve Alice's location. If the atlanta.example.com domain chooses to implement location conveyance and delivery in this fashion (i.e., LbyR), it is RECOMMENDED that entities outside this domain be able to reach the dereference server, otherwise this model of implementation is only viable within the atlanta.example.com domain. 6. SIP Element Behavior @@ -1192,46 +1202,60 @@ locationValue in this request. Because more than one locationValue can be inserted along the path of the request, this indication is necessary to show which locationValue had the problem in the response, and who the locationErrorValue is for. For example: Geolocation: ; inserted-by="alice@atlanta.example.com" If a UAC does not learn and store its location locally (a GPS chip) or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR - URI (from DHCP for example. If the latter is the case, the UAC MAY + URI (from DHCP for example). If the latter is the case, the UAC MAY SUBSCRIBE to this LbyR URI, using the 'presence' event package, to - get and store its own location. This document does not give a - reason why a UAC would want to do this. + get and store its own location. - Possession of a Target's LbyR, even though the act of dereferencing - this URI will be challenged by a LIS were this location record is - - providing a good deal of protection, SHOULD still be treated as - equivalent to possession of the location information itself and thus - TLS SHOULD be used when transmitting LbyR hop-by-hop along the path - to the Location Recipient. + The act of dereferencing a Target's LbyR will be challenged by the + LIS were this location record is - providing a good deal of + protection, SHOULD still be treated as equivalent to possession of + the location information itself and thus TLS SHOULD be used when + transmitting LbyR hop-by-hop along the path to the Location + Recipient, for protection reasons. This is not to be confused with + a possession model, in which possessing the LbyR grants + authorization to dereference the URI. Any entity dereferencing the + LbyR MUST pass whatever authentication and authorization rules are + on the LIS for this location record. The Rulemaker from [RFC3693] + is still very much in control - for any entity possessing the LbyR. + + If a UAC has already conveyed location in the original request of a + transaction, and wants to update its location information (for + whatever reason) after the original request is sent, or after a + dialog is created (regardless of how the UAC conveyed location + previously, as an LbyV or LbyR) - this is done by a UAC sending an + UPDATE request [RFC3311] containing the geolocation option tag and + Geolocation header with the new locationValue (LbyV or LbyR) to the + original destination UAS. A PIDF includes identity information. It is possible for the identity in the PIDF to be anonymous. Implementations of this extension SHOULD consider the appropriateness of including an anonymous identity in the location information where a real identity is not required. When using LbyR, the LbyR MUST NOT contain any user identifying information. For example, use something unidentifiable like + 3fg5t5yqw@example.atlanta.com rather than aliceishere@example.atlanta.com). - Use of elf-signed certificates is inappropriate for used in + Use of self-signed certificates is inappropriate for use in protecting a PIDF, as the sender does not have a secure identity of the recipient. 6.1.1 UAC Receiving a Location Failure Indication Location Recipients can be either, or both, destination UASs and intermediate servers that use the location information for location-based routing decisions. If a sent request fails based on the location information in the request, a 424 (Bad Location Information) response is sent back to the UAC. The 424 MUST have a @@ -1273,37 +1297,37 @@ location, any response MAY contain a Geolocation-Error header containing a locationErrorValue with the details of the location error. 6.2 UAS Behavior If the Geolocation header field is present in a received SIP request, the type of URI contained in the locationValue will indicate if location is an LbyV in a message body (part) or LbyR, requiring an additional dereference transaction. If the LbyR URI is - sip:, sips: or pres:, and the UAS wants to leran the UAC's location, + sip:, sips: or pres:, and the UAS wants to learn the UAC's location, the UAS MUST initiate a SUBSCRIBE to the URI provided to retrieve the PIDF-LO being conveyed by the UAC as defined in [RFC3856]. If successful, the PIDF-LO will be returned in the NOTIFY request from the remote host. The UAS is not REQUIRED to dereference the LbyR if it does not want to (by configuration or user choice). It is RECOMMENDED the UAS render the location sent to it, however it is configured to do so. A Require header with the 'geolocation' option tag indicates the UAC is requiring the UAS understand this extension or else send an error response. A 420 (Bad Extension) with a 'geolocation' option tag in an Unsupported header would be the appropriate response in this case. It is possible, but undesirable, for a message to arrive with a body - containing a LbyV, but with no Geolocation header field value + containing an LbyV, but with no Geolocation header field value pointing to it (potentially no Geolocation header field at all). In this case, the recipient MAY still read and use the message body. Unless stated otherwise by future standards-track publication(s), a LbyR URI only has meaning within the Geolocation header field and MUST NOT appear in any other SIP header field. There are 2 Geolocation header parameters, o "inserted-by=" o "used-for-routing" @@ -1342,42 +1366,47 @@ any number of issues/problems with receiving location, and the UAC or proxy servers cannot error a response. Therefore, the UAS, if it wants to send a UAC its location, SHOULD do so in a new request in a separate transaction. This document gives no guidance which SIP request to use, but SIP MESSAGE is a viable choice. A UAS MAY include a 'geolocation' option tag in the Supported header of a response, indicating it does understand this extension, even if location was not in a request to the UAS. - A UAS wishing to dereference a LbyR URI contained in a received + A UAS wishing to dereference an LbyR URI contained in a received request will use the 'presence' event package in a SUBSCRIBE request to the URI. If accepted, the PIDF-LO will return to the UAS in a NOTIFY request. If there are any errors during dereferencing, or in the PIDF-LO itself, the UAS will error the original request to the UAC with a locationErrorValue indicating what the UAS concluded was wrong with the location. This is to include any dereferencing problems encountered. Section 4.5 of this document called for the IANA registration of 3 URI schemes (sip:, sips:, and pres:) that are mandatory to implement for dereferencing. + A UAS MUST be prepared to receive subsequent location updates from + the UAC, either LbyV or LbyR (regardless of how the UAS received + location previously from this UAC). The UAC will convey location + using the UPDATE [RFC3311] method to the UAS. + If there is more than one location (any combination of LbyV and LbyR), this document does not give guidance what a Location Recipient does with each location. There are no priority or more-trusted indications given by this document. All this is considered application specific, and out-of-scope of this document. This document makes it clear that if when there are more than one location, each in the same PIDF-LO MUST be about the same Target (identifier) and point at the same position on the earth. If there - are more than one PIDF-LOs with different Target identifiers, then + is more than one PIDF-LO with different Target identifiers, then the UAC is merely telling the UAS where more than one Target is, and there should not be any conflict. 6.2.1 UAS Generating a Location Failure Indication If a UAS receives location in a request, but determines there is a problem with the location in the request, it is the responsibility of the UAS to inform whomever inserted location into that request there was a problem experienced. The Geolocation header in the request has a locationValue, providing the UAS a URI indicating @@ -1406,29 +1435,28 @@ others have errors with them, a 424 (Bad Location Information) response MUST NOT be sent. The Location Recipient (the UAS) is RECOMMENDED to send a locationErrorValue for each errored locationValue, with unique "inserter=" parameters to make sure the right entities know which locations were in error. As hinted at, a location "inserter=" can be a UAC or it can be an in-signaling-path SIP server, who is acting as a UAC Sighter, as defined in RFC3693. This means the SIP server is including its version of where it thinks the UAC is, geographically. This - "inserter=" has to be in the form of a LbyR URI in a locationValue, + "inserter=" has to be in the form of an LbyR URI in a locationValue, because SIP servers are not allowed to insert message bodies, as of the time of this publication, from all the way back to RFC3261. Each locationErrorValue has a error code, letting the location "inserter=" entity know what was wrong with the location supplied. See Section 4.3 for the 5 actionable responses a UAC can take from a locationErrorValue. - If the location "inserted-by=" entity, meaning either the UAC or proxy in the message path, chose to indicate that location was so important in the request to include a 'geolocation' option tag in a Require header, the response SHOULD be a 424 (Bad Location Information) back to the "inserter=" entity (knowing the response will ultimately go to the UAC regardless) if there needs to be a locationErrorValue sent because the location was bad. Only entities identified in a locationErrorValue as the "inserter=" entity will pay attention to this locationErrorValue. All other entities MUST ignore any locationErrorValue not directed towards them. See @@ -1541,21 +1569,21 @@ More than one Geolocation locationValue in a message is permitted, but can cause confusion at the recipient. If a proxy chooses to add a locationValue to a Geolocation header, which would be a local policy decision, the new locationValue MUST be added to the end of the header (after previous locationValue(s)). This is done to create an order of insertion of locationValues along the path. Proxies MUST NOT modify the order of locationValues in a geolocation header. - A proxy wishing to dereference a LbyR URI contained in a received + A proxy wishing to dereference an LbyR URI contained in a received request will use the 'presence' event package in a SUBSCRIBE request to the URI. If accepted, the PIDF-LO will return to the proxy in a NOTIFY request. If there are any errors during dereferencing, or in the PIDF-LO itself, the proxy will error the original request to the UAC with a locationErrorValue indicating what the proxy concluded was wrong with the location. This is to include any dereferencing problems encountered. 6.3.1 Proxy Behavior with Geolocation Header Parameters @@ -1725,21 +1754,21 @@ decide whether to reveal its location using hop-by-hop methods. UAC implementations MUST make such capabilities conditional on explicit user permission, and SHOULD alert a user that location is being conveyed. Proxies inserting location for location-based routing are unable to meet this requirement, and such use is NOT RECOMMENDED. Proxies conveying location using this extension MUST have the permission of the Target to do so. One facet within this extension is such that locations can be placed on a remote server, accessible with the possession of a URI. The - concept of a LbyR URI has its own security considerations. It is + concept of an LbyR URI has its own security considerations. It is tempting to assume that the dereference would have authentication, authorization and other security mechanisms that limit the access to information. Unfortunately, this might not be true. The access network the UAC is connected to can be the source of location reference, and it might not have any credentialing mechanism suitable for controlling access to location. Consider, specifically, a nomadic user connected to an access network in a hotel. The UAC has no way to provide a credential acceptable to the hotel Location Server (LS) to any of its intended Location Recipients. The recipient of a reference does not know if a @@ -1862,45 +1891,47 @@ Additions to this registry require an industry specification. 10. Acknowledgements To Dave Oran for helping to shape this idea. To Jon Peterson and Dean Willis on guidance of the effort. To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat, - Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie and Matt - Lepinski for constructive feedback. A special thanks to Dan Wing - for help with the S/MIME example, and to Robert Sparks for many - helpful comments and the proper building of the Geolocation-Error - header. + Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie, Matt + Lepinski and Jacqueline Lee for constructive feedback and nits + checking. + + A special thanks to Paul Kyzivat for his help with the ABNF in this + document, to Dan Wing for help with the S/MIME example, and to + Robert Sparks for many helpful comments and the proper building of + the Geolocation-Error header. 11. References 11.1 References - Normative [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource - Locators", RFC 2393, August 1998 + Locators", RFC 2392, August 1998 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004 - [RFC3856] J. Rosenberg, " A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, August 2004 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging" , RFC 3428, December 2002 @@ -1907,20 +1938,24 @@ [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. + [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer + [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension + for Event State Publication", RFC 3903, October 2004. + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [IANA-civic] http://www.iana.org/assignments/civic-address-types- registry 11.2 References - Informative [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 @@ -1928,31 +1963,36 @@ [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", RFC 4776, October 2006 Author Information James Polk Cisco Systems - 3913 Treemont Circle 33.00111N - Colleyville, Texas 76034 96.68142W + 3913 Treemont Circle + Colleyville, Texas 76034 + + 33.00111N + 96.68142W Phone: +1-817-271-3552 Email: jmpolk@cisco.com Brian Rosen NeuStar, Inc. - 470 Conrad Dr. 40.70497N - Mars, PA 16046 80.01252W - US + 470 Conrad Dr. + Mars, PA 16046 + + 40.70497N + 80.01252W Phone: +1 724 382 1051 Email: br@brianrosen.net Appendix A. Requirements for SIP Location Conveyance The following subsections address the requirements placed on the UAC, the UAS, as well as SIP proxies when conveying location. There is a motivational statement below each requirements that is not obvious in intent @@ -2056,56 +2096,58 @@ signaling network has reliable knowledge of the actual location of the Targets. Proxy-2 There must be a unique 4XX response informing the UAC it did not provide applicable location information. Appendix B. Example of INVITE with S/MIME encrypted Civic PIDF-LO This appendix gives an *EXAMPLE* (meaning this might contain errors based on future review) of a SIP INVITE request that points to the - same position on the earth as the coordinate based example that's in - section 5.1 in the body of this document: + same position on the earth as the coordinate based example that is + in section 5.1 in the body of this document: The INVITE request is TLS hop-by-hop encrypted, and the LbyV message body is S/MIME encrypted. This example shows the location message body in its unencrypted form for clarity. The message body lines below that have the '$' signs are S/MIME - encrypted. In this example, the SDP is not S/MIME encrypted. + encrypted. In this example, the SDP is not S/MIME encrypted. A + complete list of IANA registered CAtypes can be found at + [IANA-civic]. INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com ;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob From: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com - Geolocation: + Geolocation: ;inserted-by="alice@atlanta.example.com" Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ...SDP goes here --boundary1 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m - Content-ID: alice123@atlanta.example.com + Content-ID: target123@atlanta.example.com $ Content-Type: application/pidf+xml $ $ $ $ $ 2007-07-09T14:00:00Z