1 Internet Engineering Task Force (IETF) R. Carney
2 Request for Comments: 8748 GoDaddy Inc.
3 Category: Standards Track G. Brown
4 ISSN: 2070-1721 CentralNic Group plc
5 J. Frakes
6 March 2020
7
8
9 Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
10
11 Abstract
12
13 Given the expansion of the DNS namespace and the proliferation of
14 novel business models, it is desirable to provide a method for
15 Extensible Provisioning Protocol (EPP) clients to query EPP servers
16 for the fees and credits associated with various billable
17 transactions and provide expected fees and credits for certain
18 commands and objects. This document describes an EPP extension
19 mapping for registry fees.
20
21 Status of This Memo
22
23 This is an Internet Standards Track document.
24
25 This document is a product of the Internet Engineering Task Force
26 (IETF). It represents the consensus of the IETF community. It has
27 received public review and has been approved for publication by the
28 Internet Engineering Steering Group (IESG). Further information on
29 Internet Standards is available in Section 2 of RFC 7841.
30
31 Information about the current status of this document, any errata,
32 and how to provide feedback on it may be obtained at
33 https://www.rfc-editor.org/info/rfc8748.
34
35 Copyright Notice
36
37 Copyright (c) 2020 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
39
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (https://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
49
50 Table of Contents
51
52 1. Introduction
53 1.1. Conventions Used in This Document
54 2. Migrating to Newer Versions of This Extension
55 3. Extension Elements
56 3.1. Client Commands
57 3.2. Currency Codes
58 3.3. Validity Periods
59 3.4. Fees and Credits
60 3.4.1. Refunds
61 3.4.2. Grace Periods
62 3.4.3. Correlation between Refundability and Grace Periods
63 3.4.4. Applicability
64 3.5. Account Balance
65 3.6. Credit Limit
66 3.7. Classification of Objects
67 3.8. "Phase" and "Subphase" Attributes
68 3.9. Reason
69 4. Server Handling of Fee Information
70 5. EPP Command Mapping
71 5.1. EPP Query Commands
72 5.1.1. EPP <check> Command
73 5.1.2. EPP Transfer Query Command
74 5.2. EPP Transform Commands
75 5.2.1. EPP <create> Command
76 5.2.2. EPP <delete> Command
77 5.2.3. EPP <renew> Command
78 5.2.4. EPP <transfer> Command
79 5.2.5. EPP <update> Command
80 6. Formal Syntax
81 6.1. Fee Extension Schema
82 7. Security Considerations
83 8. IANA Considerations
84 8.1. XML Namespace
85 8.2. EPP Extension Registry
86 9. References
87 9.1. Normative References
88 9.2. Informative References
89 Acknowledgements
90 Authors' Addresses
91
92 1. Introduction
93
94 Historically, domain name registries have applied a simple fee
95 structure for billable transactions, namely a basic unit price
96 applied to domain <create>, <renew>, <transfer>, and Redemption Grace
97 Period (RGP) [RFC3915] restore commands. Given the relatively small
98 number of EPP servers to which EPP clients have been required to
99 connect, it has generally been the case that client operators have
100 been able to obtain details of these fees out of band by contacting
101 the server operators.
102
103 Given the expansion of the DNS namespace and the proliferation of
104 novel business models, it is desirable to provide a method for EPP
105 clients to query EPP servers for the fees and credits associated with
106 various billable transactions and certain commands and specific
107 objects.
108
109 This document describes an extension mapping for version 1.0 of the
110 Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping
111 provides a mechanism by which EPP clients may query the fees and
112 credits associated with various billable transactions and obtain
113 their current account balance.
114
115 1.1. Conventions Used in This Document
116
117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
119 "OPTIONAL" in this document are to be interpreted as described in
120 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
121 capitals, as shown here.
122
123 XML is case sensitive. Unless stated otherwise, the XML
124 specifications and examples provided in this document MUST be
125 interpreted in the character case presented in order to develop a
126 conforming implementation.
127
128 "fee" is used as an abbreviation for "urn:ietf:params:xml:ns:epp:fee-
129 1.0". The XML namespace prefix "fee" is used, but implementations
130 MUST NOT depend on it and instead employ a proper namespace-aware XML
131 parser and serializer to interpret and output the XML documents.
132
133 In the examples, "C:" represents lines sent by a protocol client, and
134 "S:" represents lines returned by a protocol server. Indentation and
135 white space in the examples are provided only to illustrate element
136 relationships and are not a required feature of this protocol.
137
138 2. Migrating to Newer Versions of This Extension
139
140 Servers that implement this extension SHOULD provide a way for
141 clients to progressively update their implementations when a new
142 version of the extension is deployed.
143
144 Servers SHOULD (for a temporary migration period) provide support for
145 older versions of the extension in parallel to the newest version and
146 allow clients to select their preferred version via the
147 <svcExtension> element of the <login> command.
148
149 If a client requests multiple versions of the extension at login,
150 then, when preparing responses to commands that do not include
151 extension elements, the server SHOULD only include extension elements
152 in the namespace of the newest version of the extension requested by
153 the client.
154
155 When preparing responses to commands that do include extension
156 elements, the server SHOULD only include extension elements for the
157 extension versions present in the command.
158
159 3. Extension Elements
160
161 3.1. Client Commands
162
163 The <fee:command> element is used in the EPP <check> command to
164 determine the fee that is applicable to the given command.
165
166 The "name" attribute of the <fee:command> is used to define which
167 transform fees the client is requesting information about. The
168 possible values for the "name" attribute are:
169
170 * "create", indicating a <create> command as defined in [RFC5730].
171
172 * "delete", indicating a <delete> command as defined in [RFC5730].
173
174 * "renew", indicating a <renew> command as defined in [RFC5730].
175
176 * "update", indicating a <update> command as defined in [RFC5730].
177
178 * "transfer", indicating a <transfer> command as defined in
179 [RFC5730].
180
181 * If the server supports registry grace period mapping [RFC3915],
182 then the server MUST also support the "restore" value as defined
183 in [RFC3915].
184
185 * "custom", indicating a custom command that MUST set the
186 "customName" attribute with a custom command name. The possible
187 set of custom command name values is dictated by the server
188 policy.
189
190 The <fee:command> element MAY have an OPTIONAL "phase" attribute
191 specifying a launch phase as described in [RFC8334]. It may also
192 contain an OPTIONAL "subphase" attribute identifying the custom or
193 subphase as described in [RFC8334].
194
195 3.2. Currency Codes
196
197 The <fee:currency> element is used to indicate the currency in which
198 fees are charged. The value of this element MUST be a three-
199 character currency code from [ISO4217_2015].
200
201 Note that [ISO4217_2015] provides the special "XXX" code, which MAY
202 be used if the server uses a non-currency-based system for assessing
203 fees, such as a system of credits.
204
205 The use of <fee:currency> elements in client commands is OPTIONAL: if
206 a <fee:currency> element is not present in a command, the server MUST
207 determine the currency based on the server default currency or on the
208 client's account settings, which are agreed to by the client and
209 server via an out-of-band channel. However, the <fee:currency>
210 element MUST be present in the responses.
211
212 Servers SHOULD NOT perform a currency conversion if a client uses an
213 incorrect currency code. Servers SHOULD return a 2004 "Parameter
214 value range error" instead.
215
216 3.3. Validity Periods
217
218 When querying for fee information using the <check> command, the
219 <fee:period> element is used to indicate the validity period, which
220 is to be added to extend the registration period of objects by the
221 <create>, <renew>, and <transfer> commands. Validity periods are
222 measured in years or months, with the appropriate units specified
223 using the "unit" attribute. Valid values for the "unit" attribute
224 are "y" for years and "m" for months. This element is derived from
225 the <domain:period> element described in [RFC5731].
226
227 The <fee:period> element is OPTIONAL in <check> commands; if omitted,
228 the server MUST determine the fee(s) using the server default period.
229 The <fee:period> element MUST be present in <check> responses.
230
231 3.4. Fees and Credits
232
233 Servers that implement this extension will include elements in
234 responses that provide information about the fees and/or credits
235 associated with a given billable transaction. A fee will result in
236 subtracting from the Account Balance (described in Section 3.5), and
237 a credit will result in adding to the Account Balance (described in
238 Section 3.5).
239
240 The <fee:fee> and <fee:credit> elements are used to provide this
241 information. The presence of a <fee:fee> element in a response
242 indicates a debit against the client's account balance; a
243 <fee:credit> element indicates a credit. A <fee:fee> element MUST
244 have a zero or greater (non-negative) value. A <fee:credit> element
245 MUST have a negative value.
246
247 A server MAY respond with multiple <fee:fee> and <fee:credit>
248 elements in the same response. In such cases, the net fee or credit
249 applicable to the transaction is the arithmetic sum of the values of
250 each of the <fee:fee> and/or <fee:credit> elements. This amount
251 applies to the total additional validity period for the object (where
252 applicable).
253
254 The following attributes are defined for the <fee:fee> element.
255 These are described in detail below:
256
257 description: an OPTIONAL attribute that provides a human-readable
258 description of the fee. Servers should provide documentation on
259 the possible values of this attribute and their meanings. An
260 OPTIONAL "lang" attribute MAY be present, per the language
261 structure in [RFC5646], to identify the language of the returned
262 text and has a default value of "en" (English). If the
263 "description" attribute is not present, the "lang" attribute can
264 be ignored.
265
266 refundable: an OPTIONAL boolean attribute indicating whether the fee
267 is refundable if the object is deleted.
268
269 grace-period: an OPTIONAL attribute that provides the time period
270 during which the fee is refundable.
271
272 applied: an OPTIONAL attribute indicating when the fee will be
273 deducted from the client's account.
274
275 The <fee:credit> element can take a "description" attribute as
276 described above. An OPTIONAL "lang" attribute MAY be present to
277 identify the language of the returned text and has a default value of
278 "en" (English).
279
280 3.4.1. Refunds
281
282 <fee:fee> elements MAY have an OPTIONAL "refundable" attribute that
283 takes a boolean value. Fees may be refunded under certain
284 circumstances, such as when a domain application is rejected (as
285 described in [RFC8334]) or when an object is deleted during the
286 relevant grace period (see Section 3.4.2).
287
288 If the "refundable" attribute is omitted, then clients SHOULD NOT
289 make any assumptions about the refundability of the fee.
290
291 3.4.2. Grace Periods
292
293 [RFC3915] describes a system of "grace periods", which are time
294 periods following a billable transaction during which, if an object
295 is deleted, the client receives a refund.
296
297 The "grace-period" attribute MAY be used to indicate the relevant
298 grace period for a fee. If a server implements the registry grace
299 period extension [RFC3915], it MUST specify the grace period for all
300 relevant transactions.
301
302 If the "grace-period" attribute is omitted, then clients SHOULD NOT
303 make any assumptions about the grace period of the fee.
304
305 3.4.3. Correlation between Refundability and Grace Periods
306
307 If a <fee:fee> element has a "grace-period" attribute, then it MUST
308 also be refundable, and the "refundable" attribute MUST be true. If
309 the "refundable" attribute of a <fee:fee> element is false, then it
310 MUST NOT have a "grace-period" attribute.
311
312 3.4.4. Applicability
313
314 Fees may be applied immediately upon receipt of a command from a
315 client or may only be applied once an out-of-band process (such as
316 the processing of applications at the end of a launch phase) has
317 taken place.
318
319 The "applied" attribute of the <fee:fee> element allows servers to
320 indicate whether a fee will be applied immediately or whether it will
321 be applied at some point in the future. This attribute takes two
322 possible values: "immediate" or "delayed".
323
324 3.5. Account Balance
325
326 The <fee:balance> element is an OPTIONAL element that MAY be included
327 in server responses to transform commands. If present, it can be
328 used by the client to determine the remaining credit at the server.
329
330 Whether or not the <fee:balance> is included in responses is a matter
331 of server policy. However, if a server chooses to offer support for
332 this element, it MUST be included in responses to all "transform" or
333 billable commands (e.g., <create>, <renew>, <update>, <delete>,
334 <transfer op="request">).
335
336 The value of the <fee:balance> MAY be negative. A negative balance
337 indicates that the server has extended a line of credit to the client
338 (see Section 3.6).
339
340 If a server includes a <fee:balance> element in response to transform
341 commands, the value of the element MUST reflect the client's account
342 balance after any fees or credits associated with that command have
343 been applied. If the "applied" attribute of the <fee:fee> element is
344 "delayed", then the <fee:balance> MUST reflect the client's account
345 balance without any fees or credits associated with that command.
346
347 3.6. Credit Limit
348
349 As described above, if a server returns a response containing a
350 <fee:balance> with a negative value, then the server has extended a
351 line of credit to the client. A server MAY also include in responses
352 a <fee:creditLimit> element that indicates the maximum credit
353 available to a client. A server MAY reject certain transactions if
354 the absolute value of the <fee:balance> is equal to or exceeds the
355 value of the <fee:creditLimit> element.
356
357 Whether or not the <fee:creditLimit> is included in responses is a
358 matter of server policy. However, if a server chooses to offer
359 support for this element, it MUST be included in responses to all
360 "transform" commands (e.g., <create>, <renew>, <update>, <delete>,
361 <transfer op="request">).
362
363 3.7. Classification of Objects
364
365 Objects may be assigned to a particular class, category, or tier,
366 each of which has a particular fee or set of fees associated with it.
367 The <fee:class> element, which MAY appear in <check> and transform
368 responses, is used to indicate the classification of an object.
369
370 If a server makes use of this element, it should provide clients with
371 a list of all the values that the element may take via an out-of-band
372 channel. Servers MUST NOT use values that do not appear on this
373 list.
374
375 Servers that make use of this element MUST use a <fee:class> element
376 with the value "standard" for all objects that are subject to the
377 standard or default fee.
378
379 3.8. "Phase" and "Subphase" Attributes
380
381 The <fee:command> element has two attributes, "phase" and "subphase",
382 that provide additional information related to a specific launch
383 phase, as described in [RFC8334]. These attributes are used as
384 filters that should refine the server processing.
385
386 If the client <fee:command> contains a server-supported combination
387 of phase/subphase, the server MUST return the fee data (including the
388 phase/subphase attribute(s)) for the specific combination.
389
390 If the client <fee:command> contains no "phase"/"subphase" attributes
391 and the server has only one active phase/subphase combination, the
392 server MUST return the data (including the "phase"/"subphase"
393 attribute(s)) of the currently active phase/subphase.
394
395 If the client <fee:command> contains no phase/subphase attributes and
396 the server has more than one active phase/subphase combination, the
397 server MUST respond with a 2003 "Required parameter missing" error.
398
399 If the client <fee:command> contains no phase/subphase attributes and
400 the server is currently in a "quiet period" (e.g., not accepting
401 registrations or applications), the server MUST return data
402 consistent with the default general availability phase (e.g., "open"
403 or "claims"), including the appropriate phase/subphase attribute(s).
404
405 If the client <fee:command> contains a phase attribute with no
406 subphase and the server has only one active subphase (or no subphase)
407 of this phase, the server MUST return the data (including the phase/
408 subphase attribute(s)) of the provided phase and currently active
409 subphase.
410
411 If the client <fee:command> contains a phase attribute with no
412 subphase and the server has more than one active subphase combination
413 of this phase, the server MUST respond with a 2003 "Required
414 parameter missing" error.
415
416 If the client <fee:command> contains a subphase with no phase
417 attribute, the server MUST respond with a 2003 "Required parameter
418 missing" error.
419
420 If the client <fee:command> contains a phase attribute not defined in
421 [RFC8334] or not supported by the server, the server MUST respond
422 with a 2004 "Parameter value range error".
423
424 If the client <fee:command> contains a subphase attribute (or phase/
425 subphase combination) not supported by the server, the server MUST
426 respond with a 2004 "Parameter value range error".
427
428 3.9. Reason
429
430 The <fee:reason> element is used to provide server-specific text in
431 an effort to better explain why a <check> command did not complete as
432 the client expected. An OPTIONAL "lang" attribute MAY be present to
433 identify the language, per the language structure in [RFC5646], of
434 the returned text and has a default value of "en" (English).
435
436 The <fee:reason> element can be used within the server response
437 <fee:command> element or within the <fee:cd> element. See
438 Section 5.1.1 for details on the <fee:cd> "check data" element.
439
440 If the server cannot calculate the relevant fees because the object,
441 command, currency, period, class, or some combination is invalid per
442 server policy, the server has two ways of handling the error
443 processing of <fee:command> element(s):
444
445 1. Fast-fail: The server, upon error identification, MAY stop
446 processing <fee:command> elements and return a <fee:cd> to the
447 client containing the <fee:objID> and a <fee:reason> element
448 detailing the reason for failure.
449
450 S: <fee:cd avail="0">
451 S: <fee:objID>example.xyz</fee:objID>
452 S: <fee:reason>Only 1 year registration periods are
453 S: valid.</fee:reason>
454 S: </fee:cd>
455
456 2. Partial-fail: The server, upon error identification, MAY continue
457 processing <fee:command> elements and return a <fee:cd> to the
458 client containing the successfully processed <fee:command>
459 elements and failed <fee:command> elements. All returned failed
460 <fee:command> elements MUST have a <fee:reason> element detailing
461 the reason for failure, and the server MAY additionally include a
462 <fee:reason> element at the <fee:cd> level.
463
464 S: <fee:cd avail="0">
465 S: <fee:objID>example.xyz</fee:objID>
466 S: <fee:command name="create">
467 S: <fee:period unit="y">2</fee:period>
468 S: <fee:reason>Only 1 year registration periods are
469 S: valid.</fee:reason>
470 S: </fee:command>
471 S: </fee:cd>
472
473 In either failure scenario, the server MUST set the <fee:cd> "avail"
474 attribute to false (0), and the server MUST process all objects in
475 the client request.
476
477 4. Server Handling of Fee Information
478
479 Depending on the server policy, a client MAY be required to include
480 the extension elements described in this document for certain
481 transform commands. Servers must provide clear documentation to
482 clients about the circumstances in which this extension must be used.
483
484 The server MUST return avail="0" in its response to a <check> command
485 for any object in the <check> command that does not include the
486 <fee:check> extension where the server would fail a domain <create>
487 command when no <fee> extension is provided for that same object.
488
489 If a server receives a <check> command from a client that results in
490 no possible fee combination, the server MUST set the "avail"
491 attribute of the <fee:cd> element to false (0) and provide a
492 <fee:reason>.
493
494 If a server receives a <check> command from a client that results in
495 an ambiguous result (i.e., multiple possible fee combinations), the
496 server MUST reject the command with a 2003 "Required parameter
497 missing" error.
498
499 If a server receives a command from a client that does not include
500 the fee extension data elements required by the server for that
501 command, then the server MUST respond with a 2003 "Required parameter
502 missing" error.
503
504 If the total fee provided by the client is less than the server's own
505 calculation of the fee or the server determines the currency is
506 inappropriate for that command, then the server MUST reject the
507 command with a 2004 "Parameter value range error".
508
509 5. EPP Command Mapping
510
511 A detailed description of the EPP syntax and semantics can be found
512 in [RFC5730].
513
514 5.1. EPP Query Commands
515
516 This extension does not add any elements to the EPP <poll> or <info>
517 commands or responses.
518
519 5.1.1. EPP <check> Command
520
521 This extension defines a new command called the Fee Check Command
522 that defines additional elements for the EPP <check> command to
523 provide fee information.
524
525 The command MAY contain an <extension> element, which MAY contain a
526 <fee:check> element. The <fee:check> element MAY contain one
527 <fee:currency> element and MUST contain one or more <fee:command>
528 elements.
529
530 The <fee:command> element(s) MUST contain a "name" attribute (see
531 Section 3.1), an OPTIONAL "phase" attribute, and an OPTIONAL
532 "subphase" attribute (see Section 3.8). The <fee:command> element(s)
533 MAY have the following child elements:
534
535 * An OPTIONAL <fee:period> element (as described in Section 3.3).
536
537 Example <check> command:
538
539 C: <?xml version="1.0" encoding="utf-8" standalone="no"?>
540 C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
541 C: <command>
542 C: <check>
543 C: <domain:check
544 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
545 C: <domain:name>example.com</domain:name>
546 C: <domain:name>example.net</domain:name>
547 C: <domain:name>example.xyz</domain:name>
548 C: </domain:check>
549 C: </check>
550 C: <extension>
551 C: <fee:check xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
552 C: <fee:currency>USD</fee:currency>
553 C: <fee:command name="create">
554 C: <fee:period unit="y">2</fee:period>
555 C: </fee:command>
556 C: <fee:command name="renew"/>
557 C: <fee:command name="transfer"/>
558 C: <fee:command name="restore"/>
559 C: </fee:check>
560 C: </extension>
561 C: <clTRID>ABC-12345</clTRID>
562 C: </command>
563 C: </epp>
564
565 When the server receives a <check> command that includes the
566 extension elements described above, its response MUST contain an
567 <extension> element, which MUST contain a child <fee:chkData>
568 element. The <fee:chkData> element MUST contain a <fee:currency>
569 element and a <fee:cd> element for each object referenced in the
570 client <check> command.
571
572 Each <fee:cd> (check data) element MUST contain the following child
573 elements:
574
575 * A <fee:objID> element, which MUST match an element referenced in
576 the client <check> command.
577
578 * An OPTIONAL <fee:class> element (as described in Section 3.7).
579
580 * A <fee:command> element matching each <fee:command> (unless the
581 "avail" attribute of the <fee:cd> is false) that appeared in the
582 corresponding <fee:check> of the client command. This element MAY
583 have the OPTIONAL "standard" attribute, with a default value of
584 "0" (or "false"), which indicates whether the fee is the standard
585 or default fee (see Section 3.7). This element MAY have the
586 OPTIONAL "phase" and "subphase" attributes, which will match the
587 same attributes in the corresponding <fee:command> element of the
588 client command if sent by the client.
589
590 The <fee:cd> element also has an OPTIONAL "avail" attribute, which is
591 a boolean. If the value of this attribute evaluates to false, this
592 indicates that the server cannot calculate the relevant fees because
593 the object, command, currency, period, class, or some combination is
594 invalid per server policy. If "avail" is false, then the <fee:cd> or
595 the <fee:command> element MUST contain a <fee:reason> element (as
596 described in Section 3.9), and the server MAY eliminate some or all
597 of the <fee:command> element(s).
598
599 The <fee:command> element(s) MAY have the following child elements:
600
601 * An OPTIONAL <fee:period> element (as described in Section 3.3),
602 which contains the same unit, if present, that appeared in the
603 <fee:period> element of the command. If the value of the parent
604 <fee:command> element is "restore", this element MUST NOT be
605 included; otherwise, it MUST be included. If no <fee:period>
606 appeared in the client command (and the command is not "restore"),
607 then the server MUST return its default period value.
608
609 * Zero or more <fee:fee> elements (as described in Section 3.4).
610
611 * Zero or more <fee:credit> elements (as described in Section 3.4).
612
613 * An OPTIONAL <fee:reason> element (as described in Section 3.9).
614
615 If the "avail" attribute of the <fee:cd> element is true (1) and if
616 no <fee:fee> elements are present in a <fee:command> element, this
617 indicates that no fee will be assessed by the server for this
618 command.
619
620 If the "avail" attribute of the <fee:cd> element is true (1), then
621 the <fee:command> element MUST NOT contain a <fee:reason> element.
622
623 Example <check> response:
624
625 S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
626 S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
627 S: <response>
628 S: <result code="1000">
629 S: <msg>Command completed successfully</msg>
630 S: </result>
631 S: <resData>
632 S: <domain:chkData
633 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
634 S: <domain:cd>
635 S: <domain:name avail="1">example.com</domain:name>
636 S: </domain:cd>
637 S: <domain:cd>
638 S: <domain:name avail="1">example.net</domain:name>
639 S: </domain:cd>
640 S: <domain:cd>
641 S: <domain:name avail="1">example.xyz</domain:name>
642 S: </domain:cd>
643 S: </domain:chkData>
644 S: </resData>
645 S: <extension>
646 S: <fee:chkData
647 S: xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
648 S: <fee:currency>USD</fee:currency>
649 S: <fee:cd avail="1">
650 S: <fee:objID>example.com</fee:objID>
651 S: <fee:class>Premium</fee:class>
652 S: <fee:command name="create">
653 S: <fee:period unit="y">2</fee:period>
654 S: <fee:fee
655 S: description="Registration Fee"
656 S: refundable="1"
657 S: grace-period="P5D">10.00</fee:fee>
658 S: </fee:command>
659 S: <fee:command name="renew">
660 S: <fee:period unit="y">1</fee:period>
661 S: <fee:fee
662 S: description="Renewal Fee"
663 S: refundable="1"
664 S: grace-period="P5D">10.00</fee:fee>
665 S: </fee:command>
666 S: <fee:command name="transfer">
667 S: <fee:period unit="y">1</fee:period>
668 S: <fee:fee
669 S: description="Transfer Fee"
670 S: refundable="1"
671 S: grace-period="P5D">10.00</fee:fee>
672 S: </fee:command>
673 S: <fee:command name="restore">
674 S: <fee:fee
675 S: description="Redemption Fee">15.00</fee:fee>
676 S: </fee:command>
677 S: </fee:cd>
678 S: <fee:cd avail="1">
679 S: <fee:objID>example.net</fee:objID>
680 S: <fee:class>standard</fee:class>
681 S: <fee:command name="create" standard="1">
682 S: <fee:period unit="y">2</fee:period>
683 S: <fee:fee
684 S: description="Registration Fee"
685 S: refundable="1"
686 S: grace-period="P5D">5.00</fee:fee>
687 S: </fee:command>
688 S: <fee:command name="renew" standard="1">
689 S: <fee:period unit="y">1</fee:period>
690 S: <fee:fee
691 S: description="Renewal Fee"
692 S: refundable="1"
693 S: grace-period="P5D">5.00</fee:fee>
694 S: </fee:command>
695 S: <fee:command name="transfer" standard="1">
696 S: <fee:period unit="y">1</fee:period>
697 S: <fee:fee
698 S: description="Transfer Fee"
699 S: refundable="1"
700 S: grace-period="P5D">5.00</fee:fee>
701 S: </fee:command>
702 S: <fee:command name="restore" standard="1">
703 S: <fee:fee
704 S: description="Redemption Fee">5.00</fee:fee>
705 S: </fee:command>
706 S: </fee:cd>
707 S: <fee:cd avail="0">
708 S: <fee:objID>example.xyz</fee:objID>
709 S: <fee:command name="create">
710 S: <fee:period unit="y">2</fee:period>
711 S: <fee:reason>Only 1 year registration periods are
712 S: valid.</fee:reason>
713 S: </fee:command>
714 S: </fee:cd>
715 S: </fee:chkData>
716 S: </extension>
717 S: <trID>
718 S: <clTRID>ABC-12345</clTRID>
719 S: <svTRID>54322-XYZ</svTRID>
720 S: </trID>
721 S: </response>
722 S: </epp>
723
724 5.1.2. EPP Transfer Query Command
725
726 This extension does not add any elements to the EPP <transfer> query
727 command, but it does include elements in the response when the
728 extension is included in the <login> command service extensions.
729
730 When the <transfer> query command has been processed successfully, if
731 the client has included the extension in the <login> command service
732 <svcExtension> element, and if the client is authorized by the server
733 to view information about the transfer, then the server MAY include
734 in the <extension> section of the EPP response a <fee:trnData>
735 element, which contains the following child elements:
736
737 * A <fee:currency> element (as described in Section 3.2).
738
739 * A <fee:period> element (as described in Section 3.3).
740
741 * Zero or more <fee:fee> elements (as described in Section 3.4)
742 containing the fees that will be charged to the gaining client.
743
744 * Zero or more <fee:credit> elements (as described in Section 3.4)
745 containing the credits that will be refunded to the losing client.
746
747 Servers SHOULD omit <fee:credit> when returning a response to the
748 gaining client and omit <fee:fee> elements when returning a response
749 to the losing client.
750
751 If no <fee:trnData> element is included in the response, then no fee
752 will be assessed by the server for the transfer.
753
754 Example <transfer> query response:
755
756 S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
757 S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
758 S: <response>
759 S: <result code="1001">
760 S: <msg>Command completed successfully; action pending</msg>
761 S: </result>
762 S: <resData>
763 S: <domain:trnData
764 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
765 S: <domain:name>example.com</domain:name>
766 S: <domain:trStatus>pending</domain:trStatus>
767 S: <domain:reID>ClientX</domain:reID>
768 S: <domain:reDate>2019-06-08T22:00:00.0Z</domain:reDate>
769 S: <domain:acID>ClientY</domain:acID>
770 S: <domain:acDate>2019-06-13T22:00:00.0Z</domain:acDate>
771 S: <domain:exDate>2021-09-08T22:00:00.0Z</domain:exDate>
772 S: </domain:trnData>
773 S: </resData>
774 S: <extension>
775 S: <fee:trnData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
776 S: <fee:currency>USD</fee:currency>
777 S: <fee:period unit="y">1</fee:period>
778 S: <fee:fee>5.00</fee:fee>
779 S: </fee:trnData>
780 S: </extension>
781 S: <trID>
782 S: <clTRID>ABC-12345</clTRID>
783 S: <svTRID>54322-XYZ</svTRID>
784 S: </trID>
785 S: </response>
786 S: </epp>
787
788 5.2. EPP Transform Commands
789
790 5.2.1. EPP <create> Command
791
792 This extension adds elements to both the EPP <create> command and
793 response when the extension is included in the <login> command
794 service extensions.
795
796 When submitting a <create> command to the server, the client MAY
797 include in the <extension> element a <fee:create> element, which
798 includes the following child elements:
799
800 * An OPTIONAL <fee:currency> element (as described in Section 3.2).
801
802 * One or more <fee:fee> elements (as described in Section 3.4).
803
804 When the <create> command has been processed successfully, the client
805 included the extension in the <login> command service extensions, and
806 a fee was assessed by the server for the transaction, the server MUST
807 include in the <extension> section of the EPP response a
808 <fee:creData> element, which contains the following child elements:
809
810 * A <fee:currency> element (as described in Section 3.2).
811
812 * Zero or more <fee:fee> elements (as described in Section 3.4).
813
814 * Zero or more <fee:credit> elements (as described in Section 3.4).
815
816 * An OPTIONAL <fee:balance> element (as described in Section 3.5).
817
818 * An OPTIONAL <fee:creditLimit> element (as described in
819 Section 3.6).
820
821 Example <create> command:
822
823 C: <?xml version="1.0" encoding="utf-8" standalone="no"?>
824 C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
825 C: <command>
826 C: <create>
827 C: <domain:create
828 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
829 C: <domain:name>example.com</domain:name>
830 C: <domain:period unit="y">2</domain:period>
831 C: <domain:ns>
832 C: <domain:hostObj>ns1.example.net</domain:hostObj>
833 C: <domain:hostObj>ns2.example.net</domain:hostObj>
834 C: </domain:ns>
835 C: <domain:registrant>jd1234</domain:registrant>
836 C: <domain:contact type="admin">sh8013</domain:contact>
837 C: <domain:contact type="tech">sh8013</domain:contact>
838 C: <domain:authInfo>
839 C: <domain:pw>2fooBAR</domain:pw>
840 C: </domain:authInfo>
841 C: </domain:create>
842 C: </create>
843 C: <extension>
844 C: <fee:create xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
845 C: <fee:currency>USD</fee:currency>
846 C: <fee:fee>5.00</fee:fee>
847 C: </fee:create>
848 C: </extension>
849 C: <clTRID>ABC-12345</clTRID>
850 C: </command>
851 C: </epp>
852
853 Example <create> response:
854
855 S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
856 S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
857 S: <response>
858 S: <result code="1000">
859 S: <msg>Command completed successfully</msg>
860 S: </result>
861 S: <resData>
862 S: <domain:creData
863 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
864 S: <domain:name>example.com</domain:name>
865 S: <domain:crDate>2019-04-03T22:00:00.0Z</domain:crDate>
866 S: <domain:exDate>2021-04-03T22:00:00.0Z</domain:exDate>
867 S: </domain:creData>
868 S: </resData>
869 S: <extension>
870 S: <fee:creData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
871 S: <fee:currency>USD</fee:currency>
872 S: <fee:fee
873 S: description="Registration Fee"
874 S: lang="en"
875 S: refundable="1"
876 S: grace-period="P5D">5.00</fee:fee>
877 S: <fee:balance>-5.00</fee:balance>
878 S: <fee:creditLimit>1000.00</fee:creditLimit>
879 S: </fee:creData>
880 S: </extension>
881 S: <trID>
882 S: <clTRID>ABC-12345</clTRID>
883 S: <svTRID>54321-XYZ</svTRID>
884 S: </trID>
885 S: </response>
886 S: </epp>
887
888 5.2.2. EPP <delete> Command
889
890 This extension does not add any elements to the EPP <delete> command,
891 but it does include elements in the response when the extension is
892 included in the <login> command service extensions.
893
894 When the <delete> command has been processed successfully and the
895 client included the extension in the <login> command service
896 extensions, the server MAY include in the <extension> section of the
897 EPP response a <fee:delData> element, which contains the following
898 child elements:
899
900 * A <fee:currency> element (as described in Section 3.2).
901
902 * Zero or more <fee:fee> elements (as described in Section 3.4).
903
904 * Zero or more <fee:credit> elements (as described in Section 3.4).
905
906 * An OPTIONAL <fee:balance> element (as described in Section 3.5).
907
908 * An OPTIONAL <fee:creditLimit> element (as described in
909 Section 3.6).
910
911 Example <delete> response:
912
913 S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
914 S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
915 S: <response>
916 S: <result code="1000">
917 S: <msg>Command completed successfully</msg>
918 S: </result>
919 S: <extension>
920 S: <fee:delData
921 S: xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
922 S: <fee:currency>USD</fee:currency>
923 S: <fee:credit
924 S: description="AGP Credit"
925 S: lang="en">-5.00</fee:credit>
926 S: <fee:balance>1005.00</fee:balance>
927 S: </fee:delData>
928 S: </extension>
929 S: <trID>
930 S: <clTRID>ABC-12345</clTRID>
931 S: <svTRID>54321-XYZ</svTRID>
932 S: </trID>
933 S: </response>
934 S: </epp>
935
936 5.2.3. EPP <renew> Command
937
938 This extension adds elements to both the EPP <renew> command and
939 response when the extension is included in the <login> command
940 service extensions.
941
942 When submitting a <renew> command to the server, the client MAY
943 include in the <extension> element a <fee:renew> element, which
944 includes the following child elements:
945
946 * An OPTIONAL <fee:currency> element (as described in Section 3.2).
947
948 * One or more <fee:fee> elements (as described in Section 3.4).
949
950 When the <renew> command has been processed successfully and the
951 client included the extension in the <login> command service
952 extensions, the server MAY include in the <extension> section of the
953 EPP response a <fee:renData> element, which contains the following
954 child elements:
955
956 * A <fee:currency> element (as described in Section 3.2).
957
958 * Zero or more <fee:fee> elements (as described in Section 3.4).
959
960 * Zero or more <fee:credit> elements (as described in Section 3.4).
961
962 * An OPTIONAL <fee:balance> element (as described in Section 3.5).
963
964 * An OPTIONAL <fee:creditLimit> element (as described in
965 Section 3.6).
966
967 Example <renew> command:
968
969 C: <?xml version="1.0" encoding="utf-8" standalone="no"?>
970 C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
971 C: <command>
972 C: <renew>
973 C: <domain:renew
974 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
975 C: <domain:name>example.com</domain:name>
976 C: <domain:curExpDate>2019-04-03</domain:curExpDate>
977 C: <domain:period unit="y">5</domain:period>
978 C: </domain:renew>
979 C: </renew>
980 C: <extension>
981 C: <fee:renew xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
982 C: <fee:currency>USD</fee:currency>
983 C: <fee:fee>5.00</fee:fee>
984 C: </fee:renew>
985 C: </extension>
986 C: <clTRID>ABC-12345</clTRID>
987 C: </command>
988 C: </epp>
989
990 Example <renew> response:
991
992 S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
993 S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
994 S: <response>
995 S: <result code="1000">
996 S: <msg>Command completed successfully</msg>
997 S: </result>
998 S: <resData>
999 S: <domain:renData
1000 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
1001 S: <domain:name>example.com</domain:name>
1002 S: <domain:exDate>2024-04-03T22:00:00.0Z</domain:exDate>
1003 S: </domain:renData>
1004 S: </resData>
1005 S: <extension>
1006 S: <fee:renData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
1007 S: <fee:currency>USD</fee:currency>
1008 S: <fee:fee
1009 S: refundable="1"
1010 S: grace-period="P5D">5.00</fee:fee>
1011 S: <fee:balance>1000.00</fee:balance>
1012 S: </fee:renData>
1013 S: </extension>
1014 S: <trID>
1015 S: <clTRID>ABC-12345</clTRID>
1016 S: <svTRID>54322-XYZ</svTRID>
1017 S: </trID>
1018 S: </response>
1019 S: </epp>
1020
1021 5.2.4. EPP <transfer> Command
1022
1023 This extension adds elements to both the EPP <transfer> command and
1024 response when the value of the "op" attribute of the <transfer>
1025 command element is "request" and the extension is included in the
1026 <login> command service extensions.
1027
1028 When submitting a <transfer> command to the server, the client MAY
1029 include in the <extension> element a <fee:transfer> element, which
1030 includes the following child elements:
1031
1032 * An OPTIONAL <fee:currency> element (as described in Section 3.2).
1033
1034 * One or more <fee:fee> elements (as described in Section 3.4).
1035
1036 When the <transfer> command has been processed successfully and the
1037 client included the extension in the <login> command service
1038 extensions, the server MAY include in the <extension> section of the
1039 EPP response a <fee:trnData> element, which contains the following
1040 child elements:
1041
1042 * A <fee:currency> element (as described in Section 3.2).
1043
1044 * Zero or more <fee:fee> elements (as described in Section 3.4).
1045
1046 * Zero or more <fee:credit> elements (as described in Section 3.4).
1047
1048 * An OPTIONAL <fee:balance> element (as described in Section 3.5).
1049
1050 * An OPTIONAL <fee:creditLimit> element (as described in
1051 Section 3.6).
1052
1053 Example <transfer> command:
1054
1055 C: <?xml version="1.0" encoding="utf-8" standalone="no"?>
1056 C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1057 C: <command>
1058 C: <transfer op="request">
1059 C: <domain:transfer
1060 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
1061 C: <domain:name>example.com</domain:name>
1062 C: <domain:period unit="y">1</domain:period>
1063 C: <domain:authInfo>
1064 C: <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
1065 C: </domain:authInfo>
1066 C: </domain:transfer>
1067 C: </transfer>
1068 C: <extension>
1069 C: <fee:transfer xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
1070 C: <fee:currency>USD</fee:currency>
1071 C: <fee:fee>5.00</fee:fee>
1072 C: </fee:transfer>
1073 C: </extension>
1074 C: <clTRID>ABC-12345</clTRID>
1075 C: </command>
1076 C: </epp>
1077
1078 Example <transfer> response:
1079
1080 S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
1081 S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1082 S: <response>
1083 S: <result code="1001">
1084 S: <msg>Command completed successfully; action pending</msg>
1085 S: </result>
1086 S: <resData>
1087 S: <domain:trnData
1088 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
1089 S: <domain:name>example.com</domain:name>
1090 S: <domain:trStatus>pending</domain:trStatus>
1091 S: <domain:reID>ClientX</domain:reID>
1092 S: <domain:reDate>2019-06-08T22:00:00.0Z</domain:reDate>
1093 S: <domain:acID>ClientY</domain:acID>
1094 S: <domain:acDate>2019-06-13T22:00:00.0Z</domain:acDate>
1095 S: <domain:exDate>2021-09-08T22:00:00.0Z</domain:exDate>
1096 S: </domain:trnData>
1097 S: </resData>
1098 S: <extension>
1099 S: <fee:trnData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
1100 S: <fee:currency>USD</fee:currency>
1101 S: <fee:fee
1102 S: refundable="1"
1103 S: grace-period="P5D">5.00</fee:fee>
1104 S: </fee:trnData>
1105 S: </extension>
1106 S: <trID>
1107 S: <clTRID>ABC-12345</clTRID>
1108 S: <svTRID>54322-XYZ</svTRID>
1109 S: </trID>
1110 S: </response>
1111 S: </epp>
1112
1113 5.2.5. EPP <update> Command
1114
1115 This extension adds elements to both the EPP <update> command and
1116 response when the extension is included in the <login> command
1117 service extensions.
1118
1119 When submitting an <update> command to the server, the client MAY
1120 include in the <extension> element a <fee:update> element, which
1121 includes the following child elements:
1122
1123 * An OPTIONAL <fee:currency> element (as described in Section 3.2).
1124
1125 * One or more <fee:fee> elements (as described in Section 3.4).
1126
1127 When the <update> command has been processed successfully and the
1128 client included the extension in the <login> command service
1129 extensions, the server MAY include in the <extension> section of the
1130 EPP response a <fee:updData> element, which contains the following
1131 child elements:
1132
1133 * A <fee:currency> element (as described in Section 3.2).
1134
1135 * Zero or more <fee:fee> elements (as described in Section 3.4).
1136
1137 * Zero or more <fee:credit> elements (as described in Section 3.4).
1138
1139 * An OPTIONAL <fee:balance> element (as described in Section 3.5).
1140
1141 * An OPTIONAL <fee:creditLimit> element (as described in
1142 Section 3.6).
1143
1144 Example <update> command:
1145
1146 C: <?xml version="1.0" encoding="utf-8" standalone="no"?>
1147 C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1148 C: <command>
1149 C: <update>
1150 C: <domain:update
1151 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
1152 C: <domain:name>example.com</domain:name>
1153 C: <domain:chg>
1154 C: <domain:registrant>sh8013</domain:registrant>
1155 C: </domain:chg>
1156 C: </domain:update>
1157 C: </update>
1158 C: <extension>
1159 C: <fee:update xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
1160 C: <fee:currency>USD</fee:currency>
1161 C: <fee:fee>5.00</fee:fee>
1162 C: </fee:update>
1163 C: </extension>
1164 C: <clTRID>ABC-12345</clTRID>
1165 C: </command>
1166 C: </epp>
1167
1168 Example <update> response:
1169
1170 S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
1171 S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1172 S: <response>
1173 S: <result code="1000">
1174 S: <msg>Command completed successfully</msg>
1175 S: </result>
1176 S: <extension>
1177 S: <fee:updData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
1178 S: <fee:currency>USD</fee:currency>
1179 S: <fee:fee>5.00</fee:fee>
1180 S: </fee:updData>
1181 S: </extension>
1182 S: <trID>
1183 S: <clTRID>ABC-12345</clTRID>
1184 S: <svTRID>54321-XYZ</svTRID>
1185 S: </trID>
1186 S: </response>
1187 S: </epp>
1188
1189 6. Formal Syntax
1190
1191 One schema is presented here -- the EPP Fee Extension schema.
1192
1193 The formal syntax presented here is a complete schema representation
1194 of the object mapping suitable for automated validation of EPP XML
1195 instances.
1196
1197 6.1. Fee Extension Schema
1198
1199 The formal syntax presented here is a complete schema representation
1200 [W3C.REC-xmlschema-1-20041028] of the object mapping suitable for
1201 automated validation of EPP XML instances. The <CODE BEGINS> and
1202 <CODE ENDS> tags are not part of the schema; they are used to note
1203 the beginning and end of the schema for URI registration purposes.
1204
1205 <CODE BEGINS>
1206 <?xml version="1.0" encoding="utf-8"?>
1207 <schema xmlns="http://www.w3.org/2001/XMLSchema"
1208 xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"
1209 xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
1210 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
1211 targetNamespace="urn:ietf:params:xml:ns:epp:fee-1.0"
1212 elementFormDefault="qualified">
1213
1214 <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
1215 <import namespace="urn:ietf:params:xml:ns:domain-1.0" />
1216
1217 <annotation>
1218 <documentation>
1219 Extensible Provisioning Protocol v1.0 Fee Extension
1220 </documentation>
1221 </annotation>
1222
1223 <!-- Child elements found in EPP commands and responses -->
1224 <element name="check" type="fee:checkType" />
1225 <element name="chkData" type="fee:chkDataType" />
1226 <element name="create" type="fee:transformCommandType" />
1227 <element name="creData" type="fee:transformResultType" />
1228 <element name="renew" type="fee:transformCommandType" />
1229 <element name="renData" type="fee:transformResultType" />
1230 <element name="transfer" type="fee:transformCommandType" />
1231 <element name="trnData" type="fee:transformResultType" />
1232 <element name="update" type="fee:transformCommandType" />
1233 <element name="updData" type="fee:transformResultType" />
1234 <element name="delData" type="fee:transformResultType" />
1235
1236 <!-- client <check> command -->
1237 <complexType name="checkType">
1238 <sequence>
1239 <element name="currency" type="fee:currencyType"
1240 minOccurs="0" />
1241 <element name="command" type="fee:commandType"
1242 minOccurs="1" maxOccurs="unbounded" />
1243 </sequence>
1244 </complexType>
1245
1246 <complexType name="objectIdentifierType">
1247 <simpleContent>
1248 <extension base="eppcom:labelType">
1249 <attribute name="element"
1250 type="NMTOKEN" default="name" />
1251 </extension>
1252 </simpleContent>
1253 </complexType>
1254
1255 <!-- server <check> result -->
1256 <complexType name="chkDataType">
1257 <sequence>
1258 <element name="currency" type="fee:currencyType" />
1259 <element name="cd" type="fee:objectCDType"
1260 maxOccurs="unbounded" />
1261 </sequence>
1262 </complexType>
1263
1264 <complexType name="objectCDType">
1265 <sequence>
1266 <element name="objID" type="fee:objectIdentifierType" />
1267 <element name="class" type="token" minOccurs="0" />
1268 <element name="command" type="fee:commandDataType"
1269 minOccurs="0" maxOccurs="unbounded" />
1270 <element name="reason" type="fee:reasonType" minOccurs="0" />
1271 </sequence>
1272 <attribute name="avail" type="boolean" default="1" />
1273 </complexType>
1274
1275 <!-- general transform (create, renew, update, transfer) command-->
1276 <complexType name="transformCommandType">
1277 <sequence>
1278 <element name="currency" type="fee:currencyType"
1279 minOccurs="0" />
1280 <element name="fee" type="fee:feeType"
1281 maxOccurs="unbounded" />
1282 <element name="credit" type="fee:creditType"
1283 minOccurs="0" maxOccurs="unbounded" />
1284 </sequence>
1285 </complexType>
1286
1287 <!-- general transform (create, renew, update) result -->
1288 <complexType name="transformResultType">
1289 <sequence>
1290 <element name="currency" type="fee:currencyType"
1291 minOccurs="0" />
1292 <element name="period" type="domain:periodType"
1293 minOccurs="0" />
1294 <element name="fee" type="fee:feeType"
1295 minOccurs="0" maxOccurs="unbounded" />
1296 <element name="credit" type="fee:creditType"
1297 minOccurs="0" maxOccurs="unbounded" />
1298 <element name="balance" type="fee:balanceType"
1299 minOccurs="0" />
1300 <element name="creditLimit" type="fee:creditLimitType"
1301 minOccurs="0" />
1302 </sequence>
1303 </complexType>
1304
1305 <!-- common types -->
1306 <simpleType name="currencyType">
1307 <restriction base="string">
1308 <pattern value="[A-Z]{3}" />
1309 </restriction>
1310 </simpleType>
1311
1312 <complexType name="commandType">
1313 <sequence>
1314 <element name="period" type="domain:periodType"
1315 minOccurs="0" maxOccurs="1" />
1316 </sequence>
1317 <attribute name="name" type="fee:commandEnum" use="required"/>
1318 <attribute name="customName" type="token"/>
1319 <attribute name="phase" type="token" />
1320 <attribute name="subphase" type="token" />
1321 </complexType>
1322
1323 <complexType name="commandDataType">
1324 <complexContent>
1325 <extension base="fee:commandType">
1326 <sequence>
1327 <element name="fee" type="fee:feeType"
1328 minOccurs="0" maxOccurs="unbounded" />
1329 <element name="credit" type="fee:creditType"
1330 minOccurs="0" maxOccurs="unbounded" />
1331 <element name="reason" type="fee:reasonType"
1332 minOccurs="0" />
1333 </sequence>
1334 <attribute name="standard" type="boolean" default="0" />
1335 </extension>
1336 </complexContent>
1337 </complexType>
1338
1339 <complexType name="reasonType">
1340 <simpleContent>
1341 <extension base="token">
1342 <attribute name="lang" type="language" default="en"/>
1343 </extension>
1344 </simpleContent>
1345 </complexType>
1346
1347 <simpleType name="commandEnum">
1348 <restriction base="token">
1349 <enumeration value="create"/>
1350 <enumeration value="delete"/>
1351 <enumeration value="renew"/>
1352 <enumeration value="update"/>
1353 <enumeration value="transfer"/>
1354 <enumeration value="restore"/>
1355 <enumeration value="custom"/>
1356 </restriction>
1357 </simpleType>
1358
1359 <simpleType name="nonNegativeDecimal">
1360 <restriction base="decimal">
1361 <minInclusive value="0" />
1362 </restriction>
1363 </simpleType>
1364
1365 <simpleType name="negativeDecimal">
1366 <restriction base="decimal">
1367 <maxInclusive value="0" />
1368 </restriction>
1369 </simpleType>
1370
1371 <complexType name="feeType">
1372 <simpleContent>
1373 <extension base="fee:nonNegativeDecimal">
1374 <attribute name="description"/>
1375 <attribute name="lang" type="language" default="en"/>
1376 <attribute name="refundable" type="boolean" />
1377 <attribute name="grace-period" type="duration" />
1378 <attribute name="applied">
1379 <simpleType>
1380 <restriction base="token">
1381 <enumeration value="immediate" />
1382 <enumeration value="delayed" />
1383 </restriction>
1384 </simpleType>
1385 </attribute>
1386 </extension>
1387 </simpleContent>
1388 </complexType>
1389
1390 <complexType name="creditType">
1391 <simpleContent>
1392 <extension base="fee:negativeDecimal">
1393 <attribute name="description"/>
1394 <attribute name="lang" type="language" default="en"/>
1395 </extension>
1396 </simpleContent>
1397 </complexType>
1398
1399 <simpleType name="balanceType">
1400 <restriction base="decimal" />
1401 </simpleType>
1402
1403 <simpleType name="creditLimitType">
1404 <restriction base="decimal" />
1405 </simpleType>
1406
1407 </schema>
1408 <CODE ENDS>
1409
1410 7. Security Considerations
1411
1412 The mapping extensions described in this document do not provide any
1413 security services beyond those described by the EPP [RFC5730], the
1414 EPP domain name mapping [RFC5731], and the protocol layers used by
1415 the EPP. The security considerations described in these other
1416 specifications apply to this specification as well. This extension
1417 passes financial information using the EPP protocol, so
1418 confidentiality and integrity protection must be provided by the
1419 transport mechanism. All transports compliant with [RFC5730] provide
1420 the needed level of confidentiality and integrity protections. The
1421 server will only provide information, including financial
1422 information, that is relevant to the authenticated client.
1423
1424 8. IANA Considerations
1425
1426 8.1. XML Namespace
1427
1428 This document uses URNs to describe XML namespaces and XML schemas
1429 conforming to a registry mechanism described in [RFC3688].
1430
1431 Registration request for the fee namespace:
1432
1433 URI: urn:ietf:params:xml:ns:epp:fee-1.0
1434
1435 Registrant Contact: IESG
1436
1437 XML: None. Namespace URIs do not represent an XML specification.
1438
1439 Registration request for the fee schema:
1440
1441 URI: urn:ietf:params:xml:schema:epp:fee-1.0
1442
1443 Registrant Contact: IESG
1444
1445 XML: See Section 6 of this document.
1446
1447 8.2. EPP Extension Registry
1448
1449 The EPP extension described in this document has been registered by
1450 IANA in the "Extensions for the Extensible Provisioning Protocol
1451 (EPP)" registry described in [RFC7451]. The details of the
1452 registration are as follows:
1453
1454 Name of Extension: Registry Fee Extension for the Extensible
1455 Provisioning Protocol (EPP)
1456
1457 Document status: Standards Track
1458
1459 Reference: RFC 8748
1460
1461 Registrant Name and Email Address: IESG <iesg@ietf.org>
1462
1463 TLDs: Any
1464
1465 IPR Disclosure: None
1466
1467 Status: Active
1468
1469 Notes: None
1470
1471 9. References
1472
1473 9.1. Normative References
1474
1475 [ISO4217_2015]
1476 ISO, "Codes for the representation of currencies",
1477 ISO 4217:2015, August 2015,
1478 <https://www.iso.org/standard/64758.html>.
1479
1480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1481 Requirement Levels", BCP 14, RFC 2119,
1482 DOI 10.17487/RFC2119, March 1997,
1483 <https://www.rfc-editor.org/info/rfc2119>.
1484
1485 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1486 DOI 10.17487/RFC3688, January 2004,
1487 <https://www.rfc-editor.org/info/rfc3688>.
1488
1489 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for
1490 the Extensible Provisioning Protocol (EPP)", RFC 3915,
1491 DOI 10.17487/RFC3915, September 2004,
1492 <https://www.rfc-editor.org/info/rfc3915>.
1493
1494 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
1495 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
1496 September 2009, <https://www.rfc-editor.org/info/rfc5646>.
1497
1498 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
1499 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
1500 <https://www.rfc-editor.org/info/rfc5730>.
1501
1502 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
1503 Domain Name Mapping", STD 69, RFC 5731,
1504 DOI 10.17487/RFC5731, August 2009,
1505 <https://www.rfc-editor.org/info/rfc5731>.
1506
1507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1508 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1509 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1510
1511 [RFC8334] Gould, J., Tan, W., and G. Brown, "Launch Phase Mapping
1512 for the Extensible Provisioning Protocol (EPP)", RFC 8334,
1513 DOI 10.17487/RFC8334, March 2018,
1514 <https://www.rfc-editor.org/info/rfc8334>.
1515
1516 [W3C.REC-xmlschema-1-20041028]
1517 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
1518 "XML Schema Part 1: Structures Second Edition", World Wide
1519 Web Consortium Recommendation REC-xmlschema-1-20041028,
1520 October 2004,
1521 <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
1522
1523 9.2. Informative References
1524
1525 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
1526 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
1527 February 2015, <https://www.rfc-editor.org/info/rfc7451>.
1528
1529 Acknowledgements
1530
1531 The authors wish to thank the following persons for their feedback
1532 and suggestions:
1533
1534 * James Gould of Verisign Inc.
1535 * Luis Munoz of ISC
1536 * Michael Young
1537 * Ben Levac
1538 * Jeff Eckhaus
1539 * Seth Goldman of Google
1540 * Klaus Malorny and Michael Bauland of Knipp
1541 * Jody Kolker, Joe Snitker, and Kevin Allendorf of GoDaddy
1542 * Michael Holloway of Com Laude
1543 * Santosh Kalsangrah of Impetus Infotech
1544 * Alex Mayrhofer of Nic.at
1545 * Thomas Corte of Knipp Medien und Kommunikation GmbH
1546
1547 Authors' Addresses
1548
1549 Roger Carney
1550 GoDaddy Inc.
1551 14455 N. Hayden Rd. #219
1552 Scottsdale, AZ 85260
1553 United States of America
1554
1555 Email: rcarney@godaddy.com
1556 URI: http://www.godaddy.com
1557
1558
1559 Gavin Brown
1560 CentralNic Group plc
1561 35-39 Moorgate
1562 London
1563 EC2R 6AR
1564 United Kingdom
1565
1566 Phone: +44 20 33 88 0600
1567 Email: gavin.brown@centralnic.com
1568 URI: http://www.centralnic.com
1569
1570
1571 Jothan Frakes
1572
1573 Email: jothan@jothan.com
1574 URI: http://jothan.com
1575
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.