5Internet Engineering Task Force (IETF) S. Hollenbeck
6Request for Comments: 9083 Verisign Labs
9Category: Standards Track June 2021
13 JSON Responses for the Registration Data Access Protocol (RDAP)
17 This document describes JSON data structures representing
18 registration information maintained by Regional Internet Registries
19 (RIRs) and Domain Name Registries (DNRs). These data structures are
20 used to form Registration Data Access Protocol (RDAP) query
21 responses. This document obsoletes RFC 7483.
25 This is an Internet Standards Track document.
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Further information on
31 Internet Standards is available in Section 2 of RFC 7841.
33 Information about the current status of this document, any errata,
34 and how to provide feedback on it may be obtained at
35 https://www.rfc-editor.org/info/rfc9083.
39 Copyright (c) 2021 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (https://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
55 1.1. Terminology and Definitions
60 4. Common Data Structures
63 4.3. Notices and Remarks
64 4.4. Language Identifier
67 4.7. Port 43 WHOIS Server
69 4.9. Object Class Name
72 5.1. The Entity Object Class
73 5.2. The Nameserver Object Class
74 5.3. The Domain Object Class
75 5.4. The IP Network Object Class
76 5.5. The Autonomous System Number Object Class
77 6. Error Response Body
78 7. Responding to Help Queries
79 8. Responding To Searches
80 9. Indicating Truncated Responses
81 10. IANA Considerations
82 10.1. RDAP JSON Media Type Registration
83 10.2. JSON Values Registry
84 10.2.1. Notice and Remark Types
88 10.2.5. Variant Relations
89 11. Security Considerations
90 12. Internationalization Considerations
91 12.1. Character Encoding
94 12.4. Internationalized Domain Names
95 13. Privacy Considerations
97 14.1. Normative References
98 14.2. Informative References
99 Appendix A. Suggested Data Modeling with the Entity Object Class
100 A.1. Registrants and Contacts
102 Appendix B. Modeling Events
103 Appendix C. Structured vs. Unstructured Addresses
104 Appendix D. Secure DNS
105 Appendix E. Motivations for Using JSON
106 Appendix F. Changes from RFC 7483
112 This document describes responses in the JSON [RFC8259] format for
113 the queries as defined by the Registration Data Access Protocol Query
114 Format [RFC9082]. A communication protocol for exchanging queries
115 and responses is described in [RFC7480]. This document obsoletes RFC
1181.1. Terminology and Definitions
120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
122 "OPTIONAL" in this document are to be interpreted as described in
123 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
124 capitals, as shown here.
126 The following list describes terminology and definitions used
127 throughout this document:
129 DNR: Domain Name Registry or Domain Name Registrar
131 LDH: letters, digits, hyphen
133 member: data found within an object as defined by JSON [RFC8259]
135 object: a data structure as defined by JSON [RFC8259]
137 object class: the definition of members that may be found in JSON
138 objects described in this document
140 object instance: an instantiation or specific instance of an object
143 RDAP: Registration Data Access Protocol
145 RIR: Regional Internet Registry
149 The data model for JSON responses is specified in five sections:
151 1. simple data types conveyed in JSON primitive types (strings,
152 numbers, booleans, and null)
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
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:
187 2. Autonomous System numbers
189 Object classes defined in this document represent a minimal set of
190 what a compliant client/server needs to understand to function
191 correctly; however, some deployments may want to include additional
192 object classes to suit individual needs. Anticipating this need for
193 extension, Section 2.1 of this document defines a mechanism for
194 extending the JSON objects that are described in this document.
196 Positive responses take two forms. A response to a lookup of a
197 single object in the registration system yields a JSON object, which
198 is the subject of the lookup. A response to a search for multiple
199 objects yields a JSON object that contains an array of JSON objects
200 that are the subject of the search. In each type of response, other
201 data structures are present within the topmost JSON object.
207 Clients of these JSON responses SHOULD ignore unrecognized JSON
208 members in responses. Servers can insert members into the JSON
209 responses, which are not specified in this document, but that does
210 not constitute an error in the response. Servers that insert such
211 unspecified members into JSON responses SHOULD have member names
212 prefixed with a short identifier followed by an underscore followed
213 by a meaningful name. It has been observed that these short
214 identifiers aid software implementers with identifying the
215 specification of the JSON member, and failure to use one could cause
216 an implementer to assume the server is erroneously using a name from
217 this specification. This allowance does not apply to jCard [RFC7095]
218 objects. The full JSON name (the prefix plus the underscore plus the
219 meaningful name) SHOULD adhere to the character and name limitations
220 of the prefix registry described in [RFC7480]. Failure to use these
221 limitations could result in slower adoption as these limitations have
222 been observed to aid some client programming models.
224 Consider the following JSON response with JSON members, all of which
225 are specified in this document.
234 "She sells sea shells down by the sea shore.",
235 "Originally written by Terry Sullivan."
243 If The Registry of the Moon desires to express information not found
244 in this specification, it might select "lunarNIC" as its identifying
245 prefix and insert, as an example, the member named
246 "lunarNIC_beforeOneSmallStep" to signify registrations occurring
247 before the first moon landing and the member named
248 "lunarNIC_harshMistressNotes" that contains other descriptive text.
250 Consider the following JSON response with JSON names, some of which
251 should be ignored by clients without knowledge of their meaning.
255 "lunarNIC_beforeOneSmallStep" : "TRUE THAT!",
261 "She sells sea shells down by the sea shore.",
262 "Originally written by Terry Sullivan."
266 "lunarNIC_harshMistressNotes" :
269 "nobody can hear you scream."
275 Insertion of unrecognized members ignored by clients may also be used
276 for future revisions to this specification.
278 Clients processing JSON responses need to be prepared for members
279 representing registration data specified in this document to be
280 absent from a response. In other words, servers are free to omit
281 unrequired/optional JSON members containing registration data based
282 on their own policies.
285 sensitive. Both servers and clients MUST transmit and process them
286 using the specified character case.
290 JSON [RFC8259] defines the data types of a number, character string,
291 boolean, array, object, and null. This section describes the
292 semantics and/or syntax reference for common, JSON character strings
293 used in this document.
295 handle: DNRs and RIRs have registry-unique identifiers that
296 may be used to specifically reference an object
297 instance. The semantics of this data type as found
298 in this document are to be a registry-unique
299 reference to the closest enclosing object where the
300 value is found. The data type names "registryId",
301 "roid", "nic-handle", "registrationNo", etc., are
302 terms often synonymous with this data type. In
303 this document, the term "handle" is used. The term
304 exposed to users by clients is a presentation issue
305 beyond the scope of this document. This value is a
306 simple character string.
308 IPv4 addresses: The representation of IPv4 addresses in this
309 document uses the dotted-decimal notation. An
310 example of this textual representation is
313 IPv6 addresses: The representation of IPv6 addresses in this
314 document follow the forms outlined in [RFC5952].
315 An example of this textual representation is
318 country codes: Where the identity of a geopolitical nation or
319 country is needed, these identities are represented
320 with the alpha-2 or two-character country code
321 designation as defined in [ISO.3166.2020]. The
322 alpha-2 representation is used because it is freely
323 available, whereas the alpha-3 and numeric-3
326 LDH names: Textual representations of DNS names where the
327 labels of the domain are all "letters, digits,
328 hyphen" labels as described by [RFC5890]. Trailing
329 periods are optional.
331 Unicode names: Textual representations of DNS names where one or
332 more of the labels are U-labels as described by
333 [RFC5890]. Trailing periods are optional.
335 dates and times: The syntax for values denoting dates and times is
336 defined in [RFC3339].
338 URIs: The syntax for values denoting a Uniform Resource
339 Identifier (URI) is defined by [RFC3986].
341 Contact information is defined using jCards as described in
342 [RFC7095]. The "fn" member is required and MUST NOT be null
343 according to [RFC6350]. An empty "fn" member MAY be used when the
344 contact name does not exist or is redacted.
3464. Common Data Structures
348 This section defines common data structures used in responses and
353 The data structure named "rdapConformance" is an array of strings,
354 each providing a hint as to the specifications used in the
355 construction of the response. This data structure MUST appear in the
356 topmost JSON object of a response and MUST NOT appear anywhere else.
357 A response to a "help" request will include identifiers for all of
358 the specifications supported by the server. A response to any other
359 request will include only identifiers for the specifications used in
360 the construction of the response. The set of returned identifiers
361 MAY vary depending on the authorization level of the client.
363 An example rdapConformance data structure:
372 The string literal "rdap_level_0" signifies conformance with this
373 specification. When custom JSON values are inserted into responses,
374 conformance to those custom specifications MUST be indicated by
375 including a unique string literal value registered in the IANA RDAP
376 Extensions registry specified in [RFC7480]. For example, if the
377 fictional Registry of the Moon wants to signify that their JSON
378 responses are conformant with their registered extensions, the string
379 used might be "lunarNIC_level_0". These registered values aid the
380 identification of specifications for software implementers, and
381 failure to use them could result in slower adoption of extensions.
383 Example rdapConformance structure with custom extensions noted:
395 The "links" array is found in data structures to signify links to
396 other resources on the Internet. The relationship of these links is
397 defined by the IANA registry described by [RFC8288].
399 The following is an example of the link structure:
402 "value" : "https://example.com/context_uri",
404 "href" : "https://example.com/target_uri",
405 "hreflang" : [ "en", "ch" ],
408 "type" : "application/json"
413 The JSON name/values of "rel", "href", "hreflang", "title", "media",
414 and "type" correspond to values found in Section 3 of [RFC8288]. The
415 "value" JSON value is the context URI as described by [RFC8288]. The
416 "value", "rel", and "href" JSON values MUST be specified. All other
417 JSON values are OPTIONAL. A "related" link relation MUST NOT include
418 an "href" URI that is the same as the "self" link relation "href" URI
419 to reduce the risk of infinite client processing loops.
420 Internationalized Domain Names (IDNs) returned in URIs SHOULD be
421 consistently returned in LDH name format to allow clients to process
422 these IDNs according to their capabilities.
424 This is an example of the "links" array as it might be found in an
430 "value" : "https://example.com/ip/2001:db8::123",
432 "href" : "https://example.com/ip/2001:db8::123",
433 "type" : "application/rdap+json"
436 "value" : "https://example.com/ip/2001:db8::123",
438 "href" : "https://example.com/ip/2001:db8::/48",
439 "type" : "application/rdap+json"
4464.3. Notices and Remarks
448 The "notices" and "remarks" data structures take the same form. The
449 notices structure denotes information about the service providing
450 RDAP information and/or information about the entire response,
451 whereas the remarks structure denotes information about the object
452 class that contains it (see Section 5 regarding object classes).
454 Both are arrays of objects. Each object contains a "title" string
455 representing the title of the object, a "type" string denoting a
456 registered type of remark or notice (see Section 10.2.1), an array of
457 strings named "description" for the purposes of conveying any
458 descriptive text, and a "links" array as described in Section 4.2.
459 The "description" array MUST be included. All other JSON values are
462 An example of the notices data structure:
467 "title" : "Terms of Use",
470 "Service subject to The Registry of the Moon's TOS.",
471 "Copyright (c) 2020 LunarNIC"
476 "value" : "https://example.net/entity/XXXX",
478 "type" : "text/html",
479 "href" : "https://www.example.com/terms_of_use.html"
487 It is the job of the clients to determine line breaks, spacing, and
488 display issues for sentences within the character strings of the
489 "description" array. Each string in the "description" array contains
490 a single complete division of human-readable text indicating to
491 clients where there are semantic breaks.
493 An example of the remarks data structure:
500 "She sells sea shells down by the sea shore.",
501 "Originally written by Terry Sullivan."
508 Note that objects in the "remarks" array may also have a "links"
511 While the "title" and "description" fields are intended primarily for
512 human consumption, the "type" string contains a well-known value to
513 be registered with IANA (see Section 10.2.1) for programmatic use.
515 An example of the remarks data structure:
520 "type" : "object truncated due to authorization",
523 "Some registration data may not have been given.",
524 "Use proper authorization credentials to see all of it."
531 While the "remarks" array will appear in many object classes in a
532 response, the "notices" array appears only in the topmost object of a
5354.4. Language Identifier
537 This data structure consists solely of a name/value pair, where the
538 name is "lang" and the value is a string containing a language
539 identifier as described in [RFC5646].
541 "lang" : "mn-Cyrl-MN"
545 The "lang" attribute as defined in this section MAY appear anywhere
546 in an object class or data structure, except for in jCard objects.
547 vCard supports similar functionality by way of the LANGUAGE property
548 parameter (see Section 5.1 of RFC 6350 [RFC6350]).
552 This data structure represents events that have occurred on an
553 instance of an object class (see Section 5 regarding object classes).
555 This is an example of an "events" array.
560 "eventAction" : "registration",
561 "eventActor" : "SOMEID-LUNARNIC",
562 "eventDate" : "1990-12-31T23:59:59Z"
565 "eventAction" : "last changed",
566 "eventActor" : "OTHERID-LUNARNIC",
567 "eventDate" : "1991-12-31T23:59:59Z"
576 * "eventAction" -- a REQUIRED string denoting the reason for the
579 * "eventActor" -- an OPTIONAL identifier denoting the actor
580 responsible for the event
582 * "eventDate" -- a REQUIRED string containing the time and date the
585 * "links" -- OPTIONAL; see Section 4.2
587 Events can be future dated. One use case for future dating of events
588 is to denote when an object expires from a registry.
590 The "links" array in this data structure is provided for references
591 to the event actor. In order to reference an RDAP entity, a "rel" of
592 "related" and a "type" of "application/rdap+json" is used in the link
595 See Section 10.2.3 for a list of values for the "eventAction" string.
596 See Appendix B regarding the various ways events can be modeled.
600 This data structure, named "status", is an array of strings
601 indicating the state of a registered object (see Section 10.2.2 for a
6044.7. Port 43 WHOIS Server
606 This data structure, a member named "port43", is a simple character
607 string containing the fully qualified host name or IP address of the
608 WHOIS [RFC3912] server where the containing object instance may be
609 found. Note that this is not a URI, as there is no WHOIS URI scheme.
613 This data structure maps a public identifier to an object class. It
614 is named "publicIds" and is an array of objects, with each object
615 containing the following REQUIRED members:
617 * type -- a string denoting the type of public identifier
619 * identifier -- a string denoting a public identifier of the type
622 The following is an example of a publicIds structure.
627 "type":"IANA Registrar ID",
6344.9. Object Class Name
636 This data structure, a member named "objectClassName", gives the
637 object class name of a particular object as a string. This
638 identifies the type of object being processed. An objectClassName is
639 REQUIRED in all RDAP response objects so that the type of the object
644 This is an example response with both rdapConformance and notices
655 "title" : "Content Removed",
658 "Without full authorization, content has been removed.",
664 "value" : "https://example.net/ip/192.0.2.0/24",
666 "type" : "text/html",
667 "href" : "https://www.example.com/redaction_policy.html"
673 "objectClassName" : "ip network",
674 "startAddress" : "192.0.2.0",
675 "endAddress" : "192.0.2.255",
676 "handle" : "XXXX-RIR",
679 "parentHandle" : "YYYY-RIR",
686 "She sells sea shells down by the sea shore.",
687 "Originally written by Terry Sullivan."
697 Object classes represent structures appropriate for a response from
698 the queries specified in [RFC9082].
700 Each object class contains a "links" array as specified in
701 Section 4.2. For every object class instance in a response, whether
702 the object class instance is directly representing the response to a
703 query or is embedded in other object class instances or is an item in
704 a search result set, servers SHOULD provide a link representing a URI
705 for that object class instance using the "self" relationship as
706 described in the IANA registry specified by [RFC8288]. As explained
707 in Section 5.2, this may be not always be possible for nameserver
708 data. Clients MUST be able to process object instances without a
709 self link. When present, clients can use the self link for caching
710 data. Servers MAY provide more than one self link for any given
711 object instance. Failure to provide any self link by a server may
712 result in clients being unable to cache object class instances.
714 Clients using self links for caching SHOULD NOT cache any object
715 class instances where the authority of the self link is different
716 than the authority of the server returning the data. Failing to do
717 so might result in cache poisoning.
719 Self links MUST contain a "type" element containing the "application/
720 rdap+json" media type when referencing RDAP object instances as
721 defined by this document.
723 This is an example of the "links" array with a self link to an object
729 "value" : "https://example.com/ip/2001:db8::123",
731 "href" : "https://example.com/ip/2001:db8::123",
732 "type" : "application/rdap+json"
7385.1. The Entity Object Class
740 The entity object class appears throughout this document and is an
741 appropriate response for the /entity/XXXX query defined in
742 "Registration Data Access Protocol (RDAP) Query Format" [RFC9082].
743 This object class represents the information of organizations,
744 corporations, governments, non-profits, clubs, individual persons,
745 and informal groups of people. All of these representations are so
746 similar that it is best to represent them in JSON [RFC8259] with one
747 construct, the entity object class, to aid in the reuse of code by
750 The entity object class uses jCard [RFC7095] to represent contact
751 information, such as postal addresses, email addresses, phone numbers
752 and names of organizations and individuals. Many of the types of
753 information that can be represented with jCard have little or no use
754 in RDAP, such as birthdays, anniversaries, and gender.
756 The entity object is served by both RIRs and DNRs. The following is
757 an example of an entity that might be served by an RIR.
760 "objectClassName" : "entity",
765 ["version", {}, "text", "4.0"],
766 ["fn", {}, "text", "Joe User"],
768 ["User", "Joe", "", "", ["ing. jr", "M.Sc."]]
770 ["kind", {}, "text", "individual"],
773 }, "language-tag", "fr"],
776 }, "language-tag", "en"],
779 }, "text", "Example"],
780 ["title", {}, "text", "Research Scientist"],
781 ["role", {}, "text", "Project Lead"],
788 "4321 Rue Somewhere",
798 "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n"
802 "", "", "", "", "", "", ""
807 "type":["work", "voice"],
811 "tel:+1-555-555-1234;ext=102"
814 { "type":["work", "cell", "voice", "video", "text"] },
816 "tel:+1-555-555-4321"
821 "joe.user@example.com"
825 }, "uri", "geo:46.772673,-71.282945"],
829 "https://www.example.com/joe.user/joe.asc"
832 "utc-offset", "-05:00"],
833 ["url", { "type":"home" },
834 "uri", "https://example.org"]
837 "roles":[ "registrar" ],
840 "type":"IANA Registrar ID",
847 "She sells sea shells down by the sea shore.",
848 "Originally written by Terry Sullivan."
854 "value":"https://example.com/entity/XXXX",
856 "href":"https://example.com/entity/XXXX",
857 "type" : "application/rdap+json"
862 "eventAction":"registration",
863 "eventDate":"1990-12-31T23:59:59Z"
869 "eventAction":"last changed",
870 "eventDate":"1991-12-31T23:59:59Z"
877 The entity object class can contain the following members:
879 * objectClassName -- the string "entity"
881 * handle -- a string representing a registry-unique identifier of
884 * vcardArray -- a jCard with the entity's contact information
886 * roles -- an array of strings, each signifying the relationship an
887 object would have with its closest containing object (see
888 Section 10.2.4 for a list of values)
890 * publicIds -- see Section 4.8
892 * entities -- an array of entity objects as defined by this section
894 * remarks -- see Section 4.3
896 * links -- see Section 4.2
898 * events -- see Section 4.5
900 * asEventActor -- this data structure takes the same form as the
901 events data structure (see Section 4.5), but each object in the
902 array MUST NOT have an "eventActor" member. These objects denote
903 that the entity is an event actor for the given events. See
904 Appendix B regarding the various ways events can be modeled.
906 * status -- see Section 4.6
908 * port43 -- see Section 4.7
910 * networks -- an array of IP network objects as defined in
913 * autnums -- an array of autnum objects as defined in Section 5.5
915 Entities may also have other entities embedded with them in an array.
916 This can be used to model an organization with specific individuals
917 fulfilling designated roles of responsibility.
919 The following is an elided example of an entity with embedded
923 "objectClassName" : "entity",
924 "handle" : "ANENTITY",
925 "roles" : [ "registrar" ],
930 "objectClassName" : "entity",
931 "handle": "ANEMBEDDEDENTITY",
932 "roles" : [ "technical" ],
942 The following is an example of an entity that might be served by a
946 "objectClassName" : "entity",
951 ["version", {}, "text", "4.0"],
952 ["fn", {}, "text", "Joe User"],
953 ["kind", {}, "text", "individual"],
956 }, "language-tag", "fr"],
959 }, "language-tag", "en"],
962 }, "text", "Example"],
963 ["title", {}, "text", "Research Scientist"],
964 ["role", {}, "text", "Project Lead"],
971 "4321 Rue Somewhere",
979 { "type":["work", "voice"], "pref":"1" },
980 "uri", "tel:+1-555-555-1234;ext=102"
984 "text", "joe.user@example.com"
988 "status":[ "validated", "locked" ],
992 "She sells sea shells down by the sea shore.",
993 "Originally written by Terry Sullivan."
999 "value":"https://example.com/entity/XXXX",
1001 "href":"https://example.com/entity/XXXX",
1002 "type":"application/rdap+json"
1005 "port43":"whois.example.net",
1008 "eventAction":"registration",
1009 "eventDate":"1990-12-31T23:59:59Z"
1012 "eventAction":"last changed",
1013 "eventDate":"1991-12-31T23:59:59Z",
1014 "eventActor":"joe@example.com"
1021 See Appendix A for use of the entity object class to model various
1022 types of entities found in both RIRs and DNRs. See Appendix C
1023 regarding structured vs. unstructured postal addresses in entities.
10255.2. The Nameserver Object Class
1027 The nameserver object class represents information regarding DNS
1028 nameservers used in both forward and reverse DNS. RIRs and some DNRs
1029 register or expose nameserver information as an attribute of a domain
1030 name, while other DNRs model nameservers as "first class objects".
1031 Please note that some of the examples in this section include lines
1032 that have been wrapped for reading clarity.
1034 The nameserver object class accommodates both models and degrees of
1035 variation in between.
1037 The following is an example of a nameserver object.
1040 "objectClassName" : "nameserver",
1042 "ldhName" : "ns1.xn--fo-5ja.example",
1043 "unicodeName" : "ns.fóo.example",
1044 "status" : [ "active" ],
1047 "v4": [ "192.0.2.1", "192.0.2.2" ],
1048 "v6": [ "2001:db8::123" ]
1055 "She sells sea shells down by the sea shore.",
1056 "Originally written by Terry Sullivan."
1063 "value" : "https://example.net/nameserver/
1064 ns1.xn--fo-5ja.example",
1066 "href" : "https://example.net/nameserver/
1067 ns1.xn--fo-5ja.example",
1068 "type" : "application/rdap+json"
1071 "port43" : "whois.example.net",
1075 "eventAction" : "registration",
1076 "eventDate" : "1990-12-31T23:59:59Z"
1079 "eventAction" : "last changed",
1080 "eventDate" : "1991-12-31T23:59:59Z",
1081 "eventActor" : "joe@example.com"
1088 Figure 18 is an example of a nameserver object with all appropriate
1089 values given. Registries using a first-class nameserver data model
1090 would embed this in domain objects as well as allowing references to
1091 it with the "/nameserver" query type (all depending on the registry
1092 operators policy). Other registries may pare back the information as
1093 needed. Figure 19 is an example of a nameserver object as would be
1094 found in RIRs and some DNRs, while Figure 20 is an example of a
1095 nameserver object as would be found in other DNRs.
1097 The following is an example of the simplest nameserver object:
1100 "objectClassName" : "nameserver",
1101 "ldhName" : "ns1.example.com"
1106 The following is an example of a simple nameserver object that might
1107 be commonly used by DNRs:
1110 "objectClassName" : "nameserver",
1111 "ldhName" : "ns1.example.com",
1112 "ipAddresses" : { "v6" : [ "2001:db8::123", "2001:db8::124" ] }
1117 As nameservers can be modeled by some registries to be first-class
1118 objects, they may also have an array of entities (Section 5.1)
1119 embedded to signify parties responsible for the maintenance,
1120 registrations, etc., of the nameservers.
1122 The following is an elided example of a nameserver with embedded
1126 "objectClassName" : "nameserver",
1128 "ldhName" : "ns.xn--fo-5ja.example",
1139 The nameserver object class can contain the following members:
1141 * objectClassName -- the string "nameserver"
1143 * handle -- a string representing a registry-unique identifier of
1146 * ldhName -- a string containing the LDH name of the nameserver (see
1149 * unicodeName -- a string containing a DNS Unicode name of the
1150 nameserver (see Section 3)
1152 * ipAddresses -- an object containing the following members:
1154 - v6 -- an array of strings containing IPv6 addresses of the
1157 - v4 -- an array of strings containing IPv4 addresses of the
1160 * entities -- an array of entity objects as defined by Section 5.1
1162 * status -- see Section 4.6
1164 * remarks -- see Section 4.3
1166 * links -- see Section 4.2
1168 * port43 -- see Section 4.7
1170 * events -- see Section 4.5
1174 The domain object class represents a DNS name and point of
1175 delegation. For RIRs, these delegation points are in the reverse DNS
1176 tree, whereas for DNRs, these delegation points are in the forward
1179 In both cases, the high-level structure of the domain object class
1180 consists of information about the domain registration, nameserver
1181 information related to the domain name, and entities related to the
1182 domain name (e.g., registrant information, contacts, etc.).
1184 The following is an elided example of the domain object showing the
1185 high-level structure:
1188 "objectClassName" : "domain",
1190 "ldhName" : "blah.example.com",
1205 The domain object class can contain the following members:
1208 * objectClassName -- the string "domain"
1210 * handle -- a string representing a registry-unique identifier of
1211 the domain object instance
1213 * ldhName -- a string describing a domain name in LDH form as
1214 described in Section 3
1216 * unicodeName -- a string containing a domain name with U-labels as
1217 described in Section 3
1219 * variants -- an array of objects, each containing the following
1222 - relation -- an array of strings, with each string denoting the
1223 relationship between the variants and the containing domain
1224 object (see Section 10.2.5 for a list of suggested variant
1227 - idnTable -- the character string literal that represents the
1228 Internationalized Domain Name (IDN) table that has been
1229 registered in the IANA Repository of IDN Practices
1232 - variantNames -- an array of objects, with each object
1233 containing an "ldhName" member and a "unicodeName" member (see
1236 * nameservers -- an array of nameserver objects as defined by
1239 * secureDNS -- an object with the following members:
1241 - zoneSigned -- boolean true if the zone has been signed, false
1244 - delegationSigned -- boolean true if there are DS records in the
1245 parent, false otherwise.
1247 - maxSigLife -- an integer representing the signature lifetime in
1248 seconds to be used when creating the RRSIG DS record in the
1249 parent zone [RFC5910].
1251 - dsData -- an array of objects, each with the following members:
1253 o keyTag -- an integer as specified by the key tag field of a
1254 DNS DS record as specified by [RFC4034] in presentation
1257 o algorithm -- an integer as specified by the algorithm field
1258 of a DNS DS record as described by RFC 4034 in presentation
1261 o digest -- a string as specified by the digest field of a DNS
1262 DS record as specified by RFC 4034 in presentation format
1264 o digestType -- an integer as specified by the digest type
1265 field of a DNS DS record as specified by RFC 4034 in
1268 o events -- see Section 4.5
1270 o links -- see Section 4.2
1272 - keyData -- an array of objects, each with the following
1275 o flags -- an integer representing the flags field value in
1276 the DNSKEY record [RFC4034] in presentation format
1278 o protocol -- an integer representation of the protocol field
1279 value of the DNSKEY record [RFC4034] in presentation format
1281 o publicKey -- a string representation of the public key in
1282 the DNSKEY record [RFC4034] in presentation format
1284 o algorithm -- an integer as specified by the algorithm field
1285 of a DNSKEY record as specified by [RFC4034] in presentation
1288 o events -- see Section 4.5
1290 o links -- see Section 4.2
1292 See Appendix D for background information on these objects.
1294 * entities -- an array of entity objects as defined by Section 5.1
1296 * status -- see Section 4.6
1298 * publicIds -- see Section 4.8
1300 * remarks -- see Section 4.3
1302 * links -- see Section 4.2
1304 * port43 -- see Section 4.7
1306 * events -- see Section 4.5
1308 * network -- represents the IP network for which a reverse DNS
1309 domain is referenced; see Section 5.4
1311 The following is an example of a JSON domain object representing a
1312 reverse DNS delegation point that might be served by an RIR (note
1313 that the dsData digest value has been modified to fit on one line).
1316 "objectClassName" : "domain",
1318 "ldhName" : "0.2.192.in-addr.arpa",
1322 "objectClassName" : "nameserver",
1323 "ldhName" : "ns1.rir.example"
1326 "objectClassName" : "nameserver",
1327 "ldhName" : "ns2.rir.example"
1332 "delegationSigned": true,
1339 "digest": "2788970E18EA14...C890C85B8205B94"
1348 "She sells sea shells down by the sea shore.",
1349 "Originally written by Terry Sullivan."
1356 "value": "https://example.net/domain/0.2.192.in-addr.arpa",
1358 "href" : "https://example.net/domain/0.2.192.in-addr.arpa",
1359 "type" : "application/rdap+json"
1366 "eventAction" : "registration",
1367 "eventDate" : "1990-12-31T23:59:59Z"
1370 "eventAction" : "last changed",
1371 "eventDate" : "1991-12-31T23:59:59Z",
1372 "eventActor" : "joe@example.com"
1378 "objectClassName" : "entity",
1383 ["version", {}, "text", "4.0"],
1384 ["fn", {}, "text", "Joe User"],
1385 ["kind", {}, "text", "individual"],
1388 }, "language-tag", "fr"],
1391 }, "language-tag", "en"],
1394 }, "text", "Example"],
1395 ["title", {}, "text", "Research Scientist"],
1396 ["role", {}, "text", "Project Lead"],
1403 "4321 Rue Somewhere",
1412 { "type":["work", "voice"], "pref":"1" },
1413 "uri", "tel:+1-555-555-1234;ext=102"
1417 "text", "joe.user@example.com"
1421 "roles" : [ "registrant" ],
1427 "She sells sea shells down by the sea shore.",
1428 "Originally written by Terry Sullivan."
1435 "value": "https://example.net/entity/XXXX",
1437 "href" : "https://example.net/entity/XXXX",
1438 "type" : "application/rdap+json"
1444 "eventAction" : "registration",
1445 "eventDate" : "1990-12-31T23:59:59Z"
1448 "eventAction" : "last changed",
1449 "eventDate" : "1991-12-31T23:59:59Z",
1450 "eventActor" : "joe@example.com"
1457 "objectClassName" : "ip network",
1458 "handle" : "XXXX-RIR",
1459 "startAddress" : "192.0.2.0",
1460 "endAddress" : "192.0.2.255",
1462 "name": "NET-RTR-1",
1463 "type" : "DIRECT ALLOCATION",
1465 "parentHandle" : "YYYY-RIR",
1466 "status" : [ "active" ]
1472 The following is an example of a JSON domain object representing a
1473 forward DNS delegation point that might be served by a DNR. Note
1474 that the secureDNS keyData publicKey value has been modified to fit
1478 "objectClassName" : "domain",
1480 "ldhName" : "xn--fo-5ja.example",
1481 "unicodeName" : "fóo.example",
1485 "relation" : [ "registered", "conjoined" ],
1489 "ldhName" : "xn--fo-cka.example",
1490 "unicodeName" : "fõo.example"
1493 "ldhName" : "xn--fo-fka.example",
1494 "unicodeName" : "föo.example"
1499 "relation" : [ "unregistered", "registration restricted" ],
1500 "idnTable": ".EXAMPLE Swedish",
1504 "ldhName": "xn--fo-8ja.example",
1505 "unicodeName" : "fôo.example"
1511 "status" : [ "locked", "transfer prohibited" ],
1514 "type":"ENS_Auth ID",
1515 "identifier":"1234567890"
1521 "objectClassName" : "nameserver",
1523 "ldhName" : "ns1.example.com",
1524 "status" : [ "active" ],
1527 "v6": [ "2001:db8::123", "2001:db8::124" ],
1528 "v4": [ "192.0.2.1", "192.0.2.2" ]
1535 "She sells sea shells down by the sea shore.",
1536 "Originally written by Terry Sullivan."
1543 "value" : "https://example.net/nameserver/ns1.example.com",
1545 "href" : "https://example.net/nameserver/ns1.example.com",
1546 "type" : "application/rdap+json"
1552 "eventAction" : "registration",
1553 "eventDate" : "1990-12-31T23:59:59Z"
1556 "eventAction" : "last changed",
1557 "eventDate" : "1991-12-31T23:59:59Z"
1562 "objectClassName" : "nameserver",
1564 "ldhName" : "ns2.example.com",
1565 "status" : [ "active" ],
1568 "v6" : [ "2001:db8::125", "2001:db8::126" ],
1569 "v4" : [ "192.0.2.3", "192.0.2.4" ]
1576 "She sells sea shells down by the sea shore.",
1577 "Originally written by Terry Sullivan."
1584 "value" : "https://example.net/nameserver/ns2.example.com",
1586 "href" : "https://example.net/nameserver/ns2.example.com",
1587 "type" : "application/rdap+json"
1593 "eventAction" : "registration",
1594 "eventDate" : "1990-12-31T23:59:59Z"
1597 "eventAction" : "last changed",
1598 "eventDate" : "1991-12-31T23:59:59Z"
1607 "delegationSigned": true,
1608 "maxSigLife": 604800,
1615 "publicKey": "AwEAAa6eDzronzjEDbT...Jg1M5N rBSPkuXpdFE=",
1619 "eventAction": "last changed",
1620 "eventDate": "2012-07-23T05:15:47Z"
1631 "She sells sea shells down by the sea shore.",
1632 "Originally written by Terry Sullivan."
1639 "value": "https://example.net/domain/xn--fo-5ja.example",
1641 "href" : "https://example.net/domain/xn--fo-5ja.example",
1642 "type" : "application/rdap+json"
1645 "port43" : "whois.example.net",
1649 "eventAction" : "registration",
1650 "eventDate" : "1990-12-31T23:59:59Z"
1653 "eventAction" : "last changed",
1654 "eventDate" : "1991-12-31T23:59:59Z",
1655 "eventActor" : "joe@example.com"
1658 "eventAction" : "transfer",
1659 "eventDate" : "1991-12-31T23:59:59Z",
1660 "eventActor" : "joe@example.com"
1663 "eventAction" : "expiration",
1664 "eventDate" : "2016-12-31T23:59:59Z",
1665 "eventActor" : "joe@example.com"
1671 "objectClassName" : "entity",
1676 ["version", {}, "text", "4.0"],
1677 ["fn", {}, "text", "Joe User"],
1678 ["kind", {}, "text", "individual"],
1681 }, "language-tag", "fr"],
1684 }, "language-tag", "en"],
1687 }, "text", "Example"],
1688 ["title", {}, "text", "Research Scientist"],
1689 ["role", {}, "text", "Project Lead"],
1696 "4321 Rue Somewhere",
1705 { "type":["work", "voice"], "pref":"1" },
1706 "uri", "tel:+1-555-555-1234;ext=102"
1710 "text", "joe.user@example.com"
1714 "status" : [ "validated", "locked" ],
1715 "roles" : [ "registrant" ],
1721 "She sells sea shells down by the sea shore.",
1722 "Originally written by Terry Sullivan."
1729 "value" : "https://example.net/entity/XXXX",
1731 "href" : "https://example.net/entity/XXXX",
1732 "type" : "application/rdap+json"
1738 "eventAction" : "registration",
1739 "eventDate" : "1990-12-31T23:59:59Z"
1742 "eventAction" : "last changed",
1743 "eventDate" : "1991-12-31T23:59:59Z"
17525.4. The IP Network Object Class
1754 The IP network object class models IP network registrations found in
1755 RIRs and is the expected response for the "/ip" query as defined by
1756 [RFC9082]. There is no equivalent object class for DNRs. The high-
1757 level structure of the IP network object class consists of
1758 information about the network registration and entities related to
1759 the IP network (e.g., registrant information, contacts, etc.).
1761 The following is an elided example of the IP network object type
1762 showing the high-level structure:
1765 "objectClassName" : "ip network",
1776 The following is an example of the JSON object for the network
1777 registration information.
1780 "objectClassName" : "ip network",
1781 "handle" : "XXXX-RIR",
1782 "startAddress" : "2001:db8::",
1783 "endAddress" : "2001:db8:0:ffff:ffff:ffff:ffff:ffff",
1785 "name": "NET-RTR-1",
1786 "type" : "DIRECT ALLOCATION",
1788 "parentHandle" : "YYYY-RIR",
1789 "status" : [ "active" ],
1795 "She sells sea shells down by the sea shore.",
1796 "Originally written by Terry Sullivan."
1803 "value" : "https://example.net/ip/2001:db8::/48",
1805 "href" : "https://example.net/ip/2001:db8::/48",
1806 "type" : "application/rdap+json"
1809 "value" : "https://example.net/ip/2001:db8::/48",
1811 "href" : "https://example.net/ip/2001:db8::/32",
1812 "type" : "application/rdap+json"
1818 "eventAction" : "registration",
1819 "eventDate" : "1990-12-31T23:59:59Z"
1822 "eventAction" : "last changed",
1823 "eventDate" : "1991-12-31T23:59:59Z"
1829 "objectClassName" : "entity",
1834 ["version", {}, "text", "4.0"],
1835 ["fn", {}, "text", "Joe User"],
1836 ["kind", {}, "text", "individual"],
1839 }, "language-tag", "fr"],
1842 }, "language-tag", "en"],
1845 }, "text", "Example"],
1846 ["title", {}, "text", "Research Scientist"],
1847 ["role", {}, "text", "Project Lead"],
1854 "4321 Rue Somewhere",
1862 { "type":["work", "voice"], "pref":"1" },
1863 "uri", "tel:+1-555-555-1234;ext=102"
1867 "text", "joe.user@example.com"
1871 "roles" : [ "registrant" ],
1877 "She sells sea shells down by the sea shore.",
1878 "Originally written by Terry Sullivan."
1885 "value" : "https://example.net/entity/xxxx",
1887 "href" : "https://example.net/entity/xxxx",
1888 "type" : "application/rdap+json"
1894 "eventAction" : "registration",
1895 "eventDate" : "1990-12-31T23:59:59Z"
1899 "eventAction" : "last changed",
1900 "eventDate" : "1991-12-31T23:59:59Z"
1909 The IP network object class can contain the following members:
1911 * objectClassName -- the string "ip network"
1913 * handle -- a string representing the RIR-unique identifier of the
1914 network registration
1916 * startAddress -- a string representing the starting IP address of
1917 the network, either IPv4 or IPv6
1919 * endAddress -- a string representing the ending IP address of the
1920 network, either IPv4 or IPv6
1922 * ipVersion -- a string signifying the IP protocol version of the
1923 network: "v4" signifies an IPv4 network, and "v6" signifies an
1926 * name -- a string representing an identifier assigned to the
1927 network registration by the registration holder
1929 * type -- a string containing an RIR-specific classification of the
1930 network per that RIR's registration model
1932 * country -- a string containing the two-character country code of
1935 * parentHandle -- a string containing an RIR-unique identifier of
1936 the parent network of this network registration
1938 * status -- an array of strings indicating the state of the IP
1939 network as defined by Section 4.6
1941 * entities -- an array of entity objects as defined by Section 5.1
1943 * remarks -- see Section 4.3
1945 * links -- see Section 4.2
1947 * port43 -- see Section 4.7
1949 * events -- see Section 4.5
19515.5. The Autonomous System Number Object Class
1953 The Autonomous System number (autnum) object class models Autonomous
1954 System number registrations found in RIRs and represents the expected
1955 response to an "/autnum" query as defined by [RFC9082]. There is no
1956 equivalent object class for DNRs. The high-level structure of the
1957 autnum object class consists of information about the Autonomous
1958 System number registration and entities related to the autnum
1959 registration (e.g., registrant information, contacts, etc.) and is
1960 similar to the IP network object class.
1962 The following is an example of a JSON object representing an autnum.
1965 "objectClassName" : "autnum",
1966 "handle" : "XXXX-RIR",
1967 "startAutnum" : 65536,
1968 "endAutnum" : 65541,
1970 "type" : "DIRECT ALLOCATION",
1971 "status" : [ "active" ],
1978 "She sells sea shells down by the sea shore.",
1979 "Originally written by Terry Sullivan."
1986 "value" : "https://example.net/autnum/65537",
1988 "href" : "https://example.net/autnum/65537",
1989 "type" : "application/rdap+json"
1996 "eventAction" : "registration",
1997 "eventDate" : "1990-12-31T23:59:59Z"
2000 "eventAction" : "last changed",
2001 "eventDate" : "1991-12-31T23:59:59Z"
2007 "objectClassName" : "entity",
2012 ["version", {}, "text", "4.0"],
2013 ["fn", {}, "text", "Joe User"],
2014 ["kind", {}, "text", "individual"],
2017 }, "language-tag", "fr"],
2020 }, "language-tag", "en"],
2023 }, "text", "Example"],
2024 ["title", {}, "text", "Research Scientist"],
2025 ["role", {}, "text", "Project Lead"],
2032 "4321 Rue Somewhere",
2040 { "type":["work", "voice"], "pref":"1" },
2041 "uri", "tel:+1-555-555-1234;ext=102"
2045 "text", "joe.user@example.com"
2049 "roles" : [ "registrant" ],
2055 "She sells sea shells down by the sea shore.",
2056 "Originally written by Terry Sullivan."
2063 "value" : "https://example.net/entity/XXXX",
2065 "href" : "https://example.net/entity/XXXX",
2066 "type" : "application/rdap+json"
2072 "eventAction" : "registration",
2073 "eventDate" : "1990-12-31T23:59:59Z"
2076 "eventAction" : "last changed",
2077 "eventDate" : "1991-12-31T23:59:59Z"
2086 The Autonomous System number object class can contain the following
2089 * objectClassName -- the string "autnum"
2091 * handle -- a string representing the RIR-unique identifier of the
2094 * startAutnum -- an unsigned 32-bit integer representing the
2095 starting number [RFC5396] in the block of Autonomous System
2098 * endAutnum -- an unsigned 32-bit integer representing the ending
2099 number [RFC5396] in the block of Autonomous System numbers
2101 * name -- a string representing an identifier assigned to the autnum
2102 registration by the registration holder
2104 * type -- a string containing an RIR-specific classification of the
2105 autnum per that RIR's registration model
2107 * status -- an array of strings indicating the state of the autnum
2108 as defined by Section 4.6
2110 * country -- a string containing the two-character country code of
2113 * entities -- an array of entity objects as defined by Section 5.1
2115 * remarks -- see Section 4.3
2117 * links -- see Section 4.2
2119 * port43 -- see Section 4.7
2121 * events -- see Section 4.5
2125 Some non-answer responses MAY return entity bodies with information
2126 that could be more descriptive.
2128 The basic structure of that response is an object class containing a
2129 REQUIRED error code number (corresponding to the HTTP response code)
2130 followed by an OPTIONAL string named "title" and an OPTIONAL array of
2131 strings named "description".
2133 This is an example of the common response body.
2137 "title": "Your Beverage Choice is Not Available",
2140 "I know coffee has more ummppphhh.",
2147 This is an example of the common response body with an
2148 rdapConformance and notices data structures:
2158 "title" : "Beverage Policy",
2161 "Beverages with caffeine for keeping horses awake."
2166 "value" : "https://example.net/ip/192.0.2.0/24",
2167 "rel" : "alternate",
2168 "type" : "text/html",
2169 "href" : "https://www.example.com/redaction_policy.html"
2176 "title": "Your beverage choice is not available",
2179 "I know coffee has more ummppphhh.",
21867. Responding to Help Queries
2188 The appropriate response to /help queries as defined by [RFC9082] is
2189 to use the notices structure as defined in Section 4.3.
2191 This is an example of a response to a /help query including the
2192 rdapConformance data structure.
2202 "title" : "Authentication Policy",
2205 "Access to sensitive data for users with proper credentials."
2210 "value" : "https://example.net/help",
2211 "rel" : "alternate",
2212 "type" : "text/html",
2213 "href" : "https://www.example.com/auth_policy.html"
22228. Responding To Searches
2224 [RFC9082] specifies three types of searches: domains, nameservers,
2225 and entities. Responses to these searches take the form of an array
2226 of object instances where each instance is an appropriate object
2227 class for the search (i.e., a search for /domains yields an array of
2228 domain object instances). These arrays are contained within the
2231 The names of the arrays are as follows:
2233 * for /domains searches, the array is "domainSearchResults"
2235 * for /nameservers searches, the array is "nameserverSearchResults"
2237 * for /entities searches, the array is "entitySearchResults"
2239 The following is an elided example of a response to a /domains
2248 "domainSearchResults" :
2251 "objectClassName" : "domain",
2252 "handle" : "1-XXXX",
2253 "ldhName" : "1.example.com",
2257 "objectClassName" : "domain",
2258 "handle" : "2-XXXX",
2259 "ldhName" : "2.example.com",
22679. Indicating Truncated Responses
2269 In cases where the data of a response needs to be limited or parts of
2270 the data need to be omitted, the response is considered "truncated".
2271 A truncated response is still valid JSON, but some of the results in
2272 a search set or some of the data in an object are not provided by the
2273 server. A server may indicate this by including a typed notice in
2274 the response object.
2276 The following is an elided example of a search response that has been
2287 "title" : "Search Policy",
2288 "type" : "result set truncated due to authorization",
2291 "Search results are limited to 25 per day per querying IP."
2296 "value" : "https://example.net/help",
2297 "rel" : "alternate",
2298 "type" : "text/html",
2299 "href" : "https://www.example.com/search_policy.html"
2304 "domainSearchResults" :
2312 A similar technique can be used with a typed remark where a single
2313 object has been returned and data in that object has been truncated.
2314 Such an example might be an entity object with only a partial set of
2315 the IP networks associated with it.
2317 The following is an elided example of an entity truncated data.
2320 "objectClassName" : "entity",
2321 "handle" : "ANENTITY",
2322 "roles" : [ "registrant" ],
2327 "objectClassName" : "entity",
2328 "handle": "ANEMBEDDEDENTITY",
2329 "roles" : [ "technical" ],
2342 "title" : "Data Policy",
2343 "type" : "object truncated due to unexplainable reason",
2346 "Some of the data in this object has been removed."
2351 "value" : "https://example.net/help",
2352 "rel" : "alternate",
2353 "type" : "text/html",
2354 "href" : "https://www.example.com/data_policy.html"
236310. IANA Considerations
2365 IANA has updated the description of the "transfer" event action as
2366 described in Section 10.2.3.
236810.1. RDAP JSON Media Type Registration
2370 IANA has updated the media type registration as described below.
2374 Type name: application
2376 Subtype name: rdap+json
2378 Required parameters: n/a
2380 Encoding considerations: See Section 3.1 of [RFC6839].
2382 Security considerations: The media represented by this identifier
2383 does not have security considerations beyond that found in
2384 Section 12 of [RFC8259].
2386 Interoperability considerations: There are no known interoperability
2387 problems regarding this media format.
2389 Published specification: RFC 9083
2391 Applications that use this media type: Implementations of the
2392 Registration Data Access Protocol (RDAP).
2394 Additional information: This media type is a product of the IETF
2395 REGEXT Working Group. The REGEXT charter, information on the
2396 REGEXT mailing list, and other documents produced by the REGEXT
2397 Working Group can be found at https://datatracker.ietf.org/wg/
2400 Person & email address to contact for further information:
2401 IESG <iesg@ietf.org>
2403 Intended usage: COMMON
2405 Restrictions on usage: none
2409 Change controller: IETF
2411 Provisional Registration: No
241310.2. JSON Values Registry
2415 IANA has created a category in the protocol registries labeled
2416 "Registration Data Access Protocol (RDAP)", and within that category,
2417 IANA has established a URL-referenceable, stand-alone registry
2418 labeled "RDAP JSON Values". This new registry is for use in the
2419 notices and remarks (Section 4.3), status (Section 4.6), role
2420 (Section 5.1), event action (Section 4.5), and domain variant
2421 relation (Section 5.3) fields specified in RDAP.
2423 Each entry in the registry contains the following fields:
2425 1. Value -- the string value being registered.
2427 2. Type -- the type of value being registered. It should be one of
2430 * "notice or remark type" -- denotes a type of notice or remark.
2432 * "status" -- denotes a value for the "status" object member as
2433 defined by Section 4.6.
2435 * "role" -- denotes a value for the "role" array as defined in
2438 * "event action" -- denotes a value for an event action as
2439 defined in Section 4.5.
2441 * "domain variant relation" -- denotes a relationship between a
2442 domain and a domain variant as defined in Section 5.3.
2444 3. Description -- a one- or two-sentence description regarding the
2445 meaning of the value, how it might be used, and/or how it should
2446 be interpreted by clients.
2448 4. Registrant Name -- the name of the person registering the value.
2450 5. Registrant Contact Information -- an email address, postal
2451 address, or some other information to be used to contact the
2454 This registry is operated under the "Expert Review" policy defined in
2457 Review of registrations into this registry by the designated
2458 expert(s) should be narrowly judged on the following criteria:
2460 1. Values in need of being placed into multiple types must be
2461 assigned a separate registration for each type.
2463 2. Values must be strings. They should be multiple words separated
2464 by single space characters. Every character should be
2465 lowercased. If possible, every word should be given in English
2466 and each character should be US-ASCII.
2468 3. Registrations should not duplicate the meaning of any existing
2469 registration. That is, if a request for a registration is
2470 significantly similar in nature to an existing registration, the
2471 request should be denied. For example, the terms "maintainer"
2472 and "registrant" are significantly similar in nature as they both
2473 denote a holder of a domain name or Internet number resource. In
2474 cases where it may be reasonably argued that machine
2475 interpretation of two similar values may alter the operation of
2476 client software, designated experts should not judge the values
2477 to be of significant similarity.
2479 4. Registrations should be relevant to the common usages of RDAP.
2480 Designated experts may rely upon the serving of the value by a
2481 DNR or RIR to make this determination.
2483 The following sections provide initial registrations into this
248610.2.1. Notice and Remark Types
2488 The following values have been registered in the "RDAP JSON Values"
2491 Value: result set truncated due to authorization
2492 Type: notice and remark type
2493 Description: The list of results does not contain all results due to
2494 lack of authorization. This may indicate to some clients that
2495 proper authorization will yield a longer result set.
2496 Registrant Name: IESG
2497 Registrant Contact Information: iesg@ietf.org
2499 Value: result set truncated due to excessive load
2500 Type: notice and remark type
2501 Description: The list of results does not contain all results due to
2502 an excessively heavy load on the server. This may indicate to
2503 some clients that requerying at a later time will yield a longer
2505 Registrant Name: IESG
2506 Registrant Contact Information: iesg@ietf.org
2508 Value: result set truncated due to unexplainable reasons
2509 Type: notice and remark type
2510 Description: The list of results does not contain all results for an
2511 unexplainable reason. This may indicate to some clients that
2512 requerying for any reason will not yield a longer result set.
2513 Registrant Name: IESG
2514 Registrant Contact Information: iesg@ietf.org
2516 Value: object truncated due to authorization
2517 Type: notice and remark type
2518 Description: The object does not contain all data due to lack of
2520 Registrant Name: IESG
2521 Registrant Contact Information: iesg@ietf.org
2523 Value: object truncated due to excessive load
2524 Type: notice and remark type
2525 Description: The object does not contain all data due to an
2526 excessively heavy load on the server. This may indicate to some
2527 clients that requerying at a later time will yield all data of the
2529 Registrant Name: IESG
2530 Registrant Contact Information: iesg@ietf.org
2532 Value: object truncated due to unexplainable reasons
2533 Type: notice and remark type
2534 Description: The object does not contain all data for an
2535 unexplainable reason.
2536 Registrant Name: IESG
2537 Registrant Contact Information: iesg@ietf.org
2541 The following values have been registered in the "RDAP JSON Values"
2546 Description: Signifies that the data of the object instance has been
2547 found to be accurate. This type of status is usually found on
2548 entity object instances to note the validity of identifying
2549 contact information.
2550 Registrant Name: IESG
2551 Registrant Contact Information: iesg@ietf.org
2553 Value: renew prohibited
2555 Description: Renewal or reregistration of the object instance is
2557 Registrant Name: IESG
2558 Registrant Contact Information: iesg@ietf.org
2560 Value: update prohibited
2562 Description: Updates to the object instance are forbidden.
2563 Registrant Name: IESG
2564 Registrant Contact Information: iesg@ietf.org
2566 Value: transfer prohibited
2568 Description: Transfers of the registration from one registrar to
2569 another are forbidden. This type of status normally applies to
2571 Registrant Name: IESG
2572 Registrant Contact Information: iesg@ietf.org
2574 Value: delete prohibited
2576 Description: Deletion of the registration of the object instance is
2577 forbidden. This type of status normally applies to DNR domain
2579 Registrant Name: IESG
2580 Registrant Contact Information: iesg@ietf.org
2584 Description: The registration of the object instance has been
2585 performed by a third party. This is most commonly applied to
2587 Registrant Name: IESG
2588 Registrant Contact Information: iesg@ietf.org
2592 Description: The information of the object instance is not
2593 designated for public consumption. This is most commonly applied
2595 Registrant Name: IESG
2596 Registrant Contact Information: iesg@ietf.org
2600 Description: Some of the information of the object instance has not
2601 been made available and has been removed. This is most commonly
2602 applied to entities.
2603 Registrant Name: IESG
2604 Registrant Contact Information: iesg@ietf.org
2608 Description: Some of the information of the object instance has been
2609 altered for the purposes of not readily revealing the actual
2610 information of the object instance. This is most commonly applied
2612 Registrant Name: IESG
2613 Registrant Contact Information: iesg@ietf.org
2617 Description: The object instance is associated with other object
2618 instances in the registry. This is most commonly used to signify
2619 that a nameserver is associated with a domain or that an entity is
2620 associated with a network resource or domain.
2621 Registrant Name: IESG
2622 Registrant Contact Information: iesg@ietf.org
2626 Description: The object instance is in use. For domain names, it
2627 signifies that the domain name is published in DNS. For network
2628 and autnum registrations, it signifies that they are allocated or
2629 assigned for use in operational networks. This maps to the "OK"
2630 status of the Extensible Provisioning Protocol (EPP) [RFC5730].
2631 Registrant Name: IESG
2632 Registrant Contact Information: iesg@ietf.org
2636 Description: The object instance is not in use. See "active".
2637 Registrant Name: IESG
2638 Registrant Contact Information: iesg@ietf.org
2642 Description: Changes to the object instance cannot be made,
2643 including the association of other object instances.
2644 Registrant Name: IESG
2645 Registrant Contact Information: iesg@ietf.org
2647 Value: pending create
2649 Description: A request has been received for the creation of the
2650 object instance, but this action is not yet complete.
2651 Registrant Name: IESG
2652 Registrant Contact Information: iesg@ietf.org
2654 Value: pending renew
2656 Description: A request has been received for the renewal of the
2657 object instance, but this action is not yet complete.
2658 Registrant Name: IESG
2659 Registrant Contact Information: iesg@ietf.org
2661 Value: pending transfer
2663 Description: A request has been received for the transfer of the
2664 object instance, but this action is not yet complete.
2665 Registrant Name: IESG
2666 Registrant Contact Information: iesg@ietf.org
2668 Value: pending update
2670 Description: A request has been received for the update or
2671 modification of the object instance, but this action is not yet
2673 Registrant Name: IESG
2674 Registrant Contact Information: iesg@ietf.org
2676 Value: pending delete
2678 Description: A request has been received for the deletion or removal
2679 of the object instance, but this action is not yet complete. For
2680 domains, this might mean that the name is no longer published in
2681 DNS but has not yet been purged from the registry database.
2682 Registrant Name: IESG
2683 Registrant Contact Information: iesg@ietf.org
268510.2.3. Event Actions
2687 The following values have been registered in the "RDAP JSON Values"
2692 Description: The object instance was initially registered.
2693 Registrant Name: IESG
2694 Registrant Contact Information: iesg@ietf.org
2696 Value: reregistration
2698 Description: The object instance was registered subsequently to
2699 initial registration.
2700 Registrant Name: IESG
2701 Registrant Contact Information: iesg@ietf.org
2705 Description: An action noting when the information in the object
2706 instance was last changed.
2707 Registrant Name: IESG
2708 Registrant Contact Information: iesg@ietf.org
2712 Description: The object instance has been removed or will be removed
2713 at a predetermined date and time from the registry.
2714 Registrant Name: IESG
2715 Registrant Contact Information: iesg@ietf.org
2719 Description: The object instance was removed from the registry at a
2720 point in time that was not predetermined.
2721 Registrant Name: IESG
2722 Registrant Contact Information: iesg@ietf.org
2724 Value: reinstantiation
2726 Description: The object instance was reregistered after having been
2727 removed from the registry.
2728 Registrant Name: IESG
2729 Registrant Contact Information: iesg@ietf.org
2733 Description: The object instance was transferred from one registrar
2735 Registrant Name: IESG
2736 Registrant Contact Information: iesg@ietf.org
2740 Description: The object instance was locked (see the "locked"
2742 Registrant Name: IESG
2743 Registrant Contact Information: iesg@ietf.org
2747 Description: The object instance was unlocked (see the "locked"
2749 Registrant Name: IESG
2750 Registrant Contact Information: iesg@ietf.org
2754 The following values have been registered in the "RDAP JSON Values"
2759 Description: The entity object instance is the registrant of the
2760 registration. In some registries, this is known as a maintainer.
2761 Registrant Name: IESG
2762 Registrant Contact Information: iesg@ietf.org
2766 Description: The entity object instance is a technical contact for
2768 Registrant Name: IESG
2769 Registrant Contact Information: iesg@ietf.org
2771 Value: administrative
2773 Description: The entity object instance is an administrative contact
2774 for the registration.
2775 Registrant Name: IESG
2776 Registrant Contact Information: iesg@ietf.org
2780 Description: The entity object instance handles network abuse issues
2781 on behalf of the registrant of the registration.
2782 Registrant Name: IESG
2783 Registrant Contact Information: iesg@ietf.org
2787 Description: The entity object instance handles payment and billing
2788 issues on behalf of the registrant of the registration.
2789 Registrant Name: IESG
2790 Registrant Contact Information: iesg@ietf.org
2794 Description: The entity object instance represents the authority
2795 responsible for the registration in the registry.
2796 Registrant Name: IESG
2797 Registrant Contact Information: iesg@ietf.org
2801 Description: The entity object instance represents a third party
2802 through which the registration was conducted (i.e., not the
2803 registry or registrar).
2804 Registrant Name: IESG
2805 Registrant Contact Information: iesg@ietf.org
2809 Description: The entity object instance represents a domain policy
2810 sponsor, such as an ICANN-approved sponsor.
2811 Registrant Name: IESG
2812 Registrant Contact Information: iesg@ietf.org
2816 Description: The entity object instance represents a proxy for
2817 another entity object, such as a registrant.
2818 Registrant Name: IESG
2819 Registrant Contact Information: iesg@ietf.org
2821 Value: notifications
2823 Description: An entity object instance designated to receive
2824 notifications about association object instances.
2825 Registrant Name: IESG
2826 Registrant Contact Information: iesg@ietf.org
2830 Description: The entity object instance handles communications
2831 related to a network operations center (NOC).
2832 Registrant Name: IESG
2833 Registrant Contact Information: iesg@ietf.org
283510.2.5. Variant Relations
2837 The following values have been registered in the "RDAP JSON Values"
2841 Type: domain variant relation
2842 Description: The variant names are registered in the registry.
2843 Registrant Name: IESG
2844 Registrant Contact Information: iesg@ietf.org
2847 Type: domain variant relation
2848 Description: The variant names are not found in the registry.
2849 Registrant Name: IESG
2850 Registrant Contact Information: iesg@ietf.org
2852 Value: registration restricted
2853 Type: domain variant relation
2854 Description: Registration of the variant names is restricted to
2855 certain parties or within certain rules.
2856 Registrant Name: IESG
2857 Registrant Contact Information: iesg@ietf.org
2859 Value: open registration
2860 Type: domain variant relation
2861 Description: Registration of the variant names is available to
2862 generally qualified registrants.
2863 Registrant Name: IESG
2864 Registrant Contact Information: iesg@ietf.org
2867 Type: domain variant relation
2868 Description: Registration of the variant names occurs automatically
2869 with the registration of the containing domain registration.
2870 Registrant Name: IESG
2871 Registrant Contact Information: iesg@ietf.org
287311. Security Considerations
2875 This specification models information serialized in JSON format. As
2876 JSON is a subset of JavaScript, implementations are advised to follow
2877 the security considerations outlined in Section 12 of [RFC8259] to
2878 prevent code injection.
2880 Though not specific to JSON, RDAP implementers should be aware of the
2881 security considerations specified in [RFC7480] and the security
2882 requirements and considerations in [RFC7481].
2884 RDAP responses allow for retrieval of DNSSEC (key) related
2885 information, but the RRSIG DS from the parent zone is not conveyed
2886 alongside it. This means that the DNSSEC keys retrieved by RDAP are
2887 disconnected from their containing PKI, and as such are not generally
2888 expected to be trusted without additional information. In
2889 particular, the HTTPS channel protecting the RDAP connection is not
2890 expected to be authorized to certify the validity of the DNSSEC keys.
2892 Clients caching data, especially clients using RDAP-specific caches
2893 (instead of HTTP-layer caches), should have safeguards to prevent
2894 cache poisoning. See Section 5 for advice on using the self links
2897 Finally, service operators should be aware of the privacy mechanisms
2898 noted in Section 13.
290012. Internationalization Considerations
290212.1. Character Encoding
2904 The default text encoding for JSON responses in RDAP is UTF-8
2905 [RFC3629], and all servers and clients MUST support UTF-8.
2909 [RFC7480] defines the use of URIs and IRIs in RDAP.
2913 Section 4.4 defines the use of language tags in the JSON responses
2914 defined in this document.
291612.4. Internationalized Domain Names
2918 IDNs are denoted in this specification by the separation of DNS names
2919 in LDH form and Unicode form (see Section 3). Representation of IDNs
2920 in registries is described by the "variants" object in Section 5.3
2921 and the suggested values listed in Section 10.2.5.
292313. Privacy Considerations
2925 This specification suggests status values to denote contact and
2926 registrant information that has been marked as private and/or has
2927 been removed or obscured. See Section 10.2.2 for the complete list
2928 of status values. A few of the status values indicate that there are
2929 privacy concerns associated with the object instance. The following
2930 status codes SHOULD be used to describe data elements of a response
2933 * private -- The object is not be shared in query responses, unless
2934 the user is authorized to view this information.
2936 * removed -- Data elements within the object have been collected but
2937 have been omitted from the response. This option can be used to
2938 prevent unauthorized access to associated object instances without
2939 the need to mark them as private.
2941 * obscured -- Data elements within the object have been collected,
2942 but the response value has been altered so that values are not
2943 easily discernible. A value changed from "1212" to "XXXX" is an
2944 example of obscured data. This option may reveal privacy
2945 sensitive information and should only be used when data
2946 sensitivity does not require a more protective option like
2947 "private" or "removed".
2949 See Appendix A.1 for an example of applying those values to contacts
295414.1. Normative References
2957 International Organization for Standardization, "Codes for
2958 the representation of names of countries and their
2959 subdivisions", Fourth edition, ISO Standard 3166, August
2962 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2963 Requirement Levels", BCP 14, RFC 2119,
2964 DOI 10.17487/RFC2119, March 1997,
2965 <https://www.rfc-editor.org/info/rfc2119>.
2967 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
2968 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
2969 <https://www.rfc-editor.org/info/rfc3339>.
2971 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
2972 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2973 2003, <https://www.rfc-editor.org/info/rfc3629>.
2975 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2976 Resource Identifier (URI): Generic Syntax", STD 66,
2977 RFC 3986, DOI 10.17487/RFC3986, January 2005,
2978 <https://www.rfc-editor.org/info/rfc3986>.
2980 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
2981 Rose, "Resource Records for the DNS Security Extensions",
2982 RFC 4034, DOI 10.17487/RFC4034, March 2005,
2983 <https://www.rfc-editor.org/info/rfc4034>.
2985 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
2986 Autonomous System (AS) Numbers", RFC 5396,
2987 DOI 10.17487/RFC5396, December 2008,
2988 <https://www.rfc-editor.org/info/rfc5396>.
2990 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
2991 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
2992 September 2009, <https://www.rfc-editor.org/info/rfc5646>.
2994 [RFC5890] Klensin, J., "Internationalized Domain Names for
2995 Applications (IDNA): Definitions and Document Framework",
2996 RFC 5890, DOI 10.17487/RFC5890, August 2010,
2997 <https://www.rfc-editor.org/info/rfc5890>.
2999 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
3000 Address Text Representation", RFC 5952,
3001 DOI 10.17487/RFC5952, August 2010,
3002 <https://www.rfc-editor.org/info/rfc5952>.
3004 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
3005 DOI 10.17487/RFC7095, January 2014,
3006 <https://www.rfc-editor.org/info/rfc7095>.
3008 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
3009 Registration Data Access Protocol (RDAP)", STD 95,
3010 RFC 7480, DOI 10.17487/RFC7480, March 2015,
3011 <https://www.rfc-editor.org/info/rfc7480>.
3013 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
3014 Registration Data Access Protocol (RDAP)", STD 95,
3015 RFC 7481, DOI 10.17487/RFC7481, March 2015,
3016 <https://www.rfc-editor.org/info/rfc7481>.
3018 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
3019 Writing an IANA Considerations Section in RFCs", BCP 26,
3020 RFC 8126, DOI 10.17487/RFC8126, June 2017,
3021 <https://www.rfc-editor.org/info/rfc8126>.
3023 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
3024 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
3025 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
3027 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
3028 Interchange Format", STD 90, RFC 8259,
3029 DOI 10.17487/RFC8259, December 2017,
3030 <https://www.rfc-editor.org/info/rfc8259>.
3032 [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
3033 DOI 10.17487/RFC8288, October 2017,
3034 <https://www.rfc-editor.org/info/rfc8288>.
3036 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
3037 Protocol (RDAP) Query Format", STD 95, RFC 9082,
3038 DOI 10.17487/RFC9082, June 2021,
3039 <https://www.rfc-editor.org/info/rfc9082>.
304114.2. Informative References
3044 IANA, "Repository of IDN Practices",
3045 <https://www.iana.org/domains/idn-tables>.
3048 MacVittie, L., "The Stealthy Ascendancy of JSON", April
3049 2011, <https://devcentral.f5.com/s/articles/the-stealthy-
3050 ascendancy-of-json>.
3052 [JSON_performance_study]
3053 Nurseitov, N., Paulson, M., Reynolds, R., and C. Izurieta,
3054 "Comparison of JSON and XML Data Interchange Formats: A
3056 <https://www.cs.montana.edu/izurieta/pubs/caine2009.pdf>.
3058 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
3059 DOI 10.17487/RFC3912, September 2004,
3060 <https://www.rfc-editor.org/info/rfc3912>.
3062 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
3063 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
3064 <https://www.rfc-editor.org/info/rfc5730>.
3066 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
3067 Security Extensions Mapping for the Extensible
3068 Provisioning Protocol (EPP)", RFC 5910,
3069 DOI 10.17487/RFC5910, May 2010,
3070 <https://www.rfc-editor.org/info/rfc5910>.
3072 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
3073 DOI 10.17487/RFC6350, August 2011,
3074 <https://www.rfc-editor.org/info/rfc6350>.
3076 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
3077 Structured Syntax Suffixes", RFC 6839,
3078 DOI 10.17487/RFC6839, January 2013,
3079 <https://www.rfc-editor.org/info/rfc6839>.
3081Appendix A. Suggested Data Modeling with the Entity Object Class
3083A.1. Registrants and Contacts
3085 This document does not provide specific object classes for
3086 registrants and contacts. Instead, the entity object class may be
3087 used to represent a registrant or contact. When the entity object is
3088 embedded inside a containing object such as a domain name or IP
3089 network, the "roles" string array can be used to signify the
3090 relationship. It is recommended that the values from Section 10.2.4
3093 The following is an example of an elided containing object with an
3094 embedded entity that is both a registrant and administrative contact:
3101 "objectClassName" : "entity",
3106 ["version", {}, "text", "4.0"],
3107 ["fn", {}, "text", "Joe User"],
3108 ["kind", {}, "text", "individual"],
3111 }, "language-tag", "fr"],
3114 }, "language-tag", "en"],
3117 }, "text", "Example"],
3118 ["title", {}, "text", "Research Scientist"],
3119 ["role", {}, "text", "Project Lead"],
3126 "4321 Rue Somewhere",
3134 { "type":["work", "voice"], "pref":"1" },
3135 "uri", "tel:+1-555-555-1234;ext=102"
3139 "text", "joe.user@example.com"
3143 "roles" : [ "registrant", "administrative" ],
3149 "She sells sea shells down by the sea shore.",
3150 "Originally written by Terry Sullivan."
3157 "eventAction" : "registration",
3158 "eventDate" : "1990-12-31T23:59:59Z"
3161 "eventAction" : "last changed",
3162 "eventDate" : "1991-12-31T23:59:59Z"
3171 In many use cases, it is necessary to hide or obscure the information
3172 of a registrant or contact due to policy or other operational
3173 matters. Registries can denote these situations with "status" values
3174 (see Section 10.2.2).
3176 The following is an elided example of a registrant with information
3177 changed to reflect that of a third party.
3184 "objectClassName" : "entity",
3187 "roles" : [ "registrant", "administrative" ],
3188 "status" : [ "proxy", "private", "obscured" ]
3197 This document does not provide a specific object class for
3198 registrars, but like registrants and contacts (see Appendix A.1), the
3199 "roles" string array maybe used. Additionally, many registrars have
3200 publicly assigned identifiers. The publicIds structure (Section 4.8)
3201 represents that information.
3203 The following is an example of an elided containing object with an
3204 embedded entity that is a registrar:
3210 "objectClassName" : "entity",
3215 ["version", {}, "text", "4.0"],
3216 ["fn", {}, "text", "Joe's Fish, Chips, and Domains"],
3217 ["kind", {}, "text", "org"],
3220 }, "language-tag", "fr"],
3223 }, "language-tag", "en"],
3226 }, "text", "Example"],
3233 "4321 Rue Somewhere",
3242 "type":["work", "voice"],
3245 "uri", "tel:+1-555-555-1234;ext=102"
3249 "text", "joes_fish_chips_and_domains@example.com"
3253 "roles":[ "registrar" ],
3256 "type":"IANA Registrar ID",
3263 "She sells sea shells down by the sea shore.",
3264 "Originally written by Terry Sullivan."
3270 "value":"https://example.net/entity/XXXX",
3273 "href":"https://www.example.com"
3282Appendix B. Modeling Events
3284 Events represent actions that have taken place against a registered
3285 object at a certain date and time. Events have three properties: the
3286 action, the actor, and the date and time of the event (which is
3287 sometimes in the future). In some cases, the identity of the actor
3290 Events can be modeled in three ways:
3292 1. events with no designated actor
3294 2. events where the actor is only designated by an identifier
3296 3. events where the actor can be modeled as an entity
3298 For the first use case, the events data structure (Section 4.5) is
3299 used without the "eventActor" object member.
3301 This is an example of an "events" array without the "eventActor".
3306 "eventAction" : "registration",
3307 "eventDate" : "1990-12-31T23:59:59Z"
3313 For the second use case, the events data structure (Section 4.5) is
3314 used with the "eventActor" object member.
3316 This is an example of an "events" array with the "eventActor".
3321 "eventAction" : "registration",
3322 "eventActor" : "XYZ-NIC",
3323 "eventDate" : "1990-12-31T23:59:59Z"
3329 For the third use case, the "asEventActor" array is used when an
3330 entity (Section 5.1) is embedded into another object class. The
3331 "asEventActor" array follows the same structure as the "events" array
3332 but does not have "eventActor" attributes.
3334 The following is an elided example of a domain object with an entity
3338 "objectClassName" : "domain",
3340 "ldhName" : "foo.example",
3341 "status" : [ "locked", "transfer prohibited" ],
3351 "eventAction" : "last changed",
3352 "eventDate" : "1990-12-31T23:59:59Z"
3361Appendix C. Structured vs. Unstructured Addresses
3363 The entity (Section 5.1) object class uses jCard [RFC7095] to
3364 represent contact information, including postal addresses. jCard has
3365 the ability to represent multiple language preferences, multiple
3366 email address and phone numbers, and multiple postal addresses in
3367 both a structured and unstructured format. This section describes
3368 the use of jCard for representing structured and unstructured
3371 The following is an example of a jCard.
3377 ["version", {}, "text", "4.0"],
3378 ["fn", {}, "text", "Joe User"],
3380 ["User", "Joe", "", "", ["ing. jr", "M.Sc."]]
3382 ["kind", {}, "text", "individual"],
3385 }, "language-tag", "fr"],
3388 }, "language-tag", "en"],
3391 }, "text", "Example"],
3392 ["title", {}, "text", "Research Scientist"],
3393 ["role", {}, "text", "Project Lead"],
3400 "4321 Rue Somewhere",
3411 "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n"
3415 "", "", "", "", "", "", ""
3419 { "type":["work", "voice"], "pref":"1" },
3420 "uri", "tel:+1-555-555-1234;ext=102"
3424 "type":["work", "cell", "voice", "video", "text"]
3427 "tel:+1-555-555-1234"
3431 "text", "joe.user@example.com"
3435 }, "uri", "geo:46.772673,-71.282945"],
3438 "uri", "https://www.example.com/joe.user/joe.asc"
3441 "utc-offset", "-05:00"],
3442 ["url", { "type":"home" },
3443 "uri", "https://example.org"]
3450 The arrays in Figure 40 with the first member of "adr" represent
3451 postal addresses. In the first example, the postal address is given
3452 as an array of strings and constitutes a structured address. For
3453 components of the structured address that are not applicable, an
3454 empty string is given. Each member of that array aligns with the
3455 positions of a vCard as given in [RFC6350]. In this example, the
3456 following data corresponds to the following positional meanings:
3458 1. post office box -- not applicable; empty string
3460 2. extended address (e.g., apartment or suite number) -- Suite 1234
3462 3. street address -- 4321 Rue Somewhere
3464 4. locality (e.g., city) -- Quebec
3466 5. region (e.g., state or province) -- QC
3468 6. postal code -- G1V 2M2
3470 7. country name (full name) -- Canada
3472 The second example is an unstructured address. It uses the "label"
3473 attribute, which is a string containing a newline (\n) character to
3474 separate address components in an unordered, unspecified manner.
3475 Note that in this example, the structured address array is still
3476 given but that each string is an empty string.
3478Appendix D. Secure DNS
3480 Section 5.3 defines the "secureDNS" member to represent secure DNS
3481 information about domain names.
3483 DNSSEC provides data integrity for DNS through the digital signing of
3484 resource records. To enable DNSSEC, the zone is signed by one or
3485 more private keys and the signatures are stored as RRSIG records. To
3486 complete the chain of trust in the DNS zone hierarchy, a digest of
3487 each DNSKEY record (which contains the public key) must be loaded
3488 into the parent zone, stored as DS records, and signed by the
3489 parent's private key (RRSIG DS record), as indicated in "Resource
3490 Records for the DNS Security Extensions" [RFC4034]. Creating the DS
3491 records in the parent zone can be done by the registration authority
3492 "Domain Name System (DNS) Security Extensions Mapping for the
3493 Extensible Provisioning Protocol (EPP)" [RFC5910].
3495 Only DS-related information is provided by RDAP, since other
3496 information is not generally stored in the registration database.
3497 Other DNSSEC-related information can be retrieved with other DNS
3500 The domain object class (Section 5.3) can represent this information
3501 using either the "dsData" or "keyData" object arrays. Client
3502 implementers should be aware that some registries do not collect or
3503 do not publish all of the secure DNS meta-information.
3505Appendix E. Motivations for Using JSON
3507 This section addresses a common question regarding the use of JSON
3508 over other data formats, most notably XML.
3510 It is often pointed out that many DNRs and one RIR support the EPP
3511 [RFC5730] standard, which is an XML serialized protocol. The logic
3512 is that since EPP is a common protocol in the industry, it follows
3513 that XML would be a more natural choice. While EPP does influence
3514 this specification quite a bit, EPP serves a different purpose, which
3515 is the provisioning of Internet resources between registries and
3516 accredited registrars and serving a much narrower audience than that
3517 envisioned for RDAP.
3519 By contrast, RDAP has a broader audience and is designed for public
3520 consumption of data. Experience from RIRs with first generation
3521 RESTful web services for WHOIS indicate that a large percentage of
3522 clients operate within browsers and other platforms where full-blown
3523 XML stacks are not readily available and where JSON is a better fit.
3525 Additionally, while EPP is used in much of the DNR community it is
3526 not a universal constant in that industry. And finally, EPP's use of
3527 XML predates the specification of JSON. If EPP had been defined
3528 today, it may very well have used JSON instead of XML.
3530 Beyond the specific DNR and RIR communities, the trend in the broader
3531 Internet industry is also switching to JSON over XML, especially in
3532 the area of RESTful web services (see [JSON_ascendancy]). Studies
3533 have also found that JSON is generally less bulky and consequently
3534 faster to parse (see [JSON_performance_study]).
3536Appendix F. Changes from RFC 7483
3538 * Addressed known errata.
3540 * Updated references to 7482 to RFC 9082. Adjusted case of "xxxx"
3541 used in examples where "XXXX" was previously used, and removed an
3542 "X" from "XXXXX". Changed IPv6 address example using "C00" to
3543 "c00". Added "a string representing" to the definitions of
3544 startAddress and endAddress. Removed "entity" from "Autonomous
3545 System Number Entity Object Class". Added "an unsigned 32-bit
3546 integer" to the definition of startAutnum and endAutnum. Added "a
3547 string representing" to the definition of name in the IP network
3548 and ASN object classes. Clarified rdapConformance identifier
3549 registration expectations in Section 4.1. Changed
3550 "lunarNic_level_0" to "lunarNIC_level_0".
3552 * Clarified that the "value", "rel" and "href" JSON values MUST be
3553 specified in the "links" array.
3555 * Clarified that the "description" array is required in the Notices
3556 and Remarks data structures and other values are OPTIONAL.
3558 * Noted that all members of the "events" and "Public IDs" arrays are
3561 * Fix "self" link values in examples. Changed "http" to "https"
3562 link values in examples. Noted that Figure 18 is an example of a
3563 nameserver object with all "appropriate" values given. In
3564 Appendix C, quoted the word "label" in "label attribute". Added
3565 reference to "status" definition in the descriptions for IP
3566 networks and autnums. Fixed a 404 for the informative reference
3567 to "The Stealthy Ascendancy of JSON". Added "boolean" to the
3568 definition of zoneSigned.
3570 * Clarified REQUIRED and OPTIONAL members of the "events" array.
3572 * Changed "SHOULD not" to "SHOULD NOT" in Section 5.
3574 * Updated normative references (RFC 5226 to RFC 8126, RFC 5988 to
3575 RFC 8288, RFC 7159 to RFC 8259). Changed examples using "ns1.xn--
3576 fo-5ja.example" to split URLs to avoid long lines.
3578 * Added acknowledgments.
3580 * Changed "The "lang" attribute may appear anywhere in an object
3581 class or data structure except for in jCard objects" to "The
3582 "lang" attribute as defined in this section MAY appear anywhere in
3583 an object class or data structure, except for in jCard objects.
3584 jCard supports similar functionality by way of the LANGUAGE
3585 property parameter (see Section 5.1 of RFC 6350 [RFC6350]".
3587 * Changed "simple data types conveyed in JSON strings" to "simple
3588 data types conveyed in JSON primitive types (strings, numbers,
3589 booleans, and null)". Changed "In other words, servers are free
3590 to not include JSON members containing registration data based on
3591 their own policies" to "In other words, servers are free to omit
3592 unrequired/optional JSON members containing registration data
3593 based on their own policies".
3595 * Changed "This data structure appears only in the topmost JSON
3596 object of a response" to "This data structure MUST appear in the
3597 topmost JSON object of a response".
3599 * Changed "Some non-answer responses may return entity bodies with
3600 information that could be more descriptive" to "Some non-answer
3601 responses MAY return entity bodies with information that could be
3604 * Changed "The basic structure of that response is an object class
3605 containing an error code number (corresponding to the HTTP
3606 response code) followed by a string named "title" and an array of
3607 strings named "description"" to "The basic structure of that
3608 response is an object class containing a REQUIRED error code
3609 number (corresponding to the HTTP response code) followed by an
3610 OPTIONAL string named "title" and an OPTIONAL array of strings
3611 named "description"".
3613 * Changed the "Autonomous System Number Object Class" section title
3614 to "The Autonomous System Number Object Class" for consistency
3615 with other section titles. Removed trailing periods in the
3616 "Terminology and Definitions" section for consistency. Changed
3617 instances of "lunarNic" to "lunarNIC" for consistency. Removed an
3618 extraneous trailing period after the eventDate description.
3619 Changed a "." to ";" in the description of the "network" member of
3620 the domain object class. Changed "The high-level structure of the
3621 autnum object class consists of information about the network
3622 registration" to "The high-level structure of the autnum object
3623 class consists of information about the Autonomous System number
3624 registration". Changed "registry unique" to "registry-unique".
3626 * Changed "registrant" to "registrar" in the description of the
3627 "transfer" event action to address erratum 6158. Added IANA
3628 instructions to correct the description of the value in the
3631 * Added text to Section 4.2 to note that "self" and "related" "href"
3632 URIs MUST NOT be the same.
3634 * Added text to Section 4.2 to describe return of IDNs in LDH name
3637 * Added text to note that the "fn" member of a contact object MAY be
3640 * Added text to clarify rdapConformance requirements in Section 4.1.
3642 * Added "obsoletes 7483" to the headers, Abstract, and Introduction.
3643 Updated BCP 14 boilerplate. Updated IANA Considerations to note
3644 that this RFC (a product of the REGEXT Working Group) replaces RFC
3645 7483. Changed "simple string" to "simple character string" in
3646 Sections 3 and 4.7. Clarified requirement for the "fn" member in
3647 Section 3. Modified the requirement for rdapConformance placement
3648 in Section 4.1. Changed "jCard" to "vCard" LANGUAGE property
3649 reference in Section 4.4. Changed "no use" to "little or no use"
3650 in Section 5.1. Added example line wrap note in Section 5.2.
3651 Modified the definition of "idnTable" in Section 5.3. Modified
3652 the dsData and keyData examples in Section 5.3. Changed
3653 "2001:c00::/23" to "2001:db8::/32" in Section 5.4. Expanded the
3654 definition of "type" in Sections 5.4 and 5.5. Modified example
3655 autnums in Section 5.5. Added text to the Security Considerations
3656 section to note that DNSSEC information returned in a response
3657 cannot be trusted directly.
3661 This document is derived from original work on RIR responses in JSON
3662 by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew L.
3663 Newton. Additionally, this document incorporates work on DNR
3664 responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean
3667 The components of the DNR object classes are derived from a
3668 categorization of WHOIS response formats created by Ning Kong, Linlin
3669 Zhou, Guangqing Deng, Steve Sheng, Francisco Arias, Ray Bellis, and
3672 Tom Harrison, Murray Kucherawy, Ed Lewis, Audric Schiltknecht, Naoki
3673 Kambe, Maarten Bosteels, Mario Loffredo, and Jasdip Singh contributed
3674 significant review comments and provided clarifying text. James
3675 Mitchell provided text regarding the processing of unknown JSON
3676 attributes and identified issues leading to the remodeling of events.
3677 Ernie Dainow and Francisco Obispo provided concrete suggestions that
3678 led to a better variant model for domain names.
3680 Ernie Dainow provided the background information on the secure DNS
3681 attributes and objects for domains, informative text on DNSSEC, and
3682 many other attributes that appear throughout the object classes of
3685 The switch to and incorporation of jCard was performed by Simon
3688 Olaf Kolkman and Murray Kucherawy chaired the IETF's WEIRDS Working
3689 Group from which this document was originally created. James Galvin
3690 and Antoin Verschuren chaired the REGEXT Working Group that worked on
3699 United States of America
3701 Email: shollenbeck@verisign.com
3702 URI: https://www.verisignlabs.com/
3706 Amazon Web Services, Inc.
3707 13200 Woodland Park Road
3709 United States of America