1 Internet Engineering Task Force (IETF) J. Gould
2 Request for Comments: 8056 VeriSign, Inc.
3 Category: Standards Track January 2017
4 ISSN: 2070-1721
5
6
7 Extensible Provisioning Protocol (EPP)
8 and Registration Data Access Protocol (RDAP) Status Mapping
9
10 Abstract
11
12 This document describes the mapping of the Extensible Provisioning
13 Protocol (EPP) statuses with the statuses registered for use in the
14 Registration Data Access Protocol (RDAP). This document identifies
15 gaps in the mapping, and registers RDAP statuses to fill those gaps
16 to ensure that all of the EPP statuses specified in RFCs are
17 supported in RDAP.
18
19 Status of This Memo
20
21 This is an Internet Standards Track document.
22
23 This document is a product of the Internet Engineering Task Force
24 (IETF). It represents the consensus of the IETF community. It has
25 received public review and has been approved for publication by the
26 Internet Engineering Steering Group (IESG). Further information on
27 Internet Standards is available in Section 2 of RFC 7841.
28
29 Information about the current status of this document, any errata,
30 and how to provide feedback on it may be obtained at
31 http://www.rfc-editor.org/info/rfc8056.
32
33 Copyright Notice
34
35 Copyright (c) 2017 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
37
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (http://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Simplified BSD License text as described in Section 4.e of
45 the Trust Legal Provisions and are provided without warranty as
46 described in the Simplified BSD License.
47
48
49
50
51
52 Gould Standards Track [Page 1]
53 RFC 8056 EPP RDAP Status Mapping January 2017
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
59 1.1. Conventions Used in This Document . . . . . . . . . . . . 2
60 2. EPP-to-RDAP Status Mapping . . . . . . . . . . . . . . . . . 2
61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
62 3.1. JSON Values Registry . . . . . . . . . . . . . . . . . . 6
63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
64 5. Normative References . . . . . . . . . . . . . . . . . . . . 10
65 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
67
68 1. Introduction
69
70 This document maps the statuses defined in the Extensible
71 Provisioning Protocol (EPP) RFCs to the list of statuses registered
72 for use in the Registration Data Access Protocol (RDAP), in the "RDAP
73 JSON Values" registry [rdap-json-values].
74
75 The "RDAP JSON Values" registry is described in Section 10.2 of
76 [RFC7483] and is available in the "RDAP JSON Values" registry
77 [rdap-json-values].
78
79 The EPP statuses used as the source of the mapping include
80 Section 2.3 of the Extensible Provisioning Protocol (EPP) Domain Name
81 Mapping [RFC5731], Section 2.3 of "Extensible Provisioning Protocol
82 (EPP) Host Mapping" [RFC5732], Section 2.2 of "Extensible
83 Provisioning Protocol (EPP) Contact Mapping" [RFC5733], and
84 Section 3.1 of "Domain Registry Grace Period Mapping for the
85 Extensible Provisioning Protocol (EPP)" [RFC3915].
86
87 Each EPP status MUST map to a single RDAP status to ensure that data
88 in the Domain Name Registries (DNRs) that use EPP can be accurately
89 presented in RDAP.
90
91 1.1. Conventions Used in This Document
92
93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
95 document are to be interpreted as described in RFC 2119 [RFC2119].
96
97 2. EPP-to-RDAP Status Mapping
98
99 Below is a list of EPP statuses from the EPP RFCs ([RFC5731],
100 [RFC5732], [RFC5733], and [RFC3915]) mapped to the RDAP statuses
101 registered in the "RDAP JSON Values" registry [rdap-json-values],
102 with the format <EPP Status> '=' <RDAP Status>, where a blank <RDAP
103 Status> indicates a gap in the mapping.
104
105
106
107 Gould Standards Track [Page 2]
108 RFC 8056 EPP RDAP Status Mapping January 2017
109
110
111 addPeriod =
112 autoRenewPeriod =
113 clientDeleteProhibited =
114 clientHold =
115 clientRenewProhibited =
116 clientTransferProhibited =
117 clientUpdateProhibited =
118 inactive = inactive
119 linked = associated
120 ok = active
121 pendingCreate = pending create
122 pendingDelete = pending delete
123 pendingRenew = pending renew
124 pendingRestore =
125 pendingTransfer = pending transfer
126 pendingUpdate = pending update
127 redemptionPeriod =
128 renewPeriod =
129 serverDeleteProhibited =
130 serverRenewProhibited =
131 serverTransferProhibited =
132 serverUpdateProhibited =
133 serverHold =
134 transferPeriod =
135
136 The "RDAP JSON Values" registry [rdap-json-values] does have a set of
137 prohibited statuses including "renew prohibited", "update
138 prohibited", "transfer prohibited", and "delete prohibited", but
139 these statuses do not directly map to the EPP prohibited statuses.
140 EPP provides status codes that allow distinguishing the case that an
141 action is prohibited because of server policy from the case that an
142 action is prohibited because of a client request. The ability to
143 make this distinction needs to be preserved in RDAP.
144
145 Each of the EPP status values that don't map directly to an RDAP
146 status value is described below. Each EPP status value includes a
147 proposed new RDAP status value and a description of the value. The
148 RDAP status value is derived from the EPP status value by converting
149 the EPP "camelCase" representation to lowercase with a space
150 character inserted between word boundaries.
151
152 addPeriod = add period; This grace period is provided after the
153 initial registration of the object. If the object is deleted by
154 the client during this period, the server provides a credit to
155 the client for the cost of the registration.
156
157
158
159
160
161
162 Gould Standards Track [Page 3]
163 RFC 8056 EPP RDAP Status Mapping January 2017
164
165
166 autoRenewPeriod = auto renew period; This grace period is provided
167 after an object registration period expires and is extended
168 (renewed) automatically by the server. If the object is deleted
169 by the client during this period, the server provides a credit to
170 the client for the cost of the auto renewal.
171
172 clientDeleteProhibited = client delete prohibited; The client
173 requested that requests to delete the object MUST be rejected.
174
175 clientHold = client hold; The client requested that the DNS
176 delegation information MUST NOT be published for the object.
177
178 clientRenewProhibited = client renew prohibited; The client
179 requested that requests to renew the object MUST be rejected.
180
181 clientTransferProhibited = client transfer prohibited; The client
182 requested that requests to transfer the object MUST be rejected.
183
184 clientUpdateProhibited = client update prohibited; The client
185 requested that requests to update the object (other than to
186 remove this status) MUST be rejected.
187
188 pendingRestore = pending restore; An object is in the process of
189 being restored after being in the redemption period state.
190
191 redemptionPeriod = redemption period; A delete has been received,
192 but the object has not yet been purged because an opportunity
193 exists to restore the object and abort the deletion process.
194
195 renewPeriod = renew period; This grace period is provided after an
196 object registration period is explicitly extended (renewed) by
197 the client. If the object is deleted by the client during this
198 period, the server provides a credit to the client for the cost
199 of the renewal.
200
201 serverDeleteProhibited = server delete prohibited; The server set
202 the status so that requests to delete the object MUST be
203 rejected.
204
205 serverRenewProhibited = server renew prohibited; The server set the
206 status so that requests to renew the object MUST be rejected.
207
208 serverTransferProhibited = server transfer prohibited; The server
209 set the status so that requests to transfer the object MUST be
210 rejected.
211
212
213
214
215
216
217 Gould Standards Track [Page 4]
218 RFC 8056 EPP RDAP Status Mapping January 2017
219
220
221 serverUpdateProhibited = server update prohibited; The server set
222 the status so that requests to update the object (other than to
223 remove this status) MUST be rejected.
224 serverHold = server hold; The server set the status so that DNS
225 delegation information MUST NOT be published for the object.
226
227 transferPeriod = transfer period; This grace period is provided
228 after the successful transfer of object registration sponsorship
229 from one client to another client. If the object is deleted by
230 the client during this period, the server provides a credit to
231 the client for the cost of the transfer.
232
233 The resulting mapping after registering the new RDAP statuses is:
234
235 addPeriod = add period
236 autoRenewPeriod = auto renew period
237 clientDeleteProhibited = client delete prohibited
238 clientHold = client hold
239 clientRenewProhibited = client renew prohibited
240 clientTransferProhibited = client transfer prohibited
241 clientUpdateProhibited = client update prohibited
242 inactive = inactive
243 linked = associated
244 ok = active
245 pendingCreate = pending create
246 pendingDelete = pending delete
247 pendingRenew = pending renew
248 pendingRestore = pending restore
249 pendingTransfer = pending transfer
250 pendingUpdate = pending update
251 redemptionPeriod = redemption period
252 renewPeriod = renew period
253 serverDeleteProhibited = server delete prohibited
254 serverRenewProhibited = server renew prohibited
255 serverTransferProhibited = server transfer prohibited
256 serverUpdateProhibited = server update prohibited
257 serverHold = server hold
258 transferPeriod = transfer period
259
260
261
262
263
264
265
266
267
268
269
270
271
272 Gould Standards Track [Page 5]
273 RFC 8056 EPP RDAP Status Mapping January 2017
274
275
276 3. IANA Considerations
277
278 3.1. JSON Values Registry
279
280 The following values have been registered by the IANA in the "RDAP
281 JSON Values" registry described in [RFC7483]:
282
283 Value: add period
284 Type: status
285 Description: This grace period is provided after the initial
286 registration of the object. If the object is deleted by the
287 client during this period, the server provides a credit to the
288 client for the cost of the registration. This maps to the Domain
289 Registry Grace Period Mapping for the Extensible Provisioning
290 Protocol (EPP) [RFC3915] 'addPeriod' status.
291 Registrant Name: IESG
292 Registrant Contact Information: iesg@ietf.org
293
294 Value: auto renew period
295 Type: status
296 Description: This grace period is provided after an object
297 registration period expires and is extended (renewed)
298 automatically by the server. If the object is deleted by the
299 client during this period, the server provides a credit to the
300 client for the cost of the auto renewal. This maps to the Domain
301 Registry Grace Period Mapping for the Extensible Provisioning
302 Protocol (EPP) [RFC3915] 'autoRenewPeriod' status.
303 Registrant Name: IESG
304 Registrant Contact Information: iesg@ietf.org
305
306 Value: client delete prohibited
307 Type: status
308 Description: The client requested that requests to delete the
309 object MUST be rejected. This maps to the Extensible Provisioning
310 Protocol (EPP) Domain Name Mapping [RFC5731], Extensible
311 Provisioning Protocol (EPP) Host Mapping [RFC5732], and Extensible
312 Provisioning Protocol (EPP) Contact Mapping [RFC5733]
313 'clientDeleteProhibited' status.
314 Registrant Name: IESG
315 Registrant Contact Information: iesg@ietf.org
316
317
318
319
320
321
322
323
324
325
326
327 Gould Standards Track [Page 6]
328 RFC 8056 EPP RDAP Status Mapping January 2017
329
330
331 Value: client hold
332 Type: status
333 Description: The client requested that the DNS delegation
334 information MUST NOT be published for the object. This maps to
335 the Extensible Provisioning Protocol (EPP) Domain Name Mapping
336 [RFC5731] 'clientHold' status.
337 Registrant Name: IESG
338 Registrant Contact Information: iesg@ietf.org
339
340 Value: client renew prohibited
341 Type: status
342 Description: The client requested that requests to renew the
343 object MUST be rejected. This maps to the Extensible Provisioning
344 Protocol (EPP) Domain Name Mapping [RFC5731]
345 'clientRenewProhibited' status.
346 Registrant Name: IESG
347 Registrant Contact Information: iesg@ietf.org
348
349 Value: client transfer prohibited
350 Type: status
351 Description: The client requested that requests to transfer the
352 object MUST be rejected. This maps to the Extensible Provisioning
353 Protocol (EPP) Domain Name Mapping [RFC5731] and Extensible
354 Provisioning Protocol (EPP) Contact Mapping [RFC5733]
355 'clientTransferProhibited' status.
356 Registrant Name: IESG
357 Registrant Contact Information: iesg@ietf.org
358
359 Value: client update prohibited
360 Type: status
361 Description: The client requested that requests to update the
362 object (other than to remove this status) MUST be rejected. This
363 maps to the Extensible Provisioning Protocol (EPP) Domain Name
364 Mapping [RFC5731], Extensible Provisioning Protocol (EPP) Host
365 Mapping [RFC5732], and Extensible Provisioning Protocol (EPP)
366 Contact Mapping [RFC5733] 'clientUpdateProhibited' status.
367 Registrant Name: IESG
368 Registrant Contact Information: iesg@ietf.org
369
370 Value: pending restore
371 Type: status
372 Description: An object is in the process of being restored after
373 being in the redemption period state. This maps to the Domain
374 Registry Grace Period Mapping for the Extensible Provisioning
375 Protocol (EPP) [RFC3915] 'pendingRestore' status.
376 Registrant Name: IESG
377 Registrant Contact Information: iesg@ietf.org
378
379
380
381
382 Gould Standards Track [Page 7]
383 RFC 8056 EPP RDAP Status Mapping January 2017
384
385
386 Value: redemption period
387 Type: status
388 Description: A delete has been received, but the object has not
389 yet been purged because an opportunity exists to restore the
390 object and abort the deletion process. This maps to the Domain
391 Registry Grace Period Mapping for the Extensible Provisioning
392 Protocol (EPP) [RFC3915] 'redemptionPeriod' status.
393 Registrant Name: IESG
394 Registrant Contact Information: iesg@ietf.org
395
396 Value: renew period
397 Type: status
398 Description: This grace period is provided after an object
399 registration period is explicitly extended (renewed) by the
400 client. If the object is deleted by the client during this
401 period, the server provides a credit to the client for the cost of
402 the renewal. This maps to the Domain Registry Grace Period
403 Mapping for the Extensible Provisioning Protocol (EPP) [RFC3915]
404 'renewPeriod' status.
405 Registrant Name: IESG
406 Registrant Contact Information: iesg@ietf.org
407
408 Value: server delete prohibited
409 Type: status
410 Description: The server set the status so that requests to delete
411 the object MUST be rejected. This maps to the Extensible
412 Provisioning Protocol (EPP) Domain Name Mapping [RFC5731],
413 Extensible Provisioning Protocol (EPP) Host Mapping [RFC5732], and
414 Extensible Provisioning Protocol (EPP) Contact Mapping [RFC5733]
415 'serverDeleteProhibited' status.
416 Registrant Name: IESG
417 Registrant Contact Information: iesg@ietf.org
418
419 Value: server renew prohibited
420 Type: status
421 Description: The server set the status so that requests to renew
422 the object MUST be rejected. This maps to the Extensible
423 Provisioning Protocol (EPP) Domain Name Mapping [RFC5731]
424 'serverRenewProhibited' status.
425 Registrant Name: IESG
426 Registrant Contact Information: iesg@ietf.org
427
428
429
430
431
432
433
434
435
436
437 Gould Standards Track [Page 8]
438 RFC 8056 EPP RDAP Status Mapping January 2017
439
440
441 Value: server transfer prohibited
442 Type: status
443 Description: The server set the status so that requests to
444 transfer the object MUST be rejected. This maps to the Extensible
445 Provisioning Protocol (EPP) Domain Name Mapping [RFC5731] and
446 Extensible Provisioning Protocol (EPP) Contact Mapping [RFC5733]
447 'serverTransferProhibited' status.
448 Registrant Name: IESG
449 Registrant Contact Information: iesg@ietf.org
450
451 Value: server update prohibited
452 Type: status
453 Description: The server set the status so that requests to update
454 the object (other than to remove this status) MUST be rejected.
455 This maps to the Extensible Provisioning Protocol (EPP) Domain
456 Name Mapping [RFC5731], Extensible Provisioning Protocol (EPP)
457 Host Mapping [RFC5732], and Extensible Provisioning Protocol (EPP)
458 Contact Mapping [RFC5733] 'serverUpdateProhibited' status.
459 Registrant Name: IESG
460 Registrant Contact Information: iesg@ietf.org
461
462 Value: server hold
463 Type: status
464 Description: The server set the status so that DNS delegation
465 information MUST NOT be published for the object. This maps to
466 the Extensible Provisioning Protocol (EPP) Domain Name Mapping
467 [RFC5731] 'serverHold' status.
468 Registrant Name: IESG
469 Registrant Contact Information: iesg@ietf.org
470
471 Value: transfer period
472 Type: status
473 Description: This grace period is provided after the successful
474 transfer of object registration sponsorship from one client to
475 another client. If the object is deleted by the client during
476 this period, the server provides a credit to the client for the
477 cost of the transfer. This maps to the Domain Registry Grace
478 Period Mapping for the Extensible Provisioning Protocol (EPP)
479 [RFC3915] 'transferPeriod' status.
480 Registrant Name: IESG
481 Registrant Contact Information: iesg@ietf.org
482
483
484
485
486
487
488
489
490
491
492 Gould Standards Track [Page 9]
493 RFC 8056 EPP RDAP Status Mapping January 2017
494
495
496 4. Security Considerations
497
498 The status values described in this document can be subject to
499 server-side information disclosure policies that restrict display of
500 the values to authorized clients. Implementers may wish to review
501 [RFC7481] for a description of the RDAP security services that can be
502 used to implement information disclosure policies.
503
504 5. Normative References
505
506 [rdap-json-values]
507 IANA, "RDAP JSON Values",
508 <https://www.iana.org/assignments/rdap-json-values/>.
509
510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
511 Requirement Levels", BCP 14, RFC 2119,
512 DOI 10.17487/RFC2119, March 1997,
513 <http://www.rfc-editor.org/info/rfc2119>.
514
515 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for
516 the Extensible Provisioning Protocol (EPP)", RFC 3915,
517 DOI 10.17487/RFC3915, September 2004,
518 <http://www.rfc-editor.org/info/rfc3915>.
519
520 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
521 Domain Name Mapping", STD 69, RFC 5731,
522 DOI 10.17487/RFC5731, August 2009,
523 <http://www.rfc-editor.org/info/rfc5731>.
524
525 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
526 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
527 August 2009, <http://www.rfc-editor.org/info/rfc5732>.
528
529 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
530 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
531 August 2009, <http://www.rfc-editor.org/info/rfc5733>.
532
533 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
534 Registration Data Access Protocol (RDAP)", RFC 7481,
535 DOI 10.17487/RFC7481, March 2015,
536 <http://www.rfc-editor.org/info/rfc7481>.
537
538 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
539 Registration Data Access Protocol (RDAP)", RFC 7483,
540 DOI 10.17487/RFC7483, March 2015,
541 <http://www.rfc-editor.org/info/rfc7483>.
542
543
544
545
546
547 Gould Standards Track [Page 10]
548 RFC 8056 EPP RDAP Status Mapping January 2017
549
550
551 Acknowledgements
552
553 Suggestions that have been incorporated into this document were
554 provided by Andrew Newton, Scott Hollenbeck, Jim Galvin, Gustavo
555 Lozano, and Robert Sparks.
556
557 Author's Address
558
559 James Gould
560 VeriSign, Inc.
561 12061 Bluemont Way
562 Reston, VA 20190
563 United States of America
564
565 Email: jgould@verisign.com
566 URI: http://www.verisign.com
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602 Gould Standards Track [Page 11]
603
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.