idnits 2.17.00 (12 Aug 2021) /tmp/idnits20816/draft-garcia-geopriv-indirect-publish-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 14, 2009) is 4662 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 == Outdated reference: draft-ietf-sipcore-location-conveyance has been published as RFC 6442 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV Working Group M. Garcia-Martin 3 Internet-Draft Ericsson 4 Intended status: Standards Track H. Tschofenig 5 Expires: February 15, 2010 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 August 14, 2009 10 Indirect Presence Publication with the Session Initiation Protocol(SIP) 11 draft-garcia-geopriv-indirect-publish-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 15, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 SIP is extended by the SIP-events framework to provide subscriptions 50 and notifications of SIP events. One example of such event 51 notification mechanism is 'presence' and this presence information is 52 carried in Presence Information Data Format (PIDF) documents. 54 The SIP PUBLISH method specified in RFC 3903 carrying a PIDF document 55 is typically used when presentities publish their own presence since 56 these presentities are typically the source of the information. 57 However, there are cases when the presentity is not the direct source 58 of the presence information. One such example is location 59 information where the end host may obtain a reference to location 60 information as opposed to as a value. The endpoint is typically not 61 interested in knowing its own location information, but other users 62 or entities might be. So, if the endpoint gets its own location 63 information with a reference and wants to publish it embedded in its 64 presence information, it first needs to de-reference it for getting a 65 value, and then it can embed that value in its presence information. 66 While this is certainly a correct sequence, it adds a round-trip to 67 the presence publication, in addition to a demand processing power 68 and network bandwidth consumption. 70 There is a need for a mechanism that the presentity can use to 71 publish indirect references, such as indirect location references. 72 This document discusses a few variants that may be used to provide 73 this functionality. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.1. Geolocation Protocols Relationship . . . . . . . . . . . . 4 79 1.2. Case Study: Location URIs . . . . . . . . . . . . . . . . 6 80 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 81 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 82 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 4. Security considerations . . . . . . . . . . . . . . . . . . . 9 84 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 86 5.2. Informational References . . . . . . . . . . . . . . . . . 9 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 The Session Initiation Protocol (SIP) [RFC3261] is extended by the 92 SIP-events framework [RFC3265] to provide subscriptions and 93 notifications of SIP events. One example of such event notification 94 mechanism is 'presence'. The presence information is typically 95 carried in Extensible Markup Language (XML) [W3C.REC-xml-20060816] 96 documents that are compliant with a given XML schema 97 [W3C.REC-xmlschema-0-20041028]. These presence documents are called 98 Presence Information Data Format (PIDF) documents [RFC3863]. 100 The SIP PUBLISH method specified in RFC 3903 [RFC3903] carrying a 101 PIDF document is typically used when presentities publish their own 102 presence information. Usually the presentity can compose a quite 103 detailed PIDF document, which is typically extended with a number of 104 rich information, such as the Presence Data Model [RFC4479], Rich 105 Presence Extensions to PIDF (RPID) [RFC4480], or the Contact 106 Information to the Presence Information Data Format (CIPID) 107 [RFC4481]. 109 In the mentioned extensions, the presentity is typically the source 110 of the extended rich presence information. However, there are 111 occasions, when the presentity is not the direct source of the 112 presence information. One of these cases occurs when a presentity 113 acquires its own location information from a HELD server 114 [I-D.ietf-geopriv-http-location-delivery]. The HELD client on the 115 end host can request Location URI (location by reference) as opposed 116 to as a value (location by value). 118 1.1. Geolocation Protocols Relationship 120 Figure 1 depicts the geolocation protocol relationship. A Location 121 URI points to a Location Configuration Protocol (LCP) server that is 122 able to provide location of a specific target. The LCP server is 123 able to associate the Location URI to the location of the target 124 inside its administrative domain. A target of location information 125 implements a Location Configuration Protocol (LCP) client. The LCP 126 client first uses the location configuration protocol to acquire its 127 location information (see step 1 in Figure 1). We assume this 128 location information is delivered in the format of a reference. 130 Then the LCP client needs to de-reference the acquired reference. 131 This done in step 2 in Figure 1 and uses a location de-reference 132 protocol to get a value of its location information. Last, the end 133 host can embed its location information in the location conveyance 134 protocol (step 3 in in Figure 1) and send it to a location recipient, 135 such as a presence server. 137 +-----------+ +------------+ 138 | | | Location | 139 | LCP | | recipient/ | 140 | server | | Presence | 141 | | | cerver | 142 +-----------+ +------------+ 143 ^ ^ ^ 144 Geopriv | | Geopriv // 145 Location | | Location // 146 Dereference| | Configuration // 147 Protocol | | Protocol // 148 (2) | | (1) // 149 | | // Geopriv Location 150 v v // Conveyance Protocol 151 +-----------+ // (e.g., SIP) 152 | Target / | // (3) 153 | End host |v 154 | LCP client| 155 +-----------+ 157 Figure 1: Current Geolocation Protocols Relationship 159 This document, though, discusses proposals for the scenario 160 envisioned in Figure 2, where the target or end hosts acquires a 161 reference via the location configuration protocol (step 1 in 162 Figure 2), sends such reference in a location conveyance protocol or 163 presence publication (step 2), and lets the location recipient or 164 presence server to acquire the actual value according to the 165 reference (step 3). 167 The kind of reference that is first acquired and then send to the 168 location recipient determines the value that the location recipient 169 gets in step 3. Section 1.2 discusses location URIs. 171 +-----------+ Geopriv +------------+ 172 | | Location | Location | 173 | LCP |<------------->| Recipient/ | 174 | server | Dereference | Presence | 175 | | Protocol (3) | Server | 176 +-----------+ +------------+ 177 ^ ^ 178 | Geopriv // 179 | Location // 180 | Configuration // 181 | Protocol // 182 | (1) // 183 | // Geopriv Location 184 v // Conveyance Protocol 185 +-----------+ // (e.g., SIP) 186 | Target / | // (2) 187 | End Host |v 188 | LCP Client| 189 +-----------+ 191 Figure 2: Proposed Geolocation Protocols Relationship 193 1.2. Case Study: Location URIs 195 A Location URI points to a Location Configuration Protocol (LCP) 196 server that is able to provide location of a specific target. The 197 LCP server is able to associate the Location URI to the location of 198 the target inside its administrative domain. However, the resolution 199 step from a Location URI to a Location Object may be influenced by 200 different parameters and by the location URI itself. 202 Depending on the value returned as an invocation to the reference 203 URI, we can classify location URI in two cases: 205 Static location URIs: 207 Whenever a static location URI is de-referenced, the same static 208 location is returned. These URIs are typically constrained by a 209 start and a stop time. For example, the location of Alice on a 210 her 21st birthday at 10:00 AM is a static location URI, because 211 she was in a place at that time and date, so, the location does 212 not change. The path that Alice took on the same day from 12 PM 213 to 2 PM is also a static location URI, because as a result of its 214 de-reference the location recipient will get the same collection 215 of locations. 217 Dynamic location URIs: 219 Every time a dynamic location URI is de-referenced a new 220 (potentially different) location is provided. Typically these 221 URIs do not have a constraint with the time. Assume Alice 222 acquires a URI that points to her current location, every time 223 that a location recipient invokes the URI, he will get a different 224 location (assuming that Alice's location changes). Another 225 example can be when Alice acquires a URI that provides her 226 location between today noon and now, so, when the location 227 recipient invokes the URI, he will be accumulating further 228 locations, providing that Alice is changing her location. 230 Dynamic location URIs have stronger privacy considerations, because 231 the target does not really know what is the location supplied at any 232 time. However, the target has mechanisms to constraint the 233 availability of a dynamic location URI, for example, by imposing a 234 time when the reference expires. 236 With either dynamic or location URIs there is a need for a mechanism 237 that allows the presentity to publish indirect references. In 238 absence of this mechanism, the presentity would need to retrieve its 239 location information by value, compose a PIDF document that contains 240 it, and publish it to the presence server. 242 1.3. Terminology 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in BCP 14, RFC 2119 247 [RFC2119]. 249 This version of the document does not contain normative text at this 250 point in time given the different options that are available to solve 251 the described problem. 253 2. Overview of Operation 255 A presentity first send a location request 256 [I-D.ietf-geopriv-http-location-delivery] over the binding protocol, 257 indicating the desire to receive its location by reference. This is 258 done by including a element with the value set to 259 "locationURI". The server responds with one or more 260 elements, typically with different URI schemas. The presentity then 261 selects a SIP or SIPS URI scheme, and: 263 [[Editor's Note: We have several options here. We need to pick 264 one.]] 266 1. Inserts the value of the locationURI in a Geolocation header 267 field, as specified in the SIP Location Conveyance document 268 [I-D.ietf-sipcore-location-conveyance]. Then, it sends it in a 269 PUBLISH request, which may also contain a regular PIDF document. 271 The drawback of this approach is that it is specific to 272 geolocation and difficult to generalize. Furthermore, it is 273 not possible to determine whether the server actually 274 understands the provided references. 276 2. Inserts the locationURI value in a new extension to the PIDF to 277 carry an indirect reference. The extension consists of a new 278 element called "indirect-reference", which is inserted. Then, 279 the PIDF is attached to a PUBLISH request and sent to the 280 presence server. 282 The drawback of this approach is that it is still not possible 283 to determine whether the server supports it. Also, if the 284 referred document is a PIDF, then the semantics would be "here 285 is the reference to an additional PIDF document" as opposed to 286 "include this position some elements that are indirectly 287 referred". The advantage of this approach is that this 288 extension is general enough to include any indirect reference, 289 for example, to a calendar that can publish RFC 4481 290 extensions to PIDF. 292 3. Creates an additional XML document (independent of a PIDF 293 document) and if the presentity also attaches a regular PIDF 294 document, then both documents are put into a MIME multipart/ 295 related wrapper, which becomes the payload of the PUBLISH 296 request. Otherwise, the sole new XML document is attached to the 297 PUBLISH request and sent to the presence server. 299 The drawback of this approach is the shy support for multipart 300 MIME bodies. The advantage is a clean solution with no 301 interferences with PIDF. It also allows to include an 302 indirect-reference of any kind. 304 When the presence server receives a PUBLISH request that contains an 305 indirect reference, it tries to de-reference, e.g., invoke the URI 306 included there. If the result of such operation is that the presence 307 server gets a presentity's PIDF document, then it should consider the 308 document as directly published from the presentity, and should 309 composed a merged PIDF document, potentially including other sources 310 of presence information. 312 3. IANA Considerations 314 This document has no actions for IANA. 316 4. Security considerations 318 The security considerations described in SIP Location Conveyance 319 [I-D.ietf-sipcore-location-conveyance]are applicable to this 320 document. 322 5. References 324 5.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 330 A., Peterson, J., Sparks, R., Handley, M., and E. 331 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 332 June 2002. 334 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 335 Event Notification", RFC 3265, June 2002. 337 5.2. Informational References 339 [I-D.ietf-geopriv-http-location-delivery] 340 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 341 "HTTP Enabled Location Delivery (HELD)", 342 draft-ietf-geopriv-http-location-delivery-15 (work in 343 progress), June 2009. 345 [I-D.ietf-sipcore-location-conveyance] 346 Polk, J. and B. Rosen, "Location Conveyance for the 347 Session Initiation Protocol", 348 draft-ietf-sipcore-location-conveyance-01 (work in 349 progress), July 2009. 351 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 352 W., and J. Peterson, "Presence Information Data Format 353 (PIDF)", RFC 3863, August 2004. 355 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 356 for Event State Publication", RFC 3903, October 2004. 358 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 359 July 2006. 361 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 362 Rosenberg, "RPID: Rich Presence Extensions to the Presence 363 Information Data Format (PIDF)", RFC 4480, July 2006. 365 [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the 366 Presence Information Data Format (PIDF) to Indicate Status 367 Information for Past and Future Time Intervals", RFC 4481, 368 July 2006. 370 [W3C.REC-xml-20060816] 371 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Maler, E., 372 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth 373 Edition)", World Wide Web Consortium FirstEdition REC-xml- 374 20060816, August 2006, 375 . 377 [W3C.REC-xmlschema-0-20041028] 378 Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer 379 Second Edition", World Wide Web Consortium 380 Recommendation REC-xmlschema-0-20041028, October 2004, 381 . 383 Authors' Addresses 385 Miguel A. Garcia-Martin 386 Ericsson 387 Calle Via de los Poblados 13 388 Madrid, ES 28033 389 Spain 391 Email: miguel.a.garcia@ericsson.com 393 Hannes Tschofenig 394 Nokia Siemens Networks 395 Linnoitustie 6 396 Espoo 02600 397 Finland 399 Phone: +358 (50) 4871445 400 Email: Hannes.Tschofenig@gmx.net 401 URI: http://www.tschofenig.priv.at/ 402 Henning Schulzrinne 403 Columbia University 404 Department of Computer Science 405 450 Computer Science Building 406 New York, NY 10027 407 USA 409 Phone: +1 212 939 7042 410 Email: schulzrinne@cs.columbia.edu 411 URI: http://www.cs.columbia.edu/~hgs