idnits 2.17.1 draft-ietf-weirds-json-response-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 148: '...nt client/server MUST understand to fu...' RFC 2119 keyword, line 188: '...N attributes but SHOULD NOT treat them...' RFC 2119 keyword, line 189: '... error. Servers MAY insert values sig...' RFC 2119 keyword, line 191: '...o JSON responses SHOULD have names pre...' RFC 2119 keyword, line 194: '...meaningful name) SHOULD adhere to the ...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 15, 2013) is 3900 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2179 == Unused Reference: 'RFC0791' is defined on line 2927, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 2933, but no explicit reference was found in the text == Unused Reference: 'RFC4343' is defined on line 2951, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 2957, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1166 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-07) exists of draft-ietf-jcardcal-jcard-05 == Outdated reference: A later version (-15) exists of draft-ietf-weirds-using-http-07 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-weirds-using-http' == Outdated reference: A later version (-18) exists of draft-ietf-weirds-rdap-query-05 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft ARIN 4 Intended status: Standards Track S. Hollenbeck 5 Expires: February 16, 2014 Verisign Labs 6 August 15, 2013 8 JSON Responses for the Registration Data Access Protocol (RDAP) 9 draft-ietf-weirds-json-response-05 11 Abstract 13 This document describes JSON data structures representing 14 registration information maintained by Regional Internet Registries 15 (RIRs) and Domain Name Registries (DNRs). These data structures are 16 used to form Registration Data Access Protocol (RDAP) query 17 responses. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 16, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 55 3. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Common Data Structures . . . . . . . . . . . . . . . . . . . 7 60 5.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 8 61 5.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5.3. Notices And Remarks . . . . . . . . . . . . . . . . . . . 9 63 5.4. Language Identifier . . . . . . . . . . . . . . . . . . . 11 64 5.5. Events . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.6. Status . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5.7. Port 43 Whois Server . . . . . . . . . . . . . . . . . . 12 67 5.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 13 68 5.9. An Example . . . . . . . . . . . . . . . . . . . . . . . 13 69 6. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 14 70 6.1. The Entity Object Class . . . . . . . . . . . . . . . . . 15 71 6.2. The Nameserver Object Class . . . . . . . . . . . . . . . 21 72 6.3. The Domain Object Class . . . . . . . . . . . . . . . . . 25 73 6.4. The IP Network Object Class . . . . . . . . . . . . . . . 37 74 6.5. Autonomous System Number Entity Object Class . . . . . . 41 75 7. Error Response Body . . . . . . . . . . . . . . . . . . . . . 44 76 8. Responding to Help Queries . . . . . . . . . . . . . . . . . 46 77 9. Responding To Searches . . . . . . . . . . . . . . . . . . . 47 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 79 10.1. RDAP JSON Media Type Registration . . . . . . . . . . . 49 80 10.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 50 81 10.2.1. Status . . . . . . . . . . . . . . . . . . . . . . . 52 82 10.2.2. Event Actions . . . . . . . . . . . . . . . . . . . 57 83 10.2.3. Roles . . . . . . . . . . . . . . . . . . . . . . . 60 84 10.2.4. Variant Relations . . . . . . . . . . . . . . . . . 63 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 64 86 12. Internationalization Considerations . . . . . . . . . . . . . 64 87 12.1. Character Encoding . . . . . . . . . . . . . . . . . . . 64 88 12.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 64 89 12.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 65 90 12.4. Internationalized Domain Names . . . . . . . . . . . . . 65 91 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 65 92 14. Contributing Authors and Acknowledgements . . . . . . . . . . 65 93 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 94 15.1. Normative References . . . . . . . . . . . . . . . . . . 66 95 15.2. Informative References . . . . . . . . . . . . . . . . . 67 96 Appendix A. Suggested Data Modeling with the Entity Object Class 68 97 A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 68 98 A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 70 99 Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 72 100 Appendix C. Structured vs Unstructured Addresses . . . . . . . . 73 101 Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 76 102 Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 77 103 Appendix F. Changelog . . . . . . . . . . . . . . . . . . . . . 77 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 106 1. Introduction 108 This document describes responses in the JSON [RFC4627] format for 109 the RESTful web queries as defined by the Registration Data Access 110 Protocol Lookup Format [I-D.ietf-weirds-rdap-query]. 112 The data model for JSON responses is specified in four sections: 114 1. simple data types conveyed in JSON strings 116 2. data structures specified as JSON arrays or objects that are used 117 repeatedly when building up larger objects 119 3. object classes representing structured data corresponding to a 120 given query 122 4. the response to an error 124 The object classes represent responses for two major categories of 125 data: responses returned by Regional Internet Registries (RIRs) for 126 registrations data related to IP addresses, reverse DNS names, and 127 Autonomous System numbers; and responses returned by Domain Name 128 Registries (DNRs) for registration data related to forward DNS names. 129 The following object classes are served by both RIRs and DNRs: 131 1. domains 133 2. nameservers 135 3. entities 136 The information served by both RIRs and DNRs for these object classes 137 overlap extensively and are given in this document as a unified model 138 for both classes of service. 140 In addition to the object classes listed above, RIRs also serve the 141 following object classes: 143 1. IP networks 145 2. Autonomous System numbers 147 Object classes defined in this document represent a minimal set of 148 what a compliant client/server MUST understand to function correctly, 149 however some deployments may want to include additional object 150 classes to suit individual needs. Anticipating this need for 151 extension, Section 3.2 of this document defines a mechanism for 152 extending the JSON objects that are described in this document. 154 2. Terminology and Definitions 156 The following list describes terminology and definitions used 157 throughout this document: 159 DNR: "Domain Name Registry". 161 LDH: "Letters, Digits, Hyphen". 163 member: data found with in an object as defined by JSON 164 [RFC4627]. 166 object: a data structure as defined by JSON [RFC4627]. 168 object class: the definition of members that may be found in JSON 169 objects described in this document. 171 object instance: an instantiation or specific instance of an object 172 class. 174 RDAP: "Registration Data Access Protocol". 176 RIR: "Regional Internet Registry". 178 3. Use of JSON 180 3.1. Signaling 182 Media type signaling for the JSON data specified in this document is 183 specified in [I-D.ietf-weirds-using-http]. 185 3.2. Naming 187 Clients processing JSON [RFC4627] responses are under no obligation 188 to process unrecognized JSON attributes but SHOULD NOT treat them as 189 an error. Servers MAY insert values signified by names into the JSON 190 responses which are not specified in this document. Insertion of 191 unspecified values into JSON responses SHOULD have names prefixed 192 with a short identifier followed by an underscore followed by a 193 meaningful name. The full JSON name (the prefix plus the underscore 194 plus the meaningful name) SHOULD adhere to the character and name 195 limitations of the prefix registry described in 196 [I-D.ietf-weirds-using-http]. 198 Consider the following JSON response with JSON names, all of which 199 are specified in this document. 201 { 202 "handle" : "ABC123", 203 "remarks" : 204 [ 205 { 206 "description" : 207 [ 208 "She sells sea shells down by the sea shore.", 209 "Originally written by Terry Sullivan." 210 ] 211 } 212 ] 213 } 215 Figure 1 217 If The Registry of the Moon desires to express information not found 218 in this specification, it might select "lunarNic" as its identifying 219 prefix and insert, as an example, the name 220 "lunarNic_beforeOneSmallStep" to signify registrations occurring 221 before the first moon landing and the name 222 "lunarNic_harshMistressNotes" containing other descriptive text. 224 Consider the following JSON response with JSON names, some of which 225 should be ignored by clients without knowledge of their meaning. 227 { 228 "handle" : "ABC123", 229 "lunarNic_beforeOneSmallStep" : "TRUE THAT!", 230 "remarks" : 231 [ 232 { 233 "description" : 234 [ 235 "She sells sea shells down by the sea shore.", 236 "Originally written by Terry Sullivan." 237 ] 238 } 239 ], 240 "lunarNic_harshMistressNotes" : 241 [ 242 "In space,", 243 "nobody can hear you scream." 244 ] 245 } 247 Figure 2 249 Insertion of unrecognized names ignored by clients may also be used 250 for future revisions to this specification. 252 Clients processing JSON responses MUST be prepared for values 253 specified in this document to be absent from a response as no JSON 254 value listed is required to appear in a response. In other words, 255 servers MAY remove values as is needed by the policies of the server 256 operator. 258 Finally, all JSON names specified in this document are case 259 sensitive. Both servers and clients MUST transmit and process them 260 using the specified character case. 262 4. Common Data Types 264 JSON [RFC4627] defines the data types of a number, character string, 265 boolean, array, object and null. This section describes the 266 semantics and/or syntax reference for data types used in this 267 document derived from the JSON character string. 269 'handle': DNRs and RIRs have registry-unique identifiers that 270 may be used to specifically reference an object 271 instance. The semantics of this data type as found 272 in this document is to be a registry-unique 273 reference to the closest enclosing object where the 274 value is found. The data type names 'registryId', 275 'roid', 'nic-handle', 'registrationNo', etc. are 276 terms often synonymous with this data type. In 277 this document, the term 'handle' is used. The term 278 exposed to users by clients is a presentation issue 279 beyond the scope of this document. 281 IPv4 addresses: The representation of IPv4 addresses in this 282 document uses the dotted-decimal notation described 283 in [RFC1166]. An example of this textual 284 representation is '192.0.2.0'. 286 IPv6 addresses: The representation of IPv6 addresses in this 287 document follow the forms outlined in [RFC5952]. 288 An example of this textual representation is 289 '2001:db8::1:0:0:1'. 291 country codes: Where the identity of a geopolitical nation or 292 country is needed, these identities are represented 293 with the alpha-2 or 2 character country code 294 designation as defined in [ISO.3166.1988]. The 295 alpha-2 representation is used because it is freely 296 available whereas the alpha-3 and numeric-3 297 standards are not. 299 LDH names: Textual representations of DNS names where the 300 labels of the domain are all "letters, digits, 301 hyphen" labels as described by [RFC5890]. Trailing 302 periods are optional. 304 Unicode names: Textual representations of DNS names where one or 305 more of the labels are U-labels as described by 306 [RFC5890]. Trailing periods are optional. 308 dates and times: The syntax for values denoting dates and times is 309 defined in [RFC3339]. 311 URIs: The syntax for values denoting a Uniform Resource 312 Identifier (URI) is defined by [RFC3986]. 314 Contact information is defined using JSON vCards as described in 315 [I-D.ietf-jcardcal-jcard] 317 5. Common Data Structures 319 This section defines common data structures used commonly in object 320 classes. 322 5.1. RDAP Conformance 324 The first data structure is named "rdapConformance" and is simply an 325 array of strings, each providing a hint as to the specifications used 326 in the construction of the response. This data structure appears 327 only in the top most object of a response. 329 An example rdapConformance data structure: 331 "rdapConformance" : 332 [ 333 "rdap_level_0" 334 ] 336 Figure 3 338 The string literal "rdap_level_0" signifies conformance with this 339 specification. When custom JSON values are inserted into responses, 340 conformance to those custom specifications should use a string 341 prefixed with the appropriate identifier from the IANA prefix 342 identifier registry specified in [I-D.ietf-weirds-using-http]. For 343 example, if the fictional Registry of the Moon wants to signify that 344 their JSON responses are conformant with their registered extensions, 345 the string used might be "lunarNIC_level_0". 347 Example rdapConformance structure with custom extensions noted: 349 "rdapConformance" : 350 [ 351 "rdap_level_0", 352 "lunarNic_level_0" 353 ] 355 Figure 4 357 5.2. Links 359 The "links" array is found in data structures to signify links to 360 other resources on the Internet. The relationship of these links is 361 defined by the IANA registry described by [RFC5988]. 363 The following is an example of the link structure: 365 { 366 "value" : "http://example.com/context_uri", 367 "rel" : "self", 368 "href" : "http://example.com/target_uri", 369 "hreflang" : [ "en", "ch" ], 370 "title" : [ "title1", "title2" ], 371 "media" : "screen", 372 "type" : "application/json" 373 } 375 Figure 5 377 The JSON name/values of "rel", "href", "hreflang", "title", "media", 378 and "type" correspond to values found in Section 5 of [RFC5988]. The 379 "value" JSON value is the context URI as described by [RFC5988]. The 380 "value", "rel", and "href" JSON values MUST be specified. All other 381 JSON values are optional. 383 This is an example of the "links" array as it might be found in an 384 object class: 386 "links" : 387 [ 388 { 389 "value" : "http://example.com/ip/2001:db8::123", 390 "rel" : "self", 391 "href" : "http://example.com/ip/2001:db8::123", 392 "type" : "application/rdap+json" 393 }, 394 { 395 "value" : "http://example.com/ip/2001:db8::123", 396 "rel" : "up", 397 "href" : "http://example.com/ip/2001:db8::/48", 398 "type" : "application/rdap+json" 399 } 401 ] 403 5.3. Notices And Remarks 405 The "notices" and "remarks" data structures take the same form. The 406 "notices" structure denotes information about the service providing 407 RDAP information, whereas the "remarks" structure denotes information 408 about the object class it is contained within (see Section 6 409 regarding object classes). 411 Both are an array of objects. Each object contains an optional 412 "title" string representing the title of the object, an array of 413 strings named "description" for the purposes of conveying any 414 descriptive text, and an optional "links" array as described in 415 Section 5.2. 417 An example of the notices data structure: 419 "notices" : 420 [ 421 { 422 "title" : "Terms of Use", 423 "description" : 424 [ 425 "Service subject to The Registry of the Moon's TOS.", 426 "Copyright (c) 2020 LunarNIC" 427 ], 428 "links" : 429 [ 430 { 431 "value" : "http://example.net/entity/XXXX", 432 "rel" : "alternate", 433 "type" : "text/html", 434 "href" : "http://www.example.com/terms_of_use.html" 435 } 436 ] 437 } 438 ] 440 Figure 6 442 It is the job of the clients to determine line breaks, spacing and 443 display issues for sentences within the character strings of the 444 "description" array. Servers SHOULD NOT split sentences across 445 multiple strings of this array. Each string is to represent a 446 semantic division in the descriptive text. 448 An example of the remarks data structure: 450 "remarks" : 451 [ 452 { 453 "description" : 454 [ 455 "She sells sea shells down by the sea shore.", 456 "Originally written by Terry Sullivan." 457 ] 458 } 459 ] 461 Figure 7 463 Note that objects in the "remarks" array may also have a "links" 464 array. 466 While the "remarks" array will appear in many object classes in a 467 response, the "notices" array appears only in the top most object of 468 a response. 470 5.4. Language Identifier 472 This data structure is a simple JSON name/value of "lang" with a 473 string containing a language identifier as described by [RFC5646]. 475 "lang" : "mn-Cyrl-MN" 477 Figure 8 479 The 'lang' attribute may appear anywhere in an object class or data 480 structure. 482 5.5. Events 484 This data structure represents events that have occurred on an 485 instance of an object class (see Section 6 regarding object classes). 487 This is an example of an "events" array. 489 "events" : 490 [ 491 { 492 "eventAction" : "registration", 493 "eventActor" : "SOMEID-LUNARNIC", 494 "eventDate" : "1990-12-31T23:59:60Z" 495 }, 496 { 497 "eventAction" : "last changed", 498 "eventActor" : "OTHERID-LUNARNIC", 499 "eventDate" : "1991-12-31T23:59:60Z" 500 } 501 ] 503 Figure 9 505 The "events" array consists of objects, each with the following 506 members: 508 o 'eventAction' -- a string denoting the reason for the event 510 o 'eventActor' -- an optional identifier denoting the actor 511 responsible for the event 513 o 'eventDate' -- a string containing the time and date the event 514 occurred. 516 o 'links' -- see Section 5.2. 518 Events can be future dated. One use case for future dating of events 519 is to denote when an object expires from a registry. 521 The 'links' array in this data structure is provided for references 522 to the event actor. If the event actor being referenced is an RDAP 523 entity, the link reference SHOULD be made with "rel" of "related" and 524 "type" of "application/rdap+json". 526 See Section 10.2.2 for a list of values for the 'eventAction' string. 527 See Appendix B regarding the various ways events can be modeled. 529 5.6. Status 531 This data structure, named 'status', is an array of strings 532 indicating the state of a registered object (see Section 10.2.1 for a 533 list of values). 535 5.7. Port 43 Whois Server 536 This data structure, named 'port43', is a simple string containing 537 the fully-qualified host name of the WHOIS [RFC3912] server where the 538 containing object instance may be found. Note that this is not a 539 URI, as there is no WHOIS URI scheme. 541 5.8. Public IDs 543 This data structure maps a public identifier to an object class. It 544 is named 'publicIds' and is an array of objects, with each object 545 containing the following members: 547 o type - a string denoting the type of public identifier 549 o identifier - a public identifier of the type denoted by 'type' 551 The following is an example of a 'publicIds' structure. 553 "publicIds": 554 [ 555 { 556 "type":"IANA Registrar ID", 557 "identifier":"1" 558 } 559 ] 561 Figure 10 563 5.9. An Example 565 This is an example response with both rdapConformance and notices 566 embedded: 568 { 569 "rdapConformance" : 570 [ 571 "rdap_level_0" 572 ], 573 "notices" : 574 [ 575 { 576 "title" : "Content Redacted", 577 "description" : 578 [ 579 "Without full authorization, content has been redacted.", 580 "Sorry, dude!" 581 ], 582 "links" : 583 [ 584 { 585 "value" : "http://example.net/ip/192.0.2.0/24", 586 "rel" : "alternate", 587 "type" : "text/html", 588 "href" : "http://www.example.com/redaction_policy.html" 589 } 590 ] 591 } 592 ], 593 "lang" : "en", 594 "startAddress" : "192.0.2.0", 595 "endAddress" : "192.0.2.255", 596 "handle" : "XXXX-RIR", 597 "ipVersion" : "v4", 598 "name": "NET-RTR-1", 599 "parentHandle" : "YYYY-RIR", 600 "remarks" : 601 [ 602 { 603 "description" : 604 [ 605 "She sells sea shells down by the sea shore.", 606 "Originally written by Terry Sullivan." 607 ] 608 } 609 ] 610 } 612 Figure 11 614 6. Object Classes 615 Object classes represent structures appropriate for a response from 616 the queries specified in [I-D.ietf-weirds-rdap-query]. 618 Each object class contains a "links" array as specified in 619 Section 5.2. For every object class instance in a response, whether 620 the object class instance is directly representing the response to a 621 query or is embedded in other object class instances, servers SHOULD 622 provide a link representing a URI for that object class instance 623 using the "self" relationship as specified in the IANA registry 624 specified by [RFC5988]. As explained in Section 6.2, this may be not 625 always be possible for name server data. Clients MUST be able to 626 process object instances without a "self" link. When present, 627 clients MAY use the self link for caching data. Servers MAY provide 628 more than one "self" link for any given object instance. 630 Self links SHOULD contain a "type" element containing the 631 "application/rdap+json" media type when referencing RDAP object 632 instances as defined by this document. Clients SHOULD NOT assume 633 self links without this media type are represented as RDAP objects as 634 defined by this document. 636 This is an example of the "links" array with a self link to an object 637 class: 639 "links" : 640 [ 641 { 642 "value" : "http://example.com/ip/2001:db8::123", 643 "rel" : "self", 644 "href" : "http://example.com/ip/2001:db8::123", 645 "type" : "application/rdap+json" 646 } 647 ] 649 6.1. The Entity Object Class 651 The entity object class appears throughout this document and is an 652 appropriate response for the /entity/XXXX query defined in 653 Registration Data Access Protocol Lookup Format 654 [I-D.ietf-weirds-rdap-query]. This object class represents the 655 information of organizations, corporations, governments, non-profits, 656 clubs, individual persons, and informal groups of people. All of 657 these representations are so similar that it is best to represent 658 them in JSON [RFC4627] with one construct, the entity object class, 659 to aid in the re-use of code by implementers. 661 The entity object is served by both RIRs and DNRs. The following is 662 an example of an entity that might be served by an RIR. For 663 illustrative purposes, it does not include rdapConformance or notices 664 data structures. 666 { 667 "handle":"XXXX", 668 "vcardArray":[ 669 "vcard", 670 [ 671 ["version", {}, "text", "4.0"], 672 ["fn", {}, "text", "Joe User"], 673 ["n", {}, "text", 674 ["User", "Joe", "", "", ["ing. jr", "M.Sc."]] 675 ], 676 ["bday", {}, "date-and-or-time", "--02-03"], 677 ["anniversary", 678 {}, "date-and-or-time", "2009-08-08T14:30:00-05:00" 679 ], 680 ["gender", {}, "text", "M"], 681 ["kind", {}, "text", "individual"], 682 ["lang", { 683 "pref":"1" 684 }, "language-tag", "fr"], 685 ["lang", { 686 "pref":"2" 687 }, "language-tag", "en"], 688 ["org", { 689 "type":"work" 690 }, "text", "Example"], 691 ["title", {}, "text", "Research Scientist"], 692 ["role", {}, "text", "Project Lead"], 693 ["adr", 694 { "type":"work" }, 695 "text", 696 [ 697 "", 698 "Suite 1234", 699 "4321 Rue Somewhere", 700 "Quebec", 701 "QC", 702 "G1V 2M2", 703 "Canada" 704 ] 705 ], 706 ["adr", 707 { 708 "type":"home", 709 "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n" 710 }, 711 "text", 712 [ 713 "", "", "", "", "", "", "" 714 ] 715 ], 716 ["tel", 717 { 718 "type":["work", "voice"], 719 "pref":"1" 720 }, 721 "uri", 722 "tel:+1-555-555-1234;ext=102" 723 ], 724 ["tel", 725 { "type":["work", "cell", "voice", "video", "text"] }, 726 "uri", 727 "tel:+1-555-555-4321" 728 ], 729 ["email", 730 { "type":"work" }, 731 "text", 732 "joe.user@example.com" 733 ], 734 ["geo", { 735 "type":"work" 736 }, "uri", "geo:46.772673,-71.282945"], 737 ["key", 738 { "type":"work" }, 739 "uri", 740 "http://www.example.com/joe.user/joe.asc" 741 ], 742 ["tz", {}, 743 "utc-offset", "-05:00"], 744 ["url", { "type":"home" }, 745 "uri", "http://example.org"] 746 ] 747 ], 748 "roles":[ "registrar" ], 749 "publicIds":[ 750 { 751 "type":"IANA Registrar ID", 752 "identifier":"1" 753 } 754 ], 755 "remarks":[ 756 { 757 "description":[ 758 "She sells sea shells down by the sea shore.", 759 "Originally written by Terry Sullivan." 760 ] 761 } 762 ], 763 "links":[ 764 { 765 "value":"http://example.com/entity/XXXX", 766 "rel":"self", 767 "href":"http://example.com/entity/XXXX", 768 "type" : "application/rdap+json" 769 } 770 ], 771 "events":[ 772 { 773 "eventAction":"registration", 774 "eventDate":"1990-12-31T23:59:60Z" 775 } 776 ], 777 "asEventActor":[ 778 { 779 "eventAction":"last changed", 780 "eventDate":"1991-12-31T23:59:60Z" 781 } 782 ] 783 } 785 Entities may also have other entities embedded with them in an array. 786 This can be used to model an organization with specific individuals 787 fulfilling designated roles of responsibility. 789 The following is an elided example of an entity with embedded 790 entities. 792 { 793 "handle" : "ANENTITY", 794 "roles" : [ "registrar" ], 795 ... 796 "entities" : 797 [ 798 { 799 "handle": "ANEMBEDDEDENTITY", 800 "roles" : [ "technical" ], 801 ... 802 }, 803 ... 804 ], 805 ... 806 } 808 Figure 12 810 This object has the following members: 812 o handle -- a string representing an registry unique identifier of 813 the entity 815 o vcardArray -- a JSON vCard with the entity's contact information 817 o roles -- an array of strings, each signifying the relationship an 818 object would have with its closest containing object (see 819 Section 10.2.3 for a list of values) 821 o publicIds - see Section 5.8 823 o entities - an array of entity objects as defined by this section. 825 o remarks -- see Section 5.3 827 o links -- see Section 5.2 829 o events -- see Section 5.5 831 o asEventActor -- this data structure takes the same form as the 832 'events' data structure (see Section 5.5), but each object in the 833 array MUST NOT have an 'eventActor' member. These objects denote 834 that the entity is an event actor for the given events. See 835 Appendix B regarding the various ways events can be modeled. 837 o status -- see Section 5.6 838 o port43 -- see Section 5.7 840 The following is an example of a entity that might be served by a 841 DNR. For illustrative purposes, it does not include rdapConformance 842 or notices data structures. 844 { 845 "handle":"XXXX", 846 "vcardArray":[ 847 "vcard", 848 [ 849 ["version", {}, "text", "4.0"], 850 ["fn", {}, "text", "Joe User"], 851 ["kind", {}, "text", "individual"], 852 ["lang", { 853 "pref":"1" 854 }, "language-tag", "fr"], 855 ["lang", { 856 "pref":"2" 857 }, "language-tag", "en"], 858 ["org", { 859 "type":"work" 860 }, "text", "Example"], 861 ["title", {}, "text", "Research Scientist"], 862 ["role", {}, "text", "Project Lead"], 863 ["adr", 864 { "type":"work" }, 865 "text", 866 [ 867 "", 868 "Suite 1234", 869 "4321 Rue Somewhere", 870 "Quebec", 871 "QC", 872 "G1V 2M2", 873 "Canada" 874 ] 875 ], 876 ["tel", 877 { "type":["work", "voice"], "pref":"1" }, 878 "uri", "tel:+1-555-555-1234;ext=102" 879 ], 880 ["email", 881 { "type":"work" }, 882 "text", "joe.user@example.com" 883 ], 884 ] 886 ], 887 "status":[ "validated", "locked" ], 888 "remarks":[ 889 { 890 "description":[ 891 "She sells sea shells down by the sea shore.", 892 "Originally written by Terry Sullivan." 893 ] 894 } 895 ], 896 "links":[ 897 { 898 "value":"http://example.com/entity/XXXX", 899 "rel":"self", 900 "href":"http://example.com/entity/XXXX", 901 "type":"application/rdap+json" 902 } 903 ], 904 "port43":"whois.example.net", 905 "events":[ 906 { 907 "eventAction":"registration", 908 "eventDate":"1990-12-31T23:59:60Z" 909 }, 910 { 911 "eventAction":"last changed", 912 "eventDate":"1991-12-31T23:59:60Z", 913 "eventActor":"joe@example.com" 914 } 915 ] 916 } 918 See Appendix A for use of the entity object class to model various 919 types of entities found in both RIRs and DNRs. See Appendix C 920 regarding structured vs. unstructured postal addresses in entities. 922 6.2. The Nameserver Object Class 924 The nameserver object class represents information regarding DNS name 925 servers used in both forward and reverse DNS. RIRs and some DNRs 926 register or expose nameserver information as an attribute of a domain 927 name, while other DNRs model nameservers as "first class objects". 929 The nameserver object class accommodates both models and degrees of 930 variation in between. 932 The following is an example of a nameserver object. For illustrative 933 purposes, it does not include rdapConformance or notices data 934 structures. 936 { 937 "handle" : "XXXX", 938 "ldhName" : "ns1.xn--fo-5ja.example", 939 "unicodeName" : "foo.example", 940 "status" : [ "active" ], 941 "ipAddresses" : 942 { 943 "v4": [ "192.0.2.1", "192.0.2.2" ], 944 "v6": [ "2001:db8::123" ] 945 }, 946 "remarks" : 947 [ 948 { 949 "description" : 950 [ 951 "She sells sea shells down by the sea shore.", 952 "Originally written by Terry Sullivan." 953 ] 954 } 955 ], 956 "links" : 957 [ 958 { 959 "value" : "http://example.net/nameserver/xxxx", 960 "rel" : "self", 961 "href" : "http://example.net/nameserver/xxxx", 962 "type" : "application/rdap+json" 963 } 964 ], 965 "port43" : "whois.example.net", 966 "events" : 967 [ 968 { 969 "eventAction" : "registration", 970 "eventDate" : "1990-12-31T23:59:60Z" 971 }, 972 { 973 "eventAction" : "last changed", 974 "eventDate" : "1991-12-31T23:59:60Z", 975 "eventActor" : "joe@example.com" 976 } 977 ] 978 } 980 Figure 13 982 Figure 13 is an example of a nameserver object with all values given. 983 Registries using a first-class nameserver data model would embed this 984 in domain objects as well as allowing references to it with the "/ 985 nameserver" query type (all depending on the registry operators 986 policy). Other registries may pare back the information as needed. 987 Figure 14 is an example of a nameserver object as would be found in 988 RIRs and some DNRs, while Figure 15 is an example of a nameserver 989 object as would be found in other DNRs. 991 The following is an example of the simplest nameserver object: 993 { 994 "ldhName" : "ns1.example.com" 995 } 997 Figure 14 999 The following is an example of a simple nameserver object that might 1000 be commonly used by DNRs: 1002 { 1003 "ldhName" : "ns1.example.com", 1004 "ipAddresses" : { "v6" : [ "2001:db8::123", "2001:db8::124" ] } 1005 } 1007 Figure 15 1009 As nameservers can be modeled by some registries to be first-class 1010 objects, they may also have an array of entities (Section 6.1) 1011 embedded to signify parties responsible for the maintenance, 1012 registrations, etc. of the nameservers. 1014 The following is an elided example of a nameserver with embedded 1015 entities. 1017 { 1018 "handle" : "XXXX", 1019 "ldhName" : "ns1.xn--fo-5ja.example", 1020 ... 1021 "entities" : 1022 [ 1023 ... 1024 ], 1025 ... 1026 } 1028 Figure 16 1030 The nameserver object class has the following members: 1032 o handle -- a string representing an registry unique identifier of 1033 the nameserver 1035 o ldhName -- a string containing the LDH name of the nameserver (see 1036 Section 4) 1038 o unicodeName -- a string containing a DNS Unicode name of the 1039 nameserver (see Section 4) 1041 o ipAddresses -- an object containing the following members: 1043 * v6 -- an array of strings containing IPv6 addresses of the 1044 nameserver 1046 * v4 -- an array of strings containing IPv4 addresses of the 1047 nameserver 1049 o entities -- an array of entity objects as defined by Section 6.1. 1051 o status - see Section 5.6 1053 o remarks - see Section 5.3 1055 o links - see Section 5.2 1057 o port43 - see Section 5.7 1059 o events - see Section 5.5 1061 6.3. The Domain Object Class 1062 The domain object class represents a DNS name and point of 1063 delegation. For RIRs these delegation points are in the reverse DNS 1064 tree, whereas for DNRs these delegation points are in the forward DNS 1065 tree. 1067 In both cases, the high level structure of the domain object class 1068 consists of information about the domain registration, nameserver 1069 information related to the domain name, and entities related to the 1070 domain name (e.g. registrant information, contacts, etc.). 1072 The following is an elided example of the domain object showing the 1073 high level structure: 1075 { 1076 "handle" : "XXX", 1077 "ldhName" : "blah.example.com", 1078 ... 1079 "nameServers" : 1080 [ 1081 ... 1082 ], 1083 ... 1084 "entities" : 1085 [ 1086 ... 1087 ] 1088 } 1090 The following is a description of the members of this object: 1092 o handle -- a string representing a registry unique identifier of 1093 the domain object instance 1095 o ldhName -- a string describing a domain name in LDH form as 1096 described in Section 4 1098 o unicodeName -- a string containing a domain name with U-labels as 1099 described in Section 4 1101 o variants -- an array of objects, each containing the following 1102 values: 1104 * relation -- an array of strings, with each string denoting the 1105 relationship between the variants and the containing domain 1106 object (see Section 10.2.4 for a list of suggested variant 1107 relations). 1109 * idnTable -- the name of the IDN table of codepoints, such as 1110 one listed with the IANA (see IDN tables [IANA_IDNTABLES]). 1112 * variantNames -- an array of objects, with each object 1113 containing an "ldhName" member and a "unicodeName" member (see 1114 Section 4). 1116 o nameservers -- an array of nameserver objects as defined by 1117 Section 6.2 1119 o secureDNS -- an object with the following members: 1121 * zoneSigned -- boolean true if the zone has been signed, false 1122 otherwise. 1124 * delegationSigned -- boolean true if there are DS records in the 1125 parent, false otherwise. 1127 * maxSigLife -- an integer representing the signature life time 1128 in seconds to be used when creating the RRSIG DS record in the 1129 parent zone [RFC5910]. 1131 * dsData - an array of objects, each with the following members: 1133 + keyTag -- an integer as specified by the key tag field of a 1134 DNS DS record as specified by RFC 4034 RFC 4034 [RFC4034] in 1135 presentation format 1137 + algorithm -- an integer as specified by the algorithm field 1138 of a DNS DS record as specified by RFC 4034 in presentation 1139 format 1141 + digest -- a string as specified by the digest field of a DNS 1142 DS record as specified by RFC 4034 in presentation format 1144 + digestType -- an integer as specified by the digest type 1145 field of a DNS DS record as specified by RFC 4034 in 1146 presentation format 1148 + events - see Section 5.5 1150 + links - see Section 5.2 1152 * keyData - an array of objects, each with the following members: 1154 + flags -- an integer representing the flags field value in 1155 the DNSKEY record [RFC4034] in presentation format. 1157 + protocol - an integer representation of the protocol field 1158 value of the DNSKEY record [RFC4034] in presentation format. 1160 + publicKey - a string representation of the public key in the 1161 DNSKEY record [RFC4034] in presentation format. 1163 + algorithm -- an integer as specified by the algorithm field 1164 of a DNSKEY record as specified by RFC 4034 [RFC4034] in 1165 presentation format 1167 + events - see Section 5.5 1169 + links - see Section 5.2 1171 See Appendix D for background information on these objects. 1173 o entities -- an array of entity objects as defined by Section 6.1. 1175 o status - see Section 5.6 1177 o publicIds - see Section 5.8 1179 o remarks - see Section 5.3 1181 o links - see Section 5.2 1183 o port43 - see Section 5.7 1185 o events - see Section 5.5 1187 The following is an example of a JSON domain object representing a 1188 reverse DNS delegation point that might be served by an RIR. For 1189 illustrative purposes, it does not include rdapConformance or notices 1190 data structures. 1192 { 1193 "handle" : "XXXX", 1194 "ldhName" : "192.in-addr.arpa", 1195 "nameServers" : 1196 [ 1197 { "ldhName" : "ns1.rir.example" }, 1198 { "ldhName" : "ns2.rir.example" } 1200 ], 1201 "secureDNS": 1202 { 1203 "delegationSigned": true, 1204 "dsData": 1205 [ 1206 { 1207 "keyTag": 12345, 1208 "algorithm": 3, 1209 "digestType": 1, 1210 "digest": "49FD46E6C4B45C55D4AC", 1211 } 1212 ] 1213 }, 1214 "remarks" : 1215 [ 1216 { 1217 "description" : 1218 [ 1219 "She sells sea shells down by the sea shore.", 1220 "Originally written by Terry Sullivan." 1221 ] 1222 } 1223 ], 1224 "links" : 1225 [ 1226 { 1227 "value": "http://example.net/domain/XXXX", 1228 "rel" : "self", 1229 "href" : "http://example.net/domain/XXXXX", 1230 "type" : "application/rdap+json" 1231 } 1232 ], 1233 "events" : 1234 [ 1235 { 1236 "eventAction" : "registration", 1237 "eventDate" : "1990-12-31T23:59:60Z" 1238 }, 1239 { 1240 "eventAction" : "last changed", 1241 "eventDate" : "1991-12-31T23:59:60Z", 1242 "eventActor" : "joe@example.com" 1243 } 1244 ], 1245 "entities" : 1246 [ 1247 { 1248 "handle" : "XXXX", 1249 "vcardArray":[ 1250 "vcard", 1251 [ 1252 ["version", {}, "text", "4.0"], 1253 ["fn", {}, "text", "Joe User"], 1254 ["kind", {}, "text", "individual"], 1255 ["lang", { 1256 "pref":"1" 1257 }, "language-tag", "fr"], 1258 ["lang", { 1259 "pref":"2" 1260 }, "language-tag", "en"], 1261 ["org", { 1262 "type":"work" 1263 }, "text", "Example"], 1264 ["title", {}, "text", "Research Scientist"], 1265 ["role", {}, "text", "Project Lead"], 1266 ["adr", 1267 { "type":"work" }, 1268 "text", 1269 [ 1270 "", 1271 "Suite 1234", 1272 "4321 Rue Somewhere", 1273 "Quebec", 1274 "QC", 1275 "G1V 2M2", 1276 "Canada" 1277 ] 1278 ], 1279 ["tel", 1280 { "type":["work", "voice"], "pref":"1" }, 1281 "uri", "tel:+1-555-555-1234;ext=102" 1282 ], 1283 ["email", 1284 { "type":"work" }, 1285 "text", "joe.user@example.com" 1286 ], 1287 ] 1288 ], 1289 "roles" : [ "registrant" ], 1290 "remarks" : 1291 [ 1292 { 1293 "description" : 1294 [ 1295 "She sells sea shells down by the sea shore.", 1296 "Originally written by Terry Sullivan." 1297 ] 1298 } 1299 ], 1300 "links" : 1301 [ 1302 { 1303 "value": "http://example.net/entity/xxxx", 1304 "rel" : "self", 1305 "href" : "http://example.net/entity/xxxx", 1306 "type" : "application/rdap+json" 1307 } 1308 ], 1309 "events" : 1310 [ 1311 { 1312 "eventAction" : "registration", 1313 "eventDate" : "1990-12-31T23:59:60Z" 1314 }, 1315 { 1316 "eventAction" : "last changed", 1317 "eventDate" : "1991-12-31T23:59:60Z", 1318 "eventActor" : "joe@example.com" 1319 } 1320 ] 1321 } 1322 ] 1323 } 1325 The following is an example of a JSON domain object representing a 1326 forward DNS delegation point that might be served by a DNR. For 1327 illustrative purposes, it does not include rdapConformance or notices 1328 data structures. 1330 { 1331 "handle" : "XXXX", 1332 "ldhName" : "xn--fo-5ja.example", 1333 "unicodeName" : "foo.example", 1334 "variants" : 1335 [ 1336 { 1337 "relation" : [ "registered", "conjoined" ], 1338 "variantNames" : 1339 [ 1340 { 1341 "ldhName" : "xn--fo-cka.example", 1342 "unicodeName" : "foo.example" 1343 }, 1344 { 1345 "ldhName" : "xn--fo-fka.example", 1346 "unicodeName" : "foeo.example" 1347 } 1348 ] 1349 }, 1350 { 1351 "relation" : [ "unregistered", "restricted registration" ], 1352 "idnTable": ".EXAMPLE Swedish", 1353 "variantNames" : 1354 [ 1355 { 1356 "ldhName": "xn--fo-8ja.example", 1357 "unicodeName" : "foo.example" 1358 } 1359 ] 1360 } 1361 ], 1362 "status" : [ "locked", "transfer prohibited" ], 1363 "publicIds":[ 1364 { 1365 "type":"ENS_Auth ID", 1366 "identifier":"1234567890" 1367 } 1368 ], 1369 "nameServers" : 1370 [ 1371 { 1372 "handle" : "XXXX", 1373 "ldhName" : "ns1.example.com", 1374 "status" : [ "active" ], 1375 "ipAddresses" : 1376 { 1377 "v6": [ "2001:db8::123", "2001:db8::124" ], 1378 "v4": [ "192.0.2.1", "192.0.2.2" ] 1379 }, 1380 "remarks" : 1381 [ 1382 { 1383 "description" : 1384 [ 1385 "She sells sea shells down by the sea shore.", 1386 "Originally written by Terry Sullivan." 1387 ] 1388 } 1390 ], 1391 "links" : 1392 [ 1393 { 1394 "value" : "http://example.net/nameserver/XXXX", 1395 "rel" : "self", 1396 "href" : "http://example.net/nameserver/XXXX", 1397 "type" : "application/rdap+json" 1398 } 1399 ], 1400 "events" : 1401 [ 1402 { 1403 "eventAction" : "registration", 1404 "eventDate" : "1990-12-31T23:59:60Z" 1405 }, 1406 { 1407 "eventAction" : "last changed", 1408 "eventDate" : "1991-12-31T23:59:60Z" 1409 } 1410 ] 1411 }, 1412 { 1413 "handle" : "XXXX", 1414 "ldhName" : "ns2.example.com", 1415 "status" : [ "active" ], 1416 "ipAddresses" : 1417 { 1418 "v6" : [ "2001:db8::125", "2001:db8::126" ], 1419 "v4" : [ "192.0.2.3", "192.0.2.4" ] 1420 }, 1421 "remarks" : 1422 [ 1423 { 1424 "description" : 1425 [ 1426 "She sells sea shells down by the sea shore.", 1427 "Originally written by Terry Sullivan." 1428 ] 1429 } 1430 ], 1431 "links" : 1432 [ 1433 { 1434 "value" : "http://example.net/nameserver/XXXX", 1435 "rel" : "self", 1436 "href" : "http://example.net/nameserver/XXXX", 1437 "type" : "application/rdap+json" 1439 } 1440 ], 1441 "events" : 1442 [ 1443 { 1444 "eventAction" : "registration", 1445 "eventDate" : "1990-12-31T23:59:60Z" 1446 }, 1447 { 1448 "eventAction" : "last changed", 1449 "eventDate" : "1991-12-31T23:59:60Z" 1450 } 1451 ] 1452 } 1453 ], 1454 "secureDNS": 1455 { 1456 "zoneSigned": true, 1457 "delegationSigned": true, 1458 "maxSigLife": 604800, 1459 "keyData": 1460 [ 1461 { 1462 "flags": 257, 1463 "protocol": 3, 1464 "algorithm": 1, 1465 "publicKey": "AQPJ////4Q==", 1466 "events": 1467 [ 1468 { 1469 "eventAction": "last changed", 1470 "eventDate": "2012-07-23T05:15:47Z" 1471 } 1472 ] 1473 } 1474 ] 1475 }, 1476 "remarks" : 1477 [ 1478 { 1479 "description" : 1480 [ 1481 "She sells sea shells down by the sea shore.", 1482 "Originally written by Terry Sullivan." 1483 ] 1484 } 1485 ], 1486 "links" : 1488 [ 1489 { 1490 "value": "http://example.net/domain/XXXX", 1491 "rel" : "self", 1492 "href" : "http://example.net/domain/XXXX", 1493 "type" : "application/rdap+json" 1494 } 1495 ], 1496 "port43" : "whois.example.net", 1497 "events" : 1498 [ 1499 { 1500 "eventAction" : "registration", 1501 "eventDate" : "1990-12-31T23:59:60Z" 1502 }, 1503 { 1504 "eventAction" : "last changed", 1505 "eventDate" : "1991-12-31T23:59:60Z", 1506 "eventActor" : "joe@example.com" 1507 }, 1508 { 1509 "eventAction" : "transfer", 1510 "eventDate" : "1991-12-31T23:59:60Z", 1511 "eventActor" : "joe@example.com" 1512 }, 1513 { 1514 "eventAction" : "expiration", 1515 "eventDate" : "2016-12-31T23:59:60Z", 1516 "eventActor" : "joe@example.com" 1517 } 1518 ], 1519 "entities" : 1520 [ 1521 { 1522 "handle" : "XXXX", 1523 "vcardArray":[ 1524 "vcard", 1525 [ 1526 ["version", {}, "text", "4.0"], 1527 ["fn", {}, "text", "Joe User"], 1528 ["kind", {}, "text", "individual"], 1529 ["lang", { 1530 "pref":"1" 1531 }, "language-tag", "fr"], 1532 ["lang", { 1533 "pref":"2" 1534 }, "language-tag", "en"], 1535 ["org", { 1536 "type":"work" 1537 }, "text", "Example"], 1538 ["title", {}, "text", "Research Scientist"], 1539 ["role", {}, "text", "Project Lead"], 1540 ["adr", 1541 { "type":"work" }, 1542 "text", 1543 [ 1544 "", 1545 "Suite 1234", 1546 "4321 Rue Somewhere", 1547 "Quebec", 1548 "QC", 1549 "G1V 2M2", 1550 "Canada" 1551 ] 1552 ], 1553 ["tel", 1554 { "type":["work", "voice"], "pref":"1" }, 1555 "uri", "tel:+1-555-555-1234;ext=102" 1556 ], 1557 ["email", 1558 { "type":"work" }, 1559 "text", "joe.user@example.com" 1560 ], 1561 ] 1562 ], 1563 "status" : [ "validated", "locked" ], 1564 "roles" : [ "registrant" ], 1565 "remarks" : 1566 [ 1567 { 1568 "description" : 1569 [ 1570 "She sells sea shells down by the sea shore.", 1571 "Originally written by Terry Sullivan." 1572 ] 1573 } 1574 ], 1575 "links" : 1576 [ 1577 { 1578 "value" : "http://example.net/entity/xxxx", 1579 "rel" : "self", 1580 "href" : "http://example.net/entity/xxxx", 1581 "type" : "application/rdap+json" 1582 } 1583 ], 1584 "events" : 1585 [ 1586 { 1587 "eventAction" : "registration", 1588 "eventDate" : "1990-12-31T23:59:60Z" 1589 }, 1590 { 1591 "eventAction" : "last changed", 1592 "eventDate" : "1991-12-31T23:59:60Z" 1593 } 1594 ] 1595 } 1596 ] 1597 } 1599 6.4. The IP Network Object Class 1601 The IP Network object class models IP network registrations found in 1602 RIRs and is the expected response for the "/ip" query as defined by 1603 [I-D.ietf-weirds-rdap-query]. There is no equivalent object class 1604 for DNRs. The high level structure of the IP network object class 1605 consists of information about the network registration and entities 1606 related to the IP network (e.g. registrant information, contacts, 1607 etc...). 1609 The following is an elided example of the IP network object type 1610 showing the high level structure: 1612 { 1613 "handle" : "XXX", 1614 ... 1615 "entities" : 1616 [ 1617 ... 1618 ] 1619 } 1621 The following is an example of the JSON object for the network 1622 registration information. For illustrative purposes, it does not 1623 include rdapConformance or notices data structures. 1625 { 1626 "handle" : "XXXX-RIR", 1627 "startAddress" : "2001:db8::0", 1628 "endAddress" : "2001:db8::0:FFFF:FFFF:FFFF:FFFF:FFFF", 1629 "ipVersion" : "v6", 1630 "name": "NET-RTR-1", 1631 "type" : "DIRECT ALLOCATION", 1632 "country" : "AU", 1633 "parentHandle" : "YYYY-RIR", 1634 "status" : [ "allocated" ], 1635 "remarks" : 1636 [ 1637 { 1638 "description" : 1639 [ 1640 "She sells sea shells down by the sea shore.", 1641 "Originally written by Terry Sullivan." 1642 ] 1643 } 1644 ], 1645 "links" : 1646 [ 1647 { 1648 "value" : "http://example.ent/ip/2001:db8::/48", 1649 "rel" : "self", 1650 "href" : "http://example.net/ip/2001:db8::/48", 1651 "type" : "application/rdap+json" 1652 }, 1653 { 1654 "value" : "http://example.net/ip/2001:db8::/48", 1655 "rel" : "up", 1656 "href" : "http://example.net/ip/2001:C00::/23", 1657 "type" : "application/rdap+json" 1658 } 1659 ], 1660 "events" : 1661 [ 1662 { 1663 "eventAction" : "registration", 1664 "eventDate" : "1990-12-31T23:59:60Z" 1665 }, 1666 { 1667 "eventAction" : "last changed", 1668 "eventDate" : "1991-12-31T23:59:60Z" 1669 } 1670 ], 1671 "entities" : 1672 [ 1673 { 1674 "handle" : "XXXX", 1675 "vcardArray":[ 1676 "vcard", 1677 [ 1678 ["version", {}, "text", "4.0"], 1679 ["fn", {}, "text", "Joe User"], 1680 ["kind", {}, "text", "individual"], 1681 ["lang", { 1682 "pref":"1" 1683 }, "language-tag", "fr"], 1684 ["lang", { 1685 "pref":"2" 1686 }, "language-tag", "en"], 1687 ["org", { 1688 "type":"work" 1689 }, "text", "Example"], 1690 ["title", {}, "text", "Research Scientist"], 1691 ["role", {}, "text", "Project Lead"], 1692 ["adr", 1693 { "type":"work" }, 1694 "text", 1695 [ 1696 "", 1697 "Suite 1234", 1698 "4321 Rue Somewhere", 1699 "Quebec", 1700 "QC", 1701 "G1V 2M2", 1702 "Canada" 1703 ] 1704 ], 1705 ["tel", 1706 { "type":["work", "voice"], "pref":"1" }, 1707 "uri", "tel:+1-555-555-1234;ext=102" 1708 ], 1709 ["email", 1710 { "type":"work" }, 1711 "text", "joe.user@example.com" 1712 ], 1713 ] 1714 ], 1715 "roles" : [ "registrant" ], 1716 "remarks" : 1717 [ 1718 { 1719 "description" : 1720 [ 1721 "She sells sea shells down by the sea shore.", 1722 "Originally written by Terry Sullivan." 1723 ] 1724 } 1725 ], 1726 "links" : 1727 [ 1728 { 1729 "value" : "http://example.net/entity/xxxx", 1730 "rel" : "self", 1731 "href" : "http://example.net/entity/xxxx", 1732 "type" : "application/rdap+json" 1733 } 1734 ], 1735 "events" : 1736 [ 1737 { 1738 "eventAction" : "registration", 1739 "eventDate" : "1990-12-31T23:59:60Z" 1740 }, 1741 { 1742 "eventAction" : "last changed", 1743 "eventDate" : "1991-12-31T23:59:60Z" 1744 } 1745 ] 1746 } 1747 ] 1748 } 1750 The following is a description of the members of this object: 1752 o handle -- a string representing an RIR unique identifier of the 1753 network registration 1755 o startAddress -- the starting IP address of the network, either 1756 IPv4 or IPv6 1758 o endAddress -- the ending IP address of the network, either IPv4 or 1759 IPv6 1761 o ipVersion -- a string signifying the IP protocol version of the 1762 network: "v4" signifying an IPv4 network, "v6" signifying an IPv6 1763 network 1765 o name -- an identifier assigned to the network registration by the 1766 registration holder 1768 o type -- a string containing an RIR-specific classification of the 1769 network 1771 o country -- a string containing the name of the 2 character country 1772 code of the network 1774 o parentHandle -- a string containing an RIR-unique identifier of 1775 the parent network of this network registration 1777 o status -- an array of strings indicating the state of the IP 1778 network 1780 o entities -- an array of entity objects as defined by Section 6.1. 1782 o remarks - see Section 5.3 1784 o links - see Section 5.2 1786 o port43 - see Section 5.7 1788 o events - see Section 5.5 1790 6.5. Autonomous System Number Entity Object Class 1792 The Autonomous System Number (autnum) object class models Autonomous 1793 System Number registrations found in RIRs and represents the expected 1794 response to an "/autnum" query as defined by 1795 [I-D.ietf-weirds-rdap-query]. There is no equivalent object class 1796 for DNRs. The high level structure of the autnum object class 1797 consists of information about the network registration and entities 1798 related to the autnum registration (e.g. registrant information, 1799 contacts, etc.), and is similar to the IP Network entity object 1800 class. 1802 The following is an example of a JSON object representing an autnum. 1803 For illustrative purposes, it does not include rdapConformance or 1804 notices data structures. 1806 { 1807 "handle" : "XXXX-RIR", 1808 "startAutnum" : 10, 1809 "endAutnum" : 15, 1810 "name": "AS-RTR-1", 1811 "type" : "DIRECT ALLOCATION", 1812 "status" : [ "allocated" ], 1813 "country": "AU", 1814 "remarks" : 1816 [ 1817 { 1818 "description" : 1819 [ 1820 "She sells sea shells down by the sea shore.", 1821 "Originally written by Terry Sullivan." 1822 ] 1823 } 1824 ], 1825 "links" : 1826 [ 1827 { 1828 "value" : "http://example.net/autnum/xxxx", 1829 "rel" : "self", 1830 "href" : "http://example.net/autnum/xxxx", 1831 "type" : "application/rdap+json" 1832 } 1833 ], 1834 "events" : 1835 [ 1836 { 1837 "eventAction" : "registration", 1838 "eventDate" : "1990-12-31T23:59:60Z" 1839 }, 1840 { 1841 "eventAction" : "last changed", 1842 "eventDate" : "1991-12-31T23:59:60Z" 1843 } 1844 ], 1845 "entities" : 1846 [ 1847 { 1848 "handle" : "XXXX", 1849 "vcardArray":[ 1850 "vcard", 1851 [ 1852 ["version", {}, "text", "4.0"], 1853 ["fn", {}, "text", "Joe User"], 1854 ["kind", {}, "text", "individual"], 1855 ["lang", { 1856 "pref":"1" 1857 }, "language-tag", "fr"], 1858 ["lang", { 1859 "pref":"2" 1860 }, "language-tag", "en"], 1861 ["org", { 1862 "type":"work" 1863 }, "text", "Example"], 1865 ["title", {}, "text", "Research Scientist"], 1866 ["role", {}, "text", "Project Lead"], 1867 ["adr", 1868 { "type":"work" }, 1869 "text", 1870 [ 1871 "", 1872 "Suite 1234", 1873 "4321 Rue Somewhere", 1874 "Quebec", 1875 "QC", 1876 "G1V 2M2", 1877 "Canada" 1878 ] 1879 ], 1880 ["tel", 1881 { "type":["work", "voice"], "pref":"1" }, 1882 "uri", "tel:+1-555-555-1234;ext=102" 1883 ], 1884 ["email", 1885 { "type":"work" }, 1886 "text", "joe.user@example.com" 1887 ], 1888 ] 1889 ], 1890 "roles" : [ "registrant" ], 1891 "remarks" : 1892 [ 1893 { 1894 "description" : 1895 [ 1896 "She sells sea shells down by the sea shore.", 1897 "Originally written by Terry Sullivan." 1898 ] 1899 } 1900 ], 1901 "links" : 1902 [ 1903 { 1904 "value" : "http://example.net/entity/XXXX", 1905 "rel" : "self", 1906 "href" : "http://example.net/entity/XXXX", 1907 "type" : "application/rdap+json" 1908 } 1909 ], 1910 "events" : 1911 [ 1912 { 1913 "eventAction" : "registration", 1914 "eventDate" : "1990-12-31T23:59:60Z" 1915 }, 1916 { 1917 "eventAction" : "last changed", 1918 "eventDate" : "1991-12-31T23:59:60Z" 1919 } 1920 ] 1921 } 1922 ] 1923 } 1925 The following is a description of the members of this object: 1927 o handle -- a string representing an RIR-unique identifier of the 1928 autnum registration 1930 o startAutnum -- a number representing the starting number [RFC5396] 1931 in the block of autonomous system numbers 1933 o endAutnum -- a number representing the ending number [RFC5396] in 1934 the block of autonomous system numbers 1936 o name -- an identifier assigned to the autnum registration by the 1937 registration holder 1939 o type -- a string containing an RIR-specific classification of the 1940 autnum 1942 o status -- an array of strings indicating the state of the autnum 1944 o country -- a string containing the name of the 2 character country 1945 code of the autnum 1947 o entities -- an array of entity objects as defined by Section 6.1. 1949 o remarks - see Section 5.3 1951 o links - see Section 5.2 1953 o port43 - see Section 5.7 1955 o events - see Section 5.5 1957 7. Error Response Body 1958 Some non-answer responses may return entity bodies with information 1959 that could be more descriptive. 1961 The basic structure of that response is an object class containing an 1962 error code number (corresponding to the HTTP response code) followed 1963 by a string named "title" followed by an array of strings named 1964 "description". 1966 This is an example of the common response body. For illustrative 1967 purposes, it does not include rdapConformance or notices data 1968 structures. 1970 { 1971 "errorCode": 418, 1972 "title": "Your beverage choice is not available", 1973 "description": 1974 [ 1975 "I know coffee has more ummppphhh.", 1976 "Sorry, dude!" 1977 ] 1978 } 1980 Figure 17 1982 A client MAY simply use the HTTP response code as the server is not 1983 required to include error data in the response body. However, if a 1984 client wishes to parse the error data, it SHOULD first check that the 1985 Content-Type header contains the appropriate media type. 1987 This is an example of the common response body with and 1988 rdapConformance and notices data structures: 1990 { 1991 "rdapConformance" : 1992 [ 1993 "rdap_level_0" 1994 ], 1995 "notices" : 1996 [ 1997 { 1998 "title" : "Beverage policy", 1999 "description" : 2000 [ 2001 "Beverages with caffeine for keeping horses awake." 2002 ], 2003 "links" : 2004 [ 2005 { 2006 "value" : "http://example.net/ip/192.0.2.0/24", 2007 "rel" : "alternate", 2008 "type" : "text/html", 2009 "href" : "http://www.example.com/redaction_policy.html" 2010 } 2011 ] 2012 } 2013 ], 2014 "lang" : "en", 2015 "errorCode": 418, 2016 "title": "Your beverage choice is not available", 2017 "description": 2018 [ 2019 "I know coffee has more ummppphhh.", 2020 "Sorry, dude!" 2021 ] 2022 } 2024 Figure 18 2026 8. Responding to Help Queries 2028 The appropriate response to /help queries as defined by 2029 [I-D.ietf-weirds-rdap-query] is to use the notices structure as 2030 defined in Section 5.3. 2032 This is an example of a response to a /help query including the 2033 rdapConformance data structure. 2035 { 2036 "rdapConformance" : 2037 [ 2038 "rdap_level_0" 2039 ], 2040 "notices" : 2041 [ 2042 { 2043 "title" : "Authentication Policy", 2044 "description" : 2045 [ 2046 "Access to sensitive data for users with proper credentials." 2047 ], 2048 "links" : 2049 [ 2050 { 2051 "value" : "http://example.net/help", 2052 "rel" : "alternate", 2053 "type" : "text/html", 2054 "href" : "http://www.example.com/auth_policy.html" 2055 } 2056 ] 2057 } 2058 ] 2059 } 2061 Figure 19 2063 9. Responding To Searches 2065 [I-D.ietf-weirds-rdap-query] specifies three types of searches: 2066 domains, nameservers, and entities. Responses to these searches take 2067 the form of an array of object instances where each instance is an 2068 appropriate object class for the search (i.e. a search for /domains 2069 yields an array of domain object instances). These arrays are 2070 contained within the response object. 2072 The names of the arrays are as follows: 2074 o for /domains searches, the array is "domains" 2076 o for /nameservers searches, the array is "nameservers" 2078 o for /entities searches, the array is "entities" 2080 The following is an elided example of a response to a /domains 2081 search. 2083 { 2084 "rdapConformance" : 2085 [ 2086 "rdap_level_0" 2087 ], 2088 ... 2089 "domains" : 2090 [ 2091 { 2092 "handle" : "1-XXXX", 2093 "name" : "1.example.com", 2094 ... 2095 }, 2096 { 2097 "handle" : "2-XXXX", 2098 "name" : "2.example.com", 2099 ... 2100 } 2101 ] 2102 } 2104 search_response_example 2106 In addition to the arrays, the response object may contain a member 2107 named "searchResultsTruncated" which is a boolean. When this value 2108 is set to true, it indicates the accompanying array did not contain 2109 all of the data that matched the search criteria. When this value is 2110 true, it is recommended that servers include a textual description 2111 for the truncation in a notices structure. 2113 The following is an elided example of a search response that has been 2114 truncated. 2116 { 2117 "rdapConformance" : 2118 [ 2119 "rdap_level_0" 2120 ], 2121 "notices" : 2122 [ 2123 { 2124 "title" : "Search Policy", 2125 "description" : 2126 [ 2127 "Search results are limited to 25 per day per querying IP." 2128 ], 2129 "links" : 2130 [ 2131 { 2132 "value" : "http://example.net/help", 2133 "rel" : "alternate", 2134 "type" : "text/html", 2135 "href" : "http://www.example.com/search_policy.html" 2136 } 2137 ] 2138 } 2139 ], 2140 "searchResultsTruncated" : true 2141 "domains" : 2142 [ 2143 ... 2144 ] 2145 } 2147 search_response_truncated_example 2149 10. IANA Considerations 2151 10.1. RDAP JSON Media Type Registration 2153 This specification registers the "application/rdap+json" media type. 2155 Type name: application 2157 Subtype name: rdap+json 2159 Required parameters: n/a 2161 Encoding considerations: See section 3.1 of [RFC6839]. 2163 Security considerations: The media represented by this identifier 2164 does not have security considerations beyond that found in section 2165 6 of [RFC4627] 2167 Interoperability considerations: There are no known 2168 interoperability problems regarding this media format. 2170 Published specification: [[ this document ]] 2172 Applications that use this media type: Implementations of the 2173 Registration Data Access Protocol (RDAP) 2175 Additional information: This media type is a product of the IETF 2176 WEIRDS working group. The WEIRDS charter, information on the 2177 WEIRDS mailing list, and other documents produced by the WEIRDS 2178 working group can be found at https://datatracker.ietf.org/wg/ 2179 weirds/ [1] 2181 Person & email address to contact for further information: Andy 2182 Newton 2184 Intended usage: COMMON 2186 Restrictions on usage: none 2188 Author: Andy Newton 2190 Change controller: IETF 2192 Provisional Registration: No (upon publication of this RFC) 2194 10.2. JSON Values Registry 2196 This section requests that the IANA establish an RDAP JSON Values 2197 Registry for use in the status (Section 5.6), role (Section 6.1), 2198 event action (Section 5.5), and domain variant relation (Section 6.3) 2199 fields specified in RDAP. 2201 Each entry in the registry should contain the following fields: 2203 1. Value - the string value being registered. 2205 2. Type - the type of value being registered. It should be one of 2206 the following: 2208 * 'status' - denotes a value for the 'status' object member as 2209 defined by Section 5.6. 2211 * 'role' - denotes a value for the 'role' array as defined in 2212 Section 6.1. 2214 * 'event action' - denotes a value for an event action as 2215 defined in Section 5.5. 2217 * 'domain variant relation' - denotes a relationship between a 2218 domain and a domain variant as defined in Section 6.3. 2220 3. Description - a one or two sentence description regarding the 2221 meaning of the value, how it might be used, and/or how it should 2222 be interpreted by clients. 2224 4. Registrant Name - the name of the person registering the value. 2226 5. Registrant Contact Information - an email address, postal 2227 address, or some other information to be used to contact the 2228 registrant. 2230 This registry should be governed by a designated expert or multiple 2231 designated experts. Registration of values into this registry should 2232 be accomplished by providing the information above to the designated 2233 expert(s). 2235 Review of registrations into this registry by the designated 2236 expert(s) should be narrowly judged on the following criteria: 2238 1. Values in need of being placed into multiple types must be 2239 assigned a separate registration for each type. 2241 2. Values must be strings. They can be multiple words separated by 2242 single space characters. Every character should be lowercased. 2243 If possible, every word should be given in English and each 2244 character should be US ASCII. 2246 3. Registrations should not duplicate the meaning of any existing 2247 registration. That is, if a request for a registration is 2248 significantly similar in nature to an existing registration, the 2249 request should be denied. For example, the terms 'maintainer' 2250 and 'registrant' are significantly similar in nature as they both 2251 denote a holder of a domain name or Internet number resource. In 2252 cases where it may be reasonably argued that machine 2253 interpretation of two similar values may alter the operation of 2254 client software, designated experts should not judge the values 2255 to be of significant similarity. 2257 4. Registrations should be relevant to the common usages of RDAP. 2258 Designated experts may rely upon the serving of the value by a 2259 DNR or RIR to make this determination. 2261 10.2.1. Status 2263 This section registers the following values into the RDAP JSON Values 2264 Registry: 2266 1. 2268 * Value: validated 2270 * Type: status 2272 * Description: Signifies that the data of the object instance 2273 has been found to be accurate. This type of status is 2274 usually found on entity object instances to note the validity 2275 of identifying contact information. 2277 * Registrant Name: Andrew Newton 2279 * Registrant Contact Information: andy@hxr.us 2281 2. 2283 * Value: renew prohibited 2285 * Type: status 2287 * Description: Renewal or reregistration of the object instance 2288 is forbidden. 2290 * Registrant Name: Andrew Newton 2292 * Registrant Contact Information: andy@hxr.us 2294 3. 2296 * Value: update prohibited 2298 * Type: status 2300 * Description: Updates to the object instance are forbidden. 2302 * Registrant Name: Andrew Newton 2304 * Registrant Contact Information: andy@hxr.us 2306 4. 2308 * Value: transfer prohibited 2310 * Type: status 2312 * Description: Transfers of the registration from one registrar 2313 to another are forbidden. This type of status normally 2314 applies to DNR domain names. 2316 * Registrant Name: Andrew Newton 2318 * Registrant Contact Information: andy@hxr.us 2320 5. 2322 * Value: delete prohibited 2324 * Type: status 2326 * Description: Deletion of the registration of the object 2327 instance is forbidden. This type of status normally applies 2328 to DNR domain names. 2330 * Registrant Name: Andrew Newton 2332 * Registrant Contact Information: andy@hxr.us 2334 6. 2336 * Value: proxy 2338 * Type: status 2340 * Description: The registration of the object instance has been 2341 performed by a third party. This is most commonly applied to 2342 entities. 2344 * Registrant Name: Andrew Newton 2346 * Registrant Contact Information: andy@hxr.us 2348 7. 2350 * Value: private 2352 * Type: status 2353 * Description: The information of the object instance is not 2354 designated for public consumption. This is most commonly 2355 applied to entities. 2357 * Registrant Name: Andrew Newton 2359 * Registrant Contact Information: andy@hxr.us 2361 8. 2363 * Value: redacted 2365 * Type: status 2367 * Description: Some of the information of the object instance 2368 has not been made available. This is most commonly applied 2369 to entities. 2371 * Registrant Name: Andrew Newton 2373 * Registrant Contact Information: andy@hxr.us 2375 9. 2377 * Value: obscured 2379 * Type: status 2381 * Description: Some of the information of the object instance 2382 has been altered for the purposes of not readily revealing 2383 the actual information of the object instance. This is most 2384 commonly applied to entities. 2386 * Registrant Name: Andrew Newton 2388 * Registrant Contact Information: andy@hxr.us 2390 10. 2392 * Value: associated 2394 * Type: status 2396 * Description: The object instance is associated with other 2397 object instances in the registry. This is most commonly used 2398 to signify that a nameserver is associated with a domain or 2399 that an entity is associated with a network resource or 2400 domain. 2402 * Registrant Name: Andrew Newton 2404 * Registrant Contact Information: andy@hxr.us 2406 11. 2408 * Value: active 2410 * Type: status 2412 * Description: The object instance is in use. For domain 2413 names, it signifies that the domain name is published in DNS. 2414 For network and autnum registrations it signifies that they 2415 are allocated or assigned for use in operational networks. 2416 This maps to the EPP 'OK' status. 2418 * Registrant Name: Andrew Newton 2420 * Registrant Contact Information: andy@hxr.us 2422 12. 2424 * Value: inactive 2426 * Type: status 2428 * Description: The object instance is not in use. See 2429 'active'. 2431 * Registrant Name: Andrew Newton 2433 * Registrant Contact Information: andy@hxr.us 2435 13. 2437 * Value: locked 2439 * Type: status 2441 * Description: Changes to the object instance cannot be made, 2442 including the assocation of other object instances. 2444 * Registrant Name: Andrew Newton 2446 * Registrant Contact Information: andy@hxr.us 2448 14. 2450 * Value: pending create 2452 * Type: status 2454 * Description: A request has been received for the creation of 2455 the object instance but this action is not yet complete. 2457 * Registrant Name: Andrew Newton 2459 * Registrant Contact Information: andy@hxr.us 2461 15. 2463 * Value: pending renew 2465 * Type: status 2467 * Description: A request has been received for the renewal of 2468 the object instance but this action is not yet complete. 2470 * Registrant Name: Andrew Newton 2472 * Registrant Contact Information: andy@hxr.us 2474 16. 2476 * Value: pending transfer 2478 * Type: status 2480 * Description: A request has been received for the transfer of 2481 the object instance but this action is not yet complete. 2483 * Registrant Name: Andrew Newton 2485 * Registrant Contact Information: andy@hxr.us 2487 17. 2489 * Value: pending update 2491 * Type: status 2493 * Description: A request has been received for the update or 2494 modification of the object instance but this action is not 2495 yet complete. 2497 * Registrant Name: Andrew Newton 2498 * Registrant Contact Information: andy@hxr.us 2500 18. 2502 * Value: pending delete 2504 * Type: status 2506 * Description: A request has been received for the deletion or 2507 removal of the object instance but this action is not yet 2508 complete. For domains, this might mean that the name in no 2509 longer published in DNS but has not yet been purged from the 2510 registry database. 2512 * Registrant Name: Andrew Newton 2514 * Registrant Contact Information: andy@hxr.us 2516 10.2.2. Event Actions 2518 This section registers the following values into the RDAP JSON Values 2519 Registry: 2521 1. 2523 * Value: registration 2525 * Type: event action 2527 * Description: The object instance was initially registered. 2529 * Registrant Name: Andrew Newton 2531 * Registrant Contact Information: andy@hxr.us 2533 2. 2535 * Value: reregistration 2537 * Type: event action 2539 * Description: The object instance was registered subsequently 2540 to initial registration. 2542 * Registrant Name: Andrew Newton 2544 * Registrant Contact Information: andy@hxr.us 2546 3. 2548 * Value: last changed 2550 * Type: event action 2552 * Description: An action noting when the information in the 2553 object instance was last changed. 2555 * Registrant Name: Andrew Newton 2557 * Registrant Contact Information: andy@hxr.us 2559 4. 2561 * Value: expiration 2563 * Type: event action 2565 * Description: The object instance has been removed or will be 2566 removed at a pre-determined date and time from the registry. 2568 * Registrant Name: Andrew Newton 2570 * Registrant Contact Information: andy@hxr.us 2572 5. 2574 * Value: deletion 2576 * Type: event action 2578 * Description: The object instance was removed from the registry 2579 at a point in time that was not pre-determined. 2581 * Registrant Name: Andrew Newton 2583 * Registrant Contact Information: andy@hxr.us 2585 6. 2587 * Value: reinstantiation 2589 * Type: event action 2591 * Description: The object instance was reregistered after having 2592 been removed from the registry. 2594 * Registrant Name: Andrew Newton 2596 * Registrant Contact Information: andy@hxr.us 2598 7. 2600 * Value: transfer 2602 * Type: event action 2604 * Description: The object instance was transferred from one 2605 registrant to another. 2607 * Registrant Name: Andrew Newton 2609 * Registrant Contact Information: andy@hxr.us 2611 8. 2613 * Value: locked 2615 * Type: event action 2617 * Description: The object instance was locked (see the 'locked' 2618 status). 2620 * Registrant Name: Andrew Newton 2622 * Registrant Contact Information: andy@hxr.us 2624 9. 2626 * Value: unlocked 2628 * Type: event action 2630 * Description: The object instance was unlocked (see the 2631 'locked' status). 2633 * Registrant Name: Andrew Newton 2635 * Registrant Contact Information: andy@hxr.us 2637 10.2.3. Roles 2639 This section registers the following values into the RDAP JSON Values 2640 Registry: 2642 1. 2644 * Value: registrant 2646 * Type: role 2648 * Description: The entity object instance is the registrant of 2649 the registration. In some registries, this is known as a 2650 maintainer. 2652 * Registrant Name: Andrew Newton 2654 * Registrant Contact Information: andy@hxr.us 2656 2. 2658 * Value: technical 2660 * Type: role 2662 * Description: The entity object instance is a technical 2663 contact for the registration. 2665 * Registrant Name: Andrew Newton 2667 * Registrant Contact Information: andy@hxr.us 2669 3. 2671 * Value: administrative 2673 * Type: role 2675 * Description: The entity object instance is an administrative 2676 contact for the registration. 2678 * Registrant Name: Andrew Newton 2680 * Registrant Contact Information: andy@hxr.us 2682 4. 2684 * Value: abuse 2685 * Type: role 2687 * Description: The entity object instance handles network abuse 2688 issues on behalf of the registrant of the registration. 2690 * Registrant Name: Andrew Newton 2692 * Registrant Contact Information: andy@hxr.us 2694 5. 2696 * Value: billing 2698 * Type: role 2700 * Description: The entity object instance handles payment and 2701 billing issues on behalf of the registrant of the 2702 registration. 2704 * Registrant Name: Andrew Newton 2706 * Registrant Contact Information: andy@hxr.us 2708 6. 2710 * Value: registrar 2712 * Type: role 2714 * Description: The entity object instance represents the 2715 authority responsible for the registration in the registry. 2717 * Registrant Name: Andrew Newton 2719 * Registrant Contact Information: andy@hxr.us 2721 7. 2723 * Value: reseller 2725 * Type: role 2727 * Description: The entity object instance represents a third 2728 party through which the registration was conducted (i.e. not 2729 the registry or registrar). 2731 * Registrant Name: Andrew Newton 2732 * Registrant Contact Information: andy@hxr.us 2734 8. 2736 * Value: sponsor 2738 * Type: role 2740 * Description: The entity object instance represents a domain 2741 policy sponsor, such as an ICANN approved sponsor. 2743 * Registrant Name: Andrew Newton 2745 * Registrant Contact Information: andy@hxr.us 2747 9. 2749 * Value: proxy 2751 * Type: role 2753 * Description: The entity object instance represents a proxy 2754 for another entity object, such as a registrant. 2756 * Registrant Name: Andrew Newton 2758 * Registrant Contact Information: andy@hxr.us 2760 10. 2762 * Value: notifications 2764 * Type: role 2766 * Description: An entity object instance designated to receive 2767 notifications about association object instances. 2769 * Registrant Name: Andrew Newton 2771 * Registrant Contact Information: andy@hxr.us 2773 11. 2775 * Value: noc 2777 * Type: role 2778 * Description: The entity object instance handles 2779 communications related to a network operations center (NOC). 2781 * Registrant Name: Andrew Newton 2783 * Registrant Contact Information: andy@hxr.us 2785 10.2.4. Variant Relations 2787 This section registers the following values into the RDAP JSON Values 2788 Registry: 2790 1. 2792 * Value: registered 2794 * Type: domain variant relation 2796 * Description: The variant names are registered in the registry. 2798 * Registrant Name: Andrew Newton 2800 * Registrant Contact Information: andy@hxr.us 2802 2. 2804 * Value: unregistered 2806 * Type: domain variant relation 2808 * Description: The variant names are not found in the registry. 2810 * Registrant Name: Andrew Newton 2812 * Registrant Contact Information: andy@hxr.us 2814 3. 2816 * Value: registration restricted 2818 * Type: domain variant relation 2820 * Description: Registration of the variant names is restricted 2821 to certain parties or within certain rules. 2823 * Registrant Name: Andrew Newton 2825 * Registrant Contact Information: andy@hxr.us 2827 4. 2829 * Value: open registration 2831 * Type: domain variant relation 2833 * Description: Registration of the variant names is available to 2834 generally qualified registrants. 2836 * Registrant Name: Andrew Newton 2838 * Registrant Contact Information: andy@hxr.us 2840 5. 2842 * Value: conjoined 2844 * Type: domain variant relation 2846 * Description: Registration of the variant names occurs 2847 automatically with the registration of the containing domain 2848 registration. 2850 * Registrant Name: Andrew Newton 2852 * Registrant Contact Information: andy@hxr.us 2854 11. Security Considerations 2856 This specification models information serialized in JSON format. As 2857 JSON is a subset of Javascript, implementations are advised to follow 2858 the security considerations outlined in Section 6 of [RFC4627] to 2859 prevent code injection. 2861 12. Internationalization Considerations 2863 12.1. Character Encoding 2865 The default text encoding for JSON and XML responses in RDAP is UTF-8 2866 [RFC3629], and all servers and clients MUST support UTF-8. Servers 2867 and clients MAY optionally support other character encodings. 2869 12.2. URIs and IRIs 2871 [I-D.ietf-weirds-using-http] defines the use of URIs and IRIs in 2872 RDAP. 2874 12.3. Language Tags 2876 Section 5.4 defines the use of language tags in the JSON responses 2877 defined in this document. 2879 12.4. Internationalized Domain Names 2881 Internationalized Domain Names (IDNs) are denoted in this 2882 specification by the separation of DNS names in LDH form and Unicode 2883 form (see Section 4). Representation of IDNs in registries is 2884 described by the "variants" object in Section 6.3 and the suggested 2885 values listed in Section 10.2.4. 2887 13. Privacy Considerations 2889 This specification suggests status values to denote contact and 2890 registrant information that has been marked as private and/or has 2891 been redacted or obscured. See Section 10.2.1 for the list of status 2892 values. See Appendix A.1 on guidance to apply those values to 2893 contacts and registrants. 2895 14. Contributing Authors and Acknowledgements 2897 This document is derived from original work on RIR responses in JSON 2898 by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew L. 2899 Newton. Additionally, this document incorporates word on DNR 2900 responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean 2901 Shen. 2903 The components of the DNR object classes are derived from a 2904 categorization of WHOIS response formats created by Ning Kong, Linlin 2905 Zhou, and Guangqing Deng, Steve Sheng and Francisco Arias, Ray 2906 Bellis, and Frederico Neves. 2908 Ed Lewis contributed significant review comments and provided 2909 clarifying text. James Mitchell provided text regarding the 2910 processing of unknown JSON attributes and identified issues leading 2911 to the remodeling of events. Ernie Dainow and Francisco Obispo 2912 provided concrete suggestions that led to a better variant model for 2913 domain names. 2915 Ernie Dainow provided the background information on the secure DNSSEC 2916 attributes and objects for domains, informative text on DNSSEC, and 2917 many other attributes that appear throughout the object classes of 2918 this draft. 2920 The switch to and incorporation of JSON vCard was performed by Simon 2921 Perreault. 2923 15. References 2925 15.1. Normative References 2927 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 2928 1981. 2930 [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet 2931 numbers", RFC 1166, July 1990. 2933 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2934 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2935 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2937 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2938 Internet: Timestamps", RFC 3339, July 2002. 2940 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2941 10646", STD 63, RFC 3629, November 2003. 2943 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2944 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2945 3986, January 2005. 2947 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2948 Rose, "Resource Records for the DNS Security Extensions", 2949 RFC 4034, March 2005. 2951 [RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity 2952 Clarification", RFC 4343, January 2006. 2954 [RFC4627] Crockford, D., "The application/json Media Type for 2955 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 2957 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2958 October 2008. 2960 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of 2961 Autonomous System (AS) Numbers", RFC 5396, December 2008. 2963 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 2964 Languages", BCP 47, RFC 5646, September 2009. 2966 [RFC5890] Klensin, J., "Internationalized Domain Names for 2967 Applications (IDNA): Definitions and Document Framework", 2968 RFC 5890, August 2010. 2970 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2971 Address Text Representation", RFC 5952, August 2010. 2973 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 2975 [I-D.ietf-jcardcal-jcard] 2976 Kewisch, P., "jCard: The JSON format for vCard", draft- 2977 ietf-jcardcal-jcard-05 (work in progress), July 2013. 2979 [I-D.ietf-weirds-using-http] 2980 Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the 2981 Registration Data Access Protocol (RDAP)", draft-ietf- 2982 weirds-using-http-07 (work in progress), July 2013. 2984 [I-D.ietf-weirds-rdap-query] 2985 Newton, A. and S. Hollenbeck, "Registration Data Access 2986 Protocol Lookup Format", draft-ietf-weirds-rdap-query-05 2987 (work in progress), June 2013. 2989 [ISO.3166.1988] 2990 International Organization for Standardization, "Codes for 2991 the representation of names of countries, 3rd edition", 2992 ISO Standard 3166, August 1988. 2994 15.2. Informative References 2996 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 2997 September 2004. 2999 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 3000 STD 69, RFC 5730, August 2009. 3002 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 3003 Security Extensions Mapping for the Extensible 3004 Provisioning Protocol (EPP)", RFC 5910, May 2010. 3006 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 3007 August 2011. 3009 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type 3010 Structured Syntax Suffixes", RFC 6839, January 2013. 3012 [JSON_acendancy] 3013 MacVittie, ., "The Stealthy Ascendancy of JSON", 04 2011. 3015 [IANA_IDNTABLES] 3016 , "IANA IDN Tables", , 3017 . 3019 [JSON_performance_study] 3020 Montana State University - Bozeman, Montana State 3021 University - Bozeman, Montana State University - Bozeman, 3022 Montana State University - Bozeman, "Comparison of JSON 3023 and XML Data Interchange Formats: A Case Study", 2009. 3025 Appendix A. Suggested Data Modeling with the Entity Object Class 3027 A.1. Registrants and Contacts 3029 This document does not provide specific object classes for 3030 registrants and contacts. Instead the entity object class may be 3031 used to represent a registrant or contact. When the entity object is 3032 embedded inside a containing object such as a domain name or IP 3033 network, the 'roles' string array can be used to signify the 3034 relationship. It is recommended that the values from Section 10.2.3 3035 be used. 3037 The following is an example of an elided containing object with an 3038 embedded entity that is both a registrant and admin contact: 3040 { 3041 ... 3042 "entities" : 3043 [ 3044 { 3045 "handle" : "XXXX", 3046 "vcardArray":[ 3047 "vcard", 3048 [ 3049 ["version", {}, "text", "4.0"], 3050 ["fn", {}, "text", "Joe User"], 3051 ["kind", {}, "text", "individual"], 3052 ["lang", { 3053 "pref":"1" 3054 }, "language-tag", "fr"], 3055 ["lang", { 3056 "pref":"2" 3057 }, "language-tag", "en"], 3058 ["org", { 3059 "type":"work" 3060 }, "text", "Example"], 3061 ["title", {}, "text", "Research Scientist"], 3062 ["role", {}, "text", "Project Lead"], 3063 ["adr", 3064 { "type":"work" }, 3065 "text", 3067 [ 3068 "", 3069 "Suite 1234", 3070 "4321 Rue Somewhere", 3071 "Quebec", 3072 "QC", 3073 "G1V 2M2", 3074 "Canada" 3075 ] 3076 ], 3077 ["tel", 3078 { "type":["work", "voice"], "pref":"1" }, 3079 "uri", "tel:+1-555-555-1234;ext=102" 3080 ], 3081 ["email", 3082 { "type":"work" }, 3083 "text", "joe.user@example.com" 3084 ], 3085 ] 3086 ], 3087 "roles" : [ "registrant", "admin" ], 3088 "remarks" : 3089 [ 3090 { 3091 "description" : 3092 [ 3093 "She sells sea shells down by the sea shore.", 3094 "Originally written by Terry Sullivan." 3095 ] 3096 } 3097 ], 3098 "events" : 3099 [ 3100 { 3101 "eventAction" : "registration", 3102 "eventDate" : "1990-12-31T23:59:60Z" 3103 }, 3104 { 3105 "eventAction" : "last changed", 3106 "eventDate" : "1991-12-31T23:59:60Z" 3107 } 3108 ] 3109 } 3110 ] 3111 } 3112 In many use cases, it is necessary to hide or obscure the information 3113 of a registrant or contact due to policy or other operational 3114 matters. Registries can denote these situations with 'status' values 3115 (see Section 10.2.1). 3117 The following is an elided example of a registrant with information 3118 changed to reflect that of a third party. 3120 { 3121 ... 3122 "entities" : 3123 [ 3124 { 3125 "handle" : "XXXX", 3126 ... 3127 "roles" : [ "registrant", "admin" ], 3128 "status" : [ "proxy", "private", "obscured" ] 3129 } 3130 ] 3131 } 3133 A.2. Registrars 3135 This document does not provide a specific object class for 3136 registrars, but like registrants and contacts (see Appendix A.1) the 3137 'roles' string array maybe used. Additionally, many registrars have 3138 publicly assigned identifiers. The 'publicIds' structure 3139 (Section 5.8) represents that information. 3141 The following is an example of an elided containing object with an 3142 embedded entity that is a registrar: 3144 { 3145 ... 3146 "entities":[ 3147 { 3148 "handle":"XXXX", 3149 "vcardArray":[ 3150 "vcard", 3151 [ 3152 ["version", {}, "text", "4.0"], 3153 ["fn", {}, "text", "Joe's Fish, Chips and Domains"], 3154 ["kind", {}, "text", "org"], 3155 ["lang", { 3156 "pref":"1" 3157 }, "language-tag", "fr"], 3158 ["lang", { 3159 "pref":"2" 3160 }, "language-tag", "en"], 3161 ["org", { 3162 "type":"work" 3163 }, "text", "Example"], 3164 ["adr", 3165 { "type":"work" }, 3166 "text", 3167 [ 3168 "", 3169 "Suite 1234", 3170 "4321 Rue Somewhere", 3171 "Quebec", 3172 "QC", 3173 "G1V 2M2", 3174 "Canada" 3175 ] 3176 ], 3177 ["tel", 3178 { 3179 "type":["work", "voice"], 3180 "pref":"1" 3181 }, 3182 "uri", "tel:+1-555-555-1234;ext=102" 3183 ], 3184 ["email", 3185 { "type":"work" }, 3186 "text", "joes_fish_chips_and_domains@example.com" 3187 ], 3188 ] 3189 ], 3190 "roles":[ "registrar" ], 3191 "publicIds":[ 3192 { 3193 "type":"IANA Registrar ID", 3194 "identifier":"1" 3195 } 3196 ], 3197 "remarks":[ 3198 { 3199 "description":[ 3200 "She sells sea shells down by the sea shore.", 3201 "Originally written by Terry Sullivan." 3202 ] 3203 } 3205 ], 3206 "links":[ 3207 { 3208 "value":"http://example.net/entity/XXXX", 3209 "rel":"alternate", 3210 "type":"text/html", 3211 "href":"http://www.example.com" 3212 } 3213 ] 3214 } 3215 ] 3216 } 3218 Appendix B. Modeling Events 3220 Events represent actions that have taken place against a registered 3221 object at a certain date and time. Events have three properties: the 3222 action, the actor, and the date and time of the event (which is 3223 sometimes in the future). In some cases the identity of the actor is 3224 not captured. 3226 Events can be modeled in three ways: 3228 1. events with no designated actor 3230 2. events where the actor is only designated by an identifier 3232 3. events where the actor can be modeled as an entity 3234 For the first use case, the 'events' data structure (Section 5.5) is 3235 used without the 'eventActor' object member. 3237 This is an example of an "events" array without the 'eventActor'. 3239 "events" : 3240 [ 3241 { 3242 "eventAction" : "registration", 3243 "eventDate" : "1990-12-31T23:59:60Z" 3244 } 3245 ] 3247 Figure 20 3249 For the second use case, the 'events' data structure (Section 5.5) is 3250 used with the 'eventActor' object member. 3252 This is an example of an "events" array with the 'eventActor'. 3254 "events" : 3255 [ 3256 { 3257 "eventAction" : "registration", 3258 "eventActor" : "XYZ-NIC", 3259 "eventDate" : "1990-12-31T23:59:60Z" 3260 } 3261 ] 3263 Figure 21 3265 For the third use case, the 'asEventActor' array is used when an 3266 entity (Section 6.1) is embedded into another object class. The 3267 'asEventActor' array follows the same structure as the 'events' array 3268 but does not have 'eventActor' attributes. 3270 The following is an elided example of a domain object with an entity 3271 as an event actor. 3273 { 3274 "handle" : "XXXX", 3275 "ldhName" : "foo.example", 3276 "status" : [ "locked", "transfer Prohibited" ], 3277 ... 3278 "entities" : 3279 [ 3280 { 3281 "handle" : "XXXX", 3282 ... 3283 "asEventActor" : 3284 [ 3285 { 3286 "eventAction" : "last changed", 3287 "eventDate" : "1990-12-31T23:59:60Z" 3288 } 3289 ] 3290 } 3291 ] 3292 } 3294 Appendix C. Structured vs Unstructured Addresses 3295 The entity (Section 6.1) object class uses jCard 3296 [I-D.ietf-jcardcal-jcard] to represent contact information, including 3297 postal addresses. jCard has the ability to represent multiple 3298 language preferences, multiple email address and phone numbers, and 3299 multiple postal addresses in both a structured and unstructured 3300 format. This section describes the use of jCard for representing 3301 structured and unstructured addresses. 3303 The following is an example of a jCard. 3305 { 3306 "vcardArray":[ 3307 "vcard", 3308 [ 3309 ["version", {}, "text", "4.0"], 3310 ["fn", {}, "text", "Joe User"], 3311 ["n", {}, "text", 3312 ["User", "Joe", "", "", ["ing. jr", "M.Sc."]] 3313 ], 3314 ["bday", {}, "date-and-or-time", "--02-03"], 3315 ["anniversary", 3316 {}, "date-and-or-time", "2009-08-08T14:30:00-05:00" 3317 ], 3318 ["gender", {}, "text", "M"], 3319 ["kind", {}, "text", "individual"], 3320 ["lang", { 3321 "pref":"1" 3322 }, "language-tag", "fr"], 3323 ["lang", { 3324 "pref":"2" 3325 }, "language-tag", "en"], 3326 ["org", { 3327 "type":"work" 3328 }, "text", "Example"], 3329 ["title", {}, "text", "Research Scientist"], 3330 ["role", {}, "text", "Project Lead"], 3331 ["adr", 3332 { "type":"work" }, 3333 "text", 3334 [ 3335 "", 3336 "Suite 1234", 3337 "4321 Rue Somewhere", 3338 "Quebec", 3339 "QC", 3340 "G1V 2M2", 3341 "Canada" 3343 ] 3344 ], 3345 ["adr", 3346 { 3347 "type":"home", 3348 "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n" 3349 }, 3350 "text", 3351 [ 3352 "", "", "", "", "", "", "" 3353 ] 3354 ], 3355 ["tel", 3356 { "type":["work", "voice"], "pref":"1" }, 3357 "uri", "tel:+1-555-555-1234;ext=102" 3358 ], 3359 ["tel", 3360 { 3361 "type":["work", "cell", "voice", "video", "text"] 3362 }, 3363 "uri", 3364 "tel:+1-555-555-1234" 3365 ], 3366 ["email", 3367 { "type":"work" }, 3368 "text", "joe.user@example.com" 3369 ], 3370 ["geo", { 3371 "type":"work" 3372 }, "uri", "geo:46.772673,-71.282945"], 3373 ["key", 3374 { "type":"work" }, 3375 "uri", "http://www.example.com/joe.user/joe.asc" 3376 ], 3377 ["tz", {}, 3378 "utc-offset", "-05:00"], 3379 ["url", { "type":"home" }, 3380 "uri", "http://example.org"] 3381 ] 3382 ] 3383 } 3385 Figure 22 3387 The arrays in Figure 22 with the first member of "adr" represent 3388 postal addresses. In the first example, the postal address is given 3389 as a an array of strings and constitutes a structured address. For 3390 components of the structured address that are not applicable, an 3391 empty string is given. Each member of that array aligns with the 3392 positions of a vCard as given in [RFC6350]. In this example, the 3393 following data corresponds to the following positional meanings: 3395 1. post office box - not applicable, empty string 3397 2. extended address (e.g., apartment or suite number) - Suite 1234 3399 3. street address - 4321 Rue Somewhere 3401 4. locality (e.g., city) - Quebec 3403 5. region (e.g., state or province) - QC 3405 6. postal code - G1V 2M2 3407 7. country name (full name) - Canada 3409 The second example is an unstructured address. It uses the label 3410 attribute, which is a string containing a newline (\n) character to 3411 separate address components in an unordered, unspecified manner. 3412 Note that in this example the structured address array is still given 3413 but that each string is an empty string. 3415 Appendix D. Secure DNS 3417 Section 6.3 defines the "secureDNS" member to represent secure DNS 3418 information about domain names. 3420 DNSSEC provides data integrity for DNS through digital signing of 3421 resource records. To enable DNSSEC, the zone is signed by one or 3422 more private keys and the signatures stored as RRSIG records. To 3423 complete the chain of trust in the DNS zone hierarchy, a digest of 3424 each DNSKEY record (which contains the public key) must be loaded 3425 into the parent zone, stored as Delegation Signer (DS) records and 3426 signed by the parent's private key (RRSIG DS record), "Resource 3427 Records for the DNS Security Extensions" [RFC4034]. Creating the DS 3428 records in the parent zone can be done by the registration authority, 3429 "Domain Name System (DNS) Security Extensions Mapping for the 3430 Extensible Provisioning Protocol (EPP)" [RFC5910]. 3432 Only DS related information is provided by RDAP, since other 3433 information is not generally stored in the registration database. 3434 Other DNSSEC related information can be retrieved with other DNS 3435 tools such as dig. 3437 The domain object class (Section 6.3) can represent this information 3438 using either the 'dsData' or 'keyData' object arrays. Client 3439 implementers should be aware that some registries do not collect or 3440 do not publish all of the secure DNS meta-information. 3442 Appendix E. Motivations for Using JSON 3444 This section addresses a common question regarding the use of JSON 3445 over other data formats, most notably XML. 3447 It is often pointed out that many DNRs and one RIR support the EPP 3448 [RFC5730] standard, which is an XML serialized protocol. The logic 3449 is that since EPP is a common protocol in the industry it follows 3450 that XML would be a more natural choice. While EPP does influence 3451 this specification quite a bit, EPP serves a different purpose which 3452 is the provisioning of Internet resources between registries and 3453 accredited registrars and serves a much narrower audience than that 3454 envisioned for RDAP. 3456 By contrast, RDAP has a broader audience and is designed for public 3457 consumption of data. Experience from RIRs with first generation 3458 RESTful web services for Whois indicate a large percentage of clients 3459 operate within browsers and other platforms where full-blown XML 3460 stacks are not readily available and where JSON is a better fit. 3462 Additionally, while EPP is used in much of the DNR community it is 3463 not a universal constant in that industry. And finally, EPP's use of 3464 XML predates the specification of JSON. If EPP had been defined 3465 today, it may very well have used JSON instead of XML. 3467 Beyond the specific DNR and RIR communities, the trend in the broader 3468 Internet industry is also switching to JSON over XML, especially in 3469 the area of RESTful web services (see [JSON_acendancy]). Studies 3470 have also found that JSON is generally less bulky and consequently 3471 faster to parse (see [JSON_performance_study]). 3473 Appendix F. Changelog 3475 Initial -00 Adopted as working group document 2012-September-18. 3477 -01 3479 Minor spelling corrections. Changed "Registry Data" to 3480 "Registration Data" for the sake of consistency. 3482 Transitioned to RFC 5988 links and relationship types from our 3483 own custom "uris" structure. 3485 Some examples had 'status' as a string. Those have been 3486 corrected as 'status' is always an array of strings. 3488 Domain variants can now have a multi-valued relationship with 3489 domain registrations. 3491 "names" in the entity object class was changed to 3492 "entityNames". 3494 Some IP address examples change to IPv6. 3496 Change phone number examples and added reference to E.164. 3498 Added section on motivations for using JSON. 3500 Added error response body section. 3502 Added JSON naming section. 3504 Added common data structures section. 3506 Added the IANA Considerations section and the media type 3507 registration. 3509 Added 'lang' name/value. 3511 Added internationalization considerations section. 3513 -02 3515 Removed level from media type registration. 3517 Textual changes as given by Ed Lewis. 3519 Fixed object class linking example noted by Francisco Obispo 3521 Fixed a lot of other examples called out by Alex Sergeyev 3523 Added a note that JSON names are case sensitive 3525 Added 'status' to IP networks as suggested by Alex Sergeyev 3527 -03 3529 Added jCard verbiage and examples and deleted overlapping 3530 contact information and the appendix on postal addresses 3531 Removed the IANA considerations as they have been moved to 3532 another document 3534 Changed the remarks structure to be like notices 3536 Reordering and rewording some of the sections so they flow 3537 better 3539 Added note about object class "self" links 3541 Changed ipAddresses in nameserver object class to separate out 3542 v6 from v4 3544 Changed IP network version identifier from integer to string to 3545 be more consistent with ipAddresses identifier in nameserver 3546 object classes 3548 Changed DNS names to LDH names and Unicode names 3550 Modified the definition of 'conjoined' variant relationship so 3551 it was circular 3553 Added 'proxy', 'private', 'redacted', and 'obscured' status 3554 values (most useful for entities). 3556 Added a privacy considerations section 3558 Added a security considerations section 3560 Added 'reseller' and 'sponsor' to the list of entity roles 3562 Added the 'events' common data structure 3564 Added 'asEventActor' to entities 3566 Added appendix on event modeling 3568 Removed the subclasses/superclassing between RIRs/DNRs for 3569 entity and domain object classes 3571 Change suggested status/relation/etc values to be case/spacing 3572 consistent 3574 Normalized some of the definitions of object class members 3576 Modifying the JSON signaling section to reference the guidance 3577 in draft-ietf-weirds-using-http 3578 Changed the text regarding the process of unknown JSON 3579 attributes 3581 -04 3583 'description' removed from IP network and autnum because it is 3584 redundant with the remarks structure. 3586 Added 'entities' array to nameservers. 3588 Added 'status' to autnum. 3590 Added 'publicIds' to entity and domain. 3592 Added embedded entities to the entity object class. 3594 Added 'idnTable' to variants objects in domain object class. 3596 Changed the numbers for startNum and endNum in autnum to 3597 numbers instead of strings. 3599 Added an example for error response with full rdapConformance 3600 and notices. 3602 Added a section discussing help. 3604 Changed entities to use vcardArray and changed the examples to 3605 be current with jCard. 3607 Added a section on structured vs unstructured addresses. 3609 Added associated to the list of status values. 3611 Added a secure DNS section changed the 'delegationKey' object 3612 into the 'secureDNS' object. 3614 Changed the suggested values to an IANA registry. 3616 Added 'proxy' to the list of entity roles. 3618 -05 3620 Added IANA registration for RDAP JSON Media Type 3622 Added 'associated' status type. This was done earlier but got 3623 dropped during a reorganization of the document. 3625 Added the following status types: 3627 active 3629 inactive 3631 locked 3633 pending create 3635 pending renew 3637 pending update 3639 pending transfer 3641 pending delete 3643 renew prohibited 3645 Added the following event actions: 3647 locked 3649 unlocked 3651 Added the following roles: 3653 notifications 3655 noc 3657 Changed the 'tech' role to 'technical' 3659 Many document reference changes. 3661 Many examples have been fixed. 3663 Added links to dsData and keyData. 3665 Changed flags and protocols to integers in keyData. 3667 Added 'entities' to the specified list for autnum. 3669 Added SHOULD/SHOULD NOT language about using "type": 3670 "application/rdap+json" for self links. 3672 Added 'port43' to ip networks and autnum. 3674 Authors' Addresses 3676 Andrew Lee Newton 3677 American Registry for Internet Numbers 3678 3635 Concorde Parkway 3679 Chantilly, VA 20151 3680 US 3682 Email: andy@arin.net 3683 URI: http://www.arin.net 3685 Scott Hollenbeck 3686 Verisign Labs 3687 12061 Bluemont Way 3688 Reston, VA 20190 3689 US 3691 Email: shollenbeck@verisign.com 3692 URI: http://www.verisignlabs.com/