idnits 2.17.1 draft-tschofenig-ecrit-xmpp-es-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (March 5, 2012) is 4434 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) == Outdated reference: A later version (-38) exists of draft-ietf-ecrit-additional-data-02 == Outdated reference: A later version (-22) exists of draft-ietf-ecrit-data-only-ea-02 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-psap-callback-03 == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-deref-protocol-04 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-local-civic-03 == Outdated reference: A later version (-08) exists of draft-ietf-geopriv-relative-location-02 ** Downref: Normative reference to an Informational RFC: RFC 5012 ** Downref: Normative reference to an Informational RFC: RFC 5194 ** Downref: Normative reference to an Informational RFC: RFC 5687 ** Downref: Normative reference to an Informational RFC: RFC 6443 == Outdated reference: A later version (-14) exists of draft-ietf-ecrit-trustworthy-location-02 == Outdated reference: A later version (-05) exists of draft-saintandre-sip-xmpp-core-01 == Outdated reference: A later version (-03) exists of draft-saintandre-sip-xmpp-im-01 == Outdated reference: A later version (-02) exists of draft-saintandre-sip-xmpp-media-01 Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track March 5, 2012 5 Expires: September 6, 2012 7 Emergency Services Functionality with the Extensible Messaging and 8 Presence Protocol (XMPP) 9 draft-tschofenig-ecrit-xmpp-es-00.txt 11 Abstract 13 The Extensible Messaging and Presence Protocol (XMPP) is a technology 14 that enjoys widespread deployment in the instant messaging 15 application domain. While many features for XMPP had been 16 standardized in the IETF as well as in the XMPP Standards Foundation 17 emergency services functionality was not part of it. 19 This document aims to initiate a discussion about the necessary 20 emergency services functionality for XMPP. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 6, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Interoperability Need . . . . . . . . . . . . . . . . . . . . 5 59 4. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Emergency Call Marking . . . . . . . . . . . . . . . . . . 7 61 4.2. Location . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.4. Voice and Video . . . . . . . . . . . . . . . . . . . . . 9 64 4.5. Real-Time Text . . . . . . . . . . . . . . . . . . . . . . 9 65 4.6. PSAP Callback . . . . . . . . . . . . . . . . . . . . . . 9 66 4.7. Additional Data . . . . . . . . . . . . . . . . . . . . . 10 67 4.8. Data Only Emergency Calls . . . . . . . . . . . . . . . . 10 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 72 7.2. Informational References . . . . . . . . . . . . . . . . . 15 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 1. Introduction 77 The Extensible Messaging and Presence Protocol (XMPP) is a technology 78 for real-time communication over the Internet that uses the 79 Extensible Markup Language (XML) as the base format for exchanging 80 information. XMPP provides a way to send small snippets of XML from 81 one communication entity to another one. XMPP has found usage in a 82 variety of protocols, but most people use it primarily for instant 83 messaging. 85 With the widespread usage of XMPP on the Internet for instant 86 messaging and the desire to offer multi-media emergency services 87 support, i.e., any form of emergency support that goes beyond voice 88 calling, a frequently asked question is those applications that 89 utilize XMPP today are able to offer emergency services support 90 similar to what had been standardized for the Session Initiation 91 Protocol (SIP) over the last 10 years. 93 XMPP has found widespread usage for instant messaging on the 94 Internet. At the same time there is an increasing interest to add 95 multi-media support to the emergency services portfolio. 96 Consequently, a frequently asked question by emergency services 97 professionals is whether applications utilizing XMPP today will be 98 able to offer emergency services support in the future as well. 99 Standardization activities have so far exclusively focused on the 100 Session Initiation Protocol (SIP). 102 The author believes that it is time to have a discussion about the 103 desired level of interoperability between XMPP and the standardized, 104 implemented and even deployed IP-based emergency services 105 infrastructure that is based on SIP. This document provides a first 106 discussion input. The main part of the document focuses on the 107 various components of the emergency services functionality. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 This document uses the terminology defined in [RFC5012]. 117 3. Interoperability Need 119 When deciding about the required emergency services functionality in 120 XMPP a decision has to be made about where to put the burden for 121 interoperability. There only seem to be two main options, which are 122 graphically shown in Figure 1 and Figure 2. 124 In Figure 1 the XMPP is used between the XMPP client and a XMPP 125 server run by some provider. Whenever the interaction with the 126 emergency services authorities are needed a gateway translates XMPP 127 to SIP very similar to how legacy protocols or proprietary protocols 128 are translated. While the exact placement placement of the XMPP-to- 129 SIP gateway does not matter from a protocol point of view deployment- 130 wise it does. Here we assume that the emergency services 131 infrastructure only supports a single protocol internally, namely 132 SIP. This is also inline with the current standardization situation. 134 ,-------. 135 ,'IP-based `. 136 .-----------. / Emergency \ 137 +------+ XMPP | Provider | | Services | 138 |XMPP |------->| .------- | | Network | 139 |Client| | |XMPP | | | | 140 +------+ | |Server | | | +------+ | 141 | '-------' | | |PSAP | | 142 | | | | +--+---+ | 143 | .---+---. | | | | 144 '-|Gateway|-' | | | 145 '---+---' | |SIP | 146 | | | | 147 |SIP | | | 148 | | | | 149 | | +--+---+ | 150 +-------------+-->|ESRP | | 151 | +------+ | 152 | | 153 \ / 154 `. ,' 155 '-------' 157 Figure 1: Backend Interoperability 159 The interworking between SIP and XMPP had been subject to earlier 160 investigations, as described in [I-D.saintandre-sip-xmpp-core], 161 [I-D.saintandre-sip-xmpp-media], and [I-D.saintandre-sip-xmpp-im]. 163 In Figure 2 we show a deployment where XMPP is used end-to-end and 164 the emergency services supports XMPP in addition to SIP. 166 ,-------. 167 ,'IP-based `. 168 / Emergency \ 169 .-----------. | Services | 170 | Provider | | Network | 171 +------+ | .-------. | | | 172 |XMPP | XMPP | |XMPP | | | +------+ | 173 |Client|------->| |Server | | | |PSAP | | 174 +------+ | '-------' | | +--+---+ | 175 | | | | | | 176 '----+------' | | | 177 | | |XMPP | 178 | | | | 179 |XMPP | | | 180 | | | | 181 +------+ | | +--+---+ | 182 |XMPP | XMPP +--------------+-->|ESRP | | 183 |Client|----------------------------+-->| | | 184 +------+ | +------+ | 185 \ / 186 `. ,' 187 '-------' 189 Figure 2: End-to-End Interoperability 191 Not shown in the figures above is the ability for combined SIP and 192 XMPP usage. Requirements for such interworking are described in 193 [I-D.veikkolainen-sip-xmpp-coex-reqs] and guidance is provided in 194 [I-D.veikkolainen-sip-voip-xmpp-im]. 196 4. Functionality 198 An important aspect in the support of emergency services in XMPP is 199 how far current XMPP features are equivalent to those offered by SIP. 200 For SIP [I-D.ietf-ecrit-phonebcp] describes the necessary 201 functionality for emergency calling on the Internet. A similar 202 specification is needed for XMPP. [I-D.ietf-ecrit-phonebcp], 203 however, relies on already defined functionality and 'glues' these 204 available building blocks together. The sub-sections below discuss 205 some of the most important building blocks. 207 4.1. Emergency Call Marking 209 In existing telecommunications systems, there are many well-known 210 communication and information services that are characterized by 211 long-term stability of user- visible identifiers, decentralized 212 administration of the underlying service, and a well-defined 213 resolution or mapping mechanism. [RFC5031] defines a URN namespace 214 that, together with resolution protocols, allows us to define global, 215 well-known services, while distributing the actual implementation 216 across a large number of service-providing entities. 218 [RFC5031] is not only used for marking SIP communication but it is 219 also used by various emergency components, such as the Location-to- 220 Service Translation (LoST) protocol. [RFC5031] also has to be 221 integrated into XMPP. 223 Part of the emergency call marking is also the ability to indicate a 224 test emergency call, as described in Section 15 of 225 [I-D.ietf-ecrit-phonebcp]. An equivalent feature is highly likely to 226 be useful for XMPP. 228 4.2. Location 230 The IETF has produced a fairly extensive set of location 231 specifications that are re-used for emergency services. The work 232 falls into various categories, as described in [RFC6280] and in 233 Section 6 of [RFC6443]. The requirements for obtaining high accuracy 234 location information are more complex for emergency services than 235 with commercial location applications due to the life critical nature 236 of the service. 238 Location Formats: 240 There are two main formats standardized for location information, 241 namely civic and geodetic location information. The core civic 242 location standard can be found in [RFC5139] and the profile for 243 geodetic information is available with [RFC5491]. [RFC5491] 244 supports a large set of location shapes. Various additional 245 extensions have been developed, such as the support for relative 246 location [I-D.ietf-geopriv-relative-location] and location civic 247 addresses [I-D.ietf-geopriv-local-civic]. It is also important to 248 mention that there have been efforts ongoing to map the civic 249 addresses in various countries to the PIDF-LO civic location 250 tokens, based on the recommendations in [RFC5774]. 252 Location Encoding: 254 There are mainly two encodings of location information, namely a 255 binary encoding, as for example used by DHCP location extensions, 256 and an XML-based encoding based on PIDF-LO [RFC4119]. Note that 257 the PIDF-LO element contains more than pure location data but also 258 provides information about the entity that constructed the 259 location object (based on the 'provided-by' element) and 260 supplementary data about the utilized location determination 261 technique (based on values from the 'method' token' IANA 262 registry). 264 Location Configuration Protocols: 266 A Location Configuration Protocol (LCP) [RFC5687] is one mechanism 267 that can be used by a device to discover its own location from a 268 LIS. Several LCPs have been developed within Geopriv, such as 269 [RFC5985]. LCPs obtain location information from location servers 270 and are therefore indirectly relevant for location conveyed within 271 XMPP. 273 Location Derefencing: 275 For location derefencing two protocols have been defined, namely 276 one based on HTTP [I-D.ietf-geopriv-deref-protocol] and another 277 one based on SIP which may use filters to reduce the number of 278 asynchronous notifications [RFC6447]. A session setup protocol 279 has to support the ability to convey these references. 281 Location Conveyance: 283 The ability to convey a PIDF-LO and a location by reference in SIP 284 had been defined by [RFC6442]. For a single call there may be 285 more than one location object in a call. 287 While there is a location extensions available in XMPP with XEP-0080 288 [XEP-0080] it is not equivalent to the functionality listed above. 289 XEP-0080 offers a different civic location format and geodetic 290 location based on a reduced set of loation shapes. It uses an XML 291 encoding and allows this information to be conveyed in XMPP. A table 292 with a mapping to the PIDF-LO semantic is provided in XEP-0080 but 293 unfortunately since the functionality is not equivalent to the list 294 presented above there will be a loss of information during the 295 lifecyle of location handling in most of the scenarios. 297 4.3. Routing 299 The LoST protocol [RFC5222] offers the ability to discover service 300 contact URIs based on provided service identifiers and location 301 information. In particular, it can be used to determine the 302 location-appropriate Public Safety Answering Point (PSAP) for 303 emergency services. During the design of LoST it was already 304 anticipated that service contact URIs based on a variety of different 305 protocols (not only SIP) will be needed. As such, XMPP is seamlessly 306 supported by LoST. 308 4.4. Voice and Video 310 With XEP-0166 [XEP-0166] the ability to initiate and manage peer-to- 311 peer media sessions between two XMPP entities in a way that is 312 interoperable with existing Internet standards had been defined. The 313 protocol enables the core session management semantics (compatible 314 with SIP) to be used for a wide variety of application types (e.g., 315 voice chat, video chat). 317 The ability for voice and video conference bridge as needed by 318 persons with disabilities for sign-language interpretation is, 319 however, not offered by Jingle. 321 4.5. Real-Time Text 323 RFC 5194 [RFC5194] defines the framework for Real-Time Text over IP. 324 All required functionality is based on SIP and the Real-Time 325 Transport Protocol (RTP). 327 XEP-0301 [XEP-0301] seems to offer functionality that is similar to 328 what had been defined by RFC 5194. 330 4.6. PSAP Callback 332 After an emergency call is completed it is possible that the call- 333 taker feels the need for further communication. For example, the 334 call may have been dropped by accident without the call- taker having 335 sufficient information about the current situation of a wounded 336 person. A call-taker may trigger a callback towards the emergency 337 caller using the contact informationprovided with the initial 338 emergency call, which includes the GRUU as well as the Address-of- 339 Record. This callback would be treated like any other call and as a 340 consequence it may get blocked by authorization policies or may get 341 forwarded to an answering machine. 343 The work on PSAP callback [I-D.ietf-ecrit-psap-callback] is an 344 ongoing effort to give these calls preferential treatment so that the 345 callback has a higher success in reaching the original emergency 346 call. 348 This functionality does not exist for XMPP yet. 350 4.7. Additional Data 352 The Internet Protocol suite offers a rich information exchange and 353 thereby better situational awareness for call takers and first 354 responders. The richness comes in various forms, including the 355 multi-media communication capabilities (via voice, video, instant 356 messaging, and real-time text), but also via more additional data 357 made available by various actors of the emergency signaling chain. 358 Sharing information between various actors will enable more 359 intelligent decision making and therefore better response in case of 360 an emergency. 362 In the SIP environment additional data had been provided in various 363 ways, as described in [I-D.ietf-ecrit-additional-data], and the same 364 capabilities will have to be provided in XMPP as well. 366 4.8. Data Only Emergency Calls 368 Data-only emergency calls are similar to regular emergency calls in 369 the sense that they require emergency call routing functionality and 370 may even have the same location requirements. On the other hand, the 371 communication interaction occurs without establishment of a voice or 372 video channel. 374 As a technical mechanism a Common Alert Protocol (CAP) payload is 375 pushed by the SIP User Agent towards the PSAP, as described in 376 [I-D.ietf-ecrit-data-only-ea]. The ability to push CAP payloads is 377 also available in XMPP with XEP-0127 [XEP-0127]. 379 5. Security Considerations 381 This document focuses on the integration of emergency services 382 functionality into XMPP. Offering security features for emergency 383 calls is both important but also challenging as security failures 384 (such as expired certificates) may have fatal effects. SIP offers a 385 secure identity mechanism as well as media security. Functionality 386 for these two areas are specified in [I-D.ietf-ecrit-phonebcp]. 387 Offering a solid mechanisms for identification of the persons seeking 388 help is important for the overal security of the emergency services 389 system, as described in [I-D.ietf-ecrit-trustworthy-location]. 391 6. Acknowledgements 393 The author would like to thank the members of the European Emergency 394 Number Association (EENA) Next Generation 112 technical committee and 395 the National Emergency Number Association (NENA) Long-Term Definition 396 working group for their discussions around XMPP emergency services 397 support. 399 7. References 401 7.1. Normative References 403 [I-D.ietf-ecrit-additional-data] 404 Rosen, B., Tschofenig, H., and R. Marshall, "Additional 405 Data related to an Emergency Call", 406 draft-ietf-ecrit-additional-data-02 (work in progress), 407 October 2011. 409 [I-D.ietf-ecrit-data-only-ea] 410 Rosen, B., Schulzrinne, H., and H. Tschofenig, "Common 411 Alerting Protocol (CAP) based Emergency Alerts using the 412 Session Initiation Protocol (SIP)", 413 draft-ietf-ecrit-data-only-ea-02 (work in progress), 414 July 2011. 416 [I-D.ietf-ecrit-phonebcp] 417 Rosen, B. and J. Polk, "Best Current Practice for 418 Communications Services in support of Emergency Calling", 419 draft-ietf-ecrit-phonebcp-20 (work in progress), 420 September 2011. 422 [I-D.ietf-ecrit-psap-callback] 423 Holmberg, C., Tschofenig, H., Schulzrinne, H., and M. 424 Patel, "Public Safety Answering Point (PSAP) Callback", 425 draft-ietf-ecrit-psap-callback-03 (work in progress), 426 October 2011. 428 [I-D.ietf-geopriv-deref-protocol] 429 Thomson, M., Dawson, M., Winterbottom, J., Tschofenig, H., 430 and H. Schulzrinne, "A Location Dereferencing Protocol 431 Using HELD", draft-ietf-geopriv-deref-protocol-04 (work in 432 progress), October 2011. 434 [I-D.ietf-geopriv-local-civic] 435 Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 436 R. George, "Specifying Civic Address Extensions in 437 PIDF-LO", draft-ietf-geopriv-local-civic-03 (work in 438 progress), February 2012. 440 [I-D.ietf-geopriv-relative-location] 441 Thomson, M., Stanley, D., Rosen, B., Thomson, A., and G. 442 Bajko, "Relative Location Representation", 443 draft-ietf-geopriv-relative-location-02 (work in 444 progress), October 2011. 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 450 Format", RFC 4119, December 2005. 452 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 453 Emergency Context Resolution with Internet Technologies", 454 RFC 5012, January 2008. 456 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 457 Emergency and Other Well-Known Services", RFC 5031, 458 January 2008. 460 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 461 Format for Presence Information Data Format Location 462 Object (PIDF-LO)", RFC 5139, February 2008. 464 [RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text 465 over IP Using the Session Initiation Protocol (SIP)", 466 RFC 5194, June 2008. 468 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 469 Tschofenig, "LoST: A Location-to-Service Translation 470 Protocol", RFC 5222, August 2008. 472 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 473 Presence Information Data Format Location Object (PIDF-LO) 474 Usage Clarification, Considerations, and Recommendations", 475 RFC 5491, March 2009. 477 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 478 Location Configuration Protocol: Problem Statement and 479 Requirements", RFC 5687, March 2010. 481 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 482 Addresses in the Presence Information Data Format Location 483 Object (PIDF-LO): Guidelines and IANA Registry 484 Definition", BCP 154, RFC 5774, March 2010. 486 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 487 RFC 5985, September 2010. 489 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 490 Tschofenig, H., and H. Schulzrinne, "An Architecture for 491 Location and Location Privacy in Internet Applications", 492 BCP 160, RFC 6280, July 2011. 494 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 495 for the Session Initiation Protocol", RFC 6442, 496 December 2011. 498 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 499 "Framework for Emergency Calling Using Internet 500 Multimedia", RFC 6443, December 2011. 502 [RFC6447] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 503 Location Notifications in the Session Initiation Protocol 504 (SIP)", RFC 6447, January 2012. 506 7.2. Informational References 508 [I-D.ietf-ecrit-trustworthy-location] 509 Tschofenig, H., Schulzrinne, H., and B. Aboba, 510 "Trustworthy Location Information", 511 draft-ietf-ecrit-trustworthy-location-02 (work in 512 progress), May 2011. 514 [I-D.saintandre-sip-xmpp-core] 515 Saint-Andre, P., Houri, A., and J. Hildebrand, 516 "Interworking between the Session Initiation Protocol 517 (SIP) and the Extensible Messaging and Presence Protocol 518 (XMPP): Core", draft-saintandre-sip-xmpp-core-01 (work in 519 progress), March 2009. 521 [I-D.saintandre-sip-xmpp-im] 522 Saint-Andre, P., Houri, A., and J. Hildebrand, 523 "Interworking between the Session Initiation Protocol 524 (SIP) and the Extensible Messaging and Presence Protocol 525 (XMPP): Instant Messaging", 526 draft-saintandre-sip-xmpp-im-01 (work in progress), 527 March 2009. 529 [I-D.saintandre-sip-xmpp-media] 530 Saint-Andre, P., "Interworking between the Session 531 Initiation Protocol (SIP) and the Extensible Messaging 532 and Presence Protocol (XMPP): Media Sessions", 533 draft-saintandre-sip-xmpp-media-01 (work in progress), 534 March 2009. 536 [I-D.veikkolainen-sip-voip-xmpp-im] 537 Veikkolainen, S. and M. Isomaki, "Guidelines and Protocol 538 Extensions for Combining SIP Based Real-time Media 539 Sessions With XMPP Based Instant Messaging and Presence 540 Service.", draft-veikkolainen-sip-voip-xmpp-im-01 (work in 541 progress), July 2009. 543 [I-D.veikkolainen-sip-xmpp-coex-reqs] 544 Veikkolainen, S. and M. Isomaki, "Requirements and Use 545 Cases for Combining SIP Based Real-time Media Sessions 546 With XMPP Based Instant Messaging and Presence Service.", 547 draft-veikkolainen-sip-xmpp-coex-reqs-02 (work in 548 progress), January 2011. 550 [XEP-0080] 551 Hildebrand, J. and P. Saint-Andre, "User Location", XSF 552 XEP 0080, September 2009. 554 [XEP-0127] 555 Saint-Andre, P. and B. Fletcher, "Common Alerting Protocol 556 (CAP) Over XMPP", XSF XEP 0127, December 2004. 558 [XEP-0166] 559 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 560 S., and J. Hildebrand, "Jingle", XSF XEP 0166, 561 December 2009. 563 [XEP-0301] 564 Rejhon, M., "In-Band Real Time Text", XSF XEP 0301, 565 June 2011. 567 Author's Address 569 Hannes Tschofenig 570 Nokia Siemens Networks 571 Linnoitustie 6 572 Espoo 02600 573 Finland 575 Phone: +358 (50) 4871445 576 Email: Hannes.Tschofenig@gmx.net 577 URI: http://www.tschofenig.priv.at