1 Internet Engineering Task Force (IETF) L. Zhou
2 Request for Comments: 8543 CNNIC
3 Category: Standards Track N. Kong
4 ISSN: 2070-1721 Consultant
5 J. Yao
6 CNNIC
7 J. Gould
8 VeriSign, Inc.
9 G. Zhou
10 March 2019
11
12
13 Extensible Provisioning Protocol (EPP) Organization Mapping
14
15 Abstract
16
17 This document describes an Extensible Provisioning Protocol (EPP)
18 mapping for provisioning and management of organization objects
19 stored in a shared central repository.
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/rfc8543.
34
35 Copyright Notice
36
37 Copyright (c) 2019 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
51
52 Zhou, et al. Standards Track [Page 1]
53 RFC 8543 EPP Organization Mapping March 2019
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
60 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3
61 3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4
62 3.2. Organization Roles . . . . . . . . . . . . . . . . . . . 4
63 3.2.1. Role Type . . . . . . . . . . . . . . . . . . . . . . 4
64 3.2.2. Role Status . . . . . . . . . . . . . . . . . . . . . 4
65 3.2.3. Role Identifier . . . . . . . . . . . . . . . . . . . 4
66 3.3. Contact and Client Identifiers . . . . . . . . . . . . . 5
67 3.4. Organization Status Values . . . . . . . . . . . . . . . 5
68 3.5. Role Status Values . . . . . . . . . . . . . . . . . . . 7
69 3.6. Parent Identifier . . . . . . . . . . . . . . . . . . . . 7
70 3.7. URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
71 3.8. Dates and Times . . . . . . . . . . . . . . . . . . . . . 8
72 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 8
73 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 8
74 4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 8
75 4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 10
76 4.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 15
77 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 16
78 4.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 16
79 4.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 20
80 4.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 21
81 4.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 21
82 4.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 21
83 4.3. Offline Review of Requested Actions . . . . . . . . . . . 25
84 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 27
85 6. Internationalization Considerations . . . . . . . . . . . . . 36
86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
87 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 36
88 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 37
89 7.3. Role Type Values Registry . . . . . . . . . . . . . . . . 37
90 7.3.1. Registration Template . . . . . . . . . . . . . . . . 37
91 7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 38
92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
94 9.1. Normative References . . . . . . . . . . . . . . . . . . 39
95 9.2. Informative References . . . . . . . . . . . . . . . . . 40
96 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
98
99
100
101
102
103
104
105
106
107 Zhou, et al. Standards Track [Page 2]
108 RFC 8543 EPP Organization Mapping March 2019
109
110
111 1. Introduction
112
113 There are many entities, such as registrars, resellers, DNS service
114 operators, and privacy proxies, involved in the domain registration
115 business. These kinds of entities have not been formally defined as
116 having an object in Extensible Provisioning Protocol (EPP). This
117 document provides a way to specify them as "organization" entities.
118
119 This document describes an organization object mapping for version
120 1.0 of the EPP [RFC5730]. This mapping is specified using XML 1.0 as
121 described in [W3C.REC-xml-20081126] and XML Schema notation as
122 described in [W3C.REC-xmlschema-1-20041028] and
123 [W3C.REC-xmlschema-2-20041028].
124
125 2. Conventions Used in This Document
126
127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
129 "OPTIONAL" in this document are to be interpreted as described in
130 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
131 capitals, as shown here.
132
133 In 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 examples are provided only to illustrate element
136 relationships and are not a required feature of this specification.
137
138 XML is case sensitive. Unless stated otherwise, XML specifications
139 and examples provided in this document MUST be interpreted in the
140 character case presented.
141
142 The XML namespace prefix "org" is used for the namespace
143 "urn:ietf:params:xml:ns:epp:org-1.0", but implementations MUST NOT
144 depend on it; instead, they should employ a proper namespace-aware
145 XML parser and serializer to interpret and output the XML documents.
146
147 3. Object Attributes
148
149 An EPP organization object has attributes and associated values that
150 can be viewed and modified by the sponsoring client or the server.
151 This section describes each attribute type in detail. The formal
152 syntax for the attribute values described here can be found in the
153 "Formal Syntax" section of this document and in the appropriate
154 normative references.
155
156
157
158
159
160
161
162 Zhou, et al. Standards Track [Page 3]
163 RFC 8543 EPP Organization Mapping March 2019
164
165
166 3.1. Organization Identifier
167
168 All EPP organizations are identified by a server-unique identifier.
169 Organization identifiers are character strings with a specified
170 minimum length, a specified maximum length, and a specified format.
171 Organization identifiers use the "clIDType" client identifier syntax
172 described in [RFC5730]. The corresponding element is <org:id>.
173
174 3.2. Organization Roles
175
176 The organization roles are used to represent the relationship an
177 organization could have. The corresponding element is <org:role>.
178 An organization object MUST always have at least one associated role.
179 Roles can be set only by the client that sponsors an organization
180 object. A client can change the role of an organization object using
181 the EPP <update> command (see Section 4.2.5).
182
183 3.2.1. Role Type
184
185 An organization role MUST have a type field, which may have any of
186 the values listed in Section 7.3. The corresponding element is
187 <org:type>. An organization could have multiple roles with different
188 role types.
189
190 3.2.2. Role Status
191
192 A role of an organization object MAY have its own statuses. The
193 corresponding element is <org:status>. The possible values for the
194 role status are defined in Section 3.5.
195
196 3.2.3. Role Identifier
197
198 A role MAY have a third-party-assigned identifier such as the IANA ID
199 for registrars. The corresponding element is <org:roleID>.
200
201 Example of organization role identifier:
202
203 <org:role>
204 <org:type>registrar</org:type>
205 <org:status>ok</org:status>
206 <org:status>linked</org:status>
207 <org:roleID>1362</org:roleID>
208 </org:role>
209
210
211
212
213
214
215
216
217 Zhou, et al. Standards Track [Page 4]
218 RFC 8543 EPP Organization Mapping March 2019
219
220
221 3.3. Contact and Client Identifiers
222
223 All EPP contacts are identified by server-unique identifiers.
224 Contact identifiers are character strings with a specified minimum
225 length, a specified maximum length, and a specified format. Contact
226 identifiers use the "clIDType" client identifier syntax described in
227 [RFC5730].
228
229 3.4. Organization Status Values
230
231 An organization object MUST always have at least one associated
232 status value. Status values can be set only by the client that
233 sponsors an organization object and by the server on which the object
234 resides. A client can change the status of an organization object
235 using the EPP <update> command. Each status value MAY be accompanied
236 by a string of human-readable text that describes the rationale for
237 the status applied to the object.
238
239 A client MUST NOT alter server status values set by the server. A
240 server MAY alter or override status values set by a client, subject
241 to local server policies. The status of an object MAY change as a
242 result of either a client-initiated transform command or an action
243 performed by a server operator.
244
245 Status values that can be added or removed by a client are prefixed
246 with "client". Corresponding server status values that can be added
247 or removed by a server are prefixed with "server". The "hold" and
248 "terminated" status values are server managed when the organization
249 has no parent identifier (Section 3.6) and otherwise MAY be client
250 managed based on server policy. Other status values that do not
251 begin with either "client" or "server" are server managed.
252
253 Status Value Descriptions:
254
255 o ok: This is the normal status value for an object that has no
256 operations pending or active prohibitions. This value is set and
257 removed by the server as other status values are added or removed.
258
259 o hold: Organization transform commands and new links MUST be
260 rejected.
261
262 o terminated: The organization that has been terminated MUST NOT be
263 linked. Organization transform commands and new links MUST be
264 rejected.
265
266
267
268
269
270
271
272 Zhou, et al. Standards Track [Page 5]
273 RFC 8543 EPP Organization Mapping March 2019
274
275
276 o linked: The organization object has at least one active
277 association with another object. The "linked" status is not
278 explicitly set by the client. Servers should provide services to
279 determine existing object associations.
280
281 o clientLinkProhibited, serverLinkProhibited: Requests to add new
282 links to the organization MUST be rejected.
283
284 o clientUpdateProhibited, serverUpdateProhibited: Requests to update
285 the object (other than to remove this status) MUST be rejected.
286
287 o clientDeleteProhibited, serverDeleteProhibited: Requests to delete
288 the object MUST be rejected.
289
290 o pendingCreate, pendingUpdate, pendingDelete: A transform command
291 has been processed for the object, but the action has not been
292 completed by the server. Server operators can delay action
293 completion for a variety of reasons, such as to allow for human
294 review or third-party action. A transform command that is
295 processed, but whose requested action is pending, is noted with
296 response code 1001.
297
298 "pendingCreate", "ok", "hold", and "terminated" are mutually
299 exclusive statuses. An organization MUST have exactly one of these
300 statuses set.
301
302 "ok" status MAY only be combined with "linked" status.
303
304 A client or server MAY combine "linked" with either
305 "clientLinkProhibited" or "serverLinkProhibited" if new links must be
306 prohibited.
307
308 "pendingDelete" status MUST NOT be combined with either
309 "clientDeleteProhibited" or "serverDeleteProhibited" status.
310
311 The "pendingCreate", "pendingDelete", and "pendingUpdate" status
312 values MUST NOT be combined with each other.
313
314 If "clientUpdateProhibited" or "serverUpdateProhibited" is set, the
315 client will not be able to update the object. For
316 "clientUpdateProhibited", the client will first need to remove
317 "clientUpdateProhibited" prior to attempting to update the object.
318 The server can modify the object at any time.
319
320
321
322
323
324
325
326
327 Zhou, et al. Standards Track [Page 6]
328 RFC 8543 EPP Organization Mapping March 2019
329
330
331 3.5. Role Status Values
332
333 A role SHOULD have at least one associated status value. Valid
334 values include "ok", "linked", "clientLinkProhibited", and
335 "serverLinkProhibited".
336
337 Status Value Descriptions:
338
339 o ok: This is the normal status value for a role that has no
340 operations pending or active prohibitions. This value is set and
341 removed by the server as other status values are added or removed.
342
343 o linked: The role of an organization object has at least one active
344 association with another object. The "linked" status is not
345 explicitly set by the client. Servers SHOULD provide services to
346 determine existing object associations.
347
348 o clientLinkProhibited, serverLinkProhibited: Requests to add new
349 links to the role MUST be rejected.
350
351 3.6. Parent Identifier
352
353 Organizations can have more than one layer. The parent identifier,
354 as defined with the <org:parentId> element, represents the parent
355 organization identifier in a child organization.
356
357 The case of reseller organizations provides an example. The parent
358 identifier is not defined for the top-level reseller, namely the
359 registrar of the registry. An N-tier reseller has a parent reseller
360 and at least one child reseller. A reseller customer has a parent
361 reseller and no child resellers.
362
363 Loops MUST be prohibited. For example: if organization A has
364 organization B as its parent identifier, organization B cannot have
365 organization A as its parent identifier. The same is true for larger
366 loops involving three or more organizations.
367
368 3.7. URL
369
370 The URL represents the organization web home page, as defined with
371 the <org:url> element.
372
373
374
375
376
377
378
379
380
381
382 Zhou, et al. Standards Track [Page 7]
383 RFC 8543 EPP Organization Mapping March 2019
384
385
386 3.8. Dates and Times
387
388 Date and time attribute values MUST be represented in Coordinated
389 Universal Time (UTC) using the Gregorian calendar. The extended
390 date-time form using uppercase "T" and "Z" characters defined in
391 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
392 values, as XML Schema does not support truncated date-time forms or
393 lowercase "T" and "Z" characters.
394
395 4. EPP Command Mapping
396
397 A detailed description of the EPP syntax and semantics can be found
398 in the EPP core protocol specification [RFC5730]. The command
399 mappings described here are specifically for use in provisioning and
400 managing organization information via EPP.
401
402 4.1. EPP Query Commands
403
404 EPP provides two commands to retrieve organization information:
405 <check> to determine if an organization object can be provisioned
406 within a repository and <info> to retrieve detailed information
407 associated with an organization object. This document does not
408 define a mapping for the EPP <transfer> command to retrieve
409 organization-object transfer status information.
410
411 4.1.1. EPP <check> Command
412
413 The EPP <check> command is used to determine if an object can be
414 provisioned within a repository. It provides a hint that allows a
415 client to anticipate the success or failure of provisioning an object
416 using the <create> command, as object-provisioning requirements are
417 ultimately a matter of server policy.
418
419 In addition to the standard EPP command elements, the <check> command
420 MUST contain an <org:check> element. This element or its ancestor
421 element MUST identify the organization namespace
422 "urn:ietf:params:xml:ns:epp:org-1.0". The <org:check> element
423 contains the following child elements:
424
425 o One or more <org:id> elements that contain the server-unique
426 identifier of the organization objects to be queried.
427
428
429
430
431
432
433
434
435
436
437 Zhou, et al. Standards Track [Page 8]
438 RFC 8543 EPP Organization Mapping March 2019
439
440
441 Example <check> command:
442
443 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
444 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
445 C: <command>
446 C: <check>
447 C: <org:check
448 C: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
449 C: <org:id>res1523</org:id>
450 C: <org:id>re1523</org:id>
451 C: <org:id>1523res</org:id>
452 C: </org:check>
453 C: </check>
454 C: <clTRID>ABC-12345</clTRID>
455 C: </command>
456 C:</epp>
457
458 When a <check> command has been processed successfully, the EPP
459 <resData> element MUST contain a child <org:chkData> element. This
460 element or its ancestor element MUST identify the organization
461 namespace "urn:ietf:params:xml:ns:epp:org-1.0". The <org:chkData>
462 element contains one or more <org:cd> elements that contain the
463 following child elements:
464
465 o An <org:id> element that identifies the queried object. This
466 element MUST contain an "avail" attribute whose value indicates
467 object availability (can it be provisioned or not) at the moment
468 the <check> command was completed. A value of "1" or "true" means
469 that the object can be provisioned. A value of "0" or "false"
470 means that the object cannot be provisioned.
471
472 o An OPTIONAL <org:reason> element that may be provided when an
473 object cannot be provisioned. If present, this element contains
474 server-specific text to help explain why the object cannot be
475 provisioned. This text MUST be represented in the response
476 language previously negotiated with the client; an OPTIONAL "lang"
477 attribute as defined in [RFC5646] may be present to identify the
478 language if the negotiated value is something other than the
479 default value of "en"(English).
480
481
482
483
484
485
486
487
488
489
490
491
492 Zhou, et al. Standards Track [Page 9]
493 RFC 8543 EPP Organization Mapping March 2019
494
495
496 Example <check> response:
497
498 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
499 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
500 S: <response>
501 S: <result code="1000">
502 S: <msg lang="en">Command completed successfully</msg>
503 S: </result>
504 S: <resData>
505 S: <org:chkData
506 S: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
507 S: <org:cd>
508 S: <org:id avail="1">res1523</org:id>
509 S: </org:cd>
510 S: <org:cd>
511 S: <org:id avail="0">re1523</org:id>
512 S: <org:reason lang="en">In use</org:reason>
513 S: </org:cd>
514 S: <org:cd>
515 S: <org:id avail="1">1523res</org:id>
516 S: </org:cd>
517 S: </org:chkData>
518 S: </resData>
519 S: <trID>
520 S: <clTRID>ABC-12345</clTRID>
521 S: <svTRID>54322-XYZ</svTRID>
522 S: </trID>
523 S: </response>
524 S:</epp>
525
526 An EPP error response MUST be returned if a <check> command cannot be
527 processed for any reason.
528
529 4.1.2. EPP <info> Command
530
531 The EPP <info> command is used to retrieve information associated
532 with an organization object. In addition to the standard EPP command
533 elements, the <info> command MUST contain an <org:info> element.
534 This element or its ancestor element MUST identify the organization
535 namespace "urn:ietf:params:xml:ns:epp:org-1.0". The <org:info>
536 element contains the following child element:
537
538 o An <org:id> element that contains the server-unique identifier of
539 the organization object to be queried.
540
541
542
543
544
545
546
547 Zhou, et al. Standards Track [Page 10]
548 RFC 8543 EPP Organization Mapping March 2019
549
550
551 Example <info> command:
552
553 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
554 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
555 C: <command>
556 C: <info>
557 C: <org:info
558 C: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
559 C: <org:id>res1523</org:id>
560 C: </org:info>
561 C: </info>
562 C: <clTRID>ABC-12345</clTRID>
563 C: </command>
564 C:</epp>
565
566 When an <info> command has been processed successfully, the EPP
567 <resData> element MUST contain a child <org:infData> element. This
568 element or its ancestor element MUST identify the organization
569 namespace "urn:ietf:params:xml:ns:epp:org-1.0". The <org:infData>
570 element contains the following child elements:
571
572 o An <org:id> element that contains the server-unique identifier of
573 the organization object, as defined in Section 3.1.
574
575 o An <org:roid> element that contains the Repository Object
576 Identifier assigned to the organization object when the object was
577 created.
578
579 o One or more <org:role> elements that contain the role type, role
580 statuses, and optional role ID of the organization.
581
582 * An <org:type> element that contains the type of the
583 organization, as defined in Section 3.2.
584
585 * One or more <org:status> elements that contain the role
586 statuses. The values of the role status are defined in
587 Section 3.5.
588
589 * An OPTIONAL <org:roleID> element that contains a third-party-
590 assigned identifier, such as IANA ID for registrars, as defined
591 in Section 3.2.3.
592
593 o One or more <org:status> elements that contain the operational
594 status of the organization, as defined in Section 3.4.
595
596 o An OPTIONAL <org:parentId> element that contains the identifier of
597 the parent object, as defined in Section 3.6.
598
599
600
601
602 Zhou, et al. Standards Track [Page 11]
603 RFC 8543 EPP Organization Mapping March 2019
604
605
606 o Zero to two <org:postalInfo> elements that contain postal-address
607 information. Two elements are provided so that address
608 information can be provided in both internationalized and
609 localized forms; a "type" attribute is used to identify the two
610 forms. If an internationalized form (type="int") is provided,
611 element content MUST be represented in a subset of Unicode
612 [UNICODE] in the range U+0020 - U+007E. If a localized form
613 (type="loc") is provided, element content MAY be represented in
614 unrestricted UTF-8. The <org:postalInfo> element contains the
615 following child elements:
616
617 * An <org:name> element that contains the name of the
618 organization.
619
620 * An OPTIONAL <org:addr> element that contains address
621 information associated with the organization. An <org:addr>
622 element contains the following child elements:
623
624 + One, two, or three <org:street> elements that contain the
625 organization's street address.
626
627 + An <org:city> element that contains the organization's city.
628
629 + An OPTIONAL <org:sp> element that contains the
630 organization's state or province.
631
632 + An OPTIONAL <org:pc> element that contains the
633 organization's postal code.
634
635 + An <org:cc> element that contains the alpha-2 organization's
636 country code. The detailed format of this element is
637 described in Section 2.4.3 of [RFC5733].
638
639 o An OPTIONAL <org:voice> element that contains the organization's
640 voice telephone number. The detailed format of this element is
641 described in Section 2.5 of [RFC5733].
642
643 o An OPTIONAL <org:fax> element that contains the organization's
644 facsimile telephone number. The detailed format of this element
645 is described in Section 2.5 of [RFC5733].
646
647 o An OPTIONAL <org:email> element that contains the organization's
648 email address. The detailed format of this element is described
649 in [RFC5322].
650
651 o An OPTIONAL <org:url> element that contains the URL to the website
652 of the organization. The detailed format of this element is
653 described in [RFC3986].
654
655
656
657 Zhou, et al. Standards Track [Page 12]
658 RFC 8543 EPP Organization Mapping March 2019
659
660
661 o Zero or more <org:contact> elements that contain identifiers for
662 the contact objects to be associated with the organization object.
663 Contact object identifiers MUST be known to the server before the
664 contact object can be associated with the organization object.
665 The required "type" is used to represent contact types. The type
666 values include "admin", "tech", "billing", "abuse", and "custom".
667 The OPTIONAL "typeName" attribute is used to define the name of a
668 "custom" type.
669
670 o An OPTIONAL <org:clID> element that contains the organization
671 identifier of the sponsoring client. There is no <org:clID>
672 element if the organization is managed by the registry.
673
674 o An <org:crID> element that contains the identifier of the client
675 that created the organization object.
676
677 o An <org:crDate> element that contains the date and time of
678 organization object creation.
679
680 o An <org:upID> element that contains the identifier of the client
681 that last updated the organization object. This element MUST NOT
682 be present if the organization has never been modified.
683
684 o An <org:upDate> element that contains the date and time of the
685 most recent organization object modification. This element MUST
686 NOT be present if the organization object has never been modified.
687
688 Example <info> response for "Example Registrar Inc." organization
689 object with identifier "registrar1362":
690
691 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
692 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
693 S: <response>
694 S: <result code="1000">
695 S: <msg lang="en">Command completed successfully</msg>
696 S: </result>
697 S: <resData>
698 S: <org:infData
699 S: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
700 S: <org:id>registrar1362</org:id>
701 S: <org:roid>registrar1362-REP</org:roid>
702 S: <org:role>
703 S: <org:type>registrar</org:type>
704 S: <org:status>ok</org:status>
705 S: <org:status>linked</org:status>
706 S: <org:roleID>1362</org:roleID>
707 S: </org:role>
708 S: <org:status>ok</org:status>
709
710
711
712 Zhou, et al. Standards Track [Page 13]
713 RFC 8543 EPP Organization Mapping March 2019
714
715
716 S: <org:postalInfo type="int">
717 S: <org:name>Example Registrar Inc.</org:name>
718 S: <org:addr>
719 S: <org:street>123 Example Dr.</org:street>
720 S: <org:street>Suite 100</org:street>
721 S: <org:city>Dulles</org:city>
722 S: <org:sp>VA</org:sp>
723 S: <org:pc>20166-6503</org:pc>
724 S: <org:cc>US</org:cc>
725 S: </org:addr>
726 S: </org:postalInfo>
727 S: <org:voice x="1234">+1.7035555555</org:voice>
728 S: <org:fax>+1.7035555556</org:fax>
729 S: <org:email>contact@organization.example</org:email>
730 S: <org:url>https://organization.example</org:url>
731 S: <org:contact type="admin">sh8013</org:contact>
732 S: <org:contact type="billing">sh8013</org:contact>
733 S: <org:contact type="custom"
734 S: typeName="legal">sh8013</org:contact>
735 S: <org:crID>ClientX</org:crID>
736 S: <org:crDate>2018-04-03T22:00:00.0Z</org:crDate>
737 S: <org:upID>ClientX</org:upID>
738 S: <org:upDate>2018-12-03T09:00:00.0Z</org:upDate>
739 S: </org:infData>
740 S: </resData>
741 S: <trID>
742 S: <clTRID>ABC-12345</clTRID>
743 S: <svTRID>54322-XYZ</svTRID>
744 S: </trID>
745 S: </response>
746 S:</epp>
747
748 Example <info> response for "Example Reseller Inc." organization
749 object of reseller type managed by identifier "registrar1362":
750
751 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
752 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
753 S: <response>
754 S: <result code="1000">
755 S: <msg lang="en">Command completed successfully</msg>
756 S: </result>
757 S: <resData>
758 S: <org:infData
759 S: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
760 S: <org:id>reseller1523</org:id>
761 S: <org:roid>reseller1523-REP</org:roid>
762 S: <org:role>
763 S: <org:type>reseller</org:type>
764
765
766
767 Zhou, et al. Standards Track [Page 14]
768 RFC 8543 EPP Organization Mapping March 2019
769
770
771 S: <org:status>ok</org:status>
772 S: <org:status>linked</org:status>
773 S: </org:role>
774 S: <org:status>ok</org:status>
775 S: <org:parentId>registrar1362</org:parentId>
776 S: <org:postalInfo type="int">
777 S: <org:name>Example Reseller Inc.</org:name>
778 S: <org:addr>
779 S: <org:street>123 Example Dr.</org:street>
780 S: <org:street>Suite 100</org:street>
781 S: <org:city>Dulles</org:city>
782 S: <org:sp>VA</org:sp>
783 S: <org:pc>20166-6503</org:pc>
784 S: <org:cc>US</org:cc>
785 S: </org:addr>
786 S: </org:postalInfo>
787 S: <org:fax>+1.7035555556</org:fax>
788 S: <org:url>https://organization.example</org:url>
789 S: <org:contact type="admin">sh8013</org:contact>
790 S: <org:clID>1362</org:clID>
791 S: <org:crID>ClientX</org:crID>
792 S: <org:crDate>2018-04-03T22:00:00.0Z</org:crDate>
793 S: <org:upID>ClientX</org:upID>
794 S: <org:upDate>2018-12-03T09:00:00.0Z</org:upDate>
795 S: </org:infData>
796 S: </resData>
797 S: <trID>
798 S: <clTRID>ABC-12345</clTRID>
799 S: <svTRID>54322-XYZ</svTRID>
800 S: </trID>
801 S: </response>
802 S:</epp>
803
804 An EPP error response MUST be returned if an <info> command cannot be
805 processed for any reason.
806
807 4.1.3. EPP <transfer> Query Command
808
809 The transfer semantics do not apply to organization objects. No EPP
810 <transfer> query command is defined in this document.
811
812
813
814
815
816
817
818
819
820
821
822 Zhou, et al. Standards Track [Page 15]
823 RFC 8543 EPP Organization Mapping March 2019
824
825
826 4.2. EPP Transform Commands
827
828 This document provides three commands to transform organization
829 object information: <create> to create an instance of an organization
830 object, <delete> to delete an instance of an organization object, and
831 <update> to change information associated with an organization
832 object. This document does not define a mapping for the EPP
833 <transfer> and <renew> command.
834
835 Transform commands are typically processed and completed in real
836 time. Server operators MAY receive and process transform commands
837 but defer completing the requested action if human or third-party
838 review is required before the requested action can be completed. In
839 such situations, the server MUST return a 1001 response code to the
840 client to note that the command has been received and processed but
841 that the requested action is pending. The server MUST also manage
842 the status of the object that is the subject of the command to
843 reflect the initiation and completion of the requested action. Once
844 the action has been completed, the client MUST be notified using a
845 service message that the action has been completed and the status of
846 the object has changed. Other notification methods MAY be used in
847 addition to the required service message.
848
849 4.2.1. EPP <create> Command
850
851 The EPP <create> command provides a transform operation that allows a
852 client to create an organization object. In addition to the standard
853 EPP command elements, the <create> command MUST contain an
854 <org:create> element. This element or its ancestor element MUST
855 identify the organization namespace "urn:ietf:params:xml:ns:epp:org-
856 1.0". The <org:create> element contains the following child
857 elements:
858
859 o An <org:id> element that contains the desired server-unique
860 identifier for the organization to be created, as defined in
861 Section 3.1.
862
863 o One or more <org:role> elements that contain the role type, role
864 statuses, and optional role ID of the organization.
865
866 * An <org:type> element that contains the type of the
867 organization, as defined in Section 3.2.
868
869 * Zero or more <org:status> elements that contain the role
870 statuses. The possible values of the role statuses are defined
871 in Section 3.5.
872
873
874
875
876
877 Zhou, et al. Standards Track [Page 16]
878 RFC 8543 EPP Organization Mapping March 2019
879
880
881 * An OPTIONAL <org:roleID> element that contains a third-party-
882 assigned identifier, such as IANA ID for registrars, as defined
883 in Section 3.2.3.
884
885 o Zero or more <org:status> elements that contain the operational
886 status of the organization, as defined in Section 3.4.
887
888 o An OPTIONAL <org:parentId> element that contains the identifier of
889 the parent object, as defined in Section 3.6.
890
891 o Zero to two <org:postalInfo> elements that contain postal-address
892 information. Two elements are provided so that address
893 information can be provided in both internationalized and
894 localized forms; a "type" attribute is used to identify the two
895 forms. If an internationalized form (type="int") is provided,
896 element content MUST be represented in a subset of Unicode
897 [UNICODE] in the range U+0020 - U+007E. If a localized form
898 (type="loc") is provided, element content MAY be represented in
899 unrestricted UTF-8. The <org:postalInfo> element contains the
900 following child elements:
901
902 * An <org:name> element that contains the name of the
903 organization.
904
905 * An OPTIONAL <org:addr> element that contains address
906 information associated with the organization. An <org:addr>
907 element contains the following child elements:
908
909 + One, two, or three <org:street> elements that contain the
910 organization's street address.
911
912 + An <org:city> element that contains the organization's city.
913
914 + An OPTIONAL <org:sp> element that contains the
915 organization's state or province.
916
917 + An OPTIONAL <org:pc> element that contains the
918 organization's postal code.
919
920 + An <org:cc> element that contains the alpha-2 organization's
921 country code. The detailed format of this element is
922 described in Section 2.4.3 of [RFC5733].
923
924 o An OPTIONAL <org:voice> element that contains the organization's
925 voice telephone number. The detailed format of this element is
926 described in Section 2.5 of [RFC5733].
927
928
929
930
931
932 Zhou, et al. Standards Track [Page 17]
933 RFC 8543 EPP Organization Mapping March 2019
934
935
936 o An OPTIONAL <org:fax> element that contains the organization's
937 facsimile telephone number. The detailed format of this element
938 is described in Section 2.5 of [RFC5733].
939
940 o An OPTIONAL <org:email> element that contains the organization's
941 email address. The detailed format of this element is described
942 of [RFC5322].
943
944 o An OPTIONAL <org:url> element that contains the URL to the website
945 of the organization. The detailed format of this element is
946 described in [RFC3986].
947
948 o Zero or more <org:contact> elements that contain identifiers for
949 the contact objects associated with the organization object.
950
951 Example <create> command:
952
953 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
954 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
955 C: <command>
956 C: <create>
957 C: <org:create
958 C: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
959 C: <org:id>res1523</org:id>
960 C: <org:role>
961 C: <org:type>reseller</org:type>
962 C: </org:role>
963 C: <org:parentId>1523res</org:parentId>
964 C: <org:postalInfo type="int">
965 C: <org:name>Example Organization Inc.</org:name>
966 C: <org:addr>
967 C: <org:street>123 Example Dr.</org:street>
968 C: <org:street>Suite 100</org:street>
969 C: <org:city>Dulles</org:city>
970 C: <org:sp>VA</org:sp>
971 C: <org:pc>20166-6503</org:pc>
972 C: <org:cc>US</org:cc>
973 C: </org:addr>
974 C: </org:postalInfo>
975 C: <org:voice x="1234">+1.7035555555</org:voice>
976 C: <org:fax>+1.7035555556</org:fax>
977 C: <org:email>contact@organization.example</org:email>
978 C: <org:url>https://organization.example</org:url>
979 C: <org:contact type="admin">sh8013</org:contact>
980 C: <org:contact type="billing">sh8013</org:contact>
981 C: </org:create>
982 C: </create>
983 C: <clTRID>ABC-12345</clTRID>
984
985
986
987 Zhou, et al. Standards Track [Page 18]
988 RFC 8543 EPP Organization Mapping March 2019
989
990
991 C: </command>
992 C:</epp>
993
994 When a <create> command has been processed successfully, the EPP
995 <resData> element MUST contain a child <org:creData> element. This
996 element or its ancestor element MUST identify the organization
997 namespace "urn:ietf:params:xml:ns:epp:org-1.0". The <org:creData>
998 element contains the following child elements:
999
1000 o An <org:id> element that contains the server-unique identifier for
1001 the created organization, as defined in Section 3.1.
1002
1003 o An <org:crDate> element that contains the date and time of
1004 organization-object creation.
1005
1006 Example <create> response:
1007
1008 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
1009 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1010 S: <response>
1011 S: <result code="1000">
1012 S: <msg lang="en">Command completed successfully</msg>
1013 S: </result>
1014 S: <resData>
1015 S: <org:creData
1016 S: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
1017 S: <org:id>res1523</org:id>
1018 S: <org:crDate>2018-04-03T22:00:00.0Z</org:crDate>
1019 S: </org:creData>
1020 S: </resData>
1021 S: <trID>
1022 S: <clTRID>ABC-12345</clTRID>
1023 S: <svTRID>54321-XYZ</svTRID>
1024 S: </trID>
1025 S: </response>
1026 S:</epp>
1027
1028 An EPP error response MUST be returned if a <create> command cannot
1029 be processed for any reason.
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042 Zhou, et al. Standards Track [Page 19]
1043 RFC 8543 EPP Organization Mapping March 2019
1044
1045
1046 4.2.2. EPP <delete> Command
1047
1048 The EPP <delete> command provides a transform operation that allows a
1049 client to delete an organization object. In addition to the standard
1050 EPP command elements, the <delete> command MUST contain an
1051 <org:delete> element. This element or its ancestor element MUST
1052 identify the organization namespace "urn:ietf:params:xml:ns:epp:org-
1053 1.0". The <org:delete> element MUST contain the following child
1054 element:
1055
1056 o An <org:id> element that contains the server-unique identifier of
1057 the organization object to be deleted, as defined in Section 3.1.
1058
1059 An organization object MUST NOT be deleted if it is associated with
1060 other known objects. An associated organization MUST NOT be deleted
1061 until associations with other known objects have been broken. A
1062 server MUST notify clients that object relationships exist by sending
1063 a 2305 error response code when a <delete> command is attempted and
1064 fails due to existing object relationships.
1065
1066 Example <delete> command:
1067
1068 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
1069 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1070 C: <command>
1071 C: <delete>
1072 C: <org:delete
1073 C: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
1074 C: <org:id>res1523</org:id>
1075 C: </org:delete>
1076 C: </delete>
1077 C: <clTRID>ABC-12345</clTRID>
1078 C: </command>
1079 C:</epp>
1080
1081 When a <delete> command has been processed successfully, a server
1082 MUST respond with an EPP response with no <resData> element.
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097 Zhou, et al. Standards Track [Page 20]
1098 RFC 8543 EPP Organization Mapping March 2019
1099
1100
1101 Example <delete> response:
1102
1103 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
1104 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1105 S: <response>
1106 S: <result code="1000">
1107 S: <msg lang="en">Command completed successfully</msg>
1108 S: </result>
1109 S: <trID>
1110 S: <clTRID>ABC-12345</clTRID>
1111 S: <svTRID>54321-XYZ</svTRID>
1112 S: </trID>
1113 S: </response>
1114 S:</epp>
1115
1116 An EPP error response MUST be returned if a <delete> command cannot
1117 be processed for any reason.
1118
1119 4.2.3. EPP <renew> Command
1120
1121 Renewal semantics do not apply to organization objects, so there is
1122 no mapping defined for the EPP <renew> command.
1123
1124 4.2.4. EPP <transfer> Command
1125
1126 Transfer semantics do not apply to organization objects, so there is
1127 no mapping defined for the EPP <transfer> command.
1128
1129 4.2.5. EPP <update> Command
1130
1131 The EPP <update> command provides a transform operation that allows a
1132 client to modify the attributes of an organization object. In
1133 addition to the standard EPP command elements, the <update> command
1134 MUST contain an <org:update> element. This element or its ancestor
1135 element MUST identify the organization namespace
1136 "urn:ietf:params:xml:ns:epp:org-1.0". The <org:update> element
1137 contains the following child elements:
1138
1139 o An <org:id> element that contains the server-unique identifier of
1140 the organization object to be updated, as defined in Section 3.1.
1141
1142 o An OPTIONAL <org:add> element that contains attribute values to be
1143 added to the object.
1144
1145 o An OPTIONAL <org:rem> element that contains attribute values to be
1146 removed from the object.
1147
1148
1149
1150
1151
1152 Zhou, et al. Standards Track [Page 21]
1153 RFC 8543 EPP Organization Mapping March 2019
1154
1155
1156 o An OPTIONAL <org:chg> element that contains attribute values to be
1157 changed.
1158
1159 At least one <org:add>, <org:rem>, or <org:chg> element MUST be
1160 provided if the command is not being extended. All of these elements
1161 MAY be omitted if an <update> extension is present. The OPTIONAL
1162 <org:add> and <org:rem> elements contain the following child
1163 elements:
1164
1165 o Zero or more <org:contact> elements that contain the identifiers
1166 for contact objects to be associated with or removed from the
1167 organization object. Contact object identifiers MUST be known to
1168 the server before the contact object can be associated with the
1169 organization object.
1170
1171 o Zero or more <org:role> elements that contain the role type, role
1172 statuses, and optional role ID of the organization.
1173
1174 * An <org:type> element that contains the role type of the
1175 organization, as defined in Section 3.2. The role type
1176 uniquely identifies the role to update.
1177
1178 * Zero or more <org:status> elements that contain the role
1179 statuses. The values of the role status are defined in
1180 Section 3.5.
1181
1182 * An OPTIONAL <org:roleID> element that contains a third-party-
1183 assigned identifier, such as IANA ID for registrars, as defined
1184 in Section 3.2.3.
1185
1186 o Zero or more <org:status> elements that contain the operational
1187 status of the organization.
1188
1189 An OPTIONAL <org:chg> element contains the following child elements,
1190 where at least one child element MUST be present:
1191
1192 o An OPTIONAL <org:parentId> element that contains the identifier of
1193 the parent object.
1194
1195 o Zero to two <org:postalInfo> elements that contain postal-address
1196 information. Two elements are provided so that address
1197 information can be provided in both internationalized and
1198 localized forms; a "type" attribute is used to identify the two
1199 forms. If an internationalized form (type="int") is provided,
1200 element content MUST be represented in a subset of Unicode
1201 [UNICODE] in the range U+0020 - U+007E. If a localized form
1202 (type="loc") is provided, element content MAY be represented in
1203 unrestricted UTF-8. The change of the postal info is defined as a
1204
1205
1206
1207 Zhou, et al. Standards Track [Page 22]
1208 RFC 8543 EPP Organization Mapping March 2019
1209
1210
1211 replacement of that postal info element with the contents of the
1212 sub-elements included in the <update> command. An empty
1213 <org:postalInfo> element is supported to allow a type of postal
1214 info to be removed. The <org:postalInfo> element contains the
1215 following child elements:
1216
1217 * An <org:name> element that contains the name of the
1218 organization.
1219
1220 * An OPTIONAL <org:addr> element that contains address
1221 information associated with the organization. An <org:addr>
1222 element contains the following child elements:
1223
1224 + One, two, or three <org:street> elements that contain the
1225 organization's street address.
1226
1227 + An <org:city> element that contains the organization's city.
1228
1229 + An OPTIONAL <org:sp> element that contains the
1230 organization's state or province.
1231
1232 + An OPTIONAL <org:pc> element that contains the
1233 organization's postal code.
1234
1235 + An <org:cc> element that contains the alpha-2 organization's
1236 country code. The detailed format of this element is
1237 described in Section 2.4.3 of [RFC5733].
1238
1239 o An OPTIONAL <org:voice> element that contains the organization's
1240 voice telephone number. The detailed format of this element is
1241 described in Section 2.5 of [RFC5733].
1242
1243 o An OPTIONAL <org:fax> element that contains the organization's
1244 facsimile telephone number. The detailed format of this element
1245 is described in Section 2.5 of [RFC5733].
1246
1247 o An OPTIONAL <org:email> element that contains the organization's
1248 email address. The detailed format of this element is described
1249 in [RFC5322].
1250
1251 o An OPTIONAL <org:url> element that contains the URL to the website
1252 of the organization. The detailed format of this element is
1253 described in [RFC3986].
1254
1255
1256
1257
1258
1259
1260
1261
1262 Zhou, et al. Standards Track [Page 23]
1263 RFC 8543 EPP Organization Mapping March 2019
1264
1265
1266 Example <update> command:
1267
1268 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
1269 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1270 C: <command>
1271 C: <update>
1272 C: <org:update
1273 C: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
1274 C: <org:id>res1523</org:id>
1275 C: <org:add>
1276 C: <org:contact type="tech">sh8013</org:contact>
1277 C: <org:role>
1278 C: <org:type>privacyproxy</org:type>
1279 C: <org:status>clientLinkProhibited</org:status>
1280 C: </org:role>
1281 C: <org:status>clientLinkProhibited</org:status>
1282 C: </org:add>
1283 C: <org:rem>
1284 C: <org:contact type="billing">sh8014</org:contact>
1285 C: <org:role>
1286 C: <org:type>reseller</org:type>
1287 C: </org:role>
1288 C: </org:rem>
1289 C: <org:chg>
1290 C: <org:postalInfo type="int">
1291 C: <org:addr>
1292 C: <org:street>124 Example Dr.</org:street>
1293 C: <org:street>Suite 200</org:street>
1294 C: <org:city>Dulles</org:city>
1295 C: <org:sp>VA</org:sp>
1296 C: <org:pc>20166-6503</org:pc>
1297 C: <org:cc>US</org:cc>
1298 C: </org:addr>
1299 C: </org:postalInfo>
1300 C: <org:voice>+1.7034444444</org:voice>
1301 C: <org:fax/>
1302 C: </org:chg>
1303 C: </org:update>
1304 C: </update>
1305 C: <clTRID>ABC-12345</clTRID>
1306 C: </command>
1307 C:</epp>
1308
1309 When an <update> command has been processed successfully, a server
1310 MUST respond with an EPP response with no <resData> element.
1311
1312
1313
1314
1315
1316
1317 Zhou, et al. Standards Track [Page 24]
1318 RFC 8543 EPP Organization Mapping March 2019
1319
1320
1321 Example <update> response:
1322
1323 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
1324 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1325 S: <response>
1326 S: <result code="1000">
1327 S: <msg lang="en">Command completed successfully</msg>
1328 S: </result>
1329 S: <trID>
1330 S: <clTRID>ABC-12345</clTRID>
1331 S: <svTRID>54321-XYZ</svTRID>
1332 S: </trID>
1333 S: </response>
1334 S:</epp>
1335
1336 An EPP error response MUST be returned if an <update> command cannot
1337 be processed for any reason.
1338
1339 4.3. Offline Review of Requested Actions
1340
1341 Commands are processed by a server in the order they are received
1342 from a client. Though an immediate response confirming receipt and
1343 processing of the command is produced by the server, a server
1344 operator MAY perform an offline review of requested transform
1345 commands before completing the requested action. In such situations,
1346 the response from the server MUST clearly note that the transform
1347 command has been received and processed, but the requested action is
1348 pending. The status in the response of the corresponding object MUST
1349 clearly reflect processing of the pending action. The server MUST
1350 notify the client when offline processing of the action has been
1351 completed.
1352
1353 Examples describing a <create> command that requires offline review
1354 are included here. Note the result code and message returned in
1355 response to the <create> command.
1356
1357 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
1358 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1359 S: <response>
1360 S: <result code="1001">
1361 S: <msg lang="en">Command completed successfully;
1362 S: action pending</msg>
1363 S: </result>
1364 S: <resData>
1365 S: <org:creData
1366 S: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
1367 S: <org:id>res1523</org:id>
1368 S: <org:crDate>2018-04-03T22:00:00.0Z</org:crDate>
1369
1370
1371
1372 Zhou, et al. Standards Track [Page 25]
1373 RFC 8543 EPP Organization Mapping March 2019
1374
1375
1376 S: </org:creData>
1377 S: </resData>
1378 S: <trID>
1379 S: <clTRID>ABC-12345</clTRID>
1380 S: <svTRID>54321-XYZ</svTRID>
1381 S: </trID>
1382 S: </response>
1383 S:</epp>
1384
1385 The status of the organization object after returning this response
1386 MUST include "pendingCreate". The server operator reviews the
1387 request offline and informs the client of the outcome of the review
1388 by queuing a service message for retrieval via the <poll> command; it
1389 MAY additionally use an out-of-band mechanism to inform the client of
1390 the outcome.
1391
1392 The service message MUST contain text that describes the notification
1393 in the child <msg> element of the response <msgQ> element. In
1394 addition, the EPP <resData> element MUST contain a child
1395 <org:panData> element. This element or its ancestor element MUST
1396 identify the organization namespace "urn:ietf:params:xml:ns:epp:org-
1397 1.0". The <org:panData> element contains the following child
1398 elements:
1399
1400 o An <org:id> element that contains the server-unique identifier of
1401 the organization object. The <org:id> element contains a REQUIRED
1402 "paResult" attribute. A positive boolean value indicates that the
1403 request has been approved and completed. A negative boolean value
1404 indicates that the request has been denied and the requested
1405 action has not been taken.
1406
1407 o An <org:paTRID> element that contains the client transaction
1408 identifier and server transaction identifier returned with the
1409 original response to process the command. The client transaction
1410 identifier is OPTIONAL and will only be returned if the client
1411 provided an identifier with the original <create> command.
1412
1413 o An <org:paDate> element that contains the date and time describing
1414 when review of the requested action was completed.
1415
1416 Example "review completed" service message:
1417
1418 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
1419 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
1420 S: <response>
1421 S: <result code="1301">
1422 S: <msg lang="en">Command completed successfully;
1423 S: ack to dequeue</msg>
1424
1425
1426
1427 Zhou, et al. Standards Track [Page 26]
1428 RFC 8543 EPP Organization Mapping March 2019
1429
1430
1431 S: </result>
1432 S: <msgQ count="5" id="12345">
1433 S: <qDate>2018-04-04T22:01:00.0Z</qDate>
1434 S: <msg>Pending action completed successfully.</msg>
1435 S: </msgQ>
1436 S: <resData>
1437 S: <org:panData
1438 S: xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0">
1439 S: <org:id paResult="1">res1523</org:id>
1440 S: <org:paTRID>
1441 S: <clTRID>ABC-12345</clTRID>
1442 S: <svTRID>54321-XYZ</svTRID>
1443 S: </org:paTRID>
1444 S: <org:paDate>2018-04-04T22:00:00.0Z</org:paDate>
1445 S: </org:panData>
1446 S: </resData>
1447 S: <trID>
1448 S: <clTRID>BCD-23456</clTRID>
1449 S: <svTRID>65432-WXY</svTRID>
1450 S: </trID>
1451 S: </response>
1452 S:</epp>
1453
1454 5. Formal Syntax
1455
1456 An EPP object mapping is specified in XML Schema notation. The
1457 formal syntax presented here is a complete schema representation of
1458 the object mapping suitable for automated validation of EPP XML
1459 instances. The BEGIN and END tags are not part of the schema; they
1460 are used to note the beginning and ending of the schema for URI
1461 registration purposes.
1462
1463 BEGIN
1464 <?xml version="1.0" encoding="UTF-8"?>
1465
1466 <schema targetNamespace="urn:ietf:params:xml:ns:epp:org-1.0"
1467 xmlns:org="urn:ietf:params:xml:ns:epp:org-1.0"
1468 xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
1469 xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
1470 xmlns="http://www.w3.org/2001/XMLSchema"
1471 elementFormDefault="qualified">
1472
1473 <!--
1474 Import common element types.
1475 -->
1476 <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
1477 <import namespace="urn:ietf:params:xml:ns:epp-1.0"/>
1478
1479
1480
1481
1482 Zhou, et al. Standards Track [Page 27]
1483 RFC 8543 EPP Organization Mapping March 2019
1484
1485
1486 <annotation>
1487 <documentation>
1488 Extensible Provisioning Protocol v1.0
1489 organization provisioning schema.
1490 </documentation>
1491 </annotation>
1492
1493 <!--
1494 Child elements found in EPP commands.
1495 -->
1496 <element name="create" type="org:createType"/>
1497 <element name="delete" type="org:sIDType"/>
1498 <element name="update" type="org:updateType"/>
1499 <element name="check" type="org:mIDType"/>
1500 <element name="info" type="org:infoType"/>
1501 <element name="panData" type="org:panDataType"/>
1502
1503 <!--
1504 Utility types.
1505 -->
1506 <simpleType name="statusType">
1507 <restriction base="token">
1508 <enumeration value="ok"/>
1509 <enumeration value="hold"/>
1510 <enumeration value="terminated"/>
1511 <enumeration value="clientDeleteProhibited"/>
1512 <enumeration value="clientUpdateProhibited"/>
1513 <enumeration value="clientLinkProhibited"/>
1514 <enumeration value="linked"/>
1515 <enumeration value="pendingCreate"/>
1516 <enumeration value="pendingUpdate"/>
1517 <enumeration value="pendingDelete"/>
1518 <enumeration value="serverDeleteProhibited"/>
1519 <enumeration value="serverUpdateProhibited"/>
1520 <enumeration value="serverLinkProhibited"/>
1521 </restriction>
1522 </simpleType>
1523
1524 <simpleType name="roleStatusType">
1525 <restriction base="token">
1526 <enumeration value="ok"/>
1527 <enumeration value="clientLinkProhibited"/>
1528 <enumeration value="linked"/>
1529 <enumeration value="serverLinkProhibited"/>
1530 </restriction>
1531 </simpleType>
1532
1533 <complexType name="roleType">
1534
1535
1536
1537 Zhou, et al. Standards Track [Page 28]
1538 RFC 8543 EPP Organization Mapping March 2019
1539
1540
1541 <sequence>
1542 <element name="type" type="token"/>
1543 <element name="status" type="org:roleStatusType"
1544 minOccurs="0" maxOccurs="3"/>
1545 <element name="roleID" type="token" minOccurs="0"/>
1546 </sequence>
1547 </complexType>
1548
1549 <complexType name="postalInfoType">
1550 <sequence>
1551 <element name="name"
1552 type="org:postalLineType"/>
1553 <element name="addr"
1554 type="org:addrType" minOccurs="0"/>
1555 </sequence>
1556 <attribute name="type"
1557 type="org:postalInfoEnumType"
1558 use="required"/>
1559 </complexType>
1560
1561 <complexType name="contactType">
1562 <simpleContent>
1563 <extension base="eppcom:clIDType">
1564 <attribute name="type" type="org:contactAttrType"
1565 use="required"/>
1566 <attribute name="typeName" type="token"/>
1567 </extension>
1568 </simpleContent>
1569 </complexType>
1570
1571 <simpleType name="contactAttrType">
1572 <restriction base="token">
1573 <enumeration value="admin"/>
1574 <enumeration value="billing"/>
1575 <enumeration value="tech"/>
1576 <enumeration value="abuse"/>
1577 <enumeration value="custom"/>
1578 </restriction>
1579 </simpleType>
1580
1581 <complexType name="e164Type">
1582 <simpleContent>
1583 <extension base="org:e164StringType">
1584 <attribute name="x" type="token"/>
1585 </extension>
1586 </simpleContent>
1587 </complexType>
1588
1589
1590
1591
1592 Zhou, et al. Standards Track [Page 29]
1593 RFC 8543 EPP Organization Mapping March 2019
1594
1595
1596 <simpleType name="e164StringType">
1597 <restriction base="token">
1598 <pattern value="(\+[0-9]{1,3}\.[0-9]{1,14})?"/>
1599 <maxLength value="17"/>
1600 </restriction>
1601 </simpleType>
1602
1603 <simpleType name="postalLineType">
1604 <restriction base="normalizedString">
1605 <minLength value="1"/>
1606 <maxLength value="255"/>
1607 </restriction>
1608 </simpleType>
1609
1610 <simpleType name="optPostalLineType">
1611 <restriction base="normalizedString">
1612 <maxLength value="255"/>
1613 </restriction>
1614 </simpleType>
1615
1616 <simpleType name="pcType">
1617 <restriction base="token">
1618 <maxLength value="16"/>
1619 </restriction>
1620 </simpleType>
1621
1622 <simpleType name="ccType">
1623 <restriction base="token">
1624 <length value="2"/>
1625 </restriction>
1626 </simpleType>
1627
1628 <complexType name="addrType">
1629 <sequence>
1630 <element name="street" type="org:optPostalLineType"
1631 minOccurs="0" maxOccurs="3"/>
1632 <element name="city" type="org:postalLineType"/>
1633 <element name="sp" type="org:optPostalLineType"
1634 minOccurs="0"/>
1635 <element name="pc" type="org:pcType"
1636 minOccurs="0"/>
1637 <element name="cc" type="org:ccType"/>
1638 </sequence>
1639 </complexType>
1640
1641 <simpleType name="postalInfoEnumType">
1642 <restriction base="token">
1643 <enumeration value="loc"/>
1644
1645
1646
1647 Zhou, et al. Standards Track [Page 30]
1648 RFC 8543 EPP Organization Mapping March 2019
1649
1650
1651 <enumeration value="int"/>
1652 </restriction>
1653 </simpleType>
1654
1655 <!--
1656 Child element of commands that require only an identifier.
1657 -->
1658 <complexType name="sIDType">
1659 <sequence>
1660 <element name="id" type="eppcom:clIDType"/>
1661 </sequence>
1662 </complexType>
1663
1664 <!--
1665 Child element of commands that accept multiple identifiers.
1666 -->
1667 <complexType name="mIDType">
1668 <sequence>
1669 <element name="id"
1670 type="eppcom:clIDType" maxOccurs="unbounded"/>
1671 </sequence>
1672 </complexType>
1673
1674 <!--
1675 Pending action notification response elements.
1676 -->
1677 <complexType name="panDataType">
1678 <sequence>
1679 <element name="id" type="org:paCLIDType"/>
1680 <element name="paTRID" type="epp:trIDType"/>
1681 <element name="paDate" type="dateTime"/>
1682 </sequence>
1683 </complexType>
1684
1685 <complexType name="paCLIDType">
1686 <simpleContent>
1687 <extension base="eppcom:clIDType">
1688 <attribute name="paResult" type="boolean"
1689 use="required"/>
1690 </extension>
1691 </simpleContent>
1692 </complexType>
1693
1694 <!--
1695 Child elements of the <info> commands.
1696 -->
1697 <complexType name="infoType">
1698 <sequence>
1699
1700
1701
1702 Zhou, et al. Standards Track [Page 31]
1703 RFC 8543 EPP Organization Mapping March 2019
1704
1705
1706 <element name="id"
1707 type="eppcom:clIDType"/>
1708 </sequence>
1709 </complexType>
1710
1711 <!--
1712 Child elements of the <create> command.
1713 -->
1714 <complexType name="createType">
1715 <sequence>
1716 <element name="id"
1717 type="eppcom:clIDType"/>
1718 <element name="role"
1719 type="org:roleType" maxOccurs="unbounded"/>
1720 <element name="status"
1721 type="org:statusType" minOccurs="0" maxOccurs="4"/>
1722 <element name="parentId"
1723 type="eppcom:clIDType" minOccurs="0"/>
1724 <element name="postalInfo"
1725 type="org:postalInfoType" minOccurs="0" maxOccurs="2"/>
1726 <element name="voice"
1727 type="org:e164Type" minOccurs="0"/>
1728 <element name="fax"
1729 type="org:e164Type" minOccurs="0"/>
1730 <element name="email"
1731 type="eppcom:minTokenType" minOccurs="0"/>
1732 <element name="url"
1733 type="anyURI" minOccurs="0"/>
1734 <element name="contact"
1735 type="org:contactType"
1736 minOccurs="0" maxOccurs="unbounded"/>
1737 </sequence>
1738 </complexType>
1739
1740 <!--
1741 Child elements of the <update> command.
1742 -->
1743 <complexType name="updateType">
1744 <sequence>
1745 <element name="id"
1746 type="eppcom:clIDType"/>
1747 <element name="add"
1748 type="org:addRemType" minOccurs="0"/>
1749 <element name="rem"
1750 type="org:addRemType" minOccurs="0"/>
1751 <element name="chg"
1752 type="org:chgType" minOccurs="0"/>
1753 </sequence>
1754
1755
1756
1757 Zhou, et al. Standards Track [Page 32]
1758 RFC 8543 EPP Organization Mapping March 2019
1759
1760
1761 </complexType>
1762
1763 <!--
1764 Data elements that can be added or removed.
1765 -->
1766 <complexType name="addRemType">
1767 <sequence>
1768 <element name="contact"
1769 type="org:contactType" minOccurs="0"
1770 maxOccurs="unbounded"/>
1771 <element name="role" type="org:roleType"
1772 minOccurs="0" maxOccurs="unbounded"/>
1773 <element name="status" type="org:statusType"
1774 minOccurs="0" maxOccurs="9"/>
1775 </sequence>
1776 </complexType>
1777
1778 <!--
1779 Data elements that can be changed.
1780 -->
1781 <complexType name="chgType">
1782 <sequence>
1783 <element name="parentId"
1784 type="eppcom:clIDType" minOccurs="0"/>
1785 <element name="postalInfo"
1786 type="org:chgPostalInfoType"
1787 minOccurs="0" maxOccurs="2"/>
1788 <element name="voice"
1789 type="org:e164Type" minOccurs="0"/>
1790 <element name="fax"
1791 type="org:e164Type" minOccurs="0"/>
1792 <element name="email"
1793 type="eppcom:minTokenType" minOccurs="0"/>
1794 <element name="url"
1795 type="anyURI" minOccurs="0"/>
1796 </sequence>
1797 </complexType>
1798
1799 <complexType name="chgPostalInfoType">
1800 <sequence>
1801 <element name="name"
1802 type="org:postalLineType" minOccurs="0"/>
1803 <element name="addr"
1804 type="org:addrType" minOccurs="0"/>
1805 </sequence>
1806 <attribute name="type"
1807 type="org:postalInfoEnumType" use="required"/>
1808 </complexType>
1809
1810
1811
1812 Zhou, et al. Standards Track [Page 33]
1813 RFC 8543 EPP Organization Mapping March 2019
1814
1815
1816 <!--
1817 Child response elements.
1818 -->
1819 <element name="chkData" type="org:chkDataType"/>
1820 <element name="creData" type="org:creDataType"/>
1821 <element name="infData" type="org:infDataType"/>
1822
1823 <!--
1824 <check> response elements.
1825 -->
1826 <complexType name="chkDataType">
1827 <sequence>
1828 <element name="cd" type="org:checkType"
1829 maxOccurs="unbounded" />
1830 </sequence>
1831 </complexType>
1832
1833 <complexType name="checkType">
1834 <sequence>
1835 <element name="id" type="org:checkIDType"/>
1836 <element name="reason" type="eppcom:reasonType"
1837 minOccurs="0"/>
1838 </sequence>
1839 </complexType>
1840
1841 <complexType name="checkIDType">
1842 <simpleContent>
1843 <extension base="eppcom:clIDType">
1844 <attribute name="avail" type="boolean"
1845 use="required"/>
1846 </extension>
1847 </simpleContent>
1848 </complexType>
1849
1850 <!--
1851 <info> response elements.
1852 -->
1853
1854 <complexType name="infDataType">
1855 <sequence>
1856 <element name="id"
1857 type="eppcom:clIDType"/>
1858 <element name="roid"
1859 type="eppcom:roidType"/>
1860 <element name="role"
1861 type="org:roleType" maxOccurs="unbounded"/>
1862 <element name="status"
1863 type="org:statusType" maxOccurs="9"/>
1864
1865
1866
1867 Zhou, et al. Standards Track [Page 34]
1868 RFC 8543 EPP Organization Mapping March 2019
1869
1870
1871 <element name="parentId"
1872 type="eppcom:clIDType" minOccurs="0"/>
1873 <element name="postalInfo"
1874 type="org:postalInfoType" minOccurs="0" maxOccurs="2"/>
1875 <element name="voice"
1876 type="org:e164Type" minOccurs="0"/>
1877 <element name="fax"
1878 type="org:e164Type" minOccurs="0"/>
1879 <element name="email"
1880 type="eppcom:minTokenType" minOccurs="0"/>
1881 <element name="url"
1882 type="anyURI" minOccurs="0"/>
1883 <element name="contact"
1884 type="org:contactType" minOccurs="0"
1885 maxOccurs="unbounded"/>
1886 <element name="clID"
1887 type="eppcom:clIDType" minOccurs="0"/>
1888 <element name="crID"
1889 type="eppcom:clIDType"/>
1890 <element name="crDate"
1891 type="dateTime"/>
1892 <element name="upID"
1893 type="eppcom:clIDType" minOccurs="0"/>
1894 <element name="upDate"
1895 type="dateTime" minOccurs="0"/>
1896 </sequence>
1897 </complexType>
1898 <!--
1899 <create> response elements.
1900 -->
1901 <complexType name="creDataType">
1902 <sequence>
1903 <element name="id" type="eppcom:clIDType"/>
1904 <element name="crDate" type="dateTime"/>
1905 </sequence>
1906 </complexType>
1907
1908 <!--
1909
1910 End of schema.
1911 -->
1912 </schema>
1913 END
1914
1915
1916
1917
1918
1919
1920
1921
1922 Zhou, et al. Standards Track [Page 35]
1923 RFC 8543 EPP Organization Mapping March 2019
1924
1925
1926 6. Internationalization Considerations
1927
1928 EPP is represented in XML, which provides native support for encoding
1929 information using the Unicode character set [UNICODE] and its more
1930 compact representations, including UTF-8. Conformant XML processors
1931 recognize both UTF-8 [RFC3629] and UTF-16 [RFC2781]. Though XML
1932 includes provisions to identify and use other character encodings
1933 through use of an "encoding" attribute in an <?xml?> declaration, use
1934 of UTF-8 is RECOMMENDED.
1935
1936 As an extension of the EPP organization object mapping, the elements
1937 and element content described in this document MUST inherit the
1938 internationalization conventions used to represent higher-layer
1939 domain and core protocol structures present in an XML instance that
1940 includes this extension.
1941
1942 7. IANA Considerations
1943
1944 7.1. XML Namespace
1945
1946 This document uses URNs to describe XML namespaces and XML schemas
1947 conforming to a registry mechanism described in [RFC3688]. IANA has
1948 assigned the following URI.
1949
1950 The organization namespace:
1951
1952 URI: urn:ietf:params:xml:ns:epp:org-1.0
1953
1954 Registrant Contact: IESG
1955
1956 XML: None. Namespace URIs do not represent an XML specification.
1957
1958 The organization XML schema:
1959
1960 URI: urn:ietf:params:xml:schema:epp:org-1.0
1961
1962 Registrant Contact: IESG
1963
1964 XML: See the "Formal Syntax" section of RFC 8543 (this document).
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977 Zhou, et al. Standards Track [Page 36]
1978 RFC 8543 EPP Organization Mapping March 2019
1979
1980
1981 7.2. EPP Extension Registry
1982
1983 The EPP extension described in this document has been registered by
1984 IANA in the "Extensions for the Extensible Provisioning Protocol
1985 (EPP)" registry described in [RFC7451]. The details of the
1986 registration are as follows:
1987
1988 Name of Extension: Extensible Provisioning Protocol (EPP)
1989 Organization Mapping
1990
1991 Document status: Standards Track
1992
1993 Reference: RFC 8543
1994
1995 Registrant Name and Email Address: IESG, iesg@ietf.org
1996
1997 TLDs: Any
1998
1999 IPR Disclosure: None
2000
2001 Status: Active
2002
2003 Notes: None
2004
2005 7.3. Role Type Values Registry
2006
2007 IANA has created a new category of protocol registry for values of
2008 the organization roles. The name of this registry is "EPP
2009 Organization Role Values". The registration policy for this registry
2010 is "Expert Review" [RFC8126].
2011
2012 7.3.1. Registration Template
2013
2014 Value: The string value being registered.
2015
2016 Description: Brief description of the organization role values.
2017
2018 Registrant Name: For RFC specifications, state "IESG". For other
2019 specifications, give the name of the responsible party.
2020
2021 Registrant Contact Information: An email address, postal address, or
2022 some other information to be used to contact the registrant.
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032 Zhou, et al. Standards Track [Page 37]
2033 RFC 8543 EPP Organization Mapping March 2019
2034
2035
2036 7.3.2. Initial Registry Contents
2037
2038 The following are the initial registry contents:
2039
2040 Value: registrar
2041
2042 Description: The entity object instance represents the authority
2043 responsible for the registration in the registry.
2044
2045 Registrant: IESG, iesg@ietf.org
2046
2047 Value: reseller
2048
2049 Description: The entity object instance represents a third party
2050 through which the registration was conducted (i.e., not the
2051 registry or registrar).
2052
2053 Registrant: IESG, iesg@ietf.org
2054
2055 Value: privacyproxy
2056
2057 Description: The entity object instance represents a third party
2058 who could help to register a domain without exposing the
2059 registrants' private information.
2060
2061 Registrant: IESG, iesg@ietf.org
2062
2063 Value: dns-operator
2064
2065 Description: The entity object instance represents a third-party
2066 DNS operator that maintains the name servers and zone data on
2067 behalf of a registrant.
2068
2069 Registrant: IESG, iesg@ietf.org
2070
2071 8. Security Considerations
2072
2073 The organization object may have personally identifiable information,
2074 such as <org:contact>. This information is not a required element in
2075 this document that can be provided on a voluntary basis. If it is
2076 provided, both client and server MUST ensure that authorization
2077 information is stored and exchanged with high-grade encryption
2078 mechanisms to provide privacy services, which are specified in
2079 [RFC5733]. The security considerations described in [RFC5730] or
2080 those caused by the protocol layers used by EPP will apply to this
2081 specification as well.
2082
2083
2084
2085
2086
2087 Zhou, et al. Standards Track [Page 38]
2088 RFC 8543 EPP Organization Mapping March 2019
2089
2090
2091 9. References
2092
2093 9.1. Normative References
2094
2095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2096 Requirement Levels", BCP 14, RFC 2119,
2097 DOI 10.17487/RFC2119, March 1997,
2098 <https://www.rfc-editor.org/info/rfc2119>.
2099
2100 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
2101 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2102 2003, <https://www.rfc-editor.org/info/rfc3629>.
2103
2104 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2105 DOI 10.17487/RFC3688, January 2004,
2106 <https://www.rfc-editor.org/info/rfc3688>.
2107
2108 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2109 Resource Identifier (URI): Generic Syntax", STD 66,
2110 RFC 3986, DOI 10.17487/RFC3986, January 2005,
2111 <https://www.rfc-editor.org/info/rfc3986>.
2112
2113 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
2114 DOI 10.17487/RFC5322, October 2008,
2115 <https://www.rfc-editor.org/info/rfc5322>.
2116
2117 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
2118 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
2119 September 2009, <https://www.rfc-editor.org/info/rfc5646>.
2120
2121 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
2122 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
2123 <https://www.rfc-editor.org/info/rfc5730>.
2124
2125 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
2126 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
2127 August 2009, <https://www.rfc-editor.org/info/rfc5733>.
2128
2129 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
2130 Writing an IANA Considerations Section in RFCs", BCP 26,
2131 RFC 8126, DOI 10.17487/RFC8126, June 2017,
2132 <https://www.rfc-editor.org/info/rfc8126>.
2133
2134 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2135 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2136 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
2137
2138
2139
2140
2141
2142 Zhou, et al. Standards Track [Page 39]
2143 RFC 8543 EPP Organization Mapping March 2019
2144
2145
2146 [UNICODE] The Unicode Consortium, "The Unicode Standard",
2147 <http://www.unicode.org/versions/latest/>.
2148
2149 [W3C.REC-xml-20081126]
2150 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
2151 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
2152 Edition)", World Wide Web Consortium Recommendation
2153 REC-xml-20081126, November 2008,
2154 <https://www.w3.org/TR/xml/>.
2155
2156 [W3C.REC-xmlschema-1-20041028]
2157 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
2158 "XML Schema Part 1: Structures Second Edition", World Wide
2159 Web Consortium Recommendation REC-xmlschema-1-20041028,
2160 October 2004,
2161 <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
2162
2163 [W3C.REC-xmlschema-2-20041028]
2164 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
2165 Second Edition", World Wide Web Consortium Recommendation
2166 REC-xmlschema-2-20041028, October 2004,
2167 <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
2168
2169 9.2. Informative References
2170
2171 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
2172 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000,
2173 <https://www.rfc-editor.org/info/rfc2781>.
2174
2175 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
2176 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
2177 February 2015, <https://www.rfc-editor.org/info/rfc7451>.
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197 Zhou, et al. Standards Track [Page 40]
2198 RFC 8543 EPP Organization Mapping March 2019
2199
2200
2201 Acknowledgments
2202
2203 The authors would like to thank Rik Ribbers, Marc Groeneweg, Patrick
2204 Mevzek, Antoin Verschuren, and Scott Hollenbeck for their careful
2205 review and valuable comments.
2206
2207 Authors' Addresses
2208
2209 Linlin Zhou
2210 CNNIC
2211 4 South 4th Street, Zhongguancun, Haidian District
2212 Beijing, Beijing 100190
2213 China
2214
2215 Email: zhoulinlin@cnnic.cn
2216
2217
2218 Ning Kong
2219 Consultant
2220
2221 Email: ietfing@gmail.com
2222
2223
2224 Jiankang Yao
2225 CNNIC
2226 4 South 4th Street, Zhongguancun, Haidian District
2227 Beijing, Beijing 100190
2228 China
2229
2230 Email: yaojk@cnnic.cn
2231
2232
2233 James Gould
2234 VeriSign, Inc.
2235 12061 Bluemont Way
2236 Reston, VA 20190
2237 United States of America
2238
2239 Email: jgould@verisign.com
2240 URI: http://www.verisign.com
2241
2242
2243 Guiqing Zhou
2244
2245 Email: qing.joe@gmail.com
2246
2247
2248
2249
2250
2251
2252 Zhou, et al. Standards Track [Page 41]
2253
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.