idnits 2.17.1 draft-saintandre-sip-xmpp-core-03.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 (February 5, 2013) is 4070 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: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 6122 (Obsoleted by RFC 7622) -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-6122bis-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: Informational A. Houri 5 Expires: August 9, 2013 IBM 6 J. Hildebrand 7 Cisco Systems, Inc. 8 February 5, 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-03 15 Abstract 17 As a foundation for the definition of application-specific, bi- 18 directional protocol mappings between the Session Initiation Protocol 19 (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this 20 document specifies the architectural assumptions underlying such 21 mappings as well as the 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 August 9, 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. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Architectural Assumptions . . . . . . . . . . . . . . . . . . 3 61 5. Address Mapping . . . . . . . . . . . . . . . . . . . . . . . 4 62 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5.2. Local Part Mapping . . . . . . . . . . . . . . . . . . . . 5 64 5.3. Instance-Specific Mapping . . . . . . . . . . . . . . . . 7 65 5.4. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.5. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Error Condition Mapping . . . . . . . . . . . . . . . . . . . 9 68 6.1. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.2. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 The IETF has worked on two signalling technologies that can be used 81 for multimedia session negotiation, messaging, presence, capabilities 82 discovery, notifications, and other application-level functionality: 84 o The Session Initiation Protocol [RFC3261], along with various SIP 85 extensions developed within the SIP for Instant Messaging and 86 Presence Leveraging Extensions (SIMPLE) Working Group. 88 o The Extensible Messaging and Presence Protocol [RFC6120], along 89 with various XMPP extensions developed by the IETF as well as by 90 the XMPP Standards Foundation. 92 Because these technologies are widely deployed, it is important to 93 clearly define mappings between them for the sake of interworking. 94 This document inaugurates a series of SIP-XMPP interworking 95 specifications by defining the architectural assumptions underlying 96 such mappings as well as the mapping of addresses and error 97 conditions. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 [RFC2119]. 106 3. Discussion Venue 108 The discussion venue for this document is the mailing list of the 109 DISPATCH WG; visit 110 for subscription and archive information. 112 4. Architectural Assumptions 114 Protocol translation between SIP and XMPP could occur in a number of 115 different entities, depending on the architecture of real-time 116 communication deployments. For example, protocol translation could 117 occur within a multi-protocol server, within a multi-protocol client, 118 or within a gateway that acts as a dedicated protocol translator. 120 This document assumes that the protocol translation will occur within 121 a gateway. (This assumption not meant to discourage protocol 122 translation within multi-protocol clients or servers; instead, this 123 assumption is followed mainly to clarify the discussion and examples 124 so that the protocol translation principles can be more easily 125 understood and can be applied by client and server implementors with 126 appropriate modifications to the examples and terminology.) 127 Specifically, we assume that the protocol translation will occur 128 within an "XMPP-to-SIP gateway" that translates XMPP syntax and 129 semantics on behalf of an XMPP service when communicating with SIP 130 services and/or within a "SIP-to-XMPP gateway" that translates SIP 131 syntax and semantics on behalf of a SIP service when communicating 132 with XMPP services. 134 This document assumes that a gateway will translate directly from one 135 protocol to the other. We further assume that protocol translation 136 will occur within a gateway in the source domain, so that information 137 generated by the user of an XMPP service will be translated by a 138 gateway within the trust domain of that XMPP service, and information 139 generated by the user of a SIP service will be translated by a 140 gateway within the trust domain of that SIP service. 142 An architectural diagram for a possible gateway deployment is shown 143 below, where the entities have the following significance and the "#" 144 character is used to show the boundary of a trust domain: 146 o romeo@example.net -- a SIP user. 147 o example.net -- a SIP service with a gateway ("GW") to XMPP. 148 o juliet@example.com -- an XMPP user. 149 o example.com -- an XMPP service with a gateway ("GW") to SIP. 151 ##@####################################################### 152 # # # 153 # +-------------+----+ # +----+-------------+ # 154 # | example.net | GW |---#---| GW | example.com | # 155 # +-------------+----+ # +----+-------------+ # 156 # | # | # 157 # romeo@example.net # juliet@example.com # 158 # # # 159 ########################################################## 161 5. Address Mapping 163 5.1. Overview 165 The basic SIP address format is a "sip:" or "sips:" URI as specified 166 in [RFC3261]. When a SIP entity supports extensions for instant 167 messaging it might be identified by an 'im:' URI as specified in the 168 Common Profile for Instant Messaging [RFC3860] (see [RFC3428]) and 169 when a SIP entity spports extensions for presence it might be 170 identified by a 'pres:' URI as specified in the Common Profile for 171 Presence [RFC3859] (see [RFC3856]). 173 The XMPP address format is specified in [RFC6122]; as specified in 174 [RFC6121], instant messaging and presence applications of XMPP also 175 need to support 'im:' and 'pres:' URIs as specified in [RFC3860] and 176 [RFC3859] respectively, although such support might simply involve 177 leaving resolution of such addresses up to an XMPP server. 179 In this document we primarily describe mappings for addresses of the 180 form ; however, we also provide guidelies for mapping 181 the addresses of specific user agent instances, which take the form 182 of Globally Routable User Agent URIs (GRUUs) in SIP and 183 "resourceparts" in XMPP. Mapping of protocol-specific identifiers 184 (such as telephone numbers) is out of scope for this specification. 185 In addition, we have ruled the mapping of domain names as out of 186 scope for now since that is a matter for the Domain Name System; 187 specifically, the issue for interworking between SIP and XMPP relates 188 to the translation of fully internationalized domain names (IDNs) 189 into non-internationalized domain names (IDNs are not allowed in the 190 SIP address format, but are allowed in the XMPP address via 191 Internationalized Domain Names in Applications, see [RFC6122] and 192 [I-D.ietf-xmpp-6122bis]). Therefore, in the following sections we 193 focus primarily on the local part of an address (these are called 194 variously "usernames", "instant inboxes", "presentities", and 195 "localparts" in the protocols at issue), and secondarily on the 196 instance-specific part of an address. 198 The sip:/sips:, im:/pres:, and XMPP address schemes allow different 199 sets of characters (although all three allow alphanumeric characters 200 and disallow both spaces and control characters). In some cases, 201 characters allowed in one scheme are disallowed in others; these 202 characters need to be mapped appropriately in order to ensure 203 interworking across systems. 205 5.2. Local Part Mapping 207 The local part of a sip:/sips: URI inherits from the "userinfo" rule 208 in [RFC3986] with several changes; here we discuss the SIP "user" 209 rule only: 211 user = 1*( unreserved / escaped / user-unreserved ) 212 user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" 213 unreserved = alphanum / mark 214 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 215 / "(" / ")" 217 Here we make the simplifying assumption that the local part of an 218 im:/pres: URI inherits from the "dot-atom-text" rule in [RFC5322] 219 rather than the more complicated "local-part" rule: 221 dot-atom-text = 1*atext *("." 1*atext) 222 atext = ALPHA / DIGIT / ; Any character except controls, 223 "!" / "#" / ; SP, and specials. 224 "$" / "%" / ; Used for atoms 225 "&" / "'" / 226 "*" / "+" / 227 "-" / "/" / 228 "=" / "?" / 229 "^" / "_" / 230 "`" / "{" / 231 "|" / "}" / 232 "~" 234 The local part of an XMPP address allows any ASCII character except 235 space, controls, and the " & ' / : < > @ characters. 237 Therefore, the following table lists the allowed and disallowed 238 characters in the local part of identifiers for each protocol (aside 239 from the alphanumeric, space, and control characters), in order by 240 hexadecimal character number (where the "A" row shows the allowed 241 characters and the "D" row shows the disallowed characters). 243 Table 1: Allowed and disallowed characters 245 +---+----------------------------------+ 246 | SIP/SIPS CHARACTERS | 247 +---+----------------------------------+ 248 | A | ! $ &'()*+,-./ ; = ? _ ~ | 249 | D | "# % : < > @[\]^ `{|} | 250 +---+----------------------------------+ 251 | IM/PRES CHARACTERS | 252 +---+----------------------------------+ 253 | A | ! #$%&' *+ - / = ? ^_`{|}~ | 254 | D | " () , . :;< > @[\] | 255 +---+----------------------------------+ 256 | XMPP CHARACTERS | 257 +---+----------------------------------+ 258 | A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ | 259 | D | " &' /: < > @ | 260 +---+----------------------------------+ 262 When transforming the local part of an address from one scheme to 263 another, an application SHOULD proceed as follows: 265 1. Unescape any escaped characters in the source address (e.g., from 266 SIP to XMPP unescape "%2F" to "/" and from XMPP to SIP unescape 267 "\27" to "'"). 268 2. Leave unmodified any characters that are allowed in the 269 destination scheme. 270 3. Escape any characters that are allowed in the source scheme but 271 reserved in the destination scheme, as escaping is defined for 272 the destination scheme. In particular: 273 * Where the destination scheme is a URI (i.e., an im:, pres:, 274 sip:, or sips: URI), each reserved character MUST be percent- 275 encoded to "%hexhex" as specified in Section 2.6 of [RFC4395] 276 (e.g., when transforming from XMPP to SIP, encode "/" as 277 "%2F"). 278 * Where the destination scheme is a native XMPP address, each 279 reserved character MUST be encoded to "\hexhex" as specified 280 in [XEP-0106] (e.g., when transforming from SIP to XMPP, 281 encode "'" as "\27"). 283 5.3. Instance-Specific Mapping 285 The meaning of a resourcepart in XMPP (i.e., the portion of a JID 286 after the slash character, such as "foo" in the JID 287 "user@example.com/foo") matches that of a Globally Routable User 288 Agent URI (GRUU) in SIP [RFC5627]. In both cases, these constructs 289 identify a particular device associated with the bare JID 290 ("user@host") of an XMPP entity or with the Address of Record (AOR) 291 of a SIP entity. Therefore, it is reasonable to map the value of a 292 "gr" URI parameter to an XMPP resource part, and vice-versa. 294 Note that the "gr" URI parameter in SIP can contain only characters 295 from the ASCII range, whereas an XMPP resourcepart can contain nearly 296 any Unicode character [UNICODE]. Therefore Unicode characters 297 outside the ASCII range need to be mapped to characters in the ASCII 298 range, as described below. 300 5.4. SIP to XMPP 302 The following is a high-level algorithm for mapping a sip:, sips:, 303 im:, or pres: URI to an XMPP address: 305 1. Remove URI scheme. 306 2. Split at the first '@' character into local part and hostname 307 (mapping the latter is out of scope). 308 3. Translate any percent-encoded strings ("%hexhex") to percent- 309 decoded octets. 310 4. Treat result as a UTF-8 string. 312 5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f" 313 respectively in order to properly handle the characters 314 disallowed in XMPP addresses but allowed in sip:/sips: URIs and 315 im:/pres: URIs as shown in Column 3 of Table 3 above (this is 316 consistent with [XEP-0106]). 317 6. Apply Nodeprep profile of Stringprep [RFC3454] or its replacement 318 (see [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization 319 (OPTIONAL). 320 7. Recombine local part with mapped hostname to form a local@domain 321 address (bare JID). 322 8. If the (SIP) address contained a "gr" URI parameter, append a 323 slash character "/" and the "gr" value to the local@domain 324 address to form a local@domain/resource address (full JID). 326 5.5. XMPP to SIP 328 The following is a high-level algorithm for mapping an XMPP address 329 to a sip:, sips:, im:, or pres: URI: 331 1. Split XMPP address into localpart (mapping described in remaining 332 steps), domainpart (hostname; mapping is out of scope), and 333 resourcepart (specifier for particular device or connection, for 334 which an OPTIONAL mapping is described below). 335 2. Apply Nodeprep profile of [RFC3454] or its replacement (see 336 [RFC6122] and [I-D.ietf-xmpp-6122bis]) for canonicalization of 337 the XMPP localpart (OPTIONAL). 338 3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/" 339 respectively (this is consistent with [XEP-0106]). 340 4. Determine if the foreign domain supports im: and pres: URIs 341 (discovered via [RFC2782] lookup as specified in [RFC6121]), else 342 assume that the foreign domain supports sip:/sips: URIs. 343 5. If converting into im: or pres: URI, for each byte, if the byte 344 is in the set (),.;[\] (i.e., the partial complement from Row 3, 345 Column 2 of Table 3 above) or is a UTF-8 character outside the 346 ASCII range then percent-encode that byte to "%hexhex" format. 347 If converting into sip: or sips: URI, for each byte, if the byte 348 is in the set #%[\]^`{|} (i.e., the partial complement from Row 349 3, Column 1 of Table 3 above) or is a UTF-8 character outside the 350 ASCII range then percent-encode that byte to "%hexhex" format. 351 6. Combine resulting local part with mapped hostname to form 352 local@domain address. 353 7. Prepend with 'im:' scheme (for XMPP stanzas) or 354 'pres:' scheme (for XMPP stanzas) if foreign domain 355 supports these, else prepend with 'sip:' or 'sips:' scheme 356 according to local service policy. 357 8. If the XMPP address included a resourcepart and the destination 358 URI scheme is 'sip:' or 'sips:', optionally append the slash 359 character '/' and then append the resourcepart (making sure to 360 percent-encode any UTF-8 characters outside the ASCII range). 362 6. Error Condition Mapping 364 SIP response codes are specified in [RFC3261] and XMPP error 365 conditions are specified in [RFC6120]. 367 6.1. XMPP to SIP 369 Table 8: Mapping of XMPP error conditions to SIP response codes 371 +------------------------------+---------------------+ 372 | XMPP Error Condition | SIP Response Code | 373 +------------------------------+---------------------+ 374 | | 400 | 375 | | 400 | 376 | | 501 | 377 | | 403 | 378 | | 410 | 379 | | 500 | 380 | | 404 | 381 | | 484 | 382 | | 406 | 383 | | 405 | 384 | | 401 | 385 | | 402 | 386 | | 480 | 387 | | 300 | 388 | | 407 | 389 | | 502 | 390 | | 504 | 391 | | 500 | 392 | | 503 | 393 | | 407 | 394 | | 400 | 395 | | 491 | 396 +------------------------------+---------------------+ 398 6.2. SIP to XMPP 400 The mapping of SIP response codes to XMPP error conditions SHOULD be 401 as follows (note that XMPP does not include 100-series or 200-series 402 response codes, only error conditions): 404 Table 9: Mapping of SIP response codes to XMPP error conditions 405 +---------------------+------------------------------+ 406 | SIP Response Code | XMPP Error Condition | 407 +---------------------+------------------------------+ 408 | 300 | | 409 | 301 | | 410 | 302 | | 411 | 305 | | 412 | 380 | | 413 | 400 | | 414 | 401 | | 415 | 402 | | 416 | 403 | | 417 | 404 | | 418 | 405 | | 419 | 406 | | 420 | 407 | | 421 | 408 | | 422 | 410 | | 423 | 413 | | 424 | 414 | | 425 | 415 | | 426 | 416 | | 427 | 420 | | 428 | 421 | | 429 | 423 | | 430 | 480 | | 431 | 481 | | 432 | 482 | | 433 | 483 | | 434 | 484 | | 435 | 485 | | 436 | 486 | | 437 | 487 | | 438 | 488 | | 439 | 491 | | 440 | 493 | | 441 | 500 | | 442 | 501 | | 443 | 502 | | 444 | 503 | | 445 | 504 | | 446 | 505 | | 447 | 513 | | 448 | 600 | | 449 | 603 | | 450 | 604 | | 451 | 606 | | 452 +---------------------+------------------------------+ 454 7. Security Considerations 456 Detailed security considerations for SIP are given in [RFC3261] and 457 for XMPP in [RFC6120]. 459 8. IANA Considerations 461 This document requests no actions of IANA. 463 9. References 465 9.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 471 A., Peterson, J., Sparks, R., Handley, M., and E. 472 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 473 June 2002. 475 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 476 Resource Identifier (URI): Generic Syntax", STD 66, 477 RFC 3986, January 2005. 479 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 480 Registration Procedures for New URI Schemes", RFC 4395, 481 February 2006. 483 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 484 Agent URIs (GRUUs) in the Session Initiation Protocol 485 (SIP)", RFC 5627, October 2009. 487 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 488 Protocol (XMPP): Core", RFC 6120, March 2011. 490 [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence 491 Protocol (XMPP): Address Format", RFC 6122, March 2011. 493 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 494 6.2", 2012, 495 . 497 9.2. Informative References 499 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 500 specifying the location of services (DNS SRV)", RFC 2782, 501 February 2000. 503 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 504 and D. Gurle, "Session Initiation Protocol (SIP) Extension 505 for Instant Messaging", RFC 3428, December 2002. 507 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 508 Internationalized Strings ("STRINGPREP")", RFC 3454, 509 December 2002. 511 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 512 Initiation Protocol (SIP)", RFC 3856, August 2004. 514 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 515 RFC 3859, August 2004. 517 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 518 (CPIM)", RFC 3860, August 2004. 520 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 521 October 2008. 523 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 524 Protocol (XMPP): Instant Messaging and Presence", 525 RFC 6121, March 2011. 527 [I-D.ietf-xmpp-6122bis] 528 Saint-Andre, P., "Extensible Messaging and Presence 529 Protocol (XMPP): Address Format", 530 draft-ietf-xmpp-6122bis-05 (work in progress), 531 November 2012. 533 [XEP-0106] 534 Saint-Andre, P. and J. Hildebrand, "JID Escaping", XSF 535 XEP 0106, May 2005. 537 Appendix A. Acknowledgements 539 The authors wish to thank the following individuals for their 540 feedback: Fabio Forno, Adrian Georgescu, Saul Ibarra, Salvatore 541 Loreto, Daniel-Constantin Mierla, and Tory Patnoe. 543 Authors' Addresses 545 Peter Saint-Andre 546 Cisco Systems, Inc. 547 1899 Wynkoop Street, Suite 600 548 Denver, CO 80202 549 USA 551 Phone: +1-303-308-3282 552 Email: psaintan@cisco.com 554 Avshalom Houri 555 IBM 556 Building 18/D, Kiryat Weizmann Science Park 557 Rehovot 76123 558 Israel 560 Email: avshalom@il.ibm.com 562 Joe Hildebrand 563 Cisco Systems, Inc. 564 1899 Wynkoop Street, Suite 600 565 Denver, CO 80202 566 USA 568 Email: jhildebr@cisco.com