idnits 2.17.1 draft-gould-casanova-regext-unhandled-namespaces-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 date (October 1, 2018) is 2034 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NAMESPACE-URI' is mentioned on line 326, but not defined == Missing Reference: 'NAMESPACE-XML' is mentioned on line 323, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-regext-change-poll-08 ** Downref: Normative reference to an Informational RFC: RFC 3735 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Best Current Practice M. Casanova 5 Expires: April 4, 2019 SWITCH 6 October 1, 2018 8 Extensible Provisioning Protocol (EPP) Unhandled Namespaces 9 draft-gould-casanova-regext-unhandled-namespaces-00 11 Abstract 13 The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, 14 includes a method for the client and server to determine the objects 15 to be managed during a session and the object extensions to be used 16 during a session. The services are identified using namespace URIs. 17 How should the server handle service data that needs to be returned 18 in the response when the client does not support the required service 19 namespace URI, which is referred to as an unhandled namespace? An 20 unhandled namespace is a significant issue for the processing of RFC 21 5730 poll messages, since poll messages are inserted by the server 22 prior to knowing the supported client services, and the client needs 23 to be capable of processing all poll messages. This document defines 24 an operational practice that enables the server to return information 25 associated with unhandled namespace URIs that is compliant with the 26 negotiated services defined in RFC 5730. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 4, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 64 2. Unhandled Namespaces . . . . . . . . . . . . . . . . . . . . 3 65 3. Use of EPP for Unhandled Namespace Data . . . . . 4 66 3.1. Unhandled Object-Level Extension . . . . . . . . . . . . 5 67 3.2. Unhandled Command-Response Extension . . . . . . . . . . 7 68 4. Usage with General EPP Responses . . . . . . . . . . . . . . 11 69 5. Usage with Poll Message EPP Responses . . . . . . . . . . . . 12 70 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 71 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 16 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 74 9. Normative References . . . . . . . . . . . . . . . . . . . . 17 75 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 The Extensible Provisioning Protocol (EPP), as defined in [RFC5730], 81 includes a method for the client and server to determine the objects 82 to be managed during a session and the object extensions to be used 83 during a session. The services are identified using namespace URIs. 84 How should the server handle service data that needs to be returned 85 in the response when the client does not support the required service 86 namespace URI, which is referred to as an unhandled namespace? An 87 unhandled namespace is a significant issue for the processing of 88 [RFC5730] poll messages, since poll messages are inserted by the 89 server prior to knowing the supported client services, and the client 90 needs to be capable of processing all poll messages. An unhandled 91 namespace is an issue also for general EPP responses when the server 92 has information that it cannot return to the client due to the 93 client's supported services. The server should be able to return 94 unhandled namespace information that the client can process later. 95 This document defines an operational practice that enables the server 96 to return information associated with unhandled namespace URIs that 97 is compliant with the negotiated services defined in [RFC5730]. 99 1.1. Conventions Used in This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 XML is case sensitive. Unless stated otherwise, XML specifications 106 and examples provided in this document MUST be interpreted in the 107 character case presented in order to develop a conforming 108 implementation. 110 In examples, "S:" represents lines returned by a protocol server. 111 Indentation and white space in examples are provided only to 112 illustrate element relationships and are not a REQUIRED feature of 113 this protocol. 115 The examples reference XML namespace prefixes that are used for the 116 associated XML namespaces. Implementations MUST NOT depend on the 117 example XML namespaces and instead employ a proper namespace-aware 118 XML parser and serializer to interpret and output the XML documents. 119 The example namespace prefixes used and their associated XML 120 namespaces include: 122 "changePoll": urn:ietf:params:xml:ns:changePoll-1.0 123 "domain": urn:ietf:params:xml:ns:domain-1.0 124 "secDNS": urn:ietf:params:xml:ns:secDNS-1.1 126 In the template example XML, placeholder content is represented by 127 the following variables: 129 "[NAMESPACE-XML]": XML content associated with a login service 130 namespace URI. An example is the element 131 content in [RFC5731]. 132 "[NAMESPACE-URI]": XML namespace URI associated with the [NAMESPACE- 133 XML] XML content. An example is "urn:ietf:params:xml:ns:domain- 134 1.0" in [RFC5731]. 136 2. Unhandled Namespaces 138 An Unhandled Namespace is an XML namespace that is associated with a 139 response extension that is not included in the client-specified EPP 140 login services of [RFC5730]. The EPP login services consists of the 141 set of XML namespace URIs included in the or 142 elements of the [RFC5730] EPP command. The services 143 supported by the server are included in the and 144 elements of the [RFC5730] EPP , which should be a superset 145 of the login services included in the EPP command. A server 146 may have information associated with a specific namespace that it 147 needs to return in the response to a client. The unhandled 148 namespaces problem exists when the server has information, that it 149 needs to return to the client, that is not supported by the client 150 based on the negotiated EPP command services. 152 3. Use of EPP for Unhandled Namespace Data 154 When a server has data to return to the client, that the client does 155 not support based on the login services, the server MAY return a 156 successful response, with the data for each unsupported namespace 157 moved into an [RFC5730] element. The unhandled namespace 158 will not cause an error response, but the unhandled namespace data 159 will instead be moved to an element, along with a reason 160 why the unhandled namespace data could not be included in the 161 appropriate location of the response. The element XML 162 will not be processed by the XML processor. The element 163 contains the following child elements: 165 : Contains a child-element with the unhandled namespace XML. 166 The XML namespace and namespace prefix of the child element MUST 167 be defined, which MAY be defined in the element or in the 168 the child element. XML processing of the element is 169 disabled in [RFC5730], so the information can safely be returned 170 in the element. 171 : A formatted human-readable message that indicates the 172 reason the unhandled namespace data was not returned in the 173 appropriate location of the response. The formatted reason 174 SHOULD follow the Augmented Backus-Naur Form (ABNF) grammar 175 [RFC5234] format: NAMESPACE-URI "not in login services", where 176 NAMESPACE-URI is the unhandled XML namespace like 177 "urn:ietf:params:xml:ns:domain-1.0" for [RFC5731]. 179 This document supports handling of unsupported namespaces for 180 [RFC3735] object-level extensions and command-response extensions. 181 This document does not support [RFC3735] protocol-level extensions or 182 authentication information extensions. Refer to the following 183 sections on how to handle an unsupported object-level extension 184 namespace or an unsupported command-response extension namespace. 186 3.1. Unhandled Object-Level Extension 188 An object-level extension in [RFC5730] is a child element of the 189 element. If the client does not handle the namespace of 190 the object-level extension, then the element is removed and 191 its object-level extension child element is moved into a [RFC5730] 192 element, with the namespace URI included in the 193 corresponding element. The response becomes a 194 general EPP response without the element. 196 Template response for a supported object-level extension. The 197 [NAMESPACE-XML] variable represents the object-level extension XML. 199 S: 200 S: 201 S: 202 S: 203 S: Command completed successfully 204 S: 205 S: 206 S: [NAMESPACE-XML] 207 S: 208 S: 209 S: ABC-12345 210 S: 54322-XYZ 211 S: 212 S: 213 S: 214 Template unhandled namespace response for an unsupported object-level 215 extension. The [NAMESPACE-XML] variable represents the object-level 216 extension XML and the [NAMESPACE-URI] variable represents the object- 217 level extension XML namespace URI. 219 S: 220 S: 221 S: 222 S: 223 S: Command completed successfully 224 S: 225 S: 226 S: [NAMESPACE-XML] 227 S: 228 S: 229 S: [NAMESPACE-URI] not in login services 230 S: 231 S: 232 S: 233 S: 234 S: ABC-12345 235 S: 54322-XYZ 236 S: 237 S: 238 S: 240 The EPP response is converted from an object response to a general 241 EPP response by the server when the client does not support the 242 object-level extension namespace URI. Below is example of converting 243 the query response example in [RFC5730] to an unhandled 244 namespace response. 246 [RFC5730] example query response converted into an 247 unhandled namespace response. 249 S: 250 S: 251 S: 252 S: 253 S: Command completed successfully 254 S: 255 S: 256 S: 258 S: example.com 259 S: pending 260 S: ClientX 261 S: 2000-06-06T22:00:00.0Z 262 S: ClientY 263 S: 2000-06-11T22:00:00.0Z 264 S: 2002-09-08T22:00:00.0Z 265 S: 266 S: 267 S: 268 S: urn:ietf:params:xml:ns:domain-1.0 not in login services 269 S: 270 S: 271 S: 272 S: 273 S: ABC-12345 274 S: 54322-XYZ 275 S: 276 S: 277 S: 279 3.2. Unhandled Command-Response Extension 281 A command-response extension in [RFC5730] is a child element of the 282 element. If the client does not handle the namespace of 283 the command-response extension, the command-response child element is 284 moved into a [RFC5730] element, with the namespace 285 URI included in the corresponding element. If 286 after moving the command-response child element there are no 287 additional command-response child elements, the element 288 MUST be removed. 290 Template response for a supported command-response extension. The 291 [NAMESPACE-XML] variable represents the command-response extension 292 XML. 294 S: 295 S: 297 S: 298 S: 299 S: Command completed successfully 300 S: 301 S: 302 S: [NAMESPACE-XML] 303 S: 304 S: 305 S: ABC-12345 306 S: 54322-XYZ 307 S: 308 S: 309 S: 310 Template unhandled namespace response for an unsupported command- 311 response extension. The [NAMESPACE-XML] variable represents the 312 command-response extension XML and the [NAMESPACE-URI] variable 313 represents the command-response extension XML namespace URI. 315 S: 316 S: 318 S: 319 S: 320 S: Command completed successfully 321 S: 322 S: 323 S: [NAMESPACE-XML] 324 S: 325 S: 326 S: [NAMESPACE-URI] not in login services 327 S: 328 S: 329 S: 330 S: 331 S: 332 S: 333 S: ABC-12345 334 S: 54322-XYZ 335 S: 336 S: 337 S: 339 The EPP response is converted to an unhandled namespace response by 340 moving the unhandled command-response extension from under the 341 to an element. Below is example of converting 342 the DS Data Interface response example in [RFC5910] to an 343 unhandled namespace response. 345 [RFC5910] DS Data Interface response converted into an 346 unhandled namespace response. 348 S: 349 S: 350 S: 351 S: 352 S: Command completed successfully 353 S: 354 S: 355 S: 357 S: 358 S: 12345 359 S: 3 360 S: 1 361 S: 49FD46E6C4B45C55D4AC 362 S: 363 S: 364 S: 365 S: 366 S: urn:ietf:params:xml:ns:secDNS-1.1 not in login services 367 S: 368 S: 369 S: 370 S: 371 S: 373 S: example.com 374 S: EXAMPLE1-REP 375 S: 376 S: jd1234 377 S: sh8013 378 S: sh8013 379 S: 380 S: ns1.example.com 381 S: ns2.example.com 382 S: 383 S: ns1.example.com 384 S: ns2.example.com 385 S: ClientX 386 S: ClientY 387 S: 1999-04-03T22:00:00.0Z 388 S: ClientX 389 S: 1999-12-03T09:00:00.0Z 390 S: 2005-04-03T22:00:00.0Z 391 S: 2000-04-08T09:00:00.0Z 392 S: 393 S: 2fooBAR 394 S: 395 S: 396 S: 397 S: 398 S: ABC-12345 399 S: 54322-XYZ 400 S: 401 S: 402 S: 404 4. Usage with General EPP Responses 406 The unhandled namespace approach defined in Section 3 MAY be used for 407 a general EPP response to an EPP command. A general EPP response 408 includes any non-poll message EPP response. The use of the unhandled 409 namespace approach for poll message EPP responses is defined in 410 Section 5. The server MAY exclude the unhandled namespace 411 information in the general EPP response or MAY include it using the 412 unhandled namespace approach. 414 The unhandled namespace approach for general EPP responses SHOULD 415 only be applicable to command-response extensions, defined in 416 Section 3.2, since the server SHOULD NOT accept an object-level EPP 417 command if the client did not include the object-level namespace URI 418 in the login services. An object-level EPP response extension is 419 returned when the server successfully executes an object-level EPP 420 command extension. The server MAY return an unhandled object-level 421 extension to the client as defined in Section 3.1. 423 Returning domain name Redemption Grace Period (RGP) data, based on 424 [RFC3915], provides an example of applying the unhandled namespace 425 approach for a general EPP response. If the client does not include 426 the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the login 427 services, and the domain response of a domain name does have 428 RGP information, the server MAY exclude the element 429 from the EPP response or MAY include it under in the 430 element per Section 3.2. 432 [RFC5731] domain name response with the unhandled [RFC3915] 433 element included under an element: 435 S: 436 S: 437 S: 438 S: 439 S: Command completed successfully 440 S: 441 S: 442 S: 443 S: 444 S: 445 S: 446 S: 447 S: urn:ietf:params:xml:ns:rgp-1.0 not in login services 448 S: 449 S: 450 S: 451 S: 452 S: 454 S: example.com 455 S: EXAMPLE1-REP 456 S: 457 S: jd1234 458 S: sh8013 459 S: sh8013 460 S: 461 S: ns1.example.com 462 S: ns1.example.net 463 S: 464 S: ns1.example.com 465 S: ns2.example.com 466 S: ClientX 467 S: ClientY 468 S: 1999-04-03T22:00:00.0Z 469 S: ClientX 470 S: 1999-12-03T09:00:00.0Z 471 S: 2005-04-03T22:00:00.0Z 472 S: 2000-04-08T09:00:00.0Z 473 S: 474 S: 2fooBAR 475 S: 476 S: 477 S: 478 S: 479 S: ABC-12345 480 S: 54322-XYZ 481 S: 482 S: 483 S: 485 5. Usage with Poll Message EPP Responses 487 The unhandled namespace approach, defined in Section 3, MUST be used 488 if there is unhandled namespace information included in an EPP 489 message response. The server inserts poll messages into the client's 490 poll queue independent of knowing the supported client login 491 services, therefore there may be unhandled object-level and command- 492 response extensions included in a client's poll queue. In [RFC5730], 493 the command is used by the client to retrieve and acknowledge 494 poll messages that have been inserted by the server. The 495 message response is an EPP response that includes the element 496 that provides poll queue meta-data about the message. The unhandled 497 namespace approach, defined in Section 3, is used for an unhandled 498 object-level extension and for each of the unhandled command-response 499 extensions attached to the message response. The resulting 500 EPP message response MAY have either or both the object-level 501 extension or command-response extensions moved to 502 elements, as defined in Section 3. 504 The Change Poll Message, as defined in [I-D.ietf-regext-change-poll], 505 which is an extension of any EPP object, is an example of applying 506 the unhandled namespace approach for EPP message responses. 507 The object that will be used in the examples is a [RFC5731] domain 508 name object. 510 [RFC5731] domain name message response with the 511 unhandled [I-D.ietf-regext-change-poll] 512 element included under an element: 514 S: 515 S: 516 S: 517 S: 518 S: Command completed successfully; ack to dequeue 519 S: 520 S: 521 S: 524 S: update 525 S: 526 S: 2013-11-22T05:00:00.000Z 527 S: 12345-XYZ 528 S: URS Admin 529 S: urs123 530 S: 531 S: URS Lock 532 S: 533 S: 534 S: 535 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services 536 S: 537 S: 538 S: 539 S: 543 S: 2018-08-24T19:21:51.087Z 544 S: Registry initiated update of domain. 545 S: 546 S: 547 S: 549 S: change-poll.tld 550 S: EXAMPLE1-REP 551 S: 552 S: 553 S: 554 S: jd1234 555 S: sh8013 556 S: sh8013 557 S: ClientX 558 S: ClientY 559 S: 2012-05-03T04:00:00.000Z 560 S: ClientZ 561 S: 2013-11-22T05:00:00.000Z 562 S: 2014-05-03T04:00:00.000Z 563 S: 564 S: 565 S: 566 S: ABC-12345 567 S: 54322-XYZ 568 S: 569 S: 570 S: 572 Unhandled [RFC5731] domain name message response and 573 the unhandled [I-D.ietf-regext-change-poll] 574 element included under an element: 576 S: 577 S: 578 S: 579 S: 580 S: Command completed successfully; ack to dequeue 581 S: 582 S: 583 S: 585 S: change-poll.tld 586 S: EXAMPLE1-REP 587 S: 588 S: 589 S: 590 S: jd1234 591 S: sh8013 592 S: sh8013 593 S: ClientX 594 S: ClientY 595 S: 2012-05-03T04:00:00.000Z 596 S: ClientZ 597 S: 2013-11-22T05:00:00.000Z 598 S: 2014-05-03T04:00:00.000Z 599 S: 600 S: 601 S: 602 S: urn:ietf:params:xml:ns:domain-1.0 not in login services 603 S: 604 S: 605 S: 606 S: 607 S: 610 S: update 611 S: 612 S: 2013-11-22T05:00:00.000Z 613 S: 12345-XYZ 614 S: URS Admin 615 S: urs123 616 S: 617 S: URS Lock 618 S: 619 S: 620 S: 621 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services 622 S: 623 S: 624 S: 625 S: 629 S: 2018-08-24T19:23:12.822Z 630 S: Registry initiated update of domain. 631 S: 632 S: 633 S: ABC-12345 634 S: 54322-XYZ 635 S: 636 S: 637 S: 639 6. Implementation Status 641 Note to RFC Editor: Please remove this section and the reference to 642 RFC 7942 [RFC7942] before publication. 644 This section records the status of known implementations of the 645 protocol defined by this specification at the time of posting of this 646 Internet-Draft, and is based on a proposal described in RFC 7942 647 [RFC7942]. The description of implementations in this section is 648 intended to assist the IETF in its decision processes in progressing 649 drafts to RFCs. Please note that the listing of any individual 650 implementation here does not imply endorsement by the IETF. 651 Furthermore, no effort has been spent to verify the information 652 presented here that was supplied by IETF contributors. This is not 653 intended as, and must not be construed to be, a catalog of available 654 implementations or their features. Readers are advised to note that 655 other implementations may exist. 657 According to RFC 7942 [RFC7942], "this will allow reviewers and 658 working groups to assign due consideration to documents that have the 659 benefit of running code, which may serve as evidence of valuable 660 experimentation and feedback that have made the implemented protocols 661 more mature. It is up to the individual working groups to use this 662 information as they see fit". 664 6.1. Verisign EPP SDK 666 Organization: Verisign Inc. 668 Name: Verisign EPP SDK 670 Description: The Verisign EPP SDK includes an implementation of the 671 unhandled namespaces for the processing of the poll queue messages. 673 Level of maturity: Development 675 Coverage: All aspects of the protocol are implemented. 677 Licensing: GNU Lesser General Public License 679 Contact: jgould@verisign.com 681 URL: https://www.verisign.com/en_US/channel-resources/domain- 682 registry-products/epp-sdks 684 7. Security Considerations 686 The document do not provide any security services beyond those 687 described by EPP [RFC5730] and protocol layers used by EPP. The 688 security considerations described in these other specifications apply 689 to this specification as well. 691 8. Acknowledgements 693 TBD 695 9. Normative References 697 [I-D.ietf-regext-change-poll] 698 Gould, J. and K. Feher, "Change Poll Extension for the 699 Extensible Provisioning Protocol (EPP)", draft-ietf- 700 regext-change-poll-08 (work in progress), May 2018. 702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, 704 DOI 10.17487/RFC2119, March 1997, . 707 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 708 Provisioning Protocol (EPP)", RFC 3735, 709 DOI 10.17487/RFC3735, March 2004, . 712 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 713 the Extensible Provisioning Protocol (EPP)", RFC 3915, 714 DOI 10.17487/RFC3915, September 2004, . 717 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 718 Specifications: ABNF", STD 68, RFC 5234, 719 DOI 10.17487/RFC5234, January 2008, . 722 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 723 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 724 . 726 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 727 Domain Name Mapping", STD 69, RFC 5731, 728 DOI 10.17487/RFC5731, August 2009, . 731 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 732 Security Extensions Mapping for the Extensible 733 Provisioning Protocol (EPP)", RFC 5910, 734 DOI 10.17487/RFC5910, May 2010, . 737 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 738 Code: The Implementation Status Section", BCP 205, 739 RFC 7942, DOI 10.17487/RFC7942, July 2016, 740 . 742 Appendix A. Change History 744 Authors' Addresses 746 James Gould 747 VeriSign, Inc. 748 12061 Bluemont Way 749 Reston, VA 20190 750 US 752 Email: jgould@verisign.com 753 URI: http://www.verisigninc.com 755 Martin Casanova 756 SWITCH 757 P.O. Box 758 Zurich, ZH 8021 759 CH 761 Email: martin.casanova@switch.ch 762 URI: http://www.switch.ch