idnits 2.17.1 draft-saintandre-sip-xmpp-core-05.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 : ---------------------------------------------------------------------------- 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 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 (June 13, 2013) is 3962 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 423 ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 6122 (Obsoleted by RFC 7622) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-6122bis-07 -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track A. Houri 5 Expires: December 15, 2013 IBM 6 J. Hildebrand 7 Cisco Systems, Inc. 8 June 13, 2013 10 Interworking between the Session Initiation Protocol (SIP) and the 11 Extensible Messaging and Presence Protocol (XMPP): Addresses and Error 12 Conditions 13 draft-saintandre-sip-xmpp-core-05 15 Abstract 17 As a foundation for the definition of bidirectional protocol mappings 18 between the Session Initiation Protocol (SIP) and the Extensible 19 Messaging and Presence Protocol (XMPP), this document specifies the 20 architectural assumptions underlying such mappings as well as the 21 mapping of addresses and error conditions. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 15, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Architectural Assumptions . . . . . . . . . . . . . . . . . . 3 60 4. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Local Part Mapping . . . . . . . . . . . . . . . . . . . . 6 63 4.3. Instance-Specific Mapping . . . . . . . . . . . . . . . . 7 64 4.4. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.5. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Error Condition Mapping . . . . . . . . . . . . . . . . . . . 9 67 5.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 The IETF has worked on two signalling technologies that can be used 80 for multimedia session negotiation, messaging, presence, capabilities 81 discovery, notifications, and other application-level functionality: 83 o The Session Initiation Protocol [RFC3261], along with various SIP 84 extensions developed within the SIP for Instant Messaging and 85 Presence Leveraging Extensions (SIMPLE) Working Group. 86 o The Extensible Messaging and Presence Protocol [RFC6120], along 87 with various XMPP extensions developed by the IETF as well as by 88 the XMPP Standards Foundation. 90 Because these technologies are widely deployed, it is important to 91 clearly define mappings between them for the sake of interworking. 92 This document inaugurates a series of SIP-XMPP interworking 93 specifications by defining the architectural assumptions underlying 94 such mappings as well as the mapping of addresses and error 95 conditions. 97 The discussion venue for this document is the mailing list of the 98 DISPATCH WG; visit https://www.ietf.org/mailman/listinfo/dispatch for 99 subscription information and discussion archives. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 [RFC2119]. 108 3. Architectural Assumptions 110 Protocol translation between SIP and XMPP could occur in a number of 111 different entities, depending on the architecture of real-time 112 communication deployments. For example, protocol translation could 113 occur within a multi-protocol server (which uses application-specific 114 connection managers to initiate traffic to and accept traffic from 115 clients or other servers natively using SIP/SIMPLE, XMPP, etc.), 116 within a multi-protocol client (which enables a user to establish 117 connections natively with various servers using SIP/SIMPLE, XMPP, 118 etc.), or within a gateway that acts as a dedicated protocol 119 translator (which takes one protocol as input and provides another 120 protocol as output). 122 This document assumes that the protocol translation will occur within 123 a gateway. (This assumption not meant to discourage protocol 124 translation within multi-protocol clients or servers; instead, this 125 assumption is followed mainly to clarify the discussion and examples 126 so that the protocol translation principles can be more easily 127 understood and can be applied by client and server implementors with 128 appropriate modifications to the examples and terminology.) 129 Specifically, we assume that the protocol translation will occur 130 within an "XMPP-to-SIP gateway" that translates XMPP syntax and 131 semantics on behalf of an XMPP service when communicating with SIP 132 services and/or within a "SIP-to-XMPP gateway" that translates SIP 133 syntax and semantics on behalf of a SIP service when communicating 134 with XMPP services (naturally, these logical functions could occur in 135 one and the same actual translator). 137 This document assumes that a gateway will translate directly from one 138 protocol to the other. For the sake of the examples, we further 139 assume that protocol translation will occur within a gateway in the 140 source domain, so that information generated by the user of an XMPP 141 service will be translated by a gateway within the trust domain of 142 that XMPP service, and information generated by the user of a SIP 143 service will be translated by a gateway within the trust domain of 144 that SIP service. However, nothing in this document ought to be 145 taken as recommending against protocol translation at the destination 146 domain. 148 An architectural diagram for a possible gateway deployment is shown 149 below, where the entities have the following significance and the "#" 150 character is used to show the boundary of a trust domain: 152 o romeo@example.net -- a SIP user. 153 o example.net -- a SIP service with a gateway ("GW") to XMPP. 154 o juliet@example.com -- an XMPP user. 155 o example.com -- an XMPP service with a gateway ("GW") to SIP. 157 ##@####################################################### 158 # # # 159 # +-------------+----+ # +----+-------------+ # 160 # | example.net | GW |---#---| GW | example.com | # 161 # +-------------+----+ # +----+-------------+ # 162 # | # | # 163 # romeo@example.net # juliet@example.com # 164 # # # 165 ########################################################## 167 4. Address Mapping 169 4.1. Overview 171 The basic SIP address format is a "sip:" or "sips:" URI as specified 172 in [RFC3261]. When a SIP entity supports extensions for instant 173 messaging it might be identified by an 'im:' URI as specified in the 174 Common Profile for Instant Messaging [RFC3860] (see [RFC3428]) and 175 when a SIP entity spports extensions for presence it might be 176 identified by a 'pres:' URI as specified in the Common Profile for 177 Presence [RFC3859] (see [RFC3856]). 179 The XMPP address format is specified in [RFC6122]; as discussed in 180 [RFC6121], instant messaging and presence applications of XMPP also 181 need to support 'im:' and 'pres:' URIs as specified in [RFC3860] and 182 [RFC3859] respectively, although such support might simply involve 183 leaving resolution of such addresses up to an XMPP server. 185 In this document we primarily describe mappings for addresses of the 186 form ; however, we also provide guidelines for mapping 187 the addresses of specific user agent instances, which take the form 188 of Globally Routable User Agent URIs (GRUUs) in SIP and 189 "resourceparts" in XMPP. Mapping of protocol-specific identifiers 190 (such as telephone numbers) is out of scope for this specification. 191 In addition, we have ruled the mapping of domain names as out of 192 scope for now since that is a matter for the Domain Name System; 193 specifically, the issue for interworking between SIP and XMPP relates 194 to the translation of fully internationalized domain names (IDNs) 195 into non-internationalized domain names (IDNs are not allowed in the 196 SIP address format, but are allowed in the XMPP address via 197 Internationalized Domain Names in Applications, see [RFC6122] and 198 [I-D.ietf-xmpp-6122bis]). Therefore, in the following sections we 199 focus primarily on the local part of an address (these are called 200 variously "usernames", "instant inboxes", "presentities", and 201 "localparts" in the protocols at issue), secondarily on the instance- 202 specific part of an address, and not at all on the domain-name part 203 of an address. 205 The sip:/sips:, im:/pres:, and XMPP address schemes allow different 206 sets of characters (although all three allow alphanumeric characters 207 and disallow both spaces and control characters). In some cases, 208 characters allowed in one scheme are disallowed in others; these 209 characters need to be mapped appropriately in order to ensure 210 interworking across systems. 212 4.2. Local Part Mapping 214 The local part of a sip:/sips: URI inherits from the "userinfo" rule 215 in [RFC3986] with several changes; here we discuss the SIP "user" 216 rule only: 218 user = 1*( unreserved / escaped / user-unreserved ) 219 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 220 unreserved = alphanum / mark 221 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 222 / "(" / ")" 224 Here we make the simplifying assumption that the local part of an 225 im:/pres: URI inherits from the "dot-atom-text" rule in [RFC5322] 226 rather than the more complicated "local-part" rule: 228 dot-atom-text = 1*atext *("." 1*atext) 229 atext = ALPHA / DIGIT / ; Any character except 230 "!" / "#" / "$" / ; controls, SP, and 231 "%" / "&" / "'" / ; specials. Used for 232 "*" / "+" / "-" / ; atoms. 233 "/" / "=" / "?" / 234 "^" / "_" / "`" / 235 "{" / "|" / "}" / 236 "~" 238 The local part of an XMPP address allows any ASCII character except 239 space, controls, and the " & ' / : < > @ characters. 241 To summarize the foregoing information, the following table lists the 242 allowed and disallowed characters in the local part of identifiers 243 for each protocol (aside from the alphanumeric, space, and control 244 characters), in order by hexadecimal character number (where each "A" 245 row shows the allowed characters and each "D" row shows the 246 disallowed characters). 248 Table 1: Allowed and disallowed characters 250 +---+----------------------------------+ 251 | SIP/SIPS CHARACTERS | 252 +---+----------------------------------+ 253 | A | ! $ &'()*+,-./ ; = ? _ ~ | 254 | D | "# % : < > @[\]^ `{|} | 255 +---+----------------------------------+ 256 | IM/PRES CHARACTERS | 257 +---+----------------------------------+ 258 | A | ! #$%&' *+ - / = ? ^_`{|}~ | 259 | D | " () , . :;< > @[\] | 260 +---+----------------------------------+ 261 | XMPP CHARACTERS | 262 +---+----------------------------------+ 263 | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | 264 | D | " &' /: < > @ | 265 +---+----------------------------------+ 267 When transforming the local part of an address from one scheme to 268 another, an application SHOULD proceed as follows: 270 1. Unescape any escaped characters in the source address (e.g., from 271 SIP to XMPP unescape "%2F" to "/" and from XMPP to SIP unescape 272 "\27" to "'"). 273 2. Leave unmodified any characters that are allowed in the 274 destination scheme. 275 3. Escape any characters that are allowed in the source scheme but 276 reserved in the destination scheme, as escaping is defined for 277 the destination scheme. In particular: 278 * Where the destination scheme is a URI (i.e., an im:, pres:, 279 sip:, or sips: URI), each reserved character MUST be percent- 280 encoded to "%hexhex" as specified in Section 2.6 of [RFC4395] 281 (e.g., when transforming from XMPP to SIP, encode "/" as 282 "%2F"). 283 * Where the destination scheme is a native XMPP address, each 284 reserved character MUST be encoded to "\hexhex" as specified 285 in [XEP-0106] (e.g., when transforming from SIP to XMPP, 286 encode "'" as "\27"). 288 4.3. Instance-Specific Mapping 290 The meaning of a resourcepart in XMPP (i.e., the portion of a JID 291 after the slash character, such as "foo" in "user@example.com/foo") 292 matches that of a Globally Routable User Agent URI (GRUU) in SIP 293 [RFC5627]. In both cases, these constructs identify a particular 294 device associated with the bare JID ("localpart@domainpart") of an 295 XMPP entity or with the Address of Record (AOR) of a SIP entity. 297 Therefore, it is reasonable to map the value of a "gr" URI parameter 298 to an XMPP resource part, and vice-versa. 300 Note that the "gr" URI parameter in SIP can contain only characters 301 from the ASCII range, whereas an XMPP resourcepart can contain nearly 302 any Unicode character [UNICODE]. Therefore Unicode characters 303 outside the ASCII range need to be mapped to characters in the ASCII 304 range, as described below. 306 4.4. SIP to XMPP 308 The following is a high-level algorithm for mapping a sip:, sips:, 309 im:, or pres: URI to an XMPP address: 311 1. Remove URI scheme. 312 2. Split at the first '@' character into local part and hostname 313 (mapping the latter is out of scope). 314 3. Translate any percent-encoded strings ("%hexhex") to percent- 315 decoded octets. 316 4. Treat result as a UTF-8 string. 317 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" 318 respectively in order to properly handle the characters 319 disallowed in XMPP addresses but allowed in sip:/sips: URIs and 320 im:/pres: URIs as shown in Table 1 above (this is consistent with 321 [XEP-0106]). 322 6. Apply Nodeprep profile of Stringprep [RFC3454] or its replacement 323 (see [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization 324 (OPTIONAL). 325 7. Recombine local part with mapped hostname to form a bare JID 326 ("localpart@domainpart"). 327 8. If the (SIP) address contained a "gr" URI parameter, append a 328 slash character "/" and the "gr" value to the bare JID to form a 329 full JID ("localpart@domainpart/resourcepart"). 331 4.5. XMPP to SIP 333 The following is a high-level algorithm for mapping an XMPP address 334 to a sip:, sips:, im:, or pres: URI: 336 1. Split XMPP address into localpart (mapping described in remaining 337 steps), domainpart (hostname; mapping is out of scope), and 338 resourcepart (specifier for particular device or connection, for 339 which an OPTIONAL mapping is described below). 340 2. Apply Nodeprep profile of [RFC3454] or its replacement (see 341 [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization of 342 the XMPP localpart (OPTIONAL). 344 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" 345 respectively (this is consistent with [XEP-0106]). 346 4. Determine if the foreign domain supports im: and pres: URIs 347 (discovered via [RFC2782] lookup as specified in [RFC6121]), else 348 assume that the foreign domain supports sip:/sips: URIs. 349 5. If converting into im: or pres: URI, for each byte, if the byte 350 is in the set (),.;[\] or is a UTF-8 character outside the ASCII 351 range then percent-encode that byte to "%hexhex" format. If 352 converting into sip: or sips: URI, for each byte, if the byte is 353 in the set #%[\]^`{|} or is a UTF-8 character outside the ASCII 354 range then percent-encode that byte to "%hexhex" format. 355 6. Combine resulting local part with mapped hostname to form 356 local@domain address. 357 7. Prepend with 'im:' scheme (for XMPP stanzas) or 358 'pres:' scheme (for XMPP stanzas) if foreign domain 359 supports these, else prepend with 'sip:' or 'sips:' scheme 360 according to local service policy. 361 8. If the XMPP address included a resourcepart and the destination 362 URI scheme is 'sip:' or 'sips:', optionally append the slash 363 character '/' and then append the resourcepart (making sure to 364 percent-encode any UTF-8 characters outside the ASCII range) as 365 the "gr" URI parameter. 367 5. Error Condition Mapping 369 SIP response codes are specified in [RFC3261] and XMPP error 370 conditions are specified in [RFC6120]. Because there is no 371 equivalent in XMPP for the provisional (1xx) and successful (2xx) 372 response codes in SIP, mappings are provided only for the redirection 373 (3xx), request failure (4xx), server failure (5xx), and glogal 374 failure (6xx) codes. 376 5.1. XMPP to SIP 378 Table 8: Mapping of XMPP error conditions to SIP response codes 380 +------------------------------+---------------------+ 381 | XMPP Error Condition | SIP Response Code | 382 +------------------------------+---------------------+ 383 | | 400 | 384 | | 400 | 385 | | 501 | 386 | | 403 | 387 | | 410 | 388 | | 500 | 389 | | 404 | 390 | | 484 | 391 | | 406 | 392 | | 405 | 393 | | 401 | 394 | | 480 | 395 | | 300 | 396 | | 407 | 397 | | 502 | 398 | | 504 | 399 | | 500 | 400 | | 503 | 401 | | 407 | 402 | | 400 | 403 | | 491 | 404 +------------------------------+---------------------+ 406 5.2. SIP to XMPP 408 The mapping of SIP response codes to XMPP error conditions SHOULD be 409 as follows (note that XMPP does not include 100-series or 200-series 410 response codes, only error conditions): 412 Table 9: Mapping of SIP response codes to XMPP error conditions 413 +---------------------+------------------------------+ 414 | SIP Response Code | XMPP Error Condition | 415 +---------------------+------------------------------+ 416 | 300 | | 417 | 301 | | 418 | 302 | | 419 | 305 | | 420 | 380 | | 421 | 400 | | 422 | 401 | | 423 | 402 | see note [1] | 424 | 403 | | 425 | 404 | | 426 | 405 | | 427 | 406 | | 428 | 407 | | 429 | 408 | | 430 | 410 | | 431 | 413 | | 432 | 414 | | 433 | 415 | | 434 | 416 | | 435 | 420 | | 436 | 421 | | 437 | 423 | | 438 | 480 | | 439 | 481 | | 440 | 482 | | 441 | 483 | | 442 | 484 | | 443 | 485 | | 444 | 486 | | 445 | 487 | | 446 | 488 | | 447 | 491 | | 448 | 493 | | 449 | 500 | | 450 | 501 | | 451 | 502 | | 452 | 503 | | 453 | 504 | | 454 | 505 | | 455 | 513 | | 456 | 600 | | 457 | 603 | | 458 | 604 | | 459 | 606 | | 460 +---------------------+------------------------------+ 462 1. The XMPP error condition was removed in 463 [RFC6120]. 465 6. Security Considerations 467 Detailed security considerations for SIP are given in [RFC3261] and 468 for XMPP in [RFC6120]. 470 7. IANA Considerations 472 This document requests no actions of IANA. 474 8. References 476 8.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 482 A., Peterson, J., Sparks, R., Handley, M., and E. 483 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 484 June 2002. 486 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 487 Resource Identifier (URI): Generic Syntax", STD 66, 488 RFC 3986, January 2005. 490 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 491 Registration Procedures for New URI Schemes", RFC 4395, 492 February 2006. 494 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 495 Agent URIs (GRUUs) in the Session Initiation Protocol 496 (SIP)", RFC 5627, October 2009. 498 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 499 Protocol (XMPP): Core", RFC 6120, March 2011. 501 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 502 Protocol (XMPP): Address Format", RFC 6122, March 2011. 504 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 505 6.2", 2012, 506 . 508 8.2. Informative References 510 [I-D.ietf-xmpp-6122bis] 511 Saint-Andre, P., "Extensible Messaging and Presence 512 Protocol (XMPP): Address Format", 513 draft-ietf-xmpp-6122bis-07 (work in progress), April 2013. 515 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 516 specifying the location of services (DNS SRV)", RFC 2782, 517 February 2000. 519 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 520 and D. Gurle, "Session Initiation Protocol (SIP) Extension 521 for Instant Messaging", RFC 3428, December 2002. 523 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 524 Internationalized Strings ("STRINGPREP")", RFC 3454, 525 December 2002. 527 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 528 Initiation Protocol (SIP)", RFC 3856, August 2004. 530 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 531 RFC 3859, August 2004. 533 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 534 (CPIM)", RFC 3860, August 2004. 536 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 537 October 2008. 539 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 540 Protocol (XMPP): Instant Messaging and Presence", 541 RFC 6121, March 2011. 543 [XEP-0106] 544 Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF 545 XEP 0106, May 2005. 547 Appendix A. Acknowledgements 549 The authors wish to thank the following individuals for their 550 feedback: Fabio Forno, Adrian Georgescu, Saul Ibarra, Markus Isomaki, 551 Salvatore Loreto, Daniel-Constantin Mierla, Tory Patnoe, and Robert 552 Sparks. 554 Authors' Addresses 556 Peter Saint-Andre 557 Cisco Systems, Inc. 558 1899 Wynkoop Street, Suite 600 559 Denver, CO 80202 560 USA 562 Phone: +1-303-308-3282 563 Email: psaintan@cisco.com 565 Avshalom Houri 566 IBM 567 Building 18/D, Kiryat Weizmann Science Park 568 Rehovot 76123 569 Israel 571 Email: avshalom@il.ibm.com 573 Joe Hildebrand 574 Cisco Systems, Inc. 575 1899 Wynkoop Street, Suite 600 576 Denver, CO 80202 577 USA 579 Email: jhildebr@cisco.com