idnits 2.17.1 draft-ietf-regext-unhandled-namespaces-05.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 (15 November 2020) is 1230 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 350, but not defined == Missing Reference: 'NAMESPACE-XML' is mentioned on line 347, 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: 19 May 2021 SWITCH 6 15 November 2020 8 Extensible Provisioning Protocol (EPP) Unhandled Namespaces 9 draft-ietf-regext-unhandled-namespaces-05 11 Abstract 13 The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, 14 includes a method for the client and server tof 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 19 May 2021. 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 (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 63 2. Unhandled Namespaces . . . . . . . . . . . . . . . . . . . . 4 64 3. Use of EPP for Unhandled Namespace Data . . . . . 4 65 3.1. Unhandled Object-Level Extension . . . . . . . . . . . . 5 66 3.2. Unhandled Command-Response Extension . . . . . . . . . . 7 67 4. Signaling Client and Server Support . . . . . . . . . . . . . 10 68 5. Usage with General EPP Responses . . . . . . . . . . . . . . 10 69 6. Usage with Poll Message EPP Responses . . . . . . . . . . . . 12 70 7. Implementation Considerations . . . . . . . . . . . . . . . . 15 71 7.1. Client Implementation Considerations . . . . . . . . . . 15 72 7.2. Server Implementation Considerations . . . . . . . . . . 16 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 16 75 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 17 76 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 77 9.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 18 78 9.2. SWITCH Automated DNSSEC Provisioning Process . . . . . . 18 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 83 12.2. Informative References . . . . . . . . . . . . . . . . . 20 84 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 20 85 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 20 86 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 20 87 A.3. Change from 02 to REGEXT 00 . . . . . . . . . . . . . . . 20 88 A.4. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 20 89 A.5. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 20 90 A.6. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 21 91 A.7. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 21 92 A.8. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 95 1. Introduction 97 The Extensible Provisioning Protocol (EPP), as defined in [RFC5730], 98 includes a method for the client and server to determine the objects 99 to be managed during a session and the object extensions to be used 100 during a session. The services are identified using namespace URIs. 101 How should the server handle service data that needs to be returned 102 in the response when the client does not support the required service 103 namespace URI, which is referred to as an unhandled namespace? An 104 unhandled namespace is a significant issue for the processing of 105 [RFC5730] poll messages, since poll messages are inserted by the 106 server prior to knowing the supported client services, and the client 107 needs to be capable of processing all poll messages. An unhandled 108 namespace is an issue also for general EPP responses when the server 109 has information that it cannot return to the client due to the 110 client's supported services. The server should be able to return 111 unhandled namespace information that the client can process later. 112 This document defines an operational practice that enables the server 113 to return information associated with unhandled namespace URIs that 114 is compliant with the negotiated services defined in [RFC5730]. 116 1.1. Conventions Used in This Document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 XML is case sensitive. Unless stated otherwise, XML specifications 123 and examples provided in this document MUST be interpreted in the 124 character case presented in order to develop a conforming 125 implementation. 127 In examples, "S:" represents lines returned by a protocol server. 128 Indentation and white space in examples are provided only to 129 illustrate element relationships and are not a REQUIRED feature of 130 this protocol. 132 The examples reference XML namespace prefixes that are used for the 133 associated XML namespaces. Implementations MUST NOT depend on the 134 example XML namespaces and instead employ a proper namespace-aware 135 XML parser and serializer to interpret and output the XML documents. 136 The example namespace prefixes used and their associated XML 137 namespaces include: 139 "changePoll": urn:ietf:params:xml:ns:changePoll-1.0 140 "domain": urn:ietf:params:xml:ns:domain-1.0 141 "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, that is not supported by the client 166 based on the negotiated EPP command services. 168 3. Use of EPP for Unhandled Namespace Data 170 In [RFC5730], the element is used to provide additional 171 error diagnostic information, including the element that 172 identifies the client-provided element that caused a server error 173 condition, and the element containing the human-readable 174 message that describes the reason for the error. This operational 175 practice extends the use of the element for the purpose of 176 returning unhandled namespace information in a successful response. 178 When a server has data to return to the client, that the client does 179 not support based on the login services, the server MAY return a 180 successful response, with the data for each unsupported namespace 181 moved into an [RFC5730] element. The unhandled namespace 182 will not cause an error response, but the unhandled namespace data 183 will instead be moved to an element, along with a reason 184 why the unhandled namespace data could not be included in the 185 appropriate location of the response. The element XML 186 will not be processed by the XML processor. The element 187 contains the following child elements: 189 : 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 in [RFC5730], so the information can safely be returned 195 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: 239 Template unhandled namespace response for an unsupported object-level 240 extension. The [NAMESPACE-XML] variable represents the object-level 241 extension XML and the [NAMESPACE-URI] variable represents the object- 242 level extension XML namespace URI. 244 S: 245 S: 246 S: 247 S: 248 S: Command completed successfully 249 S: 250 S: 251 S: [NAMESPACE-XML] 252 S: 253 S: 254 S: [NAMESPACE-URI] not in login services 255 S: 256 S: 257 S: 258 S: 259 S: ABC-12345 260 S: 54322-XYZ 261 S: 262 S: 263 S: 265 The EPP response is converted from an object response to a general 266 EPP response by the server when the client does not support the 267 object-level extension namespace URI. Below is example of converting 268 the query response example in [RFC5731] to an unhandled 269 namespace response. 271 [RFC5731] example query response converted into an 272 unhandled namespace response. 274 S: 275 S: 276 S: 277 S: 278 S: Command completed successfully 279 S: 280 S: 281 S: 283 S: example.com 284 S: pending 285 S: ClientX 286 S: 2020-06-06T22:00:00.0Z 287 S: ClientY 288 S: 2020-06-11T22:00:00.0Z 289 S: 2021-09-08T22:00:00.0Z 290 S: 291 S: 292 S: 293 S: urn:ietf:params:xml:ns:domain-1.0 not in login services 294 S: 295 S: 296 S: 297 S: 298 S: ABC-12345 299 S: 54322-XYZ 300 S: 301 S: 302 S: 304 3.2. Unhandled Command-Response Extension 306 A command-response extension in [RFC5730] is a child element of the 307 element. If the client does not handle the namespace of 308 the command-response extension, the command-response child element is 309 moved into a [RFC5730] element, with the namespace 310 URI included in the corresponding element. If 311 after moving the command-response child element there are no 312 additional command-response child elements, the element 313 MUST be removed. 315 Template response for a supported command-response extension. The 316 [NAMESPACE-XML] variable represents the command-response extension 317 XML. 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: ABC-12345 330 S: 54322-XYZ 331 S: 332 S: 333 S: 335 Template unhandled namespace response for an unsupported command- 336 response extension. The [NAMESPACE-XML] variable represents the 337 command-response extension XML and the [NAMESPACE-URI] variable 338 represents the command-response extension XML namespace URI. 340 S: 341 S: 342 S: 343 S: 344 S: Command completed successfully 345 S: 346 S: 347 S: [NAMESPACE-XML] 348 S: 349 S: 350 S: [NAMESPACE-URI] not in login services 351 S: 352 S: 353 S: 354 S: 355 S: ABC-12345 356 S: 54322-XYZ 357 S: 358 S: 359 S: 361 The EPP response is converted to an unhandled namespace response by 362 moving the unhandled command-response extension from under the 363 to an element. Below is example of converting 364 the DS Data Interface response example in [RFC5910] to an 365 unhandled namespace response. 367 [RFC5910] DS Data Interface response converted into an 368 unhandled namespace response. 370 S: 371 S: 372 S: 373 S: 374 S: Command completed successfully 375 S: 376 S: 377 S: 379 S: 380 S: 12345 381 S: 3 382 S: 1 383 S: 49FD46E6C4B45C55D4AC 384 S: 385 S: 386 S: 387 S: 388 S: urn:ietf:params:xml:ns:secDNS-1.1 not in login services 389 S: 390 S: 391 S: 392 S: 393 S: 395 S: example.com 396 S: EXAMPLE1-REP 397 S: 398 S: jd1234 399 S: sh8013 400 S: sh8013 401 S: 402 S: ns1.example.com 403 S: ns2.example.com 404 S: 405 S: ns1.example.com 406 S: ns2.example.com 407 S: ClientX 408 S: ClientY 409 S: 1999-04-03T22:00:00.0Z 410 S: ClientX 411 S: 2020-12-03T09:00:00.0Z 412 S: 2021-04-03T22:00:00.0Z 413 S: 2000-04-08T09:00:00.0Z 414 S: 415 S: 2fooBAR 416 S: 417 S: 418 S: 419 S: 420 S: ABC-12345 421 S: 54322-XYZ 422 S: 423 S: 424 S: 426 4. Signaling Client and Server Support 428 This document does not define new protocol but an operational 429 practice using the existing EPP protocol, where the client and the 430 server can signal support for the operational practice using a 431 namespace URI in the login and greeting extension services. The 432 namespace URI "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" 433 is used to signal support for the operational practice. The client 434 includes the namespace URI in an element of 435 the [RFC5730] Command. The server includes the namespace URI 436 in an element of the [RFC5730] Greeting. 438 A client that receives the namespace URI in the server's Greeting 439 extension services, can expect the following supported behavior by 440 the server: 442 1. Support unhandled namespace object-level extensions and command- 443 response extensions in EPP poll messages, per Section 6. 444 2. Support the option of unhandled namespace command-response 445 extensions in general EPP responses, per Section 5. 447 A server that receives the namespace URI in the client's 448 Command extension services, can expect the following supported 449 behavior by the client: 451 1. Support monitoring the EPP poll messages and general EPP 452 responses for unhandled namespaces. 454 5. Usage with General EPP Responses 456 The unhandled namespace approach defined in Section 3 MAY be used for 457 a general EPP response to an EPP command. A general EPP response 458 includes any non-poll message EPP response. The use of the unhandled 459 namespace approach for poll message EPP responses is defined in 460 Section 6. The server MAY exclude the unhandled namespace 461 information in the general EPP response or MAY include it using the 462 unhandled namespace approach. 464 The unhandled namespace approach for general EPP responses SHOULD 465 only be applicable to command-response extensions, defined in 466 Section 3.2, since the server SHOULD NOT accept an object-level EPP 467 command if the client did not include the object-level namespace URI 468 in the login services. An object-level EPP response extension is 469 returned when the server successfully executes an object-level EPP 470 command extension. The server MAY return an unhandled object-level 471 extension to the client as defined in Section 3.1. 473 Returning domain name Redemption Grace Period (RGP) data, based on 474 [RFC3915], provides an example of applying the unhandled namespace 475 approach for a general EPP response. If the client does not include 476 the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the login 477 services, and the domain response of a domain name does have 478 RGP information, the server MAY exclude the element 479 from the EPP response or MAY include it under in the 480 element per Section 3.2. 482 [RFC5731] domain name response with the unhandled [RFC3915] 483 element included under an element: 485 S: 486 S: 487 S: 488 S: 489 S: Command completed successfully 490 S: 491 S: 492 S: 493 S: 494 S: 495 S: 496 S: 497 S: urn:ietf:params:xml:ns:rgp-1.0 not in login services 498 S: 499 S: 500 S: 501 S: 502 S: 504 S: example.com 505 S: EXAMPLE1-REP 506 S: 507 S: jd1234 508 S: sh8013 509 S: sh8013 510 S: 511 S: ns1.example.com 512 S: ns1.example.net 513 S: 514 S: ns1.example.com 515 S: ns2.example.com 516 S: ClientX 517 S: ClientY 518 S: 1999-04-03T22:00:00.0Z 519 S: ClientX 520 S: 2020-12-03T09:00:00.0Z 521 S: 2021-04-03T22:00:00.0Z 522 S: 2000-04-08T09:00:00.0Z 523 S: 524 S: 2fooBAR 525 S: 526 S: 527 S: 528 S: 529 S: ABC-12345 530 S: 54322-XYZ 531 S: 532 S: 533 S: 535 6. Usage with Poll Message EPP Responses 537 The unhandled namespace approach, defined in Section 3, MUST be used 538 if there is unhandled namespace information included in an EPP 539 message response. The server inserts poll messages into the client's 540 poll queue independent of knowing the supported client login 541 services, therefore there may be unhandled object-level and command- 542 response extensions included in a client's poll queue. In [RFC5730], 543 the command is used by the client to retrieve and acknowledge 544 poll messages that have been inserted by the server. The 545 message response is an EPP response that includes the element 546 that provides poll queue meta-data about the message. The unhandled 547 namespace approach, defined in Section 3, is used for an unhandled 548 object-level extension and for each of the unhandled command-response 549 extensions attached to the message response. The resulting 550 EPP message response MAY have either or both the object-level 551 extension or command-response extensions moved to 552 elements, as defined in Section 3. 554 The Change Poll Message, as defined in [RFC8590], which is an 555 extension of any EPP object, is an example of applying the unhandled 556 namespace approach for EPP message responses. The object that 557 will be used in the examples is a [RFC5731] domain name object. 559 [RFC5731] domain name message response with the 560 unhandled [RFC8590] element included under an 561 element: 563 S: 564 S: 565 S: 566 S: 567 S: Command completed successfully; ack to dequeue 568 S: 569 S: 570 S: 573 S: update 574 S: 575 S: 2020-11-22T05:00:00.000Z 576 S: 12345-XYZ 577 S: URS Admin 578 S: urs123 579 S: 580 S: URS Lock 581 S: 582 S: 583 S: 584 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services 585 S: 586 S: 587 S: 588 S: 592 S: 2020-11-22T05:00:00.000Z 593 S: Registry initiated update of domain. 594 S: 595 S: 596 S: 598 S: change-poll.tld 599 S: EXAMPLE1-REP 600 S: 601 S: 602 S: 603 S: jd1234 604 S: sh8013 605 S: sh8013 606 S: ClientX 607 S: ClientY 608 S: 2012-05-03T04:00:00.000Z 609 S: ClientZ 610 S: 2020-11-22T05:00:00.000Z 611 S: 2021-05-03T04:00:00.000Z 612 S: 613 S: 614 S: 615 S: ABC-12345 616 S: 54322-XYZ 617 S: 618 S: 619 S: 621 Unhandled [RFC5731] domain name message response and 622 the unhandled [RFC8590] element included 623 under an element: 625 S: 626 S: 627 S: 628 S: 629 S: Command completed successfully; ack to dequeue 630 S: 631 S: 632 S: 634 S: change-poll.tld 635 S: EXAMPLE1-REP 636 S: 637 S: 638 S: 639 S: jd1234 640 S: sh8013 641 S: sh8013 642 S: ClientX 643 S: ClientY 644 S: 2012-05-03T04:00:00.000Z 645 S: ClientZ 646 S: 2020-11-22T05:00:00.000Z 647 S: 2021-05-03T04:00:00.000Z 648 S: 649 S: 650 S: 651 S: urn:ietf:params:xml:ns:domain-1.0 not in login services 652 S: 653 S: 654 S: 655 S: 656 S: 659 S: update 660 S: 661 S: 2020-11-22T05:00:00.000Z 662 S: 12345-XYZ 663 S: URS Admin 664 S: urs123 665 S: 666 S: URS Lock 667 S: 668 S: 669 S: 670 S: urn:ietf:params:xml:ns:changePoll-1.0 not in login services 671 S: 672 S: 673 S: 674 S: 678 S: 2020-11-22T05:00:00.000Z 679 S: Registry initiated update of domain. 680 S: 681 S: 682 S: ABC-12345 683 S: 54322-XYZ 684 S: 685 S: 686 S: 688 7. Implementation Considerations 690 There are implementation considerations for the client and the server 691 to help address the risk of the client ignoring unhandled namespace 692 information included in an EPP response that is needed to meet 693 technical, policy, or legal requirements. 695 7.1. Client Implementation Considerations 697 To reduce the likelihood of a client receiving unhandled namespace 698 information, the client should consider the following: 700 1. Ensure that the login services is accurate with what is supported 701 by the client. If there are gaps between the services supported 702 by the client and the login services included in the login 703 command, the client may receive unhandled namespace information 704 that the client could have supported. 705 2. Support all of the services included in the server greeting 706 services that may be included in an EPP response, including the 707 poll queue responses. The client should evaluate the gaps 708 between the greeting services and the login services provided in 709 the login command to identify extensions that need to be 710 supported. 711 3. Proactively monitor for unhandled namespace information in the 712 EPP responses, by looking for the inclusion of the 713 element in successful responses, recording the unsupported 714 namespace included in the element, and recording the 715 unhandled namespace information included in the element 716 for later processing. The unhandled namespace can be implemented 717 by the client to ensure that information is processed fully in 718 future EPP responses. 720 7.2. Server Implementation Considerations 722 To assist the clients in recognizing unhandled namespaces, the server 723 should consider the following: 725 1. Monitor for returning unhandled namespace information to clients 726 and report it to the clients out-of-band to EPP so the clients 727 can add support for the unhandled namespaces. 728 2. Look for the unhandled namespace support in the login services 729 when returning optional unhandled namespace information in 730 General EPP Responses. 732 8. IANA Considerations 734 8.1. XML Namespace 736 This document uses URNs to describe XML namespaces conforming to a 737 registry mechanism described in [RFC3688]. The following URI 738 assignment is requested of IANA: 740 Registration request for the unhandled namespaces namespace: 742 URI: urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0 743 Registrant Contact: IESG 744 XML: None. Namespace URIs do not represent an XML specification. 746 8.2. EPP Extension Registry 748 The EPP operational practice described in this document should be 749 registered by the IANA in the EPP Extension Registry described in 750 [RFC7451]. The details of the registration are as follows: 752 Name of Extension: "Extensible Provisioning Protocol (EPP) Unhandled 753 Namespaces" 755 Document status: Standards Track 757 Reference: (insert reference to RFC version of this document) 759 Registrant Name and Email Address: IESG, 761 TLDs: Any 763 IPR Disclosure: None 765 Status: Active 767 Notes: None 769 9. Implementation Status 771 Note to RFC Editor: Please remove this section and the reference to 772 RFC 7942 [RFC7942] before publication. 774 This section records the status of known implementations of the 775 protocol defined by this specification at the time of posting of this 776 Internet-Draft, and is based on a proposal described in RFC 7942 777 [RFC7942]. The description of implementations in this section is 778 intended to assist the IETF in its decision processes in progressing 779 drafts to RFCs. Please note that the listing of any individual 780 implementation here does not imply endorsement by the IETF. 781 Furthermore, no effort has been spent to verify the information 782 presented here that was supplied by IETF contributors. This is not 783 intended as, and must not be construed to be, a catalog of available 784 implementations or their features. Readers are advised to note that 785 other implementations may exist. 787 According to RFC 7942 [RFC7942], "this will allow reviewers and 788 working groups to assign due consideration to documents that have the 789 benefit of running code, which may serve as evidence of valuable 790 experimentation and feedback that have made the implemented protocols 791 more mature. It is up to the individual working groups to use this 792 information as they see fit". 794 9.1. Verisign EPP SDK 796 Organization: Verisign Inc. 798 Name: Verisign EPP SDK 800 Description: The Verisign EPP SDK includes an implementation of the 801 unhandled namespaces for the processing of the poll queue messages. 803 Level of maturity: Development 805 Coverage: All aspects of the protocol are implemented. 807 Licensing: GNU Lesser General Public License 809 Contact: jgould@verisign.com 811 URL: https://www.verisign.com/en_US/channel-resources/domain- 812 registry-products/epp-sdks 814 9.2. SWITCH Automated DNSSEC Provisioning Process 816 Organization: SWITCH 818 Name: Registry of .CH and .LI 820 Description: SWITCH uses poll messages to inform the registrar about 821 DNSSEC changes at the registry triggered by CDS records. These poll 822 messages are enriched with the 'urn:ietf:params:xml:ns:changePoll- 823 1.0' and the 'urn:ietf:params:xml:ns:secDNS-1.1' extension that are 824 rendered in the poll msg response according to this draft. 826 Level of maturity: Operational 828 Coverage: All aspects of the protocol are implemented. 830 Licensing: Proprietary 832 Contact: martin.casanova@switch.ch 834 URL: https://www.nic.ch/cds 836 10. Security Considerations 838 The document do not provide any security services beyond those 839 described by EPP [RFC5730] and protocol layers used by EPP. The 840 security considerations described in these other specifications apply 841 to this specification as well. 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 [RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the 893 Extensible Provisioning Protocol (EPP)", RFC 8590, 894 DOI 10.17487/RFC8590, May 2019, 895 . 897 12.2. Informative References 899 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 900 Provisioning Protocol (EPP)", RFC 3735, 901 DOI 10.17487/RFC3735, March 2004, 902 . 904 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 905 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 906 February 2015, . 908 Appendix A. Change History 910 A.1. Change from 00 to 01 912 1. Removed xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 913 reference from examples. 914 2. removed block from example. 915 3. added SWITCH Automated DNSSEC Provisioning Process at 916 Implementation Status 918 A.2. Change from 01 to 02 920 1. Ping update 922 A.3. Change from 02 to REGEXT 00 924 1. Changed to regext working group draft by changing draft-gould- 925 casanova-regext-unhandled-namespaces to draft-ietf-regext- 926 unhandled-namespaces. 928 A.4. Change from REGEXT 00 to REGEXT 01 930 1. Added the "Signaling Client and Server Support" section to 931 describe the mechanism to signal support for the BCP by the 932 client and the server. 933 2. Added the IANA Considerations section with the registration of 934 the unhandled namespaces XML namespace and the registration of 935 the EPP Best Current Practice (BCP) in the EPP Extension 936 Registry. 938 A.5. Change from REGEXT 01 to REGEXT 02 939 1. Filled in the acknowledgements section. 940 2. Changed the reference from RFC 5730 to RFC 5731 for the transfer 941 example in section 3.1 "Unhandled Object-Level" Extension. 942 3. Updated the XML namespace to 943 urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0, which 944 removed bcp from the namespace and bumped the version from 0.1 945 and 1.0. Inclusion of bcp in the XML namespace was discussed at 946 the REGEXT interim meeting. 948 A.6. Change from REGEXT 02 to REGEXT 03 950 1. Converted from xml2rfc v2 to v3. 951 2. Updated Acknowledgements to match the approach taken by the RFC 952 Editor with draft-ietf-regext-login-security. 953 3. Changed reference of ietf-regext-change-poll to RFC 8590. 955 A.7. Change from REGEXT 03 to REGEXT 04 957 1. Changed from Best Current Practice (BCP) to Standards Track based 958 on mailing list discussion. 959 2. Revised the dates in the examples to be more up-to-date. 961 A.8. Change from REGEXT 04 to REGEXT 05 963 1. Based on feedback from Thomas Corte, added a description of the 964 element in RFC 5730 and it being extended to support 965 returning unhandled namespace information. 966 2. Based on feedback from Thomas Corte, added a Implementation 967 Considerations section to cover client and server implementation 968 recommendations such as monitoring unhandled namespaces in the 969 server to report to the clients out-of-band and monitoring for 970 responses containing unhanded namespace information in the client 971 to proactively add support for the unhandled namespaces. 972 3. Moved RFC 3735 and RFC 7451 to informative references to address 973 down reference errors in idnits. 975 Authors' Addresses 977 James Gould 978 VeriSign, Inc. 979 12061 Bluemont Way 980 Reston, VA 20190 981 United States of America 983 Email: jgould@verisign.com 984 URI: http://www.verisigninc.com 985 Martin Casanova 986 SWITCH 987 P.O. Box 988 CH-8021 Zurich 989 Switzerland 991 Email: martin.casanova@switch.ch 992 URI: http://www.switch.ch