idnits 2.17.1 draft-gould-casanova-regext-unhandled-namespaces-01.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 (March 26, 2019) is 1851 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 327, but not defined == Missing Reference: 'NAMESPACE-XML' is mentioned on line 324, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3735 Summary: 2 errors (**), 0 flaws (~~), 3 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: September 27, 2019 SWITCH 6 March 26, 2019 8 Extensible Provisioning Protocol (EPP) Unhandled Namespaces 9 draft-gould-casanova-regext-unhandled-namespaces-01 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 https://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 September 27, 2019. 45 Copyright Notice 47 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 10 69 5. Usage with Poll Message EPP Responses . . . . . . . . . . . . 12 70 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 71 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 15 72 6.2. SWITCH Automated DNSSEC Provisioning Process . . . . . . 16 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 75 9. Normative References . . . . . . . . . . . . . . . . . . . . 16 76 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 17 77 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 The Extensible Provisioning Protocol (EPP), as defined in [RFC5730], 83 includes a method for the client and server to determine the objects 84 to be managed during a session and the object extensions to be used 85 during a session. The services are identified using namespace URIs. 86 How should the server handle service data that needs to be returned 87 in the response when the client does not support the required service 88 namespace URI, which is referred to as an unhandled namespace? An 89 unhandled namespace is a significant issue for the processing of 90 [RFC5730] poll messages, since poll messages are inserted by the 91 server prior to knowing the supported client services, and the client 92 needs to be capable of processing all poll messages. An unhandled 93 namespace is an issue also for general EPP responses when the server 94 has information that it cannot return to the client due to the 95 client's supported services. The server should be able to return 96 unhandled namespace information that the client can process later. 97 This document defines an operational practice that enables the server 98 to return information associated with unhandled namespace URIs that 99 is compliant with the negotiated services defined in [RFC5730]. 101 1.1. Conventions Used in This Document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 XML is case sensitive. Unless stated otherwise, XML specifications 108 and examples provided in this document MUST be interpreted in the 109 character case presented in order to develop a conforming 110 implementation. 112 In examples, "S:" represents lines returned by a protocol server. 113 Indentation and white space in examples are provided only to 114 illustrate element relationships and are not a REQUIRED feature of 115 this protocol. 117 The examples reference XML namespace prefixes that are used for the 118 associated XML namespaces. Implementations MUST NOT depend on the 119 example XML namespaces and instead employ a proper namespace-aware 120 XML parser and serializer to interpret and output the XML documents. 121 The example namespace prefixes used and their associated XML 122 namespaces include: 124 "changePoll": urn:ietf:params:xml:ns:changePoll-1.0 125 "domain": urn:ietf:params:xml:ns:domain-1.0 126 "secDNS": urn:ietf:params:xml:ns:secDNS-1.1 128 In the template example XML, placeholder content is represented by 129 the following variables: 131 "[NAMESPACE-XML]": XML content associated with a login service 132 namespace URI. An example is the element 133 content in [RFC5731]. 134 "[NAMESPACE-URI]": XML namespace URI associated with the [NAMESPACE- 135 XML] XML content. An example is "urn:ietf:params:xml:ns:domain- 136 1.0" in [RFC5731]. 138 2. Unhandled Namespaces 140 An Unhandled Namespace is an XML namespace that is associated with a 141 response extension that is not included in the client-specified EPP 142 login services of [RFC5730]. The EPP login services consists of the 143 set of XML namespace URIs included in the or 144 elements of the [RFC5730] EPP command. The services 145 supported by the server are included in the and 146 elements of the [RFC5730] EPP , which should be a superset 147 of the login services included in the EPP command. A server 148 may have information associated with a specific namespace that it 149 needs to return in the response to a client. The unhandled 150 namespaces problem exists when the server has information, that it 151 needs to return to the client, that is not supported by the client 152 based on the negotiated EPP command services. 154 3. Use of EPP for Unhandled Namespace Data 156 When a server has data to return to the client, that the client does 157 not support based on the login services, the server MAY return a 158 successful response, with the data for each unsupported namespace 159 moved into an [RFC5730] element. The unhandled namespace 160 will not cause an error response, but the unhandled namespace data 161 will instead be moved to an element, along with a reason 162 why the unhandled namespace data could not be included in the 163 appropriate location of the response. The element XML 164 will not be processed by the XML processor. The element 165 contains the following child elements: 167 : Contains a child-element with the unhandled namespace XML. 168 The XML namespace and namespace prefix of the child element MUST 169 be defined, which MAY be defined in the element or in the 170 the child element. XML processing of the element is 171 disabled in [RFC5730], so the information can safely be returned 172 in the element. 173 : A formatted human-readable message that indicates the 174 reason the unhandled namespace data was not returned in the 175 appropriate location of the response. The formatted reason 176 SHOULD follow the Augmented Backus-Naur Form (ABNF) grammar 177 [RFC5234] format: NAMESPACE-URI "not in login services", where 178 NAMESPACE-URI is the unhandled XML namespace like 179 "urn:ietf:params:xml:ns:domain-1.0" for [RFC5731]. 181 This document supports handling of unsupported namespaces for 182 [RFC3735] object-level extensions and command-response extensions. 183 This document does not support [RFC3735] protocol-level extensions or 184 authentication information extensions. Refer to the following 185 sections on how to handle an unsupported object-level extension 186 namespace or an unsupported command-response extension namespace. 188 3.1. Unhandled Object-Level Extension 190 An object-level extension in [RFC5730] is a child element of the 191 element. If the client does not handle the namespace of 192 the object-level extension, then the element is removed and 193 its object-level extension child element is moved into a [RFC5730] 194 element, with the namespace URI included in the 195 corresponding element. The response becomes a 196 general EPP response without the element. 198 Template response for a supported object-level extension. The 199 [NAMESPACE-XML] variable represents the object-level extension XML. 201 S: 202 S: 203 S: 204 S: 205 S: Command completed successfully 206 S: 207 S: 208 S: [NAMESPACE-XML] 209 S: 210 S: 211 S: ABC-12345 212 S: 54322-XYZ 213 S: 214 S: 215 S: 216 Template unhandled namespace response for an unsupported object-level 217 extension. The [NAMESPACE-XML] variable represents the object-level 218 extension XML and the [NAMESPACE-URI] variable represents the object- 219 level extension XML namespace URI. 221 S: 222 S: 223 S: 224 S: 225 S: Command completed successfully 226 S: 227 S: 228 S: [NAMESPACE-XML] 229 S: 230 S: 231 S: [NAMESPACE-URI] not in login services 232 S: 233 S: 234 S: 235 S: 236 S: ABC-12345 237 S: 54322-XYZ 238 S: 239 S: 240 S: 242 The EPP response is converted from an object response to a general 243 EPP response by the server when the client does not support the 244 object-level extension namespace URI. Below is example of converting 245 the query response example in [RFC5730] to an unhandled 246 namespace response. 248 [RFC5730] example query response converted into an 249 unhandled namespace response. 251 S: 252 S: 253 S: 254 S: 255 S: Command completed successfully 256 S: 257 S: 258 S: 260 S: example.com 261 S: pending 262 S: ClientX 263 S: 2000-06-06T22:00:00.0Z 264 S: ClientY 265 S: 2000-06-11T22:00:00.0Z 266 S: 2002-09-08T22:00:00.0Z 267 S: 268 S: 269 S: 270 S: urn:ietf:params:xml:ns:domain-1.0 not in login services 271 S: 272 S: 273 S: 274 S: 275 S: ABC-12345 276 S: 54322-XYZ 277 S: 278 S: 279 S: 281 3.2. Unhandled Command-Response Extension 283 A command-response extension in [RFC5730] is a child element of the 284 element. If the client does not handle the namespace of 285 the command-response extension, the command-response child element is 286 moved into a [RFC5730] element, with the namespace 287 URI included in the corresponding element. If 288 after moving the command-response child element there are no 289 additional command-response child elements, the element 290 MUST be removed. 292 Template response for a supported command-response extension. The 293 [NAMESPACE-XML] variable represents the command-response extension 294 XML. 296 S: 297 S: 298 S: 299 S: 300 S: Command completed successfully 301 S: 302 S: 303 S: [NAMESPACE-XML] 304 S: 305 S: 306 S: ABC-12345 307 S: 54322-XYZ 308 S: 309 S: 310 S: 312 Template unhandled namespace response for an unsupported command- 313 response extension. The [NAMESPACE-XML] variable represents the 314 command-response extension XML and the [NAMESPACE-URI] variable 315 represents the command-response extension XML namespace URI. 317 S: 318 S: 319 S: 320 S: 321 S: Command completed successfully 322 S: 323 S: 324 S: [NAMESPACE-XML] 325 S: 326 S: 327 S: [NAMESPACE-URI] not in login services 328 S: 329 S: 330 S: 331 S: 332 S: ABC-12345 333 S: 54322-XYZ 334 S: 335 S: 336 S: 338 The EPP response is converted to an unhandled namespace response by 339 moving the unhandled command-response extension from under the 340 to an element. Below is example of converting 341 the DS Data Interface response example in [RFC5910] to an 342 unhandled namespace response. 344 [RFC5910] DS Data Interface response converted into an 345 unhandled namespace response. 347 S: 348 S: 349 S: 350 S: 351 S: Command completed successfully 352 S: 353 S: 354 S: 356 S: 357 S: 12345 358 S: 3 359 S: 1 360 S: 49FD46E6C4B45C55D4AC 361 S: 362 S: 363 S: 364 S: 365 S: urn:ietf:params:xml:ns:secDNS-1.1 not in login services 366 S: 367 S: 368 S: 369 S: 370 S: 372 S: example.com 373 S: EXAMPLE1-REP 374 S: 375 S: jd1234 376 S: sh8013 377 S: sh8013 378 S: 379 S: ns1.example.com 380 S: ns2.example.com 381 S: 382 S: ns1.example.com 383 S: ns2.example.com 384 S: ClientX 385 S: ClientY 386 S: 1999-04-03T22:00:00.0Z 387 S: ClientX 388 S: 1999-12-03T09:00:00.0Z 389 S: 2005-04-03T22:00:00.0Z 390 S: 2000-04-08T09:00:00.0Z 391 S: 392 S: 2fooBAR 393 S: 394 S: 395 S: 396 S: 397 S: ABC-12345 398 S: 54322-XYZ 399 S: 400 S: 401 S: 403 4. Usage with General EPP Responses 405 The unhandled namespace approach defined in Section 3 MAY be used for 406 a general EPP response to an EPP command. A general EPP response 407 includes any non-poll message EPP response. The use of the unhandled 408 namespace approach for poll message EPP responses is defined in 409 Section 5. The server MAY exclude the unhandled namespace 410 information in the general EPP response or MAY include it using the 411 unhandled namespace approach. 413 The unhandled namespace approach for general EPP responses SHOULD 414 only be applicable to command-response extensions, defined in 415 Section 3.2, since the server SHOULD NOT accept an object-level EPP 416 command if the client did not include the object-level namespace URI 417 in the login services. An object-level EPP response extension is 418 returned when the server successfully executes an object-level EPP 419 command extension. The server MAY return an unhandled object-level 420 extension to the client as defined in Section 3.1. 422 Returning domain name Redemption Grace Period (RGP) data, based on 423 [RFC3915], provides an example of applying the unhandled namespace 424 approach for a general EPP response. If the client does not include 425 the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the login 426 services, and the domain response of a domain name does have 427 RGP information, the server MAY exclude the element 428 from the EPP response or MAY include it under in the 429 element per Section 3.2. 431 [RFC5731] domain name response with the unhandled [RFC3915] 432 element included under an element: 434 S: 435 S: 436 S: 437 S: 438 S: Command completed successfully 439 S: 440 S: 441 S: 442 S: 443 S: 444 S: 445 S: 446 S: urn:ietf:params:xml:ns:rgp-1.0 not in login services 447 S: 448 S: 449 S: 450 S: 451 S: 453 S: example.com 454 S: EXAMPLE1-REP 455 S: 456 S: jd1234 457 S: sh8013 458 S: sh8013 459 S: 460 S: ns1.example.com 461 S: ns1.example.net 462 S: 463 S: ns1.example.com 464 S: ns2.example.com 465 S: ClientX 466 S: ClientY 467 S: 1999-04-03T22:00:00.0Z 468 S: ClientX 469 S: 1999-12-03T09:00:00.0Z 470 S: 2005-04-03T22:00:00.0Z 471 S: 2000-04-08T09:00:00.0Z 472 S: 473 S: 2fooBAR 474 S: 475 S: 476 S: 477 S: 478 S: ABC-12345 479 S: 54322-XYZ 480 S: 481 S: 482 S: 484 5. Usage with Poll Message EPP Responses 486 The unhandled namespace approach, defined in Section 3, MUST be used 487 if there is unhandled namespace information included in an EPP 488 message response. The server inserts poll messages into the client's 489 poll queue independent of knowing the supported client login 490 services, therefore there may be unhandled object-level and command- 491 response extensions included in a client's poll queue. In [RFC5730], 492 the command is used by the client to retrieve and acknowledge 493 poll messages that have been inserted by the server. The 494 message response is an EPP response that includes the element 495 that provides poll queue meta-data about the message. The unhandled 496 namespace approach, defined in Section 3, is used for an unhandled 497 object-level extension and for each of the unhandled command-response 498 extensions attached to the message response. The resulting 499 EPP message response MAY have either or both the object-level 500 extension or command-response extensions moved to 501 elements, as defined in Section 3. 503 The Change Poll Message, as defined in [I-D.ietf-regext-change-poll], 504 which is an extension of any EPP object, is an example of applying 505 the unhandled namespace approach for EPP message responses. 506 The object that will be used in the examples is a [RFC5731] domain 507 name object. 509 [RFC5731] domain name message response with the 510 unhandled [I-D.ietf-regext-change-poll] 511 element included under an element: 513 S: 514 S: 515 S: 516 S: 517 S: Command completed successfully; ack to dequeue 518 S: 519 S: 520 S: 523 S: update 524 S: 525 S: 2013-11-22T05:00:00.000Z 526 S: 12345-XYZ 527 S: URS Admin 528 S: urs123 529 S: 530 S: URS Lock 531 S: 532 S: 533 S: 534 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services 535 S: 536 S: 537 S: 538 S: 542 S: 2018-08-24T19:21:51.087Z 543 S: Registry initiated update of domain. 544 S: 545 S: 546 S: 548 S: change-poll.tld 549 S: EXAMPLE1-REP 550 S: 551 S: 552 S: 553 S: jd1234 554 S: sh8013 555 S: sh8013 556 S: ClientX 557 S: ClientY 558 S: 2012-05-03T04:00:00.000Z 559 S: ClientZ 560 S: 2013-11-22T05:00:00.000Z 561 S: 2014-05-03T04:00:00.000Z 562 S: 563 S: 564 S: 565 S: ABC-12345 566 S: 54322-XYZ 567 S: 568 S: 569 S: 571 Unhandled [RFC5731] domain name message response and 572 the unhandled [I-D.ietf-regext-change-poll] 573 element included under an element: 575 S: 576 S: 577 S: 578 S: 579 S: Command completed successfully; ack to dequeue 580 S: 581 S: 582 S: 584 S: change-poll.tld 585 S: EXAMPLE1-REP 586 S: 587 S: 588 S: 589 S: jd1234 590 S: sh8013 591 S: sh8013 592 S: ClientX 593 S: ClientY 594 S: 2012-05-03T04:00:00.000Z 595 S: ClientZ 596 S: 2013-11-22T05:00:00.000Z 597 S: 2014-05-03T04:00:00.000Z 598 S: 599 S: 600 S: 601 S: urn:ietf:params:xml:ns:domain-1.0 not in login services 602 S: 603 S: 604 S: 605 S: 606 S: 609 S: update 610 S: 611 S: 2013-11-22T05:00:00.000Z 612 S: 12345-XYZ 613 S: URS Admin 614 S: urs123 615 S: 616 S: URS Lock 617 S: 618 S: 619 S: 620 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services 621 S: 622 S: 623 S: 624 S: 628 S: 2018-08-24T19:23:12.822Z 629 S: Registry initiated update of domain. 630 S: 631 S: 632 S: ABC-12345 633 S: 54322-XYZ 634 S: 635 S: 636 S: 638 6. Implementation Status 640 Note to RFC Editor: Please remove this section and the reference to 641 RFC 7942 [RFC7942] before publication. 643 This section records the status of known implementations of the 644 protocol defined by this specification at the time of posting of this 645 Internet-Draft, and is based on a proposal described in RFC 7942 646 [RFC7942]. The description of implementations in this section is 647 intended to assist the IETF in its decision processes in progressing 648 drafts to RFCs. Please note that the listing of any individual 649 implementation here does not imply endorsement by the IETF. 650 Furthermore, no effort has been spent to verify the information 651 presented here that was supplied by IETF contributors. This is not 652 intended as, and must not be construed to be, a catalog of available 653 implementations or their features. Readers are advised to note that 654 other implementations may exist. 656 According to RFC 7942 [RFC7942], "this will allow reviewers and 657 working groups to assign due consideration to documents that have the 658 benefit of running code, which may serve as evidence of valuable 659 experimentation and feedback that have made the implemented protocols 660 more mature. It is up to the individual working groups to use this 661 information as they see fit". 663 6.1. Verisign EPP SDK 665 Organization: Verisign Inc. 667 Name: Verisign EPP SDK 669 Description: The Verisign EPP SDK includes an implementation of the 670 unhandled namespaces for the processing of the poll queue messages. 672 Level of maturity: Development 674 Coverage: All aspects of the protocol are implemented. 676 Licensing: GNU Lesser General Public License 678 Contact: jgould@verisign.com 680 URL: https://www.verisign.com/en_US/channel-resources/domain- 681 registry-products/epp-sdks 683 6.2. SWITCH Automated DNSSEC Provisioning Process 685 Organization: SWITCH 687 Name: Registry of .CH and .LI 689 Description: SWITCH uses poll messages to inform the registrar about 690 DNSSEC changes at the registry triggered by CDS records. These poll 691 messages are enriched with the 'urn:ietf:params:xml:ns:changePoll- 692 1.0' and the 'urn:ietf:params:xml:ns:secDNS-1.1' extension that are 693 rendered in the poll msg response according to this draft. 695 Level of maturity: Operational 697 Coverage: All aspects of the protocol are implemented. 699 Licensing: Proprietary 701 Contact: martin.casanova@switch.ch 703 URL: https://www.nic.ch/cds 705 7. Security Considerations 707 The document do not provide any security services beyond those 708 described by EPP [RFC5730] and protocol layers used by EPP. The 709 security considerations described in these other specifications apply 710 to this specification as well. 712 8. Acknowledgements 714 TBD 716 9. Normative References 718 [I-D.ietf-regext-change-poll] 719 Gould, J. and K. Feher, "Change Poll Extension for the 720 Extensible Provisioning Protocol (EPP)", draft-ietf- 721 regext-change-poll-12 (work in progress), January 2019. 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, 725 DOI 10.17487/RFC2119, March 1997, 726 . 728 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 729 Provisioning Protocol (EPP)", RFC 3735, 730 DOI 10.17487/RFC3735, March 2004, 731 . 733 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 734 the Extensible Provisioning Protocol (EPP)", RFC 3915, 735 DOI 10.17487/RFC3915, September 2004, 736 . 738 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 739 Specifications: ABNF", STD 68, RFC 5234, 740 DOI 10.17487/RFC5234, January 2008, 741 . 743 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 744 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 745 . 747 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 748 Domain Name Mapping", STD 69, RFC 5731, 749 DOI 10.17487/RFC5731, August 2009, 750 . 752 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 753 Security Extensions Mapping for the Extensible 754 Provisioning Protocol (EPP)", RFC 5910, 755 DOI 10.17487/RFC5910, May 2010, 756 . 758 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 759 Code: The Implementation Status Section", BCP 205, 760 RFC 7942, DOI 10.17487/RFC7942, July 2016, 761 . 763 Appendix A. Change History 765 A.1. Change from 00 to 01 767 1. Removed xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 768 reference from examples. 769 2. removed block from example. 771 3. added SWITCH Automated DNSSEC Provisioning Process at 772 Implementation Status 774 Authors' Addresses 776 James Gould 777 VeriSign, Inc. 778 12061 Bluemont Way 779 Reston, VA 20190 780 US 782 Email: jgould@verisign.com 783 URI: http://www.verisigninc.com 785 Martin Casanova 786 SWITCH 787 P.O. Box 788 Zurich, ZH 8021 789 CH 791 Email: martin.casanova@switch.ch 792 URI: http://www.switch.ch