idnits 2.17.1
draft-hollenbeck-regext-rfc7483bis-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
Clients using self links for caching SHOULD not cache any object
class instances where the authority of the self link is different than
the authority of the server returning the data. Failing to do so might
result in cache poisoning.
-- The document date (February 18, 2020) is 1530 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288)
** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
** Obsolete normative reference: RFC 7482 (Obsoleted by RFC 9082)
Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 REGEXT Working Group S. Hollenbeck
3 Internet-Draft Verisign Labs
4 Intended status: Standards Track A. Newton
5 Expires: August 21, 2020 AWS
6 February 18, 2020
8 JSON Responses for the Registration Data Access Protocol (RDAP)
9 draft-hollenbeck-regext-rfc7483bis-00
11 Abstract
13 This document describes JSON data structures representing
14 registration information maintained by Regional Internet Registries
15 (RIRs) and Domain Name Registries (DNRs). These data structures are
16 used to form Registration Data Access Protocol (RDAP) query
17 responses.
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at https://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on August 21, 2020.
36 Copyright Notice
38 Copyright (c) 2020 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
54 1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3
55 1.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 4
56 2. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 5
57 2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 5
58 3. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 7
59 4. Common Data Structures . . . . . . . . . . . . . . . . . . . 8
60 4.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 8
61 4.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 9
62 4.3. Notices and Remarks . . . . . . . . . . . . . . . . . . . 10
63 4.4. Language Identifier . . . . . . . . . . . . . . . . . . . 12
64 4.5. Events . . . . . . . . . . . . . . . . . . . . . . . . . 12
65 4.6. Status . . . . . . . . . . . . . . . . . . . . . . . . . 13
66 4.7. Port 43 WHOIS Server . . . . . . . . . . . . . . . . . . 14
67 4.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 14
68 4.9. Object Class Name . . . . . . . . . . . . . . . . . . . . 14
69 4.10. An Example . . . . . . . . . . . . . . . . . . . . . . . 14
70 5. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 16
71 5.1. The Entity Object Class . . . . . . . . . . . . . . . . . 16
72 5.2. The Nameserver Object Class . . . . . . . . . . . . . . . 23
73 5.3. The Domain Object Class . . . . . . . . . . . . . . . . . 27
74 5.4. The IP Network Object Class . . . . . . . . . . . . . . . 39
75 5.5. Autonomous System Number Entity Object Class . . . . . . 43
76 6. Error Response Body . . . . . . . . . . . . . . . . . . . . . 46
77 7. Responding to Help Queries . . . . . . . . . . . . . . . . . 48
78 8. Responding To Searches . . . . . . . . . . . . . . . . . . . 49
79 9. Indicating Truncated Responses . . . . . . . . . . . . . . . 50
80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
81 10.1. RDAP JSON Media Type Registration . . . . . . . . . . . 53
82 10.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 54
83 10.2.1. Notice and Remark Types . . . . . . . . . . . . . . 55
84 10.2.2. Status . . . . . . . . . . . . . . . . . . . . . . . 56
85 10.2.3. Event Actions . . . . . . . . . . . . . . . . . . . 59
86 10.2.4. Roles . . . . . . . . . . . . . . . . . . . . . . . 61
87 10.2.5. Variant Relations . . . . . . . . . . . . . . . . . 62
88 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 63
89 11.1. RedDog . . . . . . . . . . . . . . . . . . . . . . . . . 64
90 11.2. Verisign . . . . . . . . . . . . . . . . . . . . . . . . 64
91 11.3. Verisign Labs . . . . . . . . . . . . . . . . . . . . . 65
92 12. Security Considerations . . . . . . . . . . . . . . . . . . . 65
93 13. Internationalization Considerations . . . . . . . . . . . . . 65
94 13.1. Character Encoding . . . . . . . . . . . . . . . . . . . 66
95 13.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 66
96 13.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 66
97 13.4. Internationalized Domain Names . . . . . . . . . . . . . 66
98 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 66
99 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 67
100 15.1. Normative References . . . . . . . . . . . . . . . . . . 67
101 15.2. Informative References . . . . . . . . . . . . . . . . . 68
102 Appendix A. Suggested Data Modeling with the Entity Object Class 69
103 A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 69
104 A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 72
105 Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 74
106 Appendix C. Structured vs. Unstructured Addresses . . . . . . . 75
107 Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 78
108 Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 78
109 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 79
110 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
113 1. Introduction
115 This document describes responses in the JSON [RFC7159] format for
116 the queries as defined by the Registration Data Access Protocol Query
117 Format [RFC7482]. A communication protocol for exchanging queries
118 and responses is described in [RFC7480].
120 1.1. Terminology and Definitions
122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
124 document are to be interpreted as described in [RFC2119] when
125 specified in their uppercase forms.
127 The following list describes terminology and definitions used
128 throughout this document:
130 DNR: Domain Name Registry or Domain Name Registrar
132 LDH: letters, digits, hyphen
134 member: data found within an object as defined by JSON [RFC7159].
136 object: a data structure as defined by JSON [RFC7159].
138 object class: the definition of members that may be found in JSON
139 objects described in this document.
141 object instance: an instantiation or specific instance of an object
142 class.
144 RDAP: Registration Data Access Protocol
146 RIR: Regional Internet Registry
148 1.2. Data Model
150 The data model for JSON responses is specified in five sections:
152 1. simple data types conveyed in JSON strings
154 2. data structures specified as JSON arrays or objects that are used
155 repeatedly when building up larger objects
157 3. object classes representing structured data corresponding to a
158 lookup of a single object
160 4. arrays of objects representing structured data corresponding to a
161 search for multiple objects
163 5. the response to an error
165 The object classes represent responses for two major categories of
166 data: responses returned by RIRs for registration data related to IP
167 addresses, reverse DNS names, and Autonomous System numbers and
168 responses returned by DNRs for registration data related to forward
169 DNS names. The following object classes are returned by both RIRs
170 and DNRs:
172 1. domains
174 2. nameservers
176 3. entities
178 The information served by both RIRs and DNRs for these object classes
179 overlap extensively and are given in this document as a unified model
180 for both classes of service.
182 In addition to the object classes listed above, RIRs also serve the
183 following object classes:
185 1. IP networks
186 2. Autonomous System numbers
188 Object classes defined in this document represent a minimal set of
189 what a compliant client/server needs to understand to function
190 correctly; however, some deployments may want to include additional
191 object classes to suit individual needs. Anticipating this need for
192 extension, Section 2.1 of this document defines a mechanism for
193 extending the JSON objects that are described in this document.
195 Positive responses take two forms. A response to a lookup of a
196 single object in the registration system yields a JSON object, which
197 is the subject of the lookup. A response to a search for multiple
198 objects yields a JSON object that contains an array of JSON objects
199 that are the subject of the search. In each type of response, other
200 data structures are present within the topmost JSON object.
202 2. Use of JSON
204 2.1. Naming
206 Clients of these JSON responses SHOULD ignore unrecognized JSON
207 members in responses. Servers can insert members into the JSON
208 responses, which are not specified in this document, but that does
209 not constitute an error in the response. Servers that insert such
210 unspecified members into JSON responses SHOULD have member names
211 prefixed with a short identifier followed by an underscore followed
212 by a meaningful name. It has been observed that these short
213 identifiers aid software implementers with identifying the
214 specification of the JSON member, and failure to use one could cause
215 an implementer to assume the server is erroneously using a name from
216 this specification. This allowance does not apply to jCard [RFC7095]
217 objects. The full JSON name (the prefix plus the underscore plus the
218 meaningful name) SHOULD adhere to the character and name limitations
219 of the prefix registry described in [RFC7480]. Failure to use these
220 limitations could result in slower adoption as these limitations have
221 been observed to aid some client programming models.
223 Consider the following JSON response with JSON members, all of which
224 are specified in this document.
226 {
227 "handle" : "ABC123",
228 "remarks" :
229 [
230 {
231 "description" :
232 [
233 "She sells sea shells down by the sea shore.",
234 "Originally written by Terry Sullivan."
235 ]
236 }
237 ]
238 }
240 Figure 1
242 If The Registry of the Moon desires to express information not found
243 in this specification, it might select "lunarNic" as its identifying
244 prefix and insert, as an example, the member named
245 "lunarNic_beforeOneSmallStep" to signify registrations occurring
246 before the first moon landing and the member named
247 "lunarNic_harshMistressNotes" that contains other descriptive text.
249 Consider the following JSON response with JSON names, some of which
250 should be ignored by clients without knowledge of their meaning.
252 {
253 "handle" : "ABC123",
254 "lunarNic_beforeOneSmallStep" : "TRUE THAT!",
255 "remarks" :
256 [
257 {
258 "description" :
259 [
260 "She sells sea shells down by the sea shore.",
261 "Originally written by Terry Sullivan."
262 ]
263 }
264 ],
265 "lunarNic_harshMistressNotes" :
266 [
267 "In space,",
268 "nobody can hear you scream."
269 ]
270 }
272 Figure 2
274 Insertion of unrecognized members ignored by clients may also be used
275 for future revisions to this specification.
277 Clients processing JSON responses need to be prepared for members
278 representing registration data specified in this document to be
279 absent from a response. In other words, servers are free to not
280 include JSON members containing registration data based on their own
281 policies.
283 Finally, all JSON names specified in this document are case
284 sensitive. Both servers and clients MUST transmit and process them
285 using the specified character case.
287 3. Common Data Types
289 JSON [RFC7159] defines the data types of a number, character string,
290 boolean, array, object, and null. This section describes the
291 semantics and/or syntax reference for common, JSON character strings
292 used in this document.
294 handle: DNRs and RIRs have registry-unique identifiers that
295 may be used to specifically reference an object
296 instance. The semantics of this data type as found
297 in this document are to be a registry-unique
298 reference to the closest enclosing object where the
299 value is found. The data type names "registryId",
300 "roid", "nic-handle", "registrationNo", etc., are
301 terms often synonymous with this data type. In
302 this document, the term "handle" is used. The term
303 exposed to users by clients is a presentation issue
304 beyond the scope of this document. This value is a
305 simple string.
307 IPv4 addresses: The representation of IPv4 addresses in this
308 document uses the dotted-decimal notation. An
309 example of this textual representation is
310 "192.0.2.0".
312 IPv6 addresses: The representation of IPv6 addresses in this
313 document follow the forms outlined in [RFC5952].
314 An example of this textual representation is
315 "2001:db8::1:0:0:1".
317 country codes: Where the identity of a geopolitical nation or
318 country is needed, these identities are represented
319 with the alpha-2 or two-character country code
320 designation as defined in [ISO.3166.1988]. The
321 alpha-2 representation is used because it is freely
322 available, whereas the alpha-3 and numeric-3
323 standards are not.
325 LDH names: Textual representations of DNS names where the
326 labels of the domain are all "letters, digits,
327 hyphen" labels as described by [RFC5890]. Trailing
328 periods are optional.
330 Unicode names: Textual representations of DNS names where one or
331 more of the labels are U-labels as described by
332 [RFC5890]. Trailing periods are optional.
334 dates and times: The syntax for values denoting dates and times is
335 defined in [RFC3339].
337 URIs: The syntax for values denoting a Uniform Resource
338 Identifier (URI) is defined by [RFC3986].
340 Contact information is defined using jCards as described in
341 [RFC7095].
343 4. Common Data Structures
345 This section defines common data structures used in responses and
346 object classes.
348 4.1. RDAP Conformance
350 The data structure named "rdapConformance" is an array of strings,
351 each providing a hint as to the specifications used in the
352 construction of the response. This data structure appears only in
353 the topmost JSON object of a response.
355 An example rdapConformance data structure:
357 "rdapConformance" :
358 [
359 "rdap_level_0"
360 ]
362 Figure 3
364 The string literal "rdap_level_0" signifies conformance with this
365 specification. When custom JSON values are inserted into responses,
366 conformance to those custom specifications MUST use a string prefixed
367 with the appropriate identifier from the IANA RDAP Extensions
368 registry specified in [RFC7480]. For example, if the fictional
369 Registry of the Moon wants to signify that their JSON responses are
370 conformant with their registered extensions, the string used might be
371 "lunarNIC_level_0". These prefixes aid the identification of
372 specifications for software implementers, and failure to use them
373 could result in slower adoption of extensions.
375 Example rdapConformance structure with custom extensions noted:
377 "rdapConformance" :
378 [
379 "rdap_level_0",
380 "lunarNic_level_0"
381 ]
383 Figure 4
385 4.2. Links
387 The "links" array is found in data structures to signify links to
388 other resources on the Internet. The relationship of these links is
389 defined by the IANA registry described by [RFC5988].
391 The following is an example of the link structure:
393 {
394 "value" : "http://example.com/context_uri",
395 "rel" : "self",
396 "href" : "http://example.com/target_uri",
397 "hreflang" : [ "en", "ch" ],
398 "title" : "title",
399 "media" : "screen",
400 "type" : "application/json"
401 }
403 Figure 5
405 The JSON name/values of "rel", "href", "hreflang", "title", "media",
406 and "type" correspond to values found in Section 5 of [RFC5988]. The
407 "value" JSON value is the context URI as described by [RFC5988]. The
408 "href" JSON value MUST be specified. All other JSON values are
409 OPTIONAL.
411 This is an example of the "links" array as it might be found in an
412 object class:
414 "links" :
415 [
416 {
417 "value" : "http://example.com/ip/2001:db8::123",
418 "rel" : "self",
419 "href" : "http://example.com/ip/2001:db8::123",
420 "type" : "application/rdap+json"
421 },
422 {
423 "value" : "http://example.com/ip/2001:db8::123",
424 "rel" : "up",
425 "href" : "http://example.com/ip/2001:db8::/48",
426 "type" : "application/rdap+json"
427 }
429 ]
431 Figure 6
433 4.3. Notices and Remarks
435 The "notices" and "remarks" data structures take the same form. The
436 notices structure denotes information about the service providing
437 RDAP information and/or information about the entire response,
438 whereas the remarks structure denotes information about the object
439 class that contains it (see Section 5 regarding object classes).
441 Both are arrays of objects. Each object contains an optional "title"
442 string representing the title of the object, an optional "type"
443 string denoting a registered type of remark or notice (see
444 Section 10.2.1), an array of strings named "description" for the
445 purposes of conveying any descriptive text, and an optional "links"
446 array as described in Section 4.2.
448 An example of the notices data structure:
450 "notices" :
451 [
452 {
453 "title" : "Terms of Use",
454 "description" :
455 [
456 "Service subject to The Registry of the Moon's TOS.",
457 "Copyright (c) 2020 LunarNIC"
458 ],
459 "links" :
460 [
461 {
462 "value" : "http://example.net/entity/XXXX",
463 "rel" : "alternate",
464 "type" : "text/html",
465 "href" : "http://www.example.com/terms_of_use.html"
466 }
467 ]
468 }
469 ]
471 Figure 7
473 It is the job of the clients to determine line breaks, spacing, and
474 display issues for sentences within the character strings of the
475 "description" array. Each string in the "description" array contains
476 a single complete division of human-readable text indicating to
477 clients where there are semantic breaks.
479 An example of the remarks data structure:
481 "remarks" :
482 [
483 {
484 "description" :
485 [
486 "She sells sea shells down by the sea shore.",
487 "Originally written by Terry Sullivan."
488 ]
489 }
490 ]
492 Figure 8
494 Note that objects in the "remarks" array may also have a "links"
495 array.
497 While the "title" and "description" fields are intended primarily for
498 human consumption, the "type" string contains a well-known value to
499 be registered with IANA (see Section 10.2.1) for programmatic use.
501 An example of the remarks data structure:
503 "remarks" :
504 [
505 {
506 "type" : "object truncated due to authorization",
507 "description" :
508 [
509 "Some registration data may not have been given.",
510 "Use proper authorization credentials to see all of it."
511 ]
512 }
513 ]
515 Figure 9
517 While the "remarks" array will appear in many object classes in a
518 response, the "notices" array appears only in the topmost object of a
519 response.
521 4.4. Language Identifier
523 This data structure consists solely of a name/value pair, where the
524 name is "lang" and the value is a string containing a language
525 identifier as described in [RFC5646].
527 "lang" : "mn-Cyrl-MN"
529 Figure 10
531 The "lang" attribute may appear anywhere in an object class or data
532 structure except for in jCard objects.
534 4.5. Events
536 This data structure represents events that have occurred on an
537 instance of an object class (see Section 5 regarding object classes).
539 This is an example of an "events" array.
541 "events" :
542 [
543 {
544 "eventAction" : "registration",
545 "eventActor" : "SOMEID-LUNARNIC",
546 "eventDate" : "1990-12-31T23:59:59Z"
547 },
548 {
549 "eventAction" : "last changed",
550 "eventActor" : "OTHERID-LUNARNIC",
551 "eventDate" : "1991-12-31T23:59:59Z"
552 }
553 ]
555 Figure 11
557 The "events" array consists of objects, each with the following
558 members:
560 o "eventAction" -- a string denoting the reason for the event
562 o "eventActor" -- an optional identifier denoting the actor
563 responsible for the event
565 o "eventDate" -- a string containing the time and date the event
566 occurred.
568 o "links" -- see Section 4.2
570 Events can be future dated. One use case for future dating of events
571 is to denote when an object expires from a registry.
573 The "links" array in this data structure is provided for references
574 to the event actor. In order to reference an RDAP entity, a "rel" of
575 "related" and a "type" of "application/rdap+json" is used in the link
576 reference.
578 See Section 10.2.3 for a list of values for the "eventAction" string.
579 See Appendix B regarding the various ways events can be modeled.
581 4.6. Status
583 This data structure, named "status", is an array of strings
584 indicating the state of a registered object (see Section 10.2.2 for a
585 list of values).
587 4.7. Port 43 WHOIS Server
589 This data structure, a member named "port43", is a simple string
590 containing the fully qualified host name or IP address of the WHOIS
591 [RFC3912] server where the containing object instance may be found.
592 Note that this is not a URI, as there is no WHOIS URI scheme.
594 4.8. Public IDs
596 This data structure maps a public identifier to an object class. It
597 is named "publicIds" and is an array of objects, with each object
598 containing the following members:
600 o type -- a string denoting the type of public identifier
602 o identifier -- a string denoting a public identifier of the type
603 related to "type"
605 The following is an example of a publicIds structure.
607 "publicIds":
608 [
609 {
610 "type":"IANA Registrar ID",
611 "identifier":"1"
612 }
613 ]
615 Figure 12
617 4.9. Object Class Name
619 This data structure, a member named "objectClassName", gives the
620 object class name of a particular object as a string. This
621 identifies the type of object being processed. An objectClassName is
622 REQUIRED in all RDAP response objects so that the type of the object
623 can be interpreted.
625 4.10. An Example
627 This is an example response with both rdapConformance and notices
628 embedded:
630 {
631 "rdapConformance" :
632 [
633 "rdap_level_0"
634 ],
635 "notices" :
636 [
637 {
638 "title" : "Content Removed",
639 "description" :
640 [
641 "Without full authorization, content has been removed.",
642 "Sorry, dude!"
643 ],
644 "links" :
645 [
646 {
647 "value" : "http://example.net/ip/192.0.2.0/24",
648 "rel" : "alternate",
649 "type" : "text/html",
650 "href" : "http://www.example.com/redaction_policy.html"
651 }
652 ]
653 }
654 ],
655 "lang" : "en",
656 "objectClassName" : "ip network",
657 "startAddress" : "192.0.2.0",
658 "endAddress" : "192.0.2.255",
659 "handle" : "XXXX-RIR",
660 "ipVersion" : "v4",
661 "name": "NET-RTR-1",
662 "parentHandle" : "YYYY-RIR",
663 "remarks" :
664 [
666 {
667 "description" :
668 [
669 "She sells sea shells down by the sea shore.",
670 "Originally written by Terry Sullivan."
671 ]
672 }
673 ]
674 }
676 Figure 13
678 5. Object Classes
680 Object classes represent structures appropriate for a response from
681 the queries specified in [RFC7482].
683 Each object class contains a "links" array as specified in
684 Section 4.2. For every object class instance in a response, whether
685 the object class instance is directly representing the response to a
686 query or is embedded in other object class instances or is an item in
687 a search result set, servers SHOULD provide a link representing a URI
688 for that object class instance using the "self" relationship as
689 described in the IANA registry specified by [RFC5988]. As explained
690 in Section 5.2, this may be not always be possible for nameserver
691 data. Clients MUST be able to process object instances without a
692 self link. When present, clients can use the self link for caching
693 data. Servers MAY provide more than one self link for any given
694 object instance. Failure to provide any self link by a server may
695 result in clients being unable to cache object class instances.
697 Clients using self links for caching SHOULD not cache any object
698 class instances where the authority of the self link is different
699 than the authority of the server returning the data. Failing to do
700 so might result in cache poisoning.
702 Self links MUST contain a "type" element containing the "application/
703 rdap+json" media type when referencing RDAP object instances as
704 defined by this document.
706 This is an example of the "links" array with a self link to an object
707 class:
709 "links" :
710 [
711 {
712 "value" : "http://example.com/ip/2001:db8::123",
713 "rel" : "self",
714 "href" : "http://example.com/ip/2001:db8::123",
715 "type" : "application/rdap+json"
716 }
717 ]
719 Figure 14
721 5.1. The Entity Object Class
723 The entity object class appears throughout this document and is an
724 appropriate response for the /entity/XXXX query defined in
725 "Registration Data Access Protocol (RDAP) Query Format" [RFC7482].
727 This object class represents the information of organizations,
728 corporations, governments, non-profits, clubs, individual persons,
729 and informal groups of people. All of these representations are so
730 similar that it is best to represent them in JSON [RFC7159] with one
731 construct, the entity object class, to aid in the reuse of code by
732 implementers.
734 The entity object class uses jCard [RFC7095] to represent contact
735 information, such as postal addresses, email addresses, phone numbers
736 and names of organizations and individuals. Many of the types of
737 information that can be represented with jCard have no use in RDAP,
738 such as birthdays, anniversaries, and gender.
740 The entity object is served by both RIRs and DNRs. The following is
741 an example of an entity that might be served by an RIR.
743 {
744 "objectClassName" : "entity",
745 "handle":"XXXX",
746 "vcardArray":[
747 "vcard",
748 [
749 ["version", {}, "text", "4.0"],
750 ["fn", {}, "text", "Joe User"],
751 ["n", {}, "text",
752 ["User", "Joe", "", "", ["ing. jr", "M.Sc."]]
753 ],
754 ["kind", {}, "text", "individual"],
755 ["lang", {
756 "pref":"1"
757 }, "language-tag", "fr"],
758 ["lang", {
759 "pref":"2"
760 }, "language-tag", "en"],
761 ["org", {
762 "type":"work"
763 }, "text", "Example"],
764 ["title", {}, "text", "Research Scientist"],
765 ["role", {}, "text", "Project Lead"],
766 ["adr",
767 { "type":"work" },
768 "text",
769 [
770 "",
771 "Suite 1234",
772 "4321 Rue Somewhere",
773 "Quebec",
774 "QC",
775 "G1V 2M2",
776 "Canada"
777 ]
778 ],
779 ["adr",
780 {
781 "type":"home",
782 "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n"
783 },
784 "text",
785 [
786 "", "", "", "", "", "", ""
787 ]
788 ],
789 ["tel",
790 {
791 "type":["work", "voice"],
792 "pref":"1"
793 },
794 "uri",
795 "tel:+1-555-555-1234;ext=102"
796 ],
797 ["tel",
798 { "type":["work", "cell", "voice", "video", "text"] },
799 "uri",
800 "tel:+1-555-555-4321"
801 ],
802 ["email",
803 { "type":"work" },
804 "text",
805 "joe.user@example.com"
806 ],
807 ["geo", {
808 "type":"work"
809 }, "uri", "geo:46.772673,-71.282945"],
810 ["key",
811 { "type":"work" },
812 "uri",
813 "http://www.example.com/joe.user/joe.asc"
814 ],
815 ["tz", {},
816 "utc-offset", "-05:00"],
817 ["url", { "type":"home" },
818 "uri", "http://example.org"]
819 ]
820 ],
821 "roles":[ "registrar" ],
822 "publicIds":[
823 {
824 "type":"IANA Registrar ID",
825 "identifier":"1"
826 }
827 ],
828 "remarks":[
829 {
830 "description":[
831 "She sells sea shells down by the sea shore.",
832 "Originally written by Terry Sullivan."
833 ]
834 }
835 ],
836 "links":[
837 {
838 "value":"http://example.com/entity/XXXX",
839 "rel":"self",
840 "href":"http://example.com/entity/XXXX",
841 "type" : "application/rdap+json"
842 }
843 ],
844 "events":[
845 {
846 "eventAction":"registration",
847 "eventDate":"1990-12-31T23:59:59Z"
848 }
849 ],
850 "asEventActor":[
852 {
853 "eventAction":"last changed",
854 "eventDate":"1991-12-31T23:59:59Z"
855 }
856 ]
857 }
859 Figure 15
861 The entity object class can contain the following members:
863 o objectClassName -- the string "entity"
865 o handle -- a string representing a registry unique identifier of
866 the entity
868 o vcardArray -- a jCard with the entity's contact information
869 o roles -- an array of strings, each signifying the relationship an
870 object would have with its closest containing object (see
871 Section 10.2.4 for a list of values)
873 o publicIds -- see Section 4.8
875 o entities -- an array of entity objects as defined by this section
877 o remarks -- see Section 4.3
879 o links -- see Section 4.2
881 o events -- see Section 4.5
883 o asEventActor -- this data structure takes the same form as the
884 events data structure (see Section 4.5), but each object in the
885 array MUST NOT have an "eventActor" member. These objects denote
886 that the entity is an event actor for the given events. See
887 Appendix B regarding the various ways events can be modeled.
889 o status -- see Section 4.6
891 o port43 -- see Section 4.7
893 o networks -- an array of IP network objects as defined in
894 Section 5.4
896 o autnums -- an array of autnum objects as defined in Section 5.5
898 Entities may also have other entities embedded with them in an array.
899 This can be used to model an organization with specific individuals
900 fulfilling designated roles of responsibility.
902 The following is an elided example of an entity with embedded
903 entities.
905 {
906 "objectClassName" : "entity",
907 "handle" : "ANENTITY",
908 "roles" : [ "registrar" ],
909 ...
910 "entities" :
911 [
912 {
913 "objectClassName" : "entity",
914 "handle": "ANEMBEDDEDENTITY",
915 "roles" : [ "technical" ],
916 ...
917 },
918 ...
919 ],
920 ...
921 }
923 Figure 16
925 The following is an example of an entity that might be served by a
926 DNR.
928 {
929 "objectClassName" : "entity",
930 "handle":"XXXX",
931 "vcardArray":[
932 "vcard",
933 [
934 ["version", {}, "text", "4.0"],
935 ["fn", {}, "text", "Joe User"],
936 ["kind", {}, "text", "individual"],
937 ["lang", {
938 "pref":"1"
939 }, "language-tag", "fr"],
940 ["lang", {
941 "pref":"2"
942 }, "language-tag", "en"],
943 ["org", {
944 "type":"work"
945 }, "text", "Example"],
946 ["title", {}, "text", "Research Scientist"],
947 ["role", {}, "text", "Project Lead"],
948 ["adr",
949 { "type":"work" },
950 "text",
951 [
952 "",
953 "Suite 1234",
954 "4321 Rue Somewhere",
955 "Quebec",
956 "QC",
957 "G1V 2M2",
958 "Canada"
959 ]
960 ],
961 ["tel",
962 { "type":["work", "voice"], "pref":"1" },
963 "uri", "tel:+1-555-555-1234;ext=102"
964 ],
965 ["email",
966 { "type":"work" },
967 "text", "joe.user@example.com"
968 ]
969 ]
970 ],
971 "status":[ "validated", "locked" ],
972 "remarks":[
973 {
974 "description":[
975 "She sells sea shells down by the sea shore.",
976 "Originally written by Terry Sullivan."
977 ]
978 }
979 ],
980 "links":[
981 {
982 "value":"http://example.com/entity/XXXX",
983 "rel":"self",
984 "href":"http://example.com/entity/XXXX",
985 "type":"application/rdap+json"
986 }
987 ],
988 "port43":"whois.example.net",
989 "events":[
990 {
991 "eventAction":"registration",
992 "eventDate":"1990-12-31T23:59:59Z"
993 },
994 {
995 "eventAction":"last changed",
996 "eventDate":"1991-12-31T23:59:59Z",
997 "eventActor":"joe@example.com"
998 }
999 ]
1000 }
1001 Figure 17
1003 See Appendix A for use of the entity object class to model various
1004 types of entities found in both RIRs and DNRs. See Appendix C
1005 regarding structured vs. unstructured postal addresses in entities.
1007 5.2. The Nameserver Object Class
1009 The nameserver object class represents information regarding DNS
1010 nameservers used in both forward and reverse DNS. RIRs and some DNRs
1011 register or expose nameserver information as an attribute of a domain
1012 name, while other DNRs model nameservers as "first class objects".
1014 The nameserver object class accommodates both models and degrees of
1015 variation in between.
1017 The following is an example of a nameserver object.
1019 {
1020 "objectClassName" : "nameserver",
1021 "handle" : "XXXX",
1022 "ldhName" : "ns1.xn--fo-5ja.example",
1023 "unicodeName" : "ns1.foo.example",
1024 "status" : [ "active" ],
1025 "ipAddresses" :
1026 {
1027 "v4": [ "192.0.2.1", "192.0.2.2" ],
1028 "v6": [ "2001:db8::123" ]
1029 },
1030 "remarks" :
1031 [
1032 {
1033 "description" :
1034 [
1035 "She sells sea shells down by the sea shore.",
1036 "Originally written by Terry Sullivan."
1037 ]
1038 }
1039 ],
1040 "links" :
1041 [
1042 {
1043 "value" : "http://example.net/nameserver/xxxx",
1044 "rel" : "self",
1045 "href" : "http://example.net/nameserver/xxxx",
1046 "type" : "application/rdap+json"
1047 }
1048 ],
1049 "port43" : "whois.example.net",
1050 "events" :
1051 [
1052 {
1053 "eventAction" : "registration",
1054 "eventDate" : "1990-12-31T23:59:59Z"
1055 },
1056 {
1057 "eventAction" : "last changed",
1058 "eventDate" : "1991-12-31T23:59:59Z",
1059 "eventActor" : "joe@example.com"
1060 }
1061 ]
1062 }
1064 Figure 18
1066 Figure 18 is an example of a nameserver object with all values given.
1067 Registries using a first-class nameserver data model would embed this
1068 in domain objects as well as allowing references to it with the
1069 "/nameserver" query type (all depending on the registry operators
1070 policy). Other registries may pare back the information as needed.
1071 Figure 19 is an example of a nameserver object as would be found in
1072 RIRs and some DNRs, while Figure 20 is an example of a nameserver
1073 object as would be found in other DNRs.
1075 The following is an example of the simplest nameserver object:
1077 {
1078 "objectClassName" : "nameserver",
1079 "ldhName" : "ns1.example.com"
1080 }
1082 Figure 19
1084 The following is an example of a simple nameserver object that might
1085 be commonly used by DNRs:
1087 {
1088 "objectClassName" : "nameserver",
1089 "ldhName" : "ns1.example.com",
1090 "ipAddresses" : { "v6" : [ "2001:db8::123", "2001:db8::124" ] }
1091 }
1093 Figure 20
1095 As nameservers can be modeled by some registries to be first-class
1096 objects, they may also have an array of entities (Section 5.1)
1097 embedded to signify parties responsible for the maintenance,
1098 registrations, etc., of the nameservers.
1100 The following is an elided example of a nameserver with embedded
1101 entities.
1103 {
1104 "objectClassName" : "nameserver",
1105 "handle" : "XXXX",
1106 "ldhName" : "ns1.xn--fo-5ja.example",
1107 ...
1108 "entities" :
1109 [
1110 ...
1111 ],
1112 ...
1113 }
1115 Figure 21
1117 The nameserver object class can contain the following members:
1119 o objectClassName -- the string "nameserver"
1121 o handle -- a string representing a registry unique identifier of
1122 the nameserver
1124 o ldhName -- a string containing the LDH name of the nameserver (see
1125 Section 3)
1127 o unicodeName -- a string containing a DNS Unicode name of the
1128 nameserver (see Section 3)
1130 o ipAddresses -- an object containing the following members:
1132 * v6 -- an array of strings containing IPv6 addresses of the
1133 nameserver
1135 * v4 -- an array of strings containing IPv4 addresses of the
1136 nameserver
1138 o entities -- an array of entity objects as defined by Section 5.1
1140 o status -- see Section 4.6
1142 o remarks -- see Section 4.3
1144 o links -- see Section 4.2
1146 o port43 -- see Section 4.7
1148 o events -- see Section 4.5
1150 5.3. The Domain Object Class
1152 The domain object class represents a DNS name and point of
1153 delegation. For RIRs, these delegation points are in the reverse DNS
1154 tree, whereas for DNRs, these delegation points are in the forward
1155 DNS tree.
1157 In both cases, the high-level structure of the domain object class
1158 consists of information about the domain registration, nameserver
1159 information related to the domain name, and entities related to the
1160 domain name (e.g., registrant information, contacts, etc.).
1162 The following is an elided example of the domain object showing the
1163 high-level structure:
1165 {
1166 "objectClassName" : "domain",
1167 "handle" : "XXX",
1168 "ldhName" : "blah.example.com",
1169 ...
1170 "nameservers" :
1171 [
1172 ...
1173 ],
1174 ...
1175 "entities" :
1176 [
1177 ...
1178 ]
1179 }
1181 Figure 22
1183 The domain object class can contain the following members:
1185 o objectClassName -- the string "domain"
1187 o handle -- a string representing a registry unique identifier of
1188 the domain object instance
1190 o ldhName -- a string describing a domain name in LDH form as
1191 described in Section 3
1193 o unicodeName -- a string containing a domain name with U-labels as
1194 described in Section 3
1196 o variants -- an array of objects, each containing the following
1197 values:
1199 * relation -- an array of strings, with each string denoting the
1200 relationship between the variants and the containing domain
1201 object (see Section 10.2.5 for a list of suggested variant
1202 relations).
1204 * idnTable -- the name of the Internationalized Domain Name (IDN)
1205 table of codepoints, such as one listed with the IANA (see IDN
1206 tables [IANA_IDNTABLES]).
1208 * variantNames -- an array of objects, with each object
1209 containing an "ldhName" member and a "unicodeName" member (see
1210 Section 3).
1212 o nameservers -- an array of nameserver objects as defined by
1213 Section 5.2
1215 o secureDNS -- an object with the following members:
1217 * zoneSigned -- true if the zone has been signed, false
1218 otherwise.
1220 * delegationSigned -- boolean true if there are DS records in the
1221 parent, false otherwise.
1223 * maxSigLife -- an integer representing the signature lifetime in
1224 seconds to be used when creating the RRSIG DS record in the
1225 parent zone [RFC5910].
1227 * dsData -- an array of objects, each with the following members:
1229 + keyTag -- an integer as specified by the key tag field of a
1230 DNS DS record as specified by [RFC4034] in presentation
1231 format
1233 + algorithm -- an integer as specified by the algorithm field
1234 of a DNS DS record as described by RFC 4034 in presentation
1235 format
1237 + digest -- a string as specified by the digest field of a DNS
1238 DS record as specified by RFC 4034 in presentation format
1240 + digestType -- an integer as specified by the digest type
1241 field of a DNS DS record as specified by RFC 4034 in
1242 presentation format
1244 + events -- see Section 4.5
1246 + links -- see Section 4.2
1248 * keyData -- an array of objects, each with the following
1249 members:
1251 + flags -- an integer representing the flags field value in
1252 the DNSKEY record [RFC4034] in presentation format
1254 + protocol -- an integer representation of the protocol field
1255 value of the DNSKEY record [RFC4034] in presentation format
1257 + publicKey -- a string representation of the public key in
1258 the DNSKEY record [RFC4034] in presentation format
1260 + algorithm -- an integer as specified by the algorithm field
1261 of a DNSKEY record as specified by [RFC4034] in presentation
1262 format
1264 + events -- see Section 4.5
1266 + links -- see Section 4.2
1268 See Appendix D for background information on these objects.
1270 o entities -- an array of entity objects as defined by Section 5.1
1272 o status -- see Section 4.6
1274 o publicIds -- see Section 4.8
1276 o remarks -- see Section 4.3
1278 o links -- see Section 4.2
1280 o port43 -- see Section 4.7
1282 o events -- see Section 4.5
1284 o network -- represents the IP network for which a reverse DNS
1285 domain is referenced. See Section 5.4
1287 The following is an example of a JSON domain object representing a
1288 reverse DNS delegation point that might be served by an RIR.
1290 {
1291 "objectClassName" : "domain",
1292 "handle" : "XXXX",
1293 "ldhName" : "0.2.192.in-addr.arpa",
1294 "nameservers" :
1295 [
1296 {
1297 "objectClassName" : "nameserver",
1298 "ldhName" : "ns1.rir.example"
1299 },
1300 {
1301 "objectClassName" : "nameserver",
1302 "ldhName" : "ns2.rir.example"
1303 }
1304 ],
1305 "secureDNS":
1306 {
1307 "delegationSigned": true,
1308 "dsData":
1309 [
1310 {
1311 "keyTag": 12345,
1312 "algorithm": 3,
1313 "digestType": 1,
1314 "digest": "49FD46E6C4B45C55D4AC"
1315 }
1316 ]
1317 },
1318 "remarks" :
1319 [
1320 {
1321 "description" :
1322 [
1323 "She sells sea shells down by the sea shore.",
1324 "Originally written by Terry Sullivan."
1325 ]
1326 }
1327 ],
1328 "links" :
1329 [
1330 {
1331 "value": "http://example.net/domain/XXXX",
1332 "rel" : "self",
1333 "href" : "http://example.net/domain/XXXXX",
1334 "type" : "application/rdap+json"
1336 }
1337 ],
1338 "events" :
1339 [
1340 {
1341 "eventAction" : "registration",
1342 "eventDate" : "1990-12-31T23:59:59Z"
1343 },
1344 {
1345 "eventAction" : "last changed",
1346 "eventDate" : "1991-12-31T23:59:59Z",
1347 "eventActor" : "joe@example.com"
1348 }
1349 ],
1350 "entities" :
1351 [
1352 {
1353 "objectClassName" : "entity",
1354 "handle" : "XXXX",
1355 "vcardArray":[
1356 "vcard",
1357 [
1358 ["version", {}, "text", "4.0"],
1359 ["fn", {}, "text", "Joe User"],
1360 ["kind", {}, "text", "individual"],
1361 ["lang", {
1362 "pref":"1"
1363 }, "language-tag", "fr"],
1364 ["lang", {
1365 "pref":"2"
1366 }, "language-tag", "en"],
1367 ["org", {
1368 "type":"work"
1369 }, "text", "Example"],
1370 ["title", {}, "text", "Research Scientist"],
1371 ["role", {}, "text", "Project Lead"],
1372 ["adr",
1373 { "type":"work" },
1374 "text",
1375 [
1376 "",
1377 "Suite 1234",
1378 "4321 Rue Somewhere",
1379 "Quebec",
1380 "QC",
1381 "G1V 2M2",
1382 "Canada"
1383 ]
1385 ],
1386 ["tel",
1387 { "type":["work", "voice"], "pref":"1" },
1388 "uri", "tel:+1-555-555-1234;ext=102"
1389 ],
1391 ["email",
1392 { "type":"work" },
1393 "text", "joe.user@example.com"
1394 ]
1395 ]
1396 ],
1397 "roles" : [ "registrant" ],
1398 "remarks" :
1399 [
1400 {
1401 "description" :
1402 [
1403 "She sells sea shells down by the sea shore.",
1404 "Originally written by Terry Sullivan."
1405 ]
1406 }
1407 ],
1408 "links" :
1409 [
1410 {
1411 "value": "http://example.net/entity/xxxx",
1412 "rel" : "self",
1413 "href" : "http://example.net/entity/xxxx",
1414 "type" : "application/rdap+json"
1415 }
1416 ],
1417 "events" :
1418 [
1419 {
1420 "eventAction" : "registration",
1421 "eventDate" : "1990-12-31T23:59:59Z"
1422 },
1423 {
1424 "eventAction" : "last changed",
1425 "eventDate" : "1991-12-31T23:59:59Z",
1426 "eventActor" : "joe@example.com"
1427 }
1428 ]
1429 }
1430 ],
1431 "network" :
1432 {
1433 "objectClassName" : "ip network",
1434 "handle" : "XXXX-RIR",
1435 "startAddress" : "192.0.2.0",
1436 "endAddress" : "192.0.2.255",
1437 "ipVersion" : "v4",
1438 "name": "NET-RTR-1",
1439 "type" : "DIRECT ALLOCATION",
1440 "country" : "AU",
1441 "parentHandle" : "YYYY-RIR",
1442 "status" : [ "active" ]
1443 }
1444 }
1446 Figure 23
1448 The following is an example of a JSON domain object representing a
1449 forward DNS delegation point that might be served by a DNR.
1451 {
1452 "objectClassName" : "domain",
1453 "handle" : "XXXX",
1454 "ldhName" : "xn--fo-5ja.example",
1455 "unicodeName" : "foo.example",
1456 "variants" :
1457 [
1458 {
1459 "relation" : [ "registered", "conjoined" ],
1460 "variantNames" :
1461 [
1462 {
1463 "ldhName" : "xn--fo-cka.example",
1464 "unicodeName" : "foo.example"
1465 },
1466 {
1467 "ldhName" : "xn--fo-fka.example",
1468 "unicodeName" : "foeo.example"
1469 }
1470 ]
1471 },
1472 {
1473 "relation" : [ "unregistered", "registration restricted" ],
1474 "idnTable": ".EXAMPLE Swedish",
1475 "variantNames" :
1476 [
1477 {
1478 "ldhName": "xn--fo-8ja.example",
1479 "unicodeName" : "foo.example"
1480 }
1481 ]
1483 }
1484 ],
1485 "status" : [ "locked", "transfer prohibited" ],
1486 "publicIds":[
1487 {
1488 "type":"ENS_Auth ID",
1489 "identifier":"1234567890"
1490 }
1491 ],
1492 "nameservers" :
1493 [
1494 {
1495 "objectClassName" : "nameserver",
1496 "handle" : "XXXX",
1497 "ldhName" : "ns1.example.com",
1498 "status" : [ "active" ],
1499 "ipAddresses" :
1500 {
1501 "v6": [ "2001:db8::123", "2001:db8::124" ],
1502 "v4": [ "192.0.2.1", "192.0.2.2" ]
1503 },
1504 "remarks" :
1505 [
1506 {
1507 "description" :
1508 [
1509 "She sells sea shells down by the sea shore.",
1510 "Originally written by Terry Sullivan."
1511 ]
1512 }
1513 ],
1514 "links" :
1515 [
1516 {
1517 "value" : "http://example.net/nameserver/XXXX",
1518 "rel" : "self",
1519 "href" : "http://example.net/nameserver/XXXX",
1520 "type" : "application/rdap+json"
1521 }
1522 ],
1523 "events" :
1524 [
1525 {
1526 "eventAction" : "registration",
1527 "eventDate" : "1990-12-31T23:59:59Z"
1528 },
1529 {
1530 "eventAction" : "last changed",
1531 "eventDate" : "1991-12-31T23:59:59Z"
1532 }
1533 ]
1534 },
1535 {
1536 "objectClassName" : "nameserver",
1537 "handle" : "XXXX",
1538 "ldhName" : "ns2.example.com",
1539 "status" : [ "active" ],
1540 "ipAddresses" :
1541 {
1542 "v6" : [ "2001:db8::125", "2001:db8::126" ],
1543 "v4" : [ "192.0.2.3", "192.0.2.4" ]
1544 },
1545 "remarks" :
1546 [
1547 {
1548 "description" :
1549 [
1550 "She sells sea shells down by the sea shore.",
1551 "Originally written by Terry Sullivan."
1552 ]
1553 }
1554 ],
1555 "links" :
1556 [
1557 {
1558 "value" : "http://example.net/nameserver/XXXX",
1559 "rel" : "self",
1560 "href" : "http://example.net/nameserver/XXXX",
1561 "type" : "application/rdap+json"
1562 }
1563 ],
1564 "events" :
1565 [
1566 {
1567 "eventAction" : "registration",
1568 "eventDate" : "1990-12-31T23:59:59Z"
1569 },
1570 {
1571 "eventAction" : "last changed",
1572 "eventDate" : "1991-12-31T23:59:59Z"
1573 }
1574 ]
1575 }
1576 ],
1577 "secureDNS":
1578 {
1580 "zoneSigned": true,
1581 "delegationSigned": true,
1582 "maxSigLife": 604800,
1583 "keyData":
1584 [
1585 {
1586 "flags": 257,
1587 "protocol": 3,
1588 "algorithm": 1,
1589 "publicKey": "AQPJ////4Q==",
1590 "events":
1591 [
1592 {
1593 "eventAction": "last changed",
1594 "eventDate": "2012-07-23T05:15:47Z"
1595 }
1596 ]
1597 }
1598 ]
1599 },
1600 "remarks" :
1601 [
1602 {
1603 "description" :
1604 [
1605 "She sells sea shells down by the sea shore.",
1606 "Originally written by Terry Sullivan."
1607 ]
1608 }
1609 ],
1610 "links" :
1611 [
1612 {
1613 "value": "http://example.net/domain/XXXX",
1614 "rel" : "self",
1615 "href" : "http://example.net/domain/XXXX",
1616 "type" : "application/rdap+json"
1617 }
1618 ],
1619 "port43" : "whois.example.net",
1620 "events" :
1621 [
1622 {
1623 "eventAction" : "registration",
1624 "eventDate" : "1990-12-31T23:59:59Z"
1625 },
1626 {
1627 "eventAction" : "last changed",
1628 "eventDate" : "1991-12-31T23:59:59Z",
1629 "eventActor" : "joe@example.com"
1630 },
1631 {
1632 "eventAction" : "transfer",
1633 "eventDate" : "1991-12-31T23:59:59Z",
1634 "eventActor" : "joe@example.com"
1635 },
1636 {
1637 "eventAction" : "expiration",
1638 "eventDate" : "2016-12-31T23:59:59Z",
1639 "eventActor" : "joe@example.com"
1640 }
1641 ],
1642 "entities" :
1643 [
1644 {
1645 "objectClassName" : "entity",
1646 "handle" : "XXXX",
1647 "vcardArray":[
1648 "vcard",
1649 [
1650 ["version", {}, "text", "4.0"],
1651 ["fn", {}, "text", "Joe User"],
1652 ["kind", {}, "text", "individual"],
1653 ["lang", {
1654 "pref":"1"
1655 }, "language-tag", "fr"],
1656 ["lang", {
1657 "pref":"2"
1658 }, "language-tag", "en"],
1659 ["org", {
1660 "type":"work"
1661 }, "text", "Example"],
1662 ["title", {}, "text", "Research Scientist"],
1663 ["role", {}, "text", "Project Lead"],
1664 ["adr",
1665 { "type":"work" },
1666 "text",
1667 [
1668 "",
1669 "Suite 1234",
1670 "4321 Rue Somewhere",
1671 "Quebec",
1672 "QC",
1673 "G1V 2M2",
1674 "Canada"
1675 ]
1677 ],
1678 ["tel",
1679 { "type":["work", "voice"], "pref":"1" },
1680 "uri", "tel:+1-555-555-1234;ext=102"
1681 ],
1682 ["email",
1683 { "type":"work" },
1684 "text", "joe.user@example.com"
1685 ]
1686 ]
1687 ],
1688 "status" : [ "validated", "locked" ],
1689 "roles" : [ "registrant" ],
1690 "remarks" :
1691 [
1692 {
1693 "description" :
1694 [
1695 "She sells sea shells down by the sea shore.",
1696 "Originally written by Terry Sullivan."
1697 ]
1698 }
1699 ],
1700 "links" :
1701 [
1702 {
1703 "value" : "http://example.net/entity/xxxx",
1704 "rel" : "self",
1705 "href" : "http://example.net/entity/xxxx",
1706 "type" : "application/rdap+json"
1707 }
1708 ],
1709 "events" :
1710 [
1711 {
1712 "eventAction" : "registration",
1713 "eventDate" : "1990-12-31T23:59:59Z"
1714 },
1715 {
1716 "eventAction" : "last changed",
1717 "eventDate" : "1991-12-31T23:59:59Z"
1718 }
1719 ]
1720 }
1721 ]
1722 }
1724 Figure 24
1726 5.4. The IP Network Object Class
1728 The IP network object class models IP network registrations found in
1729 RIRs and is the expected response for the "/ip" query as defined by
1730 [RFC7482]. There is no equivalent object class for DNRs. The high-
1731 level structure of the IP network object class consists of
1732 information about the network registration and entities related to
1733 the IP network (e.g., registrant information, contacts, etc.).
1735 The following is an elided example of the IP network object type
1736 showing the high-level structure:
1738 {
1739 "objectClassName" : "ip network",
1740 "handle" : "XXX",
1741 ...
1742 "entities" :
1743 [
1744 ...
1745 ]
1746 }
1748 Figure 25
1750 The following is an example of the JSON object for the network
1751 registration information.
1753 {
1754 "objectClassName" : "ip network",
1755 "handle" : "XXXX-RIR",
1756 "startAddress" : "2001:db8::",
1757 "endAddress" : "2001:db8:0:ffff:ffff:ffff:ffff:ffff",
1758 "ipVersion" : "v6",
1759 "name": "NET-RTR-1",
1760 "type" : "DIRECT ALLOCATION",
1761 "country" : "AU",
1762 "parentHandle" : "YYYY-RIR",
1763 "status" : [ "active" ],
1764 "remarks" :
1765 [
1766 {
1767 "description" :
1768 [
1769 "She sells sea shells down by the sea shore.",
1770 "Originally written by Terry Sullivan."
1771 ]
1772 }
1773 ],
1774 "links" :
1775 [
1776 {
1777 "value" : "http://example.net/ip/2001:db8::/48",
1778 "rel" : "self",
1779 "href" : "http://example.net/ip/2001:db8::/48",
1780 "type" : "application/rdap+json"
1781 },
1782 {
1783 "value" : "http://example.net/ip/2001:db8::/48",
1784 "rel" : "up",
1785 "href" : "http://example.net/ip/2001:C00::/23",
1786 "type" : "application/rdap+json"
1787 }
1788 ],
1789 "events" :
1790 [
1791 {
1792 "eventAction" : "registration",
1793 "eventDate" : "1990-12-31T23:59:59Z"
1794 },
1795 {
1796 "eventAction" : "last changed",
1797 "eventDate" : "1991-12-31T23:59:59Z"
1798 }
1799 ],
1800 "entities" :
1801 [
1802 {
1803 "objectClassName" : "entity",
1804 "handle" : "XXXX",
1805 "vcardArray":[
1806 "vcard",
1807 [
1808 ["version", {}, "text", "4.0"],
1809 ["fn", {}, "text", "Joe User"],
1810 ["kind", {}, "text", "individual"],
1811 ["lang", {
1812 "pref":"1"
1813 }, "language-tag", "fr"],
1814 ["lang", {
1815 "pref":"2"
1816 }, "language-tag", "en"],
1817 ["org", {
1818 "type":"work"
1819 }, "text", "Example"],
1820 ["title", {}, "text", "Research Scientist"],
1821 ["role", {}, "text", "Project Lead"],
1823 ["adr",
1824 { "type":"work" },
1825 "text",
1826 [
1827 "",
1828 "Suite 1234",
1829 "4321 Rue Somewhere",
1830 "Quebec",
1831 "QC",
1832 "G1V 2M2",
1833 "Canada"
1834 ]
1835 ],
1836 ["tel",
1837 { "type":["work", "voice"], "pref":"1" },
1838 "uri", "tel:+1-555-555-1234;ext=102"
1839 ],
1840 ["email",
1841 { "type":"work" },
1842 "text", "joe.user@example.com"
1843 ]
1844 ]
1845 ],
1846 "roles" : [ "registrant" ],
1847 "remarks" :
1848 [
1849 {
1850 "description" :
1851 [
1852 "She sells sea shells down by the sea shore.",
1853 "Originally written by Terry Sullivan."
1854 ]
1855 }
1856 ],
1857 "links" :
1858 [
1859 {
1860 "value" : "http://example.net/entity/xxxx",
1861 "rel" : "self",
1862 "href" : "http://example.net/entity/xxxx",
1863 "type" : "application/rdap+json"
1864 }
1865 ],
1866 "events" :
1867 [
1868 {
1869 "eventAction" : "registration",
1870 "eventDate" : "1990-12-31T23:59:59Z"
1872 },
1873 {
1874 "eventAction" : "last changed",
1875 "eventDate" : "1991-12-31T23:59:59Z"
1876 }
1877 ]
1878 }
1879 ]
1880 }
1882 Figure 26
1884 The IP network object class can contain the following members:
1886 o objectClassName -- the string "ip network"
1888 o handle -- a string representing an RIR-unique identifier of the
1889 network registration
1891 o startAddress -- the starting IP address of the network, either
1892 IPv4 or IPv6
1894 o endAddress -- the ending IP address of the network, either IPv4 or
1895 IPv6
1897 o ipVersion -- a string signifying the IP protocol version of the
1898 network: "v4" signifies an IPv4 network, and "v6" signifies an
1899 IPv6 network
1901 o name -- an identifier assigned to the network registration by the
1902 registration holder
1904 o type -- a string containing an RIR-specific classification of the
1905 network
1907 o country -- a string containing the two-character country code of
1908 the network
1910 o parentHandle -- a string containing an RIR-unique identifier of
1911 the parent network of this network registration
1913 o status -- an array of strings indicating the state of the IP
1914 network
1916 o entities -- an array of entity objects as defined by Section 5.1
1918 o remarks -- see Section 4.3
1919 o links -- see Section 4.2
1921 o port43 -- see Section 4.7
1923 o events -- see Section 4.5
1925 5.5. Autonomous System Number Entity Object Class
1927 The Autonomous System number (autnum) object class models Autonomous
1928 System number registrations found in RIRs and represents the expected
1929 response to an "/autnum" query as defined by [RFC7482]. There is no
1930 equivalent object class for DNRs. The high-level structure of the
1931 autnum object class consists of information about the network
1932 registration and entities related to the autnum registration (e.g.,
1933 registrant information, contacts, etc.) and is similar to the IP
1934 network entity object class.
1936 The following is an example of a JSON object representing an autnum.
1938 {
1939 "objectClassName" : "autnum",
1940 "handle" : "XXXX-RIR",
1941 "startAutnum" : 10,
1942 "endAutnum" : 15,
1943 "name": "AS-RTR-1",
1944 "type" : "DIRECT ALLOCATION",
1945 "status" : [ "active" ],
1946 "country": "AU",
1947 "remarks" :
1948 [
1949 {
1950 "description" :
1951 [
1952 "She sells sea shells down by the sea shore.",
1953 "Originally written by Terry Sullivan."
1954 ]
1955 }
1956 ],
1957 "links" :
1958 [
1959 {
1960 "value" : "http://example.net/autnum/xxxx",
1961 "rel" : "self",
1962 "href" : "http://example.net/autnum/xxxx",
1963 "type" : "application/rdap+json"
1964 }
1965 ],
1966 "events" :
1968 [
1969 {
1970 "eventAction" : "registration",
1971 "eventDate" : "1990-12-31T23:59:59Z"
1972 },
1973 {
1974 "eventAction" : "last changed",
1975 "eventDate" : "1991-12-31T23:59:59Z"
1976 }
1977 ],
1978 "entities" :
1979 [
1980 {
1981 "objectClassName" : "entity",
1982 "handle" : "XXXX",
1983 "vcardArray":[
1984 "vcard",
1985 [
1986 ["version", {}, "text", "4.0"],
1987 ["fn", {}, "text", "Joe User"],
1988 ["kind", {}, "text", "individual"],
1989 ["lang", {
1990 "pref":"1"
1991 }, "language-tag", "fr"],
1992 ["lang", {
1993 "pref":"2"
1994 }, "language-tag", "en"],
1995 ["org", {
1996 "type":"work"
1997 }, "text", "Example"],
1998 ["title", {}, "text", "Research Scientist"],
1999 ["role", {}, "text", "Project Lead"],
2000 ["adr",
2001 { "type":"work" },
2002 "text",
2003 [
2004 "",
2005 "Suite 1234",
2006 "4321 Rue Somewhere",
2007 "Quebec",
2008 "QC",
2009 "G1V 2M2",
2010 "Canada"
2011 ]
2012 ],
2013 ["tel",
2014 { "type":["work", "voice"], "pref":"1" },
2015 "uri", "tel:+1-555-555-1234;ext=102"
2017 ],
2018 ["email",
2019 { "type":"work" },
2020 "text", "joe.user@example.com"
2021 ]
2022 ]
2023 ],
2024 "roles" : [ "registrant" ],
2025 "remarks" :
2026 [
2027 {
2028 "description" :
2029 [
2030 "She sells sea shells down by the sea shore.",
2031 "Originally written by Terry Sullivan."
2032 ]
2033 }
2034 ],
2035 "links" :
2036 [
2037 {
2038 "value" : "http://example.net/entity/XXXX",
2039 "rel" : "self",
2040 "href" : "http://example.net/entity/XXXX",
2041 "type" : "application/rdap+json"
2042 }
2043 ],
2044 "events" :
2045 [
2046 {
2047 "eventAction" : "registration",
2048 "eventDate" : "1990-12-31T23:59:59Z"
2049 },
2050 {
2051 "eventAction" : "last changed",
2052 "eventDate" : "1991-12-31T23:59:59Z"
2053 }
2054 ]
2055 }
2056 ]
2057 }
2059 Figure 27
2061 The Autonomous System number object class can contain the following
2062 members:
2064 o objectClassName -- the string "autnum"
2065 o handle -- a string representing an RIR-unique identifier of the
2066 autnum registration
2068 o startAutnum -- a number representing the starting number [RFC5396]
2069 in the block of Autonomous System numbers
2071 o endAutnum -- a number representing the ending number [RFC5396] in
2072 the block of Autonomous System numbers
2074 o name -- an identifier assigned to the autnum registration by the
2075 registration holder
2077 o type -- a string containing an RIR-specific classification of the
2078 autnum
2080 o status -- an array of strings indicating the state of the autnum
2082 o country -- a string containing the two-character country code of
2083 the autnum
2085 o entities -- an array of entity objects as defined by Section 5.1
2087 o remarks -- see Section 4.3
2089 o links -- see Section 4.2
2091 o port43 -- see Section 4.7
2093 o events -- see Section 4.5
2095 6. Error Response Body
2097 Some non-answer responses may return entity bodies with information
2098 that could be more descriptive.
2100 The basic structure of that response is an object class containing an
2101 error code number (corresponding to the HTTP response code) followed
2102 by a string named "title" and an array of strings named
2103 "description".
2105 This is an example of the common response body.
2107 {
2108 "errorCode": 418,
2109 "title": "Your Beverage Choice is Not Available",
2110 "description":
2111 [
2112 "I know coffee has more ummppphhh.",
2113 "Sorry, dude!"
2114 ]
2115 }
2117 Figure 28
2119 This is an example of the common response body with an
2120 rdapConformance and notices data structures:
2122 {
2123 "rdapConformance" :
2124 [
2125 "rdap_level_0"
2126 ],
2127 "notices" :
2128 [
2129 {
2130 "title" : "Beverage Policy",
2131 "description" :
2132 [
2133 "Beverages with caffeine for keeping horses awake."
2134 ],
2135 "links" :
2136 [
2137 {
2138 "value" : "http://example.net/ip/192.0.2.0/24",
2139 "rel" : "alternate",
2140 "type" : "text/html",
2141 "href" : "http://www.example.com/redaction_policy.html"
2142 }
2143 ]
2144 }
2145 ],
2146 "lang" : "en",
2147 "errorCode": 418,
2148 "title": "Your beverage choice is not available",
2149 "description":
2150 [
2151 "I know coffee has more ummppphhh.",
2152 "Sorry, dude!"
2153 ]
2154 }
2156 Figure 29
2158 7. Responding to Help Queries
2160 The appropriate response to /help queries as defined by [RFC7482] is
2161 to use the notices structure as defined in Section 4.3.
2163 This is an example of a response to a /help query including the
2164 rdapConformance data structure.
2166 {
2167 "rdapConformance" :
2168 [
2169 "rdap_level_0"
2170 ],
2171 "notices" :
2172 [
2173 {
2174 "title" : "Authentication Policy",
2175 "description" :
2176 [
2177 "Access to sensitive data for users with proper credentials."
2178 ],
2179 "links" :
2180 [
2181 {
2182 "value" : "http://example.net/help",
2183 "rel" : "alternate",
2184 "type" : "text/html",
2185 "href" : "http://www.example.com/auth_policy.html"
2186 }
2187 ]
2188 }
2189 ]
2190 }
2192 Figure 30
2194 8. Responding To Searches
2196 [RFC7482] specifies three types of searches: domains, nameservers,
2197 and entities. Responses to these searches take the form of an array
2198 of object instances where each instance is an appropriate object
2199 class for the search (i.e., a search for /domains yields an array of
2200 domain object instances). These arrays are contained within the
2201 response object.
2203 The names of the arrays are as follows:
2205 o for /domains searches, the array is "domainSearchResults"
2207 o for /nameservers searches, the array is "nameserverSearchResults"
2209 o for /entities searches, the array is "entitySearchResults"
2211 The following is an elided example of a response to a /domains
2212 search.
2214 {
2215 "rdapConformance" :
2216 [
2217 "rdap_level_0"
2218 ],
2219 ...
2220 "domainSearchResults" :
2221 [
2222 {
2223 "objectClassName" : "domain",
2224 "handle" : "1-XXXX",
2225 "ldhName" : "1.example.com",
2226 ...
2227 },
2228 {
2229 "objectClassName" : "domain",
2230 "handle" : "2-XXXX",
2231 "ldhName" : "2.example.com",
2232 ...
2233 }
2234 ]
2235 }
2237 Figure 31
2239 9. Indicating Truncated Responses
2241 In cases where the data of a response needs to be limited or parts of
2242 the data need to be omitted, the response is considered "truncated".
2243 A truncated response is still valid JSON, but some of the results in
2244 a search set or some of the data in an object are not provided by the
2245 server. A server may indicate this by including a typed notice in
2246 the response object.
2248 The following is an elided example of a search response that has been
2249 truncated.
2251 {
2252 "rdapConformance" :
2253 [
2254 "rdap_level_0"
2255 ],
2256 "notices" :
2257 [
2258 {
2259 "title" : "Search Policy",
2260 "type" : "result set truncated due to authorization",
2261 "description" :
2262 [
2263 "Search results are limited to 25 per day per querying IP."
2264 ],
2265 "links" :
2266 [
2267 {
2268 "value" : "http://example.net/help",
2269 "rel" : "alternate",
2270 "type" : "text/html",
2271 "href" : "http://www.example.com/search_policy.html"
2272 }
2273 ]
2274 }
2275 ],
2276 "domainSearchResults" :
2277 [
2278 ...
2279 ]
2280 }
2282 Figure 32
2284 A similar technique can be used with a typed remark where a single
2285 object has been returned and data in that object has been truncated.
2286 Such an example might be an entity object with only a partial set of
2287 the IP networks associated with it.
2289 The following is an elided example of an entity truncated data.
2291 {
2292 "objectClassName" : "entity",
2293 "handle" : "ANENTITY",
2294 "roles" : [ "registrant" ],
2295 ...
2296 "entities" :
2297 [
2298 {
2299 "objectClassName" : "entity",
2300 "handle": "ANEMBEDDEDENTITY",
2301 "roles" : [ "technical" ],
2302 ...
2303 },
2304 ...
2305 ],
2306 "networks" :
2307 [
2308 ...
2309 ],
2310 ...
2311 "remarks" :
2312 [
2313 {
2314 "title" : "Data Policy",
2315 "type" : "object truncated due to unexplainable reason",
2316 "description" :
2317 [
2318 "Some of the data in this object has been removed."
2319 ],
2320 "links" :
2321 [
2322 {
2323 "value" : "http://example.net/help",
2324 "rel" : "alternate",
2325 "type" : "text/html",
2326 "href" : "http://www.example.com/data_policy.html"
2327 }
2328 ]
2329 }
2330 ]
2331 }
2333 Figure 33
2335 10. IANA Considerations
2337 10.1. RDAP JSON Media Type Registration
2339 This specification registers the "application/rdap+json" media type.
2341 Type name: application
2343 Subtype name: rdap+json
2345 Required parameters: n/a
2347 Encoding considerations: See Section 3.1 of [RFC6839].
2349 Security considerations: The media represented by this identifier
2350 does not have security considerations beyond that found in
2351 Section 6 of [RFC7159].
2353 Interoperability considerations: There are no known
2354 interoperability problems regarding this media format.
2356 Published specification: RFC 7483
2358 Applications that use this media type: Implementations of the
2359 Registration Data Access Protocol (RDAP).
2361 Additional information: This media type is a product of the IETF
2362 WEIRDS working group. The WEIRDS charter, information on the
2363 WEIRDS mailing list, and other documents produced by the WEIRDS
2364 working group can be found at .
2367 Person & email address to contact for further information: IESG
2368
2370 Intended usage: COMMON
2372 Restrictions on usage: none
2374 Author: Andy Newton
2376 Change controller: IETF
2378 Provisional Registration: No (upon publication of this RFC)
2380 10.2. JSON Values Registry
2382 IANA has created a category in the protocol registries labeled
2383 "Registration Data Access Protocol (RDAP)", and within that category,
2384 IANA has established a URL-referenceable, stand-alone registry
2385 labeled "RDAP JSON Values". This new registry is for use in the
2386 notices and remarks (Section 4.3), status (Section 4.6), role
2387 (Section 5.1), event action (Section 4.5), and domain variant
2388 relation (Section 5.3) fields specified in RDAP.
2390 Each entry in the registry contains the following fields:
2392 1. Value -- the string value being registered.
2394 2. Type -- the type of value being registered. It should be one of
2395 the following:
2397 * "notice or remark type" -- denotes a type of notice or remark.
2399 * "status" -- denotes a value for the "status" object member as
2400 defined by Section 4.6.
2402 * "role" -- denotes a value for the "role" array as defined in
2403 Section 5.1.
2405 * "event action" -- denotes a value for an event action as
2406 defined in Section 4.5.
2408 * "domain variant relation" -- denotes a relationship between a
2409 domain and a domain variant as defined in Section 5.3.
2411 3. Description -- a one- or two-sentence description regarding the
2412 meaning of the value, how it might be used, and/or how it should
2413 be interpreted by clients.
2415 4. Registrant Name -- the name of the person registering the value.
2417 5. Registrant Contact Information -- an email address, postal
2418 address, or some other information to be used to contact the
2419 registrant.
2421 This registry is operated under the "Expert Review" policy defined in
2422 [RFC5226].
2424 Review of registrations into this registry by the designated
2425 expert(s) should be narrowly judged on the following criteria:
2427 1. Values in need of being placed into multiple types must be
2428 assigned a separate registration for each type.
2430 2. Values must be strings. They should be multiple words separated
2431 by single space characters. Every character should be
2432 lowercased. If possible, every word should be given in English
2433 and each character should be US-ASCII.
2435 3. Registrations should not duplicate the meaning of any existing
2436 registration. That is, if a request for a registration is
2437 significantly similar in nature to an existing registration, the
2438 request should be denied. For example, the terms "maintainer"
2439 and "registrant" are significantly similar in nature as they both
2440 denote a holder of a domain name or Internet number resource. In
2441 cases where it may be reasonably argued that machine
2442 interpretation of two similar values may alter the operation of
2443 client software, designated experts should not judge the values
2444 to be of significant similarity.
2446 4. Registrations should be relevant to the common usages of RDAP.
2447 Designated experts may rely upon the serving of the value by a
2448 DNR or RIR to make this determination.
2450 The following sections provide initial registrations into this
2451 registry.
2453 10.2.1. Notice and Remark Types
2455 The following values have been registered in the "RDAP JSON Values"
2456 registry:
2458 Value: result set truncated due to authorization
2459 Type: notice and remark type
2460 Description: The list of results does not contain all results due
2461 to lack of authorization. This may indicate to some clients that
2462 proper authorization will yield a longer result set.
2463 Registrant Name: IESG
2464 Registrant Contact Information: iesg@ietf.org
2466 Value: result set truncated due to excessive load
2467 Type: notice and remark type
2468 Description: The list of results does not contain all results due
2469 to excessively heavy load on the server. This may indicate to
2470 some clients that requerying at a later time will yield a longer
2471 result set.
2472 Registrant Name: IESG
2473 Registrant Contact Information: iesg@ietf.org
2474 Value: result set truncated due to unexplainable reasons
2475 Type: notice and remark type
2476 Description: The list of results does not contain all results for
2477 an unexplainable reason. This may indicate to some clients that
2478 requerying for any reason will not yield a longer result set.
2479 Registrant Name: IESG
2480 Registrant Contact Information: iesg@ietf.org
2482 Value: object truncated due to authorization
2483 Type: notice and remark type
2484 Description: The object does not contain all data due to lack of
2485 authorization.
2486 Registrant Name: IESG
2487 Registrant Contact Information: iesg@ietf.org
2489 Value: object truncated due to excessive load
2490 Type: notice and remark type
2491 Description: The object does not contain all data due to
2492 excessively heavy load on the server. This may indicate to some
2493 clients that requerying at a later time will yield all data of the
2494 object.
2495 Registrant Name: IESG
2496 Registrant Contact Information: iesg@ietf.org
2498 Value: object truncated due to unexplainable reasons
2499 Type: notice and remark type
2500 Description: The object does not contain all data for an
2501 unexplainable reason.
2502 Registrant Name: IESG
2503 Registrant Contact Information: iesg@ietf.org
2505 10.2.2. Status
2507 The following values have been registered in the "RDAP JSON Values"
2508 registry:
2510 Value: validated
2511 Type: status
2512 Description: Signifies that the data of the object instance has
2513 been found to be accurate. This type of status is usually found
2514 on entity object instances to note the validity of identifying
2515 contact information.
2516 Registrant Name: IESG
2517 Registrant Contact Information: iesg@ietf.org
2519 Value: renew prohibited
2520 Type: status
2521 Description: Renewal or reregistration of the object instance is
2522 forbidden.
2523 Registrant Name: IESG
2524 Registrant Contact Information: iesg@ietf.org
2526 Value: update prohibited
2527 Type: status
2528 Description: Updates to the object instance are forbidden.
2529 Registrant Name: IESG
2530 Registrant Contact Information: iesg@ietf.org
2532 Value: transfer prohibited
2533 Type: status
2534 Description: Transfers of the registration from one registrar to
2535 another are forbidden. This type of status normally applies to
2536 DNR domain names.
2537 Registrant Name: IESG
2538 Registrant Contact Information: iesg@ietf.org
2540 Value: delete prohibited
2541 Type: status
2542 Description: Deletion of the registration of the object instance
2543 is forbidden. This type of status normally applies to DNR domain
2544 names.
2545 Registrant Name: IESG
2546 Registrant Contact Information: iesg@ietf.org
2548 Value: proxy
2549 Type: status
2550 Description: The registration of the object instance has been
2551 performed by a third party. This is most commonly applied to
2552 entities.
2553 Registrant Name: IESG
2554 Registrant Contact Information: iesg@ietf.org
2556 Value: private
2557 Type: status
2558 Description: The information of the object instance is not
2559 designated for public consumption. This is most commonly applied
2560 to entities.
2561 Registrant Name: IESG
2562 Registrant Contact Information: iesg@ietf.org
2564 Value: removed
2565 Type: status
2566 Description: Some of the information of the object instance has
2567 not been made available and has been removed. This is most
2568 commonly applied to entities.
2570 Registrant Name: IESG
2571 Registrant Contact Information: iesg@ietf.org
2573 Value: obscured
2574 Type: status
2575 Description: Some of the information of the object instance has
2576 been altered for the purposes of not readily revealing the actual
2577 information of the object instance. This is most commonly applied
2578 to entities.
2579 Registrant Name: IESG
2580 Registrant Contact Information: iesg@ietf.org
2582 Value: associated
2583 Type: status
2584 Description: The object instance is associated with other object
2585 instances in the registry. This is most commonly used to signify
2586 that a nameserver is associated with a domain or that an entity is
2587 associated with a network resource or domain.
2588 Registrant Name: IESG
2589 Registrant Contact Information: iesg@ietf.org
2591 Value: active
2592 Type: status
2593 Description: The object instance is in use. For domain names, it
2594 signifies that the domain name is published in DNS. For network
2595 and autnum registrations it signifies that they are allocated or
2596 assigned for use in operational networks. This maps to the
2597 Extensible Provisioning Protocol (EPP) [RFC5730] 'OK' status.
2598 Registrant Name: IESG
2599 Registrant Contact Information: iesg@ietf.org
2601 Value: inactive
2602 Type: status
2603 Description: The object instance is not in use. See 'active'.
2604 Registrant Name: IESG
2605 Registrant Contact Information: iesg@ietf.org
2607 Value: locked
2608 Type: status
2609 Description: Changes to the object instance cannot be made,
2610 including the association of other object instances.
2611 Registrant Name: IESG
2612 Registrant Contact Information: iesg@ietf.org
2614 Value: pending create
2615 Type: status
2616 Description: A request has been received for the creation of the
2617 object instance but this action is not yet complete.
2619 Registrant Name: IESG
2620 Registrant Contact Information: iesg@ietf.org
2622 Value: pending renew
2623 Type: status
2624 Description: A request has been received for the renewal of the
2625 object instance but this action is not yet complete.
2626 Registrant Name: IESG
2627 Registrant Contact Information: iesg@ietf.org
2629 Value: pending transfer
2630 Type: status
2631 Description: A request has been received for the transfer of the
2632 object instance but this action is not yet complete.
2633 Registrant Name: IESG
2634 Registrant Contact Information: iesg@ietf.org
2636 Value: pending update
2637 Type: status
2638 Description: A request has been received for the update or
2639 modification of the object instance but this action is not yet
2640 complete.
2641 Registrant Name: IESG
2642 Registrant Contact Information: iesg@ietf.org
2644 Value: pending delete
2645 Type: status
2646 Description: A request has been received for the deletion or
2647 removal of the object instance but this action is not yet
2648 complete. For domains, this might mean that the name is no longer
2649 published in DNS but has not yet been purged from the registry
2650 database.
2651 Registrant Name: IESG
2652 Registrant Contact Information: iesg@ietf.org
2654 10.2.3. Event Actions
2656 The following values have been registered in the "RDAP JSON Values"
2657 registry:
2659 Value: registration
2660 Type: event action
2661 Description: The object instance was initially registered.
2662 Registrant Name: IESG
2663 Registrant Contact Information: iesg@ietf.org
2665 Value: reregistration
2666 Type: event action
2667 Description: The object instance was registered subsequently to
2668 initial registration.
2669 Registrant Name: IESG
2670 Registrant Contact Information: iesg@ietf.org
2672 Value: last changed
2673 Type: event action
2674 Description: An action noting when the information in the object
2675 instance was last changed.
2676 Registrant Name: IESG
2677 Registrant Contact Information: iesg@ietf.org
2679 Value: expiration
2680 Type: event action
2681 Description: The object instance has been removed or will be
2682 removed at a pre-determined date and time from the registry.
2683 Registrant Name: IESG
2684 Registrant Contact Information: iesg@ietf.org
2686 Value: deletion
2687 Type: event action
2688 Description: The object instance was removed from the registry at
2689 a point in time that was not pre-determined.
2690 Registrant Name: IESG
2691 Registrant Contact Information: iesg@ietf.org
2693 Value: reinstantiation
2694 Type: event action
2695 Description: The object instance was reregistered after having
2696 been removed from the registry.
2697 Registrant Name: IESG
2698 Registrant Contact Information: iesg@ietf.org
2700 Value: transfer
2701 Type: event action
2702 Description: The object instance was transferred from one
2703 registrant to another.
2704 Registrant Name: IESG
2705 Registrant Contact Information: iesg@ietf.org
2707 Value: locked
2708 Type: event action
2709 Description: The object instance was locked (see the 'locked'
2710 status).
2711 Registrant Name: IESG
2712 Registrant Contact Information: iesg@ietf.org
2714 Value: unlocked
2715 Type: event action
2716 Description: The object instance was unlocked (see the 'locked'
2717 status).
2718 Registrant Name: IESG
2719 Registrant Contact Information: iesg@ietf.org
2721 10.2.4. Roles
2723 The following values have been registered in the "RDAP JSON Values"
2724 registry:
2726 Value: registrant
2727 Type: role
2728 Description: The entity object instance is the registrant of the
2729 registration. In some registries, this is known as a maintainer.
2730 Registrant Name: IESG
2731 Registrant Contact Information: iesg@ietf.org
2733 Value: technical
2734 Type: role
2735 Description: The entity object instance is a technical contact for
2736 the registration.
2737 Registrant Name: IESG
2738 Registrant Contact Information: iesg@ietf.org
2740 Value: administrative
2741 Type: role
2742 Description: The entity object instance is an administrative
2743 contact for the registration.
2744 Registrant Name: IESG
2745 Registrant Contact Information: iesg@ietf.org
2747 Value: abuse
2748 Type: role
2749 Description: The entity object instance handles network abuse
2750 issues on behalf of the registrant of the registration.
2751 Registrant Name: IESG
2752 Registrant Contact Information: iesg@ietf.org
2754 Value: billing
2755 Type: role
2756 Description: The entity object instance handles payment and
2757 billing issues on behalf of the registrant of the registration.
2758 Registrant Name: IESG
2759 Registrant Contact Information: iesg@ietf.org
2761 Value: registrar
2762 Type: role
2763 Description: The entity object instance represents the authority
2764 responsible for the registration in the registry.
2765 Registrant Name: IESG
2766 Registrant Contact Information: iesg@ietf.org
2768 Value: reseller
2769 Type: role
2770 Description: The entity object instance represents a third party
2771 through which the registration was conducted (i.e. not the
2772 registry or registrar).
2773 Registrant Name: IESG
2774 Registrant Contact Information: iesg@ietf.org
2776 Value: sponsor
2777 Type: role
2778 Description: The entity object instance represents a domain policy
2779 sponsor, such as an ICANN approved sponsor.
2780 Registrant Name: IESG
2781 Registrant Contact Information: iesg@ietf.org
2783 Value: proxy
2784 Type: role
2785 Description: The entity object instance represents a proxy for
2786 another entity object, such as a registrant.
2787 Registrant Name: IESG
2788 Registrant Contact Information: iesg@ietf.org
2790 Value: notifications
2791 Type: role
2792 Description: An entity object instance designated to receive
2793 notifications about association object instances.
2794 Registrant Name: IESG
2795 Registrant Contact Information: iesg@ietf.org
2797 Value: noc
2798 Type: role
2799 Description: The entity object instance handles communications
2800 related to a network operations center (NOC).
2801 Registrant Name: IESG
2802 Registrant Contact Information: iesg@ietf.org
2804 10.2.5. Variant Relations
2806 The following values have been registered in the "RDAP JSON Values"
2807 registry:
2809 Value: registered
2810 Type: domain variant relation
2811 Description: The variant names are registered in the registry.
2812 Registrant Name: IESG
2813 Registrant Contact Information: iesg@ietf.org
2815 Value: unregistered
2816 Type: domain variant relation
2817 Description: The variant names are not found in the registry.
2818 Registrant Name: IESG
2819 Registrant Contact Information: iesg@ietf.org
2821 Value: registration restricted
2822 Type: domain variant relation
2823 Description: Registration of the variant names is restricted to
2824 certain parties or within certain rules.
2825 Registrant Name: IESG
2826 Registrant Contact Information: iesg@ietf.org
2828 Value: open registration
2829 Type: domain variant relation
2830 Description: Registration of the variant names is available to
2831 generally qualified registrants.
2832 Registrant Name: IESG
2833 Registrant Contact Information: iesg@ietf.org
2835 Value: conjoined
2836 Type: domain variant relation
2837 Description: Registration of the variant names occurs
2838 automatically with the registration of the containing domain
2839 registration.
2840 Registrant Name: IESG
2841 Registrant Contact Information: iesg@ietf.org
2843 11. Implementation Status
2845 NOTE: Please remove this section and the reference to RFC 7942 prior
2846 to publication as an RFC.
2848 This section records the status of known implementations of the
2849 protocol defined by this specification at the time of posting of this
2850 Internet-Draft, and is based on a proposal described in RFC 7942
2851 [RFC7942]. The description of implementations in this section is
2852 intended to assist the IETF in its decision processes in progressing
2853 drafts to RFCs. Please note that the listing of any individual
2854 implementation here does not imply endorsement by the IETF.
2855 Furthermore, no effort has been spent to verify the information
2856 presented here that was supplied by IETF contributors. This is not
2857 intended as, and must not be construed to be, a catalog of available
2858 implementations or their features. Readers are advised to note that
2859 other implementations may exist.
2861 According to RFC 7942, "this will allow reviewers and working groups
2862 to assign due consideration to documents that have the benefit of
2863 running code, which may serve as evidence of valuable experimentation
2864 and feedback that have made the implemented protocols more mature.
2865 It is up to the individual working groups to use this information as
2866 they see fit".
2868 11.1. RedDog
2870 Responsible Organization: NIC Mexico
2872 Location: https://reddog.mx/
2874 Description: RedDog implements all the functionality of an RDAP
2875 Server defined in RFCs 7480,7481,7482 and 7483. RedDog is highly
2876 configurable and extensible to fit the needs of the developers and
2877 operators.
2879 Level of Maturity: Production.
2881 Coverage: RedDog supports all lookups, searches and responses for
2882 all object classes described in RFC 7482 and RFC 7483.
2884 Version Compatibility: RFC 7482 and RFC 7483
2886 Licensing: Apache License 2.0
2888 Contact Information: reddog-dev@nic.mx
2890 Information last updated: November 22, 2019
2892 11.2. Verisign
2894 Responsible Organization: Verisign
2896 Location: https://rdap.verisign.com/com/v1/,
2897 https://rdap.verisign.com/net/v1/
2899 Description: Verisign's production RDAP service for the .com and
2900 .net gTLDs.
2902 Level of Maturity: Production.
2904 Coverage: Lookup of domain names, name servers, entities; name
2905 server search by IP address; help.
2907 Version Compatibility: RFC 7483
2909 Contact Information: info@verisign-grs.com
2911 11.3. Verisign Labs
2913 Responsible Organization: Verisign Labs
2915 Location: https://rdap.verisignlabs.com/rdap/v1/
2917 Description: Verisign's experimental RDAP service for the .cc and
2918 .tv ccTLDs.
2920 Level of Maturity: Experimental.
2922 Coverage: Lookup of domain names, name servers, entities; name
2923 server search by IP address; basic search; regular expression
2924 search; federated authentication; help.
2926 Version Compatibility: RFC 7483
2928 Contact Information: Scott Hollenbeck, shollenbeck@verisign.com
2930 12. Security Considerations
2932 This specification models information serialized in JSON format. As
2933 JSON is a subset of JavaScript, implementations are advised to follow
2934 the security considerations outlined in Section 6 of [RFC7159] to
2935 prevent code injection.
2937 Though not specific to JSON, RDAP implementers should be aware of the
2938 security considerations specified in [RFC7480] and the security
2939 requirements and considerations in [RFC7481].
2941 Clients caching data, especially clients using RDAP-specific caches
2942 (instead of HTTP-layer caches), should have safeguards to prevent
2943 cache poisoning. See Section 5 for advice on using the self links
2944 for caching.
2946 Finally, service operators should be aware of the privacy mechanisms
2947 noted in Section 14.
2949 13. Internationalization Considerations
2950 13.1. Character Encoding
2952 The default text encoding for JSON responses in RDAP is UTF-8
2953 [RFC3629], and all servers and clients MUST support UTF-8.
2955 13.2. URIs and IRIs
2957 [RFC7480] defines the use of URIs and IRIs in RDAP.
2959 13.3. Language Tags
2961 Section 4.4 defines the use of language tags in the JSON responses
2962 defined in this document.
2964 13.4. Internationalized Domain Names
2966 IDNs are denoted in this specification by the separation of DNS names
2967 in LDH form and Unicode form (see Section 3). Representation of IDNs
2968 in registries is described by the "variants" object in Section 5.3
2969 and the suggested values listed in Section 10.2.5.
2971 14. Privacy Considerations
2973 This specification suggests status values to denote contact and
2974 registrant information that has been marked as private and/or has
2975 been removed or obscured. See Section 10.2.2 for the complete list
2976 of status values. A few of the status values indicate that there are
2977 privacy concerns associated with the object instance. The following
2978 status codes SHOULD be used to describe data elements of a response
2979 when appropriate:
2981 private -- The object is not be shared in query responses, unless
2982 the user is authorized to view this information.
2984 removed -- Data elements within the object have been collected but
2985 have been omitted from the response. This option can be used to
2986 prevent unauthorized access to associated object instances without
2987 the need to mark them as private.
2989 obscured -- Data elements within the object have been collected,
2990 but the response value has been altered so that values are not
2991 easily discernible. A value changed from "1212" to "XXXX" is an
2992 example of obscured data. This option may reveal privacy
2993 sensitive information and should only be used when data
2994 sensitivity does not require a more protective option like
2995 "private" or "removed".
2997 See Appendix A.1 for an example of applying those values to contacts
2998 and registrants.
3000 15. References
3002 15.1. Normative References
3004 [ISO.3166.1988]
3005 International Organization for Standardization, "Codes for
3006 the representation of names of countries, 3rd edition",
3007 ISO Standard 3166, August 1988.
3009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3010 Requirement Levels", BCP 14, RFC 2119,
3011 DOI 10.17487/RFC2119, March 1997,
3012 .
3014 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
3015 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
3016 .
3018 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
3019 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
3020 2003, .
3022 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3023 Resource Identifier (URI): Generic Syntax", STD 66,
3024 RFC 3986, DOI 10.17487/RFC3986, January 2005,
3025 .
3027 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3028 Rose, "Resource Records for the DNS Security Extensions",
3029 RFC 4034, DOI 10.17487/RFC4034, March 2005,
3030 .
3032 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
3033 IANA Considerations Section in RFCs", RFC 5226,
3034 DOI 10.17487/RFC5226, May 2008,
3035 .
3037 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
3038 Autonomous System (AS) Numbers", RFC 5396,
3039 DOI 10.17487/RFC5396, December 2008,
3040 .
3042 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
3043 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
3044 September 2009, .
3046 [RFC5890] Klensin, J., "Internationalized Domain Names for
3047 Applications (IDNA): Definitions and Document Framework",
3048 RFC 5890, DOI 10.17487/RFC5890, August 2010,
3049 .
3051 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
3052 Address Text Representation", RFC 5952,
3053 DOI 10.17487/RFC5952, August 2010,
3054 .
3056 [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
3057 DOI 10.17487/RFC5988, October 2010,
3058 .
3060 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
3061 DOI 10.17487/RFC7095, January 2014,
3062 .
3064 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
3065 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
3066 2014, .
3068 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
3069 Registration Data Access Protocol (RDAP)", RFC 7480,
3070 DOI 10.17487/RFC7480, March 2015,
3071 .
3073 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
3074 Registration Data Access Protocol (RDAP)", RFC 7481,
3075 DOI 10.17487/RFC7481, March 2015,
3076 .
3078 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
3079 Protocol (RDAP) Query Format", RFC 7482,
3080 DOI 10.17487/RFC7482, March 2015,
3081 .
3083 15.2. Informative References
3085 [IANA_IDNTABLES]
3086 IANA, "Repository of IDN Practices",
3087 .
3089 [JSON_ascendancy]
3090 MacVittie, L., "The Stealthy Ascendancy of JSON", April
3091 2011, .
3094 [JSON_performance_study]
3095 Nurseitov, N., Paulson, M., Reynolds, R., and C. Izurieta,
3096 "Comparison of JSON and XML Data Interchange Formats: A
3097 Case Study", 2009,
3098 .
3100 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
3101 DOI 10.17487/RFC3912, September 2004,
3102 .
3104 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
3105 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
3106 .
3108 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
3109 Security Extensions Mapping for the Extensible
3110 Provisioning Protocol (EPP)", RFC 5910,
3111 DOI 10.17487/RFC5910, May 2010,
3112 .
3114 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
3115 DOI 10.17487/RFC6350, August 2011,
3116 .
3118 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
3119 Structured Syntax Suffixes", RFC 6839,
3120 DOI 10.17487/RFC6839, January 2013,
3121 .
3123 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
3124 Code: The Implementation Status Section", BCP 205,
3125 RFC 7942, DOI 10.17487/RFC7942, July 2016,
3126 .
3128 Appendix A. Suggested Data Modeling with the Entity Object Class
3130 A.1. Registrants and Contacts
3132 This document does not provide specific object classes for
3133 registrants and contacts. Instead, the entity object class may be
3134 used to represent a registrant or contact. When the entity object is
3135 embedded inside a containing object such as a domain name or IP
3136 network, the "roles" string array can be used to signify the
3137 relationship. It is recommended that the values from Section 10.2.4
3138 be used.
3140 The following is an example of an elided containing object with an
3141 embedded entity that is both a registrant and administrative contact:
3143 {
3144 ...
3145 "entities" :
3146 [
3147 {
3148 "objectClassName" : "entity",
3149 "handle" : "XXXX",
3150 "vcardArray":[
3151 "vcard",
3152 [
3153 ["version", {}, "text", "4.0"],
3154 ["fn", {}, "text", "Joe User"],
3155 ["kind", {}, "text", "individual"],
3156 ["lang", {
3157 "pref":"1"
3158 }, "language-tag", "fr"],
3159 ["lang", {
3160 "pref":"2"
3161 }, "language-tag", "en"],
3162 ["org", {
3163 "type":"work"
3164 }, "text", "Example"],
3165 ["title", {}, "text", "Research Scientist"],
3166 ["role", {}, "text", "Project Lead"],
3167 ["adr",
3168 { "type":"work" },
3169 "text",
3170 [
3171 "",
3172 "Suite 1234",
3173 "4321 Rue Somewhere",
3174 "Quebec",
3175 "QC",
3176 "G1V 2M2",
3177 "Canada"
3178 ]
3179 ],
3180 ["tel",
3181 { "type":["work", "voice"], "pref":"1" },
3182 "uri", "tel:+1-555-555-1234;ext=102"
3183 ],
3184 ["email",
3185 { "type":"work" },
3186 "text", "joe.user@example.com"
3187 ]
3188 ]
3189 ],
3190 "roles" : [ "registrant", "administrative" ],
3191 "remarks" :
3192 [
3193 {
3194 "description" :
3195 [
3196 "She sells sea shells down by the sea shore.",
3197 "Originally written by Terry Sullivan."
3198 ]
3199 }
3200 ],
3201 "events" :
3202 [
3203 {
3204 "eventAction" : "registration",
3205 "eventDate" : "1990-12-31T23:59:59Z"
3206 },
3207 {
3208 "eventAction" : "last changed",
3209 "eventDate" : "1991-12-31T23:59:59Z"
3210 }
3211 ]
3212 }
3213 ]
3214 }
3216 Figure 34
3218 In many use cases, it is necessary to hide or obscure the information
3219 of a registrant or contact due to policy or other operational
3220 matters. Registries can denote these situations with "status" values
3221 (see Section 10.2.2).
3223 The following is an elided example of a registrant with information
3224 changed to reflect that of a third party.
3226 {
3227 ...
3228 "entities" :
3229 [
3230 {
3231 "objectClassName" : "entity",
3232 "handle" : "XXXX",
3233 ...
3234 "roles" : [ "registrant", "administrative" ],
3235 "status" : [ "proxy", "private", "obscured" ]
3236 }
3237 ]
3238 }
3240 Figure 35
3242 A.2. Registrars
3244 This document does not provide a specific object class for
3245 registrars, but like registrants and contacts (see Appendix A.1), the
3246 "roles" string array maybe used. Additionally, many registrars have
3247 publicly assigned identifiers. The publicIds structure (Section 4.8)
3248 represents that information.
3250 The following is an example of an elided containing object with an
3251 embedded entity that is a registrar:
3253 {
3254 ...
3255 "entities":[
3256 {
3257 "objectClassName" : "entity",
3258 "handle":"XXXX",
3259 "vcardArray":[
3260 "vcard",
3261 [
3262 ["version", {}, "text", "4.0"],
3263 ["fn", {}, "text", "Joe's Fish, Chips, and Domains"],
3264 ["kind", {}, "text", "org"],
3265 ["lang", {
3266 "pref":"1"
3267 }, "language-tag", "fr"],
3268 ["lang", {
3269 "pref":"2"
3270 }, "language-tag", "en"],
3271 ["org", {
3272 "type":"work"
3273 }, "text", "Example"],
3275 ["adr",
3276 { "type":"work" },
3277 "text",
3278 [
3279 "",
3280 "Suite 1234",
3281 "4321 Rue Somewhere",
3282 "Quebec",
3283 "QC",
3284 "G1V 2M2",
3285 "Canada"
3286 ]
3287 ],
3288 ["tel",
3289 {
3290 "type":["work", "voice"],
3291 "pref":"1"
3292 },
3293 "uri", "tel:+1-555-555-1234;ext=102"
3294 ],
3295 ["email",
3296 { "type":"work" },
3297 "text", "joes_fish_chips_and_domains@example.com"
3298 ]
3299 ]
3300 ],
3301 "roles":[ "registrar" ],
3302 "publicIds":[
3303 {
3304 "type":"IANA Registrar ID",
3305 "identifier":"1"
3306 }
3307 ],
3308 "remarks":[
3309 {
3310 "description":[
3311 "She sells sea shells down by the sea shore.",
3312 "Originally written by Terry Sullivan."
3313 ]
3314 }
3315 ],
3316 "links":[
3317 {
3318 "value":"http://example.net/entity/XXXX",
3319 "rel":"alternate",
3320 "type":"text/html",
3321 "href":"http://www.example.com"
3322 }
3324 ]
3325 }
3326 ]
3327 }
3329 Figure 36
3331 Appendix B. Modeling Events
3333 Events represent actions that have taken place against a registered
3334 object at a certain date and time. Events have three properties: the
3335 action, the actor, and the date and time of the event (which is
3336 sometimes in the future). In some cases, the identity of the actor
3337 is not captured.
3339 Events can be modeled in three ways:
3341 1. events with no designated actor
3343 2. events where the actor is only designated by an identifier
3345 3. events where the actor can be modeled as an entity
3347 For the first use case, the events data structure (Section 4.5) is
3348 used without the "eventActor" object member.
3350 This is an example of an "events" array without the "eventActor".
3352 "events" :
3353 [
3354 {
3355 "eventAction" : "registration",
3356 "eventDate" : "1990-12-31T23:59:59Z"
3357 }
3358 ]
3360 Figure 37
3362 For the second use case, the events data structure (Section 4.5) is
3363 used with the "eventActor" object member.
3365 This is an example of an "events" array with the "eventActor".
3367 "events" :
3368 [
3369 {
3370 "eventAction" : "registration",
3371 "eventActor" : "XYZ-NIC",
3372 "eventDate" : "1990-12-31T23:59:59Z"
3373 }
3374 ]
3376 Figure 38
3378 For the third use case, the "asEventActor" array is used when an
3379 entity (Section 5.1) is embedded into another object class. The
3380 "asEventActor" array follows the same structure as the "events" array
3381 but does not have "eventActor" attributes.
3383 The following is an elided example of a domain object with an entity
3384 as an event actor.
3386 {
3387 "objectClassName" : "domain",
3388 "handle" : "XXXX",
3389 "ldhName" : "foo.example",
3390 "status" : [ "locked", "transfer prohibited" ],
3391 ...
3392 "entities" :
3393 [
3394 {
3395 "handle" : "XXXX",
3396 ...
3397 "asEventActor" :
3398 [
3399 {
3400 "eventAction" : "last changed",
3401 "eventDate" : "1990-12-31T23:59:59Z"
3402 }
3403 ]
3404 }
3405 ]
3406 }
3408 Figure 39
3410 Appendix C. Structured vs. Unstructured Addresses
3412 The entity (Section 5.1) object class uses jCard [RFC7095] to
3413 represent contact information, including postal addresses. jCard has
3414 the ability to represent multiple language preferences, multiple
3415 email address and phone numbers, and multiple postal addresses in
3416 both a structured and unstructured format. This section describes
3417 the use of jCard for representing structured and unstructured
3418 addresses.
3420 The following is an example of a jCard.
3422 {
3423 "vcardArray":[
3424 "vcard",
3425 [
3426 ["version", {}, "text", "4.0"],
3427 ["fn", {}, "text", "Joe User"],
3428 ["n", {}, "text",
3429 ["User", "Joe", "", "", ["ing. jr", "M.Sc."]]
3430 ],
3431 ["kind", {}, "text", "individual"],
3432 ["lang", {
3433 "pref":"1"
3434 }, "language-tag", "fr"],
3435 ["lang", {
3436 "pref":"2"
3437 }, "language-tag", "en"],
3438 ["org", {
3439 "type":"work"
3440 }, "text", "Example"],
3441 ["title", {}, "text", "Research Scientist"],
3442 ["role", {}, "text", "Project Lead"],
3443 ["adr",
3444 { "type":"work" },
3445 "text",
3446 [
3447 "",
3448 "Suite 1234",
3449 "4321 Rue Somewhere",
3450 "Quebec",
3451 "QC",
3452 "G1V 2M2",
3453 "Canada"
3454 ]
3455 ],
3456 ["adr",
3457 {
3459 "type":"home",
3460 "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n"
3461 },
3462 "text",
3464 [
3465 "", "", "", "", "", "", ""
3466 ]
3467 ],
3468 ["tel",
3469 { "type":["work", "voice"], "pref":"1" },
3470 "uri", "tel:+1-555-555-1234;ext=102"
3471 ],
3472 ["tel",
3473 {
3474 "type":["work", "cell", "voice", "video", "text"]
3475 },
3476 "uri",
3477 "tel:+1-555-555-1234"
3478 ],
3479 ["email",
3480 { "type":"work" },
3481 "text", "joe.user@example.com"
3482 ],
3483 ["geo", {
3484 "type":"work"
3485 }, "uri", "geo:46.772673,-71.282945"],
3486 ["key",
3487 { "type":"work" },
3488 "uri", "http://www.example.com/joe.user/joe.asc"
3489 ],
3490 ["tz", {},
3491 "utc-offset", "-05:00"],
3492 ["url", { "type":"home" },
3493 "uri", "http://example.org"]
3494 ]
3495 ]
3496 }
3498 Figure 40
3500 The arrays in Figure 40 with the first member of "adr" represent
3501 postal addresses. In the first example, the postal address is given
3502 as an array of strings and constitutes a structured address. For
3503 components of the structured address that are not applicable, an
3504 empty string is given. Each member of that array aligns with the
3505 positions of a vCard as given in [RFC6350]. In this example, the
3506 following data corresponds to the following positional meanings:
3508 1. post office box -- not applicable; empty string
3510 2. extended address (e.g., apartment or suite number) -- Suite 1234
3511 3. street address -- 4321 Rue Somewhere
3513 4. locality (e.g., city) -- Quebec
3515 5. region (e.g., state or province) -- QC
3517 6. postal code -- G1V 2M2
3519 7. country name (full name) -- Canada
3521 The second example is an unstructured address. It uses the label
3522 attribute, which is a string containing a newline (\n) character to
3523 separate address components in an unordered, unspecified manner.
3524 Note that in this example, the structured address array is still
3525 given but that each string is an empty string.
3527 Appendix D. Secure DNS
3529 Section 5.3 defines the "secureDNS" member to represent secure DNS
3530 information about domain names.
3532 DNSSEC provides data integrity for DNS through the digital signing of
3533 resource records. To enable DNSSEC, the zone is signed by one or
3534 more private keys and the signatures are stored as RRSIG records. To
3535 complete the chain of trust in the DNS zone hierarchy, a digest of
3536 each DNSKEY record (which contains the public key) must be loaded
3537 into the parent zone, stored as DS records, and signed by the
3538 parent's private key (RRSIG DS record), as indicated in "Resource
3539 Records for the DNS Security Extensions" [RFC4034]. Creating the DS
3540 records in the parent zone can be done by the registration authority
3541 "Domain Name System (DNS) Security Extensions Mapping for the
3542 Extensible Provisioning Protocol (EPP)" [RFC5910].
3544 Only DS-related information is provided by RDAP, since other
3545 information is not generally stored in the registration database.
3546 Other DNSSEC-related information can be retrieved with other DNS
3547 tools such as dig.
3549 The domain object class (Section 5.3) can represent this information
3550 using either the "dsData" or "keyData" object arrays. Client
3551 implementers should be aware that some registries do not collect or
3552 do not publish all of the secure DNS meta-information.
3554 Appendix E. Motivations for Using JSON
3556 This section addresses a common question regarding the use of JSON
3557 over other data formats, most notably XML.
3559 It is often pointed out that many DNRs and one RIR support the EPP
3560 [RFC5730] standard, which is an XML serialized protocol. The logic
3561 is that since EPP is a common protocol in the industry, it follows
3562 that XML would be a more natural choice. While EPP does influence
3563 this specification quite a bit, EPP serves a different purpose, which
3564 is the provisioning of Internet resources between registries and
3565 accredited registrars and serving a much narrower audience than that
3566 envisioned for RDAP.
3568 By contrast, RDAP has a broader audience and is designed for public
3569 consumption of data. Experience from RIRs with first generation
3570 RESTful web services for WHOIS indicate that a large percentage of
3571 clients operate within browsers and other platforms where full-blown
3572 XML stacks are not readily available and where JSON is a better fit.
3574 Additionally, while EPP is used in much of the DNR community it is
3575 not a universal constant in that industry. And finally, EPP's use of
3576 XML predates the specification of JSON. If EPP had been defined
3577 today, it may very well have used JSON instead of XML.
3579 Beyond the specific DNR and RIR communities, the trend in the broader
3580 Internet industry is also switching to JSON over XML, especially in
3581 the area of RESTful web services (see [JSON_ascendancy]). Studies
3582 have also found that JSON is generally less bulky and consequently
3583 faster to parse (see [JSON_performance_study]).
3585 Acknowledgements
3587 This document is derived from original work on RIR responses in JSON
3588 by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew
3589 L. Newton. Additionally, this document incorporates work on DNR
3590 responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean
3591 Shen.
3593 The components of the DNR object classes are derived from a
3594 categorization of WHOIS response formats created by Ning Kong, Linlin
3595 Zhou, Guangqing Deng, Steve Sheng, Francisco Arias, Ray Bellis, and
3596 Frederico Neves.
3598 Tom Harrison, Murray Kucherawy, Ed Lewis, Audric Schiltknecht, Naoki
3599 Kambe, and Maarten Bosteels contributed significant review comments
3600 and provided clarifying text. James Mitchell provided text regarding
3601 the processing of unknown JSON attributes and identified issues
3602 leading to the remodeling of events. Ernie Dainow and Francisco
3603 Obispo provided concrete suggestions that led to a better variant
3604 model for domain names.
3606 Ernie Dainow provided the background information on the secure DNS
3607 attributes and objects for domains, informative text on DNSSEC, and
3608 many other attributes that appear throughout the object classes of
3609 this document.
3611 The switch to and incorporation of jCard was performed by Simon
3612 Perreault.
3614 Olaf Kolkman and Murray Kucherawy chaired the IETF's WEIRDS working
3615 group from which this document has been created.
3617 Change Log
3619 00: Initial version ported from RFC 7483. Addressed known errata.
3620 Added Implementation Status section.
3622 Authors' Addresses
3624 Scott Hollenbeck
3625 Verisign Labs
3626 12061 Bluemont Way
3627 Reston, VA 20190
3628 United States
3630 Email: shollenbeck@verisign.com
3631 URI: http://www.verisignlabs.com/
3633 Andy Newton
3634 Amazon Web Services, Inc.
3635 13200 Woodland Park Road
3636 Herndon, VA 20171
3637 United States of America
3639 Email: andy@hxr.us