idnits 2.17.1 draft-garcia-geopriv-indirect-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The presence agent de-references URIs to acquire the referenced information. A "sip:", "sips:" or "pres:" URI is dereferenced by subscribing for the presence event package at the given URI; a "http:" or "https:" URI is dereferenced following the rules in [I-D.winterbottom-geopriv-deref-protocol]. Other URIs MUST not be used unless a method is defined for that URI that produces a presence document. -- The document date (October 26, 2009) is 5268 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 (-05) exists of draft-winterbottom-geopriv-deref-protocol-04 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-location-conveyance-01 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-08 == Outdated reference: A later version (-03) exists of draft-ietf-geopriv-arch-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Garcia-Martin 3 Internet-Draft Ericsson 4 Intended status: Standards Track H. Tschofenig 5 Expires: April 29, 2010 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 M. Thomson 9 Andrew Corporation 10 October 26, 2009 12 Indirect Presence Publication with the Session Initiation Protocol(SIP) 13 draft-garcia-geopriv-indirect-publish-01 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 29, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 A method for indirectly publishing presence information is described. 52 This allows a presentity user agent to publish a URI that can be used 53 by the presence agent to retrieve presence information. A presence 54 agent is then better able to acquire dynamic presence information 55 without relying on the presentity user agent. This also allows a 56 presentity user agent to delegate responsibility for managing 57 changing presence data to the source of that information. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Geolocation Protocols Relationship . . . . . . . . . . . . 4 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 64 2. Indirect Presence Publish . . . . . . . . . . . . . . . . . . 6 65 2.1. Multiple Presence Sources . . . . . . . . . . . . . . . . 6 66 3. Location header . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Indicating and Requiring Support of Indirect Publish . . . . . 8 68 5. De-reference Errors . . . . . . . . . . . . . . . . . . . . . 8 69 6. The Geolocation Header . . . . . . . . . . . . . . . . . . . . 9 70 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 9. Security considerations . . . . . . . . . . . . . . . . . . . 13 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 75 10.2. Informational References . . . . . . . . . . . . . . . . . 14 76 Appendix A. Alternative Solutions Considered . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 The Session Initiation Protocol (SIP) [RFC3261] is extended by the 82 SIP-events [RFC3265] framework to provide subscriptions and 83 notifications of SIP events. One example of such event notification 84 mechanism is 'presence' and this presence information is carried in 85 Presence Information Data Format (PIDF) [RFC3863] documents. 87 Two sources of presence information have been established. The 88 presence agent might be able to acquire presence data independently, 89 or it might rely on the presentity user agent providing that 90 information. Use of the SIP PUBLISH method for the purpose of 91 informing the presence agent of state is described in RFC 3903 92 [RFC3903]. 94 Many existing elements of presence information, such as the Presence 95 Data Model [RFC4479], Rich Presence Extensions to PIDF (RPID) 96 [RFC4480], or the Contact Information to the Presence Information 97 Data Format (CIPID) [RFC4481], are acquired directly from the 98 presentity user agent. However, there are cases when the presentity 99 user agent is not the direct source of the presence information. 101 One such example is location information. A presentity user agent 102 might acquire location information from a Location Information Server 103 (LIS). Due to the dynamic nature of location information, a LIS 104 might provide location information by reference rather than value. 105 One of these cases occurs when a presentity user agent acquires its 106 own location information from a LIS using HELD 107 [I-D.ietf-geopriv-http-location-delivery]. A reference in the form 108 of a location URI allows the holder of the reference to obtain 109 location information at any time directly from the LIS. 111 This document describes a means for a presentity user agent to 112 publish presence information indirectly using a URI. The presence 113 agent is then able to obtain information directly from the source of 114 the data. This removes some of the burden of managing dynamic 115 content from the presentity user agent, as they do not need to 116 monitor changes to presence data and publish updates as changes 117 occur. 119 Presence agents might provide a complex presence document that is 120 assembled from multiple sources. A means is provided where the 121 presence agent is able to assemble a presence document. 123 The mechanism in this document was originally designed with location 124 information in mind, but it can be equally applied to any other form 125 of dynamic presence data. 127 1.1. Geolocation Protocols Relationship 129 [ED: move these pictures out of here. We need pictures that aren't 130 location-specific so that readers don't mistakenly think that this is 131 just about location. That's already compounded by using "Location", 132 so this needs to be very clear. Maybe this could be made an 133 appendix.] 135 The PIDF location object (PIDF-LO) [RFC4119] establishes location 136 information as a form of presence information. Therefore, a presence 137 agent might provide location information along with other information 138 such as status or mood ([RFC4480]). 140 A presence service commonly needs to rely on other entities to 141 provide it with location information. A presentity user agent might 142 be able to provide location information, or it might interact with a 143 Location Information Server (LIS) [I-D.ietf-geopriv-arch] to acquire 144 that information. 146 Figure 1 depicts the geolocation protocol relationship. A location 147 URI points to a resource on a LIS that is able to provide location of 148 a specific Target. The LIS is able to associate the Location URI to 149 the location of the Target inside its administrative domain. In this 150 case, the Target in question is the presentity user agent. 152 +-----------+ +------------+ 153 | | | Location | 154 | LIS | | Recipient/ | 155 | | | Presence | 156 | | | Agent | 157 +-----------+ +------------+ 158 ^ ^ ^ 159 | | // 160 Location | | Location // 161 Configuration| | Dereference // 162 Protocol | | Protocol // 163 (1) | | (2) // 164 | | // Location Conveyance 165 v v // Protocol (e.g., SIP) 166 +------------+ // (3) 167 | | // 168 | Target / | // 169 | Presentity |< 170 | | 171 +------------+ 173 Figure 1: Presence and Geolocation Protocols (Values) 175 The following three steps are followed in Figure 1: 176 (1). The presentity user agent (or Target) acquires a location URI 177 from the Location Information Server (LIS) using a Location 178 Configuration Protocol (LCP). 179 (2). Before publishing location information to the presence agent, 180 the target must first de-reference the location URI to acquire 181 a location value. Alternatively, location information might be 182 acquired from the LIS by value. 183 (3). Finally, the presentity user agent assembles an updated 184 presence document and publishes this to the presence agent. 186 A location URI [I-D.ietf-geopriv-lbyr-requirements] provides 187 additional flexibility that this process does not take advantage of. 188 A location URI provides a way for a location recipient to have 189 control over when and how location information is acquired. A 190 location URI can be used by the presence agent to acquire location 191 information according to the needs of the watchers that require the 192 information. 194 This document enables the scenario shown in Figure 2, where the 195 presentity user agent is able to acquire a location URI (step 1) and 196 publish the URI (step 2). The presence agent is then able to acquire 197 location information directly from the LIS (step 3). 199 +-----------+ +------------+ 200 | | Location | Location | 201 | LIS |<------------->| Recipient/ | 202 | | Dereference | Presence | 203 | | Protocol (3) | Agent | 204 +-----------+ +------------+ 205 ^ ^ 206 | // 207 | Location // 208 | Configuration // 209 | Protocol // 210 | (1) // 211 | // Location Conveyance 212 v // Protocol (e.g., SIP) 213 +-------------+ // (2) 214 | | // 215 | Target / | // 216 | Presentity |< 217 | | 218 +-------------+ 220 Figure 2: Presence and Geolocation Protocols (References) 222 1.2. Terminology 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in BCP 14, RFC 2119 227 [RFC2119]. 229 This document uses SIP events terminology from [RFC3265], presence 230 terminology from [RFC3903], and Geopriv terminology from 231 [I-D.ietf-geopriv-arch]. 233 2. Indirect Presence Publish 235 A presentity user agent first acquires a reference to presence 236 information in the form of a URI. 238 For location information, a location URI can be obtained using a 239 location configuration protocol, such as HELD 240 [I-D.ietf-geopriv-http-location-delivery]. For HELD, this is done 241 by including a "locationType" element with the value set to 242 "locationURI". 244 The presentity user agent then publishes the URI (or URIs) to a 245 presence agent, using the "Location" header (see Section 3). 247 This header is not specific to physical location information. Do 248 not confuse the "Location:" header with the "Geolocation:" header. 249 The former inherits its meaning from the HTTP [RFC2616] header of 250 the same name, the name being a logical location or address. The 251 latter is specifically restricted to physical location 252 information. 254 The presence agent de-references URIs to acquire the referenced 255 information. A "sip:", "sips:" or "pres:" URI is dereferenced by 256 subscribing for the presence event package at the given URI; a 257 "http:" or "https:" URI is dereferenced following the rules in 258 [I-D.winterbottom-geopriv-deref-protocol]. Other URIs MUST not be 259 used unless a method is defined for that URI that produces a presence 260 document. 262 2.1. Multiple Presence Sources 264 Indirect publish establishes multiple presence sources for a presence 265 agent. In addition to the presentity user agent, multiple indirect 266 sources of presence data can be identified using the "Location" 267 header. 269 The presence agent acquires presence information from each source. 270 This results in multiple presence documents. These documents are 271 combined to produce a single document. 273 The single presence document contains the union of the set of tuples 274 (or the [RFC4479] equivalents of "device" or "person") from every 275 presence document thus obtained. Tuple identifiers are modified as 276 necessary to prevent collisions in the identifier namespace; this 277 might be done be prefixing each tuple with the source identifier. 279 The presentity identifier in the final document is the presentity 280 identifier in any presence document provided by the presentity user 281 agent itself. Presentity identifiers from other sources are ignored. 283 The presence agent then monitors the state of the referenced presence 284 document according to the needs of watchers. The presence agent 285 updates its own copy of the presence data from each source. As 286 presence state provided by each source changes, this is combined with 287 data from other sources and watchers are notified accordingly. 289 A partial presence document [RFC5264] MAY be used if the presence 290 agent supports this format. In this case, partial differences 291 ("pidf-diff" documents) provided from a given source are applied the 292 information retrieved previously from the same source. 294 3. Location header 296 The "Location" header includes a URI for information that might 297 otherwise be included in the body of a request. It is defined by the 298 following ABNF [RFC5234], using the conventions and definitions in 299 [RFC3261]: 301 location-header = "Location" HCOLON location-header-value 302 location-value = (location-item *(COMMA location-item)) 303 location-item = LAQUOT location-URI RAQUOT 304 / *(SEMI location-param) 305 location-URI = absoluteURI 306 location-param = location-src-param / generic-param 307 location-src-param = "src" EQUAL token 309 This document defines the "Location" header field as valid in SIP 310 PUBLISH [RFC3903] requests only. 312 Each URI in the "Location" header MAY be tagged with a "src" 313 parameter, identifying the source of the data that is found at the 314 URI. This identifier is an opaque tag that is used to identify 315 different URIs as having the same source. An included URI with no 316 "src" parameter is considered to have a different "src" parameter to 317 any other included URI. URIs with identical "src" parameters 318 indicate that they are alternative URIs (possibly with different 319 schemes) for the same information. 321 A presence agent MUST only attempt to use a single URI from each set 322 with a unique "src" parameter. Presence information from any given 323 URI can only be updated or replaced with presence information from a 324 URI with the same "src" parameter. 326 Each PUBLISH message contains a complete set of URIs. The presence 327 agent MUST NOT use a URI if the most recent "Location" header 328 received does not include that URI. The "Location" header can be 329 omitted in a request, which does not alter the set of URIs used by 330 the presence agent. Providing an empty "Location" header stops the 331 presence agent from using any URIs. 333 4. Indicating and Requiring Support of Indirect Publish 335 A SIP option tag of "indirectpub" is created for use in the "Require" 336 header. This is used by a presentity user agent to provide surety 337 that any request to indirectly publish presence data has been 338 understood by the presence agent. 340 Attempts to publish indirectly MUST use this option tag in the 341 "Require" header. If an attempt to publish information indirectly 342 fails, the presence agent includes the tag in the "Unsupported" 343 header of a 420 (Bad Extension) response. Upon receiving this 344 response, the presentity user agent SHOULD attempt to de-reference 345 the URI and re-attempt the request with the presence information 346 included directly unless it is unable or local policy dictates 347 otherwise. 349 5. De-reference Errors 351 Indirect publish adds an additional de-reference step to the publish 352 process. This adds additional failure scenarios. The presence agent 353 might be unable to de-reference a URI for a number of reasons: 354 o the indicated host might be unreachable 355 o the URI might be badly formed or it might refer to a non-existent 356 destination 357 o the URI schemes - and the de-reference mechanisms they indicate - 358 provided might not be supported by the presence agent 359 o the URI might produce information that is not presence data 360 o the presence agent might not be authorized to retrieve the 361 indicated data and the de-reference request might be rejected by 362 the server 364 Some of these errors might be detected during the processing of the 365 request. Others might be encountered later by the presence agent. A 366 mechanism is provided to indicate to the presentity user agent when 367 the presence agent detects an error while processing the request. 369 [TBD: need to work out how to do this. Either way, it's almost 370 essential to indicate to the presentity user agent that something has 371 failed. There are many reasons that a URI might not be accessible, 372 in many cases, it might be useful if the presentity user agent could 373 fall back on providing information by value if the URI can't be used. 374 It might be that the presentity user agent is more able to 375 dereference the URI, or might be able to look for alternative sources 376 for the information.] 378 [The lessons of the Geolocation header might be of some use here.] 380 6. The Geolocation Header 382 [ED: Useful? Unnecessary complication? Initial inclination is 383 toward the latter.] 385 A presence agent MAY choose to treat a Geolocation header 386 [I-D.ietf-sipcore-location-conveyance] in a PUBLISH request as though 387 it were a "Location" header. The "Require" header of the request 388 MUST include "indirectpub" in this case; if it does not, the presence 389 agent cannot assume that the information was intended to be 390 published. 392 The contents of the "Geolocation" header MUST be ignored if a 393 "Location" header is present. 395 7. Example 397 In the Figure 3, the presentity user agent (PUA) acquires and 398 publishes a reference to presence data that is served by a presence 399 source (PS). The presence agent (PA) provides this information to a 400 watcher along with information included by the presentity user agent. 401 Only request messages are shown for clarity. 403 PUA PS PA WATCHER 404 | | | | 405 |<-- Acquire -->| |<-- Establish -->| 406 | Reference | | Subscription | 407 | | | | 408 |------- M1: Publish Reference ----->| | 409 | | | | 410 | |<-- M2: Subscribe --| | 411 | | | | 412 | |--- M3: Notify ---->| | 413 | | | | 414 | | |-- M4: Notify -->| 415 | | | | 416 | | ... | | 417 | | | | 418 | |----- Notify ------>| | 419 | | | | 420 | | |---- Notify ---->| 421 | | | | 422 . . . . 424 Figure 3 426 A presentity user agent acquires a URI that refers to presence 427 information. In this example, it is also assumed that the watcher 428 has also established a subscription. 430 The presentity user agent publishes this information to a presence 431 agent. The SIP PUBLISH might also include information that the 432 presentity user agent directly provides, such as the status. 434 M1: 435 PUBLISH sip:presentity@example SIP/2.0 436 To: 437 From: ;tag=1234wxyz 438 Call-ID: 81818181@pua.example 439 CSeq: 1 PUBLISH 440 Max-Forwards: 70 441 Event: presence 442 Location: ;src=abc123, 443 ;src=abc123 444 Contact: presentity@pua.example 445 Content-Type: application/pidf+xml 446 Content-Length: ... 448 449 461 From: ;tag=4567qwer 462 Call-ID: 111222@example 463 CSeq: 1 SUBSCRIBE 464 Max-Forwards: 70 465 Event: presence 466 Expires: 3600 467 Contact: sip:pa.example 468 Content-Length: 0 470 The presence source provides a notification containing presence 471 information selects one location from each source and de-references 472 this URI. For a SIP URI ("sip:", "sips:", or "pres:") this requires 473 a presence event package subscription. 475 M3: 476 NOTIFY pa.example SIP/2.0 477 To: 478 From: ;tag=7678fghj 479 Call-ID: 111222@example 480 CSeq: 1 NOTIFY 481 Max-Forwards: 70 482 Event: presence 483 Subscription-State: active; expires=3599 484 Contact: sip:source.example 485 Content-Type: application/pidf+xml 486 Content-Length: ... 488 489 490 491 492 494 The presence agent then provides a notification to the watcher with 495 this new presence data. 497 M4: 498 NOTIFY watcher@example SIP/2.0 499 To: 500 From: ;tag=asd234 501 Call-ID: 789678@example 502 CSeq: 1 NOTIFY 503 Max-Forwards: 70 504 Event: presence 505 Subscription-State: active; expires=3207 506 Contact: sip:pa.example 507 Content-Type: application/pidf+xml 508 Content-Length: ... 510 511 515 516 517 519 From this point, changes in presence state at the source trigger 520 notifications to the presence agent. This in turn triggers 521 notifications to any watchers. 523 8. IANA Considerations 525 TBD: register SIP header, "indirectpub" option tag and establish 526 parameter registry (pah). 528 9. Security considerations 530 The security considerations described in SIP Location Conveyance 531 [I-D.ietf-sip-location-conveyance]are applicable to this document. 533 Privacy protections are extremely important for presence information. 534 Indirect publish potentially provides watchers and presence agents 535 greater access to a user's private data. A presence source 537 10. References 539 10.1. Normative References 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, March 1997. 544 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 545 A., Peterson, J., Sparks, R., Handley, M., and E. 546 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 547 June 2002. 549 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 550 Event Notification", RFC 3265, June 2002. 552 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 553 Specifications: ABNF", STD 68, RFC 5234, January 2008. 555 [I-D.winterbottom-geopriv-deref-protocol] 556 Winterbottom, J., Tschofenig, H., Schulzrinne, H., 557 Thomson, M., and M. Dawson, "A Location Dereferencing 558 Protocol Using HELD", 559 draft-winterbottom-geopriv-deref-protocol-04 (work in 560 progress), July 2009. 562 [I-D.ietf-sipcore-location-conveyance] 563 Polk, J. and B. Rosen, "Location Conveyance for the 564 Session Initiation Protocol", 565 draft-ietf-sipcore-location-conveyance-01 (work in 566 progress), July 2009. 568 10.2. Informational References 570 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 571 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 572 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 574 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 575 W., and J. Peterson, "Presence Information Data Format 576 (PIDF)", RFC 3863, August 2004. 578 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 579 for Event State Publication", RFC 3903, October 2004. 581 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 582 Format", RFC 4119, December 2005. 584 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 585 July 2006. 587 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 588 Rosenberg, "RPID: Rich Presence Extensions to the Presence 589 Information Data Format (PIDF)", RFC 4480, July 2006. 591 [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the 592 Presence Information Data Format (PIDF) to Indicate Status 593 Information for Past and Future Time Intervals", RFC 4481, 594 July 2006. 596 [RFC5264] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of 597 Partial Presence Information", RFC 5264, September 2008. 599 [W3C.REC-xml-20060816] 600 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Maler, E., 601 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth 602 Edition)", World Wide Web Consortium FirstEdition REC-xml- 603 20060816, August 2006, 604 . 606 [W3C.REC-xmlschema-0-20041028] 607 Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer 608 Second Edition", World Wide Web Consortium 609 Recommendation REC-xmlschema-0-20041028, October 2004, 610 . 612 [I-D.ietf-sip-location-conveyance] 613 Polk, J. and B. Rosen, "Location Conveyance for the 614 Session Initiation Protocol", 615 draft-ietf-sip-location-conveyance-13 (work in progress), 616 March 2009. 618 [I-D.ietf-geopriv-http-location-delivery] 619 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 620 "HTTP Enabled Location Delivery (HELD)", 621 draft-ietf-geopriv-http-location-delivery-16 (work in 622 progress), August 2009. 624 [I-D.ietf-geopriv-lbyr-requirements] 625 Marshall, R., "Requirements for a Location-by-Reference 626 Mechanism", draft-ietf-geopriv-lbyr-requirements-08 (work 627 in progress), September 2009. 629 [I-D.ietf-geopriv-arch] 630 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 631 Tschofenig, H., and H. Schulzrinne, "An Architecture for 632 Location and Location Privacy in Internet Applications", 633 draft-ietf-geopriv-arch-00 (work in progress), July 2009. 635 Appendix A. Alternative Solutions Considered 637 [ED: this section is a mess; it should be cleaned up and moved to an 638 appendix.] 640 The following alternative solutions were considered in the design of 641 this solution: 642 1. Rather than using a header, additional SIP bodies could be 643 defined. This could be a PIDF extension, or a specialized 644 format. This has a number of advantages, particularly in terms 645 of good protocol hygiene. This potentially runs afoul of the shy 646 support for multipart MIME in SIP agents. As a PIDF extension, 647 it's possible that multipart support is not required, but it 648 would potentially be difficult to ensure that it is the presence 649 agent that is performing the de-reference. 650 2. Integration with partial presence publish [RFC5264] was 651 considered. Including a URI in a "pidf-diff" document would 652 provide an elegant way to integrate indirectly published data. 653 However, RFC 5264 defines a format that cannot be extended. The 654 scheme chosen also provides less flexibility and is consequently 655 significantly simpler. 656 3. It's possible that a mechanism is not necessary at all. Presence 657 sources could be given the information necessary to PUBLISH the 658 information. Mechanisms would need to be provided for this 659 purpose. Aside from the complexity of managing this 660 relationship, it does not benefit from the ability to use an 661 event-based subscription. It is also more difficult to ensure 662 that the presence source publishes when the presence agent (and 663 watchers) need the information. 664 4. The SIP Location Conveyance [I-D.ietf-sip-location-conveyance] 665 defines a Geolocation header field that could be used for 666 indirect publish. Limiting this solution to location information 667 would be a constraint that would prevent this from use for other 668 types of information. 670 Authors' Addresses 672 Miguel A. Garcia-Martin 673 Ericsson 674 Calle Via de los Poblados 13 675 Madrid, ES 28033 676 Spain 678 Email: miguel.a.garcia@ericsson.com 680 Hannes Tschofenig 681 Nokia Siemens Networks 682 Otto-Hahn-Ring 6 683 Munich, Bavaria 81739 684 Germany 686 Email: Hannes.Tschofenig@gmx.net 687 URI: http://www.tschofenig.priv.at 689 Henning Schulzrinne 690 Columbia University 691 Department of Computer Science 692 450 Computer Science Building 693 New York, NY 10027 694 USA 696 Phone: +1 212 939 7042 697 Email: schulzrinne@cs.columbia.edu 698 URI: http://www.cs.columbia.edu/~hgs 699 Martin Thomson 700 Andrew Corporation 701 PO Box U40 702 University of Wollongong, NSW 2500 703 AU 705 Phone: +61 242 212915 706 Email: martin.thomson@andrew.com 707 URI: http://www.andrew.com/