idnits 2.17.1 draft-ietf-regext-unhandled-namespaces-07.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 date (26 January 2021) is 1186 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (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 351, but not defined == Missing Reference: 'NAMESPACE-XML' is mentioned on line 348, but not defined Summary: 0 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: Standards Track M. Casanova 5 Expires: 30 July 2021 SWITCH 6 26 January 2021 8 Extensible Provisioning Protocol (EPP) Unhandled Namespaces 9 draft-ietf-regext-unhandled-namespaces-07 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 and an "unhandled namespace" is one that is associated with a service 18 not supported by the client. This document defines an operational 19 practice that enables the server to return information associated 20 with unhandled namespace URIs that is compliant with the negotiated 21 services defined in RFC 5730. 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 https://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 30 July 2021. 40 Copyright Notice 42 Copyright (c) 2021 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 (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 58 2. Unhandled Namespaces . . . . . . . . . . . . . . . . . . . . 4 59 3. Use of EPP for Unhandled Namespace Data . . . . . 4 60 3.1. Unhandled Object-Level Extension . . . . . . . . . . . . 5 61 3.2. Unhandled Command-Response Extension . . . . . . . . . . 7 62 4. Signaling Client and Server Support . . . . . . . . . . . . . 10 63 5. Usage with General EPP Responses . . . . . . . . . . . . . . 10 64 6. Usage with Poll Message EPP Responses . . . . . . . . . . . . 12 65 7. Implementation Considerations . . . . . . . . . . . . . . . . 15 66 7.1. Client Implementation Considerations . . . . . . . . . . 15 67 7.2. Server Implementation Considerations . . . . . . . . . . 16 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 16 70 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 16 71 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 72 9.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 17 73 9.2. SWITCH Automated DNSSEC Provisioning Process . . . . . . 18 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 78 12.2. Informative References . . . . . . . . . . . . . . . . . 20 79 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 20 80 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 20 81 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 20 82 A.3. Change from 02 to REGEXT 00 . . . . . . . . . . . . . . . 20 83 A.4. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 20 84 A.5. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 21 85 A.6. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 21 86 A.7. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 21 87 A.8. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 21 88 A.9. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 21 89 A.10. Change from REGEXT 06 to REGEXT 07 . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 The Extensible Provisioning Protocol (EPP), as defined in [RFC5730], 95 includes a method for the client and server to determine the objects 96 to be managed during a session and the object extensions to be used 97 during a session. The services are identified using namespace URIs. 98 How should the server handle service data that needs to be returned 99 in the response when the client does not support the required service 100 namespace URI, which is referred to as an unhandled namespace? An 101 unhandled namespace is a significant issue for the processing of 102 [RFC5730] poll messages, since poll messages are inserted by the 103 server prior to knowing the supported client services, and the client 104 needs to be capable of processing all poll messages. An unhandled 105 namespace is an issue also for general EPP responses when the server 106 has information that it cannot return to the client due to the 107 client's supported services. The server should be able to return 108 unhandled namespace information that the client can process later. 109 This document defines an operational practice that enables the server 110 to return information associated with unhandled namespace URIs that 111 is compliant with the negotiated services defined in [RFC5730]. 113 1.1. Conventions Used in This Document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 XML is case sensitive. Unless stated otherwise, XML specifications 122 and examples provided in this document MUST be interpreted in the 123 character case presented in order to develop a conforming 124 implementation. 126 In examples, "S:" represents lines returned by a protocol server. 127 Indentation and white space in examples are provided only to 128 illustrate element relationships and are not a required feature of 129 this protocol. 131 The examples reference XML namespace prefixes that are used for the 132 associated XML namespaces. Implementations MUST NOT depend on the 133 example XML namespaces and instead employ a proper namespace-aware 134 XML parser and serializer to interpret and output the XML documents. 135 The example namespace prefixes used and their associated XML 136 namespaces include: 138 "changePoll": urn:ietf:params:xml:ns:changePoll-1.0 139 "domain": urn:ietf:params:xml:ns:domain-1.0 140 "secDNS": urn:ietf:params:xml:ns:secDNS-1.1 142 In the template example XML, placeholder content is represented by 143 the following variables: 145 "[NAMESPACE-XML]": XML content associated with a login service 146 namespace URI. An example is the element 147 content in [RFC5731]. 148 "[NAMESPACE-URI]": XML namespace URI associated with the [NAMESPACE- 149 XML] XML content. An example is "urn:ietf:params:xml:ns:domain- 150 1.0" in [RFC5731]. 152 2. Unhandled Namespaces 154 An Unhandled Namespace is an XML namespace that is associated with a 155 response extension that is not included in the client-specified EPP 156 login services of [RFC5730]. The EPP login services consists of the 157 set of XML namespace URIs included in the or 158 elements of the [RFC5730] EPP command. The services 159 supported by the server are included in the and 160 elements of the [RFC5730] EPP , which should be a superset 161 of the login services included in the EPP command. A server 162 may have information associated with a specific namespace that it 163 needs to return in the response to a client. The unhandled 164 namespaces problem exists when the server has information that it 165 needs to return to the client but the namespace of the information is 166 not supported by the client based on the negotiated EPP 167 command services. 169 3. Use of EPP for Unhandled Namespace Data 171 In [RFC5730], the element is used to provide additional 172 error diagnostic information, including the element that 173 identifies the client-provided element that caused a server error 174 condition and the element containing the human-readable 175 message that describes the reason for the error. This operational 176 practice extends the use of the element for the purpose of 177 returning unhandled namespace information in a successful response. 179 When a server has data to return to the client that the client does 180 not support based on the login services, the server MAY return a 181 successful response, with the data for each unsupported namespace 182 moved into an [RFC5730] element. The unhandled namespace 183 will not cause an error response, but the unhandled namespace data 184 will instead be moved to an element, along with a reason 185 why the unhandled namespace data could not be included in the 186 appropriate location of the response. The element XML 187 will not be processed by the XML processor. The element 188 contains the following child elements: 190 : Contains a child-element with the unhandled namespace XML. 191 The XML namespace and namespace prefix of the child element MUST 192 be defined, which MAY be defined in the element or in the 193 the child element. XML processing of the element is 194 disabled by the XML schema in [RFC5730], so the information can 195 safely be returned in the element. 196 : A formatted human-readable message that indicates the 197 reason the unhandled namespace data was not returned in the 198 appropriate location of the response. The formatted reason 199 SHOULD follow the Augmented Backus-Naur Form (ABNF) grammar 200 [RFC5234] format: NAMESPACE-URI "not in login services", where 201 NAMESPACE-URI is the unhandled XML namespace like 202 "urn:ietf:params:xml:ns:domain-1.0" for [RFC5731]. 204 This document supports handling of unsupported namespaces for 205 [RFC3735] object-level extensions and command-response extensions. 206 This document does not support [RFC3735] protocol-level extensions or 207 authentication information extensions. Refer to the following 208 sections on how to handle an unsupported object-level extension 209 namespace or an unsupported command-response extension namespace. 211 3.1. Unhandled Object-Level Extension 213 An object-level extension in [RFC5730] is a child element of the 214 element. If the client does not handle the namespace of 215 the object-level extension, then the element is removed and 216 its object-level extension child element is moved into a [RFC5730] 217 element, with the namespace URI included in the 218 corresponding element. The response becomes a 219 general EPP response without the element. 221 Template response for a supported object-level extension. The 222 [NAMESPACE-XML] variable represents the object-level extension XML. 224 S: 225 S: 226 S: 227 S: 228 S: Command completed successfully 229 S: 230 S: 231 S: [NAMESPACE-XML] 232 S: 233 S: 234 S: ABC-12345 235 S: 54322-XYZ 236 S: 237 S: 238 S: 240 Template unhandled namespace response for an unsupported object-level 241 extension. The [NAMESPACE-XML] variable represents the object-level 242 extension XML and the [NAMESPACE-URI] variable represents the object- 243 level extension XML namespace URI. 245 S: 246 S: 247 S: 248 S: 249 S: Command completed successfully 250 S: 251 S: 252 S: [NAMESPACE-XML] 253 S: 254 S: 255 S: [NAMESPACE-URI] not in login services 256 S: 257 S: 258 S: 259 S: 260 S: ABC-12345 261 S: 54322-XYZ 262 S: 263 S: 264 S: 266 The EPP response is converted from an object response to a general 267 EPP response by the server when the client does not support the 268 object-level extension namespace URI. Below is example of converting 269 the query response example in [RFC5731] to an unhandled 270 namespace response. 272 [RFC5731] example query response converted into an 273 unhandled namespace response. 275 S: 276 S: 277 S: 278 S: 279 S: Command completed successfully 280 S: 281 S: 282 S: 284 S: example.com 285 S: pending 286 S: ClientX 287 S: 2020-06-06T22:00:00.0Z 288 S: ClientY 289 S: 2020-06-11T22:00:00.0Z 290 S: 2021-09-08T22:00:00.0Z 291 S: 292 S: 293 S: 294 S: urn:ietf:params:xml:ns:domain-1.0 not in login services 295 S: 296 S: 297 S: 298 S: 299 S: ABC-12345 300 S: 54322-XYZ 301 S: 302 S: 303 S: 305 3.2. Unhandled Command-Response Extension 307 A command-response extension in [RFC5730] is a child element of the 308 element. If the client does not handle the namespace of 309 the command-response extension, the command-response child element is 310 moved into a [RFC5730] element, with the namespace 311 URI included in the corresponding element. If 312 after moving the command-response child element there are no 313 additional command-response child elements, the element 314 MUST be removed. 316 Template response for a supported command-response extension. The 317 [NAMESPACE-XML] variable represents the command-response extension 318 XML. 320 S: 321 S: 322 S: 323 S: 324 S: Command completed successfully 325 S: 326 S: 327 S: [NAMESPACE-XML] 328 S: 329 S: 330 S: ABC-12345 331 S: 54322-XYZ 332 S: 333 S: 334 S: 336 Template unhandled namespace response for an unsupported command- 337 response extension. The [NAMESPACE-XML] variable represents the 338 command-response extension XML and the [NAMESPACE-URI] variable 339 represents the command-response extension XML namespace URI. 341 S: 342 S: 343 S: 344 S: 345 S: Command completed successfully 346 S: 347 S: 348 S: [NAMESPACE-XML] 349 S: 350 S: 351 S: [NAMESPACE-URI] not in login services 352 S: 353 S: 354 S: 355 S: 356 S: ABC-12345 357 S: 54322-XYZ 358 S: 359 S: 360 S: 362 The EPP response is converted to an unhandled namespace response by 363 moving the unhandled command-response extension from under the 364 to an element. Below is example of converting 365 the DS Data Interface response example in [RFC5910] to an 366 unhandled namespace response. 368 [RFC5910] DS Data Interface response converted into an 369 unhandled namespace response. 371 S: 372 S: 373 S: 374 S: 375 S: Command completed successfully 376 S: 377 S: 378 S: 380 S: 381 S: 12345 382 S: 3 383 S: 1 384 S: 49FD46E6C4B45C55D4AC 385 S: 386 S: 387 S: 388 S: 389 S: urn:ietf:params:xml:ns:secDNS-1.1 not in login services 390 S: 391 S: 392 S: 393 S: 394 S: 396 S: example.com 397 S: EXAMPLE1-REP 398 S: 399 S: jd1234 400 S: sh8013 401 S: sh8013 402 S: 403 S: ns1.example.com 404 S: ns2.example.com 405 S: 406 S: ns1.example.com 407 S: ns2.example.com 408 S: ClientX 409 S: ClientY 410 S: 1999-04-03T22:00:00.0Z 411 S: ClientX 412 S: 1999-12-03T09:00:00.0Z 413 S: 2005-04-03T22:00:00.0Z 414 S: 2000-04-08T09:00:00.0Z 415 S: 416 S: 2fooBAR 417 S: 418 S: 419 S: 420 S: 421 S: ABC-12345 422 S: 54322-XYZ 423 S: 424 S: 425 S: 427 4. Signaling Client and Server Support 429 This document does not define new protocol but an operational 430 practice using the existing EPP protocol, where the client and the 431 server can signal support for the operational practice using a 432 namespace URI in the login and greeting extension services. The 433 namespace URI "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" 434 is used to signal support for the operational practice. The client 435 includes the namespace URI in an element of 436 the [RFC5730] Command. The server includes the namespace URI 437 in an element of the [RFC5730] Greeting. 439 A client that receives the namespace URI in the server's Greeting 440 extension services can expect the following supported behavior by the 441 server: 443 1. Support unhandled namespace object-level extensions and command- 444 response extensions in EPP poll messages, per Section 6. 445 2. Support the option of unhandled namespace command-response 446 extensions in general EPP responses, per Section 5. 448 A server that receives the namespace URI in the client's 449 Command extension services can expect the following supported 450 behavior by the client: 452 1. Support monitoring the EPP poll messages and general EPP 453 responses for unhandled namespaces. 455 5. Usage with General EPP Responses 457 The unhandled namespace approach defined in Section 3 MAY be used for 458 a general EPP response to an EPP command. A general EPP response 459 includes any non-poll message EPP response. The use of the unhandled 460 namespace approach for poll message EPP responses is defined in 461 Section 6. The server MAY exclude the unhandled namespace 462 information in the general EPP response or MAY include it using the 463 unhandled namespace approach. 465 The unhandled namespace approach for general EPP responses SHOULD 466 only be applicable to command-response extensions, defined in 467 Section 3.2, since the server SHOULD NOT accept an object-level EPP 468 command if the client did not include the object-level namespace URI 469 in the login services. An object-level EPP response extension is 470 returned when the server successfully executes an object-level EPP 471 command extension. The server MAY return an unhandled object-level 472 extension to the client as defined in Section 3.1. 474 Returning domain name Redemption Grace Period (RGP) data, based on 475 [RFC3915], provides an example of applying the unhandled namespace 476 approach for a general EPP response. If the client does not include 477 the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the login 478 services, and the domain response of a domain name does have 479 RGP information, the server MAY exclude the element 480 from the EPP response or MAY include it under the element 481 per Section 3.2. 483 [RFC5731] domain name response with the unhandled [RFC3915] 484 element included under an element: 486 S: 487 S: 488 S: 489 S: 490 S: Command completed successfully 491 S: 492 S: 493 S: 494 S: 495 S: 496 S: 497 S: 498 S: urn:ietf:params:xml:ns:rgp-1.0 not in login services 499 S: 500 S: 501 S: 502 S: 503 S: 505 S: example.com 506 S: EXAMPLE1-REP 507 S: 508 S: jd1234 509 S: sh8013 510 S: sh8013 511 S: 512 S: ns1.example.com 513 S: ns1.example.net 514 S: 515 S: ns1.example.com 516 S: ns2.example.com 517 S: ClientX 518 S: ClientY 519 S: 1999-04-03T22:00:00.0Z 520 S: ClientX 521 S: 2020-12-03T09:00:00.0Z 522 S: 2021-04-03T22:00:00.0Z 523 S: 2000-04-08T09:00:00.0Z 524 S: 525 S: 2fooBAR 526 S: 527 S: 528 S: 529 S: 530 S: ABC-12345 531 S: 54322-XYZ 532 S: 533 S: 534 S: 536 6. Usage with Poll Message EPP Responses 538 The unhandled namespace approach, defined in Section 3, MUST be used 539 if there is unhandled namespace information included in an EPP 540 message response. The server inserts poll messages into the client's 541 poll queue independent of knowing the supported client login 542 services, therefore there may be unhandled object-level and command- 543 response extensions included in a client's poll queue. In [RFC5730], 544 the command is used by the client to retrieve and acknowledge 545 poll messages that have been inserted by the server. The 546 message response is an EPP response that includes the element 547 that provides poll queue meta-data about the message. The unhandled 548 namespace approach, defined in Section 3, is used for an unhandled 549 object-level extension and for each of the unhandled command-response 550 extensions attached to the message response. The resulting 551 EPP message response MAY have either or both the object-level 552 extension or command-response extensions moved to 553 elements, as defined in Section 3. 555 The Change Poll Message, as defined in [RFC8590], which is an 556 extension of any EPP object, is an example of applying the unhandled 557 namespace approach for EPP message responses. The object that 558 will be used in the examples is a [RFC5731] domain name object. 560 [RFC5731] domain name message response with the 561 unhandled [RFC8590] element included under an 562 element: 564 S: 565 S: 566 S: 567 S: 568 S: Command completed successfully; ack to dequeue 569 S: 570 S: 571 S: 575 S: update 576 S: 577 S: 2020-11-22T05:00:00.000Z 578 S: 12345-XYZ 579 S: URS Admin 580 S: urs123 581 S: 582 S: URS Lock 583 S: 584 S: 585 S: 586 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services 587 S: 588 S: 589 S: 590 S: 591 S: 2020-11-22T05:00:00.000Z 592 S: Registry initiated update of domain. 593 S: 594 S: 595 S: 597 S: change-poll.tld 598 S: EXAMPLE1-REP 599 S: 600 S: 601 S: 602 S: jd1234 603 S: sh8013 604 S: sh8013 605 S: ClientX 606 S: ClientY 607 S: 2012-05-03T04:00:00.000Z 608 S: ClientZ 609 S: 2020-11-22T05:00:00.000Z 610 S: 2021-05-03T04:00:00.000Z 611 S: 612 S: 613 S: 614 S: ABC-12345 615 S: 54322-XYZ 616 S: 617 S: 618 S: 620 Unhandled [RFC5731] domain name message response and 621 the unhandled [RFC8590] element included 622 under an element: 624 S: 625 S: 626 S: 627 S: 628 S: Command completed successfully; ack to dequeue 629 S: 630 S: 631 S: 633 S: change-poll.tld 634 S: EXAMPLE1-REP 635 S: 636 S: 637 S: 638 S: jd1234 639 S: sh8013 640 S: sh8013 641 S: ClientX 642 S: ClientY 643 S: 2012-05-03T04:00:00.000Z 644 S: ClientZ 645 S: 2020-11-22T05:00:00.000Z 646 S: 2021-05-03T04:00:00.000Z 647 S: 648 S: 649 S: 650 S: urn:ietf:params:xml:ns:domain-1.0 not in login services 651 S: 652 S: 653 S: 654 S: 655 S: 658 S: update 659 S: 660 S: 2020-11-22T05:00:00.000Z 661 S: 12345-XYZ 662 S: URS Admin 663 S: urs123 664 S: 665 S: URS Lock 666 S: 667 S: 668 S: 669 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services 670 S: 671 S: 672 S: 673 S: 674 S: 2020-11-22T05:00:00.000Z 675 S: Registry initiated update of domain. 676 S: 677 S: 678 S: ABC-12345 679 S: 54322-XYZ 680 S: 681 S: 682 S: 684 7. Implementation Considerations 686 There are implementation considerations for the client and the server 687 to help address the risk of the client ignoring unhandled namespace 688 information included in an EPP response that is needed to meet 689 technical, policy, or legal requirements. 691 7.1. Client Implementation Considerations 693 To reduce the likelihood of a client receiving unhandled namespace 694 information, the client should consider implementing the following: 696 1. Ensure that the client presents the complete set of what it 697 supports when presenting its login services. If there are gaps 698 between the services supported by the client and the login 699 services included in the login command, the client may receive 700 unhandled namespace information that the client could have 701 supported. 703 2. Support all of the services included in the server greeting 704 services that may be included in an EPP response, including the 705 poll queue responses. The client should evaluate the gaps 706 between the greeting services and the login services provided in 707 the login command to identify extensions that need to be 708 supported. 709 3. Proactively monitor for unhandled namespace information in the 710 EPP responses, by looking for the inclusion of the 711 element in successful responses, recording the unsupported 712 namespace included in the element, and recording the 713 unhandled namespace information included in the element 714 for later processing. The unhandled namespace should be 715 implemented by the client to ensure that information is processed 716 fully in future EPP responses. 718 7.2. Server Implementation Considerations 720 To assist the clients in recognizing unhandled namespaces, the server 721 should consider implementing the following: 723 1. Monitor for returning unhandled namespace information to clients 724 and report it to the clients out-of-band to EPP so the clients 725 can add support for the unhandled namespaces. 726 2. Look for the unhandled namespace support in the login services 727 when returning optional unhandled namespace information in 728 General EPP Responses. 730 8. IANA Considerations 732 8.1. XML Namespace 734 This document uses URNs to describe XML namespaces conforming to a 735 registry mechanism described in [RFC3688]. The following URI 736 assignment is requested of IANA: 738 Registration request for the unhandled namespaces namespace: 740 URI: urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0 741 Registrant Contact: IESG 742 XML: None. Namespace URIs do not represent an XML specification. 744 8.2. EPP Extension Registry 746 The EPP operational practice described in this document should be 747 registered by the IANA in the EPP Extension Registry described in 748 [RFC7451]. The details of the registration are as follows: 750 Name of Extension: "Extensible Provisioning Protocol (EPP) Unhandled 751 Namespaces" 753 Document status: Standards Track 755 Reference: (insert reference to RFC version of this document) 757 Registrant Name and Email Address: IETF, 759 TLDs: Any 761 IPR Disclosure: None 763 Status: Active 765 Notes: None 767 9. Implementation Status 769 Note to RFC Editor: Please remove this section and the reference to 770 RFC 7942 [RFC7942] before publication. 772 This section records the status of known implementations of the 773 protocol defined by this specification at the time of posting of this 774 Internet-Draft, and is based on a proposal described in RFC 7942 775 [RFC7942]. The description of implementations in this section is 776 intended to assist the IETF in its decision processes in progressing 777 drafts to RFCs. Please note that the listing of any individual 778 implementation here does not imply endorsement by the IETF. 779 Furthermore, no effort has been spent to verify the information 780 presented here that was supplied by IETF contributors. This is not 781 intended as, and must not be construed to be, a catalog of available 782 implementations or their features. Readers are advised to note that 783 other implementations may exist. 785 According to RFC 7942 [RFC7942], "this will allow reviewers and 786 working groups to assign due consideration to documents that have the 787 benefit of running code, which may serve as evidence of valuable 788 experimentation and feedback that have made the implemented protocols 789 more mature. It is up to the individual working groups to use this 790 information as they see fit". 792 9.1. Verisign EPP SDK 794 Organization: Verisign Inc. 796 Name: Verisign EPP SDK 797 Description: The Verisign EPP SDK includes an implementation of the 798 unhandled namespaces for the processing of the poll queue messages. 800 Level of maturity: Development 802 Coverage: All aspects of the protocol are implemented. 804 Licensing: GNU Lesser General Public License 806 Contact: jgould@verisign.com 808 URL: https://www.verisign.com/en_US/channel-resources/domain- 809 registry-products/epp-sdks 811 9.2. SWITCH Automated DNSSEC Provisioning Process 813 Organization: SWITCH 815 Name: Registry of .CH and .LI 817 Description: SWITCH uses poll messages to inform the registrar about 818 DNSSEC changes at the registry triggered by CDS records. These poll 819 messages are enriched with the 'urn:ietf:params:xml:ns:changePoll- 820 1.0' and the 'urn:ietf:params:xml:ns:secDNS-1.1' extension that are 821 rendered in the poll msg response according to this draft. 823 Level of maturity: Operational 825 Coverage: All aspects of the protocol are implemented. 827 Licensing: Proprietary 829 Contact: martin.casanova@switch.ch 831 URL: https://www.nic.ch/cds 833 10. Security Considerations 835 This document does not provide any security services beyond those 836 described by EPP [RFC5730] and protocol layers used by EPP. The 837 security considerations described in these other specifications apply 838 to this specification as well. Since the unhandled namespace context 839 is XML that is not processed in the first pass by the XML parser, the 840 client SHOULD consider validating the XML when the content is 841 processed to protect against the inclusion of malicious content. 843 11. Acknowledgements 845 The authors wish to thank the following persons for their feedback 846 and suggestions: Thomas Corte, Scott Hollenbeck, Patrick Mevzek, and 847 Marcel Parodi. 849 12. References 851 12.1. Normative References 853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 854 Requirement Levels", BCP 14, RFC 2119, 855 DOI 10.17487/RFC2119, March 1997, 856 . 858 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 859 DOI 10.17487/RFC3688, January 2004, 860 . 862 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 863 the Extensible Provisioning Protocol (EPP)", RFC 3915, 864 DOI 10.17487/RFC3915, September 2004, 865 . 867 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 868 Specifications: ABNF", STD 68, RFC 5234, 869 DOI 10.17487/RFC5234, January 2008, 870 . 872 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 873 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 874 . 876 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 877 Domain Name Mapping", STD 69, RFC 5731, 878 DOI 10.17487/RFC5731, August 2009, 879 . 881 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 882 Security Extensions Mapping for the Extensible 883 Provisioning Protocol (EPP)", RFC 5910, 884 DOI 10.17487/RFC5910, May 2010, 885 . 887 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 888 Code: The Implementation Status Section", BCP 205, 889 RFC 7942, DOI 10.17487/RFC7942, July 2016, 890 . 892 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 893 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 894 May 2017, . 896 [RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the 897 Extensible Provisioning Protocol (EPP)", RFC 8590, 898 DOI 10.17487/RFC8590, May 2019, 899 . 901 12.2. Informative References 903 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 904 Provisioning Protocol (EPP)", RFC 3735, 905 DOI 10.17487/RFC3735, March 2004, 906 . 908 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 909 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 910 February 2015, . 912 Appendix A. Change History 914 A.1. Change from 00 to 01 916 1. Removed xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 917 reference from examples. 918 2. removed block from example. 919 3. added SWITCH Automated DNSSEC Provisioning Process at 920 Implementation Status 922 A.2. Change from 01 to 02 924 1. Ping update 926 A.3. Change from 02 to REGEXT 00 928 1. Changed to regext working group draft by changing draft-gould- 929 casanova-regext-unhandled-namespaces to draft-ietf-regext- 930 unhandled-namespaces. 932 A.4. Change from REGEXT 00 to REGEXT 01 934 1. Added the "Signaling Client and Server Support" section to 935 describe the mechanism to signal support for the BCP by the 936 client and the server. 938 2. Added the IANA Considerations section with the registration of 939 the unhandled namespaces XML namespace and the registration of 940 the EPP Best Current Practice (BCP) in the EPP Extension 941 Registry. 943 A.5. Change from REGEXT 01 to REGEXT 02 945 1. Filled in the acknowledgements section. 946 2. Changed the reference from RFC 5730 to RFC 5731 for the transfer 947 example in section 3.1 "Unhandled Object-Level" Extension. 948 3. Updated the XML namespace to 949 urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0, which 950 removed bcp from the namespace and bumped the version from 0.1 951 and 1.0. Inclusion of bcp in the XML namespace was discussed at 952 the REGEXT interim meeting. 954 A.6. Change from REGEXT 02 to REGEXT 03 956 1. Converted from xml2rfc v2 to v3. 957 2. Updated Acknowledgements to match the approach taken by the RFC 958 Editor with draft-ietf-regext-login-security. 959 3. Changed reference of ietf-regext-change-poll to RFC 8590. 961 A.7. Change from REGEXT 03 to REGEXT 04 963 1. Changed from Best Current Practice (BCP) to Standards Track based 964 on mailing list discussion. 965 2. Revised the dates in the examples to be more up-to-date. 967 A.8. Change from REGEXT 04 to REGEXT 05 969 1. Based on feedback from Thomas Corte, added a description of the 970 element in RFC 5730 and it being extended to support 971 returning unhandled namespace information. 972 2. Based on feedback from Thomas Corte, added a Implementation 973 Considerations section to cover client and server implementation 974 recommendations such as monitoring unhandled namespaces in the 975 server to report to the clients out-of-band and monitoring for 976 responses containing unhanded namespace information in the client 977 to proactively add support for the unhandled namespaces. 978 3. Moved RFC 3735 and RFC 7451 to informative references to address 979 down reference errors in idnits. 981 A.9. Change from REGEXT 05 to REGEXT 06 983 1. Nit updates made based on the feedback provided by the Document 984 Shepherd, David Smith. 986 A.10. Change from REGEXT 06 to REGEXT 07 988 Updates based on the Barry Leiba (AD) feedback: 990 1. Simplified the abstract based on the proposal provided by the AD. 991 2. In section 1.1, updated to use the new BCP 14 boilerplate and add 992 a normative reference to RFC 8174. 993 3. In section 1.1, changed "REQUIRED feature of this protocol" to 994 "required feature of this protocol". 995 4. In section 3, added "by the XML schema" in "disabled by the XML 996 schema in [RFC5730]" to clarify the statement. 997 5. In section 8.2, changed the Registrant Name from "IESG" to 998 "IETF". 999 6. In section 10, changed "The document do not provide" to "This 1000 document does not provide". 1001 7. In section 10, added the sentence "Since the unhandled namespace 1002 context is XML that is not processed in the first pass by the XML 1003 parser, the client SHOULD consider validating the XML when the 1004 content is processed to protect against the inclusion of 1005 malicious content.". 1007 Authors' Addresses 1009 James Gould 1010 VeriSign, Inc. 1011 12061 Bluemont Way 1012 Reston, VA 20190 1013 United States of America 1015 Email: jgould@verisign.com 1016 URI: http://www.verisigninc.com 1018 Martin Casanova 1019 SWITCH 1020 P.O. Box 1021 CH-8021 Zurich 1022 Switzerland 1024 Email: martin.casanova@switch.ch 1025 URI: http://www.switch.ch