idnits 2.17.00 (12 Aug 2021) /tmp/idnits37559/draft-garcia-simple-indirect-presence-publish-01.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2009) is 4817 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: A later version (-13) exists of draft-ietf-sip-location-conveyance-12 == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group M. Garcia-Martin 3 Internet-Draft Ericsson 4 Intended status: Standards Track H. Tschofenig 5 Expires: September 7, 2009 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 March 6, 2009 10 Indirect Presence Publication with the Session Initiation Protocol(SIP) 11 draft-garcia-simple-indirect-presence-publish-01.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 September 7, 2009. 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-sip-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-sip-location-conveyance]are applicable to this document. 321 5. References 323 5.1. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 329 A., Peterson, J., Sparks, R., Handley, M., and E. 330 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 331 June 2002. 333 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 334 Event Notification", RFC 3265, June 2002. 336 5.2. Informational References 338 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 339 W., and J. Peterson, "Presence Information Data Format 340 (PIDF)", RFC 3863, August 2004. 342 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 343 for Event State Publication", RFC 3903, October 2004. 345 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 346 July 2006. 348 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 349 Rosenberg, "RPID: Rich Presence Extensions to the Presence 350 Information Data Format (PIDF)", RFC 4480, July 2006. 352 [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the 353 Presence Information Data Format (PIDF) to Indicate Status 354 Information for Past and Future Time Intervals", RFC 4481, 355 July 2006. 357 [W3C.REC-xml-20060816] 358 Paoli, J., Yergeau, F., Sperberg-McQueen, C., Bray, T., 359 and E. Maler, "Extensible Markup Language (XML) 1.0 360 (Fourth Edition)", World Wide Web Consortium 361 FirstEdition REC-xml-20060816, August 2006, 362 . 364 [W3C.REC-xmlschema-0-20041028] 365 Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer 366 Second Edition", World Wide Web Consortium 367 Recommendation REC-xmlschema-0-20041028, October 2004, 368 . 370 [I-D.ietf-sip-location-conveyance] 371 Polk, J. and B. Rosen, "Location Conveyance for the 372 Session Initiation Protocol", 373 draft-ietf-sip-location-conveyance-12 (work in progress), 374 November 2008. 376 [I-D.ietf-geopriv-http-location-delivery] 377 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 378 "HTTP Enabled Location Delivery (HELD)", 379 draft-ietf-geopriv-http-location-delivery-13 (work in 380 progress), February 2009. 382 Authors' Addresses 384 Miguel A. Garcia-Martin 385 Ericsson 386 Calle Via de los Poblados 13 387 Madrid, ES 28033 388 Spain 390 Email: miguel.a.garcia@ericsson.com 392 Hannes Tschofenig 393 Nokia Siemens Networks 394 Otto-Hahn-Ring 6 395 Munich, Bavaria 81739 396 Germany 398 Email: Hannes.Tschofenig@gmx.net 399 URI: http://www.tschofenig.priv.at 400 Henning Schulzrinne 401 Columbia University 402 Department of Computer Science 403 450 Computer Science Building 404 New York, NY 10027 405 USA 407 Phone: +1 212 939 7042 408 Email: schulzrinne@cs.columbia.edu 409 URI: http://www.cs.columbia.edu/~hgs