idnits 2.17.1 draft-saintandre-sip-xmpp-core-04.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 (April 02, 2013) is 4035 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 439 ** 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' -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-6122bis-06 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: October 04, 2013 IBM 6 J. Hildebrand 7 Cisco Systems, Inc. 8 April 02, 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-04 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 October 04, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Architectural Assumptions . . . . . . . . . . . . . . . . . . 3 60 4. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Local Part Mapping . . . . . . . . . . . . . . . . . . . 5 63 4.3. Instance-Specific Mapping . . . . . . . . . . . . . . . . 7 64 4.4. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.5. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Error Condition Mapping . . . . . . . . . . . . . . . . . . . 9 67 5.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 12 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. 87 o The Extensible Messaging and Presence Protocol [RFC6120], along 88 with various XMPP extensions developed by the IETF as well as by 89 the XMPP Standards Foundation. 91 Because these technologies are widely deployed, it is important to 92 clearly define mappings between them for the sake of interworking. 93 This document inaugurates a series of SIP-XMPP interworking 94 specifications by defining the architectural assumptions underlying 95 such mappings as well as the mapping of addresses and error 96 conditions. 98 The discussion venue for this document is the mailing list of the 99 DISPATCH WG; visit https://www.ietf.org/mailman/listinfo/dispatch for 100 subscription information and discussion archives. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 [RFC2119]. 109 3. Architectural Assumptions 111 Protocol translation between SIP and XMPP could occur in a number of 112 different entities, depending on the architecture of real-time 113 communication deployments. For example, protocol translation could 114 occur within a multi-protocol server (which uses application-specific 115 connection managers to initiate traffic to and accept traffic from 116 clients or other servers natively using SIP/SIMPLE, XMPP, etc.), 117 within a multi-protocol client (which enables a user to establish 118 connections natively with various servers using SIP/SIMPLE, XMPP, 119 etc.), or within a gateway that acts as a dedicated protocol 120 translator (which takes one protocol as input and provides another 121 protocol as output). 123 This document assumes that the protocol translation will occur within 124 a gateway. (This assumption not meant to discourage protocol 125 translation within multi-protocol clients or servers; instead, this 126 assumption is followed mainly to clarify the discussion and examples 127 so that the protocol translation principles can be more easily 128 understood and can be applied by client and server implementors with 129 appropriate modifications to the examples and terminology.) 130 Specifically, we assume that the protocol translation will occur 131 within an "XMPP-to-SIP gateway" that translates XMPP syntax and 132 semantics on behalf of an XMPP service when communicating with SIP 133 services and/or within a "SIP-to-XMPP gateway" that translates SIP 134 syntax and semantics on behalf of a SIP service when communicating 135 with XMPP services (naturally, these logical functions could occur in 136 one and the same actual translator). 138 This document assumes that a gateway will translate directly from one 139 protocol to the other. We further assume that protocol translation 140 will occur within a gateway in the source domain, so that information 141 generated by the user of an XMPP service will be translated by a 142 gateway within the trust domain of that XMPP service, and information 143 generated by the user of a SIP service will be translated by a 144 gateway within the trust domain of that SIP service. 146 An architectural diagram for a possible gateway deployment is shown 147 below, where the entities have the following significance and the "#" 148 character is used to show the boundary of a trust domain: 150 o romeo@example.net -- a SIP user. 152 o example.net -- a SIP service with a gateway ("GW") to XMPP. 154 o juliet@example.com -- an XMPP user. 156 o example.com -- an XMPP service with a gateway ("GW") to SIP. 158 ##@####################################################### 159 # # # 160 # +-------------+----+ # +----+-------------+ # 161 # | example.net | GW |---#---| GW | example.com | # 162 # +-------------+----+ # +----+-------------+ # 163 # | # | # 164 # romeo@example.net # juliet@example.com # 165 # # # 166 ########################################################## 168 4. Address Mapping 170 4.1. Overview 172 The basic SIP address format is a "sip:" or "sips:" URI as specified 173 in [RFC3261]. When a SIP entity supports extensions for instant 174 messaging it might be identified by an 'im:' URI as specified in the 175 Common Profile for Instant Messaging [RFC3860] (see [RFC3428]) and 176 when a SIP entity spports extensions for presence it might be 177 identified by a 'pres:' URI as specified in the Common Profile for 178 Presence [RFC3859] (see [RFC3856]). 180 The XMPP address format is specified in [RFC6122]; as discussed in 181 [RFC6121], instant messaging and presence applications of XMPP also 182 need to support 'im:' and 'pres:' URIs as specified in [RFC3860] and 183 [RFC3859] respectively, although such support might simply involve 184 leaving resolution of such addresses up to an XMPP server. 186 In this document we primarily describe mappings for addresses of the 187 form ; however, we also provide guidelines for mapping 188 the addresses of specific user agent instances, which take the form 189 of Globally Routable User Agent URIs (GRUUs) in SIP and 190 "resourceparts" in XMPP. Mapping of protocol-specific identifiers 191 (such as telephone numbers) is out of scope for this specification. 192 In addition, we have ruled the mapping of domain names as out of 193 scope for now since that is a matter for the Domain Name System; 194 specifically, the issue for interworking between SIP and XMPP relates 195 to the translation of fully internationalized domain names (IDNs) 196 into non-internationalized domain names (IDNs are not allowed in the 197 SIP address format, but are allowed in the XMPP address via 198 Internationalized Domain Names in Applications, see [RFC6122] and 199 [I-D.ietf-xmpp-6122bis]). Therefore, in the following sections we 200 focus primarily on the local part of an address (these are called 201 variously "usernames", "instant inboxes", "presentities", and 202 "localparts" in the protocols at issue), secondarily on the instance- 203 specific part of an address, and not at all on the domain-name part 204 of an address. 206 The sip:/sips:, im:/pres:, and XMPP address schemes allow different 207 sets of characters (although all three allow alphanumeric characters 208 and disallow both spaces and control characters). In some cases, 209 characters allowed in one scheme are disallowed in others; these 210 characters need to be mapped appropriately in order to ensure 211 interworking across systems. 213 4.2. Local Part Mapping 215 The local part of a sip:/sips: URI inherits from the "userinfo" rule 216 in [RFC3986] with several changes; here we discuss the SIP "user" 217 rule only: 219 user = 1*( unreserved / escaped / user-unreserved ) 220 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 221 unreserved = alphanum / mark 222 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 223 / "(" / ")" 225 Here we make the simplifying assumption that the local part of an im: 226 /pres: URI inherits from the "dot-atom-text" rule in [RFC5322] rather 227 than the more complicated "local-part" rule: 229 dot-atom-text = 1*atext *("." 1*atext) 230 atext = ALPHA / DIGIT / ; Any character except 231 "!" / "#" / "$" / ; controls, SP, and 232 "%" / "&" / "'" / ; specials. Used for 233 "*" / "+" / "-" / ; atoms. 234 "/" / "=" / "?" / 235 "^" / "_" / "`" / 236 "{" / "|" / "}" / 237 "~" 239 The local part of an XMPP address allows any ASCII character except 240 space, controls, and the " & ' / : < > @ characters. 242 To summarize the foregoing information, the following table lists the 243 allowed and disallowed characters in the local part of identifiers 244 for each protocol (aside from the alphanumeric, space, and control 245 characters), in order by hexadecimal character number (where each "A" 246 row shows the allowed characters and each "D" row shows the 247 disallowed characters). 249 Table 1: Allowed and disallowed characters 251 +---+----------------------------------+ 252 | SIP/SIPS CHARACTERS | 253 +---+----------------------------------+ 254 | A | ! $ &'()*+,-./ ; = ? _ ~ | 255 | D | "# % : < > @[\]^ `{|} | 256 +---+----------------------------------+ 257 | IM/PRES CHARACTERS | 258 +---+----------------------------------+ 259 | A | ! #$%&' *+ - / = ? ^_`{|}~ | 260 | D | " () , . :;< > @[\] | 261 +---+----------------------------------+ 262 | XMPP CHARACTERS | 263 +---+----------------------------------+ 264 | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | 265 | D | " &' /: < > @ | 266 +---+----------------------------------+ 268 When transforming the local part of an address from one scheme to 269 another, an application SHOULD proceed as follows: 271 1. Unescape any escaped characters in the source address (e.g., from 272 SIP to XMPP unescape "%2F" to "/" and from XMPP to SIP unescape 273 "\27" to "'"). 275 2. Leave unmodified any characters that are allowed in the 276 destination scheme. 278 3. Escape any characters that are allowed in the source scheme but 279 reserved in the destination scheme, as escaping is defined for 280 the destination scheme. In particular: 282 * Where the destination scheme is a URI (i.e., an im:, pres:, 283 sip:, or sips: URI), each reserved character MUST be percent- 284 encoded to "%hexhex" as specified in Section 2.6 of [RFC4395] 285 (e.g., when transforming from XMPP to SIP, encode "/" as 286 "%2F"). 288 * Where the destination scheme is a native XMPP address, each 289 reserved character MUST be encoded to "\hexhex" as specified 290 in [XEP-0106] (e.g., when transforming from SIP to XMPP, 291 encode "'" as "\27"). 293 4.3. Instance-Specific Mapping 295 The meaning of a resourcepart in XMPP (i.e., the portion of a JID 296 after the slash character, such as "foo" in "user@example.com/foo") 297 matches that of a Globally Routable User Agent URI (GRUU) in SIP 298 [RFC5627]. In both cases, these constructs identify a particular 299 device associated with the bare JID ("localpart@domainpart") of an 300 XMPP entity or with the Address of Record (AOR) of a SIP entity. 301 Therefore, it is reasonable to map the value of a "gr" URI parameter 302 to an XMPP resource part, and vice-versa. 304 Note that the "gr" URI parameter in SIP can contain only characters 305 from the ASCII range, whereas an XMPP resourcepart can contain nearly 306 any Unicode character [UNICODE]. Therefore Unicode characters 307 outside the ASCII range need to be mapped to characters in the ASCII 308 range, as described below. 310 4.4. SIP to XMPP 312 The following is a high-level algorithm for mapping a sip:, sips:, 313 im:, or pres: URI to an XMPP address: 315 1. Remove URI scheme. 317 2. Split at the first '@' character into local part and hostname 318 (mapping the latter is out of scope). 320 3. Translate any percent-encoded strings ("%hexhex") to percent- 321 decoded octets. 323 4. Treat result as a UTF-8 string. 325 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" 326 respectively in order to properly handle the characters 327 disallowed in XMPP addresses but allowed in sip:/sips: URIs and 328 im:/pres: URIs as shown in Table 1 above (this is consistent with 329 [XEP-0106]). 331 6. Apply Nodeprep profile of Stringprep [RFC3454] or its replacement 332 (see [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization 333 (OPTIONAL). 335 7. Recombine local part with mapped hostname to form a bare JID 336 ("localpart@domainpart"). 338 8. If the (SIP) address contained a "gr" URI parameter, append a 339 slash character "/" and the "gr" value to the bare JID to form a 340 full JID ("localpart@domainpart/resourcepart"). 342 4.5. XMPP to SIP 344 The following is a high-level algorithm for mapping an XMPP address 345 to a sip:, sips:, im:, or pres: URI: 347 1. Split XMPP address into localpart (mapping described in remaining 348 steps), domainpart (hostname; mapping is out of scope), and 349 resourcepart (specifier for particular device or connection, for 350 which an OPTIONAL mapping is described below). 352 2. Apply Nodeprep profile of [RFC3454] or its replacement (see 353 [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization of 354 the XMPP localpart (OPTIONAL). 356 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" 357 respectively (this is consistent with [XEP-0106]). 359 4. Determine if the foreign domain supports im: and pres: URIs 360 (discovered via [RFC2782] lookup as specified in [RFC6121]), else 361 assume that the foreign domain supports sip:/sips: URIs. 363 5. If converting into im: or pres: URI, for each byte, if the byte 364 is in the set (),.;[\] or is a UTF-8 character outside the ASCII 365 range then percent-encode that byte to "%hexhex" format. If 366 converting into sip: or sips: URI, for each byte, if the byte is 367 in the set #%[\]^`{|} or is a UTF-8 character outside the ASCII 368 range then percent-encode that byte to "%hexhex" format. 370 6. Combine resulting local part with mapped hostname to form 371 local@domain address. 373 7. Prepend with 'im:' scheme (for XMPP stanzas) or 374 'pres:' scheme (for XMPP stanzas) if foreign domain 375 supports these, else prepend with 'sip:' or 'sips:' scheme 376 according to local service policy. 378 8. If the XMPP address included a resourcepart and the destination 379 URI scheme is 'sip:' or 'sips:', optionally append the slash 380 character '/' and then append the resourcepart (making sure to 381 percent-encode any UTF-8 characters outside the ASCII range) as 382 the "gr" URI parameter. 384 5. Error Condition Mapping 386 SIP response codes are specified in [RFC3261] and XMPP error 387 conditions are specified in [RFC6120]. Because there is no 388 equivalent in XMPP for the provisional (1xx) and successful (2xx) 389 response codes in SIP, mappings are provided only for the redirection 390 (3xx), request failure (4xx), server failure (5xx), and glogal 391 failure (6xx) codes. 393 5.1. XMPP to SIP 395 Table 8: Mapping of XMPP error conditions to SIP response codes 397 +------------------------------+---------------------+ 398 | XMPP Error Condition | SIP Response Code | 399 +------------------------------+---------------------+ 400 | | 400 | 401 | | 400 | 402 | | 501 | 403 | | 403 | 404 | | 410 | 405 | | 500 | 406 | | 404 | 407 | | 484 | 408 | | 406 | 409 | | 405 | 410 | | 401 | 411 | | 480 | 412 | | 300 | 413 | | 407 | 414 | | 502 | 415 | | 504 | 416 | | 500 | 417 | | 503 | 418 | | 407 | 419 | | 400 | 420 | | 491 | 421 +------------------------------+---------------------+ 423 5.2. SIP to XMPP 424 The mapping of SIP response codes to XMPP error conditions SHOULD be 425 as follows (note that XMPP does not include 100-series or 200-series 426 response codes, only error conditions): 428 Table 9: Mapping of SIP response codes to XMPP error conditions 429 +---------------------+------------------------------+ 430 | SIP Response Code | XMPP Error Condition | 431 +---------------------+------------------------------+ 432 | 300 | | 433 | 301 | | 434 | 302 | | 435 | 305 | | 436 | 380 | | 437 | 400 | | 438 | 401 | | 439 | 402 | see note [1] | 440 | 403 | | 441 | 404 | | 442 | 405 | | 443 | 406 | | 444 | 407 | | 445 | 408 | | 446 | 410 | | 447 | 413 | | 448 | 414 | | 449 | 415 | | 450 | 416 | | 451 | 420 | | 452 | 421 | | 453 | 423 | | 454 | 480 | | 455 | 481 | | 456 | 482 | | 457 | 483 | | 458 | 484 | | 459 | 485 | | 460 | 486 | | 461 | 487 | | 462 | 488 | | 463 | 491 | | 464 | 493 | | 465 | 500 | | 466 | 501 | | 467 | 502 | | 468 | 503 | | 469 | 504 | | 470 | 505 | | 471 | 513 | | 472 | 600 | | 473 | 603 | | 474 | 604 | | 475 | 606 | | 476 +---------------------+------------------------------+ 477 1. The XMPP error condition was removed in 478 [RFC6120]. 480 6. Security Considerations 482 Detailed security considerations for SIP are given in [RFC3261] and 483 for XMPP in [RFC6120]. 485 7. IANA Considerations 487 This document requests no actions of IANA. 489 8. References 491 8.1. Normative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 497 A., Peterson, J., Sparks, R., Handley, M., and E. 498 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 499 June 2002. 501 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 502 Resource Identifier (URI): Generic Syntax", STD 66, RFC 503 3986, January 2005. 505 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 506 Registration Procedures for New URI Schemes", RFC 4395, 507 February 2006. 509 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 510 Agent URIs (GRUUs) in the Session Initiation Protocol 511 (SIP)", RFC 5627, October 2009. 513 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 514 Protocol (XMPP): Core", RFC 6120, March 2011. 516 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 517 Protocol (XMPP): Address Format", RFC 6122, March 2011. 519 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 520 6.2", 2012, 521 . 523 8.2. Informative References 525 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 526 specifying the location of services (DNS SRV)", RFC 2782, 527 February 2000. 529 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 530 and D. Gurle, "Session Initiation Protocol (SIP) Extension 531 for Instant Messaging", RFC 3428, December 2002. 533 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 534 Internationalized Strings ("STRINGPREP")", RFC 3454, 535 December 2002. 537 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 538 Initiation Protocol (SIP)", RFC 3856, August 2004. 540 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 541 3859, August 2004. 543 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 544 (CPIM)", RFC 3860, August 2004. 546 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 547 October 2008. 549 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 550 Protocol (XMPP): Instant Messaging and Presence", RFC 551 6121, March 2011. 553 [I-D.ietf-xmpp-6122bis] 554 Saint-Andre, P., "Extensible Messaging and Presence 555 Protocol (XMPP): Address Format", draft-ietf-xmpp- 556 6122bis-06 (work in progress), March 2013. 558 [XEP-0106] 559 Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF XEP 560 0106, May 2005. 562 Appendix A. Acknowledgements 564 The authors wish to thank the following individuals for their 565 feedback: Fabio Forno, Adrian Georgescu, Saul Ibarra, Salvatore 566 Loreto, Daniel-Constantin Mierla, Tory Patnoe, and Robert Sparks. 568 Authors' Addresses 570 Peter Saint-Andre 571 Cisco Systems, Inc. 572 1899 Wynkoop Street, Suite 600 573 Denver, CO 80202 574 USA 576 Phone: +1-303-308-3282 577 Email: psaintan@cisco.com 579 Avshalom Houri 580 IBM 581 Building 18/D, Kiryat Weizmann Science Park 582 Rehovot 76123 583 Israel 585 Email: avshalom@il.ibm.com 587 Joe Hildebrand 588 Cisco Systems, Inc. 589 1899 Wynkoop Street, Suite 600 590 Denver, CO 80202 591 USA 593 Email: jhildebr@cisco.com