idnits 2.17.1 draft-ietf-regext-epp-fees-06.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 (August 3, 2017) is 2457 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: 'ISO4217' is mentioned on line 207, but not defined == Unused Reference: 'I-D.ietf-regext-launchphase' is defined on line 1490, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-regext-launchphase-05 ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions R. Carney 3 Internet-Draft GoDaddy Inc. 4 Intended status: Standards Track G. Brown 5 Expires: February 4, 2018 CentralNic Group plc 6 J. Frakes 7 August 3, 2017 9 Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 10 draft-ietf-regext-epp-fees-06 12 Abstract 14 This document describes an Extensible Provisioning Protocol (EPP) 15 extension mapping for registry fees. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on February 4, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 53 2. Migrating to Newer Versions of This Extension . . . . . . . . 4 54 3. Extension Elements . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Client Commands . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Currency Codes . . . . . . . . . . . . . . . . . . . . . 5 57 3.3. Validity Periods . . . . . . . . . . . . . . . . . . . . 5 58 3.4. Fees and Credits . . . . . . . . . . . . . . . . . . . . 5 59 3.4.1. Refunds . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.4.2. Grace Periods . . . . . . . . . . . . . . . . . . . . 7 61 3.4.3. Correlation between Refundability and Grace Periods . 7 62 3.4.4. Applicability . . . . . . . . . . . . . . . . . . . . 7 63 3.5. Account Balance . . . . . . . . . . . . . . . . . . . . . 7 64 3.6. Credit Limit . . . . . . . . . . . . . . . . . . . . . . 8 65 3.7. Classification of Objects . . . . . . . . . . . . . . . . 8 66 3.8. Phase and Subphase Attributes . . . . . . . . . . . . . . 8 67 3.9. Reason . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4. Server Handling of Fee Information . . . . . . . . . . . . . 10 69 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 10 71 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 10 72 5.1.1.1. Server Handling of Elements . . . . . . . . . . . 14 73 5.1.2. EPP Transfer Query Command . . . . . . . . . . . . . 15 74 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 16 75 5.2.1. EPP Command . . . . . . . . . . . . . . . . 16 76 5.2.2. EPP Command . . . . . . . . . . . . . . . . 19 77 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 20 78 5.2.4. EPP Command . . . . . . . . . . . . . . . 22 79 5.2.5. EPP Command . . . . . . . . . . . . . . . . 24 80 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 81 6.1. Fee Extension Schema . . . . . . . . . . . . . . . . . . 26 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 84 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 30 85 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 31 86 9. Implemntation Status . . . . . . . . . . . . . . . . . . . . 31 87 9.1. RegistryEngine EPP Service . . . . . . . . . . . . . . . 32 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 89 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 33 90 11.1. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 33 91 11.2. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 33 92 11.3. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 33 93 11.4. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 33 94 11.5. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 33 95 11.6. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 34 96 11.7. Change from draft-brown-00 to draft-ietf-regext-fees-00 34 98 12. Normative References . . . . . . . . . . . . . . . . . . . . 34 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 101 1. Introduction 103 Historically, domain name registries have applied a simple fee 104 structure for billable transactions, namely a basic unit price 105 applied to domain , , and RGP [RFC3915] 106 restore commands. Given the relatively small number of EPP servers 107 to which EPP clients have been required to connect, it has generally 108 been the case that client operators have been able to obtain details 109 of these fees out-of-band by contacting the server operators. 111 Given the recent expansion of the DNS namespace, and the 112 proliferation of novel business models, it is now desirable to 113 provide a method for EPP clients to query EPP servers for the fees 114 and credits associated with certain commands and specific objects. 116 This document describes an extension mapping for version 1.0 of the 117 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 118 provides a mechanism by which EPP clients may query the fees and 119 credits associated with various billable transactions, and obtain 120 their current account balance. 122 1.1. Conventions Used in This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 XML is case sensitive. Unless stated otherwise, XML specifications 129 and examples provided in this document MUST be interpreted in the 130 character case presented in order to develop a conforming 131 implementation. 133 "fee" is used as an abbreviation for "urn:ietf:params:xml:ns:fee- 134 0.23". The XML namespace prefix "fee" is used, but implementations 135 MUST NOT depend on it and instead employ a proper namespace-aware XML 136 parser and serializer to interpret and output the XML documents. 138 In examples, "C:" represents lines sent by a protocol client and "S:" 139 represents lines returned by a protocol server. Indentation and 140 white space in examples are provided only to illustrate element 141 relationships and are not a REQUIRED feature of this protocol. 143 (Note to RFC Editor: remove the following paragraph before 144 publication as an RFC.) 145 The XML namespace prefix above contains a version number, 146 specifically "0.23". This version number will increment with 147 successive versions of this document, and will reach 1.0 if and when 148 this document is published as an RFC. This permits clients to 149 distinguish which version of the extension a server has implemented. 151 2. Migrating to Newer Versions of This Extension 153 (Note to RFC Editor: remove this section before publication as an 154 RFC.) 156 Servers which implement this extension SHOULD provide a way for 157 clients to progressively update their implementations when a new 158 version of the extension is deployed. 160 Servers SHOULD (for a temporary migration period) provide support for 161 older versions of the extension in parallel to the newest version, 162 and allow clients to select their preferred version via the 163 element of the command. 165 If a client requests multiple versions of the extension at login, 166 then, when preparing responses to commands which do not include 167 extension elements, the server SHOULD only include extension elements 168 in the namespace of the newest version of the extension requested by 169 the client. 171 When preparing responses to commands which do include extension 172 elements, the server SHOULD only include extension elements for the 173 extension versions present in the command. 175 3. Extension Elements 177 3.1. Client Commands 179 The element is used in the EPP command to 180 determine the fee which is applicable to the given command. 182 The list of values include: 184 o "create" indicating a command as defined in [RFC5730]; 185 o "delete" indicating a command as defined in [RFC5730]; 186 o "renew" indicating a command as defined in [RFC5730]; 187 o "update" indicating a command as defined in [RFC5730]; 188 o "transfer" indicating a command as defined in 189 [RFC5730]; 190 o If the server supports the Registry Grace Period Mapping 191 [RFC3915], then the server MUST also support the "restore" value 192 as defined in [RFC3915]; 194 o "custom" indicating a custom command that uses the customName 195 attribute to define the custom operation. 197 The element MAY have an OPTIONAL "phase" attribute 198 specifying a launch phase as described in [draft-ietf-eppext- 199 launchphase]. It may also contain an OPTIONAL "subphase" attribute 200 identifying the custom or sub-phase as described in [draft-ietf- 201 eppext-launchphase]. 203 3.2. Currency Codes 205 The element is used to indicate which currency fees 206 are charged in. This value of this element MUST be a three-character 207 currency code from [ISO4217]. 209 Note that ISO 4217 provides the special "XXX" code, which MAY be used 210 if the server uses a non-currency based system for assessing fees, 211 such as a system of credits. 213 The use of elements in client commands is OPTIONAL: if 214 a element is not present in a command, the server MUST 215 determine the currency based on the client's account settings which 216 MUST be agreed by the client and server via an out-of-band channel. 217 However, the element MUST be present in responses. 219 Servers SHOULD NOT perform a currency conversion if a client uses an 220 incorrect currency code. Servers SHOULD return a 2004 "Parameter 221 value range" error instead. 223 3.3. Validity Periods 225 When querying for fee information using the command, the 226 element is used to indicate the units to be added to the 227 registration period of objects by the , and 228 commands. This element is derived from the 229 element described in [RFC5731]. 231 The element is OPTIONAL in commands, if omitted, 232 the server MUST determine the fee(s) using the server default period. 233 The element MUST be present in responses. 235 3.4. Fees and Credits 237 Servers which implement this extension will include elements in 238 responses which provide information about the fees and/or credits 239 associated with a given billable transaction. 241 The and elements are used to provide this 242 information. The presence of a element in a response 243 indicates a debit against the client's account balance; a 244 element indicates a credit. A element MUST 245 have a non-negative value. A element MUST have a 246 negative value. 248 A server MAY respond with multiple and 249 elements in the same response. In such cases, the net fee or credit 250 applicable to the transaction is the arithmetic sum of the values of 251 each of the and/or elements. This amount 252 applies to the total additional validity period applied to the object 253 (where applicable) rather than to any incremental unit. 255 The following attributes are defined for the element. 256 These are described in detail below: 258 description: an OPTIONAL attribute which provides a human-readable 259 description of the fee. Servers should provide documentation on the 260 possible values of this attribute, and their meanings. 262 refundable: an OPTIONAL boolean attribute indicating whether the fee 263 is refundable if the object is deleted. 265 grace-period: an OPTIONAL attribute which provides the time period 266 during which the fee is refundable. 268 applied: an OPTIONAL attribute indicating when the fee will be 269 deducted from the client's account. 271 The element can take a "description" attribute as 272 described above. No other attributes are defined for this element. 274 3.4.1. Refunds 276 elements MAY have an OPTIONAL "refundable" attribute which 277 takes a boolean value. Fees may be refunded under certain 278 circumstances, such as when a domain application is rejected (as 279 described in [draft-ietf-eppext-launchphase]) or when an object is 280 deleted during the relevant Grace Period (see below). 282 If the "refundable" attribute is omitted, then clients SHOULD NOT 283 make any assumption about the refundability of the fee. 285 3.4.2. Grace Periods 287 [RFC3915] describes a system of "grace periods", which are time 288 periods following a billable transaction during which, if an object 289 is deleted, the client receives a refund. 291 The "grace-period" attribute MAY be used to indicate the relevant 292 grace period for a fee. If a server implements the Registry Grace 293 Period extension, it MUST specify the grace period for all relevant 294 transactions. 296 If the "grace-period" attribute is omitted, then clients SHOULD NOT 297 make any assumption about the grace period of the fee. 299 3.4.3. Correlation between Refundability and Grace Periods 301 If a element has a "grace-period" attribute then it MUST 302 also be refundable. If the "refundable" attribute of a 303 element is false then it MUST NOT have a "grace-period" attribute. 305 3.4.4. Applicability 307 Fees may be applied immediately upon receipt of a command from a 308 client, or may only be applied once an out-of-band process (such as 309 the processing of applications at the end of a launch phase) has 310 taken place. 312 The "applied" attribute of the element allows servers to 313 indicate whether a fee will be applied immediately, or whether it 314 will be applied at some point in the future. This attribute takes 315 two possible values: "immediate" or "delayed". 317 3.5. Account Balance 319 The element is an OPTIONAL element which MAY be 320 included in server responses to transform commands. If present, it 321 can be used by the client to determine the remaining credit at the 322 server. 324 Whether or not the is included in responses is a matter 325 of server policy. However, if a server chooses to offer support for 326 this element, it MUST be included in responses to all "transform" or 327 billable commands (ie , , , , 328 ). 330 The value of the MAY be negative. A negative balance 331 indicates that the server has extended a line of credit to the client 332 (see below). 334 If a server includes a element in response to transform 335 commands, the value of the element MUST reflect the client's account 336 balance after any fees or credits associated with that command have 337 been applied. 339 3.6. Credit Limit 341 As described above, if a server returns a response containing a 342 with a negative value, then the server has extended a 343 line of credit to the client. A server MAY also include a 344 element in responses which indicates the maximum 345 credit available to a client. A server MAY reject certain 346 transactions if the absolute value of the is equal to 347 or exceeds the value of the element. 349 Whether or not the is included in responses is a 350 matter of server policy. However, if a server chooses to offer 351 support for this element, it MUST be included in responses to all 352 "transform" commands (ie , , , , 353 ). 355 3.7. Classification of Objects 357 Objects may be assigned to a particular class, category, or tier, 358 each of which has a particular fee or set of fees associated with it. 359 The element, which MAY appear in and transform 360 responses, is used to indicate the classification of an object. 362 If a server makes use of this element, it should provide clients with 363 a list of all the values that the element may take via an out-of-band 364 channel. Servers MUST NOT use values which do not appear on this 365 list. 367 Servers which make use of this element MUST use a element 368 with the value "standard" for all objects that are subject to the 369 standard or default fee. 371 3.8. Phase and Subphase Attributes 373 The element has two attributes, phase and subphase, 374 that provide additional information related to a specific launch 375 phase as described in [draft-ietf-eppext-launchphase]. 377 If the client contains a server supported combination 378 of phase/subphase the server MUST return fee data (including the 379 phase/subphase attribute(s)) for the specific combination. 381 If the client contains no phase/subphase attributes and 382 the server has only one active phase/subphase combination the server 383 MUST return data (including the phase/subphase attribute(s)) of the 384 currently active phase/subphase. 386 If the client contains no phase/subphase attributes and 387 the server has more than one active phase/subphase combination the 388 server MUST respond with a 2003 "Required parameter missing" error. 390 If the client contains no phase/subphase attributes and 391 the server is currently in a "quiet period" (e.g. not accepting 392 registrations or applications) the server MUST return data consistent 393 with the general availability phase. 395 If the client contains a phase attribute with no 396 subphase and the server has only one active subphase (or no subphase) 397 of this phase, the server MUST return data (including the phase/ 398 subphase attribute(s)) of the provided phase and currently active 399 subphase. 401 If the client contains a phase attribute with no 402 subphase and the server has more than one active subphase combination 403 of this phase, the server MUST respond with a 2003 "Required 404 parameter missing" error. 406 If the client contains a subphase with no phase 407 attribute the server MUST respond with a 2003 "Required parameter 408 missing" error. 410 If the client contains a phase attribute not defined in 411 [draft-ietf-eppext-launchphase] or not supported by server the server 412 MUST respond with a 2004 "Parameter value range" error. 414 If the client contains a subphase attribute (or phase/ 415 subphase combination) not supported by server the server MUST respond 416 with a 2004 "Parameter value range" error. 418 3.9. Reason 420 The element is used to provide server specific text in 421 an effort to better explain why an operation did not complete as the 422 client expected. An OPTIONAL "lang" attribute MAY be present to 423 identify the language of the returned text. 425 4. Server Handling of Fee Information 427 Depending on server policy, a client MAY be required to include the 428 extension elements described in this document for certain transform 429 commands. Servers must provide clear documentation to clients about 430 the circumstances in which this extension must be used. 432 The server MUST return avail="0" in its response to a command 433 for any domain name in the command that does not include the 434 extension for which the server would likewise fail a 435 domain command when no extension is provided for that 436 same domain name. 438 If a server receives a command from a client which does not include 439 the fee extension data elements required by the server for that 440 command, then the server MUST respond with a 2003 "Required parameter 441 missing" error. 443 If the currency or total fee provided by the client is less than the 444 server's own calculation of the fee for that command, then the server 445 MUST reject the command with a 2004 "Parameter value range" error. 447 5. EPP Command Mapping 449 A detailed description of the EPP syntax and semantics can be found 450 in [RFC5730]. 452 5.1. EPP Query Commands 454 This extension does not add any elements to the EPP or 455 commands or responses. 457 5.1.1. EPP Command 459 This extension defines a new command called the Fee Check Command 460 that defines additional elements for the EPP command to 461 provide fee information along with the availability information of 462 the EPP command. 464 The command MAY contain an element which MAY contain a 465 element. The element MAY contain one 466 element and MUST contain one or more 467 elements. 469 The element(s) contain(s) a "name" attribute, an 470 OPTIONAL "phase" attribute, and an OPTIONAL "subphase" attribute. 471 The element(s) MAY have the following child elements: 473 o An OPTIONAL element (as described in Section 3.3). 475 Example command: 477 C: 478 C: 479 C: 480 C: 481 C: 483 C: example.com 484 C: example.net 485 C: example.xyz 486 C: 487 C: 488 C: 489 C: 490 C: USD 491 C: 492 C: 2 493 C: 494 C: 495 C: 496 C: 497 C: 498 C: 499 C: ABC-12345 500 C: 501 C: 503 When the server receives a command that includes the 504 extension elements described above, its response MUST contain an 505 element, which MUST contain a child 506 element. The element MUST contain a 507 element and a for each element referenced in the client 508 command. 510 Each element MUST contain the following child elements: 512 o A element, which MUST match an element referenced in 513 the client command. 514 o A element matching each (unless the 515 "avail" attribute of the if false) that appeared in the 516 corresponding of the client command. This element MAY 517 have the OPTIONAL "phase" and "subphase" attributes, which MUST 518 match the same attributes in the corresponding 519 element of the client command if sent by the client. 521 The element also has an OPTIONAL "avail" attribute which is 522 a boolean. If the value of this attribute evaluates to false, this 523 indicates that the server cannot calculate the relevant fees, because 524 the object, command, currency, period, class or some combination is 525 invalid per server policy. If "avail" is false then the 526 element MUST contain a element (as described in 527 Section 3.9) and the server MAY eliminate some or all of the 528 element(s). 530 The element(s) MAY have the following child elements: 532 o An OPTIONAL element (as described in Section 3.3), 533 which contains the same unit that appeared in the 534 element of the command. If the value of the preceding 535 element is "restore", this element MUST NOT be 536 included, otherwise it MUST be included. If no 537 appeared in the client command (and the command is not "restore") 538 then the server MUST return its default period value. 539 o Zero or more elements (as described in Section 3.4). 540 o Zero or more elements (as described in Section 3.4). 541 o An OPTIONAL element (as described in Section 3.7). 542 o An OPTIONAL element (as described in Section 3.9). 544 If the "avail" attribute of the element is true and if no 545 elements are present in a element, this 546 indicates that no fee will be assessed by the server for this 547 command. 549 If the "avail" attribute is true, then the element MUST 550 NOT contain a element. 552 Example response: 554 S: 555 S: 556 S: 557 S: 558 S: Command completed successfully 559 S: 560 S: 561 S: 563 S: 564 S: example.com 565 S: 566 S: 567 S: example.net 568 S: 569 S: 570 S: example.xyz 571 S: 572 S: 573 S: 574 S: 575 S: 578 S: USD 579 S: 580 S: example.com 581 S: 582 S: 2 583 S: 10.00 587 S: 588 S: 589 S: 1 590 S: 5.00 594 S: 595 S: 596 S: 1 597 S: 5.00 601 S: 602 S: 603 S: 5.00 605 S: 606 S: 607 S: 608 S: example.net 609 S: 610 S: 2 611 S: 10.00 615 S: 616 S: 617 S: 1 618 S: 5.00 622 S: 623 S: 624 S: 1 625 S: 5.00 629 S: 630 S: 631 S: 5.00 633 S: 634 S: 635 S: 636 S: example.xyz 637 S: 638 S: 2 639 S: Only 1 year registration periods are 640 S: vaild. 641 S: 642 S: 643 S: 644 S: 645 S: 646 S: ABC-12345 647 S: 54322-XYZ 648 S: 649 S: 650 S: 652 5.1.1.1. Server Handling of Elements 654 Clients MAY include a in the element. 655 There are two ways in which servers may handle this element: 657 1. If the server supports the concept of tiers or classes of 658 objects, then the value of this element MUST be validated. If 659 incorrect for the specified object, the "avail" attribute of the 660 corresponding element MUST be false. 661 2. If the server supports different "types" of object registrations 662 (such as a "blocking" registration which does not resolve, or 663 where a registry provides a value-added service that requires an 664 opt-out to disable), then, as with the first model, the server 665 MUST validate the value of the element. If the value is 666 incorrect, the "avail" attribute of the corresponding 667 element MUST be false, and a element (as described 668 in Section 3.9) MUST be provided. 670 Server operators must provide clear documentation to client operators 671 which of the above models it supports. 673 5.1.2. EPP Transfer Query Command 675 This extension does not add any elements to the EPP query 676 command, but does include elements in the response, when the 677 extension has been selected during a command. 679 When the query command has been processed successfully, 680 the client selected the extension when it logged in, and the client 681 is authorized by the server to view information about the transfer, 682 the server MAY include in the section of the EPP response 683 a element, which contains the following child elements: 685 o A element (as described in Section 3.2). 686 o A element (as described in Section 3.3). 687 o Zero or more elements (as described in Section 3.4) 688 containing the fees that will be charged to the gaining client. 689 o Zero or more elements (as described in Section 3.4) 690 containing the credits that will be refunded to the losing client. 692 Servers SHOULD omit when returning a response to the 693 gaining client, and omit elements when returning a response 694 to the losing client. 696 If no element is included in the response, then no fee 697 will be assessed by the server for the transfer. 699 Example query response: 701 S: 702 S: 703 S: 704 S: 705 S: Command completed successfully; action pending 706 S: 707 S: 708 S: 710 S: example.com 711 S: pending 712 S: ClientX 713 S: 2000-06-08T22:00:00.0Z 714 S: ClientY 715 S: 2000-06-13T22:00:00.0Z 716 S: 2002-09-08T22:00:00.0Z 717 S: 718 S: 719 S: 720 S: 721 S: USD 722 S: 1 723 S: 5.00 724 S: 725 S: 726 S: 727 S: ABC-12345 728 S: 54322-XYZ 729 S: 730 S: 731 S: 733 5.2. EPP Transform Commands 735 5.2.1. EPP Command 737 This extension adds elements to both the EPP command and 738 response, when the extension has been selected during a 739 command. 741 If a command is received with no extension and 742 the server requires a extension for the 743 the server MUST respond with a 2003 "Required parameter missing" 744 error. 746 When submitting a command to the server, the client MAY 747 include in the element a element which 748 includes the following child elements: 750 o An OPTIONAL element (as described in Section 3.2); 751 o One or more elements (as described in Section 3.4). 753 The server MUST fail the command if the provided 754 by the client is less than the server fee. 756 When the command has been processed successfully, and the 757 client selected the extension when it logged in, and a fee was 758 assessed by the server for the transaction, the server MUST include 759 in the section of the EPP response a 760 element, which contains the following child elements: 762 o A element (as described in Section 3.2); 763 o Zero or more elements (as described in Section 3.4); 764 o Zero or more elements (as described in Section 3.4); 765 o An OPTIONAL element (as described in Section 3.5); 766 o An OPTIONAL element (as described in 767 Section 3.6). 769 Example command: 771 C: 772 C: 773 C: 774 C: 775 C: 777 C: example.com 778 C: 2 779 C: 780 C: ns1.example.net 781 C: ns2.example.net 782 C: 783 C: jd1234 784 C: sh8013 785 C: sh8013 786 C: 787 C: 2fooBAR 788 C: 789 C: 790 C: 791 C: 792 C: 793 C: USD 794 C: 5.00 795 C: 796 C: 797 C: ABC-12345 798 C: 799 C: 800 Example response: 802 S: 803 S: 804 S: 805 S: 806 S: Command completed successfully 807 S: 808 S: 809 S: 811 S: example.com 812 S: 1999-04-03T22:00:00.0Z 813 S: 2001-04-03T22:00:00.0Z 814 S: 815 S: 816 S: 817 S: 818 S: USD 819 S: 5.00 823 S: -5.00 824 S: 1000.00 825 S: 826 S: 827 S: 828 S: ABC-12345 829 S: 54321-XYZ 830 S: 831 S: 832 S: 834 5.2.2. EPP Command 836 This extension does not add any elements to the EPP command, 837 but does include elements in the response, when the extension has 838 been selected during the command. 840 When the command has been processed successfully, and the 841 client selected the extension when it logged in, the server MAY 842 include in the section of the EPP response a 843 element, which contains the following child elements: 845 o A element (as described in Section 3.2); 846 o Zero or more elements (as described in Section 3.4); 847 o Zero or more elements (as described in Section 3.4); 848 o An OPTIONAL element (as described in Section 3.5); 849 o An OPTIONAL element (as described in 850 Section 3.6). 852 Example response: 854 S: 855 S: 856 S: 857 S: 858 S: Command completed successfully 859 S: 860 S: 861 S: 863 S: USD 864 S: -5.00 865 S: 1005.00 866 S: 867 S: 868 S: 869 S: ABC-12345 870 S: 54321-XYZ 871 S: 872 S: 873 S: 875 5.2.3. EPP Command 877 This extension adds elements to both the EPP command and 878 response, when the extension has been selected during a 879 command. 881 When submitting a command to the server, the client MAY 882 include in the element a element which 883 includes the following child elements: 885 o An OPTIONAL element (as described in Section 3.2); 886 o One or more elements (as described in Section 3.4). 888 When the command has been processed successfully, and the 889 client selected the extension when it logged in, the server MAY 890 include in the section of the EPP response a 891 element, which contains the following child elements: 893 o A element (as described in Section 3.2); 894 o Zero or more elements (as described in Section 3.4); 895 o Zero or more elements (as described in Section 3.4); 896 o An OPTIONAL element (as described in Section 3.5); 897 o An OPTIONAL element (as described in 898 Section 3.6). 900 Example command: 902 C: 903 C: 904 C: 905 C: 906 C: 908 C: example.com 909 C: 2000-04-03 910 C: 5 911 C: 912 C: 913 C: 914 C: 915 C: USD 916 C: 5.00 917 C: 918 C: 919 C: ABC-12345 920 C: 921 C: 922 Example response: 924 S: 925 S: 926 S: 927 S: 928 S: Command completed successfully 929 S: 930 S: 931 S: 933 S: example.com 934 S: 2005-04-03T22:00:00.0Z 935 S: 936 S: 937 S: 938 S: 939 S: USD 940 S: 5.00 943 S: 1000.00 944 S: 945 S: 946 S: 947 S: ABC-12345 948 S: 54322-XYZ 949 S: 950 S: 951 S: 953 5.2.4. EPP Command 955 This extension adds elements to both the EPP command and 956 response, when the value of the "op" attribute of the 957 command element is "request", and the extension has been selected 958 during the command. 960 When submitting a command to the server, the client MAY 961 include in the element a element which 962 includes the following child elements: 964 o An OPTIONAL element (as described in Section 3.2); 965 o One or more elements (as described in Section 3.4). 967 When the command has been processed successfully, and the 968 client selected the extension when it logged in, the server MAY 969 include in the section of the EPP response a 970 element, which contains the following child elements: 972 o A element (as described in Section 3.2); 973 o Zero or more elements (as described in Section 3.4); 974 o Zero or more elements (as described in Section 3.4); 975 o An OPTIONAL element (as described in Section 3.5); 976 o An OPTIONAL element (as described in 977 Section 3.6). 979 Example command: 981 C: 982 C: 983 C: 984 C: 985 C: 987 C: example.com 988 C: 1 989 C: 990 C: 2fooBAR 991 C: 992 C: 993 C: 994 C: 995 C: 996 C: USD 997 C: 5.00 998 C: 999 C: 1000 C: ABC-12345 1001 C: 1002 C: 1003 Example response: 1005 S: 1006 S: 1007 S: 1008 S: 1009 S: Command completed successfully; action pending 1010 S: 1011 S: 1012 S: 1014 S: example.com 1015 S: pending 1016 S: ClientX 1017 S: 2000-06-08T22:00:00.0Z 1018 S: ClientY 1019 S: 2000-06-13T22:00:00.0Z 1020 S: 2002-09-08T22:00:00.0Z 1021 S: 1022 S: 1023 S: 1024 S: 1025 S: USD 1026 S: 5.00 1029 S: 1030 S: 1031 S: 1032 S: ABC-12345 1033 S: 54322-XYZ 1034 S: 1035 S: 1036 S: 1038 5.2.5. EPP Command 1040 This extension adds elements to both the EPP command and 1041 response, when the extension has been selected during the 1042 command. 1044 When submitting a command to the server, the client MAY 1045 include in the element a element which 1046 includes the following child elements: 1048 o An OPTIONAL element (as described in Section 3.2); 1049 o One or more elements (as described in Section 3.4). 1051 When the command has been processed successfully, and the 1052 client selected the extension when it logged in, the server MAY 1053 include in the section of the EPP response a 1054 element, which contains the following child elements: 1056 o A element (as described in Section 3.2); 1057 o Zero or more elements (as described in Section 3.4); 1058 o Zero or more elements (as described in Section 3.4); 1059 o An OPTIONAL element (as described in Section 3.5); 1060 o An OPTIONAL element (as described in 1061 Section 3.6). 1063 Example command: 1065 C: 1066 C: 1067 C: 1068 C: 1069 C: 1071 C: example.com 1072 C: 1073 C: sh8013 1074 C: 1075 C: 1076 C: 1077 C: 1078 C: 1079 C: USD 1080 C: 5.00 1081 C: 1082 C: 1083 C: ABC-12345 1084 C: 1085 C: 1086 Example response: 1088 S: 1089 S: 1090 S: 1091 S: 1092 S: Command completed successfully 1093 S: 1094 S: 1095 S: 1096 S: USD 1097 S: 5.00 1098 S: 1099 S: 1100 S: 1101 S: ABC-12345 1102 S: 54321-XYZ 1103 S: 1104 S: 1105 S: 1107 6. Formal Syntax 1109 One schema is presented here that is the EPP Fee Extension schema. 1111 The formal syntax presented here is a complete schema representation 1112 of the object mapping suitable for automated validation of EPP XML 1113 instances. The BEGIN and END tags are not part of the schema; they 1114 are used to note the beginning and ending of the schema for URI 1115 registration purposes. 1117 6.1. Fee Extension Schema 1119 BEGIN 1120 1121 1128 1129 1131 1132 1133 Extensible Provisioning Protocol v1.0 Fee Extension 1135 1136 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1151 1152 1153 1154 1156 1158 1159 1161 1162 1163 1164 1166 1167 1168 1170 1171 1172 1173 1174 1176 1177 1179 1180 1181 1182 1184 1185 1186 1187 1189 1190 1191 1192 1194 1196 1198 1199 1201 1202 1203 1204 1206 1208 1210 1212 1214 1216 1217 1219 1220 1221 1222 1223 1224 1226 1227 1228 1230 1232 1234 1235 1236 1237 1238 1239 1240 1241 1243 1244 1245 1246 1247 1248 1249 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1263 1264 1265 1266 1267 1269 1270 1271 1272 1273 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1293 1294 1295 1296 1297 1298 1299 1301 1302 1303 1305 1306 1307 1309 1310 END 1312 7. Security Considerations 1314 The mapping extensions described in this document do not provide any 1315 security services beyond those described by EPP [RFC5730], the EPP 1316 domain name mapping [RFC5731], and protocol layers used by EPP. The 1317 security considerations described in these other specifications apply 1318 to this specification as well. 1320 8. IANA Considerations 1322 8.1. XML Namespace 1324 This document uses URNs to describe XML namespaces and XML schemas 1325 conforming to a registry mechanism described in [RFC3688]. The 1326 following URI assignment is requested of IANA: 1328 URI: ietf:params:xml:ns:fee-0.23 1330 Registrant Contact: See the "Author's Address" section of this 1331 document. 1333 XML: See the "Formal Syntax" section of this document. 1335 8.2. EPP Extension Registry 1337 The EPP extension described in this document should be registered by 1338 the IANA in the EPP Extension Registry described in [RFC7451]. The 1339 details of the registration are as follows: 1341 Name of Extension: EPP Fee Extension 1343 Document status: Standards Track 1345 Reference: (insert reference to RFC version of this document) 1347 Registrant Name and Email Address: See the "Author's Address" section 1348 of this document. 1350 TLDs: any 1352 IPR Disclosure: none 1354 Status: active 1356 Notes: none 1358 9. Implemntation Status 1360 Note to RFC Editor: Please remove this section and the reference to 1361 [RFC6982] before publication. 1363 This section records the status of known implementations of the 1364 protocol defined by this specification at the time of posting of this 1365 Internet-Draft, and is based on a proposal described in [RFC6982]. 1366 The description of implementations in this section is intended to 1367 assist the IETF in its decision processes in progressing drafts to 1368 RFCs. Please note that the listing of any individual implementation 1369 here does not imply endorsement by the IETF. Furthermore, no effort 1370 has been spent to verify the information presented here that was 1371 supplied by IETF contributors. This is not intended as, and must not 1372 be construed to be, a catalog of available implementations or their 1373 features. Readers are advised to note that other implementations may 1374 exist. 1376 According to [RFC6982], "this will allow reviewers and working groups 1377 to assign due consideration to documents that have the benefit of 1378 running code, which may serve as evidence of valuable experimentation 1379 and feedback that have made the implemented protocols more mature. 1380 It is up to the individual working groups to use this information as 1381 they see fit". 1383 9.1. RegistryEngine EPP Service 1385 Organization: CentralNic 1387 Name: RegistryEngine EPP Service 1389 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 1390 SLDs 1392 Level of maturity: Deployed in CentralNic's production environment as 1393 well as two other gTLD registry systems, and two ccTLD registry 1394 systems. 1396 Coverage: All aspects of the protocol are implemented. 1398 Licensing: Proprietary In-House software 1400 Contact: epp@centralnic.com 1402 URL: https://www.centralnic.com 1404 10. Acknowledgements 1406 The authors wish to thank the following persons for their feedback 1407 and suggestions: 1409 o James Gould of Verisign Inc 1410 o Luis Munoz of ISC 1411 o Michael Young of Architelos 1412 o Ben Levac and Jeff Eckhaus of Demand Media 1413 o Seth Goldman of Google 1414 o Klaus Malorny and Michael Bauland of Knipp 1415 o Jody Kolker, Joe Snitker and Kevin Allendorf of Go Daddy 1416 o Michael Holloway of Com Laude 1417 o Santosh Kalsangrah of Impetus Infotech 1418 o Alex Mayrhofer of Nic.at 1419 o Thomas Corte of Knipp Medien und Kommunikation GmbH 1421 11. Change History 1423 11.1. Change from 05 to 06 1425 Updated scheme to version 0.23 to allow the return of no 1426 element(s) if an error situation occurs. Edited 1427 section 3.8 extensively after input from interim meeting and REGEXT 1428 F2F meeting at IETF-99. Added normative reference for draft-ietf- 1429 eppext-launchphase. 1431 11.2. Change from 04 to 05 1433 Updated scheme to version 0.21 to support the lang attribute for the 1434 reason element of the objectCDType and the commandType types as well 1435 as to add the update command to the commandEnum type. Updated 1436 section 3.1 to include language for the custom command. Added 1437 section 3.9 to provide a description of the element. 1438 Fixed typos and added clarification text on when client fee is less 1439 than server fee in section 4. Additionally, I added description 1440 pointers to appropriate Section 3 definitions for element clarity 1441 throughout the document. 1443 11.3. Change from 03 to 04 1445 Updated scheme to version 0.19 to correct typos and to replace the 1446 commandTypeValue type with the commandEnum type and customName 1447 attribute for stricter validation. Updated various text for grammar 1448 and clarity. Added text to section 4 clarifying the response 1449 when the client provided no fee extension but the server was 1450 expecting the extension. 1452 11.4. Change from 02 to 03 1454 Updated scheme to version 0.17 to simplify the check command syntax. 1455 Moved fee avail to objectCDType to allow fast failing on error 1456 situations. Removed the objectCheckType as it was no longer being 1457 used. Updated examples to reflect these scheme changes. Added 1458 language for server failing a if the passed by the 1459 client is less than the server fee. 1461 11.5. Change from 01 to 02 1463 Updated scheme to version 0.15 to fix errors in CommandType, 1464 objectCDType, transformCommandType and transformResultType 1465 definitions. 1467 11.6. Change from 00 to 01 1469 Added Roger Carney as author to finish draft. Moved Formal Syntax 1470 section to main level numbering. Various grammar, typos, and 1471 administrative edits for clarity. Removed default value for the 1472 "applied" attribute of so that it can truly be optional. 1473 Added support for the command to return a element 1474 as well. Modified default response on the command for the 1475 optional when it was not provided in the command, 1476 leaving it to the server to provide the default period value. 1477 Extensive edits were done to the command, the 1478 response and to the fee extension schema (checkType, objectCheckType, 1479 objectIdentifierType, objectCDType, commandType) to support 1480 requesting and returning multiple transformation fees in a single 1481 call. Added section on Phase/Subphase to provide more context on the 1482 uses. 1484 11.7. Change from draft-brown-00 to draft-ietf-regext-fees-00 1486 Updated to be REGEXT WG document. 1488 12. Normative References 1490 [I-D.ietf-regext-launchphase] 1491 Gould, J., Tan, W., and G. Brown, "Launch Phase Mapping 1492 for the Extensible Provisioning Protocol (EPP)", draft- 1493 ietf-regext-launchphase-05 (work in progress), June 2017. 1495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1496 Requirement Levels", BCP 14, RFC 2119, 1497 DOI 10.17487/RFC2119, March 1997, 1498 . 1500 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1501 DOI 10.17487/RFC3688, January 2004, 1502 . 1504 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 1505 the Extensible Provisioning Protocol (EPP)", RFC 3915, 1506 DOI 10.17487/RFC3915, September 2004, 1507 . 1509 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1510 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1511 . 1513 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1514 Domain Name Mapping", STD 69, RFC 5731, 1515 DOI 10.17487/RFC5731, August 2009, 1516 . 1518 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1519 Code: The Implementation Status Section", RFC 6982, 1520 DOI 10.17487/RFC6982, July 2013, 1521 . 1523 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1524 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1525 February 2015, . 1527 Authors' Addresses 1529 Roger Carney 1530 GoDaddy Inc. 1531 14455 N. Hayden Rd. #219 1532 Scottsdale, AZ 85260 1533 US 1535 Email: rcarney@godaddy.com 1536 URI: http://www.godaddy.com 1538 Gavin Brown 1539 CentralNic Group plc 1540 35-39 Moorgate 1541 London, England EC2R 6AR 1542 GB 1544 Phone: +44 20 33 88 0600 1545 Email: gavin.brown@centralnic.com 1546 URI: http://www.centralnic.com 1548 Jothan Frakes 1550 Email: jothan@jothan.com 1551 URI: http://jothan.com