-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-zhou-eppext-reseller-mapping-00.txt
1736 lines (1195 loc) · 57.4 KB
/
draft-zhou-eppext-reseller-mapping-00.txt
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
Internet Engineering Task Force L. Zhou
Internet-Draft N. Kong
Intended status: Standards Track C. Qi
Expires: November 5, 2015 X. Lee
CNNIC
J. Gould
VeriSign, Inc.
May 4, 2015
Extensible Provisioning Protocol (EPP) Reseller Mapping
draft-zhou-eppext-reseller-mapping-00
Abstract
This document describes an Extensible Provisioning Protocol (EPP)
mapping for provisioning and management of registry reseller stored
in a shared central repository. Specified in Extensible Markup
Language (XML), this extended mapping is applied to provide
additional features required for the provisioning of registry
resellers.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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/.
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."
This Internet-Draft will expire on November 5, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Zhou, et al. Expires November 5, 2015 [Page 1]
Internet-Draft EPP Reseller Mapping May 2015
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Reseller Identifier . . . . . . . . . . . . . . . . . . . 4
3.2. Contact and Client Identifiers . . . . . . . . . . . . . 4
3.3. Reseller State . . . . . . . . . . . . . . . . . . . . . 4
3.4. Parent Identifier . . . . . . . . . . . . . . . . . . . . 4
3.5. URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.6. Disclosure of Data Elements and Attributes . . . . . . . 5
4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5
4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5
4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 5
4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 7
4.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . 13
4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 13
4.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 13
4.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 16
4.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 18
4.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 18
4.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 18
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Internationalization Considerations . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 28
7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. Normative References . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
Zhou, et al. Expires November 5, 2015 [Page 2]
Internet-Draft EPP Reseller Mapping May 2015
1. Introduction
Domain resellers are the individuals or companies that act as agents
for domain name registrars. A domain name registrar is a direct
customer of the domain name registry, is represented as the
sponsoring client to the server in [RFC5730], and may have several
resellers to help them sell domain names to end users.
This document describes an extension mapping for version 1.0 of the
Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping
specifies the reseller object mapping.
This document is specified using the XML 1.0 as described in
[W3C.REC-xml-20040204] and XML Schema notation as described in
[W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028].
2. Conventions Used in This Document
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 [RFC2119].
In examples, "C:" represents lines sent by a protocol client and "S:"
represents lines returned by a protocol server. Indentation and
white space in examples are provided only to illustrate element
relationships and are not a REQUIRED feature of this specification.
XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the
character case presented to develop a conforming implementation.
"reseller-1.0" in is used as an abbreviation for
"urn:ietf:params:xml:ns:reseller-1.0". The XML namespace prefix
"reseller" 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.
3. Object Attributes
An EPP reseller object has attributes and associated values that can
be viewed and modified by the sponsoring client or the server. This
section describes each attribute type in detail. The formal syntax
for the attribute values described here can be found in the "Formal
Syntax" section of this document and in the appropriate normative
references.
Zhou, et al. Expires November 5, 2015 [Page 3]
Internet-Draft EPP Reseller Mapping May 2015
3.1. Reseller Identifier
Reseller identifier provides the ID of the reseller of a sponsoring
registrar. Its corresponding element is <reseller:id> defined in
this document.
3.2. Contact and Client Identifiers
All EPP contacts are identified by a server-unique identifier.
Contact identifiers are character strings with a specific minimum
length, a specified maximum length, and a specified format. Contact
identifiers use the "clIDType" client identifier syntax described in
[RFC5730].
3.3. Reseller State
A reseller object MUST always have at least one associated state
value. Valid values include "ok", "readonly" and "terminated".
State Value Descriptions:
o ok: the normal status value for the reseller object.
o readonly: transform commands submitted with the reseller
identifier in the reseller extension would not be allowed.
o terminated: query and tranform commands submitted with the
reseller identifier in the reseller extension would not be
allowed.
3.4. Parent Identifier
There can be more than one layer of resellers. The parent
identifier, as defined with the <reseller:parentId> element,
represents the parent reseller identifier in a child reseller. The
parent identifier is not defined for the top level reseller, namely
the registrar of the registry. An N-tier reseller has a parent
reseller and at least one child reseller. A reseller customer has a
parent reseller and no child resellers.
3.5. URL
The URL represents the reseller web home page, as defined with the
<reseller:url> element.
Zhou, et al. Expires November 5, 2015 [Page 4]
Internet-Draft EPP Reseller Mapping May 2015
3.6. Disclosure of Data Elements and Attributes
This document supports the same disclosure features described in
Section 2.9 of with the use of the <reseller:disclose> element.
[RFC5733].
The <reseller:disclose> element MUST contain at least one of the
following child elements:
<reseller:name type="int"/>
<reseller:name type="loc"/>
<reseller:addr type="int"/>
<reseller:addr type="loc"/>
<reseller:voice/>
<reseller:fax/>
<reseller:email/>
<reseller:url/>
<reseller:contact/>
4. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found
in the EPP core protocol specification [RFC5730]. The command
mappings described here are specifically for use in provisioning and
managing reseller information via EPP.
4.1. EPP Query Commands
EPP provides three commands to retrieve domain information: <check>
to determine if a reseller object can be provisioned within a
repository, <info> to retrieve detailed information associated with a
reseller object, and <transfer> to retrieve information regarding the
transfer status of the reseller object.
4.1.1. EPP <check> Command
The EPP <check> command is used to determine if an object can be
provisioned within a repository. It provides a hint that allows a
client to anticipate the success or failure of provisioning an object
Zhou, et al. Expires November 5, 2015 [Page 5]
Internet-Draft EPP Reseller Mapping May 2015
using the <create> command, as object-provisioning requirements are
ultimately a matter of server policy.
In addition to the standard EPP command elements, the <check> command
MUST contain a <reseller:check> element that identifies the reseller
namespace. The <reseller:check> element contains the following child
elements:
o One or more <reseller:id> elements that contain the server-unique
identifier of the reseller objects to be queried.
Example <check> command:
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: <reseller:check
C: xmlns:reseller="urn:ietf:params:xml:ns:reseller-1.0">
C: <reseller:id>res1523</reseller:id>
C: <reseller:id>re1523</reseller:id>
C: <reseller:id>1523res</reseller:id>
C: </reseller:check>
C: </check>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <check> command has been processed successfully, the EPP
<resData> element MUST contain a child <reseller:chkData> element
that identifies the reseller namespace. The <reseller:chkData>
element contains one or more <reseller:cd> elements that contain the
following child elements:
o A <reseller:id> element that identifies the queried object. This
element MUST contain an "avail" attribute whose value indicates
object availability (can it be provisioned or not) at the moment
the <check> command was completed. A value of "1" or "true" means
that the object can be provisioned. A value of "0" or "false"
means that the object cannot be provisioned.
o An OPTIONAL <reseller:reason> element that MAY be provided when an
object cannot be provisioned. If present, this element contains
server-specific text to help explain why the object cannot be
provisioned. This text MUST be represented in the response
language previously negotiated with the client; an OPTIONAL "lang"
attribute MAY be present to identify the language if the
Zhou, et al. Expires November 5, 2015 [Page 6]
Internet-Draft EPP Reseller Mapping May 2015
negotiated value is something other than the default value of
"en"(English).
Example <check> response:
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: <reseller:chkData
S: xmlns:reseller="urn:ietf:params:xml:ns:reseller-1.0">
S: <reseller:cd>
S: <reseller:id avail="1">res1523</reseller:id>
S: </reseller:cd>
S: <reseller:cd>
S: <reseller:id avail="0">re1523</reseller:id>
S: <reseller:reason>In use</reseller:reason>
S: </reseller:cd>
S: <reseller:cd>
S: <reseller:id avail="1">1523res</reseller:id>
S: </reseller:cd>
S: </reseller:chkData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <check> command cannot be
processed for any reason.
4.1.2. EPP <info> Command
The EPP <info> command is used to retrieve information associated
with a reseller object. In addition to the standard EPP command
elements, the <info> command MUST contain a <reseller:info> element
that identifies the reseller namespace. The <reseller:info> element
contains the following child elements:
o A <reseller:id> element that contains the server-unique identifier
of the reseller object to be queried.
Zhou, et al. Expires November 5, 2015 [Page 7]
Internet-Draft EPP Reseller Mapping May 2015
Example <info> command:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <reseller:info
C: xmlns:reseller="urn:ietf:params:xml:ns:reseller-1.0">
C: <reseller:id>res1523</reseller:id>
C: </reseller:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an <info> command has been processed successfully, the EPP
<resData> element MUST contain a child <reseller:infData> element
that identifies the reseller namespace. The < reseller:infData>
element contains the following child elements:
o A <reseller:id> element that contains the server-unique identifier
of the reseller object, as defined in Section 3.1.
o A <reseller:roid> element that contains the Repository Object
IDentifier assigned to the reseller object when the object was
created.
o A <reseller:state> element that contains the operational state of
the reseller, as defined in Section 3.3.
o An OPTIONAL <reseller:parentId> element that contains the
identifier of the parent object, as defined in Section 3.4.
o One or two <reseller:postalInfo> elements that contain postal-
address information. Two elements are provided so that address
information can be provided in both internationalized and
localized forms; a "type" attribute is used to identify the two
forms. If an internationalized form (type="int") is provided,
element content MUST be represented in a subset of UTF-8 that can
be represented in the 7-bit US-ASCII character set. If a
localized form (type="loc") is provided, element content MAY be
represented in unrestricted UTF-8. The <reseller:postalInfo>
element contains the following child elements:
* A <reseller:name> element that contains the name of the
reseller, which SHOULD be the name of the organization.
Zhou, et al. Expires November 5, 2015 [Page 8]
Internet-Draft EPP Reseller Mapping May 2015
* A <reseller:addr> element that contains address information
associated with the reseller. A <reseller:addr> element
contains the following child elements:
+ One, two, or three OPTIONAL <reseller:street> elements that
contain the reseller's street address.
+ A <reseller:city> element that contains the reseller's city.
+ An OPTIONAL <reseller:sp> element that contains the
reseller's state or province.
+ An OPTIONAL <reseller:pc> element that contains the
reseller's postal code.
+ A <reseller:cc> element that contains the reseller's country
code.
o An OPTIONAL <reseller:voice> element that contains the reseller's
voice telephone number.
o An OPTIONAL <reseller:fax> element that contains the reseller's
facsimile telephone number.
o A <reseller:email> element that contains the reseller's email
address.
o A <reseller:url> element that contains the reseller's web home
page.
o Zero or more OPTIONAL <reseller:contact> elements that contain
identifiers for the contact objects to be associated with the
reseller object. Contact object identifiers MUST be known to the
server before the contact object can be associated with the
reseller object.
o A <reseller:clID> element that contains the identifier of the
sponsoring client, who is the domain name registrar.
o A <reseller:crID> element that contains the identifier of the
client that created the reseller object.
o A <reseller:crDate> element that contains the date and time of
reseller-object creation.
o A <reseller:upID> element that contains the identifier of the
client that last updated the reseller object. This element MUST
NOT be present if the reseller has never been modified.
Zhou, et al. Expires November 5, 2015 [Page 9]
Internet-Draft EPP Reseller Mapping May 2015
o A <reseller:upDate> element that contains the date and time of the
most recent reseller-object modification. This element MUST NOT
be present if the reseller object has never been modified.
o An OPTIONAL <reseller:disclose> element that identifies elements
that require exceptional server-operator handling to allow or
restrict disclosure to third parties. See Section 3.6 for a
description of the child elements contained within the
<reseller:disclose> element.
Example <info> response for the sponsoring client:
Zhou, et al. Expires November 5, 2015 [Page 10]
Internet-Draft EPP Reseller Mapping May 2015
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: <reseller:infData
S: xmlns:reseller="urn:ietf:params:xml:ns:reseller-1.0">
S: <reseller:id>res1523</reseller:id>
S: <reseller:roid>res1523-REP</reseller:roid>
S: <reseller:state>ok</reseller:state>
S: <reseller:parentId>1523res</reseller:parentId>
S: <reseller:postalInfo type="int">
S: <reseller:name>Example Reseller Inc.</reseller:name>
S: <reseller:addr>
S: <reseller:street>123 Example Dr.</reseller:street>
S: <reseller:street>Suite 100</reseller:street>
S: <reseller:city>Dulles</reseller:city>
S: <reseller:sp>VA</reseller:sp>
S: <reseller:pc>20166-6503</reseller:pc>
S: <reseller:cc>US</reseller:cc>
S: </reseller:addr>
S: </reseller:postalInfo>
S: <reseller:voice x="1234">+1.7035555555</reseller:voice>
S: <reseller:fax>+1.7035555556</reseller:fax>
S: <reseller:email>[email protected]</reseller:email>
S: <reseller:url>http://reseller.example</reseller:url>
S: <reseller:contact type="admin">sh8013</reseller:contact>
S: <reseller:contact type="billing">sh8013</reseller:contact>
S: <reseller:clID>ClientY</reseller:clID>
S: <reseller:crID>ClientX</reseller:crID>
S: <reseller:crDate>1999-04-03T22:00:00.0Z</reseller:crDate>
S: <reseller:upID>ClientX</reseller:upID>
S: <reseller:upDate>1999-12-03T09:00:00.0Z</reseller:upDate>
S: <reseller:disclose flag="0">
S: <reseller:voice/>
S: <reseller:email/>
S: </reseller:disclose>
S: </reseller:infData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Zhou, et al. Expires November 5, 2015 [Page 11]
Internet-Draft EPP Reseller Mapping May 2015
Example <info> for the non-sponsoring client, according to the
disclosure policy:
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: <reseller:infData
S: xmlns:reseller="urn:ietf:params:xml:ns:reseller-1.0">
S: <reseller:id>res1523</reseller:id>
S: <reseller:roid>res1523-REP</reseller:roid>
S: <reseller:state>ok</reseller:state>
S: <reseller:parentId>1523res</reseller:parentId>
S: <reseller:postalInfo type="int">
S: <reseller:name>Example Reseller Inc.</reseller:name>
S: <reseller:addr>
S: <reseller:street>123 Example Dr.</reseller:street>
S: <reseller:street>Suite 100</reseller:street>
S: <reseller:city>Dulles</reseller:city>
S: <reseller:sp>VA</reseller:sp>
S: <reseller:pc>20166-6503</reseller:pc>
S: <reseller:cc>US</reseller:cc>
S: </reseller:addr>
S: </reseller:postalInfo>
S: <reseller:email>[email protected]</reseller:email>
S: <reseller:url>http://reseller.example</reseller:url>
S: <reseller:clID>ClientY</reseller:clID>
S: <reseller:crID>ClientX</reseller:crID>
S: <reseller:crDate>1999-04-03T22:00:00.0Z</reseller:crDate>
S: <reseller:upID>ClientX</reseller:upID>
S: <reseller:upDate>1999-12-03T09:00:00.0Z</reseller:upDate>
S: <reseller:disclose flag="0">
S: <reseller:voice/>
S: <reseller:email/>
S: </reseller:disclose>
S: </reseller:infData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Zhou, et al. Expires November 5, 2015 [Page 12]
Internet-Draft EPP Reseller Mapping May 2015
An EPP error response MUST be returned if an <info> command cannot be
processed for any reason.
4.1.3. EPP <transfer> Command
The transfer semantics does not apply to reseller object. No EPP
<transfer> command is defined in this document.
4.2. EPP Transform Commands
EPP provides four commands to transform reseller-object information:
<create> to create an instance of a reseller object, <delete> to
delete an instance of a reseller object, <transfer> to manage
reseller-object sponsorship changes, and <update> to change
information associated with a reseller object. This document does
not define a mapping for the EPP <renew> command.
Transform commands are typically processed and completed in real
time. Server operators MAY receive and process transform commands
but defer completing the requested action if human or third-party
review is required before the requested action can be completed. In
such situations, the server MUST return a 1001 response code to the
client to note that the command has been received and processed but
that the requested action is pending. The server MUST also manage
the status of the object that is the subject of the command to
reflect the initiation and completion of the requested action. Once
the action has been completed, all clients involved in the
transaction MUST be notified using a service message that the action
has been completed and that the status of the object has changed.
Other notification methods MAY be used in addition to the required
service message.
4.2.1. EPP <create> Command
The EPP <create> command provides a transform operation that allows a
client to create a reseller object. In addition to the standard EPP
command elements, the <create> command MUST contain a
<reseller:create> element that identifies the reseller namespace.
The <reseller:create> element contains the following child elements:
o A <reseller:id> element that contains the desired server-unique
identifier for the reseller to be created, as defined in
Section 3.1.
o A <reseller:state> element that contains the operational status of
the reseller, as defined in Section 3.3.
Zhou, et al. Expires November 5, 2015 [Page 13]
Internet-Draft EPP Reseller Mapping May 2015
o An OPTIONAL <reseller:parentId> element that contains the
identifier of the parent object, as defined in Section 3.4.
o One or two <reseller:postalInfo> elements that contain postal-
address information. Two elements are provided so that address
information can be provided in both internationalized and
localized forms; a "type" attribute is used to identify the two
forms. If an internationalized form (type="int") is provided,
element content MUST be represented in a subset of UTF-8 that can
be represented in the 7-bit US-ASCII character set. If a
localized form (type="loc") is provided, element content MAY be
represented in unrestricted UTF-8. The <reseller:postalInfo>
element contains the following child elements:
* A <reseller:name> element that contains the name of the
reseller, which SHOULD be the name of the organization..
* A <reseller:addr> element that contains address information
associated with the reseller. A <reseller:addr> element
contains the following child elements:
+ One, two, or three OPTIONAL <reseller:street> elements that
contain the reseller's street address.
+ A <reseller:city> element that contains the reseller's city.
+ An OPTIONAL <reseller:sp> element that contains the
reseller's state or province.
+ An OPTIONAL <reseller:pc> element that contains the
reseller's postal code.
+ A <reseller:cc> element that contains the reseller's country
code.
o An OPTIONAL <reseller:voice> element that contains the reseller's
voice telephone number.
o An OPTIONAL <reseller:fax> element that contains the reseller's
facsimile telephone number.
o A <reseller:email> element that contains the reseller's email
address.
o A <reseller:url> element that contains the reseller's web home
page.
Zhou, et al. Expires November 5, 2015 [Page 14]
Internet-Draft EPP Reseller Mapping May 2015
o Zero or more OPTIONAL <reseller:contact> elements that contain
identifiers for the human or organizational social information
objects associated with the reseller object.
o An OPTIONAL <reseller:disclose> element that identifies elements
that require exceptional server-operator handling to allow or
restrict disclosure to third parties. See Section 3.6 for a
description of the child elements contained within the
<reseller:disclose> element.
Example <create> command:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <create>
C: <reseller:create
C: xmlns:reseller="urn:ietf:params:xml:ns:reseller-1.0">
C: <reseller:id>res1523</reseller:id>
C: <reseller:state>ok</reseller:state>
C: <reseller:parentId>1523res</reseller:parentId>
C: <reseller:postalInfo type="int">
C: <reseller:name>Example Reseller Inc.</reseller:name>
C: <reseller:addr>
C: <reseller:street>123 Example Dr.</reseller:street>
C: <reseller:street>Suite 100</reseller:street>
C: <reseller:city>Dulles</reseller:city>
C: <reseller:sp>VA</reseller:sp>
C: <reseller:pc>20166-6503</reseller:pc>
C: <reseller:cc>US</reseller:cc>
C: </reseller:addr>
C: </reseller:postalInfo>
C: <reseller:voice x="1234">+1.7035555555</reseller:voice>
C: <reseller:fax>+1.7035555556</reseller:fax>
C: <reseller:email>[email protected]</reseller:email>
C: <reseller:url>http://reseller.example</reseller:url>
C: <reseller:contact type="admin">sh8013</reseller:contact>
C: <reseller:contact type="billing">sh8013</reseller:contact>
C: <reseller:disclose flag="0">
C: <reseller:voice/>
C: <reseller:email/>
C: </reseller:disclose>
C: </reseller:create>
C: </create>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Zhou, et al. Expires November 5, 2015 [Page 15]
Internet-Draft EPP Reseller Mapping May 2015
When a <create> command has been processed successfully, the EPP
<resData> element MUST contain a child <reseller:creData> element
that identifies the reseller namespace. The <reseller:creData>
element contains the following child elements:
o A <reseller:id> element that contains the server-unique identifier
for the created reseller, as defined in Section 3.1..
o A <reseller:crDate> element that contains the date and time of
reseller-object creation.
Example <create> response:
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: <reseller:creData
S: xmlns:reseller="urn:ietf:params:xml:ns:reseller-1.0">
S: <reseller:id>res1523</reseller:id>
S: <reseller:crDate>1999-04-03T22:00:00.0Z</reseller:crDate>
S: </reseller:creData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <create> command cannot
be processed for any reason.
4.2.2. EPP <delete> Command
The EPP <delete> command provides a transform operation that allows a
client to delete a reseller object. In addition to the standard EPP
command elements, the <delete> command MUST contain a
<reseller:delete> element that identifies the reseller namespace.
The <reseller:delete> element MUST contain the following child
element:
o A <reseller:id> element that contains the server-unique identifier
of the reseller object, as defined in Section 3.1, to be deleted.
Zhou, et al. Expires November 5, 2015 [Page 16]
Internet-Draft EPP Reseller Mapping May 2015
A reseller object SHOULD NOT be deleted if it is associated with
other known objects. An associated reseller SHOULD NOT be deleted
until associations with other known objects have been broken. A
server SHOULD notify clients that object relationships exist by
sending a 2305 error response code when a <delete> command is
attempted and fails due to existing object relationships.
Example <delete> command:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <delete>
C: <reseller:delete
C: xmlns:reseller="urn:ietf:params:xml:ns:reseller-1.0">
C: <reseller:id>res1523</reseller:id>
C: </reseller:delete>
C: </delete>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <delete> command has been processed successfully, a server
MUST respond with an EPP response with no <resData> element.
Example <delete> response:
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: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <delete> command cannot
be processed for any reason.
Zhou, et al. Expires November 5, 2015 [Page 17]
Internet-Draft EPP Reseller Mapping May 2015
4.2.3. EPP <renew> Command
Renewal semantics do not apply to reseller objects, so there is no
mapping defined for the EPP <renew> command.
4.2.4. EPP <transfer> Command
Transfer semantics do not apply to reseller objects, so there is no
mapping defined for the EPP <transfer> command.
4.2.5. EPP <update> Command
The EPP <update> command provides a transform operation that allows a
client to modify the attributes of a reseller object. In addition to
the standard EPP command elements, the <update> command MUST contain
a <reseller:update> element that identifies the reseller namespace.
The <reseller:update> element contains the following child elements:
o A <reseller:id> element that contains the server-unique identifier
of the reseller object to be updated, as defined in Section 3.1.
o An OPTIONAL <reseller:add> element that contains attribute values
to be added to the object.
o An OPTIONAL <reseller:rem> element that contains attribute values
to be removed from the object.
o An OPTIONAL <reseller:chg> element that contains attribute values
to be changed.
At least one <reseller:add>, <reseller:rem> or <reseller:rem> element
MUST be provided if the command is not being extended. All of these
elements MAY be omitted if an <update> extension is present. The
<reseller:add> and <reseller:rem> elements contain the following
child element:
o Zero or more <reseller:contact> elements that contain the
identifiers for contact objects to be associated with or removed
from the reseller object. Contact object identifiers MUST be
known to the server before the contact object can be associated
with the reseller object.
A <reseller:chg> element contains the following OPTIONAL child
elements. At least one child element MUST be present: