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