idnits 2.17.1 draft-ietf-regext-epp-fees-09.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 (January 19, 2018) is 2279 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ISO4217' is mentioned on line 211, but not defined == Unused Reference: 'I-D.ietf-regext-launchphase' is defined on line 1575, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-regext-launchphase-05 ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions R. Carney 3 Internet-Draft GoDaddy Inc. 4 Intended status: Standards Track G. Brown 5 Expires: July 23, 2018 CentralNic Group plc 6 J. Frakes 7 January 19, 2018 9 Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 10 draft-ietf-regext-epp-fees-09 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 July 23, 2018. 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.1.1. Server Handling of Elements . . . . . . . . . . . 15 73 5.1.2. EPP Transfer Query Command . . . . . . . . . . . . . 16 74 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 17 75 5.2.1. EPP Command . . . . . . . . . . . . . . . . 17 76 5.2.2. EPP Command . . . . . . . . . . . . . . . . 19 77 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 20 78 5.2.4. EPP Command . . . . . . . . . . . . . . . 22 79 5.2.5. EPP Command . . . . . . . . . . . . . . . . 24 80 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 81 6.1. Fee Extension Schema . . . . . . . . . . . . . . . . . . 26 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 84 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 31 85 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 31 86 9. Implemntation Status . . . . . . . . . . . . . . . . . . . . 31 87 9.1. RegistryEngine EPP Service . . . . . . . . . . . . . . . 32 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 89 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 33 90 11.1. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 33 91 11.2. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 33 92 11.3. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 33 93 11.4. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 33 94 11.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 33 95 11.6. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 34 96 11.7. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 34 97 11.8. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 34 98 11.9. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 34 99 11.10. Change from draft-brown-00 to draft-ietf-regext-fees-00 35 100 12. Normative References . . . . . . . . . . . . . . . . . . . . 35 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 103 1. Introduction 105 Historically, domain name registries have applied a simple fee 106 structure for billable transactions, namely a basic unit price 107 applied to domain , , and RGP [RFC3915] 108 restore commands. Given the relatively small number of EPP servers 109 to which EPP clients have been required to connect, it has generally 110 been the case that client operators have been able to obtain details 111 of these fees out-of-band by contacting the server operators. 113 Given the recent expansion of the DNS namespace, and the 114 proliferation of novel business models, it is now desirable to 115 provide a method for EPP clients to query EPP servers for the fees 116 and credits associated with certain commands and specific objects. 118 This document describes an extension mapping for version 1.0 of the 119 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 120 provides a mechanism by which EPP clients may query the fees and 121 credits associated with various billable transactions, and obtain 122 their current account balance. 124 1.1. Conventions Used in This Document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 XML is case sensitive. Unless stated otherwise, XML specifications 131 and examples provided in this document MUST be interpreted in the 132 character case presented in order to develop a conforming 133 implementation. 135 "fee" is used as an abbreviation for "urn:ietf:params:xml:ns:fee- 136 0.25". The XML namespace prefix "fee" is used, but implementations 137 MUST NOT depend on it and instead employ a proper namespace-aware XML 138 parser and serializer to interpret and output the XML documents. 140 In examples, "C:" represents lines sent by a protocol client and "S:" 141 represents lines returned by a protocol server. Indentation and 142 white space in examples are provided only to illustrate element 143 relationships and are not a REQUIRED feature of this protocol. 145 (Note to RFC Editor: remove the following paragraph before 146 publication as an RFC.) 148 The XML namespace prefix above contains a version number, 149 specifically "0.25". This version number will increment with 150 successive versions of this document, and will reach 1.0 if and when 151 this document is published as an RFC. This permits clients to 152 distinguish which version of the extension a server has implemented. 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 [draft-ietf-eppext- 203 launchphase]. It may also contain an OPTIONAL "subphase" attribute 204 identifying the custom or sub-phase as described in [draft-ietf- 205 eppext-launchphase]. 207 3.2. Currency Codes 209 The element is used to indicate which currency fees 210 are charged in. This value of this element MUST be a three-character 211 currency code from [ISO4217]. 213 Note that ISO 4217 provides the special "XXX" code, which MAY be used 214 if the server uses a non-currency based system for assessing fees, 215 such as a system of credits. 217 The use of elements in client commands is OPTIONAL: if 218 a element is not present in a command, the server MUST 219 determine the currency based on the client's account settings which 220 MUST be agreed by the client and server via an out-of-band channel. 221 However, the 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 [draft-ietf-eppext-launchphase]) or when an object is 284 deleted during the 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, it MUST specify the grace period for all relevant 298 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 (ie , , , , 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 (ie , , , , 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 [draft-ietf-eppext-launchphase]. These 380 attributes are used as filters that should refine the server 381 processing. 383 If the client contains a server supported combination 384 of phase/subphase the server MUST return fee data (including the 385 phase/subphase attribute(s)) for the specific combination. 387 If the client contains no phase/subphase attributes and 388 the server has only one active phase/subphase combination the server 389 MUST return data (including the phase/subphase attribute(s)) of the 390 currently active phase/subphase. 392 If the client contains no phase/subphase attributes and 393 the server has more than one active phase/subphase combination the 394 server MUST respond with a 2003 "Required parameter missing" error. 396 If the client contains no phase/subphase attributes and 397 the server is currently in a "quiet period" (e.g. not accepting 398 registrations or applications)the server MUST return data consistent 399 with the default general availability phase (e.g. "open" or "claims") 400 including the appropriate phase/subphase attribute(s). 402 If the client contains a phase attribute with no 403 subphase and the server has only one active subphase (or no subphase) 404 of this phase, the server MUST return data (including the phase/ 405 subphase attribute(s)) of the provided phase and currently active 406 subphase. 408 If the client contains a phase attribute with no 409 subphase and the server has more than one active subphase combination 410 of this phase, the server MUST respond with a 2003 "Required 411 parameter missing" error. 413 If the client contains a subphase with no phase 414 attribute the server MUST respond with a 2003 "Required parameter 415 missing" error. 417 If the client contains a phase attribute not defined in 418 [draft-ietf-eppext-launchphase] or not supported by server the server 419 MUST respond with a 2004 "Parameter value range" error. 421 If the client contains a subphase attribute (or phase/ 422 subphase combination) not supported by server the server MUST respond 423 with a 2004 "Parameter value range" error. 425 3.9. Reason 427 The element is used to provide server specific text in 428 an effort to better explain why a command did not complete as 429 the client expected. An OPTIONAL "lang" attribute MAY be present to 430 identify the language of the returned text and has a default value of 431 "en" English. 433 The element can be used within the server response 434 element or within the element. 436 If the server cannot calculate the relevant fees, because the object, 437 command, currency, period, class or some combination is invalid per 438 server policy, the server has two ways of handling error processing 439 of element(s): 441 1. Fast-fail - The server, upon error identification, MAY stop 442 processing elements and return to the client a 443 containing the and a element 444 detailing the reason for failure. 446 S: 447 S: example.xyz 448 S: Only 1 year registration periods are 449 S: valid. 450 S: 452 2. Partial-fail - The server, upon error identification, MAY 453 continue processing elements and return to the 454 client a containing successfully processed 455 elements and failed elements. All returned failed 456 elements that MUST have a element 457 detailing the reason for failure, and the server MAY additionally 458 include a element at the level. 460 S: 461 S: example.xyz 462 S: 463 S: 2 464 S: Only 1 year registration periods are 465 S: valid. 466 S: 467 S: 469 In either failure scenario the server MUST set the avail 470 attribute to false (0) and the server MUST process all domain names 471 in the client request. 473 4. Server Handling of Fee Information 475 Depending on server policy, a client MAY be required to include the 476 extension elements described in this document for certain transform 477 commands. Servers must provide clear documentation to clients about 478 the circumstances in which this extension must be used. 480 The server MUST return avail="0" in its response to a command 481 for any domain name in the command that does not include the 482 extension for which the server would likewise fail a 483 domain command when no extension is provided for that 484 same domain name. 486 If a server receives a command from a client which results in 487 no possible fee combination but where a fee is required, the server 488 MUST set the "avail" attribute of the element to false and 489 provide a . 491 If a server receives a command from a client which results in 492 an ambiguous result (i.e. multiple possible fee combinations) the 493 server MUST reject the command with a 2003 "Required parameter 494 missing" error. 496 If a server receives a command from a client which does not include 497 the fee extension data elements required by the server for that 498 command, then the server MUST respond with a 2003 "Required parameter 499 missing" error. 501 If the currency or total fee provided by the client is less than the 502 server's own calculation of the fee for that command, then the server 503 MUST reject the command with a 2004 "Parameter value range" error. 505 5. EPP Command Mapping 507 A detailed description of the EPP syntax and semantics can be found 508 in [RFC5730]. 510 5.1. EPP Query Commands 512 This extension does not add any elements to the EPP or 513 commands or responses. 515 5.1.1. EPP Command 517 This extension defines a new command called the Fee Check Command 518 that defines additional elements for the EPP command to 519 provide fee information along with the availability information of 520 the EPP command. 522 The command MAY contain an element which MAY contain a 523 element. The element MAY contain one 524 element and MUST contain one or more 525 elements. 527 The element(s) contain(s) a "name" attribute (see 528 Section 3.1), an OPTIONAL "phase" attribute, and an OPTIONAL 529 "subphase" attribute (see Section 3.8). The element(s) 530 MAY have the following child elements: 532 o An OPTIONAL element (as described in Section 3.3). 534 Example command: 536 C: 537 C: 538 C: 539 C: 540 C: 542 C: example.com 543 C: example.net 544 C: example.xyz 545 C: 546 C: 547 C: 548 C: 549 C: USD 550 C: 551 C: 2 552 C: 553 C: 554 C: 555 C: 556 C: 557 C: 558 C: ABC-12345 559 C: 560 C: 562 When the server receives a command that includes the 563 extension elements described above, its response MUST contain an 564 element, which MUST contain a child 565 element. The element MUST contain a 566 element and a for each element referenced in the client 567 command. 569 Each element MUST contain the following child elements: 571 o A element, which MUST match an element referenced in 572 the client command. 573 o An OPTIONAL element (as described in Section 3.7). 574 o A element matching each (unless the 575 "avail" attribute of the if false) that appeared in the 576 corresponding of the client command. This element MAY 577 have the OPTIONAL "phase" and "subphase" attributes, which SHOULD 578 match the same attributes in the corresponding 579 element of the client command if sent by the client. 581 The element also has an OPTIONAL "avail" attribute which is 582 a boolean. If the value of this attribute evaluates to false, this 583 indicates that the server cannot calculate the relevant fees, because 584 the object, command, currency, period, class or some combination is 585 invalid per server policy. If "avail" is false then the or 586 the element MUST contain a element (as 587 described in Section 3.9) and the server MAY eliminate some or all of 588 the element(s). 590 The element(s) MAY have the following child elements: 592 o An OPTIONAL element (as described in Section 3.3), 593 which contains the same unit that appeared in the 594 element of the command. If the value of the preceding 595 element is "restore", this element MUST NOT be 596 included, otherwise it MUST be included. If no 597 appeared in the client command (and the command is not "restore") 598 then the server MUST return its default period value. 599 o Zero or more elements (as described in Section 3.4). 600 o Zero or more elements (as described in Section 3.4). 601 o An OPTIONAL element (as described in Section 3.9). 603 If the "avail" attribute of the element is true and if no 604 elements are present in a element, this 605 indicates that no fee will be assessed by the server for this 606 command. 608 If the "avail" attribute is true, then the element MUST 609 NOT contain a element. 611 Example response: 613 S: 614 S: 615 S: 616 S: 617 S: Command completed successfully 618 S: 619 S: 620 S: 622 S: 623 S: example.com 624 S: 625 S: 626 S: example.net 627 S: 628 S: 629 S: example.xyz 630 S: 631 S: 632 S: 633 S: 634 S: 636 S: USD 637 S: 638 S: example.com 639 S: 640 S: 2 641 S: 10.00 645 S: 646 S: 647 S: 1 648 S: 5.00 652 S: 653 S: 654 S: 1 655 S: 5.00 659 S: 660 S: 661 S: 5.00 663 S: 664 S: 665 S: 666 S: example.net 667 S: 668 S: 2 669 S: 10.00 673 S: 674 S: 675 S: 1 676 S: 5.00 680 S: 681 S: 682 S: 1 683 S: 5.00 687 S: 688 S: 689 S: 5.00 691 S: 692 S: 693 S: 694 S: example.xyz 695 S: 696 S: 2 697 S: Only 1 year registration periods are 698 S: valid. 699 S: 700 S: 701 S: 702 S: 703 S: 704 S: ABC-12345 705 S: 54322-XYZ 706 S: 707 S: 708 S: 710 5.1.1.1. Server Handling of Elements 712 Clients MAY include a in the element. There are 713 two ways in which servers may handle this element: 715 1. If the server supports the concept of tiers or classes of 716 objects, then the value of this element MUST be validated. If 717 incorrect for the specified object, the "avail" attribute of the 718 corresponding element MUST be false. 719 2. If the server supports different "types" of object registrations 720 (such as a "blocking" registration which does not resolve, or 721 where a registry provides a value-added service that requires an 722 opt-out to disable), then, as with the first model, the server 723 MUST validate the value of the element. If the value is 724 incorrect, the "avail" attribute of the corresponding 725 element MUST be false, and a element (as described 726 in Section 3.9) MUST be provided. 728 Server operators must provide clear documentation to client operators 729 which of the above models it supports. 731 5.1.2. EPP Transfer Query Command 733 This extension does not add any elements to the EPP query 734 command, but does include elements in the response, when the 735 extension has been selected during a command. 737 When the query command has been processed successfully, 738 the client selected the extension when it logged in, and the client 739 is authorized by the server to view information about the transfer, 740 the server MAY include in the section of the EPP response 741 a element, which contains the following child elements: 743 o A element (as described in Section 3.2). 744 o A element (as described in Section 3.3). 745 o Zero or more elements (as described in Section 3.4) 746 containing the fees that will be charged to the gaining client. 747 o Zero or more elements (as described in Section 3.4) 748 containing the credits that will be refunded to the losing client. 750 Servers SHOULD omit when returning a response to the 751 gaining client, and omit elements when returning a response 752 to the losing client. 754 If no element is included in the response, then no fee 755 will be assessed by the server for the transfer. 757 Example query response: 759 S: 760 S: 761 S: 762 S: 763 S: Command completed successfully; action pending 764 S: 765 S: 766 S: 768 S: example.com 769 S: pending 770 S: ClientX 771 S: 2000-06-08T22:00:00.0Z 772 S: ClientY 773 S: 2000-06-13T22:00:00.0Z 774 S: 2002-09-08T22:00:00.0Z 775 S: 776 S: 777 S: 778 S: 779 S: USD 780 S: 1 781 S: 5.00 782 S: 783 S: 784 S: 785 S: ABC-12345 786 S: 54322-XYZ 787 S: 788 S: 789 S: 791 5.2. EPP Transform Commands 793 5.2.1. EPP Command 795 This extension adds elements to both the EPP command and 796 response, when the extension has been selected during a 797 command. 799 When submitting a command to the server, the client MAY 800 include in the element a element which 801 includes the following child elements: 803 o An OPTIONAL element (as described in Section 3.2); 804 o One or more elements (as described in Section 3.4). 806 The server MUST fail the command if the provided 807 by the client is less than the server fee. 809 When the command has been processed successfully, and the 810 client selected the extension when it logged in, and a fee was 811 assessed by the server for the transaction, the server MUST include 812 in the section of the EPP response a 813 element, which contains the following child elements: 815 o A element (as described in Section 3.2); 816 o Zero or more elements (as described in Section 3.4); 817 o Zero or more elements (as described in Section 3.4); 818 o An OPTIONAL element (as described in Section 3.5); 819 o An OPTIONAL element (as described in 820 Section 3.6). 822 Example command: 824 C: 825 C: 826 C: 827 C: 828 C: 830 C: example.com 831 C: 2 832 C: 833 C: ns1.example.net 834 C: ns2.example.net 835 C: 836 C: jd1234 837 C: sh8013 838 C: sh8013 839 C: 840 C: 2fooBAR 841 C: 842 C: 843 C: 844 C: 845 C: 846 C: USD 847 C: 5.00 848 C: 849 C: 850 C: ABC-12345 851 C: 852 C: 853 Example response: 855 S: 856 S: 857 S: 858 S: 859 S: Command completed successfully 860 S: 861 S: 862 S: 864 S: example.com 865 S: 1999-04-03T22:00:00.0Z 866 S: 2001-04-03T22:00:00.0Z 867 S: 868 S: 869 S: 870 S: 871 S: USD 872 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 has 891 been selected during the command. 893 When the command has been processed successfully, and the 894 client selected the extension when it logged in, the server MAY 895 include in the section of the EPP response a 896 element, which contains the following child elements: 898 o A element (as described in Section 3.2); 899 o Zero or more elements (as described in Section 3.4); 900 o Zero or more elements (as described in Section 3.4); 901 o An OPTIONAL element (as described in Section 3.5); 902 o An OPTIONAL element (as described in 903 Section 3.6). 905 Example response: 907 S: 908 S: 909 S: 910 S: 911 S: Command completed successfully 912 S: 913 S: 914 S: 916 S: USD 917 S: -5.00 918 S: 1005.00 919 S: 920 S: 921 S: 922 S: ABC-12345 923 S: 54321-XYZ 924 S: 925 S: 926 S: 928 5.2.3. EPP Command 930 This extension adds elements to both the EPP command and 931 response, when the extension has been selected during a 932 command. 934 When submitting a command to the server, the client MAY 935 include in the element a element which 936 includes the following child elements: 938 o An OPTIONAL element (as described in Section 3.2); 939 o One or more elements (as described in Section 3.4). 941 When the command has been processed successfully, and the 942 client selected the extension when it logged in, the server MAY 943 include in the section of the EPP response a 944 element, which contains the following child elements: 946 o A element (as described in Section 3.2); 947 o Zero or more elements (as described in Section 3.4); 948 o Zero or more elements (as described in Section 3.4); 949 o An OPTIONAL element (as described in Section 3.5); 950 o An OPTIONAL element (as described in 951 Section 3.6). 953 Example command: 955 C: 956 C: 957 C: 958 C: 959 C: 961 C: example.com 962 C: 2000-04-03 963 C: 5 964 C: 965 C: 966 C: 967 C: 968 C: USD 969 C: 5.00 970 C: 971 C: 972 C: ABC-12345 973 C: 974 C: 975 Example response: 977 S: 978 S: 979 S: 980 S: 981 S: Command completed successfully 982 S: 983 S: 984 S: 986 S: example.com 987 S: 2005-04-03T22:00:00.0Z 988 S: 989 S: 990 S: 991 S: 992 S: USD 993 S: 5.00 996 S: 1000.00 997 S: 998 S: 999 S: 1000 S: ABC-12345 1001 S: 54322-XYZ 1002 S: 1003 S: 1004 S: 1006 5.2.4. EPP Command 1008 This extension adds elements to both the EPP command and 1009 response, when the value of the "op" attribute of the 1010 command element is "request", and the extension has been selected 1011 during the command. 1013 When submitting a command to the server, the client MAY 1014 include in the element a element which 1015 includes the following child elements: 1017 o An OPTIONAL element (as described in Section 3.2); 1018 o One or more elements (as described in Section 3.4). 1020 When the command has been processed successfully, and the 1021 client selected the extension when it logged in, the server MAY 1022 include in the section of the EPP response a 1023 element, which contains the following child elements: 1025 o A element (as described in Section 3.2); 1026 o Zero or more elements (as described in Section 3.4); 1027 o Zero or more elements (as described in Section 3.4); 1028 o An OPTIONAL element (as described in Section 3.5); 1029 o An OPTIONAL element (as described in 1030 Section 3.6). 1032 Example command: 1034 C: 1035 C: 1036 C: 1037 C: 1038 C: 1040 C: example.com 1041 C: 1 1042 C: 1043 C: 2fooBAR 1044 C: 1045 C: 1046 C: 1047 C: 1048 C: 1049 C: USD 1050 C: 5.00 1051 C: 1052 C: 1053 C: ABC-12345 1054 C: 1055 C: 1056 Example response: 1058 S: 1059 S: 1060 S: 1061 S: 1062 S: Command completed successfully; action pending 1063 S: 1064 S: 1065 S: 1067 S: example.com 1068 S: pending 1069 S: ClientX 1070 S: 2000-06-08T22:00:00.0Z 1071 S: ClientY 1072 S: 2000-06-13T22:00:00.0Z 1073 S: 2002-09-08T22:00:00.0Z 1074 S: 1075 S: 1076 S: 1077 S: 1078 S: USD 1079 S: 5.00 1082 S: 1083 S: 1084 S: 1085 S: ABC-12345 1086 S: 54322-XYZ 1087 S: 1088 S: 1089 S: 1091 5.2.5. EPP Command 1093 This extension adds elements to both the EPP command and 1094 response, when the extension has been selected during the 1095 command. 1097 When submitting a command to the server, the client MAY 1098 include in the element a element which 1099 includes the following child elements: 1101 o An OPTIONAL element (as described in Section 3.2); 1102 o One or more elements (as described in Section 3.4). 1104 When the command has been processed successfully, and the 1105 client selected the extension when it logged in, the server MAY 1106 include in the section of the EPP response a 1107 element, which contains the following child elements: 1109 o A element (as described in Section 3.2); 1110 o Zero or more elements (as described in Section 3.4); 1111 o Zero or more elements (as described in Section 3.4); 1112 o An OPTIONAL element (as described in Section 3.5); 1113 o An OPTIONAL element (as described in 1114 Section 3.6). 1116 Example command: 1118 C: 1119 C: 1120 C: 1121 C: 1122 C: 1124 C: example.com 1125 C: 1126 C: sh8013 1127 C: 1128 C: 1129 C: 1130 C: 1131 C: 1132 C: USD 1133 C: 5.00 1134 C: 1135 C: 1136 C: ABC-12345 1137 C: 1138 C: 1139 Example response: 1141 S: 1142 S: 1143 S: 1144 S: 1145 S: Command completed successfully 1146 S: 1147 S: 1148 S: 1149 S: USD 1150 S: 5.00 1151 S: 1152 S: 1153 S: 1154 S: ABC-12345 1155 S: 54321-XYZ 1156 S: 1157 S: 1158 S: 1160 6. Formal Syntax 1162 One schema is presented here that is the EPP Fee Extension schema. 1164 The formal syntax presented here is a complete schema representation 1165 of the object mapping suitable for automated validation of EPP XML 1166 instances. The BEGIN and END tags are not part of the schema; they 1167 are used to note the beginning and ending of the schema for URI 1168 registration purposes. 1170 6.1. Fee Extension Schema 1172 BEGIN 1173 1174 1181 1182 1184 1185 1186 Extensible Provisioning Protocol v1.0 Fee Extension 1188 1189 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1204 1205 1206 1207 1209 1211 1212 1214 1215 1216 1217 1219 1220 1221 1223 1224 1225 1226 1227 1229 1230 1232 1233 1234 1235 1236 1238 1239 1240 1241 1243 1244 1245 1246 1248 1250 1252 1253 1255 1256 1257 1258 1260 1262 1264 1266 1268 1270 1271 1273 1274 1275 1276 1277 1278 1280 1281 1282 1285 1286 1287 1288 1289 1290 1291 1293 1294 1295 1296 1297 1299 1301 1303 1304 1305 1306 1308 1309 1310 1311 1312 1313 1314 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1357 1358 1359 1360 1361 1362 1363 1365 1366 1367 1369 1370 1371 1373 1374 END 1376 7. Security Considerations 1378 The mapping extensions described in this document do not provide any 1379 security services beyond those described by EPP [RFC5730], the EPP 1380 domain name mapping [RFC5731], and protocol layers used by EPP. The 1381 security considerations described in these other specifications apply 1382 to this specification as well. 1384 8. IANA Considerations 1386 8.1. XML Namespace 1388 This document uses URNs to describe XML namespaces and XML schemas 1389 conforming to a registry mechanism described in [RFC3688]. The 1390 following URI assignment is requested of IANA: 1392 URI: ietf:params:xml:ns:fee-0.25 1394 Registrant Contact: See the "Author's Address" section of this 1395 document. 1397 XML: See the "Formal Syntax" section of this document. 1399 8.2. EPP Extension Registry 1401 The EPP extension described in this document should be registered by 1402 the IANA in the EPP Extension Registry described in [RFC7451]. The 1403 details of the registration are as follows: 1405 Name of Extension: EPP Fee Extension 1407 Document status: Standards Track 1409 Reference: (insert reference to RFC version of this document) 1411 Registrant Name and Email Address: See the "Author's Address" section 1412 of this document. 1414 TLDs: any 1416 IPR Disclosure: none 1418 Status: active 1420 Notes: none 1422 9. Implemntation Status 1424 Note to RFC Editor: Please remove this section and the reference to 1425 [RFC6982] before publication. 1427 This section records the status of known implementations of the 1428 protocol defined by this specification at the time of posting of this 1429 Internet-Draft, and is based on a proposal described in [RFC6982]. 1430 The description of implementations in this section is intended to 1431 assist the IETF in its decision processes in progressing drafts to 1432 RFCs. Please note that the listing of any individual implementation 1433 here does not imply endorsement by the IETF. Furthermore, no effort 1434 has been spent to verify the information presented here that was 1435 supplied by IETF contributors. This is not intended as, and must not 1436 be construed to be, a catalog of available implementations or their 1437 features. Readers are advised to note that other implementations may 1438 exist. 1440 According to [RFC6982], "this will allow reviewers and working groups 1441 to assign due consideration to documents that have the benefit of 1442 running code, which may serve as evidence of valuable experimentation 1443 and feedback that have made the implemented protocols more mature. 1444 It is up to the individual working groups to use this information as 1445 they see fit". 1447 9.1. RegistryEngine EPP Service 1449 Organization: CentralNic 1451 Name: RegistryEngine EPP Service 1453 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 1454 SLDs 1456 Level of maturity: Deployed in CentralNic's production environment as 1457 well as two other gTLD registry systems, and two ccTLD registry 1458 systems. 1460 Coverage: All aspects of the protocol are implemented. 1462 Licensing: Proprietary In-House software 1464 Contact: epp@centralnic.com 1466 URL: https://www.centralnic.com 1468 10. Acknowledgements 1470 The authors wish to thank the following persons for their feedback 1471 and suggestions: 1473 o James Gould of Verisign Inc 1474 o Luis Munoz of ISC 1475 o Michael Young of Architelos 1476 o Ben Levac and Jeff Eckhaus of Demand Media 1477 o Seth Goldman of Google 1478 o Klaus Malorny and Michael Bauland of Knipp 1479 o Jody Kolker, Joe Snitker and Kevin Allendorf of Go Daddy 1480 o Michael Holloway of Com Laude 1481 o Santosh Kalsangrah of Impetus Infotech 1482 o Alex Mayrhofer of Nic.at 1483 o Thomas Corte of Knipp Medien und Kommunikation GmbH 1485 11. Change History 1487 11.1. Change from 08 to 09 1489 Updated scheme to version 0.25 to allow tighter checking on 1490 by splitting the client and server definitions, moved 1491 the class element from the command to the object level and added an 1492 optional standard attribute to the command element. Also updated 1493 section 3.1 for clarity on name attribute; updated section 3.9 for 1494 clarity on uses of ; removed second paragraph in section 1495 5.2.1 as it was duplicative of second to last paragraph in 4.0; and 1496 updated section 5.1.1 to add section references. 1498 11.2. Change from 07 to 08 1500 Updated section 3.8 and 5.1.1 to provide clarity on server processing 1501 and response of various scenarios (i.e. "quiet" period processing). 1503 11.3. Change from 06 to 07 1505 Updated section 3.8 and 4.0 to provide clarity on server processing 1506 and response of various scenarios. 1508 11.4. Change from 05 to 06 1510 Updated scheme to version 0.23 to allow the return of no 1511 element(s) if an error situation occurs. Edited 1512 section 3.8 extensively after input from interim meeting and REGEXT 1513 F2F meeting at IETF-99. Added normative reference for draft-ietf- 1514 eppext-launchphase. 1516 11.5. Change from 04 to 05 1518 Updated scheme to version 0.21 to support the lang attribute for the 1519 reason element of the objectCDType and the commandType types as well 1520 as to add the update command to the commandEnum type. Updated 1521 section 3.1 to include language for the custom command. Added 1522 section 3.9 to provide a description of the element. 1523 Fixed typos and added clarification text on when client fee is less 1524 than server fee in section 4. Additionally, I added description 1525 pointers to appropriate Section 3 definitions for element clarity 1526 throughout the document. 1528 11.6. Change from 03 to 04 1530 Updated scheme to version 0.19 to correct typos and to replace the 1531 commandTypeValue type with the commandEnum type and customName 1532 attribute for stricter validation. Updated various text for grammar 1533 and clarity. Added text to section 4 clarifying the response 1534 when the client provided no fee extension but the server was 1535 expecting the extension. 1537 11.7. Change from 02 to 03 1539 Updated scheme to version 0.17 to simplify the check command syntax. 1540 Moved fee avail to objectCDType to allow fast failing on error 1541 situations. Removed the objectCheckType as it was no longer being 1542 used. Updated examples to reflect these scheme changes. Added 1543 language for server failing a if the passed by the 1544 client is less than the server fee. 1546 11.8. Change from 01 to 02 1548 Updated scheme to version 0.15 to fix errors in CommandType, 1549 objectCDType, transformCommandType and transformResultType 1550 definitions. 1552 11.9. Change from 00 to 01 1554 Added Roger Carney as author to finish draft. Moved Formal Syntax 1555 section to main level numbering. Various grammar, typos, and 1556 administrative edits for clarity. Removed default value for the 1557 "applied" attribute of so that it can truly be optional. 1558 Added support for the command to return a element 1559 as well. Modified default response on the command for the 1560 optional when it was not provided in the command, 1561 leaving it to the server to provide the default period value. 1562 Extensive edits were done to the command, the 1563 response and to the fee extension schema (checkType, objectCheckType, 1564 objectIdentifierType, objectCDType, commandType) to support 1565 requesting and returning multiple transformation fees in a single 1566 call. Added section on Phase/Subphase to provide more context on the 1567 uses. 1569 11.10. Change from draft-brown-00 to draft-ietf-regext-fees-00 1571 Updated to be REGEXT WG document. 1573 12. Normative References 1575 [I-D.ietf-regext-launchphase] 1576 Gould, J., Tan, W., and G. Brown, "Launch Phase Mapping 1577 for the Extensible Provisioning Protocol (EPP)", draft- 1578 ietf-regext-launchphase-05 (work in progress), June 2017. 1580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1581 Requirement Levels", BCP 14, RFC 2119, 1582 DOI 10.17487/RFC2119, March 1997, 1583 . 1585 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1586 DOI 10.17487/RFC3688, January 2004, 1587 . 1589 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 1590 the Extensible Provisioning Protocol (EPP)", RFC 3915, 1591 DOI 10.17487/RFC3915, September 2004, 1592 . 1594 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1595 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1596 . 1598 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1599 Domain Name Mapping", STD 69, RFC 5731, 1600 DOI 10.17487/RFC5731, August 2009, 1601 . 1603 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1604 Code: The Implementation Status Section", RFC 6982, 1605 DOI 10.17487/RFC6982, July 2013, 1606 . 1608 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1609 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1610 February 2015, . 1612 Authors' Addresses 1613 Roger Carney 1614 GoDaddy Inc. 1615 14455 N. Hayden Rd. #219 1616 Scottsdale, AZ 85260 1617 US 1619 Email: rcarney@godaddy.com 1620 URI: http://www.godaddy.com 1622 Gavin Brown 1623 CentralNic Group plc 1624 35-39 Moorgate 1625 London, England EC2R 6AR 1626 GB 1628 Phone: +44 20 33 88 0600 1629 Email: gavin.brown@centralnic.com 1630 URI: http://www.centralnic.com 1632 Jothan Frakes 1634 Email: jothan@jothan.com 1635 URI: http://jothan.com