idnits 2.17.1 draft-ietf-regext-epp-fees-15.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 (November 4, 2018) is 2000 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: May 8, 2019 CentralNic Group plc 6 J. Frakes 7 November 4, 2018 9 Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 10 draft-ietf-regext-epp-fees-15 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 https://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 May 8, 2019. 34 Copyright Notice 36 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . 11 69 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 11 70 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 11 71 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 11 72 5.1.2. EPP Transfer Query Command . . . . . . . . . . . . . 16 73 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 17 74 5.2.1. EPP Command . . . . . . . . . . . . . . . . 17 75 5.2.2. EPP Command . . . . . . . . . . . . . . . . 19 76 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 20 77 5.2.4. EPP Command . . . . . . . . . . . . . . . 22 78 5.2.5. EPP Command . . . . . . . . . . . . . . . . 24 79 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 80 6.1. Fee Extension Schema . . . . . . . . . . . . . . . . . . 26 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 83 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 31 84 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 32 85 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 32 86 9.1. RegistryEngine EPP Service . . . . . . . . . . . . . . . 33 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 88 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 34 89 11.1. Change from 14 to 15 . . . . . . . . . . . . . . . . . . 34 90 11.2. Change from 13 to 14 . . . . . . . . . . . . . . . . . . 34 91 11.3. Change from 12 to 13 . . . . . . . . . . . . . . . . . . 34 92 11.4. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 34 93 11.5. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 34 94 11.6. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 34 95 11.7. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 34 96 11.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 35 97 11.9. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 35 98 11.10. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 35 99 11.11. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 35 100 11.12. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 35 101 11.13. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 35 102 11.14. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 36 103 11.15. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 36 104 11.16. Change from draft-brown-00 to draft-ietf-regext-fees-00 36 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 106 12.1. Normative References . . . . . . . . . . . . . . . . . . 36 107 12.2. Informative References . . . . . . . . . . . . . . . . . 37 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 110 1. Introduction 112 Historically, domain name registries have applied a simple fee 113 structure for billable transactions, namely a basic unit price 114 applied to domain , , and RGP [RFC3915] 115 restore commands. Given the relatively small number of EPP servers 116 to which EPP clients have been required to connect, it has generally 117 been the case that client operators have been able to obtain details 118 of these fees out-of-band by contacting the server operators. 120 Given the recent expansion of the DNS namespace, and the 121 proliferation of novel business models, it is now desirable to 122 provide a method for EPP clients to query EPP servers for the fees 123 and credits associated with certain commands and specific objects. 125 This document describes an extension mapping for version 1.0 of the 126 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 127 provides a mechanism by which EPP clients may query the fees and 128 credits associated with various billable transactions, and obtain 129 their current account balance. 131 1.1. Conventions Used in This Document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 XML is case sensitive. Unless stated otherwise, XML specifications 140 and examples provided in this document MUST be interpreted in the 141 character case presented in order to develop a conforming 142 implementation. 144 "fee" is used as an abbreviation for "urn:ietf:params:xml:ns:epp:fee- 145 1.0". The XML namespace prefix "fee" is used, but implementations 146 MUST NOT depend on it and instead employ a proper namespace-aware XML 147 parser and serializer to interpret and output the XML documents. 149 In examples, "C:" represents lines sent by a protocol client and "S:" 150 represents lines returned by a protocol server. Indentation and 151 white space in examples are provided only to illustrate element 152 relationships and are not a REQUIRED feature of this protocol. 154 2. Migrating to Newer Versions of This Extension 156 (Note to RFC Editor: remove this section before publication as an 157 RFC.) 159 Servers which implement this extension SHOULD provide a way for 160 clients to progressively update their implementations when a new 161 version of the extension is deployed. 163 Servers SHOULD (for a temporary migration period) provide support for 164 older versions of the extension in parallel to the newest version, 165 and allow clients to select their preferred version via the 166 element of the command. 168 If a client requests multiple versions of the extension at login, 169 then, when preparing responses to commands which do not include 170 extension elements, the server SHOULD only include extension elements 171 in the namespace of the newest version of the extension requested by 172 the client. 174 When preparing responses to commands which do include extension 175 elements, the server SHOULD only include extension elements for the 176 extension versions present in the command. 178 3. Extension Elements 180 3.1. Client Commands 182 The element is used in the EPP command to 183 determine the fee which is applicable to the given command. 185 The use of the keys off the use of the "name" attribute 186 to define which transform fees the client is requesting information 187 about. Here is the list of possible values for the "name" attribute: 189 o "create" indicating a command as defined in [RFC5730]; 190 o "delete" indicating a command as defined in [RFC5730]; 191 o "renew" indicating a command as defined in [RFC5730]; 192 o "update" indicating a command as defined in [RFC5730]; 193 o "transfer" indicating a command as defined in 194 [RFC5730]; 195 o If the server supports the Registry Grace Period Mapping 196 [RFC3915], then the server MUST also support the "restore" value 197 as defined in [RFC3915]; 198 o "custom" indicating a custom command that uses the "customName" 199 attribute to define the custom operation. 201 The element MAY have an OPTIONAL "phase" attribute 202 specifying a launch phase as described in [RFC8334]. It may also 203 contain an OPTIONAL "subphase" attribute identifying the custom or 204 sub-phase as described in [RFC8334]. 206 3.2. Currency Codes 208 The element is used to indicate which currency fees 209 are charged in. This value of this element MUST be a three-character 210 currency code from [ISO4217]. 212 Note that ISO 4217 provides the special "XXX" code, which MAY be used 213 if the server uses a non-currency based system for assessing fees, 214 such as a system of credits. 216 The use of elements in client commands is OPTIONAL: if 217 a element is not present in a command, the server MUST 218 determine the currency based on the server default currency or based 219 on the client's account settings which are agreed to by the client 220 and server via an out-of-band channel. However, the 221 element MUST be present in responses. 223 Servers SHOULD NOT perform a currency conversion if a client uses an 224 incorrect currency code. Servers SHOULD return a 2004 "Parameter 225 value range" error instead. 227 3.3. Validity Periods 229 When querying for fee information using the command, the 230 element is used to indicate the units to be added to the 231 registration period of objects by the , and 232 commands. This element is derived from the 233 element described in [RFC5731]. 235 The element is OPTIONAL in commands, if omitted, 236 the server MUST determine the fee(s) using the server default period. 237 The element MUST be present in responses. 239 3.4. Fees and Credits 241 Servers which implement this extension will include elements in 242 responses which provide information about the fees and/or credits 243 associated with a given billable transaction. 245 The and elements are used to provide this 246 information. The presence of a element in a response 247 indicates a debit against the client's account balance; a 248 element indicates a credit. A element MUST 249 have a non-negative value. A element MUST have a 250 negative value. 252 A server MAY respond with multiple and 253 elements in the same response. In such cases, the net fee or credit 254 applicable to the transaction is the arithmetic sum of the values of 255 each of the and/or elements. This amount 256 applies to the total additional validity period applied to the object 257 (where applicable) rather than to any incremental unit. 259 The following attributes are defined for the element. 260 These are described in detail below: 262 description: an OPTIONAL attribute which provides a human-readable 263 description of the fee. Servers should provide documentation on the 264 possible values of this attribute, and their meanings. 266 refundable: an OPTIONAL boolean attribute indicating whether the fee 267 is refundable if the object is deleted. 269 grace-period: an OPTIONAL attribute which provides the time period 270 during which the fee is refundable. 272 applied: an OPTIONAL attribute indicating when the fee will be 273 deducted from the client's account. 275 The element can take a "description" attribute as 276 described above. No other attributes are defined for this element. 278 3.4.1. Refunds 280 elements MAY have an OPTIONAL "refundable" attribute which 281 takes a boolean value. Fees may be refunded under certain 282 circumstances, such as when a domain application is rejected (as 283 described in [RFC8334]) or when an object is deleted during the 284 relevant Grace Period (see below). 286 If the "refundable" attribute is omitted, then clients SHOULD NOT 287 make any assumption about the refundability of the fee. 289 3.4.2. Grace Periods 291 [RFC3915] describes a system of "grace periods", which are time 292 periods following a billable transaction during which, if an object 293 is deleted, the client receives a refund. 295 The "grace-period" attribute MAY be used to indicate the relevant 296 grace period for a fee. If a server implements the Registry Grace 297 Period extension [RFC3915], it MUST specify the grace period for all 298 relevant transactions. 300 If the "grace-period" attribute is omitted, then clients SHOULD NOT 301 make any assumption about the grace period of the fee. 303 3.4.3. Correlation between Refundability and Grace Periods 305 If a element has a "grace-period" attribute then it MUST 306 also be refundable. If the "refundable" attribute of a 307 element is false then it MUST NOT have a "grace-period" attribute. 309 3.4.4. Applicability 311 Fees may be applied immediately upon receipt of a command from a 312 client, or may only be applied once an out-of-band process (such as 313 the processing of applications at the end of a launch phase) has 314 taken place. 316 The "applied" attribute of the element allows servers to 317 indicate whether a fee will be applied immediately, or whether it 318 will be applied at some point in the future. This attribute takes 319 two possible values: "immediate" or "delayed". 321 3.5. Account Balance 323 The element is an OPTIONAL element which MAY be 324 included in server responses to transform commands. If present, it 325 can be used by the client to determine the remaining credit at the 326 server. 328 Whether or not the is included in responses is a matter 329 of server policy. However, if a server chooses to offer support for 330 this element, it MUST be included in responses to all "transform" or 331 billable commands (e.g. , , , , 332 ). 334 The value of the MAY be negative. A negative balance 335 indicates that the server has extended a line of credit to the client 336 (see below). 338 If a server includes a element in response to transform 339 commands, the value of the element MUST reflect the client's account 340 balance after any fees or credits associated with that command have 341 been applied. 343 3.6. Credit Limit 345 As described above, if a server returns a response containing a 346 with a negative value, then the server has extended a 347 line of credit to the client. A server MAY also include a 348 element in responses which indicates the maximum 349 credit available to a client. A server MAY reject certain 350 transactions if the absolute value of the is equal to 351 or exceeds the value of the element. 353 Whether or not the is included in responses is a 354 matter of server policy. However, if a server chooses to offer 355 support for this element, it MUST be included in responses to all 356 "transform" commands (e.g. , , , , 357 ). 359 3.7. Classification of Objects 361 Objects may be assigned to a particular class, category, or tier, 362 each of which has a particular fee or set of fees associated with it. 363 The element, which MAY appear in and transform 364 responses, is used to indicate the classification of an object. 366 If a server makes use of this element, it should provide clients with 367 a list of all the values that the element may take via an out-of-band 368 channel. Servers MUST NOT use values which do not appear on this 369 list. 371 Servers which make use of this element MUST use a element 372 with the value "standard" for all objects that are subject to the 373 standard or default fee. 375 3.8. Phase and Subphase Attributes 377 The element has two attributes, phase and subphase, 378 that provide additional information related to a specific launch 379 phase as described in [RFC8334]. These attributes are used as 380 filters that should refine the server processing. 382 If the client contains a server supported combination 383 of phase/subphase the server MUST return fee data (including the 384 phase/subphase attribute(s)) for the specific combination. 386 If the client contains no phase/subphase attributes and 387 the server has only one active phase/subphase combination the server 388 MUST return data (including the phase/subphase attribute(s)) of the 389 currently active phase/subphase. 391 If the client contains no phase/subphase attributes and 392 the server has more than one active phase/subphase combination the 393 server MUST respond with a 2003 "Required parameter missing" error. 395 If the client contains no phase/subphase attributes and 396 the server is currently in a "quiet period" (e.g. not accepting 397 registrations or applications) the server MUST return data consistent 398 with the default general availability phase (e.g. "open" or "claims") 399 including the appropriate phase/subphase attribute(s). 401 If the client contains a phase attribute with no 402 subphase and the server has only one active subphase (or no subphase) 403 of this phase, the server MUST return data (including the phase/ 404 subphase attribute(s)) of the provided phase and currently active 405 subphase. 407 If the client contains a phase attribute with no 408 subphase and the server has more than one active subphase combination 409 of this phase, the server MUST respond with a 2003 "Required 410 parameter missing" error. 412 If the client contains a subphase with no phase 413 attribute the server MUST respond with a 2003 "Required parameter 414 missing" error. 416 If the client contains a phase attribute not defined in 417 [RFC8334] or not supported by server the server MUST respond with a 418 2004 "Parameter value range" error. 420 If the client contains a subphase attribute (or phase/ 421 subphase combination) not supported by server the server MUST respond 422 with a 2004 "Parameter value range" error. 424 3.9. Reason 426 The element is used to provide server specific text in 427 an effort to better explain why a command did not complete as 428 the client expected. An OPTIONAL "lang" attribute MAY be present to 429 identify the language of the returned text and has a default value of 430 "en" (English). 432 The element can be used within the server response 433 element or within the element. 435 If the server cannot calculate the relevant fees, because the object, 436 command, currency, period, class or some combination is invalid per 437 server policy, the server has two ways of handling error processing 438 of element(s): 440 1. Fast-fail - The server, upon error identification, MAY stop 441 processing elements and return to the client a 442 containing the and a element 443 detailing the reason for failure. 445 S: 446 S: example.xyz 447 S: Only 1 year registration periods are 448 S: valid. 449 S: 451 2. Partial-fail - The server, upon error identification, MAY 452 continue processing elements and return to the 453 client a containing successfully processed 454 elements and failed elements. All returned failed 455 elements MUST have a element detailing 456 the reason for failure, and the server MAY additionally include a 457 element at the level. 459 S: 460 S: example.xyz 461 S: 462 S: 2 463 S: Only 1 year registration periods are 464 S: valid. 465 S: 466 S: 468 In either failure scenario the server MUST set the avail 469 attribute to false (0) and the server MUST process all objects in the 470 client request. 472 4. Server Handling of Fee Information 474 Depending on server policy, a client MAY be required to include the 475 extension elements described in this document for certain transform 476 commands. Servers must provide clear documentation to clients about 477 the circumstances in which this extension must be used. 479 The server MUST return avail="0" in its response to a command 480 for any object in the command that does not include the 481 extension for which the server would likewise fail a 482 domain command when no extension is provided for that 483 same object. 485 If a server receives a command from a client, which results 486 in no possible fee combination but where a fee is required, the 487 server MUST set the "avail" attribute of the element to 488 false and provide a . 490 If a server receives a command from a client, which results 491 in an ambiguous result (i.e. multiple possible fee combinations) the 492 server MUST reject the command with a 2003 "Required parameter 493 missing" error. 495 If a server receives a command from a client, which does not include 496 the fee extension data elements required by the server for that 497 command, then the server MUST respond with a 2003 "Required parameter 498 missing" error. 500 If the currency or total fee provided by the client is less than the 501 server's own calculation of the fee for that command, then the server 502 MUST reject the command with a 2004 "Parameter value range" error. 504 5. EPP Command Mapping 506 A detailed description of the EPP syntax and semantics can be found 507 in [RFC5730]. 509 5.1. EPP Query Commands 511 This extension does not add any elements to the EPP or 512 commands or responses. 514 5.1.1. EPP Command 516 This extension defines a new command called the Fee Check Command 517 that defines additional elements for the EPP command to 518 provide fee information along with the availability information of 519 the EPP command. 521 The command MAY contain an element which MAY contain a 522 element. The element MAY contain one 523 element and MUST contain one or more 524 elements. 526 The element(s) contain(s) a "name" attribute (see 527 Section 3.1), an OPTIONAL "phase" attribute, and an OPTIONAL 528 "subphase" attribute (see Section 3.8). The element(s) 529 MAY have the following child elements: 531 o An OPTIONAL element (as described in Section 3.3). 533 Example command: 535 C: 536 C: 537 C: 538 C: 539 C: 541 C: example.com 542 C: example.net 543 C: example.xyz 544 C: 545 C: 546 C: 547 C: 548 C: USD 549 C: 550 C: 2 551 C: 552 C: 553 C: 554 C: 555 C: 556 C: 557 C: ABC-12345 558 C: 559 C: 561 When the server receives a command that includes the 562 extension elements described above, its response MUST contain an 563 element, which MUST contain a child 564 element. The element MUST contain a 565 element and a for each element referenced in the client 566 command. 568 Each element MUST contain the following child elements: 570 o A element, which MUST match an element referenced in 571 the client command. 572 o An OPTIONAL element (as described in Section 3.7). 573 o A element matching each (unless the 574 "avail" attribute of the if false) that appeared in the 575 corresponding of the client command. This element MAY 576 have the OPTIONAL "standard" attribute, with a default value of 577 "0" (or "false"), which indicates whether the fee matches the fee 578 of the "standard" classification (see section 3.7). This element 579 MAY have the OPTIONAL "phase" and "subphase" attributes, which 580 SHOULD match the same attributes in the corresponding 581 element of the client command if sent by the client. 583 The element also has an OPTIONAL "avail" attribute which is 584 a boolean. If the value of this attribute evaluates to false, this 585 indicates that the server cannot calculate the relevant fees, because 586 the object, command, currency, period, class or some combination is 587 invalid per server policy. If "avail" is false then the or 588 the element MUST contain a element (as 589 described in Section 3.9) and the server MAY eliminate some or all of 590 the element(s). 592 The element(s) MAY have the following child elements: 594 o An OPTIONAL element (as described in Section 3.3), 595 which contains the same unit that appeared in the 596 element of the command. If the value of the preceding 597 element is "restore", this element MUST NOT be 598 included, otherwise it MUST be included. If no 599 appeared in the client command (and the command is not "restore") 600 then the server MUST return its default period value. 601 o Zero or more elements (as described in Section 3.4). 602 o Zero or more elements (as described in Section 3.4). 603 o An OPTIONAL element (as described in Section 3.9). 605 If the "avail" attribute of the element is true and if no 606 elements are present in a element, this 607 indicates that no fee will be assessed by the server for this 608 command. 610 If the "avail" attribute is true, then the element MUST 611 NOT contain a element. 613 Example response: 615 S: 616 S: 617 S: 618 S: 619 S: Command completed successfully 620 S: 621 S: 622 S: 624 S: 625 S: example.com 626 S: 627 S: 628 S: example.net 629 S: 630 S: 631 S: example.xyz 632 S: 633 S: 634 S: 635 S: 636 S: 638 S: USD 639 S: 640 S: example.com 641 S: Premium 642 S: 643 S: 2 644 S: 10.00 648 S: 649 S: 650 S: 1 651 S: 10.00 655 S: 656 S: 657 S: 1 658 S: 10.00 662 S: 663 S: 664 S: 15.00 666 S: 667 S: 668 S: 669 S: example.net 670 S: standard 671 S: 672 S: 2 673 S: 5.00 677 S: 678 S: 679 S: 1 680 S: 5.00 684 S: 685 S: 686 S: 1 687 S: 5.00 691 S: 692 S: 693 S: 5.00 695 S: 696 S: 697 S: 698 S: example.xyz 699 S: 700 S: 2 701 S: Only 1 year registration periods are 702 S: valid. 703 S: 704 S: 705 S: 706 S: 707 S: 708 S: ABC-12345 709 S: 54322-XYZ 710 S: 711 S: 712 S: 714 5.1.2. EPP Transfer Query Command 716 This extension does not add any elements to the EPP query 717 command, but does include elements in the response, when the 718 extension is included in the command service extensions. 720 When the query command has been processed successfully, if 721 the client has included the extension in the command service 722 element, and if the client is authorized by the server 723 to view information about the transfer, then the server MAY include 724 in the section of the EPP response a 725 element, which contains the following child elements: 727 o A element (as described in Section 3.2). 728 o A element (as described in Section 3.3). 729 o Zero or more elements (as described in Section 3.4) 730 containing the fees that will be charged to the gaining client. 731 o Zero or more elements (as described in Section 3.4) 732 containing the credits that will be refunded to the losing client. 734 Servers SHOULD omit when returning a response to the 735 gaining client, and omit elements when returning a response 736 to the losing client. 738 If no element is included in the response, then no fee 739 will be assessed by the server for the transfer. 741 Example query response: 743 S: 744 S: 745 S: 746 S: 747 S: Command completed successfully; action pending 748 S: 749 S: 750 S: 752 S: example.com 753 S: pending 754 S: ClientX 755 S: 2000-06-08T22:00:00.0Z 756 S: ClientY 757 S: 2000-06-13T22:00:00.0Z 758 S: 2002-09-08T22:00:00.0Z 759 S: 760 S: 761 S: 762 S: 763 S: USD 764 S: 1 765 S: 5.00 766 S: 767 S: 768 S: 769 S: ABC-12345 770 S: 54322-XYZ 771 S: 772 S: 773 S: 775 5.2. EPP Transform Commands 777 5.2.1. EPP Command 779 This extension adds elements to both the EPP command and 780 response, when the extension is included in the command 781 service extensions. 783 When submitting a command to the server, the client MAY 784 include in the element a element which 785 includes the following child elements: 787 o An OPTIONAL element (as described in Section 3.2); 788 o One or more elements (as described in Section 3.4). 790 The server MUST fail the command if the provided 791 by the client is less than the server fee. 793 When the command has been processed successfully, and the 794 client included the extension in the command service 795 extensions, and a fee was assessed by the server for the transaction, 796 the server MUST include in the section of the EPP 797 response a element, which contains the following child 798 elements: 800 o A element (as described in Section 3.2); 801 o Zero or more elements (as described in Section 3.4); 802 o Zero or more elements (as described in Section 3.4); 803 o An OPTIONAL element (as described in Section 3.5); 804 o An OPTIONAL element (as described in 805 Section 3.6). 807 Example command: 809 C: 810 C: 811 C: 812 C: 813 C: 815 C: example.com 816 C: 2 817 C: 818 C: ns1.example.net 819 C: ns2.example.net 820 C: 821 C: jd1234 822 C: sh8013 823 C: sh8013 824 C: 825 C: 2fooBAR 826 C: 827 C: 828 C: 829 C: 830 C: 831 C: USD 832 C: 5.00 833 C: 834 C: 835 C: ABC-12345 836 C: 837 C: 838 Example response: 840 S: 841 S: 842 S: 843 S: 844 S: Command completed successfully 845 S: 846 S: 847 S: 849 S: example.com 850 S: 1999-04-03T22:00:00.0Z 851 S: 2001-04-03T22:00:00.0Z 852 S: 853 S: 854 S: 855 S: 856 S: USD 857 S: 5.00 861 S: -5.00 862 S: 1000.00 863 S: 864 S: 865 S: 866 S: ABC-12345 867 S: 54321-XYZ 868 S: 869 S: 870 S: 872 5.2.2. EPP Command 874 This extension does not add any elements to the EPP command, 875 but does include elements in the response, when the extension is 876 included in the command service extensions. 878 When the command has been processed successfully, and the 879 client included the extension in the command service 880 extensions, the server MAY include in the section of the 881 EPP response a element, which contains the following 882 child elements: 884 o A element (as described in Section 3.2); 885 o Zero or more elements (as described in Section 3.4); 886 o Zero or more elements (as described in Section 3.4); 887 o An OPTIONAL element (as described in Section 3.5); 888 o An OPTIONAL element (as described in 889 Section 3.6). 891 Example response: 893 S: 894 S: 895 S: 896 S: 897 S: Command completed successfully 898 S: 899 S: 900 S: 902 S: USD 903 S: -5.00 904 S: 1005.00 905 S: 906 S: 907 S: 908 S: ABC-12345 909 S: 54321-XYZ 910 S: 911 S: 912 S: 914 5.2.3. EPP Command 916 This extension adds elements to both the EPP command and 917 response, when the extension is included in the command 918 service extensions. 920 When submitting a command to the server, the client MAY 921 include in the element a element which 922 includes the following child elements: 924 o An OPTIONAL element (as described in Section 3.2); 925 o One or more elements (as described in Section 3.4). 927 When the command has been processed successfully, and the 928 client included the extension in the command service 929 extensions, the server MAY include in the section of the 930 EPP response a element, which contains the following 931 child elements: 933 o A element (as described in Section 3.2); 934 o Zero or more elements (as described in Section 3.4); 935 o Zero or more elements (as described in Section 3.4); 936 o An OPTIONAL element (as described in Section 3.5); 937 o An OPTIONAL element (as described in 938 Section 3.6). 940 Example command: 942 C: 943 C: 944 C: 945 C: 946 C: 948 C: example.com 949 C: 2000-04-03 950 C: 5 951 C: 952 C: 953 C: 954 C: 955 C: USD 956 C: 5.00 957 C: 958 C: 959 C: ABC-12345 960 C: 961 C: 962 Example response: 964 S: 965 S: 966 S: 967 S: 968 S: Command completed successfully 969 S: 970 S: 971 S: 973 S: example.com 974 S: 2005-04-03T22:00:00.0Z 975 S: 976 S: 977 S: 978 S: 979 S: USD 980 S: 5.00 983 S: 1000.00 984 S: 985 S: 986 S: 987 S: ABC-12345 988 S: 54322-XYZ 989 S: 990 S: 991 S: 993 5.2.4. EPP Command 995 This extension adds elements to both the EPP command and 996 response, when the value of the "op" attribute of the 997 command element is "request", and the extension is included in the 998 command service extensions. 1000 When submitting a command to the server, the client MAY 1001 include in the element a element which 1002 includes the following child elements: 1004 o An OPTIONAL element (as described in Section 3.2); 1005 o One or more elements (as described in Section 3.4). 1007 When the command has been processed successfully, and the 1008 client included the extension in the command service 1009 extensions, the server MAY include in the section of the 1010 EPP response a element, which contains the following 1011 child elements: 1013 o A element (as described in Section 3.2); 1014 o Zero or more elements (as described in Section 3.4); 1015 o Zero or more elements (as described in Section 3.4); 1016 o An OPTIONAL element (as described in Section 3.5); 1017 o An OPTIONAL element (as described in 1018 Section 3.6). 1020 Example command: 1022 C: 1023 C: 1024 C: 1025 C: 1026 C: 1028 C: example.com 1029 C: 1 1030 C: 1031 C: 2fooBAR 1032 C: 1033 C: 1034 C: 1035 C: 1036 C: 1037 C: USD 1038 C: 5.00 1039 C: 1040 C: 1041 C: ABC-12345 1042 C: 1043 C: 1044 Example response: 1046 S: 1047 S: 1048 S: 1049 S: 1050 S: Command completed successfully; action pending 1051 S: 1052 S: 1053 S: 1055 S: example.com 1056 S: pending 1057 S: ClientX 1058 S: 2000-06-08T22:00:00.0Z 1059 S: ClientY 1060 S: 2000-06-13T22:00:00.0Z 1061 S: 2002-09-08T22:00:00.0Z 1062 S: 1063 S: 1064 S: 1065 S: 1066 S: USD 1067 S: 5.00 1070 S: 1071 S: 1072 S: 1073 S: ABC-12345 1074 S: 54322-XYZ 1075 S: 1076 S: 1077 S: 1079 5.2.5. EPP Command 1081 This extension adds elements to both the EPP command and 1082 response, when the extension is included in the command 1083 service extensions. 1085 When submitting a command to the server, the client MAY 1086 include in the element a element which 1087 includes the following child elements: 1089 o An OPTIONAL element (as described in Section 3.2); 1090 o One or more elements (as described in Section 3.4). 1092 When the command has been processed successfully, and the 1093 client included the extension in the command service 1094 extensions, the server MAY include in the section of the 1095 EPP response a element, which contains the following 1096 child elements: 1098 o A element (as described in Section 3.2); 1099 o Zero or more elements (as described in Section 3.4); 1100 o Zero or more elements (as described in Section 3.4); 1101 o An OPTIONAL element (as described in Section 3.5); 1102 o An OPTIONAL element (as described in 1103 Section 3.6). 1105 Example command: 1107 C: 1108 C: 1109 C: 1110 C: 1111 C: 1113 C: example.com 1114 C: 1115 C: sh8013 1116 C: 1117 C: 1118 C: 1119 C: 1120 C: 1121 C: USD 1122 C: 5.00 1123 C: 1124 C: 1125 C: ABC-12345 1126 C: 1127 C: 1128 Example response: 1130 S: 1131 S: 1132 S: 1133 S: 1134 S: Command completed successfully 1135 S: 1136 S: 1137 S: 1138 S: USD 1139 S: 5.00 1140 S: 1141 S: 1142 S: 1143 S: ABC-12345 1144 S: 54321-XYZ 1145 S: 1146 S: 1147 S: 1149 6. Formal Syntax 1151 One schema is presented here that is the EPP Fee Extension schema. 1153 The formal syntax presented here is a complete schema representation 1154 of the object mapping suitable for automated validation of EPP XML 1155 instances. The BEGIN and END tags are not part of the schema; they 1156 are used to note the beginning and ending of the schema for URI 1157 registration purposes. 1159 6.1. Fee Extension Schema 1161 Copyright (c) 2018 IETF Trust and the persons identified as authors 1162 of the code. All rights reserved. 1164 Redistribution and use in source and binary forms, with or without 1165 modification, are permitted provided that the following conditions 1166 are met: 1168 o Redistributions of source code must retain the above copyright 1169 notice, this list of conditions and the following disclaimer. 1170 o Redistributions in binary form must reproduce the above copyright 1171 notice, this list of conditions and the following disclaimer in 1172 the documentation and/or other materials provided with the 1173 distribution. 1174 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1175 names of specific contributors, may be used to endorse or promote 1176 products derived from this software without specific prior written 1177 permission. 1179 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1180 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1181 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1182 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1183 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1184 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1185 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1186 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1187 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1188 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1189 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1191 BEGIN 1192 1193 1200 1201 1203 1204 1205 Extensible Provisioning Protocol v1.0 Fee Extension 1206 1207 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1222 1223 1224 1225 1227 1229 1230 1232 1233 1234 1235 1237 1238 1239 1241 1242 1243 1244 1245 1247 1248 1250 1251 1252 1253 1254 1256 1257 1258 1259 1261 1262 1263 1264 1266 1268 1270 1271 1272 1273 1274 1275 1277 1279 1281 1283 1285 1287 1288 1290 1291 1292 1293 1294 1295 1297 1298 1299 1301 1302 1303 1304 1305 1306 1308 1309 1310 1311 1312 1314 1316 1318 1319 1321 1322 1323 1325 1326 1327 1328 1329 1330 1331 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1345 1346 1347 1348 1349 1351 1352 1353 1354 1355 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1370 1371 1372 1373 1374 1376 1377 1378 1379 1380 1381 1382 1384 1385 1386 1388 1389 1390 1392 1393 END 1395 7. Security Considerations 1397 The mapping extensions described in this document do not provide any 1398 security services beyond those described by EPP [RFC5730], the EPP 1399 domain name mapping [RFC5731], and protocol layers used by EPP. The 1400 security considerations described in these other specifications apply 1401 to this specification as well. 1403 8. IANA Considerations 1405 8.1. XML Namespace 1407 This document uses URNs to describe XML namespaces and XML schemas 1408 conforming to a registry mechanism described in [RFC3688]. 1410 Registration request for the fee namespace: 1412 URI: urn:ietf:params:xml:ns:epp:fee-1.0 1414 Registrant Contact: IESG 1416 XML: None. Namespace URIs do not represent an XML specification. 1418 Registration request for the fee schema: 1420 URI: urn:ietf:params:xml:schema:epp:fee-1.0 1422 Registrant Contact: IESG 1424 XML: See the "Formal Syntax" section of this document. 1426 8.2. EPP Extension Registry 1428 The EPP extension described in this document should be registered by 1429 the IANA in the EPP Extension Registry described in [RFC7451]. The 1430 details of the registration are as follows: 1432 Name of Extension: Registry Fee Extension for the Extensible 1433 Provisioning Protocol (EPP) 1435 Document status: Standards Track 1437 Reference: (insert reference to RFC version of this document) 1439 Registrant Name and Email Address: IESG, 1441 TLDs: Any 1443 IPR Disclosure: None 1445 Status: Active 1447 Notes: None 1449 9. Implementation Status 1451 Note to RFC Editor: Please remove this section and the reference to 1452 [RFC7942] before publication. 1454 This section records the status of known implementations of the 1455 protocol defined by this specification at the time of posting of this 1456 Internet-Draft, and is based on a proposal described in [RFC7942]. 1457 The description of implementations in this section is intended to 1458 assist the IETF in its decision processes in progressing drafts to 1459 RFCs. Please note that the listing of any individual implementation 1460 here does not imply endorsement by the IETF. Furthermore, no effort 1461 has been spent to verify the information presented here that was 1462 supplied by IETF contributors. This is not intended as, and must not 1463 be construed to be, a catalog of available implementations or their 1464 features. Readers are advised to note that other implementations may 1465 exist. 1467 According to [RFC7942], "this will allow reviewers and working groups 1468 to assign due consideration to documents that have the benefit of 1469 running code, which may serve as evidence of valuable experimentation 1470 and feedback that have made the implemented protocols more mature. 1471 It is up to the individual working groups to use this information as 1472 they see fit". 1474 9.1. RegistryEngine EPP Service 1476 Organization: CentralNic 1478 Name: RegistryEngine EPP Service 1480 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 1481 SLDs 1483 Level of maturity: Deployed in CentralNic's production environment as 1484 well as two other gTLD registry systems, and two ccTLD registry 1485 systems. 1487 Coverage: All aspects of the protocol are implemented. 1489 Licensing: Proprietary In-House software 1491 Contact: epp@centralnic.com 1493 URL: https://www.centralnic.com 1495 10. Acknowledgements 1497 The authors wish to thank the following persons for their feedback 1498 and suggestions: 1500 o James Gould of Verisign Inc 1501 o Luis Munoz of ISC 1502 o Michael Young of Architelos 1503 o Ben Levac and Jeff Eckhaus of Demand Media 1504 o Seth Goldman of Google 1505 o Klaus Malorny and Michael Bauland of Knipp 1506 o Jody Kolker, Joe Snitker and Kevin Allendorf of Go Daddy 1507 o Michael Holloway of Com Laude 1508 o Santosh Kalsangrah of Impetus Infotech 1509 o Alex Mayrhofer of Nic.at 1510 o Thomas Corte of Knipp Medien und Kommunikation GmbH 1512 11. Change History 1514 11.1. Change from 14 to 15 1516 Updated schema, moving the "standard" attribute of the 1517 "commandDataType" inside the block. 1519 11.2. Change from 13 to 14 1521 Moved RFC 7451 reference from Normative to Informative section. 1523 11.3. Change from 12 to 13 1525 Updated XML namespace and schema registration to be "epp" scoped - 1526 global replace of XML namespace from urn:ietf:params:xml:ns:fee-1.0 1527 to urn:ietf:params:xml:ns:epp:fee-1.0 and the XML schema registration 1528 from urn:ietf:params:xml:schema:fee-1.0 to 1529 urn:ietf:params:xml:schema:epp:fee-1.0. 1531 11.4. Change from 11 to 12 1533 Updated references to current version of documents and moved the 1534 "standard" attribute from the check command (commandType) to the 1535 check response (commandDataType). 1537 11.5. Change from 10 to 11 1539 Updated document per Working Group Last Call comments. Made minor 1540 textual changes throughout for enhanced clarity per WGLC comments. 1542 11.6. Change from 09 to 10 1544 Updated document per Working Group Last Call comments. Updated 1545 schema to version 1.0 in anticipation of standardization, no changes 1546 were made to the latest, 0.25, schema. Made minor textual changes 1547 throughout for enhanced clarity per WGLC comments. 1549 11.7. Change from 08 to 09 1551 Updated scheme to version 0.25 to allow tighter checking on 1552 by splitting the client and server definitions, moved 1553 the class element from the command to the object level and added an 1554 optional standard attribute to the command element. Also updated 1555 section 3.1 for clarity on name attribute; updated section 3.9 for 1556 clarity on uses of ; removed second paragraph in section 1557 5.2.1 as it was duplicative of second to last paragraph in 4.0; and 1558 updated section 5.1.1 to add section references. 1560 11.8. Change from 07 to 08 1562 Updated section 3.8 and 5.1.1 to provide clarity on server processing 1563 and response of various scenarios (i.e. "quiet" period processing). 1565 11.9. Change from 06 to 07 1567 Updated section 3.8 and 4.0 to provide clarity on server processing 1568 and response of various scenarios. 1570 11.10. Change from 05 to 06 1572 Updated scheme to version 0.23 to allow the return of no 1573 element(s) if an error situation occurs. Edited 1574 section 3.8 extensively after input from interim meeting and REGEXT 1575 F2F meeting at IETF-99. Added normative reference for draft-ietf- 1576 eppext-launchphase. 1578 11.11. Change from 04 to 05 1580 Updated scheme to version 0.21 to support the lang attribute for the 1581 reason element of the objectCDType and the commandType types as well 1582 as to add the update command to the commandEnum type. Updated 1583 section 3.1 to include language for the custom command. Added 1584 section 3.9 to provide a description of the element. 1585 Fixed typos and added clarification text on when client fee is less 1586 than server fee in section 4. Additionally, I added description 1587 pointers to appropriate Section 3 definitions for element clarity 1588 throughout the document. 1590 11.12. Change from 03 to 04 1592 Updated scheme to version 0.19 to correct typos and to replace the 1593 commandTypeValue type with the commandEnum type and customName 1594 attribute for stricter validation. Updated various text for grammar 1595 and clarity. Added text to section 4 clarifying the response 1596 when the client provided no fee extension but the server was 1597 expecting the extension. 1599 11.13. Change from 02 to 03 1601 Updated scheme to version 0.17 to simplify the check command syntax. 1602 Moved fee avail to objectCDType to allow fast failing on error 1603 situations. Removed the objectCheckType as it was no longer being 1604 used. Updated examples to reflect these scheme changes. Added 1605 language for server failing a if the passed by the 1606 client is less than the server fee. 1608 11.14. Change from 01 to 02 1610 Updated scheme to version 0.15 to fix errors in CommandType, 1611 objectCDType, transformCommandType and transformResultType 1612 definitions. 1614 11.15. Change from 00 to 01 1616 Added Roger Carney as author to finish draft. Moved Formal Syntax 1617 section to main level numbering. Various grammar, typos, and 1618 administrative edits for clarity. Removed default value for the 1619 "applied" attribute of so that it can truly be optional. 1620 Added support for the command to return a element 1621 as well. Modified default response on the command for the 1622 optional when it was not provided in the command, 1623 leaving it to the server to provide the default period value. 1624 Extensive edits were done to the command, the 1625 response and to the fee extension schema (checkType, objectCheckType, 1626 objectIdentifierType, objectCDType, commandType) to support 1627 requesting and returning multiple transformation fees in a single 1628 call. Added section on Phase/Subphase to provide more context on the 1629 uses. 1631 11.16. Change from draft-brown-00 to draft-ietf-regext-fees-00 1633 Updated to be REGEXT WG document. 1635 12. References 1637 12.1. Normative References 1639 [ISO4217] International Organization for Standardization, "Codes for 1640 the representation of currencies", August 2015, 1641 . 1643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1644 Requirement Levels", BCP 14, RFC 2119, 1645 DOI 10.17487/RFC2119, March 1997, 1646 . 1648 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1649 DOI 10.17487/RFC3688, January 2004, 1650 . 1652 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 1653 the Extensible Provisioning Protocol (EPP)", RFC 3915, 1654 DOI 10.17487/RFC3915, September 2004, 1655 . 1657 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1658 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1659 . 1661 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1662 Domain Name Mapping", STD 69, RFC 5731, 1663 DOI 10.17487/RFC5731, August 2009, 1664 . 1666 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1667 Code: The Implementation Status Section", BCP 205, 1668 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1669 . 1671 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1672 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1673 May 2017, . 1675 [RFC8334] Gould, J., Tan, W., and G. Brown, "Launch Phase Mapping 1676 for the Extensible Provisioning Protocol (EPP)", RFC 8334, 1677 DOI 10.17487/RFC8334, March 2018, 1678 . 1680 12.2. Informative References 1682 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1683 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1684 February 2015, . 1686 Authors' Addresses 1688 Roger Carney 1689 GoDaddy Inc. 1690 14455 N. Hayden Rd. #219 1691 Scottsdale, AZ 85260 1692 US 1694 Email: rcarney@godaddy.com 1695 URI: http://www.godaddy.com 1696 Gavin Brown 1697 CentralNic Group plc 1698 35-39 Moorgate 1699 London, England EC2R 6AR 1700 GB 1702 Phone: +44 20 33 88 0600 1703 Email: gavin.brown@centralnic.com 1704 URI: http://www.centralnic.com 1706 Jothan Frakes 1708 Email: jothan@jothan.com 1709 URI: http://jothan.com