idnits 2.17.1 draft-ietf-regext-epp-fees-18.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 (September 8, 2019) is 1690 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: March 11, 2020 CentralNic Group plc 6 J. Frakes 7 September 8, 2019 9 Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 10 draft-ietf-regext-epp-fees-18 12 Abstract 14 Given the expansion of the DNS namespace, and the proliferation of 15 novel business models, it is desirable to provide a method for 16 Extensible Provisioning Protocol (EPP) clients to query EPP servers 17 for the fees and credits and provide expected fees and credits for 18 certain commands and objects. This document describes an EPP 19 extension mapping for registry fees. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 11, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. Migrating to Newer Versions of This Extension . . . . . . . . 4 58 3. Extension Elements . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Client Commands . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Currency Codes . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Validity Periods . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Fees and Credits . . . . . . . . . . . . . . . . . . . . 6 63 3.4.1. Refunds . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4.2. Grace Periods . . . . . . . . . . . . . . . . . . . . 7 65 3.4.3. Correlation between Refundability and Grace Periods . 7 66 3.4.4. Applicability . . . . . . . . . . . . . . . . . . . . 7 67 3.5. Account Balance . . . . . . . . . . . . . . . . . . . . . 8 68 3.6. Credit Limit . . . . . . . . . . . . . . . . . . . . . . 8 69 3.7. Classification of Objects . . . . . . . . . . . . . . . . 8 70 3.8. Phase and Subphase Attributes . . . . . . . . . . . . . . 9 71 3.9. Reason . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Server Handling of Fee Information . . . . . . . . . . . . . 11 73 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 12 75 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 12 76 5.1.2. EPP Transfer Query Command . . . . . . . . . . . . . 16 77 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 18 78 5.2.1. EPP Command . . . . . . . . . . . . . . . . 18 79 5.2.2. EPP Command . . . . . . . . . . . . . . . . 20 80 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 21 81 5.2.4. EPP Command . . . . . . . . . . . . . . . 23 82 5.2.5. EPP Command . . . . . . . . . . . . . . . . 25 83 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 84 6.1. Fee Extension Schema . . . . . . . . . . . . . . . . . . 27 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 87 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 32 88 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 32 89 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 33 90 9.1. RegistryEngine EPP Service . . . . . . . . . . . . . . . 33 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 92 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 34 93 11.1. Change from 17 to 18 . . . . . . . . . . . . . . . . . . 34 94 11.2. Change from 16 to 17 . . . . . . . . . . . . . . . . . . 34 95 11.3. Change from 15 to 16 . . . . . . . . . . . . . . . . . . 34 96 11.4. Change from 14 to 15 . . . . . . . . . . . . . . . . . . 35 97 11.5. Change from 13 to 14 . . . . . . . . . . . . . . . . . . 35 98 11.6. Change from 12 to 13 . . . . . . . . . . . . . . . . . . 35 99 11.7. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 35 100 11.8. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 35 101 11.9. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 35 102 11.10. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 35 103 11.11. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 36 104 11.12. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 36 105 11.13. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 36 106 11.14. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 36 107 11.15. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 36 108 11.16. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 36 109 11.17. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 37 110 11.18. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 37 111 11.19. Change from draft-brown-00 to draft-ietf-regext-fees-00 37 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 114 12.2. Informative References . . . . . . . . . . . . . . . . . 38 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 117 1. Introduction 119 Historically, domain name registries have applied a simple fee 120 structure for billable transactions, namely a basic unit price 121 applied to domain , , and RGP [RFC3915] 122 restore commands. Given the relatively small number of EPP servers 123 to which EPP clients have been required to connect, it has generally 124 been the case that client operators have been able to obtain details 125 of these fees out-of-band by contacting the server operators. 127 Given the expansion of the DNS namespace, and the proliferation of 128 novel business models, it is desirable to provide a method for EPP 129 clients to query EPP servers for the fees and credits associated with 130 certain commands and specific objects. 132 This document describes an extension mapping for version 1.0 of the 133 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 134 provides a mechanism by which EPP clients may query the fees and 135 credits associated with various billable transactions, and obtain 136 their current account balance. 138 1.1. Conventions Used in This Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 XML is case sensitive. Unless stated otherwise, XML specifications 147 and examples provided in this document MUST be interpreted in the 148 character case presented in order to develop a conforming 149 implementation. 151 "fee" is used as an abbreviation for "urn:ietf:params:xml:ns:epp:fee- 152 1.0". The XML namespace prefix "fee" is used, but implementations 153 MUST NOT depend on it and instead employ a proper namespace-aware XML 154 parser and serializer to interpret and output the XML documents. 156 In examples, "C:" represents lines sent by a protocol client and "S:" 157 represents lines returned by a protocol server. Indentation and 158 white space in examples are provided only to illustrate element 159 relationships and are not a required feature of this protocol. 161 2. Migrating to Newer Versions of This Extension 163 Servers which implement this extension SHOULD provide a way for 164 clients to progressively update their implementations when a new 165 version of the extension is deployed. 167 Servers SHOULD (for a temporary migration period) provide support for 168 older versions of the extension in parallel to the newest version, 169 and allow clients to select their preferred version via the 170 element of the command. 172 If a client requests multiple versions of the extension at login, 173 then, when preparing responses to commands which do not include 174 extension elements, the server SHOULD only include extension elements 175 in the namespace of the newest version of the extension requested by 176 the client. 178 When preparing responses to commands which do include extension 179 elements, the server SHOULD only include extension elements for the 180 extension versions present in the command. 182 3. Extension Elements 184 3.1. Client Commands 186 The element is used in the EPP command to 187 determine the fee that is applicable to the given command. 189 The use of the keys off the use of the "name" attribute 190 to define which transform fees the client is requesting information 191 about. Here is the list of possible values for the "name" attribute: 193 o "create" indicating a command as defined in [RFC5730]; 194 o "delete" indicating a command as defined in [RFC5730]; 195 o "renew" indicating a command as defined in [RFC5730]; 196 o "update" indicating a command as defined in [RFC5730]; 197 o "transfer" indicating a command as defined in 198 [RFC5730]; 199 o If the server supports the Registry Grace Period Mapping 200 [RFC3915], then the server MUST also support the "restore" value 201 as defined in [RFC3915]; 202 o "custom" indicating a custom command that uses the "customName" 203 attribute to define the custom operation. 205 The element MAY have an OPTIONAL "phase" attribute 206 specifying a launch phase as described in [RFC8334]. It may also 207 contain an OPTIONAL "subphase" attribute identifying the custom or 208 sub-phase as described in [RFC8334]. 210 3.2. Currency Codes 212 The element is used to indicate which currency fees 213 are charged in. This value of this element MUST be a three-character 214 currency code from [ISO4217:2015]. 216 Note that ISO 4217:2015 provides the special "XXX" code, which MAY be 217 used if the server uses a non-currency based system for assessing 218 fees, such as a system of credits. 220 The use of elements in client commands is OPTIONAL: if 221 a element is not present in a command, the server MUST 222 determine the currency based on the server default currency or based 223 on the client's account settings which are agreed to by the client 224 and server via an out-of-band channel. However, the 225 element MUST be present in responses. 227 Servers SHOULD NOT perform a currency conversion if a client uses an 228 incorrect currency code. Servers SHOULD return a 2004 "Parameter 229 value range" error instead. 231 3.3. Validity Periods 233 When querying for fee information using the command, the 234 element is used to indicate the units to be added to the 235 registration period of objects by the , and 236 commands. This element is derived from the 237 element described in [RFC5731]. 239 The element is OPTIONAL in commands, if omitted, 240 the server MUST determine the fee(s) using the server default period. 241 The element MUST be present in responses. 243 3.4. Fees and Credits 245 Servers which implement this extension will include elements in 246 responses which provide information about the fees and/or credits 247 associated with a given billable transaction. A fee will result in 248 subtracting from the Account Balance (described in Section 3.5) and a 249 credit will result in adding to the Account Balance (described in 250 Section 3.5). 252 The and elements are used to provide this 253 information. The presence of a element in a response 254 indicates a debit against the client's account balance; a 255 element indicates a credit. A element MUST 256 have a non-negative value. A element MUST have a 257 negative value. 259 A server MAY respond with multiple and 260 elements in the same response. In such cases, the net fee or credit 261 applicable to the transaction is the arithmetic sum of the values of 262 each of the and/or elements. This amount 263 applies to the total additional validity period applied to the object 264 (where applicable) rather than to any incremental unit. 266 The following attributes are defined for the element. 267 These are described in detail below: 269 description: an OPTIONAL attribute which provides a human-readable 270 description of the fee. Servers should provide documentation on the 271 possible values of this attribute, and their meanings. An OPTIONAL 272 "lang" attribute MAY be present to identify the language of the 273 returned text and has a default value of "en" (English). 275 refundable: an OPTIONAL boolean attribute indicating whether the fee 276 is refundable if the object is deleted. 278 grace-period: an OPTIONAL attribute which provides the time period 279 during which the fee is refundable. 281 applied: an OPTIONAL attribute indicating when the fee will be 282 deducted from the client's account. 284 The element can take a "description" attribute as 285 described above. An OPTIONAL "lang" attribute MAY be present to 286 identify the language of the returned text and has a default value of 287 "en" (English). 289 3.4.1. Refunds 291 elements MAY have an OPTIONAL "refundable" attribute which 292 takes a boolean value. Fees may be refunded under certain 293 circumstances, such as when a domain application is rejected (as 294 described in [RFC8334]) or when an object is deleted during the 295 relevant Grace Period (see below). 297 If the "refundable" attribute is omitted, then clients SHOULD NOT 298 make any assumption about the refundability of the fee. 300 3.4.2. Grace Periods 302 [RFC3915] describes a system of "grace periods", which are time 303 periods following a billable transaction during which, if an object 304 is deleted, the client receives a refund. 306 The "grace-period" attribute MAY be used to indicate the relevant 307 grace period for a fee. If a server implements the Registry Grace 308 Period extension [RFC3915], it MUST specify the grace period for all 309 relevant transactions. 311 If the "grace-period" attribute is omitted, then clients SHOULD NOT 312 make any assumption about the grace period of the fee. 314 3.4.3. Correlation between Refundability and Grace Periods 316 If a element has a "grace-period" attribute then it MUST 317 also be refundable and the "refundable" attribute MUST be true. If 318 the "refundable" attribute of a element is false then it 319 MUST NOT have a "grace-period" attribute. 321 3.4.4. Applicability 323 Fees may be applied immediately upon receipt of a command from a 324 client, or may only be applied once an out-of-band process (such as 325 the processing of applications at the end of a launch phase) has 326 taken place. 328 The "applied" attribute of the element allows servers to 329 indicate whether a fee will be applied immediately, or whether it 330 will be applied at some point in the future. This attribute takes 331 two possible values: "immediate" or "delayed". 333 3.5. Account Balance 335 The element is an OPTIONAL element which MAY be 336 included in server responses to transform commands. If present, it 337 can be used by the client to determine the remaining credit at the 338 server. 340 Whether or not the is included in responses is a matter 341 of server policy. However, if a server chooses to offer support for 342 this element, it MUST be included in responses to all "transform" or 343 billable commands (e.g. , , , , 344 ). 346 The value of the MAY be negative. A negative balance 347 indicates that the server has extended a line of credit to the client 348 (see below). 350 If a server includes a element in response to transform 351 commands, the value of the element MUST reflect the client's account 352 balance after any fees or credits associated with that command have 353 been applied. If the "applied" attribute of the element is 354 "delayed", then the MUST reflect the client's account 355 balance without any fees or credits associated with that command. 357 3.6. Credit Limit 359 As described above, if a server returns a response containing a 360 with a negative value, then the server has extended a 361 line of credit to the client. A server MAY also include a 362 element in responses that indicates the maximum 363 credit available to a client. A server MAY reject certain 364 transactions if the absolute value of the is equal to 365 or exceeds the value of the element. 367 Whether or not the is included in responses is a 368 matter of server policy. However, if a server chooses to offer 369 support for this element, it MUST be included in responses to all 370 "transform" commands (e.g. , , , , 371 ). 373 3.7. Classification of Objects 375 Objects may be assigned to a particular class, category, or tier, 376 each of which has a particular fee or set of fees associated with it. 377 The element, which MAY appear in and transform 378 responses, is used to indicate the classification of an object. 380 If a server makes use of this element, it should provide clients with 381 a list of all the values that the element may take via an out-of-band 382 channel. Servers MUST NOT use values which do not appear on this 383 list. 385 Servers that make use of this element MUST use a element 386 with the value "standard" for all objects that are subject to the 387 standard or default fee. 389 3.8. Phase and Subphase Attributes 391 The element has two attributes, phase and subphase, 392 that provide additional information related to a specific launch 393 phase as described in [RFC8334]. These attributes are used as 394 filters that should refine the server processing. 396 If the client contains a server supported combination 397 of phase/subphase the server MUST return fee data (including the 398 phase/subphase attribute(s)) for the specific combination. 400 If the client contains no phase/subphase attributes and 401 the server has only one active phase/subphase combination the server 402 MUST return data (including the phase/subphase attribute(s)) of the 403 currently active phase/subphase. 405 If the client contains no phase/subphase attributes and 406 the server has more than one active phase/subphase combination the 407 server MUST respond with a 2003 "Required parameter missing" error. 409 If the client contains no phase/subphase attributes and 410 the server is currently in a "quiet period" (e.g. not accepting 411 registrations or applications) the server MUST return data consistent 412 with the default general availability phase (e.g. "open" or "claims") 413 including the appropriate phase/subphase attribute(s). 415 If the client contains a phase attribute with no 416 subphase and the server has only one active subphase (or no subphase) 417 of this phase, the server MUST return data (including the phase/ 418 subphase attribute(s)) of the provided phase and currently active 419 subphase. 421 If the client contains a phase attribute with no 422 subphase and the server has more than one active subphase combination 423 of this phase, the server MUST respond with a 2003 "Required 424 parameter missing" error. 426 If the client contains a subphase with no phase 427 attribute the server MUST respond with a 2003 "Required parameter 428 missing" error. 430 If the client contains a phase attribute not defined in 431 [RFC8334] or not supported by server the server MUST respond with a 432 2004 "Parameter value range" error. 434 If the client contains a subphase attribute (or phase/ 435 subphase combination) not supported by server the server MUST respond 436 with a 2004 "Parameter value range" error. 438 3.9. Reason 440 The element is used to provide server specific text in 441 an effort to better explain why a command did not complete as 442 the client expected. An OPTIONAL "lang" attribute MAY be present to 443 identify the language of the returned text and has a default value of 444 "en" (English). 446 The element can be used within the server response 447 element or within the element. 449 If the server cannot calculate the relevant fees, because the object, 450 command, currency, period, class or some combination is invalid per 451 server policy, the server has two ways of handling error processing 452 of element(s): 454 1. Fast-fail - The server, upon error identification, MAY stop 455 processing elements and return to the client a 456 containing the and a element 457 detailing the reason for failure. 459 S: 460 S: example.xyz 461 S: Only 1 year registration periods are 462 S: valid. 463 S: 465 2. Partial-fail - The server, upon error identification, MAY 466 continue processing elements and return to the 467 client a containing successfully processed 468 elements and failed elements. All returned failed 469 elements MUST have a element detailing 470 the reason for failure, and the server MAY additionally include a 471 element at the level. 473 S: 474 S: example.xyz 475 S: 476 S: 2 477 S: Only 1 year registration periods are 478 S: valid. 479 S: 480 S: 482 In either failure scenario the server MUST set the avail 483 attribute to false (0) and the server MUST process all objects in the 484 client request. 486 4. Server Handling of Fee Information 488 Depending on server policy, a client MAY be required to include the 489 extension elements described in this document for certain transform 490 commands. Servers must provide clear documentation to clients about 491 the circumstances in which this extension must be used. 493 The server MUST return avail="0" in its response to a command 494 for any object in the command that does not include the 495 extension for which the server would likewise fail a 496 domain command when no extension is provided for that 497 same object. 499 If a server receives a command from a client, which results 500 in no possible fee combination but where a fee is required, the 501 server MUST set the "avail" attribute of the element to 502 false and provide a . 504 If a server receives a command from a client, which results 505 in an ambiguous result (i.e. multiple possible fee combinations) the 506 server MUST reject the command with a 2003 "Required parameter 507 missing" error. 509 If a server receives a command from a client, which does not include 510 the fee extension data elements required by the server for that 511 command, then the server MUST respond with a 2003 "Required parameter 512 missing" error. 514 If the currency or total fee provided by the client is less than the 515 server's own calculation of the fee for that command, then the server 516 MUST reject the command with a 2004 "Parameter value range" error. 518 5. EPP Command Mapping 520 A detailed description of the EPP syntax and semantics can be found 521 in [RFC5730]. 523 5.1. EPP Query Commands 525 This extension does not add any elements to the EPP or 526 commands or responses. 528 5.1.1. EPP Command 530 This extension defines a new command called the Fee Check Command 531 that defines additional elements for the EPP command to 532 provide fee information along with the availability information of 533 the EPP command. 535 The command MAY contain an element which MAY contain a 536 element. The element MAY contain one 537 element and MUST contain one or more 538 elements. 540 The element(s) contain(s) a "name" attribute (see 541 Section 3.1), an OPTIONAL "phase" attribute, and an OPTIONAL 542 "subphase" attribute (see Section 3.8). The element(s) 543 MAY have the following child elements: 545 o An OPTIONAL element (as described in Section 3.3). 547 Example command: 549 C: 550 C: 551 C: 552 C: 553 C: 555 C: example.com 556 C: example.net 557 C: example.xyz 558 C: 559 C: 560 C: 561 C: 562 C: USD 563 C: 564 C: 2 565 C: 566 C: 567 C: 568 C: 569 C: 570 C: 571 C: ABC-12345 572 C: 573 C: 575 When the server receives a command that includes the 576 extension elements described above, its response MUST contain an 577 element, which MUST contain a child 578 element. The element MUST contain a 579 element and a for each element referenced in the client 580 command. 582 Each element MUST contain the following child elements: 584 o A element, which MUST match an element referenced in 585 the client command. 586 o An OPTIONAL element (as described in Section 3.7). 587 o A element matching each (unless the 588 "avail" attribute of the if false) that appeared in the 589 corresponding of the client command. This element MAY 590 have the OPTIONAL "standard" attribute, with a default value of 591 "0" (or "false"), which indicates whether the fee matches the fee 592 of the "standard" classification (see section 3.7). This element 593 MAY have the OPTIONAL "phase" and "subphase" attributes, which 594 SHOULD match the same attributes in the corresponding 595 element of the client command if sent by the client. 597 The element also has an OPTIONAL "avail" attribute which is 598 a boolean. If the value of this attribute evaluates to false, this 599 indicates that the server cannot calculate the relevant fees, because 600 the object, command, currency, period, class or some combination is 601 invalid per server policy. If "avail" is false then the or 602 the element MUST contain a element (as 603 described in Section 3.9) and the server MAY eliminate some or all of 604 the element(s). 606 The element(s) MAY have the following child elements: 608 o An OPTIONAL element (as described in Section 3.3), 609 which contains the same unit that appeared in the 610 element of the command. If the value of the preceding 611 element is "restore", this element MUST NOT be 612 included, otherwise it MUST be included. If no 613 appeared in the client command (and the command is not "restore") 614 then the server MUST return its default period value. 615 o Zero or more elements (as described in Section 3.4). 616 o Zero or more elements (as described in Section 3.4). 617 o An OPTIONAL element (as described in Section 3.9). 619 If the "avail" attribute of the element is true and if no 620 elements are present in a element, this 621 indicates that no fee will be assessed by the server for this 622 command. 624 If the "avail" attribute is true, then the element MUST 625 NOT contain a element. 627 Example response: 629 S: 630 S: 631 S: 632 S: 633 S: Command completed successfully 634 S: 635 S: 636 S: 638 S: 639 S: example.com 640 S: 641 S: 642 S: example.net 643 S: 644 S: 645 S: example.xyz 646 S: 647 S: 648 S: 649 S: 650 S: 652 S: USD 653 S: 654 S: example.com 655 S: Premium 656 S: 657 S: 2 658 S: 10.00 662 S: 663 S: 664 S: 1 665 S: 10.00 669 S: 670 S: 671 S: 1 672 S: 10.00 676 S: 677 S: 678 S: 15.00 680 S: 681 S: 682 S: 683 S: example.net 684 S: standard 685 S: 686 S: 2 687 S: 5.00 691 S: 692 S: 693 S: 1 694 S: 5.00 698 S: 699 S: 700 S: 1 701 S: 5.00 705 S: 706 S: 707 S: 5.00 709 S: 710 S: 711 S: 712 S: example.xyz 713 S: 714 S: 2 715 S: Only 1 year registration periods are 716 S: valid. 717 S: 718 S: 719 S: 720 S: 721 S: 722 S: ABC-12345 723 S: 54322-XYZ 724 S: 725 S: 726 S: 728 5.1.2. EPP Transfer Query Command 730 This extension does not add any elements to the EPP query 731 command, but does include elements in the response, when the 732 extension is included in the command service extensions. 734 When the query command has been processed successfully, if 735 the client has included the extension in the command service 736 element, and if the client is authorized by the server 737 to view information about the transfer, then the server MAY include 738 in the section of the EPP response a 739 element, which contains the following child elements: 741 o A element (as described in Section 3.2). 742 o A element (as described in Section 3.3). 743 o Zero or more elements (as described in Section 3.4) 744 containing the fees that will be charged to the gaining client. 745 o Zero or more elements (as described in Section 3.4) 746 containing the credits that will be refunded to the losing client. 748 Servers SHOULD omit when returning a response to the 749 gaining client, and omit elements when returning a response 750 to the losing client. 752 If no element is included in the response, then no fee 753 will be assessed by the server for the transfer. 755 Example query response: 757 S: 758 S: 759 S: 760 S: 761 S: Command completed successfully; action pending 762 S: 763 S: 764 S: 766 S: example.com 767 S: pending 768 S: ClientX 769 S: 2000-06-08T22:00:00.0Z 770 S: ClientY 771 S: 2000-06-13T22:00:00.0Z 772 S: 2002-09-08T22:00:00.0Z 773 S: 774 S: 775 S: 776 S: 777 S: USD 778 S: 1 779 S: 5.00 780 S: 781 S: 782 S: 783 S: ABC-12345 784 S: 54322-XYZ 785 S: 786 S: 787 S: 789 5.2. EPP Transform Commands 791 5.2.1. EPP Command 793 This extension adds elements to both the EPP command and 794 response, when the extension is included in the command 795 service extensions. 797 When submitting a command to the server, the client MAY 798 include in the element a element which 799 includes the following child elements: 801 o An OPTIONAL element (as described in Section 3.2); 802 o One or more elements (as described in Section 3.4). 804 The server MUST fail the command if the provided 805 by the client is less than the server fee. 807 When the command has been processed successfully, and the 808 client included the extension in the command service 809 extensions, and a fee was assessed by the server for the transaction, 810 the server MUST include in the section of the EPP 811 response a element, which contains the following child 812 elements: 814 o A element (as described in Section 3.2); 815 o Zero or more elements (as described in Section 3.4); 816 o Zero or more elements (as described in Section 3.4); 817 o An OPTIONAL element (as described in Section 3.5); 818 o An OPTIONAL element (as described in 819 Section 3.6). 821 Example command: 823 C: 824 C: 825 C: 826 C: 827 C: 829 C: example.com 830 C: 2 831 C: 832 C: ns1.example.net 833 C: ns2.example.net 834 C: 835 C: jd1234 836 C: sh8013 837 C: sh8013 838 C: 839 C: 2fooBAR 840 C: 841 C: 842 C: 843 C: 844 C: 845 C: USD 846 C: 5.00 847 C: 848 C: 849 C: ABC-12345 850 C: 851 C: 852 Example response: 854 S: 855 S: 856 S: 857 S: 858 S: Command completed successfully 859 S: 860 S: 861 S: 863 S: example.com 864 S: 1999-04-03T22:00:00.0Z 865 S: 2001-04-03T22:00:00.0Z 866 S: 867 S: 868 S: 869 S: 870 S: USD 871 S: 5.00 876 S: -5.00 877 S: 1000.00 878 S: 879 S: 880 S: 881 S: ABC-12345 882 S: 54321-XYZ 883 S: 884 S: 885 S: 887 5.2.2. EPP Command 889 This extension does not add any elements to the EPP command, 890 but does include elements in the response, when the extension is 891 included in the command service extensions. 893 When the command has been processed successfully, and the 894 client included the extension in the command service 895 extensions, the server MAY include in the section of the 896 EPP response a element, which contains the following 897 child elements: 899 o A element (as described in Section 3.2); 900 o Zero or more elements (as described in Section 3.4); 901 o Zero or more elements (as described in Section 3.4); 902 o An OPTIONAL element (as described in Section 3.5); 903 o An OPTIONAL element (as described in 904 Section 3.6). 906 Example response: 908 S: 909 S: 910 S: 911 S: 912 S: Command completed successfully 913 S: 914 S: 915 S: 917 S: USD 918 S: -5.00 921 S: 1005.00 922 S: 923 S: 924 S: 925 S: ABC-12345 926 S: 54321-XYZ 927 S: 928 S: 929 S: 931 5.2.3. EPP Command 933 This extension adds elements to both the EPP command and 934 response, when the extension is included in the command 935 service extensions. 937 When submitting a command to the server, the client MAY 938 include in the element a element which 939 includes the following child elements: 941 o An OPTIONAL element (as described in Section 3.2); 942 o One or more elements (as described in Section 3.4). 944 When the command has been processed successfully, and the 945 client included the extension in the command service 946 extensions, the server MAY include in the section of the 947 EPP response a element, which contains the following 948 child elements: 950 o A element (as described in Section 3.2); 951 o Zero or more elements (as described in Section 3.4); 952 o Zero or more elements (as described in Section 3.4); 953 o An OPTIONAL element (as described in Section 3.5); 954 o An OPTIONAL element (as described in 955 Section 3.6). 957 Example command: 959 C: 960 C: 961 C: 962 C: 963 C: 965 C: example.com 966 C: 2000-04-03 967 C: 5 968 C: 969 C: 970 C: 971 C: 972 C: USD 973 C: 5.00 974 C: 975 C: 976 C: ABC-12345 977 C: 978 C: 979 Example response: 981 S: 982 S: 983 S: 984 S: 985 S: Command completed successfully 986 S: 987 S: 988 S: 990 S: example.com 991 S: 2005-04-03T22:00:00.0Z 992 S: 993 S: 994 S: 995 S: 996 S: USD 997 S: 5.00 1000 S: 1000.00 1001 S: 1002 S: 1003 S: 1004 S: ABC-12345 1005 S: 54322-XYZ 1006 S: 1007 S: 1008 S: 1010 5.2.4. EPP Command 1012 This extension adds elements to both the EPP command and 1013 response, when the value of the "op" attribute of the 1014 command element is "request", and the extension is included in the 1015 command service extensions. 1017 When submitting a command to the server, the client MAY 1018 include in the element a element which 1019 includes the following child elements: 1021 o An OPTIONAL element (as described in Section 3.2); 1022 o One or more elements (as described in Section 3.4). 1024 When the command has been processed successfully, and the 1025 client included the extension in the command service 1026 extensions, the server MAY include in the section of the 1027 EPP response a element, which contains the following 1028 child elements: 1030 o A element (as described in Section 3.2); 1031 o Zero or more elements (as described in Section 3.4); 1032 o Zero or more elements (as described in Section 3.4); 1033 o An OPTIONAL element (as described in Section 3.5); 1034 o An OPTIONAL element (as described in 1035 Section 3.6). 1037 Example command: 1039 C: 1040 C: 1041 C: 1042 C: 1043 C: 1045 C: example.com 1046 C: 1 1047 C: 1048 C: 2fooBAR 1049 C: 1050 C: 1051 C: 1052 C: 1053 C: 1054 C: USD 1055 C: 5.00 1056 C: 1057 C: 1058 C: ABC-12345 1059 C: 1060 C: 1061 Example response: 1063 S: 1064 S: 1065 S: 1066 S: 1067 S: Command completed successfully; action pending 1068 S: 1069 S: 1070 S: 1072 S: example.com 1073 S: pending 1074 S: ClientX 1075 S: 2000-06-08T22:00:00.0Z 1076 S: ClientY 1077 S: 2000-06-13T22:00:00.0Z 1078 S: 2002-09-08T22:00:00.0Z 1079 S: 1080 S: 1081 S: 1082 S: 1083 S: USD 1084 S: 5.00 1087 S: 1088 S: 1089 S: 1090 S: ABC-12345 1091 S: 54322-XYZ 1092 S: 1093 S: 1094 S: 1096 5.2.5. EPP Command 1098 This extension adds elements to both the EPP command and 1099 response, when the extension is included in the command 1100 service extensions. 1102 When submitting a command to the server, the client MAY 1103 include in the element a element which 1104 includes the following child elements: 1106 o An OPTIONAL element (as described in Section 3.2); 1107 o One or more elements (as described in Section 3.4). 1109 When the command has been processed successfully, and the 1110 client included the extension in the command service 1111 extensions, the server MAY include in the section of the 1112 EPP response a element, which contains the following 1113 child elements: 1115 o A element (as described in Section 3.2); 1116 o Zero or more elements (as described in Section 3.4); 1117 o Zero or more elements (as described in Section 3.4); 1118 o An OPTIONAL element (as described in Section 3.5); 1119 o An OPTIONAL element (as described in 1120 Section 3.6). 1122 Example command: 1124 C: 1125 C: 1126 C: 1127 C: 1128 C: 1130 C: example.com 1131 C: 1132 C: sh8013 1133 C: 1134 C: 1135 C: 1136 C: 1137 C: 1138 C: USD 1139 C: 5.00 1140 C: 1141 C: 1142 C: ABC-12345 1143 C: 1144 C: 1145 Example response: 1147 S: 1148 S: 1149 S: 1150 S: 1151 S: Command completed successfully 1152 S: 1153 S: 1154 S: 1155 S: USD 1156 S: 5.00 1157 S: 1158 S: 1159 S: 1160 S: ABC-12345 1161 S: 54321-XYZ 1162 S: 1163 S: 1164 S: 1166 6. Formal Syntax 1168 One schema is presented here that is the EPP Fee Extension schema. 1170 The formal syntax presented here is a complete schema representation 1171 of the object mapping suitable for automated validation of EPP XML 1172 instances. The BEGIN and END tags are not part of the schema; they 1173 are used to note the beginning and ending of the schema for URI 1174 registration purposes. 1176 6.1. Fee Extension Schema 1178 The formal syntax presented here is a complete schema representation 1179 of the object mapping suitable for automated validation of EPP XML 1180 instances. The BEGIN and END tags are not part of the schema; they 1181 are used to note the beginning and ending of the schema for URI 1182 registration purposes. 1184 BEGIN 1185 1186 1192 1193 1195 1196 1197 Extensible Provisioning Protocol v1.0 Fee Extension 1198 1199 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1214 1215 1216 1217 1219 1221 1222 1224 1225 1226 1227 1229 1230 1231 1233 1234 1235 1236 1237 1239 1241 1243 1244 1245 1246 1247 1249 1250 1251 1252 1254 1255 1256 1257 1259 1261 1263 1264 1266 1267 1268 1269 1271 1273 1275 1277 1279 1281 1282 1284 1285 1286 1287 1288 1290 1292 1293 1294 1296 1297 1298 1299 1300 1301 1303 1304 1305 1306 1307 1309 1311 1313 1314 1315 1316 1317 1319 1320 1321 1322 1323 1324 1325 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1344 1345 1346 1347 1348 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1369 1370 1371 1372 1373 1374 1375 1376 1378 1379 1380 1382 1383 1384 1386 1387 END 1389 7. Security Considerations 1391 The mapping extensions described in this document do not provide any 1392 security services beyond those described by EPP [RFC5730], the EPP 1393 domain name mapping [RFC5731], and protocol layers used by EPP. The 1394 security considerations described in these other specifications apply 1395 to this specification as well. This extension passes financial 1396 information using the EPP protocol, so confidentiality and integrity 1397 protection must be provided by the transport mechanism. All 1398 transports compliant with [RFC5730] provide the needed level of 1399 confidentiality and integrity protections. 1401 8. IANA Considerations 1403 8.1. XML Namespace 1405 This document uses URNs to describe XML namespaces and XML schemas 1406 conforming to a registry mechanism described in [RFC3688]. 1408 Registration request for the fee namespace: 1410 URI: urn:ietf:params:xml:ns:epp:fee-1.0 1412 Registrant Contact: IESG 1414 XML: None. Namespace URIs do not represent an XML specification. 1416 Registration request for the fee schema: 1418 URI: urn:ietf:params:xml:schema:epp:fee-1.0 1420 Registrant Contact: IESG 1422 XML: See the "Formal Syntax" section of this document. 1424 8.2. EPP Extension Registry 1426 The EPP extension described in this document should be registered by 1427 the IANA in the EPP Extension Registry described in [RFC7451]. The 1428 details of the registration are as follows: 1430 Name of Extension: Registry Fee Extension for the Extensible 1431 Provisioning Protocol (EPP) 1433 Document status: Standards Track 1434 Reference: (insert reference to RFC version of this document) 1436 Registrant Name and Email Address: IESG, 1438 TLDs: Any 1440 IPR Disclosure: None 1442 Status: Active 1444 Notes: None 1446 9. Implementation Status 1448 Note to RFC Editor: Please remove this section and the reference to 1449 [RFC7942] before publication. 1451 This section records the status of known implementations of the 1452 protocol defined by this specification at the time of posting of this 1453 Internet-Draft, and is based on a proposal described in [RFC7942]. 1454 The description of implementations in this section is intended to 1455 assist the IETF in its decision processes in progressing drafts to 1456 RFCs. Please note that the listing of any individual implementation 1457 here does not imply endorsement by the IETF. Furthermore, no effort 1458 has been spent to verify the information presented here that was 1459 supplied by IETF contributors. This is not intended as, and must not 1460 be construed to be, a catalog of available implementations or their 1461 features. Readers are advised to note that other implementations may 1462 exist. 1464 According to [RFC7942], "this will allow reviewers and working groups 1465 to assign due consideration to documents that have the benefit of 1466 running code, which may serve as evidence of valuable experimentation 1467 and feedback that have made the implemented protocols more mature. 1468 It is up to the individual working groups to use this information as 1469 they see fit". 1471 9.1. RegistryEngine EPP Service 1473 Organization: CentralNic 1475 Name: RegistryEngine EPP Service 1477 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 1478 SLDs 1479 Level of maturity: Deployed in CentralNic's production environment as 1480 well as two other gTLD registry systems, and two ccTLD registry 1481 systems. 1483 Coverage: All aspects of the protocol are implemented. 1485 Licensing: Proprietary In-House software 1487 Contact: epp@centralnic.com 1489 URL: https://www.centralnic.com 1491 10. Acknowledgements 1493 The authors wish to thank the following persons for their feedback 1494 and suggestions: 1496 o James Gould of Verisign Inc 1497 o Luis Munoz of ISC 1498 o Michael Young of Architelos 1499 o Ben Levac and Jeff Eckhaus of Demand Media 1500 o Seth Goldman of Google 1501 o Klaus Malorny and Michael Bauland of Knipp 1502 o Jody Kolker, Joe Snitker and Kevin Allendorf of Go Daddy 1503 o Michael Holloway of Com Laude 1504 o Santosh Kalsangrah of Impetus Infotech 1505 o Alex Mayrhofer of Nic.at 1506 o Thomas Corte of Knipp Medien und Kommunikation GmbH 1508 11. Change History 1510 11.1. Change from 17 to 18 1512 Corrected erroneous edit left in place in previous revision (17), 1513 reverted text back to original text (revision 16) in section 3.4. 1515 11.2. Change from 16 to 17 1517 Updated per AD review, all updates were just textual for clarity and 1518 correctness. 1520 11.3. Change from 15 to 16 1522 Updated per AD review and list comments: several grammar corrections; 1523 clarification text added to section 3.4.3 and 3.5; and a schema 1524 update for consistency by providing a "lang" attribute to the 1525 and "description" attribute detailed in 1526 section 3.4. 1528 11.4. Change from 14 to 15 1530 Updated schema, moving the "standard" attribute of the 1531 "commandDataType" inside the block. 1533 11.5. Change from 13 to 14 1535 Moved RFC 7451 reference from Normative to Informative section. 1537 11.6. Change from 12 to 13 1539 Updated XML namespace and schema registration to be "epp" scoped - 1540 global replace of XML namespace from urn:ietf:params:xml:ns:fee-1.0 1541 to urn:ietf:params:xml:ns:epp:fee-1.0 and the XML schema registration 1542 from urn:ietf:params:xml:schema:fee-1.0 to 1543 urn:ietf:params:xml:schema:epp:fee-1.0. 1545 11.7. Change from 11 to 12 1547 Updated references to current version of documents and moved the 1548 "standard" attribute from the check command (commandType) to the 1549 check response (commandDataType). 1551 11.8. Change from 10 to 11 1553 Updated document per Working Group Last Call comments. Made minor 1554 textual changes throughout for enhanced clarity per WGLC comments. 1556 11.9. Change from 09 to 10 1558 Updated document per Working Group Last Call comments. Updated 1559 schema to version 1.0 in anticipation of standardization, no changes 1560 were made to the latest, 0.25, schema. Made minor textual changes 1561 throughout for enhanced clarity per WGLC comments. 1563 11.10. Change from 08 to 09 1565 Updated scheme to version 0.25 to allow tighter checking on 1566 by splitting the client and server definitions, moved 1567 the class element from the command to the object level and added an 1568 optional standard attribute to the command element. Also updated 1569 section 3.1 for clarity on name attribute; updated section 3.9 for 1570 clarity on uses of ; removed second paragraph in section 1571 5.2.1 as it was duplicative of second to last paragraph in 4.0; and 1572 updated section 5.1.1 to add section references. 1574 11.11. Change from 07 to 08 1576 Updated section 3.8 and 5.1.1 to provide clarity on server processing 1577 and response of various scenarios (i.e. "quiet" period processing). 1579 11.12. Change from 06 to 07 1581 Updated section 3.8 and 4.0 to provide clarity on server processing 1582 and response of various scenarios. 1584 11.13. Change from 05 to 06 1586 Updated scheme to version 0.23 to allow the return of no 1587 element(s) if an error situation occurs. Edited 1588 section 3.8 extensively after input from interim meeting and REGEXT 1589 F2F meeting at IETF-99. Added normative reference for draft-ietf- 1590 eppext-launchphase. 1592 11.14. Change from 04 to 05 1594 Updated scheme to version 0.21 to support the lang attribute for the 1595 reason element of the objectCDType and the commandType types as well 1596 as to add the update command to the commandEnum type. Updated 1597 section 3.1 to include language for the custom command. Added 1598 section 3.9 to provide a description of the element. 1599 Fixed typos and added clarification text on when client fee is less 1600 than server fee in section 4. Additionally, I added description 1601 pointers to appropriate Section 3 definitions for element clarity 1602 throughout the document. 1604 11.15. Change from 03 to 04 1606 Updated scheme to version 0.19 to correct typos and to replace the 1607 commandTypeValue type with the commandEnum type and customName 1608 attribute for stricter validation. Updated various text for grammar 1609 and clarity. Added text to section 4 clarifying the response 1610 when the client provided no fee extension but the server was 1611 expecting the extension. 1613 11.16. Change from 02 to 03 1615 Updated scheme to version 0.17 to simplify the check command syntax. 1616 Moved fee avail to objectCDType to allow fast failing on error 1617 situations. Removed the objectCheckType as it was no longer being 1618 used. Updated examples to reflect these scheme changes. Added 1619 language for server failing a if the passed by the 1620 client is less than the server fee. 1622 11.17. Change from 01 to 02 1624 Updated scheme to version 0.15 to fix errors in CommandType, 1625 objectCDType, transformCommandType and transformResultType 1626 definitions. 1628 11.18. Change from 00 to 01 1630 Added Roger Carney as author to finish draft. Moved Formal Syntax 1631 section to main level numbering. Various grammar, typos, and 1632 administrative edits for clarity. Removed default value for the 1633 "applied" attribute of so that it can truly be optional. 1634 Added support for the command to return a element 1635 as well. Modified default response on the command for the 1636 optional when it was not provided in the command, 1637 leaving it to the server to provide the default period value. 1638 Extensive edits were done to the command, the 1639 response and to the fee extension schema (checkType, objectCheckType, 1640 objectIdentifierType, objectCDType, commandType) to support 1641 requesting and returning multiple transformation fees in a single 1642 call. Added section on Phase/Subphase to provide more context on the 1643 uses. 1645 11.19. Change from draft-brown-00 to draft-ietf-regext-fees-00 1647 Updated to be REGEXT WG document. 1649 12. References 1651 12.1. Normative References 1653 [ISO4217:2015] 1654 International Organization for Standardization, "Codes for 1655 the representation of currencies", August 2015, 1656 . 1658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1659 Requirement Levels", BCP 14, RFC 2119, 1660 DOI 10.17487/RFC2119, March 1997, 1661 . 1663 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1664 DOI 10.17487/RFC3688, January 2004, 1665 . 1667 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 1668 the Extensible Provisioning Protocol (EPP)", RFC 3915, 1669 DOI 10.17487/RFC3915, September 2004, 1670 . 1672 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1673 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1674 . 1676 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1677 Domain Name Mapping", STD 69, RFC 5731, 1678 DOI 10.17487/RFC5731, August 2009, 1679 . 1681 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1682 Code: The Implementation Status Section", BCP 205, 1683 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1684 . 1686 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1687 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1688 May 2017, . 1690 [RFC8334] Gould, J., Tan, W., and G. Brown, "Launch Phase Mapping 1691 for the Extensible Provisioning Protocol (EPP)", RFC 8334, 1692 DOI 10.17487/RFC8334, March 2018, 1693 . 1695 12.2. Informative References 1697 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1698 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1699 February 2015, . 1701 Authors' Addresses 1703 Roger Carney 1704 GoDaddy Inc. 1705 14455 N. Hayden Rd. #219 1706 Scottsdale, AZ 85260 1707 US 1709 Email: rcarney@godaddy.com 1710 URI: http://www.godaddy.com 1711 Gavin Brown 1712 CentralNic Group plc 1713 35-39 Moorgate 1714 London, England EC2R 6AR 1715 GB 1717 Phone: +44 20 33 88 0600 1718 Email: gavin.brown@centralnic.com 1719 URI: http://www.centralnic.com 1721 Jothan Frakes 1723 Email: jothan@jothan.com 1724 URI: http://jothan.com