This repository was archived by the owner on Mar 28, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 8
Expand file tree
/
Copy pathdraft-ietf-regext-epp-fees.html
More file actions
2092 lines (1984 loc) · 95.1 KB
/
draft-ietf-regext-epp-fees.html
File metadata and controls
2092 lines (1984 loc) · 95.1 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Registry Fee Extension for
the Extensible Provisioning Protocol (EPP)</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Registry Fee Extension for
the Extensible Provisioning Protocol (EPP)">
<meta name="keywords" content="EPP, XML">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Internet Engineering Task Force</td><td class="header">G. Brown</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">CentralNic Group plc</td></tr>
<tr><td class="header">Intended status: Standards Track</td><td class="header">J. Frakes</td></tr>
<tr><td class="header">Expires: November 20, 2016</td><td class="header">May 19, 2016</td></tr>
</table></td></tr></table>
<h1><br />Registry Fee Extension for
the Extensible Provisioning Protocol (EPP)<br />draft-ietf-regext-epp-fees-00</h1>
<h3>Abstract</h3>
<p>This document describes an Extensible Provisioning Protocol
(EPP) extension mapping for registry fees.
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
This Internet-Draft will expire on November 20, 2016.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Introduction<br />
<a href="#anchor2">1.1.</a>
Conventions Used in This Document<br />
<a href="#anchor3">2.</a>
Migrating to Newer Versions of This Extension<br />
<a href="#anchor4">3.</a>
Extension Elements<br />
<a href="#anchor5">3.1.</a>
Client Commands<br />
<a href="#currency-codes">3.2.</a>
Currency Codes<br />
<a href="#validity-periods">3.3.</a>
Validity Periods<br />
<a href="#fees-and-credits">3.4.</a>
Fees and Credits<br />
<a href="#anchor6">3.4.1.</a>
Refunds<br />
<a href="#anchor7">3.4.2.</a>
Grace Periods<br />
<a href="#anchor8">3.4.3.</a>
Correlation between Refundability and Grace Periods<br />
<a href="#anchor9">3.4.4.</a>
Applicability<br />
<a href="#account-balance">3.5.</a>
Account Balance<br />
<a href="#credit-limit">3.6.</a>
Credit Limit<br />
<a href="#classification">3.7.</a>
Classification of Objects<br />
<a href="#anchor10">4.</a>
Server Handling of Fee Information<br />
<a href="#anchor11">5.</a>
Retrieving Future Fee Information<br />
<a href="#anchor12">6.</a>
EPP Command Mapping<br />
<a href="#anchor13">6.1.</a>
EPP Query Commands<br />
<a href="#anchor14">6.1.1.</a>
EPP <check> Command<br />
<a href="#anchor15">6.1.1.1.</a>
Server Handling of <fee:class> Elements<br />
<a href="#anchor16">6.1.2.</a>
EPP Transfer Query Command<br />
<a href="#anchor17">6.2.</a>
EPP Transform Commands<br />
<a href="#anchor18">6.2.1.</a>
EPP <create> Command<br />
<a href="#anchor19">6.2.2.</a>
EPP <delete> Command<br />
<a href="#anchor20">6.2.3.</a>
EPP <renew> Command<br />
<a href="#anchor21">6.2.4.</a>
EPP <transfer> Command<br />
<a href="#anchor22">6.2.5.</a>
EPP <update> Command<br />
<a href="#anchor23">6.3.</a>
Formal Syntax<br />
<a href="#Security">7.</a>
Security Considerations<br />
<a href="#IANA">8.</a>
IANA Considerations<br />
<a href="#anchor24">8.1.</a>
XML Namespace<br />
<a href="#anchor25">8.2.</a>
EPP Extension Registry<br />
<a href="#impl">9.</a>
Implementation Status<br />
<a href="#anchor26">9.1.</a>
RegistryEngine EPP Service<br />
<a href="#anchor27">10.</a>
Acknowledgements<br />
<a href="#anchor28">11.</a>
Change History<br />
<a href="#anchor29">11.1.</a>
Changes from 00 to 01<br />
<a href="#anchor30">11.2.</a>
Changes from 01 to 02<br />
<a href="#anchor31">11.3.</a>
Changes from 02 to 03<br />
<a href="#anchor32">11.4.</a>
Changes from 03 to 04<br />
<a href="#anchor33">11.5.</a>
Changes from 04 to 05<br />
<a href="#anchor34">11.6.</a>
Changes from 05 to 06<br />
<a href="#anchor35">11.7.</a>
Changes from 06 to 07<br />
<a href="#anchor36">11.8.</a>
Changes from draft-brown-epp-fees-07 to draft-ietf-regext-epp-fees-00<br />
<a href="#rfc.references1">12.</a>
Normative References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>Historically, domain name registries have applied a simple fee
structure for billable transactions, namely a basic unit price applied to
domain <create>, <renew>, <transfer> and <a class='info' href='#RFC3915'>RGP<span> (</span><span class='info'>Hollenbeck, S., “Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP),” September 2004.</span><span>)</span></a> [RFC3915] restore commands. Given the relatively small
number of EPP servers to which EPP clients have been required to connect,
it has generally been the case that client operators have been able to
obtain details of these fees out-of-band by contacting the server
operators.
</p>
<p>Given the recent expansion of the DNS namespace, and the proliferation
of novel business models, it is now desirable to provide a method for EPP
clients to query EPP servers for the fees and credits associated with
certain commands and specific objects.
</p>
<p>This document describes an extension mapping for version 1.0 of the
<a class='info' href='#RFC5730'>Extensible Provisioning Protocol (EPP)<span> (</span><span class='info'>Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” August 2009.</span><span>)</span></a> [RFC5730]. This
EPP mapping provides a mechanism by which EPP clients may query the fees
and credits associated with various billable transactions, and also
obtain their current account balance.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
Conventions Used in This Document</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
<a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<p>XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the
character case presented in order to develop a conforming
implementation.
</p>
<p>"fee" is used as an abbreviation for
"urn:ietf:params:xml:ns:fee-0.12". The XML namespace prefix "fee"
is used, but implementations MUST NOT depend on it and instead employ a
proper namespace-aware XML parser and serializer to interpret and output
the XML documents.
</p>
<p>(Note to RFC Editor: remove the following paragraph before publication
as an RFC.)
</p>
<p>The XML namespace prefix above contains a version number,
specifically "0.12". This version number will increment with
successive versions of this document, and will reach 1.0 if and when
this document is published as an RFC. This permits clients to
distinguish which version of the extension a server has implemented.
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Migrating to Newer Versions of This Extension</h3>
<p>(Note to RFC Editor: remove this section before publication as an
RFC.)
</p>
<p>Servers which implement this extension SHOULD provide a
way for clients to progressively update their implementations
when a new version of the extension is deployed.
</p>
<p>Servers SHOULD (for a temporary migration period) provide support for
older versions of the extension in parallel to the newest version, and
allow clients to select their preferred version via the
<svcExtension> element of the <login> command.
</p>
<p>If a client requests multiple versions of the extension at login, then,
when preparing responses to commands which do not include extension elements,
the server SHOULD only include extension elements in the namespace of the newest
version of the extension requested by the client.
</p>
<p>When preparing responses to commands which do include extension elements, the
server SHOULD only include extension elements for the extension versions present
in the command.
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Extension Elements</h3>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.
Client Commands</h3>
<p>The <fee:command> element is used in the EPP <check> command to
determine the fee which is applicable to the given command.
</p>
<p>The element values permitted by the server is a matter of repository
policy, but MUST include as a minimum the following values:
</p>
<ul class="text">
<li>"create" indicating a <create> command;
</li>
<li>"renew" indicating a <renew> command;
</li>
<li>"transfer" indicating a <transfer> command;
</li>
</ul><p>
If the server supports the <a class='info' href='#RFC3915'>Registry Grace Period
Mapping<span> (</span><span class='info'>Hollenbeck, S., “Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP),” September 2004.</span><span>)</span></a> [RFC3915], then the server MUST also support the "restore" value.
</p>
<p>The <fee:command> element MAY have an OPTIONAL "phase" attribute
specifying a launch phase as described in
<a class='info' href='#draft-ietf-eppext-launchphase'>[draft‑ietf‑eppext‑launchphase]<span> (</span><span class='info'>Gould, J., Tan, W., and G. Brown, “Launch Phase Mapping for the Extensible Provisioning Protocol (EPP),” 2016.</span><span>)</span></a>. It may also contain an
OPTIONAL "subphase" attribute identifying the custom or sub-phase as
described in <a class='info' href='#draft-ietf-eppext-launchphase'>[draft‑ietf‑eppext‑launchphase]<span> (</span><span class='info'>Gould, J., Tan, W., and G. Brown, “Launch Phase Mapping for the Extensible Provisioning Protocol (EPP),” 2016.</span><span>)</span></a>.
</p>
<a name="currency-codes"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.
Currency Codes</h3>
<p>The <fee:currency> element is used to indicate which currency
fees are charged in. This value of this element MUST be a three-character
currency code from <a class='info' href='#ISO4217'>[ISO4217]<span> (</span><span class='info'>International Organization for Standardization, “ISO 4217:2008, Codes for the representation of currencies and funds,” 2008.</span><span>)</span></a>.
</p>
<p>Note that ISO 4217 provides the special "XXX" code, which MAY be used
if the server uses a non-currency based system for assessing fees, such as
a system of credits.
</p>
<p>The use of <fee:currency> elements in commands is OPTIONAL:
if a <fee:currency> element is not present in a command, the
server MUST determine the currency based on the client's account settings
which MUST be agreed by the client and server via an out-of-band
channel. However, the <fee:currency> element MUST be present in
responses.
</p>
<p>Servers SHOULD NOT perform a currency conversion if a client uses an
incorrect currency code. Servers SHOULD return a 2004 error instead.
</p>
<a name="validity-periods"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.3"></a><h3>3.3.
Validity Periods</h3>
<p>When querying for fee information using the <check> command,
the <fee:period> element is used to indicate the units to be added
to the registration period of objects by the <create>,
<renew> and <transfer> commands. This element is derived
from the <domain:period> element described in <a class='info' href='#RFC5731'>[RFC5731]<span> (</span><span class='info'>Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.</span><span>)</span></a>.
</p>
<p>The <fee:period> element is OPTIONAL in <check> commands:
if omitted, the server MUST determine the fee(s) using a validity period
of 1 year. The <fee:period> element MUST be present in <check>
responses.
</p>
<a name="fees-and-credits"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.4"></a><h3>3.4.
Fees and Credits</h3>
<p>Servers which implement this extension will include elements in
responses which provide information about the fees and/or credits
associated with a given billable transaction.
</p>
<p>The <fee:fee> and <fee:credit> elements are used to provide
this information. The presence of a <fee:fee> element in a response
indicates a debit against the client's account balance; a
<fee:credit> element indicates a credit. A <fee:fee> element
MUST have a non-negative value. A <fee:credit> element MUST have a
negative value.
</p>
<p>A server MAY respond with multiple <fee:fee> and
<fee:credit> elements in the same response. In such cases, the net
fee or credit applicable to the transaction is the arithmetic sum of the
values of each of the <fee:fee> and/or <fee:credit> elements.
This amount applies to the total additional validity period applied to the
object (where applicable) rather than to any incremental unit.
</p>
<p>The following attributes are defined for the <fee:fee> element.
These are described in detail below:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>description:</dt>
<dd>an OPTIONAL attribute which provides a
human-readable description of the fee. Servers should provide
documentation on the possible values of this attribute, and their
meanings.
</dd>
<dt>refundable:</dt>
<dd>an OPTIONAL boolean attribute indicating
whether the fee is refundable if the object is deleted.
</dd>
<dt>grace-period:</dt>
<dd>an OPTIONAL attribute which provides the
time period during which the fee is refundable.
</dd>
<dt>applied:</dt>
<dd>an OPTIONAL attribute indicating when the
fee will be deducted from the client's account.
</dd>
</dl></blockquote>
<p>The <fee:credit> element can take a "description" attribute
as described above. No other attributes are defined for this
element.
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.4.1"></a><h3>3.4.1.
Refunds</h3>
<p><fee:fee> elements MAY have an OPTIONAL "refundable" attribute
which takes a boolean value. Fees may be refunded under certain
circumstances, such as when a domain application is rejected (as
described in <a class='info' href='#draft-ietf-eppext-launchphase'>[draft‑ietf‑eppext‑launchphase]<span> (</span><span class='info'>Gould, J., Tan, W., and G. Brown, “Launch Phase Mapping for the Extensible Provisioning Protocol (EPP),” 2016.</span><span>)</span></a>) or when
an object is deleted during the relevant Grace Period (see below).
</p>
<p>If the "refundable" attribute is omitted, then clients SHOULD NOT make
any assumption about the refundability of the fee.
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.4.2"></a><h3>3.4.2.
Grace Periods</h3>
<p><a class='info' href='#RFC3915'>[RFC3915]<span> (</span><span class='info'>Hollenbeck, S., “Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP),” September 2004.</span><span>)</span></a> describes a system of "grace periods",
which are time periods following a billable transaction during which,
if an object is deleted, the client receives a refund.
</p>
<p>The "grace-period" attribute MAY be used to indicate the relevant
grace period for a fee. If a server implements the Registry Grace
Period extension, it MUST specify the grace period for all relevant
transactions.
</p>
<p>If the "grace-period" attribute is omitted, then clients
SHOULD NOT make any assumption about the grace period of the fee.
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.4.3"></a><h3>3.4.3.
Correlation between Refundability and Grace Periods</h3>
<p>If a <fee:fee> element has a "grace-period" attribute then
it MUST also be refundable. If the "refundable" attribute of a
<fee:fee> element is false then it MUST NOT have a
"grace-period" attribute.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.4.4"></a><h3>3.4.4.
Applicability</h3>
<p>Fees may be applied immediately upon receipt of a command from a
client, or may only be applied once an out-of-band process (such as
the processing of applications at the end of a launch phase) has
taken place.
</p>
<p>The "applied" attribute of the <fee:fee> element allows
servers to indicate whether a fee will be applied immediately, or
whether it will be applied at some point in the future. This
attribute takes two possible values: "immediate" (which is the
default) or "delayed".
</p>
<a name="account-balance"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.5"></a><h3>3.5.
Account Balance</h3>
<p>The <fee:balance> element is an OPTIONAL element which MAY
be included in server responses to transform commands. If present,
it can be used by the client to determine the remaining credit at
the server.
</p>
<p>Whether or not the <fee:balance> is included in responses is a
matter of server policy. However, if a server chooses
to offer support for this element, it MUST be included in responses
to all "transform" commands (ie <create>, <renew>,
<update>, <delete>, <transfer op="request">).
</p>
<p>The value of the <fee:balance> MAY be negative. A negative
balance indicates that the server has extended a line of credit to the
client (see below).
</p>
<p>If a server includes a <fee:balance> element in response to
transform commands, the value of the element MUST reflect the client's
account balance after any fees or credits associated with that command
have been applied.
</p>
<a name="credit-limit"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.6"></a><h3>3.6.
Credit Limit</h3>
<p>As described above, if a server returns a response containing a
<fee:balance> with a negative value, then the server has extended a
line of credit to the client. A server MAY also include a
<fee:creditLimit> element in responses which indicates the maximum
credit available to a client. A server MAY reject certain transactions if
the absolute value of the <fee:balance> is equal to or exceeds the
value of the <fee:creditLimit> element.
</p>
<p>Whether or not the <fee:creditLimit> is included in responses
is a matter of server policy. However, if a server chooses
to offer support for this element, it MUST be included in responses
to all "transform" commands (ie <create>, <renew>,
<update>, <delete>, <transfer op="request">).
</p>
<a name="classification"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.7"></a><h3>3.7.
Classification of Objects</h3>
<p>Objects may be assigned to a particular class, category, or tier,
each of which has a particular fee or set of fees associated with it. The
<fee:class> element which appears in <check> responses is
used to indicate the classification of an object.
</p>
<p>If a server makes use of this element, it should provide clients with a
list of all the values that the element may take via an out-of-band
channel. Servers MUST NOT use values which do not appear on this list.
</p>
<p>Servers which make use of this element MUST use a <fee:class>
element with the value "standard" for all objects that are subject to the
standard or default fee.
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Server Handling of Fee Information</h3>
<p>Depending on server policy, a client MAY be required to include the
extension elements described in this document for certain transform
commands. Servers must provide clear documentation to clients about the
circumstances in which this extension must be used.
</p>
<p>If a server receives a command from a client which does not include
the extension elements required by the server for that command, then
it MUST respond with a 2003 "Required parameter missing" error.
</p>
<p>If the currency or total fee provided by the client do not agree
with the server's own calculation of the fee for that command, then the
server MUST reject the command with a 2004 "Parameter value range"
error.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Retrieving Future Fee Information</h3>
<p>Sometimes, the time interval between when a client queries the
fee for a command, and when that command takes place, is long enough that
there is a non-negligible probability that the fee might change in
the intervening time.
</p>
<p>To ensure that clients can obtain the most accurate fee information
in such circumstances, clients can include a <fee:cmdDate> element
in fee <check> commands, to indicate the anticipated date and time
of a billable transaction.
</p>
<p>If a server receives a command containing a <fee:cmdDate> element,
and the server is unable to provide accurate fee information for the given
date and time, then it MUST respond with a 2306 "Parameter value policy
error" error. Otherwise, the server MUST return fee information that will
prevail at the date and time provided.
</p>
<p>This extension provides no mechanism to enforce the application of these
fees when the command is subsequently submitted; servers MUST reject commands
which include incorrect fee information, as described above.
</p>
<p>If a server knows that the fee information it is returning to a client
is going to change in the future, it MAY include <fee:notAfter>
elements in <check> responses. This element contains a date and time
after which the provided fee information will no longer apply. Clients which
receive a response from a server which contain <fee:notAfter> elements
may then re-query for the fee information (using the <fee:cmdDate>
element) described above if the value of the <fee:notAfter> element
is before the anticipated time when the command will be submitted.
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
EPP Command Mapping</h3>
<p>A detailed description of the EPP syntax and semantics can be found in
<a class='info' href='#RFC5730'>[RFC5730]<span> (</span><span class='info'>Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” August 2009.</span><span>)</span></a>.
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1.
EPP Query Commands</h3>
<p>This extension does not add any elements to the EPP <poll> or
<info> commands or responses.
</p>
<a name="anchor14"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1.1"></a><h3>6.1.1.
EPP <check> Command</h3>
<p>This extension defines additional elements for the EPP
<check> command.
</p>
<p>The command MAY contain an <extension> element which
MAY contain a <fee:check> element. The <fee:check> element
contains the following child elements:
</p>
<p></p>
<ul class="text">
<li>A <fee:command> element;
</li>
<li>An OPTIONAL <fee:currency> element;
</li>
<li>An OPTIONAL <fee:period> element.
</li>
<li>An OPTIONAL <fee:class> element.
</li>
<li>An OPTIONAL <fee:cmdDate> element.
</li>
</ul>
<p>Example <check> command:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
C: <?xml version="1.0" encoding="utf-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <check>
C: <domain:check
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: <domain:name>example.net</domain:name>
C: <domain:name>example.xyz</domain:name>
C: </domain:check>
C: </check>
C: <extension>
C: <fee:check xmlns:fee="urn:ietf:params:xml:ns:fee-0.12">
C: <fee:command>create</fee:command>
C: <fee:currency>USD</fee:currency>
C: <fee:cmdDate
C: >2016-05-17T13:22:21.0Z</fee:cmdDate>
C: </fee:check>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C: </epp>
</pre></div>
<p>When the server receives a <check> command that includes the
extension elements described above, its response MUST (subject to the
exception described below) contain an <extension> element,
which MUST contain a child <fee:chkData> element. The
<fee:chkData> element MUST contain a <fee:cd> element for
each object referenced in the <check> element in the command.
</p>
<p>The <fee:cd> element has an OPTIONAL "avail" attribute which
is a boolean. If the value of this attribute evaluates to false, this
indicates that the server cannot calculate the relevant fees, because
the object, command, currency, period or class is invalid according to
server policy.
</p>
<p>The <fee:cd> contains the following child elements:
</p>
<p></p>
<ul class="text">
<li>A <fee:object> element, which contains a copy of the child
element of the <check> element of the command, to which the fee
information relates.
</li>
<li>A <fee:command> element, which contains the same command
that appeared in the corresponding <fee:command> element in the
command. This element MAY have the OPTIONAL "phase" and "subphase" elements,
which MUST match the same attributes in the corresponding
<fee:command> element in the command.
</li>
<li>A <fee:currency> element, which contains the same currency code
that appeared in the <fee:currency> element of the command.
If no <fee:currency> element appeared in the command, then
the client's default billing currency should be used.
</li>
<li>An OPTIONAL <fee:period> element, which contains the same unit
that appeared in the <fee:currency> element of the command. If
the value of the preceding <fee:command> element is "restore",
this element MUST NOT be included. Otherwise it MUST be included. If
no <fee:period> appeared in command (and the command is not
"restore") then this element MUST have a value of 1 year.
</li>
<li>Zero or more <fee:fee> elements.
</li>
<li>Zero or more <fee:credit> elements.
</li>
<li>An OPTIONAL <fee:class> element.
</li>
<li>An OPTIONAL <fee:reason> element.
</li>
<li>An OPTIONAL <fee:cmdDate> element, which contains the same
date and time that appeared in the <fee:check> element of
the command.
</li>
</ul>
<p>If no <fee:fee> elements are present in a <fee:cd>
element, this indicates that no fee will be assessed by the
server for this command.
</p>
<p>If the "avail" attribute of the <fee:cd> element is false, then
the <fee:cd> element MUST NOT contain any <fee:fee> or
<fee:credit> child elements. If the "avail" attribute is true,
then the <fee:cd> element MUST NOT contain a <fee:reason>
element.
</p>
<p>Example <check> response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:chkData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:cd>
S: <domain:name avail="1">example.com</domain:name>
S: </domain:cd>
S: <domain:cd>
S: <domain:name avail="1">example.net</domain:name>
S: </domain:cd>
S: <domain:cd>
S: <domain:name avail="1">example.xyz</domain:name>
S: </domain:cd>
S: </domain:chkData>
S: </resData>
S: <extension>
S: <fee:chkData
S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.12"
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <fee:cd avail="1">
S: <fee:object>
S: <domain:name>example.com</domain:name>
S: </fee:object>
S: <fee:command>create</fee:command>
S: <fee:currency>USD</fee:currency>
S: <fee:period unit="y">1</fee:period>
S: <fee:fee
S: description="Registration Fee"
S: refundable="1"
S: grace-period="P5D">5.00</fee:fee>
S: <fee:cmdDate
S: >2016-05-17T13:22:21.0Z</fee:cmdDate>
S: </fee:cd>
S: <fee:cd avail="1">
S: <fee:object>
S: <domain:name>example.net</domain:name>
S: </fee:object>
S: <fee:command>create</fee:command>
S: <fee:currency>USD</fee:currency>
S: <fee:period unit="y">1</fee:period>
S: <fee:fee
S: description="Registration Fee"
S: refundable="1"
S: grace-period="P5D">5.00</fee:fee>
S: <fee:cmdDate
S: >2016-05-17T13:22:21.0Z</fee:cmdDate>
S: </fee:cd>
S: <fee:cd avail="0">
S: <fee:object>
S: <domain:name>example.xyz</domain:name>
S: </fee:object>
S: <fee:command>create</fee:command>
S: <fee:currency>USD</fee:currency>
S: <fee:period unit="y">1</fee:period>
S: <fee:reason>
S: minimum period is 2 years.
S: </fee:reason>
S: <fee:cmdDate
S: >2016-05-17T13:22:21.0Z</fee:cmdDate>
S: </fee:cd>
S: </fee:chkData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S: </epp>
</pre></div>
<a name="anchor15"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1.1.1"></a><h3>6.1.1.1.
Server Handling of <fee:class> Elements</h3>
<p>When a server supports classes as described in Section 3.7,
and the <fee:class> element is present in the command, the server MUST
validate the value of this element, and return an error for unknown values.
If the given value is incorrect for the specified object, the
"avail" attribute of the corresponding <fee:cd> element MUST be
false.
</p>
<p>The <fee:cd> section MUST contain the appropriate
<fee:class> element when the servers support classes, as described
in Section 3.7, and the "avail"
attribute of the <fee:cd> element is true.
</p>
<a name="anchor16"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1.2"></a><h3>6.1.2.
EPP Transfer Query Command</h3>
<p>This extension does not add any elements to the EPP
<transfer> query command, but does include elements in the
response, when the extension has been selected during a <login>
command.
</p>
<p>When the <transfer> query command has been processed
successfully, the client selected the extension when it logged in, and
the client is authorised by the server to view information about the
transfer, the server MAY include in the <extension> section of
the EPP response a <fee:trnData> element, which contains the
following child elements:
</p>
<p></p>
<ul class="text">
<li>A <fee:currency> element.
</li>
<li>A <fee:period> element.
</li>
<li>Zero or more <fee:fee> elements containing the fees
that will be charged to the gaining client.
</li>
<li>Zero or more <fee:credit> elements containing the credits
that will be refunded to the losing client.
</li>
</ul>
<p>Servers SHOULD omit <fee:credit> when returning a response
to the gaining client, and omit <fee:fee> elements
when returning a response to the losing client.
</p>
<p>If no <fee:trnData> element is included in the
response, then no fee will be assessed by the server for the
transfer.
</p>
<p>Example <transfer> query response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1001">
S: <msg>Command completed successfully; action pending</msg>
S: </result>
S: <resData>
S: <domain:trnData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>example.com</domain:name>
S: <domain:trStatus>pending</domain:trStatus>
S: <domain:reID>ClientX</domain:reID>
S: <domain:reDate>2000-06-08T22:00:00.0Z</domain:reDate>
S: <domain:acID>ClientY</domain:acID>
S: <domain:acDate>2000-06-13T22:00:00.0Z</domain:acDate>
S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
S: </domain:trnData>
S: </resData>
S: <extension>
S: <fee:trnData xmlns:fee="urn:ietf:params:xml:ns:fee-0.12">
S: <fee:currency>USD</fee:currency>
S: <fee:period unit="y">1</fee:period>
S: <fee:fee>5.00</fee:fee>
S: </fee:trnData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S: </epp>
</pre></div>
<a name="anchor17"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2.
EPP Transform Commands</h3>
<a name="anchor18"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2.1"></a><h3>6.2.1.
EPP <create> Command</h3>
<p>This extension adds elements to both the EPP <create> command
and response, when the extension has been selected during a
<login> command.
</p>
<p>When submitting a <create> command to the server, the client
MAY include in the <extension> element a <fee:create>
element which includes the following child elements:
</p>
<p></p>
<ul class="text">
<li>An OPTIONAL <fee:currency> element;
</li>
<li>One or more <fee:fee> elements.
</li>
</ul>
<p>When the <create> command has been processed successfully,
and the client selected the extension when it logged in, and a fee was
assessed by the server for the transaction, the server MUST include in
the <extension> section of the EPP response a
<fee:creData> element, which contains the following child
elements:
</p>
<p></p>
<ul class="text">
<li>A <fee:currency> element;