Registry Fee Extension for 52 | the Extensible Provisioning Protocol (EPP)

90 | Historically, domain name registries have applied a simple fee 91 | structure for billable transactions, namely a basic unit price applied to 92 | domain <create>, <renew>, <transfer> and RGP restore commands. Given the relatively small 94 | number of EPP servers to which EPP clients have been required to connect, 95 | it has generally been the case that client operators have been able to 96 | obtain details of these fees out-of-band by contacting the server 97 | operators. 98 | 99 | Given the recent expansion of the DNS namespace, and the proliferation 100 | of novel business models, it is now desirable to provide a method for EPP 101 | clients to query EPP servers for the fees and credits associated with 102 | certain commands and specific objects. 103 | 104 | This document describes an extension mapping for version 1.0 of the 105 | Extensible Provisioning Protocol (EPP). This 106 | EPP mapping provides a mechanism by which EPP clients may query the fees 107 | and credits associated with various billable transactions, and also 108 | obtain their current account balance. 109 | 110 |

111 | 112 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 | document are to be interpreted as described in 115 | RFC 2119. 116 | 117 | XML is case sensitive. Unless stated otherwise, XML specifications 118 | and examples provided in this document MUST be interpreted in the 119 | character case presented in order to develop a conforming 120 | implementation. 121 | 122 | "fee" is used as an abbreviation for 123 | "urn:ietf:params:xml:ns:fee-&VERSION;". The XML namespace prefix "fee" 124 | is used, but implementations MUST NOT depend on it and instead employ a 125 | proper namespace-aware XML parser and serializer to interpret and output 126 | the XML documents. 127 | 128 | (Note to RFC Editor: remove the following paragraph before publication 129 | as an RFC.) 130 | 131 | The XML namespace prefix above contains a version number, 132 | specifically "&VERSION;". This version number will increment with 133 | successive versions of this document, and will reach 1.0 if and when 134 | this document is published as an RFC. This permits clients to 135 | distinguish which version of the extension a server has implemented. 136 | 137 |

138 |

141 | (Note to RFC Editor: remove this section before publication as an 142 | RFC.) 143 | Servers which implement this extension SHOULD provide a 144 | way for clients to progressively update their implementations 145 | when a new version of the extension is deployed. 146 | Servers SHOULD (for a temporary migration period) provide support for 147 | older versions of the extension in parallel to the newest version, and 148 | allow clients to select their preferred version via the 149 | <svcExtension> element of the <login> command. 150 | If a client requests multiple versions of the extension at login, then, 151 | when preparing responses to commands which do not include extension elements, 152 | the server SHOULD only include extension elements in the namespace of the newest 153 | version of the extension requested by the client. 154 | When preparing responses to commands which do include extension elements, the 155 | server SHOULD only include extension elements for the extension versions present 156 | in the command. 157 |

160 | 161 |

183 | 184 |

185 | The <fee:currency> element is used to indicate which currency 186 | fees are charged in. This value of this element MUST be a three-character 187 | currency code from . 188 | 189 | Note that ISO 4217 provides the special "XXX" code, which MAY be used 190 | if the server uses a non-currency based system for assessing fees, such as 191 | a system of credits. 192 | 193 | The use of <fee:currency> elements in commands is OPTIONAL: 194 | if a <fee:currency> element is not present in a command, the 195 | server MUST determine the currency based on the client's account settings 196 | which MUST be agreed by the client and server via an out-of-band 197 | channel. However, the <fee:currency> element MUST be present in 198 | responses. 199 | 200 | Servers SHOULD NOT perform a currency conversion if a client uses an 201 | incorrect currency code. Servers SHOULD return a 2004 error instead. 202 |

203 | 204 |

205 | When querying for fee information using the <check> command, 206 | the <fee:period> element is used to indicate the units to be added 207 | to the registration period of objects by the <create>, 208 | <renew> and <transfer> commands. This element is derived 209 | from the <domain:period> element described in . 211 | 212 | The <fee:period> element is OPTIONAL in <check> commands: 213 | if omitted, the server MUST determine the fee(s) using a validity period 214 | of 1 year. The <fee:period> element MUST be present in <check> 215 | responses. 216 | 217 |

218 | 219 |

262 | <fee:fee> elements MAY have an OPTIONAL "refundable" attribute 263 | which takes a boolean value. Fees may be refunded under certain 264 | circumstances, such as when a domain application is rejected (as 265 | described in ) or when 266 | an object is deleted during the relevant Grace Period (see below). 267 | 268 | If the "refundable" attribute is omitted, then clients SHOULD NOT make 269 | any assumption about the refundability of the fee. 270 |

271 | 272 |

273 | describes a system of "grace periods", 274 | which are time periods following a billable transaction during which, 275 | if an object is deleted, the client receives a refund. 276 | 277 | The "grace-period" attribute MAY be used to indicate the relevant 278 | grace period for a fee. If a server implements the Registry Grace 279 | Period extension, it MUST specify the grace period for all relevant 280 | transactions. 281 | 282 | If the "grace-period" attribute is omitted, then clients 283 | SHOULD NOT make any assumption about the grace period of the fee. 284 |

285 | 286 |

287 | If a <fee:fee> element has a "grace-period" attribute then 288 | it MUST also be refundable. If the "refundable" attribute of a 289 | <fee:fee> element is false then it MUST NOT have a 290 | "grace-period" attribute. 291 |

292 | 293 |

294 | Fees may be applied immediately upon receipt of a command from a 295 | client, or may only be applied once an out-of-band process (such as 296 | the processing of applications at the end of a launch phase) has 297 | taken place. 298 | 299 | The "applied" attribute of the <fee:fee> element allows 300 | servers to indicate whether a fee will be applied immediately, or 301 | whether it will be applied at some point in the future. This 302 | attribute takes two possible values: "immediate" (which is the 303 | default) or "delayed". 304 |

305 |

306 | 307 |

308 | The <fee:balance> element is an OPTIONAL element which MAY 309 | be included in server responses to transform commands. If present, 310 | it can be used by the client to determine the remaining credit at 311 | the server. 312 | 313 | Whether or not the <fee:balance> is included in responses is a 314 | matter of server policy. However, if a server chooses 315 | to offer support for this element, it MUST be included in responses 316 | to all "transform" commands (ie <create>, <renew>, 317 | <update>, <delete>, <transfer op="request">). 318 | 319 | The value of the <fee:balance> MAY be negative. A negative 320 | balance indicates that the server has extended a line of credit to the 321 | client (see below). 322 | 323 | If a server includes a <fee:balance> element in response to 324 | transform commands, the value of the element MUST reflect the client's 325 | account balance after any fees or credits associated with that command 326 | have been applied. 327 |

328 | 329 |

330 | As described above, if a server returns a response containing a 331 | <fee:balance> with a negative value, then the server has extended a 332 | line of credit to the client. A server MAY also include a 333 | <fee:creditLimit> element in responses which indicates the maximum 334 | credit available to a client. A server MAY reject certain transactions if 335 | the absolute value of the <fee:balance> is equal to or exceeds the 336 | value of the <fee:creditLimit> element. 337 | 338 | Whether or not the <fee:creditLimit> is included in responses 339 | is a matter of server policy. However, if a server chooses 340 | to offer support for this element, it MUST be included in responses 341 | to all "transform" commands (ie <create>, <renew>, 342 | <update>, <delete>, <transfer op="request">). 343 |

344 | 345 |

346 | Objects may be assigned to a particular class, category, or tier, 347 | each of which has a particular fee or set of fees associated with it. The 348 | <fee:class> element which appears in <check> responses is 349 | used to indicate the classification of an object. 350 | 351 | If a server makes use of this element, it should provide clients with a 352 | list of all the values that the element may take via an out-of-band 353 | channel. Servers MUST NOT use values which do not appear on this list. 354 | 355 | Servers which make use of this element MUST use a <fee:class> 356 | element with the value "standard" for all objects that are subject to the 357 | standard or default fee. 358 |

359 |

362 | 363 | Depending on server policy, a client MAY be required to include the 364 | extension elements described in this document for certain transform 365 | commands. Servers must provide clear documentation to clients about the 366 | circumstances in which this extension must be used. 367 | 368 | If a server receives a command from a client which does not include 369 | the extension elements required by the server for that command, then 370 | it MUST respond with a 2003 "Required parameter missing" error. 371 | 372 | If the currency or total fee provided by the client do not agree 373 | with the server's own calculation of the fee for that command, then the 374 | server MUST reject the command with a 2004 "Parameter value range" 375 | error. 376 | 377 |

380 | Sometimes, the time interval between when a client queries the 381 | fee for a command, and when that command takes place, is long enough that 382 | there is a non-negligible probability that the fee might change in 383 | the intervening time. 384 | 385 | To ensure that clients can obtain the most accurate fee information 386 | in such circumstances, clients can include a <fee:cmdDate> element 387 | in fee <check> commands, to indicate the anticipated date and time 388 | of a billable transaction. 389 | 390 | If a server receives a command containing a <fee:cmdDate> element, 391 | and the server is unable to provide accurate fee information for the given 392 | date and time, then it MUST respond with a 2306 "Parameter value policy 393 | error" error. Otherwise, the server MUST return fee information that will 394 | prevail at the date and time provided. 395 | 396 | This extension provides no mechanism to enforce the application of these 397 | fees when the command is subsequently submitted; servers MUST reject commands 398 | which include incorrect fee information, as described above. 399 | 400 | If a server knows that the fee information it is returning to a client 401 | is going to change in the future, it MAY include <fee:notAfter> 402 | elements in <check> responses. This element contains a date and time 403 | after which the provided fee information will no longer apply. Clients which 404 | receive a response from a server which contain <fee:notAfter> elements 405 | may then re-query for the fee information (using the <fee:cmdDate> 406 | element) described above if the value of the <fee:notAfter> element 407 | is before the anticipated time when the command will be submitted. 408 |

411 | 412 | A detailed description of the EPP syntax and semantics can be found in 413 | . 414 | 415 |

416 | This extension does not add any elements to the EPP <poll> or 417 | <info> commands or responses. 418 | 419 |

420 | This extension defines additional elements for the EPP 421 | <check> command. 422 | 423 | The command MAY contain an <extension> element which 424 | MAY contain a <fee:check> element. The <fee:check> element 425 | contains the following child elements: 426 | 427 | 428 | A <fee:command> element; 429 | 430 | An OPTIONAL <fee:currency> element; 431 | 432 | An OPTIONAL <fee:period> element. 433 | 434 | An OPTIONAL <fee:class> element. 435 | 436 | An OPTIONAL <fee:cmdDate> element. 437 | 438 | 439 | Example <check> command: 440 | 441 |

509 | 511 | 512 |

513 | When a server supports classes as described in Section 3.7, 514 | and the <fee:class> element is present in the command, the server MUST 515 | validate the value of this element, and return an error for unknown values. 516 | If the given value is incorrect for the specified object, the 517 | "avail" attribute of the corresponding <fee:cd> element MUST be 518 | false. 519 | 520 | The <fee:cd> section MUST contain the appropriate 521 | <fee:class> element when the servers support classes, as described 522 | in Section 3.7, and the "avail" 523 | attribute of the <fee:cd> element is true. 524 |

525 |

526 | 527 |

563 | 565 | 566 |

567 | 568 |

569 | 570 |

571 | 572 |

573 | This extension adds elements to both the EPP <create> command 574 | and response, when the extension has been selected during a 575 | <login> command. 576 | 577 | When submitting a <create> command to the server, the client 578 | MAY include in the <extension> element a <fee:create> 579 | element which includes the following child elements: 580 | 581 | 582 | An OPTIONAL <fee:currency> element; 583 | 584 | One or more <fee:fee> elements. 585 | 586 | 587 | When the <create> command has been processed successfully, 588 | and the client selected the extension when it logged in, and a fee was 589 | assessed by the server for the transaction, the server MUST include in 590 | the <extension> section of the EPP response a 591 | <fee:creData> element, which contains the following child 592 | elements: 593 | 594 | 596 | 597 | If no fee or credit has been assessed by the server for this transaction, 598 | a <fee:creData> element MUST NOT be included in the response. 599 | 600 | Example <create> command: 601 | 602 |

603 | 605 | 606 | Example <create> response: 607 | 608 |

609 | 611 | 612 |

613 | 614 |

634 | 636 |

637 | 638 |

639 | This extension adds elements to both the EPP <renew> command 640 | and response, when the extension has been selected during a 641 | <login> command. 642 | 643 | When submitting a <renew> command to the server, the client 644 | MAY include in the <extension> element a <fee:renew> 645 | element which includes the following child elements: 646 | 647 | 648 | An OPTIONAL <fee:currency> element; 649 | 650 | One or more <fee:fee> elements. 651 | 652 | 653 | When the <renew> command has been processed successfully, 654 | and the client selected the extension when it logged in, the server 655 | MAY include in the <extension> section of the EPP response a 656 | <fee:renData> element, which contains the following child 657 | elements: 658 | 659 | 661 | 662 | If no fee or credit has been assessed by the server for this transaction, 663 | a <fee:renData> element MUST NOT be included in the response. 664 | 665 | Example <renew> command: 666 | 667 |

668 | 670 | 671 | Example <renew> response: 672 | 673 |

674 | 676 | 677 |

678 | 679 |

680 | This extension adds elements to both the EPP <transfer> 681 | command and response, when the value of the "op" attribute of the 682 | <transfer> command element is "request", and the extension has 683 | been selected during the <login> command. 684 | 685 | When submitting a <transfer> command to the server, the client 686 | MAY include in the <extension> element a <fee:transfer> 687 | element which includes the following child elements: 688 | 689 | 690 | An OPTIONAL <fee:currency> element; 691 | 692 | One or more <fee:fee> elements. 693 | 694 | 695 | When the <transfer> command has been processed successfully, 696 | and the client selected the extension when it logged in, the server 697 | MAY include in the <extension> section of the EPP response a 698 | <fee:trnData> element, which contains the following child 699 | elements: 700 | 701 | 703 | 704 | If no fee or credit has been assessed by the server for this transaction, 705 | a <fee:trnData> element MUST NOT be included in the response. 706 | 707 | Example <transfer> command: 708 | 709 |

710 | 712 | 713 | Example <transfer> response: 714 | 715 |

716 | 718 | 719 |

720 | 721 |

722 | This extension adds elements to both the EPP <update> command 723 | and response, when the extension has been selected during a 724 | <login> has been selected during the <login> command. 725 | 726 | When submitting a <update> command to the server, the client 727 | MAY include in the <extension> element a <fee:update> 728 | element which includes the following child elements: 729 | 730 | 731 | An OPTIONAL <fee:currency> element; 732 | 733 | One or more <fee:fee> elements. 734 | 735 | 736 | When the <update> command has been processed successfully, 737 | and the client selected the extension when it logged in, the server 738 | MAY include in the <extension> section of the EPP response a 739 | <fee:upData> element, which contains the following child 740 | elements: 741 | 742 | 744 | 745 | If no fee or credit has been assessed by the server for this transaction, 746 | a <fee:upData> element MUST NOT be included in the response. 747 | 748 | Example <update> command: 749 | 750 |

751 | 753 | 754 | Example <update> response: 755 | 756 |

757 | 759 | 760 |

761 | 762 |

763 | 764 |

765 | An EPP object mapping is specified in XML Schema notation. The formal 766 | syntax presented here is a complete schema representation of the object 767 | mapping suitable for automated validation of EPP XML instances. 768 | 769 | Copyright (c) 2014 IETF Trust and the persons identified as authors 770 | of the code. All rights reserved. 771 | 772 | Redistribution and use in source and binary forms, with or without 773 | modification, are permitted provided that the following conditions are 774 | met: 775 | 776 | 777 | Redistributions of source code must retain the above copyright 778 | notice, this list of conditions and the following disclaimer. 779 | 780 | Redistributions in binary form must reproduce the above copyright 781 | notice, this list of conditions and the following disclaimer in the 782 | documentation and/or other materials provided with the 783 | distribution. 784 | 785 | Neither the name of Internet Society, IETF or IETF Trust, nor the 786 | names of specific contributors, may be used to endorse or promote 787 | products derived from this software without specific prior written 788 | permission. 789 | 790 | 791 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 792 | "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 793 | LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 794 | PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER 795 | OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 796 | EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 797 | PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR 798 | PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 799 | LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 800 | NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 801 | SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 802 | 803 |

804 | BEGIN 805 | 807 | END 808 | 809 |

810 | 811 |

814 | The mapping extensions described in this document do not provide any 815 | security services beyond those described by EPP, 816 | the EPP domain name mapping, and protocol 817 | layers used by EPP. The security considerations described in these other 818 | specifications apply to this specification as well.

821 |

822 | This document uses URNs to describe XML namespaces and XML schemas 823 | conforming to a registry mechanism described in . 824 | The following URI assignment is requested of IANA: 825 | URI: urn:ietf:params:xml:ns:fee-&VERSION; 826 | Registrant Contact: See the "Author's Address" section of this 827 | document. 828 | XML: See the "Formal Syntax" section of this document. 829 |

830 |

844 |

847 | Note to RFC Editor: Please remove this section and the reference to 848 | before publication. 849 | 850 | This section records the status of known implementations of the 851 | protocol defined by this specification at the time of posting of this 852 | Internet-Draft, and is based on a proposal described in . 853 | The description of implementations in this section is 854 | intended to assist the IETF in its decision processes in progressing 855 | drafts to RFCs. Please note that the listing of any individual 856 | implementation here does not imply endorsement by the IETF. 857 | Furthermore, no effort has been spent to verify the information 858 | presented here that was supplied by IETF contributors. This is not 859 | intended as, and must not be construed to be, a catalog of available 860 | implementations or their features. Readers are advised to note that 861 | other implementations may exist. 862 | 863 | According to , "this will allow reviewers and 864 | working groups to assign due consideration to documents that have the 865 | benefit of running code, which may serve as evidence of valuable 866 | experimentation and feedback that have made the implemented protocols 867 | more mature. It is up to the individual working groups to use this 868 | information as they see fit". 869 | 870 |

871 | Organization: CentralNic 872 | Name: RegistryEngine EPP Service 873 | Description: Generic high-volume EPP service for gTLDs, ccTLDs and SLDs 874 | Level of maturity: Deployed in CentralNic's production environment as well 875 | as two other gTLD registry systems, and two ccTLD registry systems. 876 | Coverage: All aspects of the protocol are implemented. 877 | Licensing: Proprietary In-House software 878 | Contact: epp@centralnic.com 879 | URL: https://www.centralnic.com 880 |

881 |

903 |

912 |

932 |

933 | 934 | Added the "applied" attribute to to <fee:fee> elements. 935 | Simplified the wording in relation to when a server can return an 936 | error for extended <info> commands. 937 | Added the <fee:period> element to transfer query responses. 938 | Removed wording about how servers behave when receiving incorrect 939 | fee information from transform commands, and put it into a single 940 | section at the top of the document. 941 | Allow servers to omit <fee:fee> elements from <fee:cd> 942 | elements if the command specified by the client is forbidden. 943 | 944 |

945 |

946 | 947 | Changed Intended Status to Standards Track. 948 | As per suggestion from Michael Bauland, the <fee:period> 949 | element is no longer included in <check> and <info> 950 | responses for "restore" commands. It's still mandatory for all other 951 | commands. 952 | Added summary of the attributes for the <fee:fee> element. 953 | Clarified that the "refundable" and "grace-period" attributes of 954 | the <fee:fee> elements are dependant on each other and cannot 955 | appear on their own. 956 | Removed the option of returning a 1001 response when the fee is 957 | incorrect. 958 | Forbidden the inclusion of extension elements in transform responses 959 | if no fee/credit has been assessed. 960 | Made the <fee:currency> element optional in transform 961 | commands. 962 | Amended XML Namespace section of IANA Considerations, added 963 | EPP Extension Registry section. 964 | 965 |

966 |

967 | 968 | Removed the extended <info> command. The <check> command 969 | is the only command that can be used now. 970 | Introduced a mandatory-to-implement "standard" class for non-premium 971 | domains. 972 | The decision was made to keep availability info in <check> responses 973 | as registrars have indicated that it is very useful as it avoids unnecessary 974 | round trips to the server. 975 | Allow <fee:credit> elements to be present in <check> 976 | responses. 977 | Allow the number of <fee:fee> which can appear in transform responses 978 | to be zero. 979 | Removed the <fee:balance> and <fee:creditLimit> elements from 980 | transfer query responses. The reason is that these elements are defined 981 | as containing the values after the transform command has taken place - which 982 | means that it is not appropriate to include them in a query response. 983 | Added Implementation Status section. 984 | 985 |

986 |

987 | 988 | The specification is now object-agnostic, but works with 989 | RFC5731 domains by default. 990 | Renamed the <fee:domain> element to <fee:object>. Added the 991 | "objURI" attribute. 992 | Removed the default value for the "refundable" attribute of <fee:fee> 993 | elements, and added text about how clients should handle such cases. Added similar 994 | text to the documentation of the "grace-period" attribute. 995 | Removed references to the defunct <info> command syntax. 996 | "MUST" requirements regarding documentation have been changed to "must". 997 | Created separate "Correlation between Refundability and Grace Periods" section 998 | describing how the "refundable" and "grace-period" attributes work together. 999 | 1000 |

1001 |

1002 | 1003 | Changed the syntax of the <check> form to be simpler: a single set of 1004 | <fee:command>, <fee:currency> etc elements is applied to the objects 1005 | specified in the main body of the <check> command. 1006 | Simplified the object-agnosticism to simply copy the element from the 1007 | <check> command into the <fee:cd> element. 1008 | Added the "avail" attribute to the <fee:cd> element and added commentary 1009 | about its semantics. 1010 | Added the <fee:reason> element to the <check> response so 1011 | servers can indicate why fee information is not available. 1012 | 1013 |

1014 |

1025 |

66 | Historically, domain name registries have applied a simple fee 67 | structure for billable transactions, namely a basic unit price applied to 68 | domain <create>, <renew>, <transfer> and RGP restore commands. Given the relatively small 69 | number of EPP servers to which EPP clients have been required to connect, 70 | it has generally been the case that client operators have been able to 71 | obtain details of these fees out-of-band by contacting the server 72 | operators. 73 | 74 | Given the recent expansion of the DNS namespace, and the proliferation 75 | of novel business models, it is now desirable to provide a method for EPP 76 | clients to query EPP servers for the fees and credits associated with 77 | certain commands and specific objects. 78 | 79 | This document describes an extension mapping for version 1.0 of the 80 | Extensible Provisioning Protocol (EPP). This 81 | EPP mapping provides a mechanism by which EPP clients may query the fees 82 | and credits associated with various billable transactions, and also 83 | obtain their current account balance. 84 | 85 |

86 | 87 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 | document are to be interpreted as described in 90 | RFC 2119. 91 | 92 | XML is case sensitive. Unless stated otherwise, XML specifications 93 | and examples provided in this document MUST be interpreted in the 94 | character case presented in order to develop a conforming 95 | implementation. 96 | 97 | "fee" is used as an abbreviation for 98 | "urn:ietf:params:xml:ns:fee-&VERSION;". The XML namespace prefix "fee" 99 | is used, but implementations MUST NOT depend on it and instead employ a 100 | proper namespace-aware XML parser and serializer to interpret and output 101 | the XML documents. 102 | 103 | (Note to RFC Editor: remove the following paragraph before publication 104 | as an RFC.) 105 | 106 | The XML namespace prefix above contains a version number, 107 | specifically "&VERSION;". This version number will increment with 108 | successive versions of this document, and will reach 1.0 if and when 109 | this document is published as an RFC. This permits clients to 110 | distinguish which version of the extension a server has implemented. 111 | 112 |

113 |

116 | (Note to RFC Editor: remove this section before publication as an 117 | RFC.) 118 | Servers which implement this extension SHOULD provide a 119 | way for clients to progressively update their implementations 120 | when a new version of the extension is deployed. 121 | Servers SHOULD (for a temporary migration period) provide support for 122 | older versions of the extension in parallel to the newest version, and 123 | allow clients to select their preferred version via the 124 | <svcExtension> element of the <login> command. 125 | If a client requests multiple versions of the extension at login, then, 126 | when preparing responses to commands which do not include extension elements, 127 | the server SHOULD only include extension elements in the namespace of the newest 128 | version of the extension requested by the client. 129 | When preparing responses to commands which do include extension elements, the 130 | server SHOULD only include extension elements for the extension versions present 131 | in the command. 132 |

135 | 136 |

158 | 159 |

160 | The <fee:currency> element is used to indicate which currency 161 | fees are charged in. This value of this element MUST be a three-character 162 | currency code from . 163 | 164 | Note that ISO 4217 provides the special "XXX" code, which MAY be used 165 | if the server uses a non-currency based system for assessing fees, such as 166 | a system of credits. 167 | 168 | The use of <fee:currency> elements in commands is OPTIONAL: 169 | if a <fee:currency> element is not present in a command, the 170 | server MUST determine the currency based on the client's account settings 171 | which MUST be agreed by the client and server via an out-of-band 172 | channel. However, the <fee:currency> element MUST be present in 173 | responses. 174 | 175 | Servers SHOULD NOT perform a currency conversion if a client uses an 176 | incorrect currency code. Servers SHOULD return a 2004 error instead. 177 |

178 | 179 |

180 | When querying for fee information using the <check> command, 181 | the <fee:period> element is used to indicate the units to be added 182 | to the registration period of objects by the <create>, 183 | <renew> and <transfer> commands. This element is derived 184 | from the <domain:period> element described in . 185 | 186 | The <fee:period> element is OPTIONAL in <check> commands: 187 | if omitted, the server MUST determine the fee(s) using a validity period 188 | of 1 year. The <fee:period> element MUST be present in <check> 189 | responses. 190 | 191 |

192 | 193 |

236 | <fee:fee> elements MAY have an OPTIONAL "refundable" attribute 237 | which takes a boolean value. Fees may be refunded under certain 238 | circumstances, such as when a domain application is rejected (as 239 | described in ) or when 240 | an object is deleted during the relevant Grace Period (see below). 241 | 242 | If the "refundable" attribute is omitted, then clients SHOULD NOT make 243 | any assumption about the refundability of the fee. 244 |

245 | 246 |

247 | describes a system of "grace periods", 248 | which are time periods following a billable transaction during which, 249 | if an object is deleted, the client receives a refund. 250 | 251 | The "grace-period" attribute MAY be used to indicate the relevant 252 | grace period for a fee. If a server implements the Registry Grace 253 | Period extension, it MUST specify the grace period for all relevant 254 | transactions. 255 | 256 | If the "grace-period" attribute is omitted, then clients 257 | SHOULD NOT make any assumption about the grace period of the fee. 258 |

259 | 260 |

261 | If a <fee:fee> element has a "grace-period" attribute then 262 | it MUST also be refundable. If the "refundable" attribute of a 263 | <fee:fee> element is false then it MUST NOT have a 264 | "grace-period" attribute. 265 |

266 | 267 |

268 | Fees may be applied immediately upon receipt of a command from a 269 | client, or may only be applied once an out-of-band process (such as 270 | the processing of applications at the end of a launch phase) has 271 | taken place. 272 | 273 | The "applied" attribute of the <fee:fee> element allows 274 | servers to indicate whether a fee will be applied immediately, or 275 | whether it will be applied at some point in the future. This 276 | attribute takes two possible values: "immediate" (which is the 277 | default) or "delayed". 278 |

279 |

280 | 281 |

282 | The <fee:balance> element is an OPTIONAL element which MAY 283 | be included in server responses to transform commands. If present, 284 | it can be used by the client to determine the remaining credit at 285 | the server. 286 | 287 | Whether or not the <fee:balance> is included in responses is a 288 | matter of server policy. However, if a server chooses 289 | to offer support for this element, it MUST be included in responses 290 | to all "transform" commands (ie <create>, <renew>, 291 | <update>, <delete>, <transfer op="request">). 292 | 293 | The value of the <fee:balance> MAY be negative. A negative 294 | balance indicates that the server has extended a line of credit to the 295 | client (see below). 296 | 297 | If a server includes a <fee:balance> element in response to 298 | transform commands, the value of the element MUST reflect the client's 299 | account balance after any fees or credits associated with that command 300 | have been applied. 301 |

302 | 303 |

304 | As described above, if a server returns a response containing a 305 | <fee:balance> with a negative value, then the server has extended a 306 | line of credit to the client. A server MAY also include a 307 | <fee:creditLimit> element in responses which indicates the maximum 308 | credit available to a client. A server MAY reject certain transactions if 309 | the absolute value of the <fee:balance> is equal to or exceeds the 310 | value of the <fee:creditLimit> element. 311 | 312 | Whether or not the <fee:creditLimit> is included in responses 313 | is a matter of server policy. However, if a server chooses 314 | to offer support for this element, it MUST be included in responses 315 | to all "transform" commands (ie <create>, <renew>, 316 | <update>, <delete>, <transfer op="request">). 317 |

318 | 319 |

320 | Objects may be assigned to a particular class, category, or tier, 321 | each of which has a particular fee or set of fees associated with it. The 322 | <fee:class> element which appears in <check> responses is 323 | used to indicate the classification of an object. 324 | 325 | If a server makes use of this element, it should provide clients with a 326 | list of all the values that the element may take via an out-of-band 327 | channel. Servers MUST NOT use values which do not appear on this list. 328 | 329 | Servers which make use of this element MUST use a <fee:class> 330 | element with the value "standard" for all objects that are subject to the 331 | standard or default fee. 332 |

333 |

336 | 337 | Depending on server policy, a client MAY be required to include the 338 | extension elements described in this document for certain transform 339 | commands. Servers must provide clear documentation to clients about the 340 | circumstances in which this extension must be used. 341 | 342 | If a server receives a command from a client which does not include 343 | the extension elements required by the server for that command, then 344 | it MUST respond with a 2003 "Required parameter missing" error. 345 | 346 | If the currency or total fee provided by the client do not agree 347 | with the server's own calculation of the fee for that command, then the 348 | server MUST reject the command with a 2004 "Parameter value range" 349 | error. 350 | 351 |

354 | Sometimes, the time interval between when a client queries the 355 | fee for a command, and when that command takes place, is long enough that 356 | there is a non-negligible probability that the fee might change in 357 | the intervening time. 358 | 359 | To ensure that clients can obtain the most accurate fee information 360 | in such circumstances, clients can include a <fee:cmdDate> element 361 | in fee <check> commands, to indicate the anticipated date and time 362 | of a billable transaction. 363 | 364 | If a server receives a command containing a <fee:cmdDate> element, 365 | and the server is unable to provide accurate fee information for the given 366 | date and time, then it MUST respond with a 2306 "Parameter value policy 367 | error" error. Otherwise, the server MUST return fee information that will 368 | prevail at the date and time provided. 369 | 370 | This extension provides no mechanism to enforce the application of these 371 | fees when the command is subsequently submitted; servers MUST reject commands 372 | which include incorrect fee information, as described above. 373 | 374 | If a server knows that the fee information it is returning to a client 375 | is going to change in the future, it MAY include <fee:notAfter> 376 | elements in <check> responses. This element contains a date and time 377 | after which the provided fee information will no longer apply. Clients which 378 | receive a response from a server which contain <fee:notAfter> elements 379 | may then re-query for the fee information (using the <fee:cmdDate> 380 | element) described above if the value of the <fee:notAfter> element 381 | is before the anticipated time when the command will be submitted. 382 |

385 | 386 | A detailed description of the EPP syntax and semantics can be found in 387 | . 388 | 389 |

390 | This extension does not add any elements to the EPP <poll> or 391 | <info> commands or responses. 392 | 393 |

394 | This extension defines additional elements for the EPP 395 | <check> command. 396 | 397 | The command MAY contain an <extension> element which 398 | MAY contain a <fee:check> element. The <fee:check> element 399 | contains the following child elements: 400 | 401 | 402 | A <fee:command> element; 403 | 404 | An OPTIONAL <fee:currency> element; 405 | 406 | An OPTIONAL <fee:period> element. 407 | 408 | An OPTIONAL <fee:class> element. 409 | 410 | An OPTIONAL <fee:cmdDate> element. 411 | 412 | 413 | Example <check> command: 414 | 415 |

580 | When a server supports classes as described in Section 3.7, 581 | and the <fee:class> element is present in the command, the server MUST 582 | validate the value of this element, and return an error for unknown values. 583 | If the given value is incorrect for the specified object, the 584 | "avail" attribute of the corresponding <fee:cd> element MUST be 585 | false. 586 | 587 | The <fee:cd> section MUST contain the appropriate 588 | <fee:class> element when the servers support classes, as described 589 | in Section 3.7, and the "avail" 590 | attribute of the <fee:cd> element is true. 591 |

592 |

593 | 594 |

664 | 665 |

666 | 667 |

668 | 669 |

670 | This extension adds elements to both the EPP <create> command 671 | and response, when the extension has been selected during a 672 | <login> command. 673 | 674 | When submitting a <create> command to the server, the client 675 | MAY include in the <extension> element a <fee:create> 676 | element which includes the following child elements: 677 | 678 | 679 | An OPTIONAL <fee:currency> element; 680 | 681 | One or more <fee:fee> elements. 682 | 683 | 684 | When the <create> command has been processed successfully, 685 | and the client selected the extension when it logged in, and a fee was 686 | assessed by the server for the transaction, the server MUST include in 687 | the <extension> section of the EPP response a 688 | <fee:creData> element, which contains the following child 689 | elements: 690 | 691 | 692 | A <fee:currency> element; 693 | 694 | Zero or more <fee:fee> elements; 695 | 696 | Zero or more <fee:credit> elements; 697 | 698 | An OPTIONAL <fee:balance> element; 699 | 700 | An OPTIONAL <fee:creditLimit> element. 701 | 702 | 703 | If no fee or credit has been assessed by the server for this transaction, 704 | a <fee:creData> element MUST NOT be included in the response. 705 | 706 | Example <create> command: 707 | 708 |

774 | 775 |

776 | This extension does not add any elements to the EPP <delete> 777 | command, but does include elements in the response, when the extension 778 | has been selected during the <login> command. 779 | 780 | When the <delete> command has been processed successfully, 781 | and the client selected the extension when it logged in, the server 782 | MAY include in the <extension> section of the EPP response a 783 | <fee:delData> element, which contains the following child 784 | elements: 785 | 786 | 787 | A <fee:currency> element; 788 | 789 | Zero or more <fee:fee> elements; 790 | 791 | Zero or more <fee:credit> elements; 792 | 793 | An OPTIONAL <fee:balance> element; 794 | 795 | An OPTIONAL <fee:creditLimit> element. 796 | 797 | 798 | If no credit has been assessed by the server for this transaction, 799 | a <fee:delData> element MUST NOT be included in the response. 800 | 801 | Example <delete> response: 802 | 803 |

826 | 827 |

828 | This extension adds elements to both the EPP <renew> command 829 | and response, when the extension has been selected during a 830 | <login> command. 831 | 832 | When submitting a <renew> command to the server, the client 833 | MAY include in the <extension> element a <fee:renew> 834 | element which includes the following child elements: 835 | 836 | 837 | An OPTIONAL <fee:currency> element; 838 | 839 | One or more <fee:fee> elements. 840 | 841 | 842 | When the <renew> command has been processed successfully, 843 | and the client selected the extension when it logged in, the server 844 | MAY include in the <extension> section of the EPP response a 845 | <fee:renData> element, which contains the following child 846 | elements: 847 | 848 | 849 | A <fee:currency> element; 850 | 851 | Zero or more <fee:fee> elements; 852 | 853 | Zero or more <fee:credit> elements; 854 | 855 | An OPTIONAL <fee:balance> element; 856 | 857 | An OPTIONAL <fee:creditLimit> element. 858 | 859 | 860 | If no fee or credit has been assessed by the server for this transaction, 861 | a <fee:renData> element MUST NOT be included in the response. 862 | 863 | Example <renew> command: 864 | 865 |

920 | 921 |

922 | This extension adds elements to both the EPP <transfer> 923 | command and response, when the value of the "op" attribute of the 924 | <transfer> command element is "request", and the extension has 925 | been selected during the <login> command. 926 | 927 | When submitting a <transfer> command to the server, the client 928 | MAY include in the <extension> element a <fee:transfer> 929 | element which includes the following child elements: 930 | 931 | 932 | An OPTIONAL <fee:currency> element; 933 | 934 | One or more <fee:fee> elements. 935 | 936 | 937 | When the <transfer> command has been processed successfully, 938 | and the client selected the extension when it logged in, the server 939 | MAY include in the <extension> section of the EPP response a 940 | <fee:trnData> element, which contains the following child 941 | elements: 942 | 943 | 944 | A <fee:currency> element; 945 | 946 | Zero or more <fee:fee> elements; 947 | 948 | Zero or more <fee:credit> elements; 949 | 950 | An OPTIONAL <fee:balance> element; 951 | 952 | An OPTIONAL <fee:creditLimit> element. 953 | 954 | 955 | If no fee or credit has been assessed by the server for this transaction, 956 | a <fee:trnData> element MUST NOT be included in the response. 957 | 958 | Example <transfer> command: 959 | 960 |

1021 | 1022 |

1023 | This extension adds elements to both the EPP <update> command 1024 | and response, when the extension has been selected during a 1025 | <login> has been selected during the <login> command. 1026 | 1027 | When submitting a <update> command to the server, the client 1028 | MAY include in the <extension> element a <fee:update> 1029 | element which includes the following child elements: 1030 | 1031 | 1032 | An OPTIONAL <fee:currency> element; 1033 | 1034 | One or more <fee:fee> elements. 1035 | 1036 | 1037 | When the <update> command has been processed successfully, 1038 | and the client selected the extension when it logged in, the server 1039 | MAY include in the <extension> section of the EPP response a 1040 | <fee:upData> element, which contains the following child 1041 | elements: 1042 | 1043 | 1044 | A <fee:currency> element; 1045 | 1046 | Zero or more <fee:fee> elements; 1047 | 1048 | Zero or more <fee:credit> elements; 1049 | 1050 | An OPTIONAL <fee:balance> element; 1051 | 1052 | An OPTIONAL <fee:creditLimit> element. 1053 | 1054 | 1055 | If no fee or credit has been assessed by the server for this transaction, 1056 | a <fee:upData> element MUST NOT be included in the response. 1057 | 1058 | Example <update> command: 1059 | 1060 |

1108 | 1109 |

1110 | 1111 |

1112 | An EPP object mapping is specified in XML Schema notation. The formal 1113 | syntax presented here is a complete schema representation of the object 1114 | mapping suitable for automated validation of EPP XML instances. 1115 | 1116 | Copyright (c) 2014 IETF Trust and the persons identified as authors 1117 | of the code. All rights reserved. 1118 | 1119 | Redistribution and use in source and binary forms, with or without 1120 | modification, are permitted provided that the following conditions are 1121 | met: 1122 | 1123 | 1124 | Redistributions of source code must retain the above copyright 1125 | notice, this list of conditions and the following disclaimer. 1126 | 1127 | Redistributions in binary form must reproduce the above copyright 1128 | notice, this list of conditions and the following disclaimer in the 1129 | documentation and/or other materials provided with the 1130 | distribution. 1131 | 1132 | Neither the name of Internet Society, IETF or IETF Trust, nor the 1133 | names of specific contributors, may be used to endorse or promote 1134 | products derived from this software without specific prior written 1135 | permission. 1136 | 1137 | 1138 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1139 | "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1140 | LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 1141 | PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER 1142 | OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 1143 | EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 1144 | PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR 1145 | PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 1146 | LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 1147 | NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 1148 | SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1149 | 1150 |

1151 | BEGIN 1152 | <?xml version="1.0" encoding="utf-8"?> 1153 | <schema xmlns="http://www.w3.org/2001/XMLSchema" 1154 | xmlns:fee="urn:ietf:params:xml:ns:fee-0.12" 1155 | xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" 1156 | xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 1157 | targetNamespace="urn:ietf:params:xml:ns:fee-0.12" 1158 | elementFormDefault="qualified"> 1159 | 1160 | <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" /> 1161 | <import namespace="urn:ietf:params:xml:ns:domain-1.0" /> 1162 | 1163 | <annotation> 1164 | <documentation>Extensible Provisioning Protocol 1165 | v1.0 extension schema for fee 1166 | information.</documentation> 1167 | </annotation> 1168 | 1169 |  1172 | <element name="check" type="fee:checkType" /> 1173 | <element name="chkData" type="fee:chkDataType" /> 1174 | <element name="create" type="fee:transformCommandType" /> 1175 | <element name="creData" type="fee:transformResultType" /> 1176 | <element name="renew" type="fee:transformCommandType" /> 1177 | <element name="renData" type="fee:transformResultType" /> 1178 | <element name="transfer" type="fee:transformCommandType" /> 1179 | <element name="trnData" type="fee:transferResultType" /> 1180 | <element name="update" type="fee:transformCommandType" /> 1181 | <element name="updData" type="fee:transformResultType" /> 1182 | <element name="delData" type="fee:transformResultType" /> 1183 | 1184 |  1187 | <complexType name="checkType"> 1188 | <sequence> 1189 | <element name="command" type="fee:commandType" /> 1190 | <element name="currency" type="fee:currencyType" 1191 | minOccurs="0" /> 1192 | <element name="period" type="domain:periodType" 1193 | minOccurs="0" /> 1194 | <element name="class" type="token" 1195 | minOccurs="0" /> 1196 | <element name="cmdDate" type="dateTime" 1197 | minOccurs="0" /> 1198 | </sequence> 1199 | </complexType> 1200 | 1201 |  1204 | <complexType name="chkDataType"> 1205 | <sequence> 1206 | <element name="cd" type="fee:objectCDType" 1207 | maxOccurs="unbounded" /> 1208 | </sequence> 1209 | </complexType> 1210 | 1211 | <complexType name="objectCDType"> 1212 | <sequence> 1213 | <element name="object"> 1214 | <complexType> 1215 | <sequence> 1216 | <any namespace="##other" processContents="lax"/> 1217 | </sequence> 1218 | </complexType> 1219 | </element> 1220 | <element name="command" type="fee:commandType" /> 1221 | <element name="currency" type="fee:currencyType" /> 1222 | <element name="period" type="domain:periodType" 1223 | minOccurs="0" maxOccurs="1" /> 1224 | <element name="fee" type="fee:feeType" 1225 | minOccurs="0" maxOccurs="unbounded" /> 1226 | <element name="credit" type="fee:creditType" 1227 | minOccurs="0" maxOccurs="unbounded" /> 1228 | <element name="class" type="token" minOccurs="0" /> 1229 | <element name="reason" type="token" minOccurs="0" /> 1230 | <element name="cmdDate" type="dateTime" 1231 | minOccurs="0" /> 1232 | <element name="notAfter" type="dateTime" 1233 | minOccurs="0" /> 1234 | </sequence> 1235 | <attribute name="avail" type="boolean" default="1" /> 1236 | </complexType> 1237 | 1238 |  1241 | <complexType name="transformCommandType"> 1242 | <sequence> 1243 | <element name="currency" type="fee:currencyType" 1244 | minOccurs="0" /> 1245 | <element name="fee" type="fee:feeType" 1246 | maxOccurs="unbounded" /> 1247 | <element name="credit" type="fee:creditType" 1248 | minOccurs="0" maxOccurs="unbounded" /> 1249 | </sequence> 1250 | </complexType> 1251 | 1252 |  1255 | <complexType name="transformResultType"> 1256 | <sequence> 1257 | <element name="currency" type="fee:currencyType" /> 1258 | <element name="fee" type="fee:feeType" 1259 | minOccurs="0" maxOccurs="unbounded" /> 1260 | <element name="credit" type="fee:creditType" 1261 | minOccurs="0" maxOccurs="unbounded" /> 1262 | <element name="balance" type="fee:balanceType" 1263 | minOccurs="0" /> 1264 | <element name="creditLimit" type="fee:creditLimitType" 1265 | minOccurs="0" /> 1266 | </sequence> 1267 | </complexType> 1268 | 1269 |  1272 | <complexType name="transferResultType"> 1273 | <sequence> 1274 | <element name="currency" type="fee:currencyType" /> 1275 | 1276 |  1277 | <element name="period" type="domain:periodType" 1278 | minOccurs="0" /> 1279 | 1280 | <element name="fee" type="fee:feeType" 1281 | maxOccurs="unbounded" /> 1282 | <element name="credit" type="fee:creditType" 1283 | minOccurs="0" maxOccurs="unbounded" /> 1284 | 1285 | <element name="balance" type="fee:balanceType" 1286 | minOccurs="0" /> 1287 | <element name="creditLimit" type="fee:creditLimitType" 1288 | minOccurs="0" /> 1289 | </sequence> 1290 | </complexType> 1291 | 1292 |  1295 | <simpleType name="currencyType"> 1296 | <restriction base="string"> 1297 | <pattern value="[A-Z]{3}" /> 1298 | </restriction> 1299 | </simpleType> 1300 | 1301 | <complexType name="commandType"> 1302 | <simpleContent> 1303 | <extension base="fee:commandTypeValue"> 1304 | <attribute name="phase" type="token" /> 1305 | <attribute name="subphase" type="token" /> 1306 | </extension> 1307 | </simpleContent> 1308 | </complexType> 1309 | 1310 | <simpleType name="commandTypeValue"> 1311 | <restriction base="token"> 1312 | <minLength value="3"/> 1313 | <maxLength value="16"/> 1314 | </restriction> 1315 | </simpleType> 1316 | 1317 | <simpleType name="nonNegativeDecimal"> 1318 | <restriction base="decimal"> 1319 | <minInclusive value="0" /> 1320 | </restriction> 1321 | </simpleType> 1322 | 1323 | <simpleType name="negativeDecimal"> 1324 | <restriction base="decimal"> 1325 | <maxInclusive value="0" /> 1326 | </restriction> 1327 | </simpleType> 1328 | 1329 | <complexType name="feeType"> 1330 | <simpleContent> 1331 | <extension base="fee:nonNegativeDecimal"> 1332 | <attribute name="description"/> 1333 | <attribute name="refundable" type="boolean" /> 1334 | <attribute name="grace-period" type="duration" /> 1335 | <attribute name="applied" default="immediate"> 1336 | <simpleType> 1337 | <restriction base="token"> 1338 | <enumeration value="immediate" /> 1339 | <enumeration value="delayed" /> 1340 | </restriction> 1341 | </simpleType> 1342 | </attribute> 1343 | </extension> 1344 | </simpleContent> 1345 | </complexType> 1346 | 1347 | <complexType name="creditType"> 1348 | <simpleContent> 1349 | <extension base="fee:negativeDecimal"> 1350 | <attribute name="description"/> 1351 | </extension> 1352 | </simpleContent> 1353 | </complexType> 1354 | 1355 | <simpleType name="balanceType"> 1356 | <restriction base="decimal" /> 1357 | </simpleType> 1358 | 1359 | <simpleType name="creditLimitType"> 1360 | <restriction base="decimal" /> 1361 | </simpleType> 1362 | 1363 | </schema> 1364 | 1365 | END 1366 | 1367 |

1368 | 1369 |

1372 | The mapping extensions described in this document do not provide any 1373 | security services beyond those described by EPP, 1374 | the EPP domain name mapping, and protocol 1375 | layers used by EPP. The security considerations described in these other 1376 | specifications apply to this specification as well.

1379 |

1380 | This document uses URNs to describe XML namespaces and XML schemas 1381 | conforming to a registry mechanism described in . 1382 | The following URI assignment is requested of IANA: 1383 | URI: urn:ietf:params:xml:ns:fee-&VERSION; 1384 | Registrant Contact: See the "Author's Address" section of this 1385 | document. 1386 | XML: See the "Formal Syntax" section of this document. 1387 |

1388 |

1389 | The EPP extension described in this document should be registered 1390 | by the IANA in the EPP Extension Registry described in . The details of the registration are as follows: 1391 | Name of Extension: EPP Fee Extension 1392 | Document status: Standards Track 1393 | Reference: (insert reference to RFC version of this document) 1394 | Registrant Name and Email Address: See the "Author's Address" section 1395 | of this document. 1396 | TLDs: any 1397 | IPR Disclosure: none 1398 | Status: active 1399 | Notes: none 1400 |

1401 |

1404 | Note to RFC Editor: Please remove this section and the reference to 1405 | before publication. 1406 | 1407 | This section records the status of known implementations of the 1408 | protocol defined by this specification at the time of posting of this 1409 | Internet-Draft, and is based on a proposal described in . 1410 | The description of implementations in this section is 1411 | intended to assist the IETF in its decision processes in progressing 1412 | drafts to RFCs. Please note that the listing of any individual 1413 | implementation here does not imply endorsement by the IETF. 1414 | Furthermore, no effort has been spent to verify the information 1415 | presented here that was supplied by IETF contributors. This is not 1416 | intended as, and must not be construed to be, a catalog of available 1417 | implementations or their features. Readers are advised to note that 1418 | other implementations may exist. 1419 | 1420 | According to , "this will allow reviewers and 1421 | working groups to assign due consideration to documents that have the 1422 | benefit of running code, which may serve as evidence of valuable 1423 | experimentation and feedback that have made the implemented protocols 1424 | more mature. It is up to the individual working groups to use this 1425 | information as they see fit". 1426 | 1427 |

1428 | Organization: CentralNic 1429 | Name: RegistryEngine EPP Service 1430 | Description: Generic high-volume EPP service for gTLDs, ccTLDs and SLDs 1431 | Level of maturity: Deployed in CentralNic's production environment as well 1432 | as two other gTLD registry systems, and two ccTLD registry systems. 1433 | Coverage: All aspects of the protocol are implemented. 1434 | Licensing: Proprietary In-House software 1435 | Contact: epp@centralnic.com 1436 | URL: https://www.centralnic.com 1437 |

1438 |

1460 |

1469 |

1489 |

1490 | 1491 | Added the "applied" attribute to to <fee:fee> elements. 1492 | Simplified the wording in relation to when a server can return an 1493 | error for extended <info> commands. 1494 | Added the <fee:period> element to transfer query responses. 1495 | Removed wording about how servers behave when receiving incorrect 1496 | fee information from transform commands, and put it into a single 1497 | section at the top of the document. 1498 | Allow servers to omit <fee:fee> elements from <fee:cd> 1499 | elements if the command specified by the client is forbidden. 1500 | 1501 |

1502 |

1503 | 1504 | Changed Intended Status to Standards Track. 1505 | As per suggestion from Michael Bauland, the <fee:period> 1506 | element is no longer included in <check> and <info> 1507 | responses for "restore" commands. It's still mandatory for all other 1508 | commands. 1509 | Added summary of the attributes for the <fee:fee> element. 1510 | Clarified that the "refundable" and "grace-period" attributes of 1511 | the <fee:fee> elements are dependant on each other and cannot 1512 | appear on their own. 1513 | Removed the option of returning a 1001 response when the fee is 1514 | incorrect. 1515 | Forbidden the inclusion of extension elements in transform responses 1516 | if no fee/credit has been assessed. 1517 | Made the <fee:currency> element optional in transform 1518 | commands. 1519 | Amended XML Namespace section of IANA Considerations, added 1520 | EPP Extension Registry section. 1521 | 1522 |

1523 |

1524 | 1525 | Removed the extended <info> command. The <check> command 1526 | is the only command that can be used now. 1527 | Introduced a mandatory-to-implement "standard" class for non-premium 1528 | domains. 1529 | The decision was made to keep availability info in <check> responses 1530 | as registrars have indicated that it is very useful as it avoids unnecessary 1531 | round trips to the server. 1532 | Allow <fee:credit> elements to be present in <check> 1533 | responses. 1534 | Allow the number of <fee:fee> which can appear in transform responses 1535 | to be zero. 1536 | Removed the <fee:balance> and <fee:creditLimit> elements from 1537 | transfer query responses. The reason is that these elements are defined 1538 | as containing the values after the transform command has taken place - which 1539 | means that it is not appropriate to include them in a query response. 1540 | Added Implementation Status section. 1541 | 1542 |

1543 |

1544 | 1545 | The specification is now object-agnostic, but works with 1546 | RFC5731 domains by default. 1547 | Renamed the <fee:domain> element to <fee:object>. Added the 1548 | "objURI" attribute. 1549 | Removed the default value for the "refundable" attribute of <fee:fee> 1550 | elements, and added text about how clients should handle such cases. Added similar 1551 | text to the documentation of the "grace-period" attribute. 1552 | Removed references to the defunct <info> command syntax. 1553 | "MUST" requirements regarding documentation have been changed to "must". 1554 | Created separate "Correlation between Refundability and Grace Periods" section 1555 | describing how the "refundable" and "grace-period" attributes work together. 1556 | 1557 |

1558 |

1559 | 1560 | Changed the syntax of the <check> form to be simpler: a single set of 1561 | <fee:command>, <fee:currency> etc elements is applied to the objects 1562 | specified in the main body of the <check> command. 1563 | Simplified the object-agnosticism to simply copy the element from the 1564 | <check> command into the <fee:cd> element. 1565 | Added the "avail" attribute to the <fee:cd> element and added commentary 1566 | about its semantics. 1567 | Added the <fee:reason> element to the <check> response so 1568 | servers can indicate why fee information is not available. 1569 | 1570 |

1571 |

1582 |