1 Internet Engineering Task Force (IETF) L. Zhou
2 Request for Comments: 8544 CNNIC
3 Category: Standards Track N. Kong
4 ISSN: 2070-1721 Consultant
5 J. Wei
6 J. Yao
7 CNNIC
8 J. Gould
9 VeriSign, Inc.
10 April 2019
11
12
13 Organization Extension for the Extensible Provisioning Protocol (EPP)
14
15 Abstract
16
17 This document describes an extension to Extensible Provisioning
18 Protocol (EPP) object mappings that is designed to support assigning
19 an organization to any existing object (domain, host, contact) as
20 well as any future objects.
21
22 Status of This Memo
23
24 This is an Internet Standards Track document.
25
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 7841.
31
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 https://www.rfc-editor.org/info/rfc8544.
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Zhou, et al. Standards Track [Page 1]
53 RFC 8544 Organization Extension for the EPP April 2019
54
55
56 Copyright Notice
57
58 Copyright (c) 2019 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (https://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
74 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
75 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3
76 3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4
77 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4
78 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4
79 4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 4
80 4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 4
81 4.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 8
82 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8
83 4.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 8
84 4.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 10
85 4.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 10
86 4.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 11
87 4.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 11
88 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
89 6. Internationalization Considerations . . . . . . . . . . . . . 18
90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
91 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 18
92 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 19
93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
95 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
96 9.2. Informative References . . . . . . . . . . . . . . . . . 21
97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
99
100
101
102
103
104
105
106
107 Zhou, et al. Standards Track [Page 2]
108 RFC 8544 Organization Extension for the EPP April 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 are supported in the Extensible
116 Provisioning Protocol (EPP) by the "organization" entities in
117 [RFC8543]. This document provides a way to associate any EPP object
118 such as domain names in [RFC5731], hosts in [RFC5732], and contacts
119 in [RFC5733] to "organization" entities in [RFC8543]. The examples
120 provided in this document are used for the domain object for
121 illustration purposes. The host and contact object could be extended
122 in the same way as the domain object.
123
124 Organization object identifiers, defined in [RFC8543], MUST be known
125 to the server before the organization object can be associated with
126 the EPP object.
127
128 This document is specified using XML 1.0 as described in
129 [W3C.REC-xml-20081126] and XML Schema notation as described in
130 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028].
131
132 2. Conventions Used in This Document
133
134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
136 "OPTIONAL" in this document are to be interpreted as described in
137 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
138 capitals, as shown here.
139
140 In examples, "C:" represents lines sent by a protocol client, and
141 "S:" represents lines returned by a protocol server. Indentation and
142 white space in examples are provided only to illustrate element
143 relationships and are not a required feature of this specification.
144
145 XML is case sensitive. Unless stated otherwise, XML specifications
146 and examples provided in this document MUST be interpreted in the
147 character case presented.
148
149 The XML namespace prefix "orgext" is used for the namespace
150 "urn:ietf:params:xml:ns:epp:orgext-1.0", but implementations MUST NOT
151 depend on it; instead, they should employ a proper namespace-aware
152 XML parser and serializer to interpret and output the XML documents.
153
154 3. Object Attributes
155
156 This extension adds additional elements to EPP object mappings such
157 as the EPP domain name mapping [RFC5731]. Only the new elements are
158 described here.
159
160
161
162 Zhou, et al. Standards Track [Page 3]
163 RFC 8544 Organization Extension for the EPP April 2019
164
165
166 3.1. Organization Identifier
167
168 The organization identifier provides the ID of an organization. Its
169 corresponding element is <orgext:id>, which refers to the <org:id>
170 element defined in [RFC8543]. All organization objects are
171 identified by a server-unique identifier. A "role" attribute is used
172 to represent the relationship that the organization has to the EPP
173 object. Any given object MUST have at most one associated
174 organization ID for any given role value.
175
176 4. EPP Command Mapping
177
178 A detailed description of the EPP syntax and semantics can be found
179 in the EPP core protocol specification [RFC5730]. The command
180 mappings described here are specifically for assigning organizations
181 to EPP objects.
182
183 4.1. EPP Query Commands
184
185 EPP provides three commands to retrieve EPP object information:
186 <check> to determine if an object can be provisioned within a
187 repository, <info> to retrieve detailed information associated with
188 an object, and <transfer> to retrieve object transfer status
189 information.
190
191 4.1.1. EPP <check> Command
192
193 This extension does not add any elements to the EPP <check> command
194 or <check> response described in the EPP object mapping.
195
196 4.1.2. EPP <info> Command
197
198 This extension does not add any elements to the EPP <info> command
199 described in the EPP object mapping. However, additional elements
200 are defined for the <info> response in the EPP object mapping.
201
202 When an <info> command has been processed successfully, the EPP
203 <resData> element MUST contain child elements as described in the EPP
204 object extensions. In addition, the EPP <extension> element SHOULD
205 contain a child <orgext:infData> element. This element is returned
206 if the object has data that is associated with this extension and
207 that is based on server policy. This element or its ancestor element
208
209
210
211
212
213
214
215
216
217 Zhou, et al. Standards Track [Page 4]
218 RFC 8544 Organization Extension for the EPP April 2019
219
220
221 MUST identify the extension namespace
222 "urn:ietf:params:xml:ns:epp:orgext-1.0". The <orgext:infData>
223 element contains the following child elements:
224
225 o Zero or more <orgext:id> elements are allowed that contain the
226 identifier of the organization, as defined in Section 3.1. The
227 "role" attribute is used to represent the relationship that the
228 organization has to the object. See Section 7.3 of [RFC8543] for
229 a list of values.
230
231 Example <info> response for an authorized client with multiple
232 organizations:
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 Zhou, et al. Standards Track [Page 5]
273 RFC 8544 Organization Extension for the EPP April 2019
274
275
276 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
277 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
278 S: <response>
279 S: <result code="1000">
280 S: <msg lang="en-US">Command completed successfully</msg>
281 S: </result>
282 S: <resData>
283 S: <domain:infData
284 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
285 S: <domain:name>example.com</domain:name>
286 S: <domain:roid>EXAMPLE1-REP</domain:roid>
287 S: <domain:status s="ok"/>
288 S: <domain:registrant>jd1234</domain:registrant>
289 S: <domain:contact type="admin">sh8013</domain:contact>
290 S: <domain:contact type="billing">sh8013</domain:contact>
291 S: <domain:contact type="tech">sh8013</domain:contact>
292 S: <domain:ns>
293 S: <domain:hostObj>ns1.example.com</domain:hostObj>
294 S: </domain:ns>
295 S: <domain:clID>ClientX</domain:clID>
296 S: <domain:crID>ClientY</domain:crID>
297 S: <domain:crDate>2015-02-06T04:01:21.0Z</domain:crDate>
298 S: <domain:exDate>2018-02-06T04:01:21.0Z</domain:exDate>
299 S: <domain:authInfo>
300 S: <domain:pw>2fooBAR</domain:pw>
301 S: </domain:authInfo>
302 S: </domain:infData>
303 S: </resData>
304 S: <extension>
305 S: <orgext:infData
306 S: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
307 S: <orgext:id role="reseller">reseller1523</orgext:id>
308 S: <orgext:id role="privacyproxy">proxy2935</orgext:id>
309 S: </orgext:infData>
310 S: </extension>
311 S: <trID>
312 S: <clTRID>ngcl-IvJjzMZc</clTRID>
313 S: <svTRID>test142AWQONJZ</svTRID>
314 S: </trID>
315 S: </response>
316 S:</epp>
317
318
319
320
321
322
323
324
325
326
327 Zhou, et al. Standards Track [Page 6]
328 RFC 8544 Organization Extension for the EPP April 2019
329
330
331 Example <info> response for an authorized client with no
332 organization:
333
334 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
335 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
336 S: <response>
337 S: <result code="1000">
338 S: <msg lang="en-US">Command completed successfully</msg>
339 S: </result>
340 S: <resData>
341 S: <domain:infData
342 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
343 S: <domain:name>example.com</domain:name>
344 S: <domain:roid>EXAMPLE1-REP</domain:roid>
345 S: <domain:status s="ok"/>
346 S: <domain:registrant>jd1234</domain:registrant>
347 S: <domain:contact type="admin">sh8013</domain:contact>
348 S: <domain:contact type="billing">sh8013</domain:contact>
349 S: <domain:contact type="tech">sh8013</domain:contact>
350 S: <domain:ns>
351 S: <domain:hostObj>ns1.example.com</domain:hostObj>
352 S: </domain:ns>
353 S: <domain:clID>ClientX</domain:clID>
354 S: <domain:crID>ClientY</domain:crID>
355 S: <domain:crDate>2015-02-06T04:01:21.0Z</domain:crDate>
356 S: <domain:exDate>2018-02-06T04:01:21.0Z</domain:exDate>
357 S: <domain:authInfo>
358 S: <domain:pw>2fooBAR</domain:pw>
359 S: </domain:authInfo>
360 S: </domain:infData>
361 S: </resData>
362 S: <extension>
363 S: <orgext:infData
364 S: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"/>
365 S: </extension>
366 S: <trID>
367 S: <clTRID>ngcl-IvJjzMZc</clTRID>
368 S: <svTRID>test142AWQONJZ</svTRID>
369 S: </trID>
370 S: </response>
371 S:</epp>
372
373 An EPP error response MUST be returned if an <info> command cannot be
374 processed for any reason.
375
376
377
378
379
380
381
382 Zhou, et al. Standards Track [Page 7]
383 RFC 8544 Organization Extension for the EPP April 2019
384
385
386 4.1.3. EPP <transfer> Query Command
387
388 This extension does not add any elements to the EPP <transfer> query
389 command or <transfer> query response described in the EPP object
390 mapping.
391
392 4.2. EPP Transform Commands
393
394 EPP provides five commands to transform EPP objects: <create> to
395 create an instance of an object, <delete> to delete an instance of an
396 object, <renew> to extend the validity period of an object,
397 <transfer> to manage the object sponsorship changes, and <update> to
398 change information associated with an object.
399
400 4.2.1. EPP <create> Command
401
402 This extension defines additional elements for the EPP <create>
403 command described in the EPP object extensions. No additional
404 elements are defined for the EPP <create> response.
405
406 The EPP <create> command provides a transform operation that allows a
407 client to create an object. In addition to the EPP command elements
408 described in the EPP object extensions, the command MUST contain an
409 <extension> element, and the <extension> element MUST contain a child
410 <orgext:create> element. This element is used if the client wants to
411 associate data defined in this extension to the object. This element
412 or its ancestor element MUST identify the extension namespace
413 "urn:ietf:params:xml:ns:epp:orgext-1.0". The <orgext:create> element
414 contains the following child elements:
415
416 o One or more <orgext:id> elements that contain the identifier of
417 the organization, as defined in Section 3.1. The "role" attribute
418 is used to represent the relationship that the organization has to
419 the object. See Section 7.3 of [RFC8543] for a list of values.
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437 Zhou, et al. Standards Track [Page 8]
438 RFC 8544 Organization Extension for the EPP April 2019
439
440
441 Example <create> command with only one organization:
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: <create>
447 C: <domain:create
448 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
449 C: <domain:name>example.com</domain:name>
450 C: <domain:period unit="y">3</domain:period>
451 C: <domain:ns>
452 C: <domain:hostObj>ns1.example.com</domain:hostObj>
453 C: </domain:ns>
454 C: <domain:registrant>jd1234</domain:registrant>
455 C: <domain:contact type="tech">sh8013</domain:contact>
456 C: <domain:contact type="billing">sh8013</domain:contact>
457 C: <domain:contact type="admin">sh8013</domain:contact>
458 C: <domain:authInfo>
459 C: <domain:pw>fooBAR</domain:pw>
460 C: </domain:authInfo>
461 C: </domain:create>
462 C: </create>
463 C: <extension>
464 C: <orgext:create
465 C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
466 C: <orgext:id role="reseller">reseller1523</orgext:id>
467 C: </orgext:create>
468 C: </extension>
469 C: <clTRID>ABC-12345</clTRID>
470 C: </command>
471 C:</epp>
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492 Zhou, et al. Standards Track [Page 9]
493 RFC 8544 Organization Extension for the EPP April 2019
494
495
496 Example <create> command with multiple organizations:
497
498 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
499 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
500 C: <command>
501 C: <create>
502 C: <domain:create
503 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
504 C: <domain:name>example.com</domain:name>
505 C: <domain:period unit="y">3</domain:period>
506 C: <domain:ns>
507 C: <domain:hostObj>ns1.example.com</domain:hostObj>
508 C: </domain:ns>
509 C: <domain:registrant>jd1234</domain:registrant>
510 C: <domain:contact type="tech">sh8013</domain:contact>
511 C: <domain:contact type="billing">sh8013</domain:contact>
512 C: <domain:contact type="admin">sh8013</domain:contact>
513 C: <domain:authInfo>
514 C: <domain:pw>fooBAR</domain:pw>
515 C: </domain:authInfo>
516 C: </domain:create>
517 C: </create>
518 C: <extension>
519 C: <orgext:create
520 C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
521 C: <orgext:id role="reseller">reseller1523</orgext:id>
522 C: <orgext:id role="privacyproxy">proxy2935</orgext:id>
523 C: </orgext:create>
524 C: </extension>
525 C: <clTRID>ABC-12345</clTRID>
526 C: </command>
527 C:</epp>
528
529 When a <create> command has been processed successfully, the EPP
530 response is as described in the EPP object extension.
531
532 An EPP error response MUST be returned if a <create> command cannot
533 be processed for any reason.
534
535 4.2.2. EPP <delete> Command
536
537 This extension does not add any elements to the EPP <delete> command
538 or <delete> response described in the EPP object mapping.
539
540 4.2.3. EPP <renew> Command
541
542 This extension does not add any elements to the EPP <renew> command
543 or <renew> response described in the EPP object mapping.
544
545
546
547 Zhou, et al. Standards Track [Page 10]
548 RFC 8544 Organization Extension for the EPP April 2019
549
550
551 4.2.4. EPP <transfer> Command
552
553 This extension does not add any elements to the EPP <transfer>
554 command or <transfer> response described in the EPP object mapping,
555 but after a successful transfer of an object with an assigned
556 organization, the handling of the assigned organization is dependent
557 on the organization roles and server policy.
558
559 4.2.5. EPP <update> Command
560
561 This extension defines additional elements for the EPP <update>
562 command described in the EPP domain mapping [RFC5731], host mapping
563 [RFC5732], and contact mapping [RFC5733]. No additional elements are
564 defined for the EPP <update> response.
565
566 The EPP <update> command provides a transform operation that allows a
567 client to modify the attributes of an object. In addition to the EPP
568 <update> command elements, the command MUST contain an <extension>
569 element, and the <extension> element MUST contain a child
570 <orgext:update> element. This element is used if the client wants to
571 update the object with data defined in this extension. This element
572 or its ancestor element MUST identify the extension namespace
573 "urn:ietf:params:xml:ns:epp:orgext-1.0". The <orgext:update> element
574 contains the following child elements:
575
576 o An OPTIONAL <orgext:add> element that contains one or more
577 <orgext:id> elements, as defined in Section 3.1, that add
578 nonexistent organization roles to the object. The <orgext:id>
579 element MUST have a non-empty organization identifier value. The
580 server SHOULD validate that the <orgext:id> element role does not
581 exist.
582
583 o An OPTIONAL <orgext:rem> element that contains one or more
584 <orgext:id> elements, as defined in Section 3.1, that remove
585 organization roles from the object. The <orgext:id> element MAY
586 have an empty organization identifier value. The server SHOULD
587 validate the existence of the <orgext:id> element role and the
588 organization identifier if provided.
589
590 o An OPTIONAL <orgext:chg> element that contains one or more
591 <orgext:id> elements, as defined in Section 3.1, that change
592 organization role identifiers for the object. The existing
593 organization identifier value will be replaced for the defined
594 role. The server SHOULD validate the existence of the <orgext:id>
595 element role.
596
597 At least one <orgext:add>, <orgext:rem>, or <orgext:chg> element MUST
598 be provided.
599
600
601
602 Zhou, et al. Standards Track [Page 11]
603 RFC 8544 Organization Extension for the EPP April 2019
604
605
606 Example <update> command, adding a reseller:
607
608 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
609 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
610 C: <command>
611 C: <update>
612 C: <domain:update
613 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
614 C: <domain:name>example.com</domain:name>
615 C: </domain:update>
616 C: </update>
617 C: <extension>
618 C: <orgext:update
619 C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
620 C: <orgext:add>
621 C: <orgext:id role="reseller">reseller1523</orgext:id>
622 C: </orgext:add>
623 C: </orgext:update>
624 C: </extension>
625 C: <clTRID>ABC-12345</clTRID>
626 C: </command>
627 C:</epp>
628
629 Example <update> command, adding multiple organizations:
630
631 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
632 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
633 C: <command>
634 C: <update>
635 C: <domain:update
636 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
637 C: <domain:name>example.com</domain:name>
638 C: </domain:update>
639 C: </update>
640 C: <extension>
641 C: <orgext:update
642 C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
643 C: <orgext:add>
644 C: <orgext:id role="reseller">reseller1523</orgext:id>
645 C: <orgext:id role="privacyproxy">proxy2935</orgext:id>
646 C: </orgext:add>
647 C: </orgext:update>
648 C: </extension>
649 C: <clTRID>ABC-12345</clTRID>
650 C: </command>
651 C:</epp>
652
653
654
655
656
657 Zhou, et al. Standards Track [Page 12]
658 RFC 8544 Organization Extension for the EPP April 2019
659
660
661 Example <update> command, removing a reseller:
662
663 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
664 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
665 C: <command>
666 C: <update>
667 C: <domain:update
668 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
669 C: <domain:name>example.com</domain:name>
670 C: </domain:update>
671 C: </update>
672 C: <extension>
673 C: <orgext:update
674 C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
675 C: <orgext:rem>
676 C: <orgext:id role="reseller"/>
677 C: </orgext:rem>
678 C: </orgext:update>
679 C: </extension>
680 C: <clTRID>ABC-12345</clTRID>
681 C: </command>
682 C:</epp>
683
684 Example <update> command, removing multiple organizations:
685
686 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
687 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
688 C: <command>
689 C: <update>
690 C: <domain:update
691 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
692 C: <domain:name>example.com</domain:name>
693 C: </domain:update>
694 C: </update>
695 C: <extension>
696 C: <orgext:update
697 C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
698 C: <orgext:rem>
699 C: <orgext:id role="reseller"/>
700 C: <orgext:id role="privacyproxy"/>
701 C: </orgext:rem>
702 C: </orgext:update>
703 C: </extension>
704 C: <clTRID>ABC-12345</clTRID>
705 C: </command>
706 C:</epp>
707
708
709
710
711
712 Zhou, et al. Standards Track [Page 13]
713 RFC 8544 Organization Extension for the EPP April 2019
714
715
716 Example <update> command, updating reseller identifier:
717
718 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
719 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
720 C: <command>
721 C: <update>
722 C: <domain:update
723 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
724 C: <domain:name>example.com</domain:name>
725 C: </domain:update>
726 C: </update>
727 C: <extension>
728 C: <orgext:update
729 C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
730 C: <orgext:chg>
731 C: <orgext:id role="reseller">reseller1523</orgext:id>
732 C: </orgext:chg>
733 C: </orgext:update>
734 C: </extension>
735 C: <clTRID>ABC-12345</clTRID>
736 C: </command>
737 C:</epp>
738
739 Example <update> command, updating multiple organization identifiers:
740
741 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
742 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
743 C: <command>
744 C: <update>
745 C: <domain:update
746 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
747 C: <domain:name>example.com</domain:name>
748 C: </domain:update>
749 C: </update>
750 C: <extension>
751 C: <orgext:update
752 C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
753 C: <orgext:chg>
754 C: <orgext:id role="reseller">reseller1523</orgext:id>
755 C: <orgext:id role="privacyproxy">proxy2935</orgext:id>
756 C: </orgext:chg>
757 C: </orgext:update>
758 C: </extension>
759 C: <clTRID>ABC-12345</clTRID>
760 C: </command>
761 C:</epp>
762
763
764
765
766
767 Zhou, et al. Standards Track [Page 14]
768 RFC 8544 Organization Extension for the EPP April 2019
769
770
771 When an extended <update> command has been processed successfully,
772 the EPP response is as described in the EPP object extension.
773
774 An EPP error response MUST be returned if an <update> command cannot
775 be processed for any reason. An attempt to add one organization ID
776 or multiple organization IDs with a particular role value when at
777 least one of them already exists does not change the object at all.
778 A server SHOULD notify clients that object relationships exist by
779 sending a 2305 error response code. An attempt to remove an
780 organization ID or multiple organization IDs with a particular role
781 value when at least one of them does not exist does not change the
782 object at all. A server SHOULD notify clients that object
783 relationships do not exist by sending a 2305 error response code. An
784 attempt to change an organization ID or multiple organization IDs
785 with a particular role value when at least one of them does not exist
786 does not change the object at all. A server SHOULD notify clients
787 that object relationships do not exist by sending a 2305 error
788 response code. Response format with error value elements is defined
789 in Section 2.6 of [RFC5730].
790
791 5. Formal Syntax
792
793 An EPP object mapping is specified in XML Schema notation. The
794 formal syntax presented here is a complete schema representation of
795 the object mapping suitable for automated validation of EPP XML
796 instances. The BEGIN and END tags are not part of the schema; they
797 are used to note the beginning and ending of the schema for URI
798 registration purposes.
799
800 BEGIN
801 <?xml version="1.0" encoding="UTF-8"?>
802
803 <schema
804 targetNamespace="urn:ietf:params:xml:ns:epp:orgext-1.0"
805 xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"
806 xmlns="http://www.w3.org/2001/XMLSchema"
807 elementFormDefault="qualified"
808 >
809
810 <annotation>
811 <documentation>
812 Extensible Provisioning Protocol v1.0
813 Organization Extension Schema v1.0
814 </documentation>
815 </annotation>
816
817
818
819
820
821
822 Zhou, et al. Standards Track [Page 15]
823 RFC 8544 Organization Extension for the EPP April 2019
824
825
826 <!-- Child elements found in EPP commands -->
827 <element
828 name="create"
829 type="orgext:createType"/>
830 <element
831 name="update"
832 type="orgext:updateType"/>
833
834 <!--
835 Organization identifier with required role
836 -->
837 <complexType name="orgIdType">
838 <simpleContent>
839 <extension base="token">
840 <attribute
841 name="role"
842 type="token"
843 use="required"/>
844 </extension>
845 </simpleContent>
846 </complexType>
847
848 <!--
849 Child elements of the <orgext:create> command.
850 All elements must be present at time of creation.
851 -->
852 <complexType name="createType">
853 <sequence>
854 <!-- Agent identifier or the organization,
855 e.g., registrar, reseller, privacy proxy, etc. -->
856 <element
857 name="id"
858 type="orgext:orgIdType"
859 maxOccurs="unbounded"/>
860 </sequence>
861 </complexType>
862
863 <!--
864 Child elements of <orgext:update> command
865 -->
866 <complexType name="updateType">
867 <sequence>
868 <element
869 name="add"
870 type="orgext:addRemChgType"
871 minOccurs="0"
872 />
873
874
875
876
877 Zhou, et al. Standards Track [Page 16]
878 RFC 8544 Organization Extension for the EPP April 2019
879
880
881 <element
882 name="rem"
883 type="orgext:addRemChgType"
884 minOccurs="0"
885 />
886 <element
887 name="chg"
888 type="orgext:addRemChgType"
889 minOccurs="0"
890 />
891 </sequence>
892 </complexType>
893
894 <complexType name="addRemChgType">
895 <sequence>
896 <!-- Agent identifier of the organization,
897 e.g., registrar, reseller, privacy proxy, etc. -->
898 <element
899 name="id"
900 type="orgext:orgIdType"
901 maxOccurs="unbounded"/>
902 </sequence>
903 </complexType>
904
905 <!-- Child response element -->
906 <element
907 name="infData"
908 type="orgext:infDataType"/>
909
910 <!-- <orgext:infData> response elements -->
911 <complexType name="infDataType">
912 <sequence>
913 <!-- Agent identifier the organization,
914 e.g., registrar, reseller, privacy proxy, etc. -->
915 <element
916 name="id"
917 type="orgext:orgIdType"
918 minOccurs="0"
919 maxOccurs="unbounded"/>
920 </sequence>
921 </complexType>
922
923 <!-- End of schema -->
924 </schema>
925 END
926
927
928
929
930
931
932 Zhou, et al. Standards Track [Page 17]
933 RFC 8544 Organization Extension for the EPP April 2019
934
935
936 6. Internationalization Considerations
937
938 EPP is represented in XML, which provides native support for encoding
939 information using the Unicode character set [UNICODE] and its more
940 compact representations, including UTF-8. Conformant XML processors
941 recognize both UTF-8 [RFC3629] and UTF-16 [RFC2781]. Though XML
942 includes provisions to identify and use other character encodings
943 through use of an "encoding" attribute in an <?xml?> declaration, use
944 of UTF-8 is RECOMMENDED.
945
946 As an extension of the EPP object mapping, the elements and element
947 content described in this document MUST inherit the
948 internationalization conventions used to represent higher-layer
949 domain and core protocol structures present in an XML instance that
950 includes this extension.
951
952 7. IANA Considerations
953
954 7.1. XML Namespace
955
956 This document uses URNs to describe XML namespaces and XML schemas
957 conforming to a registry mechanism described in [RFC3688]. IANA has
958 assigned the following URI.
959
960 The organization extension namespace:
961
962 URI: urn:ietf:params:xml:ns:epp:orgext-1.0
963
964 Registrant Contact: IESG
965
966 XML: None. Namespace URIs do not represent an XML specification.
967
968 The organization XML schema:
969
970 URI: urn:ietf:params:xml:schema:epp:orgext-1.0
971
972 Registrant Contact: IESG
973
974 XML: See the "Formal Syntax" section of RFC 8544 (this document).
975
976
977
978
979
980
981
982
983
984
985
986
987 Zhou, et al. Standards Track [Page 18]
988 RFC 8544 Organization Extension for the EPP April 2019
989
990
991 7.2. EPP Extension Registry
992
993 The EPP extension described in this document has been registered by
994 IANA in the "Extensions for the Extensible Provisioning Protocol
995 (EPP)" registry described in [RFC7451]. The details of the
996 registration are as follows:
997
998 Name of Extension: Organization Extension for the Extensible
999 Provisioning Protocol (EPP)
1000
1001 Document Status: Standards Track
1002
1003 Reference: RFC 8544
1004
1005 Registrant Name and Email Address: IESG, iesg@ietf.org
1006
1007 TLDs: Any
1008
1009 IPR Disclosure: None
1010
1011 Status: Active
1012
1013 Notes: None
1014
1015 8. Security Considerations
1016
1017 The object mapping extension described in this document does not
1018 provide any other security services or introduce any additional
1019 considerations beyond those described by [RFC5730], [RFC5731],
1020 [RFC5732], and [RFC5733] or those caused by the protocol layers used
1021 by EPP.
1022
1023 9. References
1024
1025 9.1. Normative References
1026
1027 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1028 Requirement Levels", BCP 14, RFC 2119,
1029 DOI 10.17487/RFC2119, March 1997,
1030 <https://www.rfc-editor.org/info/rfc2119>.
1031
1032 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
1033 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
1034 2003, <https://www.rfc-editor.org/info/rfc3629>.
1035
1036 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1037 DOI 10.17487/RFC3688, January 2004,
1038 <https://www.rfc-editor.org/info/rfc3688>.
1039
1040
1041
1042 Zhou, et al. Standards Track [Page 19]
1043 RFC 8544 Organization Extension for the EPP April 2019
1044
1045
1046 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
1047 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
1048 <https://www.rfc-editor.org/info/rfc5730>.
1049
1050 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
1051 Domain Name Mapping", STD 69, RFC 5731,
1052 DOI 10.17487/RFC5731, August 2009,
1053 <https://www.rfc-editor.org/info/rfc5731>.
1054
1055 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
1056 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
1057 August 2009, <https://www.rfc-editor.org/info/rfc5732>.
1058
1059 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
1060 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
1061 August 2009, <https://www.rfc-editor.org/info/rfc5733>.
1062
1063 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1064 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1065 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1066
1067 [UNICODE] The Unicode Consortium, "The Unicode Standard",
1068 <http://www.unicode.org/versions/latest/>.
1069
1070 [W3C.REC-xml-20081126]
1071 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
1072 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
1073 Edition)", World Wide Web Consortium Recommendation
1074 REC-xml-20081126, November 2008,
1075 <https://www.w3.org/TR/xml/>.
1076
1077 [W3C.REC-xmlschema-1-20041028]
1078 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
1079 "XML Schema Part 1: Structures Second Edition", World Wide
1080 Web Consortium Recommendation REC-xmlschema-1-20041028,
1081 October 2004,
1082 <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
1083
1084 [W3C.REC-xmlschema-2-20041028]
1085 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
1086 Second Edition", World Wide Web Consortium Recommendation
1087 REC-xmlschema-2-20041028, October 2004,
1088 <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
1089
1090
1091
1092
1093
1094
1095
1096
1097 Zhou, et al. Standards Track [Page 20]
1098 RFC 8544 Organization Extension for the EPP April 2019
1099
1100
1101 9.2. Informative References
1102
1103 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
1104 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000,
1105 <https://www.rfc-editor.org/info/rfc2781>.
1106
1107 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
1108 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
1109 February 2015, <https://www.rfc-editor.org/info/rfc7451>.
1110
1111 [RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou,
1112 "Extensible Provisioning Protocol (EPP) Organization
1113 Mapping", RFC 8543, DOI 10.17487/RFC8543, March 2019,
1114 <https://www.rfc-editor.org/info/rfc8543>.
1115
1116 Acknowledgments
1117
1118 The authors would like to thank Rik Ribbers, Marc Groeneweg, Patrick
1119 Mevzek, Antoin Verschuren, and Scott Hollenbeck for their careful
1120 review and valuable comments.
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152 Zhou, et al. Standards Track [Page 21]
1153 RFC 8544 Organization Extension for the EPP April 2019
1154
1155
1156 Authors' Addresses
1157
1158 Linlin Zhou
1159 CNNIC
1160 4 South 4th Street, Zhongguancun, Haidian District
1161 Beijing, Beijing 100190
1162 China
1163
1164 Email: zhoulinlin@cnnic.cn
1165
1166
1167 Ning Kong
1168 Consultant
1169
1170 Email: ietfing@gmail.com
1171
1172
1173 Junkai Wei
1174 CNNIC
1175 4 South 4th Street, Zhongguancun, Haidian District
1176 Beijing, Beijing 100190
1177 China
1178
1179 Email: weijunkai@cnnic.cn
1180
1181
1182 Jiankang Yao
1183 CNNIC
1184 4 South 4th Street, Zhongguancun, Haidian District
1185 Beijing, Beijing 100190
1186 China
1187
1188 Email: yaojk@cnnic.cn
1189
1190
1191 James Gould
1192 VeriSign, Inc.
1193 12061 Bluemont Way
1194 Reston, VA 20190
1195 United States of America
1196
1197 Email: jgould@verisign.com
1198 URI: http://www.verisign.com
1199
1200
1201
1202
1203
1204
1205
1206
1207 Zhou, et al. Standards Track [Page 22]
1208
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.