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