idnits 2.17.1 draft-ietf-regext-epp-fees-20.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 (October 21, 2019) is 1646 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: 'RFC5646' is mentioned on line 449, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 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: April 23, 2020 CentralNic Group plc 6 J. Frakes 7 October 21, 2019 9 Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 10 draft-ietf-regext-epp-fees-20 12 Abstract 14 Given the expansion of the DNS namespace, and the proliferation of 15 novel business models, it is desirable to provide a method for 16 Extensible Provisioning Protocol (EPP) clients to query EPP servers 17 for the fees and credits and provide expected fees and credits for 18 certain commands and objects. This document describes an EPP 19 extension mapping for registry fees. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 23, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. Migrating to Newer Versions of This Extension . . . . . . . . 4 58 3. Extension Elements . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Client Commands . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Currency Codes . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Validity Periods . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Fees and Credits . . . . . . . . . . . . . . . . . . . . 6 63 3.4.1. Refunds . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4.2. Grace Periods . . . . . . . . . . . . . . . . . . . . 7 65 3.4.3. Correlation between Refundability and Grace Periods . 7 66 3.4.4. Applicability . . . . . . . . . . . . . . . . . . . . 7 67 3.5. Account Balance . . . . . . . . . . . . . . . . . . . . . 8 68 3.6. Credit Limit . . . . . . . . . . . . . . . . . . . . . . 8 69 3.7. Classification of Objects . . . . . . . . . . . . . . . . 9 70 3.8. Phase and Subphase Attributes . . . . . . . . . . . . . . 9 71 3.9. Reason . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Server Handling of Fee Information . . . . . . . . . . . . . 11 73 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 12 75 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 12 76 5.1.2. EPP Transfer Query Command . . . . . . . . . . . . . 16 77 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 18 78 5.2.1. EPP Command . . . . . . . . . . . . . . . . 18 79 5.2.2. EPP Command . . . . . . . . . . . . . . . . 20 80 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 21 81 5.2.4. EPP Command . . . . . . . . . . . . . . . 23 82 5.2.5. EPP Command . . . . . . . . . . . . . . . . 25 83 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27 84 6.1. Fee Extension Schema . . . . . . . . . . . . . . . . . . 27 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 87 8.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 32 88 8.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 32 89 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 33 90 9.1. RegistryEngine EPP Service . . . . . . . . . . . . . . . 33 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 92 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 34 93 11.1. Change from 18 to 19 . . . . . . . . . . . . . . . . . . 34 94 11.2. Change from 18 to 19 . . . . . . . . . . . . . . . . . . 34 95 11.3. Change from 17 to 18 . . . . . . . . . . . . . . . . . . 34 96 11.4. Change from 16 to 17 . . . . . . . . . . . . . . . . . . 35 97 11.5. Change from 15 to 16 . . . . . . . . . . . . . . . . . . 35 98 11.6. Change from 14 to 15 . . . . . . . . . . . . . . . . . . 35 99 11.7. Change from 13 to 14 . . . . . . . . . . . . . . . . . . 35 100 11.8. Change from 12 to 13 . . . . . . . . . . . . . . . . . . 35 101 11.9. Change from 11 to 12 . . . . . . . . . . . . . . . . . . 35 102 11.10. Change from 10 to 11 . . . . . . . . . . . . . . . . . . 35 103 11.11. Change from 09 to 10 . . . . . . . . . . . . . . . . . . 35 104 11.12. Change from 08 to 09 . . . . . . . . . . . . . . . . . . 36 105 11.13. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 36 106 11.14. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 36 107 11.15. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 36 108 11.16. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 36 109 11.17. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 36 110 11.18. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 37 111 11.19. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 37 112 11.20. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 37 113 11.21. Change from draft-brown-00 to draft-ietf-regext-fees-00 37 114 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 115 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 116 12.2. Informative References . . . . . . . . . . . . . . . . . 39 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 119 1. Introduction 121 Historically, domain name registries have applied a simple fee 122 structure for billable transactions, namely a basic unit price 123 applied to domain , , and RGP [RFC3915] 124 restore commands. Given the relatively small number of EPP servers 125 to which EPP clients have been required to connect, it has generally 126 been the case that client operators have been able to obtain details 127 of these fees out-of-band by contacting the server operators. 129 Given the expansion of the DNS namespace, and the proliferation of 130 novel business models, it is desirable to provide a method for EPP 131 clients to query EPP servers for the fees and credits associated with 132 certain commands and specific objects. 134 This document describes an extension mapping for version 1.0 of the 135 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping 136 provides a mechanism by which EPP clients may query the fees and 137 credits associated with various billable transactions, and obtain 138 their current account balance. 140 1.1. Conventions Used in This Document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 XML is case sensitive. Unless stated otherwise, XML specifications 149 and examples provided in this document MUST be interpreted in the 150 character case presented in order to develop a conforming 151 implementation. 153 "fee" is used as an abbreviation for "urn:ietf:params:xml:ns:epp:fee- 154 1.0". The XML namespace prefix "fee" is used, but implementations 155 MUST NOT depend on it and instead employ a proper namespace-aware XML 156 parser and serializer to interpret and output the XML documents. 158 In examples, "C:" represents lines sent by a protocol client and "S:" 159 represents lines returned by a protocol server. Indentation and 160 white space in examples are provided only to illustrate element 161 relationships and are not a required feature of this protocol. 163 2. Migrating to Newer Versions of This Extension 165 Servers which implement this extension SHOULD provide a way for 166 clients to progressively update their implementations when a new 167 version of the extension is deployed. 169 Servers SHOULD (for a temporary migration period) provide support for 170 older versions of the extension in parallel to the newest version, 171 and allow clients to select their preferred version via the 172 element of the command. 174 If a client requests multiple versions of the extension at login, 175 then, when preparing responses to commands which do not include 176 extension elements, the server SHOULD only include extension elements 177 in the namespace of the newest version of the extension requested by 178 the client. 180 When preparing responses to commands which do include extension 181 elements, the server SHOULD only include extension elements for the 182 extension versions present in the command. 184 3. Extension Elements 186 3.1. Client Commands 188 The element is used in the EPP command to 189 determine the fee that is applicable to the given command. 191 The use of the keys off the use of the "name" attribute 192 to define which transform fees the client is requesting information 193 about. Here is the list of possible values for the "name" attribute: 195 o "create" indicating a command as defined in [RFC5730]; 196 o "delete" indicating a command as defined in [RFC5730]; 197 o "renew" indicating a command as defined in [RFC5730]; 198 o "update" indicating a command as defined in [RFC5730]; 199 o "transfer" indicating a command as defined in 200 [RFC5730]; 201 o If the server supports the Registry Grace Period Mapping 202 [RFC3915], then the server MUST also support the "restore" value 203 as defined in [RFC3915]; 204 o "custom" indicating a custom command that MUST set the 205 "customName" attribute with custom command name. The possible set 206 of custom command name values is up to server policy. 208 The element MAY have an OPTIONAL "phase" attribute 209 specifying a launch phase as described in [RFC8334]. It may also 210 contain an OPTIONAL "subphase" attribute identifying the custom or 211 sub-phase as described in [RFC8334]. 213 3.2. Currency Codes 215 The element is used to indicate which currency fees 216 are charged in. This value of this element MUST be a three-character 217 currency code from [ISO4217:2015]. 219 Note that ISO 4217:2015 provides the special "XXX" code, which MAY be 220 used if the server uses a non-currency based system for assessing 221 fees, such as a system of credits. 223 The use of elements in client commands is OPTIONAL: if 224 a element is not present in a command, the server MUST 225 determine the currency based on the server default currency or based 226 on the client's account settings which are agreed to by the client 227 and server via an out-of-band channel. However, the 228 element MUST be present in responses. 230 Servers SHOULD NOT perform a currency conversion if a client uses an 231 incorrect currency code. Servers SHOULD return a 2004 "Parameter 232 value range" error instead. 234 3.3. Validity Periods 236 When querying for fee information using the command, the 237 element is used to indicate the period measured in years 238 or months, with the appropriate units specified using the "unit" 239 attribute to be added to the registration period of objects by the 240 , and commands. This element is derived 241 from the element described in [RFC5731]. 243 The element is OPTIONAL in commands, if omitted, 244 the server MUST determine the fee(s) using the server default period. 245 The element MUST be present in responses. 247 3.4. Fees and Credits 249 Servers which implement this extension will include elements in 250 responses which provide information about the fees and/or credits 251 associated with a given billable transaction. A fee will result in 252 subtracting from the Account Balance (described in Section 3.5) and a 253 credit will result in adding to the Account Balance (described in 254 Section 3.5). 256 The and elements are used to provide this 257 information. The presence of a element in a response 258 indicates a debit against the client's account balance; a 259 element indicates a credit. A element MUST 260 have a zero or greater (non-negative) value. A element 261 MUST have a negative value. 263 A server MAY respond with multiple and 264 elements in the same response. In such cases, the net fee or credit 265 applicable to the transaction is the arithmetic sum of the values of 266 each of the and/or elements. This amount 267 applies to the total additional validity period applied to the object 268 (where applicable). 270 The following attributes are defined for the element. 271 These are described in detail below: 273 description: an OPTIONAL attribute which provides a human-readable 274 description of the fee. Servers should provide documentation on the 275 possible values of this attribute, and their meanings. An OPTIONAL 276 "lang" attribute MAY be present, per the language structure in 277 [RFC5646], to identify the language of the returned text and has a 278 default value of "en" (English). If the "description" attribute is 279 not present, the "lang" attribute can be ignored. 281 refundable: an OPTIONAL boolean attribute indicating whether the fee 282 is refundable if the object is deleted. 284 grace-period: an OPTIONAL attribute which provides the time period 285 during which the fee is refundable. 287 applied: an OPTIONAL attribute indicating when the fee will be 288 deducted from the client's account. 290 The element can take a "description" attribute as 291 described above. An OPTIONAL "lang" attribute MAY be present to 292 identify the language of the returned text and has a default value of 293 "en" (English). 295 3.4.1. Refunds 297 elements MAY have an OPTIONAL "refundable" attribute which 298 takes a boolean value. Fees may be refunded under certain 299 circumstances, such as when a domain application is rejected (as 300 described in [RFC8334]) or when an object is deleted during the 301 relevant Grace Period (see below). 303 If the "refundable" attribute is omitted, then clients SHOULD NOT 304 make any assumption about the refundability of the fee. 306 3.4.2. Grace Periods 308 [RFC3915] describes a system of "grace periods", which are time 309 periods following a billable transaction during which, if an object 310 is deleted, the client receives a refund. 312 The "grace-period" attribute MAY be used to indicate the relevant 313 grace period for a fee. If a server implements the Registry Grace 314 Period extension [RFC3915], it MUST specify the grace period for all 315 relevant transactions. 317 If the "grace-period" attribute is omitted, then clients SHOULD NOT 318 make any assumption about the grace period of the fee. 320 3.4.3. Correlation between Refundability and Grace Periods 322 If a element has a "grace-period" attribute then it MUST 323 also be refundable and the "refundable" attribute MUST be true. If 324 the "refundable" attribute of a element is false then it 325 MUST NOT have a "grace-period" attribute. 327 3.4.4. Applicability 329 Fees may be applied immediately upon receipt of a command from a 330 client, or may only be applied once an out-of-band process (such as 331 the processing of applications at the end of a launch phase) has 332 taken place. 334 The "applied" attribute of the element allows servers to 335 indicate whether a fee will be applied immediately, or whether it 336 will be applied at some point in the future. This attribute takes 337 two possible values: "immediate" or "delayed". 339 3.5. Account Balance 341 The element is an OPTIONAL element which MAY be 342 included in server responses to transform commands. If present, it 343 can be used by the client to determine the remaining credit at the 344 server. 346 Whether or not the is included in responses is a matter 347 of server policy. However, if a server chooses to offer support for 348 this element, it MUST be included in responses to all "transform" or 349 billable commands (e.g. , , , , 350 ). 352 The value of the MAY be negative. A negative balance 353 indicates that the server has extended a line of credit to the client 354 (see below). 356 If a server includes a element in response to transform 357 commands, the value of the element MUST reflect the client's account 358 balance after any fees or credits associated with that command have 359 been applied. If the "applied" attribute of the element is 360 "delayed", then the MUST reflect the client's account 361 balance without any fees or credits associated with that command. 363 3.6. Credit Limit 365 As described above, if a server returns a response containing a 366 with a negative value, then the server has extended a 367 line of credit to the client. A server MAY also include a 368 element in responses that indicates the maximum 369 credit available to a client. A server MAY reject certain 370 transactions if the absolute value of the is equal to 371 or exceeds the value of the element. 373 Whether or not the is included in responses is a 374 matter of server policy. However, if a server chooses to offer 375 support for this element, it MUST be included in responses to all 376 "transform" commands (e.g. , , , , 377 ). 379 3.7. Classification of Objects 381 Objects may be assigned to a particular class, category, or tier, 382 each of which has a particular fee or set of fees associated with it. 383 The element, which MAY appear in and transform 384 responses, is used to indicate the classification of an object. 386 If a server makes use of this element, it should provide clients with 387 a list of all the values that the element may take via an out-of-band 388 channel. Servers MUST NOT use values which do not appear on this 389 list. 391 Servers that make use of this element MUST use a element 392 with the value "standard" for all objects that are subject to the 393 standard or default fee. 395 3.8. Phase and Subphase Attributes 397 The element has two attributes, phase and subphase, 398 that provide additional information related to a specific launch 399 phase as described in [RFC8334]. These attributes are used as 400 filters that should refine the server processing. 402 If the client contains a server supported combination 403 of phase/subphase the server MUST return fee data (including the 404 phase/subphase attribute(s)) for the specific combination. 406 If the client contains no phase/subphase attributes and 407 the server has only one active phase/subphase combination the server 408 MUST return data (including the phase/subphase attribute(s)) of the 409 currently active phase/subphase. 411 If the client contains no phase/subphase attributes and 412 the server has more than one active phase/subphase combination the 413 server MUST respond with a 2003 "Required parameter missing" error. 415 If the client contains no phase/subphase attributes and 416 the server is currently in a "quiet period" (e.g. not accepting 417 registrations or applications) the server MUST return data consistent 418 with the default general availability phase (e.g. "open" or "claims") 419 including the appropriate phase/subphase attribute(s). 421 If the client contains a phase attribute with no 422 subphase and the server has only one active subphase (or no subphase) 423 of this phase, the server MUST return data (including the phase/ 424 subphase attribute(s)) of the provided phase and currently active 425 subphase. 427 If the client contains a phase attribute with no 428 subphase and the server has more than one active subphase combination 429 of this phase, the server MUST respond with a 2003 "Required 430 parameter missing" error. 432 If the client contains a subphase with no phase 433 attribute the server MUST respond with a 2003 "Required parameter 434 missing" error. 436 If the client contains a phase attribute not defined in 437 [RFC8334] or not supported by server the server MUST respond with a 438 2004 "Parameter value range" error. 440 If the client contains a subphase attribute (or phase/ 441 subphase combination) not supported by server the server MUST respond 442 with a 2004 "Parameter value range" error. 444 3.9. Reason 446 The element is used to provide server specific text in 447 an effort to better explain why a command did not complete as 448 the client expected. An OPTIONAL "lang" attribute MAY be present to 449 identify the language, per the language structure in [RFC5646], of 450 the returned text and has a default value of "en" (English). 452 The element can be used within the server response 453 element or within the element. See section 454 5.1.1 for details on the "check data" element. 456 If the server cannot calculate the relevant fees, because the object, 457 command, currency, period, class or some combination is invalid per 458 server policy, the server has two ways of handling error processing 459 of element(s): 461 1. Fast-fail - The server, upon error identification, MAY stop 462 processing elements and return to the client a 463 containing the and a element 464 detailing the reason for failure. 466 S: 467 S: example.xyz 468 S: Only 1 year registration periods are 469 S: valid. 470 S: 472 2. Partial-fail - The server, upon error identification, MAY 473 continue processing elements and return to the 474 client a containing successfully processed 475 elements and failed elements. All returned failed 476 elements MUST have a element detailing 477 the reason for failure, and the server MAY additionally include a 478 element at the level. 480 S: 481 S: example.xyz 482 S: 483 S: 2 484 S: Only 1 year registration periods are 485 S: valid. 486 S: 487 S: 489 In either failure scenario the server MUST set the avail 490 attribute to false (0) and the server MUST process all objects in the 491 client request. 493 4. Server Handling of Fee Information 495 Depending on server policy, a client MAY be required to include the 496 extension elements described in this document for certain transform 497 commands. Servers must provide clear documentation to clients about 498 the circumstances in which this extension must be used. 500 The server MUST return avail="0" in its response to a command 501 for any object in the command that does not include the 502 extension for which the server would likewise fail a 503 domain command when no extension is provided for that 504 same object. 506 If a server receives a command from a client, which results 507 in no possible fee combination, the server MUST set the "avail" 508 attribute of the element to false (0) and provide a 509 . 511 If a server receives a command from a client, which results 512 in an ambiguous result (i.e. multiple possible fee combinations) the 513 server MUST reject the command with a 2003 "Required parameter 514 missing" error. 516 If a server receives a command from a client, which does not include 517 the fee extension data elements required by the server for that 518 command, then the server MUST respond with a 2003 "Required parameter 519 missing" error. 521 If the total fee provided by the client is less than the server's own 522 calculation of the fee or the server determines the currency is 523 inappropriate for that command, then the server MUST reject the 524 command with a 2004 "Parameter value range" error. 526 5. EPP Command Mapping 528 A detailed description of the EPP syntax and semantics can be found 529 in [RFC5730]. 531 5.1. EPP Query Commands 533 This extension does not add any elements to the EPP or 534 commands or responses. 536 5.1.1. EPP Command 538 This extension defines a new command called the Fee Check Command 539 that defines additional elements for the EPP command to 540 provide fee information along with the availability information of 541 the EPP command. 543 The command MAY contain an element which MAY contain a 544 element. The element MAY contain one 545 element and MUST contain one or more 546 elements. 548 The element(s) MUST contain(s) a "name" attribute (see 549 Section 3.1), an OPTIONAL "phase" attribute, and an OPTIONAL 550 "subphase" attribute (see Section 3.8). The element(s) 551 MAY have the following child elements: 553 o An OPTIONAL element (as described in Section 3.3). 555 Example command: 557 C: 558 C: 559 C: 560 C: 561 C: 563 C: example.com 564 C: example.net 565 C: example.xyz 566 C: 567 C: 568 C: 569 C: 570 C: USD 571 C: 572 C: 2 573 C: 574 C: 575 C: 576 C: 577 C: 578 C: 579 C: ABC-12345 580 C: 581 C: 583 When the server receives a command that includes the 584 extension elements described above, its response MUST contain an 585 element, which MUST contain a child 586 element. The element MUST contain a 587 element and a element for each object referenced in the 588 client command. 590 Each (check data) element MUST contain the following child 591 elements: 593 o A element, which MUST match an element referenced in 594 the client command. 595 o An OPTIONAL element (as described in Section 3.7). 596 o A element matching each (unless the 597 "avail" attribute of the if false) that appeared in the 598 corresponding of the client command. This element MAY 599 have the OPTIONAL "standard" attribute, with a default value of 600 "0" (or "false"), which indicates whether the fee matches the fee 601 of the "standard" classification (see section 3.7). This element 602 MAY have the OPTIONAL "phase" and "subphase" attributes, which 603 will match the same attributes in the corresponding 604 element of the client command if sent by the client. 606 The element also has an OPTIONAL "avail" attribute which is 607 a boolean. If the value of this attribute evaluates to false, this 608 indicates that the server cannot calculate the relevant fees, because 609 the object, command, currency, period, class or some combination is 610 invalid per server policy. If "avail" is false then the or 611 the element MUST contain a element (as 612 described in Section 3.9) and the server MAY eliminate some or all of 613 the element(s). 615 The element(s) MAY have the following child elements: 617 o An OPTIONAL element (as described in Section 3.3), 618 which contains the same unit, if present, that appeared in the 619 element of the command. If the value of the parent 620 element is "restore", this element MUST NOT be 621 included, otherwise it MUST be included. If no 622 appeared in the client command (and the command is not "restore") 623 then the server MUST return its default period value. 624 o Zero or more elements (as described in Section 3.4). 625 o Zero or more elements (as described in Section 3.4). 626 o An OPTIONAL element (as described in Section 3.9). 628 If the "avail" attribute of the element is true (1) and if 629 no elements are present in a element, this 630 indicates that no fee will be assessed by the server for this 631 command. 633 If the "avail" attribute of the element is true (1), then 634 the element MUST NOT contain a element. 636 Example response: 638 S: 639 S: 640 S: 641 S: 642 S: Command completed successfully 643 S: 644 S: 645 S: 647 S: 648 S: example.com 649 S: 650 S: 651 S: example.net 652 S: 653 S: 654 S: example.xyz 655 S: 656 S: 657 S: 658 S: 659 S: 661 S: USD 662 S: 663 S: example.com 664 S: Premium 665 S: 666 S: 2 667 S: 10.00 671 S: 672 S: 673 S: 1 674 S: 10.00 678 S: 679 S: 680 S: 1 681 S: 10.00 685 S: 686 S: 687 S: 15.00 689 S: 690 S: 691 S: 692 S: example.net 693 S: standard 694 S: 695 S: 2 696 S: 5.00 700 S: 701 S: 702 S: 1 703 S: 5.00 707 S: 708 S: 709 S: 1 710 S: 5.00 714 S: 715 S: 716 S: 5.00 718 S: 719 S: 720 S: 721 S: example.xyz 722 S: 723 S: 2 724 S: Only 1 year registration periods are 725 S: valid. 726 S: 727 S: 728 S: 729 S: 730 S: 731 S: ABC-12345 732 S: 54322-XYZ 733 S: 734 S: 735 S: 737 5.1.2. EPP Transfer Query Command 739 This extension does not add any elements to the EPP query 740 command, but does include elements in the response, when the 741 extension is included in the command service extensions. 743 When the query command has been processed successfully, if 744 the client has included the extension in the command service 745 element, and if the client is authorized by the server 746 to view information about the transfer, then the server MAY include 747 in the section of the EPP response a 748 element, which contains the following child elements: 750 o A element (as described in Section 3.2). 751 o A element (as described in Section 3.3). 752 o Zero or more elements (as described in Section 3.4) 753 containing the fees that will be charged to the gaining client. 754 o Zero or more elements (as described in Section 3.4) 755 containing the credits that will be refunded to the losing client. 757 Servers SHOULD omit when returning a response to the 758 gaining client, and omit elements when returning a response 759 to the losing client. 761 If no element is included in the response, then no fee 762 will be assessed by the server for the transfer. 764 Example query response: 766 S: 767 S: 768 S: 769 S: 770 S: Command completed successfully; action pending 771 S: 772 S: 773 S: 775 S: example.com 776 S: pending 777 S: ClientX 778 S: 2019-06-08T22:00:00.0Z 779 S: ClientY 780 S: 2019-06-13T22:00:00.0Z 781 S: 2021-09-08T22:00:00.0Z 782 S: 783 S: 784 S: 785 S: 786 S: USD 787 S: 1 788 S: 5.00 789 S: 790 S: 791 S: 792 S: ABC-12345 793 S: 54322-XYZ 794 S: 795 S: 796 S: 798 5.2. EPP Transform Commands 800 5.2.1. EPP Command 802 This extension adds elements to both the EPP command and 803 response, when the extension is included in the command 804 service extensions. 806 When submitting a command to the server, the client MAY 807 include in the element a element which 808 includes the following child elements: 810 o An OPTIONAL element (as described in Section 3.2); 811 o One or more elements (as described in Section 3.4). 813 When the command has been processed successfully, and the 814 client included the extension in the command service 815 extensions, and a fee was assessed by the server for the transaction, 816 the server MUST include in the section of the EPP 817 response a element, which contains the following child 818 elements: 820 o A element (as described in Section 3.2); 821 o Zero or more elements (as described in Section 3.4); 822 o Zero or more elements (as described in Section 3.4); 823 o An OPTIONAL element (as described in Section 3.5); 824 o An OPTIONAL element (as described in 825 Section 3.6). 827 Example command: 829 C: 830 C: 831 C: 832 C: 833 C: 835 C: example.com 836 C: 2 837 C: 838 C: ns1.example.net 839 C: ns2.example.net 840 C: 841 C: jd1234 842 C: sh8013 843 C: sh8013 844 C: 845 C: 2fooBAR 846 C: 847 C: 848 C: 849 C: 850 C: 851 C: USD 852 C: 5.00 853 C: 854 C: 855 C: ABC-12345 856 C: 857 C: 858 Example response: 860 S: 861 S: 862 S: 863 S: 864 S: Command completed successfully 865 S: 866 S: 867 S: 869 S: example.com 870 S: 2019-04-03T22:00:00.0Z 871 S: 2021-04-03T22:00:00.0Z 872 S: 873 S: 874 S: 875 S: 876 S: USD 877 S: 5.00 882 S: -5.00 883 S: 1000.00 884 S: 885 S: 886 S: 887 S: ABC-12345 888 S: 54321-XYZ 889 S: 890 S: 891 S: 893 5.2.2. EPP Command 895 This extension does not add any elements to the EPP command, 896 but does include elements in the response, when the extension is 897 included in the command service extensions. 899 When the command has been processed successfully, and the 900 client included the extension in the command service 901 extensions, the server MAY include in the section of the 902 EPP response a element, which contains the following 903 child elements: 905 o A element (as described in Section 3.2); 906 o Zero or more elements (as described in Section 3.4); 907 o Zero or more elements (as described in Section 3.4); 908 o An OPTIONAL element (as described in Section 3.5); 909 o An OPTIONAL element (as described in 910 Section 3.6). 912 Example response: 914 S: 915 S: 916 S: 917 S: 918 S: Command completed successfully 919 S: 920 S: 921 S: 923 S: USD 924 S: -5.00 927 S: 1005.00 928 S: 929 S: 930 S: 931 S: ABC-12345 932 S: 54321-XYZ 933 S: 934 S: 935 S: 937 5.2.3. EPP Command 939 This extension adds elements to both the EPP command and 940 response, when the extension is included in the command 941 service extensions. 943 When submitting a command to the server, the client MAY 944 include in the element a element which 945 includes the following child elements: 947 o An OPTIONAL element (as described in Section 3.2); 948 o One or more elements (as described in Section 3.4). 950 When the command has been processed successfully, and the 951 client included the extension in the command service 952 extensions, the server MAY include in the section of the 953 EPP response a element, which contains the following 954 child elements: 956 o A element (as described in Section 3.2); 957 o Zero or more elements (as described in Section 3.4); 958 o Zero or more elements (as described in Section 3.4); 959 o An OPTIONAL element (as described in Section 3.5); 960 o An OPTIONAL element (as described in 961 Section 3.6). 963 Example command: 965 C: 966 C: 967 C: 968 C: 969 C: 971 C: example.com 972 C: 2019-04-03 973 C: 5 974 C: 975 C: 976 C: 977 C: 978 C: USD 979 C: 5.00 980 C: 981 C: 982 C: ABC-12345 983 C: 984 C: 985 Example response: 987 S: 988 S: 989 S: 990 S: 991 S: Command completed successfully 992 S: 993 S: 994 S: 996 S: example.com 997 S: 2024-04-03T22:00:00.0Z 998 S: 999 S: 1000 S: 1001 S: 1002 S: USD 1003 S: 5.00 1006 S: 1000.00 1007 S: 1008 S: 1009 S: 1010 S: ABC-12345 1011 S: 54322-XYZ 1012 S: 1013 S: 1014 S: 1016 5.2.4. EPP Command 1018 This extension adds elements to both the EPP command and 1019 response, when the value of the "op" attribute of the 1020 command element is "request", and the extension is included in the 1021 command service extensions. 1023 When submitting a command to the server, the client MAY 1024 include in the element a element which 1025 includes the following child elements: 1027 o An OPTIONAL element (as described in Section 3.2); 1028 o One or more elements (as described in Section 3.4). 1030 When the command has been processed successfully, and the 1031 client included the extension in the command service 1032 extensions, the server MAY include in the section of the 1033 EPP response a element, which contains the following 1034 child elements: 1036 o A element (as described in Section 3.2); 1037 o Zero or more elements (as described in Section 3.4); 1038 o Zero or more elements (as described in Section 3.4); 1039 o An OPTIONAL element (as described in Section 3.5); 1040 o An OPTIONAL element (as described in 1041 Section 3.6). 1043 Example command: 1045 C: 1046 C: 1047 C: 1048 C: 1049 C: 1051 C: example.com 1052 C: 1 1053 C: 1054 C: 2fooBAR 1055 C: 1056 C: 1057 C: 1058 C: 1059 C: 1060 C: USD 1061 C: 5.00 1062 C: 1063 C: 1064 C: ABC-12345 1065 C: 1066 C: 1067 Example response: 1069 S: 1070 S: 1071 S: 1072 S: 1073 S: Command completed successfully; action pending 1074 S: 1075 S: 1076 S: 1078 S: example.com 1079 S: pending 1080 S: ClientX 1081 S: 2019-06-08T22:00:00.0Z 1082 S: ClientY 1083 S: 2019-06-13T22:00:00.0Z 1084 S: 2021-09-08T22:00:00.0Z 1085 S: 1086 S: 1087 S: 1088 S: 1089 S: USD 1090 S: 5.00 1093 S: 1094 S: 1095 S: 1096 S: ABC-12345 1097 S: 54322-XYZ 1098 S: 1099 S: 1100 S: 1102 5.2.5. EPP Command 1104 This extension adds elements to both the EPP command and 1105 response, when the extension is included in the command 1106 service extensions. 1108 When submitting a command to the server, the client MAY 1109 include in the element a element which 1110 includes the following child elements: 1112 o An OPTIONAL element (as described in Section 3.2); 1113 o One or more elements (as described in Section 3.4). 1115 When the command has been processed successfully, and the 1116 client included the extension in the command service 1117 extensions, the server MAY include in the section of the 1118 EPP response a element, which contains the following 1119 child elements: 1121 o A element (as described in Section 3.2); 1122 o Zero or more elements (as described in Section 3.4); 1123 o Zero or more elements (as described in Section 3.4); 1124 o An OPTIONAL element (as described in Section 3.5); 1125 o An OPTIONAL element (as described in 1126 Section 3.6). 1128 Example command: 1130 C: 1131 C: 1132 C: 1133 C: 1134 C: 1136 C: example.com 1137 C: 1138 C: sh8013 1139 C: 1140 C: 1141 C: 1142 C: 1143 C: 1144 C: USD 1145 C: 5.00 1146 C: 1147 C: 1148 C: ABC-12345 1149 C: 1150 C: 1151 Example response: 1153 S: 1154 S: 1155 S: 1156 S: 1157 S: Command completed successfully 1158 S: 1159 S: 1160 S: 1161 S: USD 1162 S: 5.00 1163 S: 1164 S: 1165 S: 1166 S: ABC-12345 1167 S: 54321-XYZ 1168 S: 1169 S: 1170 S: 1172 6. Formal Syntax 1174 One schema is presented here that is the EPP Fee Extension schema. 1176 The formal syntax presented here is a complete schema representation 1177 of the object mapping suitable for automated validation of EPP XML 1178 instances. The BEGIN and END tags are not part of the schema; they 1179 are used to note the beginning and ending of the schema for URI 1180 registration purposes. 1182 6.1. Fee Extension Schema 1184 The formal syntax presented here is a complete schema representation 1185 of the object mapping suitable for automated validation of EPP XML 1186 instances. The BEGIN and END tags are not part of the schema; they 1187 are used to note the beginning and ending of the schema for URI 1188 registration purposes. 1190 BEGIN 1191 1192 1198 1199 1201 1202 1203 Extensible Provisioning Protocol v1.0 Fee Extension 1204 1205 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1220 1221 1222 1223 1225 1227 1228 1230 1231 1232 1233 1235 1236 1237 1239 1240 1241 1242 1243 1245 1247 1249 1250 1251 1252 1253 1255 1256 1257 1258 1260 1261 1262 1263 1265 1267 1269 1270 1272 1273 1274 1275 1277 1279 1281 1283 1285 1287 1288 1290 1291 1292 1293 1294 1296 1298 1299 1300 1302 1303 1304 1305 1306 1307 1309 1310 1311 1312 1313 1315 1317 1319 1320 1321 1322 1323 1325 1326 1327 1328 1329 1330 1331 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1350 1351 1352 1353 1354 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1375 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. This extension passes financial 1402 information using the EPP protocol, so confidentiality and integrity 1403 protection must be provided by the transport mechanism. All 1404 transports compliant with [RFC5730] provide the needed level of 1405 confidentiality and integrity protections. The server will only 1406 provide information, including financial information, that is 1407 relevant to the authenticated client. 1409 8. IANA Considerations 1411 8.1. XML Namespace 1413 This document uses URNs to describe XML namespaces and XML schemas 1414 conforming to a registry mechanism described in [RFC3688]. 1416 Registration request for the fee namespace: 1418 URI: urn:ietf:params:xml:ns:epp:fee-1.0 1420 Registrant Contact: IESG 1422 XML: None. Namespace URIs do not represent an XML specification. 1424 Registration request for the fee schema: 1426 URI: urn:ietf:params:xml:schema:epp:fee-1.0 1428 Registrant Contact: IESG 1430 XML: See the "Formal Syntax" section of this document. 1432 8.2. EPP Extension Registry 1434 The EPP extension described in this document should be registered by 1435 the IANA in the EPP Extension Registry described in [RFC7451]. The 1436 details of the registration are as follows: 1438 Name of Extension: Registry Fee Extension for the Extensible 1439 Provisioning Protocol (EPP) 1440 Document status: Standards Track 1442 Reference: (insert reference to RFC version of this document) 1444 Registrant Name and Email Address: IESG, 1446 TLDs: Any 1448 IPR Disclosure: None 1450 Status: Active 1452 Notes: None 1454 9. Implementation Status 1456 Note to RFC Editor: Please remove this section and the reference to 1457 [RFC7942] before publication. 1459 This section records the status of known implementations of the 1460 protocol defined by this specification at the time of posting of this 1461 Internet-Draft, and is based on a proposal described in [RFC7942]. 1462 The description of implementations in this section is intended to 1463 assist the IETF in its decision processes in progressing drafts to 1464 RFCs. Please note that the listing of any individual implementation 1465 here does not imply endorsement by the IETF. Furthermore, no effort 1466 has been spent to verify the information presented here that was 1467 supplied by IETF contributors. This is not intended as, and must not 1468 be construed to be, a catalog of available implementations or their 1469 features. Readers are advised to note that other implementations may 1470 exist. 1472 According to [RFC7942], "this will allow reviewers and working groups 1473 to assign due consideration to documents that have the benefit of 1474 running code, which may serve as evidence of valuable experimentation 1475 and feedback that have made the implemented protocols more mature. 1476 It is up to the individual working groups to use this information as 1477 they see fit". 1479 9.1. RegistryEngine EPP Service 1481 Organization: CentralNic 1483 Name: RegistryEngine EPP Service 1485 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 1486 SLDs 1487 Level of maturity: Deployed in CentralNic's production environment as 1488 well as two other gTLD registry systems, and two ccTLD registry 1489 systems. 1491 Coverage: All aspects of the protocol are implemented. 1493 Licensing: Proprietary In-House software 1495 Contact: epp@centralnic.com 1497 URL: https://www.centralnic.com 1499 10. Acknowledgements 1501 The authors wish to thank the following persons for their feedback 1502 and suggestions: 1504 o James Gould of Verisign Inc 1505 o Luis Munoz of ISC 1506 o Michael Young of Architelos 1507 o Ben Levac and Jeff Eckhaus of Demand Media 1508 o Seth Goldman of Google 1509 o Klaus Malorny and Michael Bauland of Knipp 1510 o Jody Kolker, Joe Snitker and Kevin Allendorf of Go Daddy 1511 o Michael Holloway of Com Laude 1512 o Santosh Kalsangrah of Impetus Infotech 1513 o Alex Mayrhofer of Nic.at 1514 o Thomas Corte of Knipp Medien und Kommunikation GmbH 1516 11. Change History 1518 11.1. Change from 18 to 19 1520 Added normative reference for XML Schema. 1522 11.2. Change from 18 to 19 1524 Updated per IESG review, all updates (except for one schema change) 1525 were just textual for clarity and correctness. The schema change was 1526 to require the name attribute of the commandType element. 1528 11.3. Change from 17 to 18 1530 Corrected erroneous edit left in place in previous revision (17), 1531 reverted text back to original text (revision 16) in section 3.4. 1533 11.4. Change from 16 to 17 1535 Updated per AD review, all updates were just textual for clarity and 1536 correctness. 1538 11.5. Change from 15 to 16 1540 Updated per AD review and list comments: several grammar corrections; 1541 clarification text added to section 3.4.3 and 3.5; and a schema 1542 update for consistency by providing a "lang" attribute to the 1543 and "description" attribute detailed in 1544 section 3.4. 1546 11.6. Change from 14 to 15 1548 Updated schema, moving the "standard" attribute of the 1549 "commandDataType" inside the block. 1551 11.7. Change from 13 to 14 1553 Moved RFC 7451 reference from Normative to Informative section. 1555 11.8. Change from 12 to 13 1557 Updated XML namespace and schema registration to be "epp" scoped - 1558 global replace of XML namespace from urn:ietf:params:xml:ns:fee-1.0 1559 to urn:ietf:params:xml:ns:epp:fee-1.0 and the XML schema registration 1560 from urn:ietf:params:xml:schema:fee-1.0 to 1561 urn:ietf:params:xml:schema:epp:fee-1.0. 1563 11.9. Change from 11 to 12 1565 Updated references to current version of documents and moved the 1566 "standard" attribute from the check command (commandType) to the 1567 check response (commandDataType). 1569 11.10. Change from 10 to 11 1571 Updated document per Working Group Last Call comments. Made minor 1572 textual changes throughout for enhanced clarity per WGLC comments. 1574 11.11. Change from 09 to 10 1576 Updated document per Working Group Last Call comments. Updated 1577 schema to version 1.0 in anticipation of standardization, no changes 1578 were made to the latest, 0.25, schema. Made minor textual changes 1579 throughout for enhanced clarity per WGLC comments. 1581 11.12. Change from 08 to 09 1583 Updated scheme to version 0.25 to allow tighter checking on 1584 by splitting the client and server definitions, moved 1585 the class element from the command to the object level and added an 1586 optional standard attribute to the command element. Also updated 1587 section 3.1 for clarity on name attribute; updated section 3.9 for 1588 clarity on uses of ; removed second paragraph in section 1589 5.2.1 as it was duplicative of second to last paragraph in 4.0; and 1590 updated section 5.1.1 to add section references. 1592 11.13. Change from 07 to 08 1594 Updated section 3.8 and 5.1.1 to provide clarity on server processing 1595 and response of various scenarios (i.e. "quiet" period processing). 1597 11.14. Change from 06 to 07 1599 Updated section 3.8 and 4.0 to provide clarity on server processing 1600 and response of various scenarios. 1602 11.15. Change from 05 to 06 1604 Updated scheme to version 0.23 to allow the return of no 1605 element(s) if an error situation occurs. Edited 1606 section 3.8 extensively after input from interim meeting and REGEXT 1607 F2F meeting at IETF-99. Added normative reference for draft-ietf- 1608 eppext-launchphase. 1610 11.16. Change from 04 to 05 1612 Updated scheme to version 0.21 to support the lang attribute for the 1613 reason element of the objectCDType and the commandType types as well 1614 as to add the update command to the commandEnum type. Updated 1615 section 3.1 to include language for the custom command. Added 1616 section 3.9 to provide a description of the element. 1617 Fixed typos and added clarification text on when client fee is less 1618 than server fee in section 4. Additionally, I added description 1619 pointers to appropriate Section 3 definitions for element clarity 1620 throughout the document. 1622 11.17. Change from 03 to 04 1624 Updated scheme to version 0.19 to correct typos and to replace the 1625 commandTypeValue type with the commandEnum type and customName 1626 attribute for stricter validation. Updated various text for grammar 1627 and clarity. Added text to section 4 clarifying the response 1628 when the client provided no fee extension but the server was 1629 expecting the extension. 1631 11.18. Change from 02 to 03 1633 Updated scheme to version 0.17 to simplify the check command syntax. 1634 Moved fee avail to objectCDType to allow fast failing on error 1635 situations. Removed the objectCheckType as it was no longer being 1636 used. Updated examples to reflect these scheme changes. Added 1637 language for server failing a if the passed by the 1638 client is less than the server fee. 1640 11.19. Change from 01 to 02 1642 Updated scheme to version 0.15 to fix errors in CommandType, 1643 objectCDType, transformCommandType and transformResultType 1644 definitions. 1646 11.20. Change from 00 to 01 1648 Added Roger Carney as author to finish draft. Moved Formal Syntax 1649 section to main level numbering. Various grammar, typos, and 1650 administrative edits for clarity. Removed default value for the 1651 "applied" attribute of so that it can truly be optional. 1652 Added support for the command to return a element 1653 as well. Modified default response on the command for the 1654 optional when it was not provided in the command, 1655 leaving it to the server to provide the default period value. 1656 Extensive edits were done to the command, the 1657 response and to the fee extension schema (checkType, objectCheckType, 1658 objectIdentifierType, objectCDType, commandType) to support 1659 requesting and returning multiple transformation fees in a single 1660 call. Added section on Phase/Subphase to provide more context on the 1661 uses. 1663 11.21. Change from draft-brown-00 to draft-ietf-regext-fees-00 1665 Updated to be REGEXT WG document. 1667 12. References 1669 12.1. Normative References 1671 [ISO4217:2015] 1672 International Organization for Standardization, "Codes for 1673 the representation of currencies", August 2015, 1674 . 1676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1677 Requirement Levels", BCP 14, RFC 2119, 1678 DOI 10.17487/RFC2119, March 1997, 1679 . 1681 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1682 DOI 10.17487/RFC3688, January 2004, 1683 . 1685 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 1686 the Extensible Provisioning Protocol (EPP)", RFC 3915, 1687 DOI 10.17487/RFC3915, September 2004, 1688 . 1690 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1691 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1692 . 1694 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1695 Domain Name Mapping", STD 69, RFC 5731, 1696 DOI 10.17487/RFC5731, August 2009, 1697 . 1699 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1700 Code: The Implementation Status Section", BCP 205, 1701 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1702 . 1704 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1705 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1706 May 2017, . 1708 [RFC8334] Gould, J., Tan, W., and G. Brown, "Launch Phase Mapping 1709 for the Extensible Provisioning Protocol (EPP)", RFC 8334, 1710 DOI 10.17487/RFC8334, March 2018, 1711 . 1713 [W3C.REC-xmlschema-1-20041028] 1714 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1715 "XML Schema Part 1: Structures Second Edition", World Wide 1716 Web Consortium Recommendation REC-xmlschema-1-20041028, 1717 October 2004, 1718 . 1720 12.2. Informative References 1722 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1723 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1724 February 2015, . 1726 Authors' Addresses 1728 Roger Carney 1729 GoDaddy Inc. 1730 14455 N. Hayden Rd. #219 1731 Scottsdale, AZ 85260 1732 US 1734 Email: rcarney@godaddy.com 1735 URI: http://www.godaddy.com 1737 Gavin Brown 1738 CentralNic Group plc 1739 35-39 Moorgate 1740 London, England EC2R 6AR 1741 GB 1743 Phone: +44 20 33 88 0600 1744 Email: gavin.brown@centralnic.com 1745 URI: http://www.centralnic.com 1747 Jothan Frakes 1749 Email: jothan@jothan.com 1750 URI: http://jothan.com