1 Internet Engineering Task Force (IETF) A. Newton
2 Request for Comments: 7483 ARIN
3 Category: Standards Track S. Hollenbeck
4 ISSN: 2070-1721 Verisign Labs
5 March 2015
6
7
8 JSON Responses for the Registration Data Access Protocol (RDAP)
9
10 Abstract
11
12 This document describes JSON data structures representing
13 registration information maintained by Regional Internet Registries
14 (RIRs) and Domain Name Registries (DNRs). These data structures are
15 used to form Registration Data Access Protocol (RDAP) query
16 responses.
17
18 Status of This Memo
19
20 This is an Internet Standards Track document.
21
22 This document is a product of the Internet Engineering Task Force
23 (IETF). It represents the consensus of the IETF community. It has
24 received public review and has been approved for publication by the
25 Internet Engineering Steering Group (IESG). Further information on
26 Internet Standards is available in Section 2 of RFC 5741.
27
28 Information about the current status of this document, any errata,
29 and how to provide feedback on it may be obtained at
30 http://www.rfc-editor.org/info/rfc7483.
31
32 Copyright Notice
33
34 Copyright (c) 2015 IETF Trust and the persons identified as the
35 document authors. All rights reserved.
36
37 This document is subject to BCP 78 and the IETF Trust's Legal
38 Provisions Relating to IETF Documents
39 (http://trustee.ietf.org/license-info) in effect on the date of
40 publication of this document. Please review these documents
41 carefully, as they describe your rights and restrictions with respect
42 to this document. Code Components extracted from this document must
43 include Simplified BSD License text as described in Section 4.e of
44 the Trust Legal Provisions and are provided without warranty as
45 described in the Simplified BSD License.
46
47
48
49
50
51
52 Newton & Hollenbeck Standards Track [Page 1]
53 RFC 7483 RDAP JSON Responses March 2015
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3
60 1.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 4
61 2. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 5
62 2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 5
63 3. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 7
64 4. Common Data Structures . . . . . . . . . . . . . . . . . . . 8
65 4.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 8
66 4.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 9
67 4.3. Notices and Remarks . . . . . . . . . . . . . . . . . . . 10
68 4.4. Language Identifier . . . . . . . . . . . . . . . . . . . 11
69 4.5. Events . . . . . . . . . . . . . . . . . . . . . . . . . 11
70 4.6. Status . . . . . . . . . . . . . . . . . . . . . . . . . 13
71 4.7. Port 43 WHOIS Server . . . . . . . . . . . . . . . . . . 13
72 4.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 13
73 4.9. Object Class Name . . . . . . . . . . . . . . . . . . . . 14
74 4.10. An Example . . . . . . . . . . . . . . . . . . . . . . . 14
75 5. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 15
76 5.1. The Entity Object Class . . . . . . . . . . . . . . . . . 16
77 5.2. The Nameserver Object Class . . . . . . . . . . . . . . . 22
78 5.3. The Domain Object Class . . . . . . . . . . . . . . . . . 26
79 5.4. The IP Network Object Class . . . . . . . . . . . . . . . 38
80 5.5. Autonomous System Number Entity Object Class . . . . . . 42
81 6. Error Response Body . . . . . . . . . . . . . . . . . . . . . 45
82 7. Responding to Help Queries . . . . . . . . . . . . . . . . . 48
83 8. Responding To Searches . . . . . . . . . . . . . . . . . . . 48
84 9. Indicating Truncated Responses . . . . . . . . . . . . . . . 49
85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
86 10.1. RDAP JSON Media Type Registration . . . . . . . . . . . 52
87 10.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 53
88 10.2.1. Notice and Remark Types . . . . . . . . . . . . . . 54
89 10.2.2. Status . . . . . . . . . . . . . . . . . . . . . . . 56
90 10.2.3. Event Actions . . . . . . . . . . . . . . . . . . . 49
91 10.2.4. Roles . . . . . . . . . . . . . . . . . . . . . . . 61
92 10.2.5. Variant Relations . . . . . . . . . . . . . . . . . 63
93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 64
94 12. Internationalization Considerations . . . . . . . . . . . . . 64
95 12.1. Character Encoding . . . . . . . . . . . . . . . . . . . 64
96 12.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 64
97 12.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 64
98 12.4. Internationalized Domain Names . . . . . . . . . . . . . 65
99 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 65
100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 65
101 14.1. Normative References . . . . . . . . . . . . . . . . . . 65
102 14.2. Informative References . . . . . . . . . . . . . . . . . 67
103
104
105
106
107 Newton & Hollenbeck Standards Track [Page 2]
108 RFC 7483 RDAP JSON Responses March 2015
109
110
111 Appendix A. Suggested Data Modeling with the Entity Object Class 68
112 A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 68
113 A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 70
114 Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 72
115 Appendix C. Structured vs. Unstructured Addresses . . . . . . . 74
116 Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 76
117 Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 77
118 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 77
119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
120
121 1. Introduction
122
123 This document describes responses in the JSON [RFC7159] format for
124 the queries as defined by the Registration Data Access Protocol Query
125 Format [RFC7482]. A communication protocol for exchanging queries
126 and responses is described in [RFC7480].
127
128 1.1. Terminology and Definitions
129
130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
132 document are to be interpreted as described in [RFC2119] when
133 specified in their uppercase forms.
134
135 The following list describes terminology and definitions used
136 throughout this document:
137
138 DNR: Domain Name Registry
139
140 LDH: letters, digits, hyphen
141
142 member: data found within an object as defined by JSON
143 [RFC7159].
144
145 object: a data structure as defined by JSON [RFC7159].
146
147 object class: the definition of members that may be found in JSON
148 objects described in this document.
149
150 object instance: an instantiation or specific instance of an object
151 class.
152
153 RDAP: Registration Data Access Protocol
154
155 RIR: Regional Internet Registry
156
157
158
159
160
161
162 Newton & Hollenbeck Standards Track [Page 3]
163 RFC 7483 RDAP JSON Responses March 2015
164
165
166 1.2. Data Model
167
168 The data model for JSON responses is specified in five sections:
169
170 1. simple data types conveyed in JSON strings
171
172 2. data structures specified as JSON arrays or objects that are used
173 repeatedly when building up larger objects
174
175 3. object classes representing structured data corresponding to a
176 lookup of a single object
177
178 4. arrays of objects representing structured data corresponding to a
179 search for multiple objects
180
181 5. the response to an error
182
183 The object classes represent responses for two major categories of
184 data: responses returned by RIRs for registration data related to IP
185 addresses, reverse DNS names, and Autonomous System numbers and
186 responses returned by DNRs for registration data related to forward
187 DNS names. The following object classes are returned by both RIRs
188 and DNRs:
189
190 1. domains
191
192 2. nameservers
193
194 3. entities
195
196 The information served by both RIRs and DNRs for these object classes
197 overlap extensively and are given in this document as a unified model
198 for both classes of service.
199
200 In addition to the object classes listed above, RIRs also serve the
201 following object classes:
202
203 1. IP networks
204
205 2. Autonomous System numbers
206
207 Object classes defined in this document represent a minimal set of
208 what a compliant client/server needs to understand to function
209 correctly; however, some deployments may want to include additional
210 object classes to suit individual needs. Anticipating this need for
211 extension, Section 2.1 of this document defines a mechanism for
212 extending the JSON objects that are described in this document.
213
214
215
216
217 Newton & Hollenbeck Standards Track [Page 4]
218 RFC 7483 RDAP JSON Responses March 2015
219
220
221 Positive responses take two forms. A response to a lookup of a
222 single object in the registration system yields a JSON object, which
223 is the subject of the lookup. A response to a search for multiple
224 objects yields a JSON object that contains an array of JSON objects
225 that are the subject of the search. In each type of response, other
226 data structures are present within the topmost JSON object.
227
228 2. Use of JSON
229
230 2.1. Naming
231
232 Clients of these JSON responses SHOULD ignore unrecognized JSON
233 members in responses. Servers can insert members into the JSON
234 responses, which are not specified in this document, but that does
235 not constitute an error in the response. Servers that insert such
236 unspecified members into JSON responses SHOULD have member names
237 prefixed with a short identifier followed by an underscore followed
238 by a meaningful name. It has been observed that these short
239 identifiers aid software implementers with identifying the
240 specification of the JSON member, and failure to use one could cause
241 an implementer to assume the server is erroneously using a name from
242 this specification. This allowance does not apply to jCard [RFC7095]
243 objects. The full JSON name (the prefix plus the underscore plus the
244 meaningful name) SHOULD adhere to the character and name limitations
245 of the prefix registry described in [RFC7480]. Failure to use these
246 limitations could result in slower adoption as these limitations have
247 been observed to aid some client programming models.
248
249 Consider the following JSON response with JSON members, all of which
250 are specified in this document.
251
252 {
253 "handle" : "ABC123",
254 "remarks" :
255 [
256 {
257 "description" :
258 [
259 "She sells sea shells down by the sea shore.",
260 "Originally written by Terry Sullivan."
261 ]
262 }
263 ]
264 }
265
266 Figure 1
267
268
269
270
271
272 Newton & Hollenbeck Standards Track [Page 5]
273 RFC 7483 RDAP JSON Responses March 2015
274
275
276 If The Registry of the Moon desires to express information not found
277 in this specification, it might select "lunarNic" as its identifying
278 prefix and insert, as an example, the member named
279 "lunarNic_beforeOneSmallStep" to signify registrations occurring
280 before the first moon landing and the member named
281 "lunarNic_harshMistressNotes" that contains other descriptive text.
282
283 Consider the following JSON response with JSON names, some of which
284 should be ignored by clients without knowledge of their meaning.
285
286 {
287 "handle" : "ABC123",
288 "lunarNic_beforeOneSmallStep" : "TRUE THAT!",
289 "remarks" :
290 [
291 {
292 "description" :
293 [
294 "She sells sea shells down by the sea shore.",
295 "Originally written by Terry Sullivan."
296 ]
297 }
298 ],
299 "lunarNic_harshMistressNotes" :
300 [
301 "In space,",
302 "nobody can hear you scream."
303 ]
304 }
305
306 Figure 2
307
308 Insertion of unrecognized members ignored by clients may also be used
309 for future revisions to this specification.
310
311 Clients processing JSON responses need to be prepared for members
312 representing registration data specified in this document to be
313 absent from a response. In other words, servers are free to not
314 include JSON members containing registration data based on their own
315 policies.
316
317 Finally, all JSON names specified in this document are case
318 sensitive. Both servers and clients MUST transmit and process them
319 using the specified character case.
320
321
322
323
324
325
326
327 Newton & Hollenbeck Standards Track [Page 6]
328 RFC 7483 RDAP JSON Responses March 2015
329
330
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.
331 3. Common Data Types
332
333 JSON [RFC7159] defines the data types of a number, character string,
334 boolean, array, object, and null. This section describes the
335 semantics and/or syntax reference for common, JSON character strings
336 used in this document.
337
338 handle: DNRs and RIRs have registry-unique identifiers that
339 may be used to specifically reference an object
340 instance. The semantics of this data type as found
341 in this document are to be a registry-unique
342 reference to the closest enclosing object where the
343 value is found. The data type names "registryId",
344 "roid", "nic-handle", "registrationNo", etc., are
345 terms often synonymous with this data type. In
346 this document, the term "handle" is used. The term
347 exposed to users by clients is a presentation issue
348 beyond the scope of this document.
349
350 IPv4 addresses: The representation of IPv4 addresses in this
351 document uses the dotted-decimal notation. An
352 example of this textual representation is
353 "192.0.2.0".
354
355 IPv6 addresses: The representation of IPv6 addresses in this
356 document follow the forms outlined in [RFC5952].
357 An example of this textual representation is
358 "2001:db8::1:0:0:1".
359
360 country codes: Where the identity of a geopolitical nation or
361 country is needed, these identities are represented
362 with the alpha-2 or two-character country code
363 designation as defined in [ISO.3166.1988]. The
364 alpha-2 representation is used because it is freely
365 available, whereas the alpha-3 and numeric-3
366 standards are not.
367
368 LDH names: Textual representations of DNS names where the
369 labels of the domain are all "letters, digits,
370 hyphen" labels as described by [RFC5890]. Trailing
371 periods are optional.
372
373 Unicode names: Textual representations of DNS names where one or
374 more of the labels are U-labels as described by
375 [RFC5890]. Trailing periods are optional.
376
377 dates and times: The syntax for values denoting dates and times is
378 defined in [RFC3339].
379
380
381
382 Newton & Hollenbeck Standards Track [Page 7]
383 RFC 7483 RDAP JSON Responses March 2015
384
385
386 URIs: The syntax for values denoting a Uniform Resource
387 Identifier (URI) is defined by [RFC3986].
388
389 Contact information is defined using jCards as described in
390 [RFC7095].
391
392 4. Common Data Structures
393
394 This section defines common data structures used in responses and
395 object classes.
396
397 4.1. RDAP Conformance
398
399 The data structure named "rdapConformance" is an array of strings,
400 each providing a hint as to the specifications used in the
401 construction of the response. This data structure appears only in
402 the topmost JSON object of a response.
403
404 An example rdapConformance data structure:
405
406 "rdapConformance" :
407 [
408 "rdap_level_0"
409 ]
410
411 Figure 3
412
413 The string literal "rdap_level_0" signifies conformance with this
414 specification. When custom JSON values are inserted into responses,
415 conformance to those custom specifications MUST use a string prefixed
416 with the appropriate identifier from the IANA RDAP Extensions
417 registry specified in [RFC7480]. For example, if the fictional
418 Registry of the Moon wants to signify that their JSON responses are
419 conformant with their registered extensions, the string used might be
420 "lunarNIC_level_0". These prefixes aid the identification of
421 specifications for software implementers, and failure to use them
422 could result in slower adoption of extensions.
423
424 Example rdapConformance structure with custom extensions noted:
425
426 "rdapConformance" :
427 [
428 "rdap_level_0",
429 "lunarNic_level_0"
430 ]
431
432 Figure 4
433
434
435
436
437 Newton & Hollenbeck Standards Track [Page 8]
438 RFC 7483 RDAP JSON Responses March 2015
439
440
441 4.2. Links
442
443 The "links" array is found in data structures to signify links to
444 other resources on the Internet. The relationship of these links is
445 defined by the IANA registry described by [RFC5988].
446
447 The following is an example of the link structure:
448
449 {
450 "value" : "http://example.com/context_uri",
451 "rel" : "self",
452 "href" : "http://example.com/target_uri",
453 "hreflang" : [ "en", "ch" ],
454 "title" : "title",
455 "media" : "screen",
456 "type" : "application/json"
457 }
458
459 Figure 5
460
461 The JSON name/values of "rel", "href", "hreflang", "title", "media",
462 and "type" correspond to values found in Section 5 of [RFC5988]. The
463 "value" JSON value is the context URI as described by [RFC5988]. The
464 "href" JSON value MUST be specified. All other JSON values are
465 OPTIONAL.
466
467 This is an example of the "links" array as it might be found in an
468 object class:
469
470 "links" :
471 [
472 {
473 "value" : "http://example.com/ip/2001:db8::123",
474 "rel" : "self",
475 "href" : "http://example.com/ip/2001:db8::123",
476 "type" : "application/rdap+json"
477 },
478 {
479 "value" : "http://example.com/ip/2001:db8::123",
480 "rel" : "up",
481 "href" : "http://example.com/ip/2001:db8::/48",
482 "type" : "application/rdap+json"
483 }
484
485 ]
486
487 Figure 6
488
489
490
491
492 Newton & Hollenbeck Standards Track [Page 9]
493 RFC 7483 RDAP JSON Responses March 2015
494
495
496 4.3. Notices and Remarks
497
498 The "notices" and "remarks" data structures take the same form. The
499 notices structure denotes information about the service providing
500 RDAP information and/or information about the entire response,
501 whereas the remarks structure denotes information about the object
502 class that contains it (see Section 5 regarding object classes).
503
504 Both are arrays of objects. Each object contains an optional "title"
505 string representing the title of the object, an optional "type"
506 string denoting a registered type of remark or notice (see
507 Section 10.2.1), an array of strings named "description" for the
508 purposes of conveying any descriptive text, and an optional "links"
509 array as described in Section 4.2.
510
511 An example of the notices data structure:
512
513 "notices" :
514 [
515 {
516 "title" : "Terms of Use",
517 "description" :
518 [
519 "Service subject to The Registry of the Moon's TOS.",
520 "Copyright (c) 2020 LunarNIC"
521 ],
522 "links" :
523 [
524 {
525 "value" : "http://example.net/entity/XXXX",
526 "rel" : "alternate",
527 "type" : "text/html",
528 "href" : "http://www.example.com/terms_of_use.html"
529 }
530 ]
531 }
532 ]
533
534 Figure 7
535
536 It is the job of the clients to determine line breaks, spacing, and
537 display issues for sentences within the character strings of the
538 "description" array. Each string in the "description" array contains
539 a single complete division of human-readable text indicating to
540 clients where there are semantic breaks.
541
542
543
544
545
546
547 Newton & Hollenbeck Standards Track [Page 10]
548 RFC 7483 RDAP JSON Responses March 2015
549
550
551 An example of the remarks data structure:
552
553 "remarks" :
554 [
555 {
556 "description" :
557 [
558 "She sells sea shells down by the sea shore.",
559 "Originally written by Terry Sullivan."
560 ]
561 }
562 ]
563
564 Figure 8
565
566 Note that objects in the "remarks" array may also have a "links"
567 array.
568
569 While the "title" and "description" fields are intended primarily for
570 human consumption, the "type" string contains a well-known value to
571 be registered with IANA (see Section 10.2.1) for programmatic use.
572
573 An example of the remarks data structure:
574
575 "remarks" :
576 [
577 {
578 "type" : "object truncated due to authorization",
579 "description" :
580 [
581 "Some registration data may not have been given.",
582 "Use proper authorization credentials to see all of it."
583 ]
584 }
585 ]
586
587 Figure 9
588
589 While the "remarks" array will appear in many object classes in a
590 response, the "notices" array appears only in the topmost object of a
591 response.
592
593
594
595
596
597
598
599
600
601
602 Newton & Hollenbeck Standards Track [Page 11]
603 RFC 7483 RDAP JSON Responses March 2015
604
605
606 4.4. Language Identifier
607
608 This data structure consists solely of a name/value pair, where the
609 name is "lang" and the value is a string containing a language
610 identifier as described in [RFC5646].
611
612 "lang" : "mn-Cyrl-MN"
613
614 Figure 10
615
616 The "lang" attribute may appear anywhere in an object class or data
617 structure except for in jCard objects.
618
619 4.5. Events
620
621 This data structure represents events that have occurred on an
622 instance of an object class (see Section 5 regarding object classes).
623
624 This is an example of an "events" array.
625
626 "events" :
627 [
628 {
629 "eventAction" : "registration",
630 "eventActor" : "SOMEID-LUNARNIC",
631 "eventDate" : "1990-12-31T23:59:59Z"
632 },
633 {
634 "eventAction" : "last changed",
635 "eventActor" : "OTHERID-LUNARNIC",
636 "eventDate" : "1991-12-31T23:59:59Z"
637 }
638 ]
639
640 Figure 11
641
642 The "events" array consists of objects, each with the following
643 members:
644
645 o "eventAction" -- a string denoting the reason for the event
646
647 o "eventActor" -- an optional identifier denoting the actor
648 responsible for the event
649
650 o "eventDate" -- a string containing the time and date the event
651 occurred.
652
653 o "links" -- see Section 4.2
654
655
656
657 Newton & Hollenbeck Standards Track [Page 12]
658 RFC 7483 RDAP JSON Responses March 2015
659
660
661 Events can be future dated. One use case for future dating of events
662 is to denote when an object expires from a registry.
663
664 The "links" array in this data structure is provided for references
665 to the event actor. In order to reference an RDAP entity, a "rel" of
666 "related" and a "type" of "application/rdap+json" is used in the link
667 reference.
668
669 See Section 10.2.3 for a list of values for the "eventAction" string.
670 See Appendix B regarding the various ways events can be modeled.
671
672 4.6. Status
673
674 This data structure, named "status", is an array of strings
675 indicating the state of a registered object (see Section 10.2.2 for a
676 list of values).
677
678 4.7. Port 43 WHOIS Server
679
680 This data structure, a member named "port43", is a simple string
681 containing the fully qualified host name or IP address of the WHOIS
682 [RFC3912] server where the containing object instance may be found.
683 Note that this is not a URI, as there is no WHOIS URI scheme.
684
handle: DNRs and RIRs have registry-unique identifiers that
may be used to specifically reference an object
instance. The semantics of this data type as found
in this document are to be a registry-unique
reference to the closest enclosing object where the
value is found. The data type names "registryId",
"roid", "nic-handle", "registrationNo", etc., are
terms often synonymous with this data type. In
this document, the term "handle" is used. The term
exposed to users by clients is a presentation issue
beyond the scope of this document.
handle: DNRs and RIRs have registry-unique identifiers that
may be used to specifically reference an object
instance. The semantics of this data type as found
in this document are to be a registry-unique
reference to the closest enclosing object where the
value is found. The data type names "registryId",
"roid", "nic-handle", "registrationNo", etc., are
terms often synonymous with this data type. In
this document, the term "handle" is used. The term
exposed to users by clients is a presentation issue
beyond the scope of this document. This value is a
simple string.
All uses of handle in section 5 call "handle" out as being a string, but if a reader were to only read section 3 they would not know it.
685 4.8. Public IDs
686
687 This data structure maps a public identifier to an object class. It
688 is named "publicIds" and is an array of objects, with each object
689 containing the following members:
690
691 o type -- a string denoting the type of public identifier
692
693 o identifier -- a public identifier of the type denoted by "type"
694
695 The following is an example of a publicIds structure.
696
697 "publicIds":
698 [
699 {
700 "type":"IANA Registrar ID",
701 "identifier":"1"
702 }
703 ]
704
705 Figure 12
706
707
708
709
710
711
712 Newton & Hollenbeck Standards Track [Page 13]
713 RFC 7483 RDAP JSON Responses March 2015
714
715
716 4.9. Object Class Name
717
718 This data structure, a member named "objectClassName", gives the
719 object class name of a particular object as a string. This
720 identifies the type of object being processed. An objectClassName is
721 REQUIRED in all RDAP response objects so that the type of the object
722 can be interpreted.
723
724 4.10. An Example
725
726 This is an example response with both rdapConformance and notices
727 embedded:
728
729 {
730 "rdapConformance" :
731 [
732 "rdap_level_0"
733 ],
734 "notices" :
735 [
736 {
737 "title" : "Content Removed",
738 "description" :
739 [
740 "Without full authorization, content has been removed.",
741 "Sorry, dude!"
742 ],
743 "links" :
744 [
745 {
746 "value" : "http://example.net/ip/192.0.2.0/24",
747 "rel" : "alternate",
748 "type" : "text/html",
749 "href" : "http://www.example.com/redaction_policy.html"
750 }
751 ]
752 }
753 ],
754 "lang" : "en",
755 "objectClassName" : "ip network",
756 "startAddress" : "192.0.2.0",
757 "endAddress" : "192.0.2.255",
758 "handle" : "XXXX-RIR",
759 "ipVersion" : "v4",
760 "name": "NET-RTR-1",
761 "parentHandle" : "YYYY-RIR",
762 "remarks" :
763 [
764
765
766
767 Newton & Hollenbeck Standards Track [Page 14]
768 RFC 7483 RDAP JSON Responses March 2015
769
770
771 {
772 "description" :
773 [
774 "She sells sea shells down by the sea shore.",
775 "Originally written by Terry Sullivan."
776 ]
777 }
778 ]
779 }
780
781 Figure 13
782
783 5. Object Classes
784
785 Object classes represent structures appropriate for a response from
786 the queries specified in [RFC7482].
787
788 Each object class contains a "links" array as specified in
789 Section 4.2. For every object class instance in a response, whether
790 the object class instance is directly representing the response to a
791 query or is embedded in other object class instances or is an item in
792 a search result set, servers SHOULD provide a link representing a URI
793 for that object class instance using the "self" relationship as
794 described in the IANA registry specified by [RFC5988]. As explained
795 in Section 5.2, this may be not always be possible for nameserver
796 data. Clients MUST be able to process object instances without a
797 self link. When present, clients can use the self link for caching
798 data. Servers MAY provide more than one self link for any given
799 object instance. Failure to provide any self link by a server may
800 result in clients being unable to cache object class instances.
801
802 Clients using self links for caching SHOULD not cache any object
803 class instances where the authority of the self link is different
804 than the authority of the server returning the data. Failing to do
805 so might result in cache poisoning.
806
807 Self links MUST contain a "type" element containing the "application/
808 rdap+json" media type when referencing RDAP object instances as
809 defined by this document.
810
811
812
813
814
815
816
817
818
819
820
821
822 Newton & Hollenbeck Standards Track [Page 15]
823 RFC 7483 RDAP JSON Responses March 2015
824
825
826 This is an example of the "links" array with a self link to an object
827 class:
828
829 "links" :
830 [
831 {
832 "value" : "http://example.com/ip/2001:db8::123",
833 "rel" : "self",
834 "href" : "http://example.com/ip/2001:db8::123",
835 "type" : "application/rdap+json"
836 }
837 ]
838
839 Figure 14
840
841 5.1. The Entity Object Class
842
843 The entity object class appears throughout this document and is an
844 appropriate response for the /entity/XXXX query defined in
845 "Registration Data Access Protocol (RDAP) Query Format" [RFC7482].
846 This object class represents the information of organizations,
847 corporations, governments, non-profits, clubs, individual persons,
848 and informal groups of people. All of these representations are so
849 similar that it is best to represent them in JSON [RFC7159] with one
850 construct, the entity object class, to aid in the reuse of code by
851 implementers.
852
853 The entity object class uses jCard [RFC7095] to represent contact
854 information, such as postal addresses, email addresses, phone numbers
855 and names of organizations and individuals. Many of the types of
856 information that can be represented with jCard have no use in RDAP,
857 such as birthdays, anniversaries, and gender.
858
859 The entity object is served by both RIRs and DNRs. The following is
860 an example of an entity that might be served by an RIR.
861
862 {
863 "objectClassName" : "entity",
864 "handle":"XXXX",
865 "vcardArray":[
866 "vcard",
867 [
868 ["version", {}, "text", "4.0"],
869 ["fn", {}, "text", "Joe User"],
870 ["n", {}, "text",
871 ["User", "Joe", "", "", ["ing. jr", "M.Sc."]]
872 ],
873 ["kind", {}, "text", "individual"],
874
875
876
877 Newton & Hollenbeck Standards Track [Page 16]
878 RFC 7483 RDAP JSON Responses March 2015
879
880
881 ["lang", {
882 "pref":"1"
883 }, "language-tag", "fr"],
884 ["lang", {
885 "pref":"2"
886 }, "language-tag", "en"],
887 ["org", {
888 "type":"work"
889 }, "text", "Example"],
890 ["title", {}, "text", "Research Scientist"],
891 ["role", {}, "text", "Project Lead"],
892 ["adr",
893 { "type":"work" },
894 "text",
895 [
896 "",
897 "Suite 1234",
898 "4321 Rue Somewhere",
899 "Quebec",
900 "QC",
901 "G1V 2M2",
902 "Canada"
903 ]
904 ],
905 ["adr",
906 {
907 "type":"home",
908 "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n"
909 },
910 "text",
911 [
912 "", "", "", "", "", "", ""
913 ]
914 ],
915 ["tel",
916 {
917 "type":["work", "voice"],
918 "pref":"1"
919 },
920 "uri",
921 "tel:+1-555-555-1234;ext=102"
922 ],
923 ["tel",
924 { "type":["work", "cell", "voice", "video", "text"] },
925 "uri",
926 "tel:+1-555-555-4321"
927 ],
928 ["email",
929
930
931
932 Newton & Hollenbeck Standards Track [Page 17]
933 RFC 7483 RDAP JSON Responses March 2015
934
935
936 { "type":"work" },
937 "text",
938 "joe.user@example.com"
939 ],
940 ["geo", {
941 "type":"work"
942 }, "uri", "geo:46.772673,-71.282945"],
943 ["key",
944 { "type":"work" },
945 "uri",
946 "http://www.example.com/joe.user/joe.asc"
947 ],
948 ["tz", {},
949 "utc-offset", "-05:00"],
950 ["url", { "type":"home" },
951 "uri", "http://example.org"]
952 ]
953 ],
954 "roles":[ "registrar" ],
955 "publicIds":[
956 {
957 "type":"IANA Registrar ID",
958 "identifier":"1"
959 }
960 ],
961 "remarks":[
962 {
963 "description":[
964 "She sells sea shells down by the sea shore.",
965 "Originally written by Terry Sullivan."
966 ]
967 }
968 ],
969 "links":[
970 {
971 "value":"http://example.com/entity/XXXX",
972 "rel":"self",
973 "href":"http://example.com/entity/XXXX",
974 "type" : "application/rdap+json"
975 }
976 ],
977 "events":[
978 {
979 "eventAction":"registration",
980 "eventDate":"1990-12-31T23:59:59Z"
981 }
982 ],
983 "asEventActor":[
984
985
986
987 Newton & Hollenbeck Standards Track [Page 18]
988 RFC 7483 RDAP JSON Responses March 2015
989
990
991 {
992 "eventAction":"last changed",
993 "eventDate":"1991-12-31T23:59:59Z"
994 }
995 ]
996 }
997
998 Figure 15
999
1000 The entity object class can contain the following members:
1001
1002 o objectClassName -- the string "entity"
1003
1004 o handle -- a string representing a registry unique identifier of
1005 the entity
1006
1007 o vcardArray -- a jCard with the entity's contact information
1008
1009 o roles -- an array of strings, each signifying the relationship an
1010 object would have with its closest containing object (see
1011 Section 10.2.4 for a list of values)
1012
1013 o publicIds -- see Section 4.8
1014
1015 o entities -- an array of entity objects as defined by this section
1016
1017 o remarks -- see Section 4.3
1018
1019 o links -- see Section 4.2
1020
1021 o events -- see Section 4.5
1022
1023 o asEventActor -- this data structure takes the same form as the
1024 events data structure (see Section 4.5), but each object in the
1025 array MUST NOT have an "eventActor" member. These objects denote
1026 that the entity is an event actor for the given events. See
1027 Appendix B regarding the various ways events can be modeled.
1028
1029 o status -- see Section 4.6
1030
1031 o port43 -- see Section 4.7
1032
1033 o networks -- an array of IP network objects as defined in
1034 Section 5.4
1035
1036 o autnums -- an array of autnum objects as defined in Section 5.5
1037
1038
1039
1040
1041
1042 Newton & Hollenbeck Standards Track [Page 19]
1043 RFC 7483 RDAP JSON Responses March 2015
1044
1045
1046 Entities may also have other entities embedded with them in an array.
1047 This can be used to model an organization with specific individuals
1048 fulfilling designated roles of responsibility.
1049
1050 The following is an elided example of an entity with embedded
1051 entities.
1052
1053 {
1054 "objectClassName" : "entity",
1055 "handle" : "ANENTITY",
1056 "roles" : [ "registrar" ],
1057 ...
1058 "entities" :
1059 [
1060 {
1061 "objectClassName" : "entity",
1062 "handle": "ANEMBEDDEDENTITY",
1063 "roles" : [ "technical" ],
1064 ...
1065 },
1066 ...
1067 ],
1068 ...
1069 }
1070
1071 Figure 16
1072
1073 The following is an example of an entity that might be served by a
1074 DNR.
1075
1076 {
1077 "objectClassName" : "entity",
1078 "handle":"XXXX",
1079 "vcardArray":[
1080 "vcard",
1081 [
1082 ["version", {}, "text", "4.0"],
1083 ["fn", {}, "text", "Joe User"],
1084 ["kind", {}, "text", "individual"],
1085 ["lang", {
1086 "pref":"1"
1087 }, "language-tag", "fr"],
1088 ["lang", {
1089 "pref":"2"
1090 }, "language-tag", "en"],
1091 ["org", {
1092 "type":"work"
1093 }, "text", "Example"],
1094
1095
1096
1097 Newton & Hollenbeck Standards Track [Page 20]
1098 RFC 7483 RDAP JSON Responses March 2015
1099
1100
1101 ["title", {}, "text", "Research Scientist"],
1102 ["role", {}, "text", "Project Lead"],
1103 ["adr",
1104 { "type":"work" },
1105 "text",
1106 [
1107 "",
1108 "Suite 1234",
1109 "4321 Rue Somewhere",
1110 "Quebec",
1111 "QC",
1112 "G1V 2M2",
1113 "Canada"
1114 ]
1115 ],
1116 ["tel",
1117 { "type":["work", "voice"], "pref":"1" },
1118 "uri", "tel:+1-555-555-1234;ext=102"
1119 ],
1120 ["email",
1121 { "type":"work" },
1122 "text", "joe.user@example.com"
1123 ]
1124 ]
1125 ],
1126 "status":[ "validated", "locked" ],
1127 "remarks":[
1128 {
1129 "description":[
1130 "She sells sea shells down by the sea shore.",
1131 "Originally written by Terry Sullivan."
1132 ]
1133 }
1134 ],
1135 "links":[
1136 {
1137 "value":"http://example.com/entity/XXXX",
1138 "rel":"self",
1139 "href":"http://example.com/entity/XXXX",
1140 "type":"application/rdap+json"
1141 }
1142 ],
1143 "port43":"whois.example.net",
1144 "events":[
1145 {
1146 "eventAction":"registration",
1147 "eventDate":"1990-12-31T23:59:59Z"
1148 },
1149
1150
1151
1152 Newton & Hollenbeck Standards Track [Page 21]
1153 RFC 7483 RDAP JSON Responses March 2015
1154
1155
1156 {
1157 "eventAction":"last changed",
1158 "eventDate":"1991-12-31T23:59:59Z",
1159 "eventActor":"joe@example.com"
1160 }
1161 ]
1162 }
1163
1164 Figure 17
1165
1166 See Appendix A for use of the entity object class to model various
1167 types of entities found in both RIRs and DNRs. See Appendix C
1168 regarding structured vs. unstructured postal addresses in entities.
1169
1170 5.2. The Nameserver Object Class
1171
1172 The nameserver object class represents information regarding DNS
1173 nameservers used in both forward and reverse DNS. RIRs and some DNRs
1174 register or expose nameserver information as an attribute of a domain
1175 name, while other DNRs model nameservers as "first class objects".
1176
1177 The nameserver object class accommodates both models and degrees of
1178 variation in between.
1179
1180 The following is an example of a nameserver object.
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207 Newton & Hollenbeck Standards Track [Page 22]
1208 RFC 7483 RDAP JSON Responses March 2015
1209
1210
1211 {
1212 "objectClassName" : "nameserver",
1213 "handle" : "XXXX",
identifier -- a public identifier of the type denoted by "type"
identifier -- a string denoting a public identifier of the type
related to "type"
While the example given in section 4.8 shows "identifier" being a string, the prose description does not clearly state it.
1214 "ldhName" : "ns1.xn--fo-5ja.example",
1215 "unicodeName" : "ns1.foo.example",
1216 "status" : [ "active" ],
1217 "ipAddresses" :
1218 {
1219 "v4": [ "192.0.2.1", "192.0.2.2" ],
1220 "v6": [ "2001:db8::123" ]
1221 },
1222 "remarks" :
1223 [
1224 {
1225 "description" :
1226 [
1227 "She sells sea shells down by the sea shore.",
1228 "Originally written by Terry Sullivan."
1229 ]
1230 }
1231 ],
1232 "links" :
1233 [
1234 {
1235 "value" : "http://example.net/nameserver/xxxx",
1236 "rel" : "self",
1237 "href" : "http://example.net/nameserver/xxxx",
1238 "type" : "application/rdap+json"
1239 }
1240 ],
1241 "port43" : "whois.example.net",
1242 "events" :
1243 [
1244 {
1245 "eventAction" : "registration",
1246 "eventDate" : "1990-12-31T23:59:59Z"
1247 },
1248 {
1249 "eventAction" : "last changed",
1250 "eventDate" : "1991-12-31T23:59:59Z",
1251 "eventActor" : "joe@example.com"
1252 }
1253 ]
1254 }
1255
1256
1257 Figure 18
1258
1259
1260
1261
1262 Newton & Hollenbeck Standards Track [Page 23]
1263 RFC 7483 RDAP JSON Responses March 2015
1264
1265
1266 Figure 18 is an example of a nameserver object with all values given.
1267 Registries using a first-class nameserver data model would embed this
1268 in domain objects as well as allowing references to it with the
1269 "/nameserver" query type (all depending on the registry operators
1270 policy). Other registries may pare back the information as needed.
1271 Figure 19 is an example of a nameserver object as would be found in
1272 RIRs and some DNRs, while Figure 20 is an example of a nameserver
1273 object as would be found in other DNRs.
1274
1275 The following is an example of the simplest nameserver object:
1276
1277 {
1278 "objectClassName" : "nameserver",
1279 "ldhName" : "ns1.example.com"
1280 }
1281
1282 Figure 19
1283
1284 The following is an example of a simple nameserver object that might
1285 be commonly used by DNRs:
1286
1287 {
1288 "objectClassName" : "nameserver",
1289 "ldhName" : "ns1.example.com",
1290 "ipAddresses" : { "v6" : [ "2001:db8::123", "2001:db8::124" ] }
1291 }
1292
1293 Figure 20
1294
1295 As nameservers can be modeled by some registries to be first-class
1296 objects, they may also have an array of entities (Section 5.1)
1297 embedded to signify parties responsible for the maintenance,
1298 registrations, etc., of the nameservers.
1299
1300 The following is an elided example of a nameserver with embedded
1301 entities.
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317 Newton & Hollenbeck Standards Track [Page 24]
1318 RFC 7483 RDAP JSON Responses March 2015
1319
1320
1321 {
1322 "objectClassName" : "nameserver",
1323 "handle" : "XXXX",
1324 "ldhName" : "ns1.xn--fo-5ja.example",
1325 ...
1326 "entities" :
1327 [
1328 ...
1329 ],
1330 ...
1331 }
1332
1333 Figure 21
1334
1335 The nameserver object class can contain the following members:
1336
1337 o objectClassName -- the string "nameserver"
1338
1339 o handle -- a string representing a registry unique identifier of
1340 the nameserver
1341
1342 o ldhName -- a string containing the LDH name of the nameserver (see
1343 Section 3)
1344
1345 o unicodeName -- a string containing a DNS Unicode name of the
1346 nameserver (see Section 3)
1347
1348 o ipAddresses -- an object containing the following members:
1349
1350 * v6 -- an array of strings containing IPv6 addresses of the
1351 nameserver
1352
1353 * v4 -- an array of strings containing IPv4 addresses of the
1354 nameserver
1355
1356 o entities -- an array of entity objects as defined by Section 5.1
1357
1358 o status -- see Section 4.6
1359
1360 o remarks -- see Section 4.3
1361
1362 o links -- see Section 4.2
1363
1364 o port43 -- see Section 4.7
1365
1366 o events -- see Section 4.5
1367
1368
1369
1370
1371
1372 Newton & Hollenbeck Standards Track [Page 25]
1373 RFC 7483 RDAP JSON Responses March 2015
1374
1375
"ldhName" : "ns1.xn--fo-5ja.example", "unicodeName" : "ns1.foo.example",
"ldhName" : "ns1.xn--fo-5ja.example", "unicodeName" : "ns1.foóo.example",
1376 5.3. The Domain Object Class
1377
1378 The domain object class represents a DNS name and point of
1379 delegation. For RIRs, these delegation points are in the reverse DNS
1380 tree, whereas for DNRs, these delegation points are in the forward
1381 DNS tree.
1382
1383 In both cases, the high-level structure of the domain object class
1384 consists of information about the domain registration, nameserver
1385 information related to the domain name, and entities related to the
1386 domain name (e.g., registrant information, contacts, etc.).
1387
1388 The following is an elided example of the domain object showing the
1389 high-level structure:
1390
1391 {
1392 "objectClassName" : "domain",
1393 "handle" : "XXX",
1394 "ldhName" : "blah.example.com",
1395 ...
1396 "nameservers" :
1397 [
1398 ...
1399 ],
1400 ...
1401 "entities" :
1402 [
1403 ...
1404 ]
1405 }
1406
1407 Figure 22
1408
1409 The domain object class can contain the following members:
1410
1411 o objectClassName -- the string "domain"
1412
1413 o handle -- a string representing a registry unique identifier of
1414 the domain object instance
1415
1416 o ldhName -- a string describing a domain name in LDH form as
1417 described in Section 3
1418
1419 o unicodeName -- a string containing a domain name with U-labels as
1420 described in Section 3
1421
1422
1423
1424
1425
1426
1427 Newton & Hollenbeck Standards Track [Page 26]
1428 RFC 7483 RDAP JSON Responses March 2015
1429
1430
1431 o variants -- an array of objects, each containing the following
1432 values:
1433
1434 * relation -- an array of strings, with each string denoting the
1435 relationship between the variants and the containing domain
1436 object (see Section 10.2.5 for a list of suggested variant
1437 relations).
1438
1439 * idnTable -- the name of the Internationalized Domain Name (IDN)
1440 table of codepoints, such as one listed with the IANA (see IDN
1441 tables [IANA_IDNTABLES]).
1442
1443 * variantNames -- an array of objects, with each object
1444 containing an "ldhName" member and a "unicodeName" member (see
1445 Section 3).
1446
1447 o nameservers -- an array of nameserver objects as defined by
1448 Section 5.2
1449
1450 o secureDNS -- an object with the following members:
1451
1452 * zoneSigned -- true if the zone has been signed, false
1453 otherwise.
1454
1455 * delegationSigned -- boolean true if there are DS records in the
1456 parent, false otherwise.
1457
1458 * maxSigLife -- an integer representing the signature lifetime in
1459 seconds to be used when creating the RRSIG DS record in the
1460 parent zone [RFC5910].
1461
1462 * dsData -- an array of objects, each with the following members:
1463
1464 + keyTag -- an integer as specified by the key tag field of a
1465 DNS DS record as specified by [RFC4034] in presentation
1466 format
1467
1468 + algorithm -- an integer as specified by the algorithm field
1469 of a DNS DS record as described by RFC 4034 in presentation
1470 format
1471
1472 + digest -- a string as specified by the digest field of a DNS
1473 DS record as specified by RFC 4034 in presentation format
1474
1475 + digestType -- an integer as specified by the digest type
1476 field of a DNS DS record as specified by RFC 4034 in
1477 presentation format
1478
1479
1480
1481
1482 Newton & Hollenbeck Standards Track [Page 27]
1483 RFC 7483 RDAP JSON Responses March 2015
1484
1485
1486 + events -- see Section 4.5
1487
1488 + links -- see Section 4.2
1489
1490 * keyData -- an array of objects, each with the following
1491 members:
1492
1493 + flags -- an integer representing the flags field value in
1494 the DNSKEY record [RFC4034] in presentation format
1495
1496 + protocol -- an integer representation of the protocol field
1497 value of the DNSKEY record [RFC4034] in presentation format
1498
1499 + publicKey -- a string representation of the public key in
1500 the DNSKEY record [RFC4034] in presentation format
1501
1502 + algorithm -- an integer as specified by the algorithm field
1503 of a DNSKEY record as specified by [RFC4034] in presentation
1504 format
1505
1506 + events -- see Section 4.5
1507
1508 + links -- see Section 4.2
1509
1510 See Appendix D for background information on these objects.
1511
1512 o entities -- an array of entity objects as defined by Section 5.1
1513
1514 o status -- see Section 4.6
1515
1516 o publicIds -- see Section 4.8
1517
1518 o remarks -- see Section 4.3
1519
1520 o links -- see Section 4.2
1521
1522 o port43 -- see Section 4.7
1523
1524 o events -- see Section 4.5
1525
1526 o network -- represents the IP network for which a reverse DNS
1527 domain is referenced. See Section 5.4
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537 Newton & Hollenbeck Standards Track [Page 28]
1538 RFC 7483 RDAP JSON Responses March 2015
1539
1540
1541 The following is an example of a JSON domain object representing a
1542 reverse DNS delegation point that might be served by an RIR.
1543
1544 {
1545 "objectClassName" : "domain",
1546 "handle" : "XXXX",
1547 "ldhName" : "0.2.192.in-addr.arpa",
1548 "nameservers" :
1549 [
1550 {
1551 "objectClassName" : "nameserver",
1552 "ldhName" : "ns1.rir.example"
1553 },
1554 {
1555 "objectClassName" : "nameserver",
1556 "ldhName" : "ns2.rir.example"
1557 }
1558 ],
1559 "secureDNS":
1560 {
1561 "delegationSigned": true,
1562 "dsData":
1563 [
1564 {
1565 "keyTag": 12345,
1566 "algorithm": 3,
1567 "digestType": 1,
1568 "digest": "49FD46E6C4B45C55D4AC"
1569 }
1570 ]
1571 },
1572 "remarks" :
1573 [
1574 {
1575 "description" :
1576 [
1577 "She sells sea shells down by the sea shore.",
1578 "Originally written by Terry Sullivan."
1579 ]
1580 }
1581 ],
1582 "links" :
1583 [
1584 {
1585 "value": "http://example.net/domain/XXXX",
1586 "rel" : "self",
1587 "href" : "http://example.net/domain/XXXXX",
1588 "type" : "application/rdap+json"
1589
1590
1591
1592 Newton & Hollenbeck Standards Track [Page 29]
1593 RFC 7483 RDAP JSON Responses March 2015
1594
1595
1596 }
1597 ],
1598 "events" :
1599 [
1600 {
1601 "eventAction" : "registration",
1602 "eventDate" : "1990-12-31T23:59:59Z"
1603 },
1604 {
1605 "eventAction" : "last changed",
1606 "eventDate" : "1991-12-31T23:59:59Z",
1607 "eventActor" : "joe@example.com"
1608 }
1609 ],
1610 "entities" :
1611 [
1612 {
1613 "objectClassName" : "entity",
1614 "handle" : "XXXX",
1615 "vcardArray":[
1616 "vcard",
1617 [
1618 ["version", {}, "text", "4.0"],
1619 ["fn", {}, "text", "Joe User"],
1620 ["kind", {}, "text", "individual"],
1621 ["lang", {
1622 "pref":"1"
1623 }, "language-tag", "fr"],
1624 ["lang", {
1625 "pref":"2"
1626 }, "language-tag", "en"],
1627 ["org", {
1628 "type":"work"
1629 }, "text", "Example"],
1630 ["title", {}, "text", "Research Scientist"],
1631 ["role", {}, "text", "Project Lead"],
1632 ["adr",
1633 { "type":"work" },
1634 "text",
1635 [
1636 "",
1637 "Suite 1234",
1638 "4321 Rue Somewhere",
1639 "Quebec",
1640 "QC",
1641 "G1V 2M2",
1642 "Canada"
1643 ]
1644
1645
1646
1647 Newton & Hollenbeck Standards Track [Page 30]
1648 RFC 7483 RDAP JSON Responses March 2015
1649
1650
1651 ],
1652 ["tel",
1653 { "type":["work", "voice"], "pref":"1" },
1654 "uri", "tel:+1-555-555-1234;ext=102"
1655 ],
1656 ["email",
1657 { "type":"work" },
1658 "text", "joe.user@example.com"
1659 ]
1660 ]
1661 ],
1662 "roles" : [ "registrant" ],
1663 "remarks" :
1664 [
1665 {
1666 "description" :
1667 [
1668 "She sells sea shells down by the sea shore.",
1669 "Originally written by Terry Sullivan."
1670 ]
1671 }
1672 ],
1673 "links" :
1674 [
1675 {
1676 "value": "http://example.net/entity/xxxx",
1677 "rel" : "self",
1678 "href" : "http://example.net/entity/xxxx",
1679 "type" : "application/rdap+json"
1680 }
1681 ],
1682 "events" :
1683 [
1684 {
1685 "eventAction" : "registration",
1686 "eventDate" : "1990-12-31T23:59:59Z"
1687 },
1688 {
1689 "eventAction" : "last changed",
1690 "eventDate" : "1991-12-31T23:59:59Z",
1691 "eventActor" : "joe@example.com"
1692 }
1693 ]
1694 }
1695 ],
1696 "network" :
1697 {
1698 "objectClassName" : "ip network",
1699
1700
1701
1702 Newton & Hollenbeck Standards Track [Page 31]
1703 RFC 7483 RDAP JSON Responses March 2015
1704
1705
1706 "handle" : "XXXX-RIR",
1707 "startAddress" : "192.0.2.0",
1708 "endAddress" : "192.0.2.255",
1709 "ipVersion" : "v6",
1710 "name": "NET-RTR-1",
1711 "type" : "DIRECT ALLOCATION",
1712 "country" : "AU",
1713 "parentHandle" : "YYYY-RIR",
1714 "status" : [ "active" ]
1715 }
1716 }
1717
1718 Figure 23
1719
1720 The following is an example of a JSON domain object representing a
1721 forward DNS delegation point that might be served by a DNR.
1722
1723 {
1724 "objectClassName" : "domain",
1725 "handle" : "XXXX",
"network" :
{
"objectClassName" : "ip network",
"handle" : "XXXX-RIR",
"startAddress" : "192.0.2.0",
"endAddress" : "192.0.2.255",
"ipVersion" : "v6",
"network" :
{
"objectClassName" : "ip network",
"handle" : "XXXX-RIR",
"startAddress" : "192.0.2.0",
"endAddress" : "192.0.2.255",
"ipVersion" : "v4",
1726 "ldhName" : "xn--fo-5ja.example",
1727 "unicodeName" : "foo.example",
1728 "variants" :
1729 [
1730 {
1731 "relation" : [ "registered", "conjoined" ],
1732 "variantNames" :
1733 [
1734 {
1735 "ldhName" : "xn--fo-cka.example",
1736 "unicodeName" : "foo.example"
1737 },
1738 {
1739 "ldhName" : "xn--fo-fka.example",
1740 "unicodeName" : "foo.example"
1741 }
1742 ]
1743 },
1744 {
1745 "relation" : [ "unregistered", "registration restricted" ],
1746 "idnTable": ".EXAMPLE Swedish",
1747 "variantNames" :
1748 [
1749 {
1750 "ldhName": "xn--fo-8ja.example",
1751 "unicodeName" : "foo.example"
1752 }
1753 ]
1754
1755
1756
1757 Newton & Hollenbeck Standards Track [Page 32]
1758 RFC 7483 RDAP JSON Responses March 2015
1759
1760
1761 }
1762 ],
1763 "status" : [ "locked", "transfer prohibited" ],
1764 "publicIds":[
1765 {
1766 "type":"ENS_Auth ID",
1767 "identifier":"1234567890"
1768 }
1769 ],
1770 "nameservers" :
1771 [
1772 {
1773 "objectClassName" : "nameserver",
1774 "handle" : "XXXX",
1775 "ldhName" : "ns1.example.com",
1776 "status" : [ "active" ],
1777 "ipAddresses" :
1778 {
1779 "v6": [ "2001:db8::123", "2001:db8::124" ],
1780 "v4": [ "192.0.2.1", "192.0.2.2" ]
1781 },
1782 "remarks" :
1783 [
1784 {
1785 "description" :
1786 [
1787 "She sells sea shells down by the sea shore.",
1788 "Originally written by Terry Sullivan."
1789 ]
1790 }
1791 ],
1792 "links" :
1793 [
1794 {
1795 "value" : "http://example.net/nameserver/XXXX",
1796 "rel" : "self",
1797 "href" : "http://example.net/nameserver/XXXX",
1798 "type" : "application/rdap+json"
1799 }
1800 ],
1801 "events" :
1802 [
1803 {
1804 "eventAction" : "registration",
1805 "eventDate" : "1990-12-31T23:59:59Z"
1806 },
1807 {
1808 "eventAction" : "last changed",
1809
1810
1811
1812 Newton & Hollenbeck Standards Track [Page 33]
1813 RFC 7483 RDAP JSON Responses March 2015
1814
1815
1816 "eventDate" : "1991-12-31T23:59:59Z"
1817 }
1818 ]
1819 },
1820 {
1821 "objectClassName" : "nameserver",
1822 "handle" : "XXXX",
1823 "ldhName" : "ns2.example.com",
1824 "status" : [ "active" ],
1825 "ipAddresses" :
1826 {
1827 "v6" : [ "2001:db8::125", "2001:db8::126" ],
1828 "v4" : [ "192.0.2.3", "192.0.2.4" ]
1829 },
1830 "remarks" :
1831 [
1832 {
1833 "description" :
1834 [
1835 "She sells sea shells down by the sea shore.",
1836 "Originally written by Terry Sullivan."
1837 ]
1838 }
1839 ],
1840 "links" :
1841 [
1842 {
1843 "value" : "http://example.net/nameserver/XXXX",
1844 "rel" : "self",
1845 "href" : "http://example.net/nameserver/XXXX",
1846 "type" : "application/rdap+json"
1847 }
1848 ],
1849 "events" :
1850 [
1851 {
1852 "eventAction" : "registration",
1853 "eventDate" : "1990-12-31T23:59:59Z"
1854 },
1855 {
1856 "eventAction" : "last changed",
1857 "eventDate" : "1991-12-31T23:59:59Z"
1858 }
1859 ]
1860 }
1861 ],
1862 "secureDNS":
1863 {
1864
1865
1866
1867 Newton & Hollenbeck Standards Track [Page 34]
1868 RFC 7483 RDAP JSON Responses March 2015
1869
1870
1871 "zoneSigned": true,
1872 "delegationSigned": true,
1873 "maxSigLife": 604800,
1874 "keyData":
1875 [
1876 {
1877 "flags": 257,
1878 "protocol": 3,
1879 "algorithm": 1,
1880 "publicKey": "AQPJ////4Q==",
1881 "events":
1882 [
1883 {
1884 "eventAction": "last changed",
1885 "eventDate": "2012-07-23T05:15:47Z"
1886 }
1887 ]
1888 }
1889 ]
1890 },
1891 "remarks" :
1892 [
1893 {
1894 "description" :
1895 [
1896 "She sells sea shells down by the sea shore.",
1897 "Originally written by Terry Sullivan."
1898 ]
1899 }
1900 ],
1901 "links" :
1902 [
1903 {
1904 "value": "http://example.net/domain/XXXX",
1905 "rel" : "self",
1906 "href" : "http://example.net/domain/XXXX",
1907 "type" : "application/rdap+json"
1908 }
1909 ],
1910 "port43" : "whois.example.net",
1911 "events" :
1912 [
1913 {
1914 "eventAction" : "registration",
1915 "eventDate" : "1990-12-31T23:59:59Z"
1916 },
1917 {
1918 "eventAction" : "last changed",
1919
1920
1921
1922 Newton & Hollenbeck Standards Track [Page 35]
1923 RFC 7483 RDAP JSON Responses March 2015
1924
1925
1926 "eventDate" : "1991-12-31T23:59:59Z",
1927 "eventActor" : "joe@example.com"
1928 },
1929 {
1930 "eventAction" : "transfer",
1931 "eventDate" : "1991-12-31T23:59:59Z",
1932 "eventActor" : "joe@example.com"
1933 },
1934 {
1935 "eventAction" : "expiration",
1936 "eventDate" : "2016-12-31T23:59:59Z",
1937 "eventActor" : "joe@example.com"
1938 }
1939 ],
1940 "entities" :
1941 [
1942 {
1943 "objectClassName" : "entity",
1944 "handle" : "XXXX",
1945 "vcardArray":[
1946 "vcard",
1947 [
1948 ["version", {}, "text", "4.0"],
1949 ["fn", {}, "text", "Joe User"],
1950 ["kind", {}, "text", "individual"],
1951 ["lang", {
1952 "pref":"1"
1953 }, "language-tag", "fr"],
1954 ["lang", {
1955 "pref":"2"
1956 }, "language-tag", "en"],
1957 ["org", {
1958 "type":"work"
1959 }, "text", "Example"],
1960 ["title", {}, "text", "Research Scientist"],
1961 ["role", {}, "text", "Project Lead"],
1962 ["adr",
1963 { "type":"work" },
1964 "text",
1965 [
1966 "",
1967 "Suite 1234",
1968 "4321 Rue Somewhere",
1969 "Quebec",
1970 "QC",
1971 "G1V 2M2",
1972 "Canada"
1973 ]
1974
1975
1976
1977 Newton & Hollenbeck Standards Track [Page 36]
1978 RFC 7483 RDAP JSON Responses March 2015
1979
1980
1981 ],
1982 ["tel",
1983 { "type":["work", "voice"], "pref":"1" },
1984 "uri", "tel:+1-555-555-1234;ext=102"
1985 ],
1986 ["email",
1987 { "type":"work" },
1988 "text", "joe.user@example.com"
1989 ]
1990 ]
1991 ],
1992 "status" : [ "validated", "locked" ],
1993 "roles" : [ "registrant" ],
1994 "remarks" :
1995 [
1996 {
1997 "description" :
1998 [
1999 "She sells sea shells down by the sea shore.",
2000 "Originally written by Terry Sullivan."
2001 ]
2002 }
2003 ],
2004 "links" :
2005 [
2006 {
2007 "value" : "http://example.net/entity/xxxx",
2008 "rel" : "self",
2009 "href" : "http://example.net/entity/xxxx",
2010 "type" : "application/rdap+json"
2011 }
2012 ],
2013 "events" :
2014 [
2015 {
2016 "eventAction" : "registration",
2017 "eventDate" : "1990-12-31T23:59:59Z"
2018 },
2019 {
2020 "eventAction" : "last changed",
2021 "eventDate" : "1991-12-31T23:59:59Z"
2022 }
2023 ]
2024 }
2025 ]
2026 }
2027
2028 Figure 24
2029
2030
2031
2032 Newton & Hollenbeck Standards Track [Page 37]
2033 RFC 7483 RDAP JSON Responses March 2015
2034
2035
2036 5.4. The IP Network Object Class
2037
2038 The IP network object class models IP network registrations found in
2039 RIRs and is the expected response for the "/ip" query as defined by
2040 [RFC7482]. There is no equivalent object class for DNRs. The high-
2041 level structure of the IP network object class consists of
2042 information about the network registration and entities related to
2043 the IP network (e.g., registrant information, contacts, etc.).
2044
2045 The following is an elided example of the IP network object type
2046 showing the high-level structure:
2047
2048 {
2049 "objectClassName" : "ip network",
2050 "handle" : "XXX",
2051 ...
2052 "entities" :
2053 [
2054 ...
2055 ]
2056 }
2057
2058 Figure 25
2059
2060 The following is an example of the JSON object for the network
2061 registration information.
2062
2063 {
2064 "objectClassName" : "ip network",
2065 "handle" : "XXXX-RIR",
2066 "startAddress" : "2001:db8::",
2067 "endAddress" : "2001:db8:0:ffff:ffff:ffff:ffff:ffff",
2068 "ipVersion" : "v6",
2069 "name": "NET-RTR-1",
2070 "type" : "DIRECT ALLOCATION",
2071 "country" : "AU",
2072 "parentHandle" : "YYYY-RIR",
2073 "status" : [ "active" ],
2074 "remarks" :
2075 [
2076 {
2077 "description" :
2078 [
2079 "She sells sea shells down by the sea shore.",
2080 "Originally written by Terry Sullivan."
2081 ]
2082 }
2083 ],
2084
2085
2086
2087 Newton & Hollenbeck Standards Track [Page 38]
2088 RFC 7483 RDAP JSON Responses March 2015
2089
2090
2091 "links" :
2092 [
2093 {
2094 "value" : "http://example.net/ip/2001:db8::/48",
2095 "rel" : "self",
2096 "href" : "http://example.net/ip/2001:db8::/48",
2097 "type" : "application/rdap+json"
2098 },
2099 {
2100 "value" : "http://example.net/ip/2001:db8::/48",
2101 "rel" : "up",
2102 "href" : "http://example.net/ip/2001:C00::/23",
2103 "type" : "application/rdap+json"
2104 }
2105 ],
2106 "events" :
2107 [
2108 {
2109 "eventAction" : "registration",
2110 "eventDate" : "1990-12-31T23:59:59Z"
2111 },
2112 {
2113 "eventAction" : "last changed",
2114 "eventDate" : "1991-12-31T23:59:59Z"
2115 }
2116 ],
2117 "entities" :
2118 [
2119 {
2120 "objectClassName" : "entity",
2121 "handle" : "XXXX",
2122 "vcardArray":[
2123 "vcard",
2124 [
2125 ["version", {}, "text", "4.0"],
2126 ["fn", {}, "text", "Joe User"],
2127 ["kind", {}, "text", "individual"],
2128 ["lang", {
2129 "pref":"1"
2130 }, "language-tag", "fr"],
2131 ["lang", {
2132 "pref":"2"
2133 }, "language-tag", "en"],
2134 ["org", {
2135 "type":"work"
2136 }, "text", "Example"],
2137 ["title", {}, "text", "Research Scientist"],
2138 ["role", {}, "text", "Project Lead"],
2139
2140
2141
2142 Newton & Hollenbeck Standards Track [Page 39]
2143 RFC 7483 RDAP JSON Responses March 2015
2144
2145
2146 ["adr",
2147 { "type":"work" },
2148 "text",
2149 [
2150 "",
2151 "Suite 1234",
2152 "4321 Rue Somewhere",
2153 "Quebec",
2154 "QC",
2155 "G1V 2M2",
2156 "Canada"
2157 ]
2158 ],
2159 ["tel",
2160 { "type":["work", "voice"], "pref":"1" },
2161 "uri", "tel:+1-555-555-1234;ext=102"
2162 ],
2163 ["email",
2164 { "type":"work" },
2165 "text", "joe.user@example.com"
2166 ]
2167 ]
2168 ],
2169 "roles" : [ "registrant" ],
2170 "remarks" :
2171 [
2172 {
2173 "description" :
2174 [
2175 "She sells sea shells down by the sea shore.",
2176 "Originally written by Terry Sullivan."
2177 ]
2178 }
2179 ],
2180 "links" :
2181 [
2182 {
2183 "value" : "http://example.net/entity/xxxx",
2184 "rel" : "self",
2185 "href" : "http://example.net/entity/xxxx",
2186 "type" : "application/rdap+json"
2187 }
2188 ],
2189 "events" :
2190 [
2191 {
2192 "eventAction" : "registration",
2193 "eventDate" : "1990-12-31T23:59:59Z"
2194
2195
2196
2197 Newton & Hollenbeck Standards Track [Page 40]
2198 RFC 7483 RDAP JSON Responses March 2015
2199
2200
2201 },
2202 {
2203 "eventAction" : "last changed",
2204 "eventDate" : "1991-12-31T23:59:59Z"
2205 }
2206 ]
2207 }
2208 ]
2209 }
2210
2211 Figure 26
2212
2213 The IP network object class can contain the following members:
2214
2215 o objectClassName -- the string "ip network"
2216
2217 o handle -- a string representing an RIR-unique identifier of the
2218 network registration
2219
2220 o startAddress -- the starting IP address of the network, either
2221 IPv4 or IPv6
2222
2223 o endAddress -- the ending IP address of the network, either IPv4 or
2224 IPv6
2225
2226 o ipVersion -- a string signifying the IP protocol version of the
2227 network: "v4" signifies an IPv4 network, and "v6" signifies an
2228 IPv6 network
2229
2230 o name -- an identifier assigned to the network registration by the
2231 registration holder
2232
2233 o type -- a string containing an RIR-specific classification of the
2234 network
2235
2236 o country -- a string containing the two-character country code of
2237 the network
2238
2239 o parentHandle -- a string containing an RIR-unique identifier of
2240 the parent network of this network registration
2241
2242 o status -- an array of strings indicating the state of the IP
2243 network
2244
2245 o entities -- an array of entity objects as defined by Section 5.1
2246
2247 o remarks -- see Section 4.3
2248
2249
2250
2251
2252 Newton & Hollenbeck Standards Track [Page 41]
2253 RFC 7483 RDAP JSON Responses March 2015
2254
2255
2256 o links -- see Section 4.2
2257
2258 o port43 -- see Section 4.7
2259
2260 o events -- see Section 4.5
2261
"ldhName" : "xn--fo-5ja.example", "unicodeName" : "foo.example", "ldhName" : "xn--fo-cka.example", "unicodeName" : "foo.example" "ldhName" : "xn--fo-fka.example", "unicodeName" : "foo.example" "ldhName": "xn--fo-8ja.example", "unicodeName" : "foo.example"
"ldhName" : "xn--fo-5ja.example", "unicodeName" : "foóo.example", "ldhName" : "xn--fo-cka.example", "unicodeName" : "foõo.example" "ldhName" : "xn--fo-fka.example", "unicodeName" : "foöo.example" "ldhName" : "xn--fo-8ja.example", "unicodeName" : "foôo.example"
2262 5.5. Autonomous System Number Entity Object Class
2263
2264 The Autonomous System number (autnum) object class models Autonomous
2265 System number registrations found in RIRs and represents the expected
2266 response to an "/autnum" query as defined by [RFC7482]. There is no
2267 equivalent object class for DNRs. The high-level structure of the
2268 autnum object class consists of information about the network
2269 registration and entities related to the autnum registration (e.g.,
2270 registrant information, contacts, etc.) and is similar to the IP
2271 network entity object class.
2272
2273 The following is an example of a JSON object representing an autnum.
2274
2275 {
2276 "objectClassName" : "autnum",
2277 "handle" : "XXXX-RIR",
2278 "startAutnum" : 10,
2279 "endAutnum" : 15,
2280 "name": "AS-RTR-1",
2281 "type" : "DIRECT ALLOCATION",
2282 "status" : [ "active" ],
2283 "country": "AU",
2284 "remarks" :
2285 [
2286 {
2287 "description" :
2288 [
2289 "She sells sea shells down by the sea shore.",
2290 "Originally written by Terry Sullivan."
2291 ]
2292 }
2293 ],
2294 "links" :
2295 [
2296 {
2297 "value" : "http://example.net/autnum/xxxx",
2298 "rel" : "self",
2299 "href" : "http://example.net/autnum/xxxx",
2300 "type" : "application/rdap+json"
2301 }
2302 ],
2303 "events" :
2304
2305
2306
2307 Newton & Hollenbeck Standards Track [Page 42]
2308 RFC 7483 RDAP JSON Responses March 2015
2309
2310
2311 [
2312 {
2313 "eventAction" : "registration",
2314 "eventDate" : "1990-12-31T23:59:59Z"
2315 },
2316 {
2317 "eventAction" : "last changed",
2318 "eventDate" : "1991-12-31T23:59:59Z"
2319 }
2320 ],
2321 "entities" :
2322 [
2323 {
2324 "objectClassName" : "entity",
2325 "handle" : "XXXX",
2326 "vcardArray":[
2327 "vcard",
2328 [
2329 ["version", {}, "text", "4.0"],
2330 ["fn", {}, "text", "Joe User"],
2331 ["kind", {}, "text", "individual"],
2332 ["lang", {
2333 "pref":"1"
2334 }, "language-tag", "fr"],
2335 ["lang", {
2336 "pref":"2"
2337 }, "language-tag", "en"],
2338 ["org", {
2339 "type":"work"
2340 }, "text", "Example"],
2341 ["title", {}, "text", "Research Scientist"],
2342 ["role", {}, "text", "Project Lead"],
2343 ["adr",
2344 { "type":"work" },
2345 "text",
2346 [
2347 "",
2348 "Suite 1234",
2349 "4321 Rue Somewhere",
2350 "Quebec",
2351 "QC",
2352 "G1V 2M2",
2353 "Canada"
2354 ]
2355 ],
2356 ["tel",
2357 { "type":["work", "voice"], "pref":"1" },
2358 "uri", "tel:+1-555-555-1234;ext=102"
2359
2360
2361
2362 Newton & Hollenbeck Standards Track [Page 43]
2363 RFC 7483 RDAP JSON Responses March 2015
2364
2365
2366 ],
2367 ["email",
2368 { "type":"work" },
2369 "text", "joe.user@example.com"
2370 ]
2371 ]
2372 ],
2373 "roles" : [ "registrant" ],
2374 "remarks" :
2375 [
2376 {
2377 "description" :
2378 [
2379 "She sells sea shells down by the sea shore.",
2380 "Originally written by Terry Sullivan."
2381 ]
2382 }
2383 ],
2384 "links" :
2385 [
2386 {
2387 "value" : "http://example.net/entity/XXXX",
2388 "rel" : "self",
2389 "href" : "http://example.net/entity/XXXX",
2390 "type" : "application/rdap+json"
2391 }
2392 ],
2393 "events" :
2394 [
2395 {
2396 "eventAction" : "registration",
2397 "eventDate" : "1990-12-31T23:59:59Z"
2398 },
2399 {
2400 "eventAction" : "last changed",
2401 "eventDate" : "1991-12-31T23:59:59Z"
2402 }
2403 ]
2404 }
2405 ]
2406 }
2407
2408 Figure 27
2409
2410
2411
2412
2413
2414
2415
2416
2417 Newton & Hollenbeck Standards Track [Page 44]
2418 RFC 7483 RDAP JSON Responses March 2015
2419
2420
2421 The Autonomous System number object class can contain the following
2422 members:
2423
2424 o objectClassName -- the string "autnum"
2425
2426 o handle -- a string representing an RIR-unique identifier of the
2427 autnum registration
2428
2429 o startAutnum -- a number representing the starting number [RFC5396]
2430 in the block of Autonomous System numbers
2431
2432 o endAutnum -- a number representing the ending number [RFC5396] in
2433 the block of Autonomous System numbers
2434
2435 o name -- an identifier assigned to the autnum registration by the
2436 registration holder
2437
2438 o type -- a string containing an RIR-specific classification of the
2439 autnum
2440
2441 o status -- an array of strings indicating the state of the autnum
2442
2443 o country -- a string containing the name of the two-character
2444 country code of the autnum
2445
2446 o entities -- an array of entity objects as defined by Section 5.1
2447
2448 o remarks -- see Section 4.3
2449
2450 o links -- see Section 4.2
2451
2452 o port43 -- see Section 4.7
2453
2454 o events -- see Section 4.5
2455
2456 6. Error Response Body
2457
2458 Some non-answer responses may return entity bodies with information
2459 that could be more descriptive.
2460
2461 The basic structure of that response is an object class containing an
2462 error code number (corresponding to the HTTP response code) followed
2463 by a string named "title" and an array of strings named
2464 "description".
2465
2466
2467
2468
2469
2470
2471
2472 Newton & Hollenbeck Standards Track [Page 45]
2473 RFC 7483 RDAP JSON Responses March 2015
2474
2475
2476 This is an example of the common response body.
2477
2478 {
2479 "errorCode": 418,
2480 "title": "Your Beverage Choice is Not Available",
2481 "description":
2482 [
2483 "I know coffee has more ummppphhh.",
2484 "Sorry, dude!"
2485 ]
2486 }
2487
2488 Figure 28
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527 Newton & Hollenbeck Standards Track [Page 46]
2528 RFC 7483 RDAP JSON Responses March 2015
2529
2530
2531 This is an example of the common response body with an
2532 rdapConformance and notices data structures:
2533
2534 {
2535 "rdapConformance" :
2536 [
2537 "rdap_level_0"
2538 ],
2539 "notices" :
2540 [
2541 {
2542 "title" : "Beverage Policy",
2543 "description" :
2544 [
2545 "Beverages with caffeine for keeping horses awake."
2546 ],
2547 "links" :
2548 [
2549 {
2550 "value" : "http://example.net/ip/192.0.2.0/24",
2551 "rel" : "alternate",
2552 "type" : "text/html",
2553 "href" : "http://www.example.com/redaction_policy.html"
2554 }
2555 ]
2556 }
2557 ],
2558 "lang" : "en",
2559 "errorCode": 418,
2560 "title": "Your beverage choice is not available",
2561 "description":
2562 [
2563 "I know coffee has more ummppphhh.",
2564 "Sorry, dude!"
2565 ]
2566 }
2567
2568 Figure 29
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582 Newton & Hollenbeck Standards Track [Page 47]
2583 RFC 7483 RDAP JSON Responses March 2015
2584
2585
2586 7. Responding to Help Queries
2587
2588 The appropriate response to /help queries as defined by [RFC7482] is
2589 to use the notices structure as defined in Section 4.3.
2590
2591 This is an example of a response to a /help query including the
2592 rdapConformance data structure.
2593
2594 {
2595 "rdapConformance" :
2596 [
2597 "rdap_level_0"
2598 ],
2599 "notices" :
2600 [
2601 {
2602 "title" : "Authentication Policy",
2603 "description" :
2604 [
2605 "Access to sensitive data for users with proper credentials."
2606 ],
2607 "links" :
2608 [
2609 {
2610 "value" : "http://example.net/help",
2611 "rel" : "alternate",
2612 "type" : "text/html",
2613 "href" : "http://www.example.com/auth_policy.html"
2614 }
2615 ]
2616 }
2617 ]
2618 }
2619
2620 Figure 30
2621
2622 8. Responding To Searches
2623
2624 [RFC7482] specifies three types of searches: domains, nameservers,
2625 and entities. Responses to these searches take the form of an array
2626 of object instances where each instance is an appropriate object
2627 class for the search (i.e., a search for /domains yields an array of
2628 domain object instances). These arrays are contained within the
2629 response object.
2630
2631
2632
2633
2634
2635
2636
2637 Newton & Hollenbeck Standards Track [Page 48]
2638 RFC 7483 RDAP JSON Responses March 2015
2639
2640
2641 The names of the arrays are as follows:
2642
2643 o for /domains searches, the array is "domainSearchResults"
2644
2645 o for /nameservers searches, the array is "nameserverSearchResults"
2646
2647 o for /entities searches, the array is "entitySearchResults"
2648
2649 The following is an elided example of a response to a /domains
2650 search.
2651
2652 {
2653 "rdapConformance" :
2654 [
2655 "rdap_level_0"
2656 ],
2657 ...
2658 "domainSearchResults" :
2659 [
2660 {
2661 "objectClassName" : "domain",
2662 "handle" : "1-XXXX",
2663 "ldhName" : "1.example.com",
2664 ...
2665 },
2666 {
2667 "objectClassName" : "domain",
2668 "handle" : "2-XXXX",
2669 "ldhName" : "2.example.com",
2670 ...
2671 }
2672 ]
2673 }
2674
2675 Figure 31
2676
2677 9. Indicating Truncated Responses
2678
2679 In cases where the data of a response needs to be limited or parts of
2680 the data need to be omitted, the response is considered "truncated".
2681 A truncated response is still valid JSON, but some of the results in
2682 a search set or some of the data in an object are not provided by the
2683 server. A server may indicate this by including a typed notice in
2684 the response object.
2685
2686 The following is an elided example of a search response that has been
2687 truncated.
2688
2689
2690
2691
2692 Newton & Hollenbeck Standards Track [Page 49]
2693 RFC 7483 RDAP JSON Responses March 2015
2694
2695
2696 {
2697 "rdapConformance" :
2698 [
2699 "rdap_level_0"
2700 ],
2701 "notices" :
2702 [
2703 {
2704 "title" : "Search Policy",
2705 "type" : "result set truncated due to authorization",
2706 "description" :
2707 [
2708 "Search results are limited to 25 per day per querying IP."
2709 ],
2710 "links" :
2711 [
2712 {
2713 "value" : "http://example.net/help",
2714 "rel" : "alternate",
2715 "type" : "text/html",
2716 "href" : "http://www.example.com/search_policy.html"
2717 }
2718 ]
2719 }
2720 ],
2721 "domainSearchResults" :
2722 [
2723 ...
2724 ]
2725 }
2726
2727
2728 Figure 32
2729
2730 A similar technique can be used with a typed remark where a single
2731 object has been returned and data in that object has been truncated.
2732 Such an example might be an entity object with only a partial set of
2733 the IP networks associated with it.
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747 Newton & Hollenbeck Standards Track [Page 50]
2748 RFC 7483 RDAP JSON Responses March 2015
2749
2750
2751 The following is an elided example of an entity truncated data.
2752
2753 {
2754 "objectClassName" : "entity",
2755 "handle" : "ANENTITY",
2756 "roles" : [ "registrant" ],
2757 ...
2758 "entities" :
2759 [
2760 {
2761 "objectClassName" : "entity",
2762 "handle": "ANEMBEDDEDENTITY",
2763 "roles" : [ "technical" ],
2764 ...
2765 },
2766 ...
2767 ],
2768 "networks" :
2769 [
2770 ...
2771 ],
2772 ...
2773 "remarks" :
2774 [
2775 {
2776 "title" : "Data Policy",
2777 "type" : "object truncated due to unexplainable reason",
2778 "description" :
2779 [
2780 "Some of the data in this object has been removed."
2781 ],
2782 "links" :
2783 [
2784 {
2785 "value" : "http://example.net/help",
2786 "rel" : "alternate",
2787 "type" : "text/html",
2788 "href" : "http://www.example.com/data_policy.html"
2789 }
2790 ]
2791 }
2792 ]
2793 }
2794
2795
2796 Figure 33
2797
2798
2799
2800
2801
2802 Newton & Hollenbeck Standards Track [Page 51]
2803 RFC 7483 RDAP JSON Responses March 2015
2804
2805
2806 10. IANA Considerations
2807
2808 10.1. RDAP JSON Media Type Registration
2809
2810 This specification registers the "application/rdap+json" media type.
2811
2812 Type name: application
2813
2814 Subtype name: rdap+json
2815
2816 Required parameters: n/a
2817
2818 Encoding considerations: See Section 3.1 of [RFC6839].
2819
2820 Security considerations: The media represented by this identifier
2821 does not have security considerations beyond that found in
2822 Section 6 of [RFC7159].
2823
2824 Interoperability considerations: There are no known
2825 interoperability problems regarding this media format.
2826
2827 Published specification: RFC 7483
2828
2829 Applications that use this media type: Implementations of the
2830 Registration Data Access Protocol (RDAP).
2831
2832 Additional information: This media type is a product of the IETF
2833 WEIRDS working group. The WEIRDS charter, information on the
2834 WEIRDS mailing list, and other documents produced by the WEIRDS
2835 working group can be found at
2836 <https://datatracker.ietf.org/wg/weirds/>.
2837
2838 Person & email address to contact for further information: IESG
2839 <iesg@ietf.org>
2840
2841 Intended usage: COMMON
2842
2843 Restrictions on usage: none
2844
2845 Author: Andy Newton
2846
2847 Change controller: IETF
2848
2849 Provisional Registration: No (upon publication of this RFC)
2850
2851
2852
2853
2854
2855
2856
2857 Newton & Hollenbeck Standards Track [Page 52]
2858 RFC 7483 RDAP JSON Responses March 2015
2859
2860
2861 10.2. JSON Values Registry
2862
2863 IANA has created a category in the protocol registries labeled
2864 "Registration Data Access Protocol (RDAP)", and within that category,
2865 IANA has established a URL-referenceable, stand-alone registry
2866 labeled "RDAP JSON Values". This new registry is for use in the
2867 notices and remarks (Section 4.3), status (Section 4.6), role
2868 (Section 5.1), event action (Section 4.5), and domain variant
2869 relation (Section 5.3) fields specified in RDAP.
2870
2871 Each entry in the registry contains the following fields:
2872
2873 1. Value -- the string value being registered.
2874
2875 2. Type -- the type of value being registered. It should be one of
2876 the following:
2877
2878 * "notice or remark type" -- denotes a type of notice or remark.
2879
2880 * "status" -- denotes a value for the "status" object member as
2881 defined by Section 4.6.
2882
2883 * "role" -- denotes a value for the "role" array as defined in
2884 Section 5.1.
2885
2886 * "event action" -- denotes a value for an event action as
2887 defined in Section 4.5.
2888
2889 * "domain variant relation" -- denotes a relationship between a
2890 domain and a domain variant as defined in Section 5.3.
2891
2892 3. Description -- a one- or two-sentence description regarding the
2893 meaning of the value, how it might be used, and/or how it should
2894 be interpreted by clients.
2895
2896 4. Registrant Name -- the name of the person registering the value.
2897
2898 5. Registrant Contact Information -- an email address, postal
2899 address, or some other information to be used to contact the
2900 registrant.
2901
2902 This registry is operated under the "Expert Review" policy defined in
2903 [RFC5226].
2904
2905
2906
2907
2908
2909
2910
2911
2912 Newton & Hollenbeck Standards Track [Page 53]
2913 RFC 7483 RDAP JSON Responses March 2015
2914
2915
2916 Review of registrations into this registry by the designated
2917 expert(s) should be narrowly judged on the following criteria:
2918
2919 1. Values in need of being placed into multiple types must be
2920 assigned a separate registration for each type.
2921
2922 2. Values must be strings. They should be multiple words separated
2923 by single space characters. Every character should be
2924 lowercased. If possible, every word should be given in English
2925 and each character should be US-ASCII.
2926
2927 3. Registrations should not duplicate the meaning of any existing
2928 registration. That is, if a request for a registration is
2929 significantly similar in nature to an existing registration, the
2930 request should be denied. For example, the terms "maintainer"
2931 and "registrant" are significantly similar in nature as they both
2932 denote a holder of a domain name or Internet number resource. In
2933 cases where it may be reasonably argued that machine
2934 interpretation of two similar values may alter the operation of
2935 client software, designated experts should not judge the values
2936 to be of significant similarity.
2937
2938 4. Registrations should be relevant to the common usages of RDAP.
2939 Designated experts may rely upon the serving of the value by a
2940 DNR or RIR to make this determination.
2941
2942 The following sections provide initial registrations into this
2943 registry.
2944
2945 10.2.1. Notice and Remark Types
2946
2947 The following values have been registered in the "RDAP JSON Values"
2948 registry:
2949
2950 Value: result set truncated due to authorization
2951 Type: notice and remark type
2952 Description: The list of results does not contain all results due
2953 to lack of authorization. This may indicate to some clients
2954 that proper authorization will yield a longer result set.
2955 Registrant Name: IESG
2956 Registrant Contact Information: iesg@ietf.org
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967 Newton & Hollenbeck Standards Track [Page 54]
2968 RFC 7483 RDAP JSON Responses March 2015
2969
2970
2971 Value: result set truncated due to excessive load
2972 Type: notice and remark type
2973 Description: The list of results does not contain all results due
2974 to an excessively heavy load on the server. This may indicate
2975 to some clients that requerying at a later time will yield a
2976 longer result set.
2977 Registrant Name: IESG
2978 Registrant Contact Information: iesg@ietf.org
2979
2980
2981 Value: result set truncated due to unexplainable reasons
2982 Type: notice and remark type
2983 Description: The list of results does not contain all results for
2984 an unexplainable reason. This may indicate to some clients
2985 that requerying for any reason will not yield a longer result
2986 set.
2987 Registrant Name: IESG
2988 Registrant Contact Information: iesg@ietf.org
2989
2990
2991 Value: object truncated due to authorization
2992 Type: notice and remark type
2993 Description: The object does not contain all data due to lack of
2994 authorization.
2995 Registrant Name: IESG
2996 Registrant Contact Information: iesg@ietf.org
2997
2998
2999 Value: object truncated due to excessive load
3000 Type: notice and remark type
3001 Description: The object does not contain all data due to an
3002 excessively heavy load on the server. This may indicate to
3003 some clients that requerying at a later time will yield all
3004 data of the object.
3005 Registrant Name: IESG
3006 Registrant Contact Information: iesg@ietf.org
3007
3008
3009 Value: object truncated due to unexplainable reasons
3010 Type: notice and remark type
3011 Description: The object does not contain all data for an
3012 unexplainable reason.
3013 Registrant Name: IESG
3014 Registrant Contact Information: iesg@ietf.org
3015
3016
3017
3018
3019
3020
3021
3022 Newton & Hollenbeck Standards Track [Page 55]
3023 RFC 7483 RDAP JSON Responses March 2015
3024
3025
3026 10.2.2. Status
3027
3028 The following values have been registered in the "RDAP JSON Values"
3029 registry:
3030
3031 Value: validated
3032 Type: status
3033 Description: Signifies that the data of the object instance has
3034 been found to be accurate. This type of status is usually
3035 found on entity object instances to note the validity of
3036 identifying contact information.
3037 Registrant Name: IESG
3038 Registrant Contact Information: iesg@ietf.org
3039
3040
3041 Value: renew prohibited
3042 Type: status
3043 Description: Renewal or reregistration of the object instance is
3044 forbidden.
3045 Registrant Name: IESG
3046 Registrant Contact Information: iesg@ietf.org
3047
3048
3049 Value: update prohibited
3050 Type: status
3051 Description: Updates to the object instance are forbidden.
3052 Registrant Name: IESG
3053 Registrant Contact Information: iesg@ietf.org
3054
3055
3056 Value: transfer prohibited
3057 Type: status
3058 Description: Transfers of the registration from one registrar to
3059 another are forbidden. This type of status normally applies to
3060 DNR domain names.
3061 Registrant Name: IESG
3062 Registrant Contact Information: iesg@ietf.org
3063
3064
3065 Value: delete prohibited
3066 Type: status
3067 Description: Deletion of the registration of the object instance
3068 is forbidden. This type of status normally applies to DNR
3069 domain names.
3070 Registrant Name: IESG
3071 Registrant Contact Information: iesg@ietf.org
3072
3073
3074
3075
3076
3077 Newton & Hollenbeck Standards Track [Page 56]
3078 RFC 7483 RDAP JSON Responses March 2015
3079
3080
3081 Value: proxy
3082 Type: status
3083 Description: The registration of the object instance has been
3084 performed by a third party. This is most commonly applied to
3085 entities.
3086 Registrant Name: IESG
3087 Registrant Contact Information: iesg@ietf.org
3088
3089
3090 Value: private
3091 Type: status
3092 Description: The information of the object instance is not
3093 designated for public consumption. This is most commonly
3094 applied to entities.
3095 Registrant Name: IESG
3096 Registrant Contact Information: iesg@ietf.org
3097
3098
3099 Value: removed
3100 Type: status
3101 Description: Some of the information of the object instance has
3102 not been made available and has been removed. This is most
3103 commonly applied to entities.
3104 Registrant Name: IESG
3105 Registrant Contact Information: iesg@ietf.org
3106
3107
3108 Value: obscured
3109 Type: status
3110 Description: Some of the information of the object instance has
3111 been altered for the purposes of not readily revealing the
3112 actual information of the object instance. This is most
3113 commonly applied to entities.
3114 Registrant Name: IESG
3115 Registrant Contact Information: iesg@ietf.org
3116
3117
3118 Value: associated
3119 Type: status
3120 Description: The object instance is associated with other object
3121 instances in the registry. This is most commonly used to
3122 signify that a nameserver is associated with a domain or that
3123 an entity is associated with a network resource or domain.
3124 Registrant Name: IESG
3125 Registrant Contact Information: iesg@ietf.org
3126
3127
3128
3129
3130
3131
3132 Newton & Hollenbeck Standards Track [Page 57]
3133 RFC 7483 RDAP JSON Responses March 2015
3134
3135
3136 Value: active
3137 Type: status
3138 Description: The object instance is in use. For domain names, it
3139 signifies that the domain name is published in DNS. For
3140 network and autnum registrations, it signifies that they are
3141 allocated or assigned for use in operational networks. This
3142 maps to the "OK" status of the Extensible Provisioning Protocol
3143 (EPP) [RFC5730] .
3144 Registrant Name: IESG
3145 Registrant Contact Information: iesg@ietf.org
3146
3147
3148 Value: inactive
3149 Type: status
3150 Description: The object instance is not in use. See "active".
3151 Registrant Name: IESG
3152 Registrant Contact Information: iesg@ietf.org
3153
3154
3155 Value: locked
3156 Type: status
3157 Description: Changes to the object instance cannot be made,
3158 including the association of other object instances.
3159 Registrant Name: IESG
3160 Registrant Contact Information: iesg@ietf.org
3161
3162
3163 Value: pending create
3164 Type: status
3165 Description: A request has been received for the creation of the
3166 object instance, but this action is not yet complete.
3167 Registrant Name: IESG
3168 Registrant Contact Information: iesg@ietf.org
3169
3170
3171 Value: pending renew
3172 Type: status
3173 Description: A request has been received for the renewal of the
3174 object instance, but this action is not yet complete.
3175 Registrant Name: IESG
3176 Registrant Contact Information: iesg@ietf.org
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187 Newton & Hollenbeck Standards Track [Page 58]
3188 RFC 7483 RDAP JSON Responses March 2015
3189
3190
3191 Value: pending transfer
3192 Type: status
3193 Description: A request has been received for the transfer of the
3194 object instance, but this action is not yet complete.
3195 Registrant Name: IESG
3196 Registrant Contact Information: iesg@ietf.org
3197
3198
3199 Value: pending update
3200 Type: status
3201 Description: A request has been received for the update or
3202 modification of the object instance, but this action is not yet
3203 complete.
3204 Registrant Name: IESG
3205 Registrant Contact Information: iesg@ietf.org
3206
3207
3208 Value: pending delete
3209 Type: status
3210 Description: A request has been received for the deletion or
3211 removal of the object instance, but this action is not yet
3212 complete. For domains, this might mean that the name is no
3213 longer published in DNS but has not yet been purged from the
3214 registry database.
3215 Registrant Name: IESG
3216 Registrant Contact Information: iesg@ietf.org
3217
country -- a string containing the name of the two-character country code of the autnum
country -- a string containing the two-character country code of the autnum
As described in Section 3, country codes should consistently be represented as two-character string values. Note that this differs from the "full name" format used in jCard representations of entity objects.
3218 10.2.3. Event Actions
3219
3220 The following values have been registered in the "RDAP JSON Values"
3221 registry:
3222
3223 Value: registration
3224 Type: event action
3225 Description: The object instance was initially registered.
3226 Registrant Name: IESG
3227 Registrant Contact Information: iesg@ietf.org
3228
3229
3230 Value: reregistration
3231 Type: event action
3232 Description: The object instance was registered subsequently to
3233 initial registration.
3234 Registrant Name: IESG
3235 Registrant Contact Information: iesg@ietf.org
3236
3237
3238
3239
3240
3241
3242 Newton & Hollenbeck Standards Track [Page 59]
3243 RFC 7483 RDAP JSON Responses March 2015
3244
3245
3246 Value: last changed
3247 Type: event action
3248 Description: An action noting when the information in the object
3249 instance was last changed.
3250 Registrant Name: IESG
3251 Registrant Contact Information: iesg@ietf.org
3252
3253
3254 Value: expiration
3255 Type: event action
3256 Description: The object instance has been removed or will be
3257 removed at a predetermined date and time from the registry.
3258 Registrant Name: IESG
3259 Registrant Contact Information: iesg@ietf.org
3260
3261
3262 Value: deletion
3263 Type: event action
3264 Description: The object instance was removed from the registry at
3265 a point in time that was not predetermined.
3266 Registrant Name: IESG
3267 Registrant Contact Information: iesg@ietf.org
3268
3269
3270 Value: reinstantiation
3271 Type: event action
3272 Description: The object instance was reregistered after having
3273 been removed from the registry.
3274 Registrant Name: IESG
3275 Registrant Contact Information: iesg@ietf.org
3276
3277
3278 Value: transfer
3279 Type: event action
3280 Description: The object instance was transferred from one
3281 registrant to another.
3282 Registrant Name: IESG
3283 Registrant Contact Information: iesg@ietf.org
3284
3285
3286 Value: locked
3287 Type: event action
3288 Description: The object instance was locked (see the "locked"
3289 status).
3290 Registrant Name: IESG
3291 Registrant Contact Information: iesg@ietf.org
3292
3293
3294
3295
3296
3297 Newton & Hollenbeck Standards Track [Page 60]
3298 RFC 7483 RDAP JSON Responses March 2015
3299
3300
3301 Value: unlocked
3302 Type: event action
3303 Description: The object instance was unlocked (see the "locked"
3304 status).
3305 Registrant Name: IESG
3306 Registrant Contact Information: iesg@ietf.org
3307
3308 10.2.4. Roles
3309
3310 The following values have been registered in the "RDAP JSON Values"
3311 registry:
3312
3313 Value: registrant
3314 Type: role
3315 Description: The entity object instance is the registrant of the
3316 registration. In some registries, this is known as a
3317 maintainer.
3318 Registrant Name: IESG
3319 Registrant Contact Information: iesg@ietf.org
3320
3321
3322 Value: technical
3323 Type: role
3324 Description: The entity object instance is a technical contact for
3325 the registration.
3326 Registrant Name: IESG
3327 Registrant Contact Information: iesg@ietf.org
3328
3329
3330 Value: administrative
3331 Type: role
3332 Description: The entity object instance is an administrative
3333 contact for the registration.
3334 Registrant Name: IESG
3335 Registrant Contact Information: iesg@ietf.org
3336
3337
3338 Value: abuse
3339 Type: role
3340 Description: The entity object instance handles network abuse
3341 issues on behalf of the registrant of the registration.
3342 Registrant Name: IESG
3343 Registrant Contact Information: iesg@ietf.org
3344
3345
3346
3347
3348
3349
3350
3351
3352 Newton & Hollenbeck Standards Track [Page 61]
3353 RFC 7483 RDAP JSON Responses March 2015
3354
3355
3356 Value: billing
3357 Type: role
3358 Description: The entity object instance handles payment and
3359 billing issues on behalf of the registrant of the registration.
3360 Registrant Name: IESG
3361 Registrant Contact Information: iesg@ietf.org
3362
3363
3364 Value: registrar
3365 Type: role
3366 Description: The entity object instance represents the authority
3367 responsible for the registration in the registry.
3368 Registrant Name: IESG
3369 Registrant Contact Information: iesg@ietf.org
3370
3371
3372 Value: reseller
3373 Type: role
3374 Description: The entity object instance represents a third party
3375 through which the registration was conducted (i.e., not the
3376 registry or registrar).
3377 Registrant Name: IESG
3378 Registrant Contact Information: iesg@ietf.org
3379
3380
3381 Value: sponsor
3382 Type: role
3383 Description: The entity object instance represents a domain policy
3384 sponsor, such as an ICANN-approved sponsor.
3385 Registrant Name: IESG
3386 Registrant Contact Information: iesg@ietf.org
3387
3388
3389 Value: proxy
3390 Type: role
3391 Description: The entity object instance represents a proxy for
3392 another entity object, such as a registrant.
3393 Registrant Name: IESG
3394 Registrant Contact Information: iesg@ietf.org
3395
3396
3397 Value: notifications
3398 Type: role
3399 Description: An entity object instance designated to receive
3400 notifications about association object instances.
3401 Registrant Name: IESG
3402 Registrant Contact Information: iesg@ietf.org
3403
3404
3405
3406
3407 Newton & Hollenbeck Standards Track [Page 62]
3408 RFC 7483 RDAP JSON Responses March 2015
3409
3410
3411 Value: noc
3412 Type: role
3413 Description: The entity object instance handles communications
3414 related to a network operations center (NOC).
3415 Registrant Name: IESG
3416 Registrant Contact Information: iesg@ietf.org
3417
3418 10.2.5. Variant Relations
3419
3420 The following values have been registered in the "RDAP JSON Values"
3421 registry:
3422
3423 Value: registered
3424 Type: domain variant relation
3425 Description: The variant names are registered in the registry.
3426 Registrant Name: IESG
3427 Registrant Contact Information: iesg@ietf.org
3428
3429
3430 Value: unregistered
3431 Type: domain variant relation
3432 Description: The variant names are not found in the registry.
3433 Registrant Name: IESG
3434 Registrant Contact Information: iesg@ietf.org
3435
3436
3437 Value: registration restricted
3438 Type: domain variant relation
3439 Description: Registration of the variant names is restricted to
3440 certain parties or within certain rules.
3441 Registrant Name: IESG
3442 Registrant Contact Information: iesg@ietf.org
3443
3444
3445 Value: open registration
3446 Type: domain variant relation
3447 Description: Registration of the variant names is available to
3448 generally qualified registrants.
3449 Registrant Name: IESG
3450 Registrant Contact Information: iesg@ietf.org
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462 Newton & Hollenbeck Standards Track [Page 63]
3463 RFC 7483 RDAP JSON Responses March 2015
3464
3465
3466 Value: conjoined
3467 Type: domain variant relation
3468 Description: Registration of the variant names occurs
3469 automatically with the registration of the containing domain
3470 registration.
3471 Registrant Name: IESG
3472 Registrant Contact Information: iesg@ietf.org
3473
3474 11. Security Considerations
3475
3476 This specification models information serialized in JSON format. As
3477 JSON is a subset of JavaScript, implementations are advised to follow
3478 the security considerations outlined in Section 6 of [RFC7159] to
3479 prevent code injection.
3480
3481 Though not specific to JSON, RDAP implementers should be aware of the
3482 security considerations specified in [RFC7480] and the security
3483 requirements and considerations in [RFC7481].
3484
3485 Clients caching data, especially clients using RDAP-specific caches
3486 (instead of HTTP-layer caches), should have safeguards to prevent
3487 cache poisoning. See Section 5 for advice on using the self links
3488 for caching.
3489
3490 Finally, service operators should be aware of the privacy mechanisms
3491 noted in Section 13.
3492
3493 12. Internationalization Considerations
3494
3495 12.1. Character Encoding
3496
3497 The default text encoding for JSON responses in RDAP is UTF-8
3498 [RFC3629], and all servers and clients MUST support UTF-8.
3499
3500 12.2. URIs and IRIs
3501
3502 [RFC7480] defines the use of URIs and IRIs in RDAP.
3503
3504 12.3. Language Tags
3505
3506 Section 4.4 defines the use of language tags in the JSON responses
3507 defined in this document.
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517 Newton & Hollenbeck Standards Track [Page 64]
3518 RFC 7483 RDAP JSON Responses March 2015
3519
3520
3521 12.4. Internationalized Domain Names
3522
3523 IDNs are denoted in this specification by the separation of DNS names
3524 in LDH form and Unicode form (see Section 3). Representation of IDNs
3525 in registries is described by the "variants" object in Section 5.3
3526 and the suggested values listed in Section 10.2.5.
3527
3528 13. Privacy Considerations
3529
3530 This specification suggests status values to denote contact and
3531 registrant information that has been marked as private and/or has
3532 been removed or obscured. See Section 10.2.2 for the complete list
3533 of status values. A few of the status values indicate that there are
3534 privacy concerns associated with the object instance. The following
3535 status codes SHOULD be used to describe data elements of a response
3536 when appropriate:
3537
3538 private -- The object is not be shared in query responses, unless
3539 the user is authorized to view this information.
3540
3541 removed -- Data elements within the object have been collected but
3542 have been omitted from the response. This option can be used to
3543 prevent unauthorized access to associated object instances without
3544 the need to mark them as private.
3545
3546 obscured -- Data elements within the object have been collected,
3547 but the response value has been altered so that values are not
3548 easily discernible. A value changed from "1212" to "XXXX" is an
3549 example of obscured data. This option may reveal privacy
3550 sensitive information and should only be used when data
3551 sensitivity does not require a more protective option like
3552 "private" or "removed".
3553
3554 See Appendix A.1 for an example of applying those values to contacts
3555 and registrants.
3556
3557 14. References
3558
3559 14.1. Normative References
3560
3561 [ISO.3166.1988]
3562 International Organization for Standardization, "Codes for
3563 the representation of names of countries, 3rd edition",
3564 ISO Standard 3166, August 1988.
3565
3566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3567 Requirement Levels", BCP 14, RFC 2119, March 1997,
3568 <http://www.rfc-editor.org/info/rfc2119>.
3569
3570
3571
3572 Newton & Hollenbeck Standards Track [Page 65]
3573 RFC 7483 RDAP JSON Responses March 2015
3574
3575
3576 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
3577 Internet: Timestamps", RFC 3339, July 2002,
3578 <http://www.rfc-editor.org/info/rfc3339>.
3579
3580 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
3581 10646", STD 63, RFC 3629, November 2003,
3582 <http://www.rfc-editor.org/info/rfc3629>.
3583
3584 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3585 Resource Identifier (URI): Generic Syntax", STD 66, RFC
3586 3986, January 2005,
3587 <http://www.rfc-editor.org/info/rfc3986>.
3588
3589 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3590 Rose, "Resource Records for the DNS Security Extensions",
3591 RFC 4034, March 2005,
3592 <http://www.rfc-editor.org/info/rfc4034>.
3593
3594 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
3595 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3596 May 2008, <http://www.rfc-editor.org/info/rfc5226>.
3597
3598 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
3599 Autonomous System (AS) Numbers", RFC 5396, December 2008,
3600 <http://www.rfc-editor.org/info/rfc5396>.
3601
3602 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
3603 Languages", BCP 47, RFC 5646, September 2009,
3604 <http://www.rfc-editor.org/info/rfc5646>.
3605
3606 [RFC5890] Klensin, J., "Internationalized Domain Names for
3607 Applications (IDNA): Definitions and Document Framework",
3608 RFC 5890, August 2010,
3609 <http://www.rfc-editor.org/info/rfc5890>.
3610
3611 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
3612 Address Text Representation", RFC 5952, August 2010,
3613 <http://www.rfc-editor.org/info/rfc5952>.
3614
3615 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010,
3616 <http://www.rfc-editor.org/info/rfc5988>.
3617
3618 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
3619 January 2014, <http://www.rfc-editor.org/info/rfc7095>.
3620
3621 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
3622 Interchange Format", RFC 7159, March 2014,
3623 <http://www.rfc-editor.org/info/rfc7159>.
3624
3625
3626
3627 Newton & Hollenbeck Standards Track [Page 66]
3628 RFC 7483 RDAP JSON Responses March 2015
3629
3630
3631 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
3632 Registration Data Access Protocol (RDAP)", RFC 7480, March
3633 2015, <http://www.rfc-editor.org/info/rfc7480>.
3634
3635 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
3636 Registration Data Access Protocol (RDAP)", RFC 7481, March
3637 2015, <http://www.rfc-editor.org/info/rfc7481>.
3638
3639 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
3640 Protocol (RDAP) Query Format", RFC 7482, March 2015,
3641 <http://www.rfc-editor.org/info/rfc7482>.
3642
3643 14.2. Informative References
3644
3645 [IANA_IDNTABLES]
3646 IANA, "Repository of IDN Practices",
3647 <http://www.iana.org/domains/idn-tables>.
3648
3649 [JSON_ascendancy]
3650 MacVittie, L., "The Stealthy Ascendancy of JSON", April
3651 2011, <https://devcentral.f5.com/weblogs/macvittie/
3652 archive/2011/04/27/the-stealthy-ascendancy-of-json.aspx>.
3653
3654 [JSON_performance_study]
3655 Nurseitov, N., Paulson, M., Reynolds, R., and C. Izurieta,
3656 "Comparison of JSON and XML Data Interchange Formats: A
3657 Case Study", 2009,
3658 <http://www.cs.montana.edu/izurieta/pubs/caine2009.pdf>.
3659
3660 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
3661 September 2004, <http://www.rfc-editor.org/info/rfc3912>.
3662
3663 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
3664 STD 69, RFC 5730, August 2009,
3665 <http://www.rfc-editor.org/info/rfc5730>.
3666
3667 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
3668 Security Extensions Mapping for the Extensible
3669 Provisioning Protocol (EPP)", RFC 5910, May 2010,
3670 <http://www.rfc-editor.org/info/rfc5910>.
3671
3672 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
3673 August 2011, <http://www.rfc-editor.org/info/rfc6350>.
3674
3675 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
3676 Structured Syntax Suffixes", RFC 6839, January 2013,
3677 <http://www.rfc-editor.org/info/rfc6839>.
3678
3679
3680
3681
3682 Newton & Hollenbeck Standards Track [Page 67]
3683 RFC 7483 RDAP JSON Responses March 2015
3684
3685
3686 Appendix A. Suggested Data Modeling with the Entity Object Class
3687
3688 A.1. Registrants and Contacts
3689
3690 This document does not provide specific object classes for
3691 registrants and contacts. Instead, the entity object class may be
3692 used to represent a registrant or contact. When the entity object is
3693 embedded inside a containing object such as a domain name or IP
3694 network, the "roles" string array can be used to signify the
3695 relationship. It is recommended that the values from Section 10.2.4
3696 be used.
3697
3698 The following is an example of an elided containing object with an
3699 embedded entity that is both a registrant and administrative contact:
3700
3701 {
3702 ...
3703 "entities" :
3704 [
3705 {
3706 "objectClassName" : "entity",
3707 "handle" : "XXXX",
3708 "vcardArray":[
3709 "vcard",
3710 [
3711 ["version", {}, "text", "4.0"],
3712 ["fn", {}, "text", "Joe User"],
3713 ["kind", {}, "text", "individual"],
3714 ["lang", {
3715 "pref":"1"
3716 }, "language-tag", "fr"],
3717 ["lang", {
3718 "pref":"2"
3719 }, "language-tag", "en"],
3720 ["org", {
3721 "type":"work"
3722 }, "text", "Example"],
3723 ["title", {}, "text", "Research Scientist"],
3724 ["role", {}, "text", "Project Lead"],
3725 ["adr",
3726 { "type":"work" },
3727 "text",
3728 [
3729 "",
3730 "Suite 1234",
3731 "4321 Rue Somewhere",
3732 "Quebec",
3733 "QC",
3734
3735
3736
3737 Newton & Hollenbeck Standards Track [Page 68]
3738 RFC 7483 RDAP JSON Responses March 2015
3739
3740
3741 "G1V 2M2",
3742 "Canada"
3743 ]
3744 ],
3745 ["tel",
3746 { "type":["work", "voice"], "pref":"1" },
3747 "uri", "tel:+1-555-555-1234;ext=102"
3748 ],
3749 ["email",
3750 { "type":"work" },
3751 "text", "joe.user@example.com"
3752 ]
3753 ]
3754 ],
3755 "roles" : [ "registrant", "administrative" ],
3756 "remarks" :
3757 [
3758 {
3759 "description" :
3760 [
3761 "She sells sea shells down by the sea shore.",
3762 "Originally written by Terry Sullivan."
3763 ]
3764 }
3765 ],
3766 "events" :
3767 [
3768 {
3769 "eventAction" : "registration",
3770 "eventDate" : "1990-12-31T23:59:59Z"
3771 },
3772 {
3773 "eventAction" : "last changed",
3774 "eventDate" : "1991-12-31T23:59:59Z"
3775 }
3776 ]
3777 }
3778 ]
3779 }
3780
3781 Figure 34
3782
3783 In many use cases, it is necessary to hide or obscure the information
3784 of a registrant or contact due to policy or other operational
3785 matters. Registries can denote these situations with "status" values
3786 (see Section 10.2.2).
3787
3788
3789
3790
3791
3792 Newton & Hollenbeck Standards Track [Page 69]
3793 RFC 7483 RDAP JSON Responses March 2015
3794
3795
3796 The following is an elided example of a registrant with information
3797 changed to reflect that of a third party.
3798
3799 {
3800 ...
3801 "entities" :
3802 [
3803 {
3804 "objectClassName" : "entity",
3805 "handle" : "XXXX",
3806 ...
3807 "roles" : [ "registrant", "administrative" ],
3808 "status" : [ "proxy", "private", "obscured" ]
3809 }
3810 ]
3811 }
3812
3813 Figure 35
3814
3815 A.2. Registrars
3816
3817 This document does not provide a specific object class for
3818 registrars, but like registrants and contacts (see Appendix A.1), the
3819 "roles" string array maybe used. Additionally, many registrars have
3820 publicly assigned identifiers. The publicIds structure (Section 4.8)
3821 represents that information.
3822
3823 The following is an example of an elided containing object with an
3824 embedded entity that is a registrar:
3825
3826 {
3827 ...
3828 "entities":[
3829 {
3830 "objectClassName" : "entity",
3831 "handle":"XXXX",
3832 "vcardArray":[
3833 "vcard",
3834 [
3835 ["version", {}, "text", "4.0"],
3836 ["fn", {}, "text", "Joe's Fish, Chips, and Domains"],
3837 ["kind", {}, "text", "org"],
3838 ["lang", {
3839 "pref":"1"
3840 }, "language-tag", "fr"],
3841 ["lang", {
3842 "pref":"2"
3843 }, "language-tag", "en"],
3844
3845
3846
3847 Newton & Hollenbeck Standards Track [Page 70]
3848 RFC 7483 RDAP JSON Responses March 2015
3849
3850
3851 ["org", {
3852 "type":"work"
3853 }, "text", "Example"],
3854 ["adr",
3855 { "type":"work" },
3856 "text",
3857 [
3858 "",
3859 "Suite 1234",
3860 "4321 Rue Somewhere",
3861 "Quebec",
3862 "QC",
3863 "G1V 2M2",
3864 "Canada"
3865 ]
3866 ],
3867 ["tel",
3868 {
3869 "type":["work", "voice"],
3870 "pref":"1"
3871 },
3872 "uri", "tel:+1-555-555-1234;ext=102"
3873 ],
3874 ["email",
3875 { "type":"work" },
3876 "text", "joes_fish_chips_and_domains@example.com"
3877 ]
3878 ]
3879 ],
3880 "roles":[ "registrar" ],
3881 "publicIds":[
3882 {
3883 "type":"IANA Registrar ID",
3884 "identifier":"1"
3885 }
3886 ],
3887 "remarks":[
3888 {
3889 "description":[
3890 "She sells sea shells down by the sea shore.",
3891 "Originally written by Terry Sullivan."
3892 ]
3893 }
3894 ],
3895 "links":[
3896 {
3897 "value":"http://example.net/entity/XXXX",
3898 "rel":"alternate",
3899
3900
3901
3902 Newton & Hollenbeck Standards Track [Page 71]
3903 RFC 7483 RDAP JSON Responses March 2015
3904
3905
3906 "type":"text/html",
3907 "href":"http://www.example.com"
3908 }
3909 ]
3910 }
3911 ]
3912 }
3913
3914 Figure 36
3915
3916 Appendix B. Modeling Events
3917
3918 Events represent actions that have taken place against a registered
3919 object at a certain date and time. Events have three properties: the
3920 action, the actor, and the date and time of the event (which is
3921 sometimes in the future). In some cases, the identity of the actor
3922 is not captured.
3923
3924 Events can be modeled in three ways:
3925
3926 1. events with no designated actor
3927
3928 2. events where the actor is only designated by an identifier
3929
3930 3. events where the actor can be modeled as an entity
3931
3932 For the first use case, the events data structure (Section 4.5) is
3933 used without the "eventActor" object member.
3934
3935 This is an example of an "events" array without the "eventActor".
3936
3937 "events" :
3938 [
3939 {
3940 "eventAction" : "registration",
3941 "eventDate" : "1990-12-31T23:59:59Z"
3942 }
3943 ]
3944
3945 Figure 37
3946
3947 For the second use case, the events data structure (Section 4.5) is
3948 used with the "eventActor" object member.
3949
3950
3951
3952
3953
3954
3955
3956
3957 Newton & Hollenbeck Standards Track [Page 72]
3958 RFC 7483 RDAP JSON Responses March 2015
3959
3960
3961 This is an example of an "events" array with the "eventActor".
3962
3963 "events" :
3964 [
3965 {
3966 "eventAction" : "registration",
3967 "eventActor" : "XYZ-NIC",
3968 "eventDate" : "1990-12-31T23:59:59Z"
3969 }
3970 ]
3971
3972 Figure 38
3973
3974 For the third use case, the "asEventActor" array is used when an
3975 entity (Section 5.1) is embedded into another object class. The
3976 "asEventActor" array follows the same structure as the "events" array
3977 but does not have "eventActor" attributes.
3978
3979 The following is an elided example of a domain object with an entity
3980 as an event actor.
3981
3982 {
3983 "objectClassName" : "domain",
3984 "handle" : "XXXX",
3985 "ldhName" : "foo.example",
3986 "status" : [ "locked", "transfer prohibited" ],
3987 ...
3988 "entities" :
3989 [
3990 {
3991 "handle" : "XXXX",
3992 ...
3993 "asEventActor" :
3994 [
3995 {
3996 "eventAction" : "last changed",
3997 "eventDate" : "1990-12-31T23:59:59Z"
3998 }
3999 ]
4000 }
4001 ]
4002 }
4003
4004 Figure 39
4005
4006
4007
4008
4009
4010
4011
4012 Newton & Hollenbeck Standards Track [Page 73]
4013 RFC 7483 RDAP JSON Responses March 2015
4014
4015
4016 Appendix C. Structured vs. Unstructured Addresses
4017
4018 The entity (Section 5.1) object class uses jCard [RFC7095] to
4019 represent contact information, including postal addresses. jCard has
4020 the ability to represent multiple language preferences, multiple
4021 email address and phone numbers, and multiple postal addresses in
4022 both a structured and unstructured format. This section describes
4023 the use of jCard for representing structured and unstructured
4024 addresses.
4025
4026 The following is an example of a jCard.
4027
4028 {
4029 "vcardArray":[
4030 "vcard",
4031 [
4032 ["version", {}, "text", "4.0"],
4033 ["fn", {}, "text", "Joe User"],
4034 ["n", {}, "text",
4035 ["User", "Joe", "", "", ["ing. jr", "M.Sc."]]
4036 ],
4037 ["kind", {}, "text", "individual"],
4038 ["lang", {
4039 "pref":"1"
4040 }, "language-tag", "fr"],
4041 ["lang", {
4042 "pref":"2"
4043 }, "language-tag", "en"],
4044 ["org", {
4045 "type":"work"
4046 }, "text", "Example"],
4047 ["title", {}, "text", "Research Scientist"],
4048 ["role", {}, "text", "Project Lead"],
4049 ["adr",
4050 { "type":"work" },
4051 "text",
4052 [
4053 "",
4054 "Suite 1234",
4055 "4321 Rue Somewhere",
4056 "Quebec",
4057 "QC",
4058 "G1V 2M2",
4059 "Canada"
4060 ]
4061 ],
4062 ["adr",
4063 {
4064
4065
4066
4067 Newton & Hollenbeck Standards Track [Page 74]
4068 RFC 7483 RDAP JSON Responses March 2015
4069
4070
4071 "type":"home",
4072 "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n"
4073 },
4074 "text",
4075 [
4076 "", "", "", "", "", "", ""
4077 ]
4078 ],
4079 ["tel",
4080 { "type":["work", "voice"], "pref":"1" },
4081 "uri", "tel:+1-555-555-1234;ext=102"
4082 ],
4083 ["tel",
4084 {
4085 "type":["work", "cell", "voice", "video", "text"]
4086 },
4087 "uri",
4088 "tel:+1-555-555-1234"
4089 ],
4090 ["email",
4091 { "type":"work" },
4092 "text", "joe.user@example.com"
4093 ],
4094 ["geo", {
4095 "type":"work"
4096 }, "uri", "geo:46.772673,-71.282945"],
4097 ["key",
4098 { "type":"work" },
4099 "uri", "http://www.example.com/joe.user/joe.asc"
4100 ],
4101 ["tz", {},
4102 "utc-offset", "-05:00"],
4103 ["url", { "type":"home" },
4104 "uri", "http://example.org"]
4105 ]
4106 ]
4107 }
4108
4109 Figure 40
4110
4111 The arrays in Figure 40 with the first member of "adr" represent
4112 postal addresses. In the first example, the postal address is given
4113 as an array of strings and constitutes a structured address. For
4114 components of the structured address that are not applicable, an
4115 empty string is given. Each member of that array aligns with the
4116 positions of a vCard as given in [RFC6350]. In this example, the
4117 following data corresponds to the following positional meanings:
4118
4119
4120
4121
4122 Newton & Hollenbeck Standards Track [Page 75]
4123 RFC 7483 RDAP JSON Responses March 2015
4124
4125
4126 1. post office box -- not applicable; empty string
4127
4128 2. extended address (e.g., apartment or suite number) -- Suite 1234
4129
4130 3. street address -- 4321 Rue Somewhere
4131
4132 4. locality (e.g., city) -- Quebec
4133
4134 5. region (e.g., state or province) -- QC
4135
4136 6. postal code -- G1V 2M2
4137
4138 7. country name (full name) -- Canada
4139
4140 The second example is an unstructured address. It uses the label
4141 attribute, which is a string containing a newline (\n) character to
4142 separate address components in an unordered, unspecified manner.
4143 Note that in this example, the structured address array is still
4144 given but that each string is an empty string.
4145
4146 Appendix D. Secure DNS
4147
4148 Section 5.3 defines the "secureDNS" member to represent secure DNS
4149 information about domain names.
4150
4151 DNSSEC provides data integrity for DNS through the digital signing of
4152 resource records. To enable DNSSEC, the zone is signed by one or
4153 more private keys and the signatures are stored as RRSIG records. To
4154 complete the chain of trust in the DNS zone hierarchy, a digest of
4155 each DNSKEY record (which contains the public key) must be loaded
4156 into the parent zone, stored as DS records, and signed by the
4157 parent's private key (RRSIG DS record), as indicated in "Resource
4158 Records for the DNS Security Extensions" [RFC4034]. Creating the DS
4159 records in the parent zone can be done by the registration authority
4160 "Domain Name System (DNS) Security Extensions Mapping for the
4161 Extensible Provisioning Protocol (EPP)" [RFC5910].
4162
4163 Only DS-related information is provided by RDAP, since other
4164 information is not generally stored in the registration database.
4165 Other DNSSEC-related information can be retrieved with other DNS
4166 tools such as dig.
4167
4168 The domain object class (Section 5.3) can represent this information
4169 using either the "dsData" or "keyData" object arrays. Client
4170 implementers should be aware that some registries do not collect or
4171 do not publish all of the secure DNS meta-information.
4172
4173
4174
4175
4176
4177 Newton & Hollenbeck Standards Track [Page 76]
4178 RFC 7483 RDAP JSON Responses March 2015
4179
4180
4181 Appendix E. Motivations for Using JSON
4182
4183 This section addresses a common question regarding the use of JSON
4184 over other data formats, most notably XML.
4185
4186 It is often pointed out that many DNRs and one RIR support the EPP
4187 [RFC5730] standard, which is an XML serialized protocol. The logic
4188 is that since EPP is a common protocol in the industry, it follows
4189 that XML would be a more natural choice. While EPP does influence
4190 this specification quite a bit, EPP serves a different purpose, which
4191 is the provisioning of Internet resources between registries and
4192 accredited registrars and serving a much narrower audience than that
4193 envisioned for RDAP.
4194
4195 By contrast, RDAP has a broader audience and is designed for public
4196 consumption of data. Experience from RIRs with first generation
4197 RESTful web services for WHOIS indicate that a large percentage of
4198 clients operate within browsers and other platforms where full-blown
4199 XML stacks are not readily available and where JSON is a better fit.
4200
4201 Additionally, while EPP is used in much of the DNR community it is
4202 not a universal constant in that industry. And finally, EPP's use of
4203 XML predates the specification of JSON. If EPP had been defined
4204 today, it may very well have used JSON instead of XML.
4205
4206 Beyond the specific DNR and RIR communities, the trend in the broader
4207 Internet industry is also switching to JSON over XML, especially in
4208 the area of RESTful web services (see [JSON_ascendancy]). Studies
4209 have also found that JSON is generally less bulky and consequently
4210 faster to parse (see [JSON_performance_study]).
4211
4212 Acknowledgements
4213
4214 This document is derived from original work on RIR responses in JSON
4215 by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew L.
4216 Newton. Additionally, this document incorporates work on DNR
4217 responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean
4218 Shen.
4219
4220 The components of the DNR object classes are derived from a
4221 categorization of WHOIS response formats created by Ning Kong, Linlin
4222 Zhou, Guangqing Deng, Steve Sheng, Francisco Arias, Ray Bellis, and
4223 Frederico Neves.
4224
4225 Tom Harrison, Murray Kucherawy, Ed Lewis, Audric Schiltknecht, Naoki
4226 Kambe, and Maarten Bosteels contributed significant review comments
4227 and provided clarifying text. James Mitchell provided text regarding
4228 the processing of unknown JSON attributes and identified issues
4229
4230
4231
4232 Newton & Hollenbeck Standards Track [Page 77]
4233 RFC 7483 RDAP JSON Responses March 2015
4234
4235
4236 leading to the remodeling of events. Ernie Dainow and Francisco
4237 Obispo provided concrete suggestions that led to a better variant
4238 model for domain names.
4239
4240 Ernie Dainow provided the background information on the secure DNS
4241 attributes and objects for domains, informative text on DNSSEC, and
4242 many other attributes that appear throughout the object classes of
4243 this document.
4244
4245 The switch to and incorporation of jCard was performed by Simon
4246 Perreault.
4247
4248 Olaf Kolkman and Murray Kucherawy chaired the IETF's WEIRDS working
4249 group from which this document has been created.
4250
4251 Authors' Addresses
4252
4253 Andrew Lee Newton
4254 American Registry for Internet Numbers
4255 3635 Concorde Parkway
4256 Chantilly, VA 20151
4257 United States
4258
4259 EMail: andy@arin.net
4260 URI: http://www.arin.net
4261
4262
4263 Scott Hollenbeck
4264 Verisign Labs
4265 12061 Bluemont Way
4266 Reston, VA 20190
4267 United States
4268
4269 EMail: shollenbeck@verisign.com
4270 URI: http://www.verisignlabs.com/
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287 Newton & Hollenbeck Standards Track [Page 78]
4288
Description: The object instance was transferred from one registrant to another.
Description: The object instance was transferred from one registrar to another.
I believe the corrected text is what was intended for this particular registry value, and is what is being implemented by operators today. Registrant-to-registrant transfers are also possible, but they're not performed using EPP and are not logged as an event action. The text in the RFC should be changed and the description of the action in the IANA registry should also be changed.