idnits 2.17.00 (12 Aug 2021) /tmp/idnits38394/draft-garcia-simple-indirect-presence-publish-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 444. 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 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 (February 18, 2008) is 5206 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-09 == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 H. Tschofenig 4 Intended status: Standards Track Nokia Siemens Networks 5 Expires: August 21, 2008 H. Schulzrinne 6 Columbia University 7 February 18, 2008 9 Indirect Presence Publication with the Session Initiation Protocol(SIP) 10 draft-garcia-simple-indirect-presence-publish-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 21, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 SIP is extended by the SIP-events framework to provide subscriptions 44 and notifications of SIP events. One example of such event 45 notification mechanism is 'presence' and this presence information is 46 carried in Presence Information Data Format (PIDF) documents. 48 The SIP PUBLISH method specified in RFC 3903 carrying a PIDF document 49 is typically used when presentities publish their own presence since 50 these presentities are typically the source of the information. 51 However, there are cases when the presentity is not the direct source 52 of the presence information. One such example is location 53 information where the end host may obtain a reference to location 54 information as opposed to as a value. The endpoint is typically not 55 interested in knowing its own location information, but other users 56 or entities might be. So, if the endpoint gets its own location 57 information with a reference and wants to publish it embedded in its 58 presence information, it first needs to de-reference it for getting a 59 value, and then it can embed that value in its presence information. 60 While this is certainly a correct sequence, it adds a round-trip to 61 the presence publication, in addition to a demand processing power 62 and network bandwidth consumption. 64 There is a need for a mechanism that the presentity can use to 65 publish indirect references, such as indirect location references. 66 This document discusses a few variants that may be used to provide 67 this functionality. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Geolocation Protocols Relationship . . . . . . . . . . . . 4 73 1.2. Case Study: Location URIs . . . . . . . . . . . . . . . . 6 74 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 75 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 76 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 4. Security considerations . . . . . . . . . . . . . . . . . . . 9 78 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 80 5.2. Informational References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 82 Intellectual Property and Copyright Statements . . . . . . . . . . 12 84 1. Introduction 86 The Session Initiation Protocol (SIP) [RFC3261] is extended by the 87 SIP-events framework [RFC3265] to provide subscriptions and 88 notifications of SIP events. One example of such event notification 89 mechanism is 'presence'. The presence information is typically 90 carried in Extensible Markup Language (XML) [W3C.REC-xml-20060816] 91 documents that are compliant with a given XML schema 92 [W3C.REC-xmlschema-0-20041028]. These presence documents are called 93 Presence Information Data Format (PIDF) documents [RFC3863]. 95 The SIP PUBLISH method specified in RFC 3903 [RFC3903] carrying a 96 PIDF document is typically used when presentities publish their own 97 presence information. Usually the presentity can compose a quite 98 detailed PIDF document, which is typically extended with a number of 99 rich information, such as the Presence Data Model [RFC4479], Rich 100 Presence Extensions to PIDF (RPID) [RFC4480], or the Contact 101 Information to the Presence Information Data Format (CIPID) 102 [RFC4481]. 104 In the mentioned extensions, the presentity is typically the source 105 of the extended rich presence information. However, there are 106 occasions, when the presentity is not the direct source of the 107 presence information. One of these cases occurs when a presentity 108 acquires its own location information from a HELD server 109 [I-D.ietf-geopriv-http-location-delivery]. The HELD client on the 110 end host can request Location URI (location by reference) as opposed 111 to as a value (location by value). 113 1.1. Geolocation Protocols Relationship 115 Figure 1 depicts the geolocation protocol relationship. A Location 116 URI points to a Location Configuration Protocol (LCP) server that is 117 able to provide location of a specific target. The LCP server is 118 able to associate the Location URI to the location of the target 119 inside its administrative domain. A target of location information 120 implements a Location Configuration Protocol (LCP) client. The LCP 121 client first uses the location configuration protocol to acquire its 122 location information (see step 1 in Figure 1). We assume this 123 location information is delivered in the format of a reference. 125 Then the LCP client needs to de-reference the acquired reference. 126 This done in step 2 in Figure 1 and uses a location de-reference 127 protocol to get a value of its location information. Last, the end 128 host can embed its location information in the location conveyance 129 protocol (step 3 in in Figure 1) and send it to a location recipient, 130 such as a presence server. 132 +-----------+ +------------+ 133 | | | Location | 134 | LCP | | recipient/ | 135 | server | | Presence | 136 | | | cerver | 137 +-----------+ +------------+ 138 ^ ^ ^ 139 Geopriv | | Geopriv // 140 Location | | Location // 141 Dereference| | Configuration // 142 Protocol | | Protocol // 143 (2) | | (1) // 144 | | // Geopriv Location 145 v v // Conveyance Protocol 146 +-----------+ // (e.g., SIP) 147 | Target / | // (3) 148 | End host |v 149 | LCP client| 150 +-----------+ 152 Figure 1: Current Geolocation Protocols Relationship 154 This document, though, discusses proposals for the scenario 155 envisioned in Figure 2, where the target or end hosts acquires a 156 reference via the location configuration protocol (step 1 in 157 Figure 2), sends such reference in a location conveyance protocol or 158 presence publication (step 2), and lets the location recipient or 159 presence server to acquire the actual value according to the 160 reference (step 3). 162 The kind of reference that is first acquired and then send to the 163 location recipient determines the value that the location recipient 164 gets in step 3. Section 1.2 discusses location URIs. 166 +-----------+ Geopriv +------------+ 167 | | Location | Location | 168 | LCP |<------------->| Recipient/ | 169 | server | Dereference | Presence | 170 | | Protocol (3) | Server | 171 +-----------+ +------------+ 172 ^ ^ 173 | Geopriv // 174 | Location // 175 | Configuration // 176 | Protocol // 177 | (1) // 178 | // Geopriv Location 179 v // Conveyance Protocol 180 +-----------+ // (e.g., SIP) 181 | Target / | // (2) 182 | End Host |v 183 | LCP Client| 184 +-----------+ 186 Figure 2: Proposed Geolocation Protocols Relationship 188 1.2. Case Study: Location URIs 190 A Location URI points to a Location Configuration Protocol (LCP) 191 server that is able to provide location of a specific target. The 192 LCP server is able to associate the Location URI to the location of 193 the target inside its administrative domain. However, the resolution 194 step from a Location URI to a Location Object may be influenced by 195 different parameters and by the location URI itself. 197 Depending on the value returned as an invocation to the reference 198 URI, we can classify location URI in two cases: 200 Static location URIs: 202 Whenever a static location URI is de-referenced, the same static 203 location is returned. These URIs are typically constrained by a 204 start and a stop time. For example, the location of Alice on a 205 her 21st birthday at 10:00 AM is a static location URI, because 206 she was in a place at that time and date, so, the location does 207 not change. The path that Alice took on the same day from 12 PM 208 to 2 PM is also a static location URI, because as a result of its 209 de-reference the location recipient will get the same collection 210 of locations. 212 Dynamic location URIs: 214 Every time a dynamic location URI is de-referenced a new 215 (potentially different) location is provided. Typically these 216 URIs do not have a constraint with the time. Assume Alice 217 acquires a URI that points to her current location, every time 218 that a location recipient invokes the URI, he will get a different 219 location (assuming that Alice's location changes). Another 220 example can be when Alice acquires a URI that provides her 221 location between today noon and now, so, when the location 222 recipient invokes the URI, he will be accumulating further 223 locations, providing that Alice is changing her location. 225 Dynamic location URIs have stronger privacy considerations, because 226 the target does not really know what is the location supplied at any 227 time. However, the target has mechanisms to constraint the 228 availability of a dynamic location URI, for example, by imposing a 229 time when the reference expires. 231 With either dynamic or location URIs there is a need for a mechanism 232 that allows the presentity to publish indirect references. In 233 absence of this mechanism, the presentity would need to retrieve its 234 location information by value, compose a PIDF document that contains 235 it, and publish it to the presence server. 237 1.3. Terminology 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in BCP 14, RFC 2119 242 [RFC2119]. 244 This version of the document does not contain normative text at this 245 point in time given the different options that are available to solve 246 the described problem. 248 2. Overview of Operation 250 A presentity first send a location request 251 [I-D.ietf-geopriv-http-location-delivery] over the binding protocol, 252 indicating the desire to receive its location by reference. This is 253 done by including a element with the value set to 254 "locationURI". The server responds with one or more 255 elements, typically with different URI schemas. The presentity then 256 selects a SIP or SIPS URI scheme, and: 258 [[Editor's Note: We have several options here. We need to pick 259 one.]] 261 1. Inserts the value of the locationURI in a Geolocation header 262 field, as specified in the SIP Location Conveyance document 263 [I-D.ietf-sip-location-conveyance]. Then, it sends it in a 264 PUBLISH request, which may also contain a regular PIDF document. 266 The drawback of this approach is that it is specific to 267 geolocation and difficult to generalize. Furthermore, it is 268 not possible to determine whether the server actually 269 understands the provided references. 271 2. Inserts the locationURI value in a new extension to the PIDF to 272 carry an indirect reference. The extension consists of a new 273 element called "indirect-reference", which is inserted. Then, 274 the PIDF is attached to a PUBLISH request and sent to the 275 presence server. 277 The drawback of this approach is that it is still not possible 278 to determine whether the server supports it. Also, if the 279 referred document is a PIDF, then the semantics would be "here 280 is the reference to an additional PIDF document" as opposed to 281 "include this position some elements that are indirectly 282 referred". The advantage of this approach is that this 283 extension is general enough to include any indirect reference, 284 for example, to a calendar that can publish RFC 4481 285 extensions to PIDF. 287 3. Creates an additional XML document (independent of a PIDF 288 document) and if the presentity also attaches a regular PIDF 289 document, then both documents are put into a MIME multipart/ 290 related wrapper, which becomes the payload of the PUBLISH 291 request. Otherwise, the sole new XML document is attached to the 292 PUBLISH request and sent to the presence server. 294 The drawback of this approach is the shy support for multipart 295 MIME bodies. The advantage is a clean solution with no 296 interferences with PIDF. It also allows to include an 297 indirect-reference of any kind. 299 When the presence server receives a PUBLISH request that contains an 300 indirect reference, it tries to de-reference, e.g., invoke the URI 301 included there. If the result of such operation is that the presence 302 server gets a presentity's PIDF document, then it should consider the 303 document as directly published from the presentity, and should 304 composed a merged PIDF document, potentially including other sources 305 of presence information. 307 3. IANA Considerations 309 This document has no actions for IANA. 311 4. Security considerations 313 The security considerations described in SIP Location Conveyance 314 [I-D.ietf-sip-location-conveyance]are applicable to this document. 316 5. References 318 5.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 324 A., Peterson, J., Sparks, R., Handley, M., and E. 325 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 326 June 2002. 328 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 329 Event Notification", RFC 3265, June 2002. 331 5.2. Informational References 333 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 334 W., and J. Peterson, "Presence Information Data Format 335 (PIDF)", RFC 3863, August 2004. 337 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 338 for Event State Publication", RFC 3903, October 2004. 340 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 341 July 2006. 343 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 344 Rosenberg, "RPID: Rich Presence Extensions to the Presence 345 Information Data Format (PIDF)", RFC 4480, July 2006. 347 [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the 348 Presence Information Data Format (PIDF) to Indicate Status 349 Information for Past and Future Time Intervals", RFC 4481, 350 July 2006. 352 [W3C.REC-xml-20060816] 353 Maler, E., Paoli, J., Bray, T., Sperberg-McQueen, C., and 354 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 355 Edition)", World Wide Web Consortium Recommendation REC- 356 xml-20060816, August 2006, 357 . 359 [W3C.REC-xmlschema-0-20041028] 360 Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer 361 Second Edition", World Wide Web Consortium 362 Recommendation REC-xmlschema-0-20041028, October 2004, 363 . 365 [I-D.ietf-sip-location-conveyance] 366 Polk, J. and B. Rosen, "Location Conveyance for the 367 Session Initiation Protocol", 368 draft-ietf-sip-location-conveyance-09 (work in progress), 369 November 2007. 371 [I-D.ietf-geopriv-http-location-delivery] 372 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 373 "HTTP Enabled Location Delivery (HELD)", 374 draft-ietf-geopriv-http-location-delivery-04 (work in 375 progress), January 2008. 377 Authors' Addresses 379 Miguel A. Garcia-Martin 380 Nokia Siemens Networks 381 P.O.Box 6 382 Nokia Siemens Networks, FIN 02022 383 Finland 385 Email: miguel.garcia@nsn.com 387 Hannes Tschofenig 388 Nokia Siemens Networks 389 Otto-Hahn-Ring 6 390 Munich, Bavaria 81739 391 Germany 393 Email: Hannes.Tschofenig@nsn.com 394 URI: http://www.tschofenig.com 395 Henning Schulzrinne 396 Columbia University 397 Department of Computer Science 398 450 Computer Science Building 399 New York, NY 10027 400 USA 402 Phone: +1 212 939 7042 403 Email: schulzrinne@cs.columbia.edu 404 URI: http://www.cs.columbia.edu/~hgs 406 Full Copyright Statement 408 Copyright (C) The IETF Trust (2008). 410 This document is subject to the rights, licenses and restrictions 411 contained in BCP 78, and except as set forth therein, the authors 412 retain all their rights. 414 This document and the information contained herein are provided on an 415 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 416 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 417 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 418 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 419 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 420 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 422 Intellectual Property 424 The IETF takes no position regarding the validity or scope of any 425 Intellectual Property Rights or other rights that might be claimed to 426 pertain to the implementation or use of the technology described in 427 this document or the extent to which any license under such rights 428 might or might not be available; nor does it represent that it has 429 made any independent effort to identify any such rights. Information 430 on the procedures with respect to rights in RFC documents can be 431 found in BCP 78 and BCP 79. 433 Copies of IPR disclosures made to the IETF Secretariat and any 434 assurances of licenses to be made available, or the result of an 435 attempt made to obtain a general license or permission for the use of 436 such proprietary rights by implementers or users of this 437 specification can be obtained from the IETF on-line IPR repository at 438 http://www.ietf.org/ipr. 440 The IETF invites any interested party to bring to its attention any 441 copyrights, patents or patent applications, or other proprietary 442 rights that may cover technology that may be required to implement 443 this standard. Please address the information to the IETF at 444 ietf-ipr@ietf.org. 446 Acknowledgment 448 Funding for the RFC Editor function is provided by the IETF 449 Administrative Support Activity (IASA).