idnits 2.17.1 draft-ietf-weirds-json-response-07.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 150: '...nt client/server MUST understand to fu...' RFC 2119 keyword, line 190: '...N attributes but SHOULD NOT treat them...' RFC 2119 keyword, line 191: '... error. Servers MAY insert values sig...' RFC 2119 keyword, line 193: '...o JSON responses SHOULD have names pre...' RFC 2119 keyword, line 196: '...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 (April 30, 2014) is 3647 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) == Unused Reference: 'RFC0791' is defined on line 2981, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 2987, but no explicit reference was found in the text == Unused Reference: 'RFC4343' is defined on line 3005, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 3011, 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 (-15) exists of draft-ietf-weirds-using-http-08 -- 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-10 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: November 1, 2014 Verisign Labs 6 April 30, 2014 8 JSON Responses for the Registration Data Access Protocol (RDAP) 9 draft-ietf-weirds-json-response-07 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 November 1, 2014. 36 Copyright Notice 38 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Common Data Structures . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 13 67 5.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 13 68 5.9. An Example . . . . . . . . . . . . . . . . . . . . . . . 13 69 6. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.1. The Entity Object Class . . . . . . . . . . . . . . . . . 15 71 6.2. The Nameserver Object Class . . . . . . . . . . . . . . . 22 72 6.3. The Domain Object Class . . . . . . . . . . . . . . . . . 26 73 6.4. The IP Network Object Class . . . . . . . . . . . . . . . 37 74 6.5. Autonomous System Number Entity Object Class . . . . . . 41 75 7. Error Response Body . . . . . . . . . . . . . . . . . . . . . 45 76 8. Responding to Help Queries . . . . . . . . . . . . . . . . . 46 77 9. Responding To Searches . . . . . . . . . . . . . . . . . . . 47 78 10. Indicating Truncated Responses . . . . . . . . . . . . . . . 48 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 80 11.1. RDAP JSON Media Type Registration . . . . . . . . . . . 50 81 11.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 51 82 11.2.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 83 11.2.2. Event Actions . . . . . . . . . . . . . . . . . . . 58 84 11.2.3. Roles . . . . . . . . . . . . . . . . . . . . . . . 60 85 11.2.4. Variant Relations . . . . . . . . . . . . . . . . . 64 86 12. Security Considerations . . . . . . . . . . . . . . . . . . . 65 87 13. Internationalization Considerations . . . . . . . . . . . . . 65 88 13.1. Character Encoding . . . . . . . . . . . . . . . . . . . 65 89 13.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 65 90 13.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 65 91 13.4. Internationalized Domain Names . . . . . . . . . . . . . 66 92 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 66 93 15. Contributing Authors and Acknowledgements . . . . . . . . . . 66 94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 95 16.1. Normative References . . . . . . . . . . . . . . . . . . 67 96 16.2. Informative References . . . . . . . . . . . . . . . . . 68 97 Appendix A. Suggested Data Modeling with the Entity Object Class 69 98 A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 69 99 A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 71 100 Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 73 101 Appendix C. Structured vs Unstructured Addresses . . . . . . . . 75 102 Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 77 103 Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 78 104 Appendix F. Changelog . . . . . . . . . . . . . . . . . . . . . 78 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 107 1. Introduction 109 This document describes responses in the JSON [RFC4627] format for 110 the RESTful web queries as defined by the Registration Data Access 111 Protocol Lookup Format [I-D.ietf-weirds-rdap-query]. 113 The data model for JSON responses is specified in four sections: 115 1. simple data types conveyed in JSON strings 117 2. data structures specified as JSON arrays or objects that are used 118 repeatedly when building up larger objects 120 3. object classes representing structured data corresponding to a 121 given query 123 4. the response to an error 125 The object classes represent responses for two major categories of 126 data: responses returned by Regional Internet Registries (RIRs) for 127 registrations data related to IP addresses, reverse DNS names, and 128 Autonomous System numbers; and responses returned by Domain Name 129 Registries (DNRs) for registration data related to forward DNS names. 130 The following object classes are served by both RIRs and DNRs: 132 1. domains 134 2. nameservers 136 3. entities 138 The information served by both RIRs and DNRs for these object classes 139 overlap extensively and are given in this document as a unified model 140 for both classes of service. 142 In addition to the object classes listed above, RIRs also serve the 143 following object classes: 145 1. IP networks 147 2. Autonomous System numbers 149 Object classes defined in this document represent a minimal set of 150 what a compliant client/server MUST understand to function correctly, 151 however some deployments may want to include additional object 152 classes to suit individual needs. Anticipating this need for 153 extension, Section 3.2 of this document defines a mechanism for 154 extending the JSON objects that are described in this document. 156 2. Terminology and Definitions 158 The following list describes terminology and definitions used 159 throughout this document: 161 DNR: "Domain Name Registry". 163 LDH: "Letters, Digits, Hyphen". 165 member: data found with in an object as defined by JSON 166 [RFC4627]. 168 object: a data structure as defined by JSON [RFC4627]. 170 object class: the definition of members that may be found in JSON 171 objects described in this document. 173 object instance: an instantiation or specific instance of an object 174 class. 176 RDAP: "Registration Data Access Protocol". 178 RIR: "Regional Internet Registry". 180 3. Use of JSON 182 3.1. Signaling 184 Media type signaling for the JSON data specified in this document is 185 specified in [I-D.ietf-weirds-using-http]. 187 3.2. Naming 189 Clients processing JSON [RFC4627] responses are under no obligation 190 to process unrecognized JSON attributes but SHOULD NOT treat them as 191 an error. Servers MAY insert values signified by names into the JSON 192 responses which are not specified in this document. Insertion of 193 unspecified values into JSON responses SHOULD have names prefixed 194 with a short identifier followed by an underscore followed by a 195 meaningful name. The full JSON name (the prefix plus the underscore 196 plus the meaningful name) SHOULD adhere to the character and name 197 limitations of the prefix registry described in 198 [I-D.ietf-weirds-using-http]. 200 Consider the following JSON response with JSON names, all of which 201 are specified in this document. 203 { 204 "handle" : "ABC123", 205 "remarks" : 206 [ 207 { 208 "description" : 209 [ 210 "She sells sea shells down by the sea shore.", 211 "Originally written by Terry Sullivan." 212 ] 213 } 214 ] 215 } 217 Figure 1 219 If The Registry of the Moon desires to express information not found 220 in this specification, it might select "lunarNic" as its identifying 221 prefix and insert, as an example, the name 222 "lunarNic_beforeOneSmallStep" to signify registrations occurring 223 before the first moon landing and the name 224 "lunarNic_harshMistressNotes" containing other descriptive text. 226 Consider the following JSON response with JSON names, some of which 227 should be ignored by clients without knowledge of their meaning. 229 { 230 "handle" : "ABC123", 231 "lunarNic_beforeOneSmallStep" : "TRUE THAT!", 232 "remarks" : 233 [ 234 { 235 "description" : 236 [ 237 "She sells sea shells down by the sea shore.", 238 "Originally written by Terry Sullivan." 239 ] 240 } 241 ], 242 "lunarNic_harshMistressNotes" : 243 [ 244 "In space,", 245 "nobody can hear you scream." 246 ] 247 } 249 Figure 2 251 Insertion of unrecognized names ignored by clients may also be used 252 for future revisions to this specification. 254 Clients processing JSON responses MUST be prepared for values 255 specified in this document to be absent from a response as no JSON 256 value listed is required to appear in a response. In other words, 257 servers MAY remove values as is needed by the policies of the server 258 operator. 260 Finally, all JSON names specified in this document are case 261 sensitive. Both servers and clients MUST transmit and process them 262 using the specified character case. 264 4. Common Data Types 266 JSON [RFC4627] defines the data types of a number, character string, 267 boolean, array, object and null. This section describes the 268 semantics and/or syntax reference for data types used in this 269 document derived from the JSON character string. 271 'handle': DNRs and RIRs have registry-unique identifiers that 272 may be used to specifically reference an object 273 instance. The semantics of this data type as found 274 in this document is to be a registry-unique 275 reference to the closest enclosing object where the 276 value is found. The data type names 'registryId', 277 'roid', 'nic-handle', 'registrationNo', etc. are 278 terms often synonymous with this data type. In 279 this document, the term 'handle' is used. The term 280 exposed to users by clients is a presentation issue 281 beyond the scope of this document. 283 IPv4 addresses: The representation of IPv4 addresses in this 284 document uses the dotted-decimal notation described 285 in [RFC1166]. An example of this textual 286 representation is '192.0.2.0'. 288 IPv6 addresses: The representation of IPv6 addresses in this 289 document follow the forms outlined in [RFC5952]. 290 An example of this textual representation is 291 '2001:db8::1:0:0:1'. 293 country codes: Where the identity of a geopolitical nation or 294 country is needed, these identities are represented 295 with the alpha-2 or 2 character country code 296 designation as defined in [ISO.3166.1988]. The 297 alpha-2 representation is used because it is freely 298 available whereas the alpha-3 and numeric-3 299 standards are not. 301 LDH names: Textual representations of DNS names where the 302 labels of the domain are all "letters, digits, 303 hyphen" labels as described by [RFC5890]. Trailing 304 periods are optional. 306 Unicode names: Textual representations of DNS names where one or 307 more of the labels are U-labels as described by 308 [RFC5890]. Trailing periods are optional. 310 dates and times: The syntax for values denoting dates and times is 311 defined in [RFC3339]. 313 URIs: The syntax for values denoting a Uniform Resource 314 Identifier (URI) is defined by [RFC3986]. 316 Contact information is defined using JSON vCards as described in 317 [I-D.ietf-jcardcal-jcard] 319 5. Common Data Structures 321 This section defines common data structures used commonly in object 322 classes. 324 5.1. RDAP Conformance 326 The first data structure is named "rdapConformance" and is simply an 327 array of strings, each providing a hint as to the specifications used 328 in the construction of the response. This data structure appears 329 only in the top most object of a response. 331 An example rdapConformance data structure: 333 "rdapConformance" : 334 [ 335 "rdap_level_0" 336 ] 338 Figure 3 340 The string literal "rdap_level_0" signifies conformance with this 341 specification. When custom JSON values are inserted into responses, 342 conformance to those custom specifications should use a string 343 prefixed with the appropriate identifier from the IANA prefix 344 identifier registry specified in [I-D.ietf-weirds-using-http]. For 345 example, if the fictional Registry of the Moon wants to signify that 346 their JSON responses are conformant with their registered extensions, 347 the string used might be "lunarNIC_level_0". 349 Example rdapConformance structure with custom extensions noted: 351 "rdapConformance" : 352 [ 353 "rdap_level_0", 354 "lunarNic_level_0" 355 ] 357 Figure 4 359 5.2. Links 361 The "links" array is found in data structures to signify links to 362 other resources on the Internet. The relationship of these links is 363 defined by the IANA registry described by [RFC5988]. 365 The following is an example of the link structure: 367 { 368 "value" : "http://example.com/context_uri", 369 "rel" : "self", 370 "href" : "http://example.com/target_uri", 371 "hreflang" : [ "en", "ch" ], 372 "title" : [ "title1", "title2" ], 373 "media" : "screen", 374 "type" : "application/json" 375 } 377 Figure 5 379 The JSON name/values of "rel", "href", "hreflang", "title", "media", 380 and "type" correspond to values found in Section 5 of [RFC5988]. The 381 "value" JSON value is the context URI as described by [RFC5988]. The 382 "value", "rel", and "href" JSON values MUST be specified. All other 383 JSON values are optional. 385 This is an example of the "links" array as it might be found in an 386 object class: 388 "links" : 389 [ 390 { 391 "value" : "http://example.com/ip/2001:db8::123", 392 "rel" : "self", 393 "href" : "http://example.com/ip/2001:db8::123", 394 "type" : "application/rdap+json" 395 }, 396 { 397 "value" : "http://example.com/ip/2001:db8::123", 398 "rel" : "up", 399 "href" : "http://example.com/ip/2001:db8::/48", 400 "type" : "application/rdap+json" 401 } 403 ] 405 5.3. Notices And Remarks 407 The "notices" and "remarks" data structures take the same form. The 408 "notices" structure denotes information about the service providing 409 RDAP information, whereas the "remarks" structure denotes information 410 about the object class it is contained within (see Section 6 411 regarding object classes). 413 Both are an array of objects. Each object contains an optional 414 "title" string representing the title of the object, an array of 415 strings named "description" for the purposes of conveying any 416 descriptive text, and an optional "links" array as described in 417 Section 5.2. 419 An example of the notices data structure: 421 "notices" : 422 [ 423 { 424 "title" : "Terms of Use", 425 "description" : 426 [ 427 "Service subject to The Registry of the Moon's TOS.", 428 "Copyright (c) 2020 LunarNIC" 429 ], 430 "links" : 431 [ 432 { 433 "value" : "http://example.net/entity/XXXX", 434 "rel" : "alternate", 435 "type" : "text/html", 436 "href" : "http://www.example.com/terms_of_use.html" 437 } 438 ] 439 } 440 ] 442 Figure 6 444 It is the job of the clients to determine line breaks, spacing and 445 display issues for sentences within the character strings of the 446 "description" array. Servers SHOULD NOT split sentences across 447 multiple strings of this array. Each string is to represent a 448 semantic division in the descriptive text. 450 An example of the remarks data structure: 452 "remarks" : 453 [ 454 { 455 "description" : 456 [ 457 "She sells sea shells down by the sea shore.", 458 "Originally written by Terry Sullivan." 459 ] 460 } 461 ] 463 Figure 7 465 Note that objects in the "remarks" array may also have a "links" 466 array. 468 While the "remarks" array will appear in many object classes in a 469 response, the "notices" array appears only in the top most object of 470 a response. 472 5.4. Language Identifier 474 This data structure is a simple JSON name/value of "lang" with a 475 string containing a language identifier as described by [RFC5646]. 477 "lang" : "mn-Cyrl-MN" 479 Figure 8 481 The 'lang' attribute may appear anywhere in an object class or data 482 structure. 484 5.5. Events 486 This data structure represents events that have occurred on an 487 instance of an object class (see Section 6 regarding object classes). 489 This is an example of an "events" array. 491 "events" : 492 [ 493 { 494 "eventAction" : "registration", 495 "eventActor" : "SOMEID-LUNARNIC", 496 "eventDate" : "1990-12-31T23:59:60Z" 497 }, 498 { 499 "eventAction" : "last changed", 500 "eventActor" : "OTHERID-LUNARNIC", 501 "eventDate" : "1991-12-31T23:59:60Z" 502 } 503 ] 505 Figure 9 507 The "events" array consists of objects, each with the following 508 members: 510 o 'eventAction' -- a string denoting the reason for the event 512 o 'eventActor' -- an optional identifier denoting the actor 513 responsible for the event 515 o 'eventDate' -- a string containing the time and date the event 516 occurred. 518 o 'links' -- see Section 5.2. 520 Events can be future dated. One use case for future dating of events 521 is to denote when an object expires from a registry. 523 The 'links' array in this data structure is provided for references 524 to the event actor. If the event actor being referenced is an RDAP 525 entity, the link reference SHOULD be made with "rel" of "related" and 526 "type" of "application/rdap+json". 528 See Section 11.2.2 for a list of values for the 'eventAction' string. 529 See Appendix B regarding the various ways events can be modeled. 531 5.6. Status 533 This data structure, named 'status', is an array of strings 534 indicating the state of a registered object (see Section 11.2.1 for a 535 list of values). 537 5.7. Port 43 Whois Server 539 This data structure, named 'port43', is a simple string containing 540 the fully-qualified host name of the WHOIS [RFC3912] server where the 541 containing object instance may be found. Note that this is not a 542 URI, as there is no WHOIS URI scheme. 544 5.8. Public IDs 546 This data structure maps a public identifier to an object class. It 547 is named 'publicIds' and is an array of objects, with each object 548 containing the following members: 550 o type - a string denoting the type of public identifier 552 o identifier - a public identifier of the type denoted by 'type' 554 The following is an example of a 'publicIds' structure. 556 "publicIds": 557 [ 558 { 559 "type":"IANA Registrar ID", 560 "identifier":"1" 561 } 562 ] 564 Figure 10 566 5.9. An Example 567 This is an example response with both rdapConformance and notices 568 embedded: 570 { 571 "rdapConformance" : 572 [ 573 "rdap_level_0" 574 ], 575 "notices" : 576 [ 577 { 578 "title" : "Content Redacted", 579 "description" : 580 [ 581 "Without full authorization, content has been redacted.", 582 "Sorry, dude!" 583 ], 584 "links" : 585 [ 586 { 587 "value" : "http://example.net/ip/192.0.2.0/24", 588 "rel" : "alternate", 589 "type" : "text/html", 590 "href" : "http://www.example.com/redaction_policy.html" 591 } 592 ] 593 } 594 ], 595 "lang" : "en", 596 "startAddress" : "192.0.2.0", 597 "endAddress" : "192.0.2.255", 598 "handle" : "XXXX-RIR", 599 "ipVersion" : "v4", 600 "name": "NET-RTR-1", 601 "parentHandle" : "YYYY-RIR", 602 "remarks" : 603 [ 604 { 605 "description" : 606 [ 607 "She sells sea shells down by the sea shore.", 608 "Originally written by Terry Sullivan." 609 ] 610 } 611 ] 612 } 614 Figure 11 616 6. Object Classes 618 Object classes represent structures appropriate for a response from 619 the queries specified in [I-D.ietf-weirds-rdap-query]. 621 Each object class contains a "links" array as specified in 622 Section 5.2. For every object class instance in a response, whether 623 the object class instance is directly representing the response to a 624 query or is embedded in other object class instances, servers SHOULD 625 provide a link representing a URI for that object class instance 626 using the "self" relationship as specified in the IANA registry 627 specified by [RFC5988]. As explained in Section 6.2, this may be not 628 always be possible for name server data. Clients MUST be able to 629 process object instances without a "self" link. When present, 630 clients MAY use the self link for caching data. Servers MAY provide 631 more than one "self" link for any given object instance. 633 Self links SHOULD contain a "type" element containing the 634 "application/rdap+json" media type when referencing RDAP object 635 instances as defined by this document. Clients SHOULD NOT assume 636 self links without this media type are represented as RDAP objects as 637 defined by this document. 639 This is an example of the "links" array with a self link to an object 640 class: 642 "links" : 643 [ 644 { 645 "value" : "http://example.com/ip/2001:db8::123", 646 "rel" : "self", 647 "href" : "http://example.com/ip/2001:db8::123", 648 "type" : "application/rdap+json" 649 } 650 ] 652 6.1. The Entity Object Class 654 The entity object class appears throughout this document and is an 655 appropriate response for the /entity/XXXX query defined in 656 Registration Data Access Protocol Lookup Format 657 [I-D.ietf-weirds-rdap-query]. This object class represents the 658 information of organizations, corporations, governments, non-profits, 659 clubs, individual persons, and informal groups of people. All of 660 these representations are so similar that it is best to represent 661 them in JSON [RFC4627] with one construct, the entity object class, 662 to aid in the re-use of code by implementers. 664 The entity object is served by both RIRs and DNRs. The following is 665 an example of an entity that might be served by an RIR. For 666 illustrative purposes, it does not include rdapConformance or notices 667 data structures. 669 { 670 "handle":"XXXX", 671 "vcardArray":[ 672 "vcard", 673 [ 674 ["version", {}, "text", "4.0"], 675 ["fn", {}, "text", "Joe User"], 676 ["n", {}, "text", 677 ["User", "Joe", "", "", ["ing. jr", "M.Sc."]] 678 ], 679 ["bday", {}, "date-and-or-time", "--02-03"], 680 ["anniversary", 681 {}, "date-and-or-time", "2009-08-08T14:30:00-05:00" 682 ], 683 ["gender", {}, "text", "M"], 684 ["kind", {}, "text", "individual"], 685 ["lang", { 686 "pref":"1" 687 }, "language-tag", "fr"], 688 ["lang", { 689 "pref":"2" 690 }, "language-tag", "en"], 691 ["org", { 692 "type":"work" 693 }, "text", "Example"], 694 ["title", {}, "text", "Research Scientist"], 695 ["role", {}, "text", "Project Lead"], 696 ["adr", 697 { "type":"work" }, 698 "text", 699 [ 700 "", 701 "Suite 1234", 702 "4321 Rue Somewhere", 703 "Quebec", 704 "QC", 705 "G1V 2M2", 706 "Canada" 707 ] 708 ], 709 ["adr", 710 { 711 "type":"home", 712 "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n" 713 }, 714 "text", 715 [ 716 "", "", "", "", "", "", "" 717 ] 718 ], 719 ["tel", 720 { 721 "type":["work", "voice"], 722 "pref":"1" 723 }, 724 "uri", 725 "tel:+1-555-555-1234;ext=102" 726 ], 727 ["tel", 728 { "type":["work", "cell", "voice", "video", "text"] }, 729 "uri", 730 "tel:+1-555-555-4321" 731 ], 732 ["email", 733 { "type":"work" }, 734 "text", 735 "joe.user@example.com" 736 ], 737 ["geo", { 738 "type":"work" 739 }, "uri", "geo:46.772673,-71.282945"], 740 ["key", 741 { "type":"work" }, 742 "uri", 743 "http://www.example.com/joe.user/joe.asc" 744 ], 745 ["tz", {}, 746 "utc-offset", "-05:00"], 747 ["url", { "type":"home" }, 748 "uri", "http://example.org"] 749 ] 750 ], 751 "roles":[ "registrar" ], 752 "publicIds":[ 753 { 754 "type":"IANA Registrar ID", 755 "identifier":"1" 756 } 757 ], 758 "remarks":[ 759 { 760 "description":[ 761 "She sells sea shells down by the sea shore.", 762 "Originally written by Terry Sullivan." 763 ] 764 } 765 ], 766 "links":[ 767 { 768 "value":"http://example.com/entity/XXXX", 769 "rel":"self", 770 "href":"http://example.com/entity/XXXX", 771 "type" : "application/rdap+json" 772 } 773 ], 774 "events":[ 775 { 776 "eventAction":"registration", 777 "eventDate":"1990-12-31T23:59:60Z" 778 } 779 ], 780 "asEventActor":[ 781 { 782 "eventAction":"last changed", 783 "eventDate":"1991-12-31T23:59:60Z" 784 } 785 ] 786 } 788 Entities may also have other entities embedded with them in an array. 789 This can be used to model an organization with specific individuals 790 fulfilling designated roles of responsibility. 792 The following is an elided example of an entity with embedded 793 entities. 795 { 796 "handle" : "ANENTITY", 797 "roles" : [ "registrar" ], 798 ... 799 "entities" : 800 [ 801 { 802 "handle": "ANEMBEDDEDENTITY", 803 "roles" : [ "technical" ], 804 ... 805 }, 806 ... 807 ], 808 ... 809 } 811 Figure 12 813 This object has the following members: 815 o handle -- a string representing an registry unique identifier of 816 the entity 818 o vcardArray -- a JSON vCard with the entity's contact information 820 o roles -- an array of strings, each signifying the relationship an 821 object would have with its closest containing object (see 822 Section 11.2.3 for a list of values) 824 o publicIds - see Section 5.8 826 o entities - an array of entity objects as defined by this section. 828 o remarks -- see Section 5.3 830 o links -- see Section 5.2 832 o events -- see Section 5.5 834 o asEventActor -- this data structure takes the same form as the 835 'events' data structure (see Section 5.5), but each object in the 836 array MUST NOT have an 'eventActor' member. These objects denote 837 that the entity is an event actor for the given events. See 838 Appendix B regarding the various ways events can be modeled. 840 o status -- see Section 5.6 842 o port43 -- see Section 5.7 844 o networks -- an array of IP network objects as defined in 845 Section 6.4 847 o autnums -- an array of autnum objects as defined in Section 6.5 849 The following is an example of a entity that might be served by a 850 DNR. For illustrative purposes, it does not include rdapConformance 851 or notices data structures. 853 { 854 "handle":"XXXX", 855 "vcardArray":[ 856 "vcard", 857 [ 858 ["version", {}, "text", "4.0"], 859 ["fn", {}, "text", "Joe User"], 860 ["kind", {}, "text", "individual"], 861 ["lang", { 862 "pref":"1" 863 }, "language-tag", "fr"], 864 ["lang", { 865 "pref":"2" 866 }, "language-tag", "en"], 867 ["org", { 868 "type":"work" 869 }, "text", "Example"], 870 ["title", {}, "text", "Research Scientist"], 871 ["role", {}, "text", "Project Lead"], 872 ["adr", 873 { "type":"work" }, 874 "text", 875 [ 876 "", 877 "Suite 1234", 878 "4321 Rue Somewhere", 879 "Quebec", 880 "QC", 881 "G1V 2M2", 882 "Canada" 883 ] 885 ], 886 ["tel", 887 { "type":["work", "voice"], "pref":"1" }, 888 "uri", "tel:+1-555-555-1234;ext=102" 889 ], 890 ["email", 891 { "type":"work" }, 892 "text", "joe.user@example.com" 893 ], 894 ] 895 ], 896 "status":[ "validated", "locked" ], 897 "remarks":[ 898 { 899 "description":[ 900 "She sells sea shells down by the sea shore.", 901 "Originally written by Terry Sullivan." 902 ] 903 } 904 ], 905 "links":[ 906 { 907 "value":"http://example.com/entity/XXXX", 908 "rel":"self", 909 "href":"http://example.com/entity/XXXX", 910 "type":"application/rdap+json" 911 } 912 ], 913 "port43":"whois.example.net", 914 "events":[ 915 { 916 "eventAction":"registration", 917 "eventDate":"1990-12-31T23:59:60Z" 918 }, 919 { 920 "eventAction":"last changed", 921 "eventDate":"1991-12-31T23:59:60Z", 922 "eventActor":"joe@example.com" 923 } 924 ] 925 } 927 See Appendix A for use of the entity object class to model various 928 types of entities found in both RIRs and DNRs. See Appendix C 929 regarding structured vs. unstructured postal addresses in entities. 931 6.2. The Nameserver Object Class 933 The nameserver object class represents information regarding DNS name 934 servers used in both forward and reverse DNS. RIRs and some DNRs 935 register or expose nameserver information as an attribute of a domain 936 name, while other DNRs model nameservers as "first class objects". 938 The nameserver object class accommodates both models and degrees of 939 variation in between. 941 The following is an example of a nameserver object. For illustrative 942 purposes, it does not include rdapConformance or notices data 943 structures. 945 { 946 "handle" : "XXXX", 947 "ldhName" : "ns1.xn--fo-5ja.example", 948 "unicodeName" : "foo.example", 949 "status" : [ "active" ], 950 "ipAddresses" : 951 { 952 "v4": [ "192.0.2.1", "192.0.2.2" ], 953 "v6": [ "2001:db8::123" ] 954 }, 955 "remarks" : 956 [ 957 { 958 "description" : 959 [ 960 "She sells sea shells down by the sea shore.", 961 "Originally written by Terry Sullivan." 962 ] 963 } 964 ], 965 "links" : 966 [ 967 { 968 "value" : "http://example.net/nameserver/xxxx", 969 "rel" : "self", 970 "href" : "http://example.net/nameserver/xxxx", 971 "type" : "application/rdap+json" 972 } 973 ], 974 "port43" : "whois.example.net", 975 "events" : 976 [ 977 { 978 "eventAction" : "registration", 979 "eventDate" : "1990-12-31T23:59:60Z" 980 }, 981 { 982 "eventAction" : "last changed", 983 "eventDate" : "1991-12-31T23:59:60Z", 984 "eventActor" : "joe@example.com" 985 } 986 ] 987 } 989 Figure 13 991 Figure 13 is an example of a nameserver object with all values given. 992 Registries using a first-class nameserver data model would embed this 993 in domain objects as well as allowing references to it with the "/ 994 nameserver" query type (all depending on the registry operators 995 policy). Other registries may pare back the information as needed. 996 Figure 14 is an example of a nameserver object as would be found in 997 RIRs and some DNRs, while Figure 15 is an example of a nameserver 998 object as would be found in other DNRs. 1000 The following is an example of the simplest nameserver object: 1002 { 1003 "ldhName" : "ns1.example.com" 1004 } 1006 Figure 14 1008 The following is an example of a simple nameserver object that might 1009 be commonly used by DNRs: 1011 { 1012 "ldhName" : "ns1.example.com", 1013 "ipAddresses" : { "v6" : [ "2001:db8::123", "2001:db8::124" ] } 1014 } 1016 Figure 15 1018 As nameservers can be modeled by some registries to be first-class 1019 objects, they may also have an array of entities (Section 6.1) 1020 embedded to signify parties responsible for the maintenance, 1021 registrations, etc. of the nameservers. 1023 The following is an elided example of a nameserver with embedded 1024 entities. 1026 { 1027 "handle" : "XXXX", 1028 "ldhName" : "ns1.xn--fo-5ja.example", 1029 ... 1030 "entities" : 1031 [ 1032 ... 1033 ], 1034 ... 1035 } 1037 Figure 16 1039 The nameserver object class has the following members: 1041 o handle -- a string representing an registry unique identifier of 1042 the nameserver 1044 o ldhName -- a string containing the LDH name of the nameserver (see 1045 Section 4) 1047 o unicodeName -- a string containing a DNS Unicode name of the 1048 nameserver (see Section 4) 1050 o ipAddresses -- an object containing the following members: 1052 * v6 -- an array of strings containing IPv6 addresses of the 1053 nameserver 1055 * v4 -- an array of strings containing IPv4 addresses of the 1056 nameserver 1058 o entities -- an array of entity objects as defined by Section 6.1. 1060 o status - see Section 5.6 1062 o remarks - see Section 5.3 1064 o links - see Section 5.2 1066 o port43 - see Section 5.7 1068 o events - see Section 5.5 1070 6.3. The Domain Object Class 1072 The domain object class represents a DNS name and point of 1073 delegation. For RIRs these delegation points are in the reverse DNS 1074 tree, whereas for DNRs these delegation points are in the forward DNS 1075 tree. 1077 In both cases, the high level structure of the domain object class 1078 consists of information about the domain registration, nameserver 1079 information related to the domain name, and entities related to the 1080 domain name (e.g. registrant information, contacts, etc.). 1082 The following is an elided example of the domain object showing the 1083 high level structure: 1085 { 1086 "handle" : "XXX", 1087 "ldhName" : "blah.example.com", 1088 ... 1089 "nameServers" : 1090 [ 1091 ... 1092 ], 1093 ... 1094 "entities" : 1095 [ 1096 ... 1097 ] 1098 } 1100 The following is a description of the members of this object: 1102 o handle -- a string representing a registry unique identifier of 1103 the domain object instance 1105 o ldhName -- a string describing a domain name in LDH form as 1106 described in Section 4 1108 o unicodeName -- a string containing a domain name with U-labels as 1109 described in Section 4 1111 o variants -- an array of objects, each containing the following 1112 values: 1114 * relation -- an array of strings, with each string denoting the 1115 relationship between the variants and the containing domain 1116 object (see Section 11.2.4 for a list of suggested variant 1117 relations). 1119 * idnTable -- the name of the IDN table of codepoints, such as 1120 one listed with the IANA (see IDN tables [IANA_IDNTABLES]). 1122 * variantNames -- an array of objects, with each object 1123 containing an "ldhName" member and a "unicodeName" member (see 1124 Section 4). 1126 o nameServers -- an array of nameserver objects as defined by 1127 Section 6.2 1129 o secureDNS -- an object with the following members: 1131 * zoneSigned -- boolean true if the zone has been signed, false 1132 otherwise. 1134 * delegationSigned -- boolean true if there are DS records in the 1135 parent, false otherwise. 1137 * maxSigLife -- an integer representing the signature life time 1138 in seconds to be used when creating the RRSIG DS record in the 1139 parent zone [RFC5910]. 1141 * dsData - an array of objects, each with the following members: 1143 + keyTag -- an integer as specified by the key tag field of a 1144 DNS DS record as specified by RFC 4034 RFC 4034 [RFC4034] in 1145 presentation format 1147 + algorithm -- an integer as specified by the algorithm field 1148 of a DNS DS record as specified by RFC 4034 in presentation 1149 format 1151 + digest -- a string as specified by the digest field of a DNS 1152 DS record as specified by RFC 4034 in presentation format 1154 + digestType -- an integer as specified by the digest type 1155 field of a DNS DS record as specified by RFC 4034 in 1156 presentation format 1158 + events - see Section 5.5 1160 + links - see Section 5.2 1162 * keyData - an array of objects, each with the following members: 1164 + flags -- an integer representing the flags field value in 1165 the DNSKEY record [RFC4034] in presentation format. 1167 + protocol - an integer representation of the protocol field 1168 value of the DNSKEY record [RFC4034] in presentation format. 1170 + publicKey - a string representation of the public key in the 1171 DNSKEY record [RFC4034] in presentation format. 1173 + algorithm -- an integer as specified by the algorithm field 1174 of a DNSKEY record as specified by RFC 4034 [RFC4034] in 1175 presentation format 1177 + events - see Section 5.5 1179 + links - see Section 5.2 1181 See Appendix D for background information on these objects. 1183 o entities -- an array of entity objects as defined by Section 6.1. 1185 o status - see Section 5.6 1187 o publicIds - see Section 5.8 1189 o remarks - see Section 5.3 1191 o links - see Section 5.2 1193 o port43 - see Section 5.7 1195 o events - see Section 5.5 1197 o network - represents the IP network for which a reverse DNS domain 1198 is referenced. See Section 6.4 1200 The following is an example of a JSON domain object representing a 1201 reverse DNS delegation point that might be served by an RIR. For 1202 illustrative purposes, it does not include rdapConformance or notices 1203 data structures. 1205 { 1206 "handle" : "XXXX", 1207 "ldhName" : "192.in-addr.arpa", 1208 "nameServers" : 1209 [ 1210 { "ldhName" : "ns1.rir.example" }, 1211 { "ldhName" : "ns2.rir.example" } 1212 ], 1213 "secureDNS": 1214 { 1215 "delegationSigned": true, 1216 "dsData": 1217 [ 1218 { 1219 "keyTag": 12345, 1220 "algorithm": 3, 1221 "digestType": 1, 1222 "digest": "49FD46E6C4B45C55D4AC" 1223 } 1224 ] 1225 }, 1226 "remarks" : 1227 [ 1228 { 1229 "description" : 1230 [ 1231 "She sells sea shells down by the sea shore.", 1232 "Originally written by Terry Sullivan." 1233 ] 1234 } 1235 ], 1236 "links" : 1237 [ 1238 { 1239 "value": "http://example.net/domain/XXXX", 1240 "rel" : "self", 1241 "href" : "http://example.net/domain/XXXXX", 1242 "type" : "application/rdap+json" 1243 } 1244 ], 1245 "events" : 1246 [ 1247 { 1248 "eventAction" : "registration", 1249 "eventDate" : "1990-12-31T23:59:60Z" 1250 }, 1251 { 1252 "eventAction" : "last changed", 1253 "eventDate" : "1991-12-31T23:59:60Z", 1254 "eventActor" : "joe@example.com" 1255 } 1256 ], 1257 "entities" : 1258 [ 1259 { 1260 "handle" : "XXXX", 1261 "vcardArray":[ 1262 "vcard", 1263 [ 1264 ["version", {}, "text", "4.0"], 1265 ["fn", {}, "text", "Joe User"], 1266 ["kind", {}, "text", "individual"], 1267 ["lang", { 1268 "pref":"1" 1269 }, "language-tag", "fr"], 1270 ["lang", { 1271 "pref":"2" 1272 }, "language-tag", "en"], 1273 ["org", { 1274 "type":"work" 1275 }, "text", "Example"], 1276 ["title", {}, "text", "Research Scientist"], 1277 ["role", {}, "text", "Project Lead"], 1278 ["adr", 1279 { "type":"work" }, 1280 "text", 1281 [ 1282 "", 1283 "Suite 1234", 1284 "4321 Rue Somewhere", 1285 "Quebec", 1286 "QC", 1287 "G1V 2M2", 1288 "Canada" 1289 ] 1290 ], 1291 ["tel", 1292 { "type":["work", "voice"], "pref":"1" }, 1293 "uri", "tel:+1-555-555-1234;ext=102" 1294 ], 1295 ["email", 1296 { "type":"work" }, 1297 "text", "joe.user@example.com" 1298 ], 1299 ] 1300 ], 1301 "roles" : [ "registrant" ], 1302 "remarks" : 1303 [ 1304 { 1305 "description" : 1306 [ 1307 "She sells sea shells down by the sea shore.", 1308 "Originally written by Terry Sullivan." 1309 ] 1310 } 1311 ], 1312 "links" : 1313 [ 1314 { 1315 "value": "http://example.net/entity/xxxx", 1316 "rel" : "self", 1317 "href" : "http://example.net/entity/xxxx", 1318 "type" : "application/rdap+json" 1319 } 1320 ], 1321 "events" : 1322 [ 1323 { 1324 "eventAction" : "registration", 1325 "eventDate" : "1990-12-31T23:59:60Z" 1326 }, 1327 { 1328 "eventAction" : "last changed", 1329 "eventDate" : "1991-12-31T23:59:60Z", 1330 "eventActor" : "joe@example.com" 1331 } 1332 ] 1333 } 1334 ], 1335 "network" : 1336 { 1337 "handle" : "XXXX-RIR", 1338 "startAddress" : "2001:db8::0", 1339 "endAddress" : "2001:db8::0:FFFF:FFFF:FFFF:FFFF:FFFF", 1340 "ipVersion" : "v6", 1341 "name": "NET-RTR-1", 1342 "type" : "DIRECT ALLOCATION", 1343 "country" : "AU", 1344 "parentHandle" : "YYYY-RIR", 1345 "status" : [ "allocated" ] 1346 } 1347 } 1349 The following is an example of a JSON domain object representing a 1350 forward DNS delegation point that might be served by a DNR. For 1351 illustrative purposes, it does not include rdapConformance or notices 1352 data structures. 1354 { 1355 "handle" : "XXXX", 1356 "ldhName" : "xn--fo-5ja.example", 1357 "unicodeName" : "foo.example", 1358 "variants" : 1359 [ 1360 { 1361 "relation" : [ "registered", "conjoined" ], 1362 "variantNames" : 1363 [ 1364 { 1365 "ldhName" : "xn--fo-cka.example", 1366 "unicodeName" : "foo.example" 1367 }, 1368 { 1369 "ldhName" : "xn--fo-fka.example", 1370 "unicodeName" : "foeo.example" 1371 } 1372 ] 1373 }, 1374 { 1375 "relation" : [ "unregistered", "restricted registration" ], 1376 "idnTable": ".EXAMPLE Swedish", 1377 "variantNames" : 1378 [ 1379 { 1380 "ldhName": "xn--fo-8ja.example", 1381 "unicodeName" : "foo.example" 1382 } 1383 ] 1384 } 1385 ], 1386 "status" : [ "locked", "transfer prohibited" ], 1387 "publicIds":[ 1388 { 1389 "type":"ENS_Auth ID", 1390 "identifier":"1234567890" 1391 } 1392 ], 1393 "nameServers" : 1394 [ 1395 { 1396 "handle" : "XXXX", 1397 "ldhName" : "ns1.example.com", 1398 "status" : [ "active" ], 1399 "ipAddresses" : 1400 { 1401 "v6": [ "2001:db8::123", "2001:db8::124" ], 1402 "v4": [ "192.0.2.1", "192.0.2.2" ] 1403 }, 1404 "remarks" : 1405 [ 1406 { 1407 "description" : 1408 [ 1409 "She sells sea shells down by the sea shore.", 1410 "Originally written by Terry Sullivan." 1411 ] 1412 } 1413 ], 1414 "links" : 1415 [ 1416 { 1417 "value" : "http://example.net/nameserver/XXXX", 1418 "rel" : "self", 1419 "href" : "http://example.net/nameserver/XXXX", 1420 "type" : "application/rdap+json" 1421 } 1422 ], 1423 "events" : 1424 [ 1425 { 1426 "eventAction" : "registration", 1427 "eventDate" : "1990-12-31T23:59:60Z" 1428 }, 1429 { 1430 "eventAction" : "last changed", 1431 "eventDate" : "1991-12-31T23:59:60Z" 1432 } 1433 ] 1434 }, 1435 { 1436 "handle" : "XXXX", 1437 "ldhName" : "ns2.example.com", 1438 "status" : [ "active" ], 1439 "ipAddresses" : 1440 { 1441 "v6" : [ "2001:db8::125", "2001:db8::126" ], 1442 "v4" : [ "192.0.2.3", "192.0.2.4" ] 1443 }, 1444 "remarks" : 1445 [ 1446 { 1447 "description" : 1448 [ 1449 "She sells sea shells down by the sea shore.", 1450 "Originally written by Terry Sullivan." 1451 ] 1452 } 1453 ], 1454 "links" : 1455 [ 1456 { 1457 "value" : "http://example.net/nameserver/XXXX", 1458 "rel" : "self", 1459 "href" : "http://example.net/nameserver/XXXX", 1460 "type" : "application/rdap+json" 1461 } 1462 ], 1463 "events" : 1464 [ 1465 { 1466 "eventAction" : "registration", 1467 "eventDate" : "1990-12-31T23:59:60Z" 1468 }, 1469 { 1470 "eventAction" : "last changed", 1471 "eventDate" : "1991-12-31T23:59:60Z" 1472 } 1473 ] 1474 } 1475 ], 1476 "secureDNS": 1477 { 1478 "zoneSigned": true, 1479 "delegationSigned": true, 1480 "maxSigLife": 604800, 1481 "keyData": 1482 [ 1483 { 1484 "flags": 257, 1485 "protocol": 3, 1486 "algorithm": 1, 1487 "publicKey": "AQPJ////4Q==", 1488 "events": 1489 [ 1490 { 1491 "eventAction": "last changed", 1492 "eventDate": "2012-07-23T05:15:47Z" 1493 } 1494 ] 1495 } 1496 ] 1497 }, 1498 "remarks" : 1499 [ 1500 { 1501 "description" : 1502 [ 1503 "She sells sea shells down by the sea shore.", 1504 "Originally written by Terry Sullivan." 1505 ] 1506 } 1507 ], 1508 "links" : 1509 [ 1510 { 1511 "value": "http://example.net/domain/XXXX", 1512 "rel" : "self", 1513 "href" : "http://example.net/domain/XXXX", 1514 "type" : "application/rdap+json" 1515 } 1516 ], 1517 "port43" : "whois.example.net", 1518 "events" : 1519 [ 1520 { 1521 "eventAction" : "registration", 1522 "eventDate" : "1990-12-31T23:59:60Z" 1523 }, 1524 { 1525 "eventAction" : "last changed", 1526 "eventDate" : "1991-12-31T23:59:60Z", 1527 "eventActor" : "joe@example.com" 1528 }, 1529 { 1530 "eventAction" : "transfer", 1531 "eventDate" : "1991-12-31T23:59:60Z", 1532 "eventActor" : "joe@example.com" 1533 }, 1534 { 1535 "eventAction" : "expiration", 1536 "eventDate" : "2016-12-31T23:59:60Z", 1537 "eventActor" : "joe@example.com" 1538 } 1539 ], 1540 "entities" : 1541 [ 1542 { 1543 "handle" : "XXXX", 1544 "vcardArray":[ 1545 "vcard", 1547 [ 1548 ["version", {}, "text", "4.0"], 1549 ["fn", {}, "text", "Joe User"], 1550 ["kind", {}, "text", "individual"], 1551 ["lang", { 1552 "pref":"1" 1553 }, "language-tag", "fr"], 1554 ["lang", { 1555 "pref":"2" 1556 }, "language-tag", "en"], 1557 ["org", { 1558 "type":"work" 1559 }, "text", "Example"], 1560 ["title", {}, "text", "Research Scientist"], 1561 ["role", {}, "text", "Project Lead"], 1562 ["adr", 1563 { "type":"work" }, 1564 "text", 1565 [ 1566 "", 1567 "Suite 1234", 1568 "4321 Rue Somewhere", 1569 "Quebec", 1570 "QC", 1571 "G1V 2M2", 1572 "Canada" 1573 ] 1574 ], 1575 ["tel", 1576 { "type":["work", "voice"], "pref":"1" }, 1577 "uri", "tel:+1-555-555-1234;ext=102" 1578 ], 1579 ["email", 1580 { "type":"work" }, 1581 "text", "joe.user@example.com" 1582 ], 1583 ] 1584 ], 1585 "status" : [ "validated", "locked" ], 1586 "roles" : [ "registrant" ], 1587 "remarks" : 1588 [ 1589 { 1590 "description" : 1591 [ 1592 "She sells sea shells down by the sea shore.", 1593 "Originally written by Terry Sullivan." 1594 ] 1596 } 1597 ], 1598 "links" : 1599 [ 1600 { 1601 "value" : "http://example.net/entity/xxxx", 1602 "rel" : "self", 1603 "href" : "http://example.net/entity/xxxx", 1604 "type" : "application/rdap+json" 1605 } 1606 ], 1607 "events" : 1608 [ 1609 { 1610 "eventAction" : "registration", 1611 "eventDate" : "1990-12-31T23:59:60Z" 1612 }, 1613 { 1614 "eventAction" : "last changed", 1615 "eventDate" : "1991-12-31T23:59:60Z" 1616 } 1617 ] 1618 } 1619 ] 1620 } 1622 6.4. The IP Network Object Class 1624 The IP Network object class models IP network registrations found in 1625 RIRs and is the expected response for the "/ip" query as defined by 1626 [I-D.ietf-weirds-rdap-query]. There is no equivalent object class 1627 for DNRs. The high level structure of the IP network object class 1628 consists of information about the network registration and entities 1629 related to the IP network (e.g. registrant information, contacts, 1630 etc...). 1632 The following is an elided example of the IP network object type 1633 showing the high level structure: 1635 { 1636 "handle" : "XXX", 1637 ... 1638 "entities" : 1639 [ 1640 ... 1641 ] 1642 } 1644 The following is an example of the JSON object for the network 1645 registration information. For illustrative purposes, it does not 1646 include rdapConformance or notices data structures. 1648 { 1649 "handle" : "XXXX-RIR", 1650 "startAddress" : "2001:db8::0", 1651 "endAddress" : "2001:db8::0:FFFF:FFFF:FFFF:FFFF:FFFF", 1652 "ipVersion" : "v6", 1653 "name": "NET-RTR-1", 1654 "type" : "DIRECT ALLOCATION", 1655 "country" : "AU", 1656 "parentHandle" : "YYYY-RIR", 1657 "status" : [ "allocated" ], 1658 "remarks" : 1659 [ 1660 { 1661 "description" : 1662 [ 1663 "She sells sea shells down by the sea shore.", 1664 "Originally written by Terry Sullivan." 1665 ] 1666 } 1667 ], 1668 "links" : 1669 [ 1670 { 1671 "value" : "http://example.ent/ip/2001:db8::/48", 1672 "rel" : "self", 1673 "href" : "http://example.net/ip/2001:db8::/48", 1674 "type" : "application/rdap+json" 1675 }, 1676 { 1677 "value" : "http://example.net/ip/2001:db8::/48", 1678 "rel" : "up", 1679 "href" : "http://example.net/ip/2001:C00::/23", 1680 "type" : "application/rdap+json" 1681 } 1682 ], 1683 "events" : 1684 [ 1685 { 1686 "eventAction" : "registration", 1687 "eventDate" : "1990-12-31T23:59:60Z" 1688 }, 1689 { 1690 "eventAction" : "last changed", 1691 "eventDate" : "1991-12-31T23:59:60Z" 1692 } 1693 ], 1694 "entities" : 1695 [ 1696 { 1697 "handle" : "XXXX", 1698 "vcardArray":[ 1699 "vcard", 1700 [ 1701 ["version", {}, "text", "4.0"], 1702 ["fn", {}, "text", "Joe User"], 1703 ["kind", {}, "text", "individual"], 1704 ["lang", { 1705 "pref":"1" 1706 }, "language-tag", "fr"], 1707 ["lang", { 1708 "pref":"2" 1709 }, "language-tag", "en"], 1710 ["org", { 1711 "type":"work" 1712 }, "text", "Example"], 1713 ["title", {}, "text", "Research Scientist"], 1714 ["role", {}, "text", "Project Lead"], 1715 ["adr", 1716 { "type":"work" }, 1717 "text", 1718 [ 1719 "", 1720 "Suite 1234", 1721 "4321 Rue Somewhere", 1722 "Quebec", 1723 "QC", 1724 "G1V 2M2", 1725 "Canada" 1726 ] 1727 ], 1728 ["tel", 1729 { "type":["work", "voice"], "pref":"1" }, 1730 "uri", "tel:+1-555-555-1234;ext=102" 1731 ], 1732 ["email", 1733 { "type":"work" }, 1734 "text", "joe.user@example.com" 1735 ], 1736 ] 1737 ], 1738 "roles" : [ "registrant" ], 1739 "remarks" : 1740 [ 1741 { 1742 "description" : 1743 [ 1744 "She sells sea shells down by the sea shore.", 1745 "Originally written by Terry Sullivan." 1746 ] 1747 } 1748 ], 1749 "links" : 1750 [ 1751 { 1752 "value" : "http://example.net/entity/xxxx", 1753 "rel" : "self", 1754 "href" : "http://example.net/entity/xxxx", 1755 "type" : "application/rdap+json" 1756 } 1757 ], 1758 "events" : 1759 [ 1760 { 1761 "eventAction" : "registration", 1762 "eventDate" : "1990-12-31T23:59:60Z" 1763 }, 1764 { 1765 "eventAction" : "last changed", 1766 "eventDate" : "1991-12-31T23:59:60Z" 1767 } 1768 ] 1769 } 1770 ] 1771 } 1772 The following is a description of the members of this object: 1774 o handle -- a string representing an RIR unique identifier of the 1775 network registration 1777 o startAddress -- the starting IP address of the network, either 1778 IPv4 or IPv6 1780 o endAddress -- the ending IP address of the network, either IPv4 or 1781 IPv6 1783 o ipVersion -- a string signifying the IP protocol version of the 1784 network: "v4" signifying an IPv4 network, "v6" signifying an IPv6 1785 network 1787 o name -- an identifier assigned to the network registration by the 1788 registration holder 1790 o type -- a string containing an RIR-specific classification of the 1791 network 1793 o country -- a string containing the name of the 2 character country 1794 code of the network 1796 o parentHandle -- a string containing an RIR-unique identifier of 1797 the parent network of this network registration 1799 o status -- an array of strings indicating the state of the IP 1800 network 1802 o entities -- an array of entity objects as defined by Section 6.1. 1804 o remarks - see Section 5.3 1806 o links - see Section 5.2 1808 o port43 - see Section 5.7 1810 o events - see Section 5.5 1812 6.5. Autonomous System Number Entity Object Class 1814 The Autonomous System Number (autnum) object class models Autonomous 1815 System Number registrations found in RIRs and represents the expected 1816 response to an "/autnum" query as defined by 1817 [I-D.ietf-weirds-rdap-query]. There is no equivalent object class 1818 for DNRs. The high level structure of the autnum object class 1819 consists of information about the network registration and entities 1820 related to the autnum registration (e.g. registrant information, 1821 contacts, etc.), and is similar to the IP Network entity object 1822 class. 1824 The following is an example of a JSON object representing an autnum. 1825 For illustrative purposes, it does not include rdapConformance or 1826 notices data structures. 1828 { 1829 "handle" : "XXXX-RIR", 1830 "startAutnum" : 10, 1831 "endAutnum" : 15, 1832 "name": "AS-RTR-1", 1833 "type" : "DIRECT ALLOCATION", 1834 "status" : [ "allocated" ], 1835 "country": "AU", 1836 "remarks" : 1837 [ 1838 { 1839 "description" : 1840 [ 1841 "She sells sea shells down by the sea shore.", 1842 "Originally written by Terry Sullivan." 1843 ] 1844 } 1845 ], 1846 "links" : 1847 [ 1848 { 1849 "value" : "http://example.net/autnum/xxxx", 1850 "rel" : "self", 1851 "href" : "http://example.net/autnum/xxxx", 1852 "type" : "application/rdap+json" 1853 } 1854 ], 1855 "events" : 1856 [ 1857 { 1858 "eventAction" : "registration", 1859 "eventDate" : "1990-12-31T23:59:60Z" 1860 }, 1861 { 1862 "eventAction" : "last changed", 1863 "eventDate" : "1991-12-31T23:59:60Z" 1864 } 1865 ], 1866 "entities" : 1868 [ 1869 { 1870 "handle" : "XXXX", 1871 "vcardArray":[ 1872 "vcard", 1873 [ 1874 ["version", {}, "text", "4.0"], 1875 ["fn", {}, "text", "Joe User"], 1876 ["kind", {}, "text", "individual"], 1877 ["lang", { 1878 "pref":"1" 1879 }, "language-tag", "fr"], 1880 ["lang", { 1881 "pref":"2" 1882 }, "language-tag", "en"], 1883 ["org", { 1884 "type":"work" 1885 }, "text", "Example"], 1886 ["title", {}, "text", "Research Scientist"], 1887 ["role", {}, "text", "Project Lead"], 1888 ["adr", 1889 { "type":"work" }, 1890 "text", 1891 [ 1892 "", 1893 "Suite 1234", 1894 "4321 Rue Somewhere", 1895 "Quebec", 1896 "QC", 1897 "G1V 2M2", 1898 "Canada" 1899 ] 1900 ], 1901 ["tel", 1902 { "type":["work", "voice"], "pref":"1" }, 1903 "uri", "tel:+1-555-555-1234;ext=102" 1904 ], 1905 ["email", 1906 { "type":"work" }, 1907 "text", "joe.user@example.com" 1908 ], 1909 ] 1910 ], 1911 "roles" : [ "registrant" ], 1912 "remarks" : 1913 [ 1914 { 1915 "description" : 1917 [ 1918 "She sells sea shells down by the sea shore.", 1919 "Originally written by Terry Sullivan." 1920 ] 1921 } 1922 ], 1923 "links" : 1924 [ 1925 { 1926 "value" : "http://example.net/entity/XXXX", 1927 "rel" : "self", 1928 "href" : "http://example.net/entity/XXXX", 1929 "type" : "application/rdap+json" 1930 } 1931 ], 1932 "events" : 1933 [ 1934 { 1935 "eventAction" : "registration", 1936 "eventDate" : "1990-12-31T23:59:60Z" 1937 }, 1938 { 1939 "eventAction" : "last changed", 1940 "eventDate" : "1991-12-31T23:59:60Z" 1941 } 1942 ] 1943 } 1944 ] 1945 } 1947 The following is a description of the members of this object: 1949 o handle -- a string representing an RIR-unique identifier of the 1950 autnum registration 1952 o startAutnum -- a number representing the starting number [RFC5396] 1953 in the block of autonomous system numbers 1955 o endAutnum -- a number representing the ending number [RFC5396] in 1956 the block of autonomous system numbers 1958 o name -- an identifier assigned to the autnum registration by the 1959 registration holder 1961 o type -- a string containing an RIR-specific classification of the 1962 autnum 1964 o status -- an array of strings indicating the state of the autnum 1966 o country -- a string containing the name of the 2 character country 1967 code of the autnum 1969 o entities -- an array of entity objects as defined by Section 6.1. 1971 o remarks - see Section 5.3 1973 o links - see Section 5.2 1975 o port43 - see Section 5.7 1977 o events - see Section 5.5 1979 7. Error Response Body 1981 Some non-answer responses may return entity bodies with information 1982 that could be more descriptive. 1984 The basic structure of that response is an object class containing an 1985 error code number (corresponding to the HTTP response code) followed 1986 by a string named "title" followed by an array of strings named 1987 "description". 1989 This is an example of the common response body. For illustrative 1990 purposes, it does not include rdapConformance or notices data 1991 structures. 1993 { 1994 "errorCode": 418, 1995 "title": "Your beverage choice is not available", 1996 "description": 1997 [ 1998 "I know coffee has more ummppphhh.", 1999 "Sorry, dude!" 2000 ] 2001 } 2003 Figure 17 2005 A client MAY simply use the HTTP response code as the server is not 2006 required to include error data in the response body. However, if a 2007 client wishes to parse the error data, it SHOULD first check that the 2008 Content-Type header contains the appropriate media type. 2010 This is an example of the common response body with and 2011 rdapConformance and notices data structures: 2013 { 2014 "rdapConformance" : 2015 [ 2016 "rdap_level_0" 2017 ], 2018 "notices" : 2019 [ 2020 { 2021 "title" : "Beverage policy", 2022 "description" : 2023 [ 2024 "Beverages with caffeine for keeping horses awake." 2025 ], 2026 "links" : 2027 [ 2028 { 2029 "value" : "http://example.net/ip/192.0.2.0/24", 2030 "rel" : "alternate", 2031 "type" : "text/html", 2032 "href" : "http://www.example.com/redaction_policy.html" 2033 } 2034 ] 2035 } 2036 ], 2037 "lang" : "en", 2038 "errorCode": 418, 2039 "title": "Your beverage choice is not available", 2040 "description": 2041 [ 2042 "I know coffee has more ummppphhh.", 2043 "Sorry, dude!" 2044 ] 2045 } 2047 Figure 18 2049 8. Responding to Help Queries 2051 The appropriate response to /help queries as defined by 2052 [I-D.ietf-weirds-rdap-query] is to use the notices structure as 2053 defined in Section 5.3. 2055 This is an example of a response to a /help query including the 2056 rdapConformance data structure. 2058 { 2059 "rdapConformance" : 2060 [ 2061 "rdap_level_0" 2062 ], 2063 "notices" : 2064 [ 2065 { 2066 "title" : "Authentication Policy", 2067 "description" : 2068 [ 2069 "Access to sensitive data for users with proper credentials." 2070 ], 2071 "links" : 2072 [ 2073 { 2074 "value" : "http://example.net/help", 2075 "rel" : "alternate", 2076 "type" : "text/html", 2077 "href" : "http://www.example.com/auth_policy.html" 2078 } 2079 ] 2080 } 2081 ] 2082 } 2084 Figure 19 2086 9. Responding To Searches 2088 [I-D.ietf-weirds-rdap-query] specifies three types of searches: 2089 domains, nameservers, and entities. Responses to these searches take 2090 the form of an array of object instances where each instance is an 2091 appropriate object class for the search (i.e. a search for /domains 2092 yields an array of domain object instances). These arrays are 2093 contained within the response object. 2095 The names of the arrays are as follows: 2097 o for /domains searches, the array is "domainSearchResults" 2099 o for /nameservers searches, the array is "nameserverSearchResults" 2101 o for /entities searches, the array is "entitySearchResults" 2102 The following is an elided example of a response to a /domains 2103 search. 2105 { 2106 "rdapConformance" : 2107 [ 2108 "rdap_level_0" 2109 ], 2110 ... 2111 "domainSearchResults" : 2112 [ 2113 { 2114 "handle" : "1-XXXX", 2115 "ldhName" : "1.example.com", 2116 ... 2117 }, 2118 { 2119 "handle" : "2-XXXX", 2120 "ldhName" : "2.example.com", 2121 ... 2122 } 2123 ] 2124 } 2126 search_response_example 2128 10. Indicating Truncated Responses 2130 In cases where the data of a response has been truncated (i.e. not 2131 all of it has been included in the response), a server may indicate 2132 this by including the boolean "resultsTruncated" in the response 2133 object. Whe this value is set to true, it indicates the data of the 2134 response has been truncated. When this value is true, it is 2135 recommended that servers include a textual description describing the 2136 nature of the truncation in a notices structure. 2138 The following is an elided example of a search response that has been 2139 truncated. 2141 { 2142 "rdapConformance" : 2143 [ 2144 "rdap_level_0" 2145 ], 2146 "notices" : 2147 [ 2148 { 2149 "title" : "Search Policy", 2150 "description" : 2151 [ 2152 "Search results are limited to 25 per day per querying IP." 2153 ], 2154 "links" : 2155 [ 2156 { 2157 "value" : "http://example.net/help", 2158 "rel" : "alternate", 2159 "type" : "text/html", 2160 "href" : "http://www.example.com/search_policy.html" 2161 } 2162 ] 2163 } 2164 ], 2165 "resultsTruncated" : true 2166 "domainSearchResults" : 2167 [ 2168 ... 2169 ] 2170 } 2172 search_response_truncated_example 2174 Note that "resultsTruncated" can be used where a single object has 2175 been returned and data in that object has been truncated. Such an 2176 example might be an entity object with only a partial set of the IP 2177 networks associated with it. 2179 The following is an elided example of an entity truncated data. 2181 { 2182 "handle" : "ANENTITY", 2183 "roles" : [ "registrant" ], 2184 ... 2185 "entities" : 2186 [ 2187 { 2188 "handle": "ANEMBEDDEDENTITY", 2189 "roles" : [ "technical" ], 2190 ... 2191 }, 2192 ... 2193 ], 2194 "networks" : 2195 [ 2196 ... 2197 ], 2198 ... 2199 "resultsTruncated": true 2200 } 2202 Figure 20 2204 11. IANA Considerations 2206 11.1. RDAP JSON Media Type Registration 2208 This specification registers the "application/rdap+json" media type. 2210 Type name: application 2212 Subtype name: rdap+json 2214 Required parameters: n/a 2216 Encoding considerations: See section 3.1 of [RFC6839]. 2218 Security considerations: The media represented by this identifier 2219 does not have security considerations beyond that found in section 2220 6 of [RFC4627] 2222 Interoperability considerations: There are no known 2223 interoperability problems regarding this media format. 2225 Published specification: [[ this document ]] 2227 Applications that use this media type: Implementations of the 2228 Registration Data Access Protocol (RDAP) 2230 Additional information: This media type is a product of the IETF 2231 WEIRDS working group. The WEIRDS charter, information on the 2232 WEIRDS mailing list, and other documents produced by the WEIRDS 2233 working group can be found at https://datatracker.ietf.org/wg/ 2234 weirds/ 2236 Person & email address to contact for further information: Andy 2237 Newton 2239 Intended usage: COMMON 2241 Restrictions on usage: none 2243 Author: Andy Newton 2245 Change controller: IETF 2247 Provisional Registration: No (upon publication of this RFC) 2249 11.2. JSON Values Registry 2251 This section requests that the IANA establish an RDAP JSON Values 2252 Registry for use in the status (Section 5.6), role (Section 6.1), 2253 event action (Section 5.5), and domain variant relation (Section 6.3) 2254 fields specified in RDAP. 2256 Each entry in the registry should contain the following fields: 2258 1. Value - the string value being registered. 2260 2. Type - the type of value being registered. It should be one of 2261 the following: 2263 * 'status' - denotes a value for the 'status' object member as 2264 defined by Section 5.6. 2266 * 'role' - denotes a value for the 'role' array as defined in 2267 Section 6.1. 2269 * 'event action' - denotes a value for an event action as 2270 defined in Section 5.5. 2272 * 'domain variant relation' - denotes a relationship between a 2273 domain and a domain variant as defined in Section 6.3. 2275 3. Description - a one or two sentence description regarding the 2276 meaning of the value, how it might be used, and/or how it should 2277 be interpreted by clients. 2279 4. Registrant Name - the name of the person registering the value. 2281 5. Registrant Contact Information - an email address, postal 2282 address, or some other information to be used to contact the 2283 registrant. 2285 This registry should be governed by a designated expert or multiple 2286 designated experts. Registration of values into this registry should 2287 be accomplished by providing the information above to the designated 2288 expert(s). 2290 Review of registrations into this registry by the designated 2291 expert(s) should be narrowly judged on the following criteria: 2293 1. Values in need of being placed into multiple types must be 2294 assigned a separate registration for each type. 2296 2. Values must be strings. They can be multiple words separated by 2297 single space characters. Every character should be lowercased. 2298 If possible, every word should be given in English and each 2299 character should be US ASCII. 2301 3. Registrations should not duplicate the meaning of any existing 2302 registration. That is, if a request for a registration is 2303 significantly similar in nature to an existing registration, the 2304 request should be denied. For example, the terms 'maintainer' 2305 and 'registrant' are significantly similar in nature as they both 2306 denote a holder of a domain name or Internet number resource. In 2307 cases where it may be reasonably argued that machine 2308 interpretation of two similar values may alter the operation of 2309 client software, designated experts should not judge the values 2310 to be of significant similarity. 2312 4. Registrations should be relevant to the common usages of RDAP. 2313 Designated experts may rely upon the serving of the value by a 2314 DNR or RIR to make this determination. 2316 11.2.1. Status 2318 This section registers the following values into the RDAP JSON Values 2319 Registry: 2321 1. 2323 * Value: validated 2325 * Type: status 2327 * Description: Signifies that the data of the object instance 2328 has been found to be accurate. This type of status is 2329 usually found on entity object instances to note the validity 2330 of identifying contact information. 2332 * Registrant Name: Andrew Newton 2334 * Registrant Contact Information: andy@hxr.us 2336 2. 2338 * Value: renew prohibited 2340 * Type: status 2342 * Description: Renewal or reregistration of the object instance 2343 is forbidden. 2345 * Registrant Name: Andrew Newton 2347 * Registrant Contact Information: andy@hxr.us 2349 3. 2351 * Value: update prohibited 2353 * Type: status 2355 * Description: Updates to the object instance are forbidden. 2357 * Registrant Name: Andrew Newton 2359 * Registrant Contact Information: andy@hxr.us 2361 4. 2363 * Value: transfer prohibited 2364 * Type: status 2366 * Description: Transfers of the registration from one registrar 2367 to another are forbidden. This type of status normally 2368 applies to DNR domain names. 2370 * Registrant Name: Andrew Newton 2372 * Registrant Contact Information: andy@hxr.us 2374 5. 2376 * Value: delete prohibited 2378 * Type: status 2380 * Description: Deletion of the registration of the object 2381 instance is forbidden. This type of status normally applies 2382 to DNR domain names. 2384 * Registrant Name: Andrew Newton 2386 * Registrant Contact Information: andy@hxr.us 2388 6. 2390 * Value: proxy 2392 * Type: status 2394 * Description: The registration of the object instance has been 2395 performed by a third party. This is most commonly applied to 2396 entities. 2398 * Registrant Name: Andrew Newton 2400 * Registrant Contact Information: andy@hxr.us 2402 7. 2404 * Value: private 2406 * Type: status 2408 * Description: The information of the object instance is not 2409 designated for public consumption. This is most commonly 2410 applied to entities. 2412 * Registrant Name: Andrew Newton 2414 * Registrant Contact Information: andy@hxr.us 2416 8. 2418 * Value: redacted 2420 * Type: status 2422 * Description: Some of the information of the object instance 2423 has not been made available. This is most commonly applied 2424 to entities. 2426 * Registrant Name: Andrew Newton 2428 * Registrant Contact Information: andy@hxr.us 2430 9. 2432 * Value: obscured 2434 * Type: status 2436 * Description: Some of the information of the object instance 2437 has been altered for the purposes of not readily revealing 2438 the actual information of the object instance. This is most 2439 commonly applied to entities. 2441 * Registrant Name: Andrew Newton 2443 * Registrant Contact Information: andy@hxr.us 2445 10. 2447 * Value: associated 2449 * Type: status 2451 * Description: The object instance is associated with other 2452 object instances in the registry. This is most commonly used 2453 to signify that a nameserver is associated with a domain or 2454 that an entity is associated with a network resource or 2455 domain. 2457 * Registrant Name: Andrew Newton 2459 * Registrant Contact Information: andy@hxr.us 2461 11. 2463 * Value: active 2465 * Type: status 2467 * Description: The object instance is in use. For domain 2468 names, it signifies that the domain name is published in DNS. 2469 For network and autnum registrations it signifies that they 2470 are allocated or assigned for use in operational networks. 2471 This maps to the EPP 'OK' status. 2473 * Registrant Name: Andrew Newton 2475 * Registrant Contact Information: andy@hxr.us 2477 12. 2479 * Value: inactive 2481 * Type: status 2483 * Description: The object instance is not in use. See 2484 'active'. 2486 * Registrant Name: Andrew Newton 2488 * Registrant Contact Information: andy@hxr.us 2490 13. 2492 * Value: locked 2494 * Type: status 2496 * Description: Changes to the object instance cannot be made, 2497 including the assocation of other object instances. 2499 * Registrant Name: Andrew Newton 2501 * Registrant Contact Information: andy@hxr.us 2503 14. 2505 * Value: pending create 2507 * Type: status 2508 * Description: A request has been received for the creation of 2509 the object instance but this action is not yet complete. 2511 * Registrant Name: Andrew Newton 2513 * Registrant Contact Information: andy@hxr.us 2515 15. 2517 * Value: pending renew 2519 * Type: status 2521 * Description: A request has been received for the renewal of 2522 the object instance but this action is not yet complete. 2524 * Registrant Name: Andrew Newton 2526 * Registrant Contact Information: andy@hxr.us 2528 16. 2530 * Value: pending transfer 2532 * Type: status 2534 * Description: A request has been received for the transfer of 2535 the object instance but this action is not yet complete. 2537 * Registrant Name: Andrew Newton 2539 * Registrant Contact Information: andy@hxr.us 2541 17. 2543 * Value: pending update 2545 * Type: status 2547 * Description: A request has been received for the update or 2548 modification of the object instance but this action is not 2549 yet complete. 2551 * Registrant Name: Andrew Newton 2553 * Registrant Contact Information: andy@hxr.us 2555 18. 2557 * Value: pending delete 2559 * Type: status 2561 * Description: A request has been received for the deletion or 2562 removal of the object instance but this action is not yet 2563 complete. For domains, this might mean that the name in no 2564 longer published in DNS but has not yet been purged from the 2565 registry database. 2567 * Registrant Name: Andrew Newton 2569 * Registrant Contact Information: andy@hxr.us 2571 11.2.2. Event Actions 2573 This section registers the following values into the RDAP JSON Values 2574 Registry: 2576 1. 2578 * Value: registration 2580 * Type: event action 2582 * Description: The object instance was initially registered. 2584 * Registrant Name: Andrew Newton 2586 * Registrant Contact Information: andy@hxr.us 2588 2. 2590 * Value: reregistration 2592 * Type: event action 2594 * Description: The object instance was registered subsequently 2595 to initial registration. 2597 * Registrant Name: Andrew Newton 2599 * Registrant Contact Information: andy@hxr.us 2601 3. 2603 * Value: last changed 2604 * Type: event action 2606 * Description: An action noting when the information in the 2607 object instance was last changed. 2609 * Registrant Name: Andrew Newton 2611 * Registrant Contact Information: andy@hxr.us 2613 4. 2615 * Value: expiration 2617 * Type: event action 2619 * Description: The object instance has been removed or will be 2620 removed at a pre-determined date and time from the registry. 2622 * Registrant Name: Andrew Newton 2624 * Registrant Contact Information: andy@hxr.us 2626 5. 2628 * Value: deletion 2630 * Type: event action 2632 * Description: The object instance was removed from the registry 2633 at a point in time that was not pre-determined. 2635 * Registrant Name: Andrew Newton 2637 * Registrant Contact Information: andy@hxr.us 2639 6. 2641 * Value: reinstantiation 2643 * Type: event action 2645 * Description: The object instance was reregistered after having 2646 been removed from the registry. 2648 * Registrant Name: Andrew Newton 2650 * Registrant Contact Information: andy@hxr.us 2652 7. 2654 * Value: transfer 2656 * Type: event action 2658 * Description: The object instance was transferred from one 2659 registrant to another. 2661 * Registrant Name: Andrew Newton 2663 * Registrant Contact Information: andy@hxr.us 2665 8. 2667 * Value: locked 2669 * Type: event action 2671 * Description: The object instance was locked (see the 'locked' 2672 status). 2674 * Registrant Name: Andrew Newton 2676 * Registrant Contact Information: andy@hxr.us 2678 9. 2680 * Value: unlocked 2682 * Type: event action 2684 * Description: The object instance was unlocked (see the 2685 'locked' status). 2687 * Registrant Name: Andrew Newton 2689 * Registrant Contact Information: andy@hxr.us 2691 11.2.3. Roles 2693 This section registers the following values into the RDAP JSON Values 2694 Registry: 2696 1. 2698 * Value: registrant 2699 * Type: role 2701 * Description: The entity object instance is the registrant of 2702 the registration. In some registries, this is known as a 2703 maintainer. 2705 * Registrant Name: Andrew Newton 2707 * Registrant Contact Information: andy@hxr.us 2709 2. 2711 * Value: technical 2713 * Type: role 2715 * Description: The entity object instance is a technical 2716 contact for the registration. 2718 * Registrant Name: Andrew Newton 2720 * Registrant Contact Information: andy@hxr.us 2722 3. 2724 * Value: administrative 2726 * Type: role 2728 * Description: The entity object instance is an administrative 2729 contact for the registration. 2731 * Registrant Name: Andrew Newton 2733 * Registrant Contact Information: andy@hxr.us 2735 4. 2737 * Value: abuse 2739 * Type: role 2741 * Description: The entity object instance handles network abuse 2742 issues on behalf of the registrant of the registration. 2744 * Registrant Name: Andrew Newton 2746 * Registrant Contact Information: andy@hxr.us 2748 5. 2750 * Value: billing 2752 * Type: role 2754 * Description: The entity object instance handles payment and 2755 billing issues on behalf of the registrant of the 2756 registration. 2758 * Registrant Name: Andrew Newton 2760 * Registrant Contact Information: andy@hxr.us 2762 6. 2764 * Value: registrar 2766 * Type: role 2768 * Description: The entity object instance represents the 2769 authority responsible for the registration in the registry. 2771 * Registrant Name: Andrew Newton 2773 * Registrant Contact Information: andy@hxr.us 2775 7. 2777 * Value: reseller 2779 * Type: role 2781 * Description: The entity object instance represents a third 2782 party through which the registration was conducted (i.e. not 2783 the registry or registrar). 2785 * Registrant Name: Andrew Newton 2787 * Registrant Contact Information: andy@hxr.us 2789 8. 2791 * Value: sponsor 2793 * Type: role 2794 * Description: The entity object instance represents a domain 2795 policy sponsor, such as an ICANN approved sponsor. 2797 * Registrant Name: Andrew Newton 2799 * Registrant Contact Information: andy@hxr.us 2801 9. 2803 * Value: proxy 2805 * Type: role 2807 * Description: The entity object instance represents a proxy 2808 for another entity object, such as a registrant. 2810 * Registrant Name: Andrew Newton 2812 * Registrant Contact Information: andy@hxr.us 2814 10. 2816 * Value: notifications 2818 * Type: role 2820 * Description: An entity object instance designated to receive 2821 notifications about association object instances. 2823 * Registrant Name: Andrew Newton 2825 * Registrant Contact Information: andy@hxr.us 2827 11. 2829 * Value: noc 2831 * Type: role 2833 * Description: The entity object instance handles 2834 communications related to a network operations center (NOC). 2836 * Registrant Name: Andrew Newton 2838 * Registrant Contact Information: andy@hxr.us 2840 11.2.4. Variant Relations 2842 This section registers the following values into the RDAP JSON Values 2843 Registry: 2845 1. 2847 * Value: registered 2849 * Type: domain variant relation 2851 * Description: The variant names are registered in the registry. 2853 * Registrant Name: Andrew Newton 2855 * Registrant Contact Information: andy@hxr.us 2857 2. 2859 * Value: unregistered 2861 * Type: domain variant relation 2863 * Description: The variant names are not found in the registry. 2865 * Registrant Name: Andrew Newton 2867 * Registrant Contact Information: andy@hxr.us 2869 3. 2871 * Value: registration restricted 2873 * Type: domain variant relation 2875 * Description: Registration of the variant names is restricted 2876 to certain parties or within certain rules. 2878 * Registrant Name: Andrew Newton 2880 * Registrant Contact Information: andy@hxr.us 2882 4. 2884 * Value: open registration 2886 * Type: domain variant relation 2887 * Description: Registration of the variant names is available to 2888 generally qualified registrants. 2890 * Registrant Name: Andrew Newton 2892 * Registrant Contact Information: andy@hxr.us 2894 5. 2896 * Value: conjoined 2898 * Type: domain variant relation 2900 * Description: Registration of the variant names occurs 2901 automatically with the registration of the containing domain 2902 registration. 2904 * Registrant Name: Andrew Newton 2906 * Registrant Contact Information: andy@hxr.us 2908 12. Security Considerations 2910 This specification models information serialized in JSON format. As 2911 JSON is a subset of Javascript, implementations are advised to follow 2912 the security considerations outlined in Section 6 of [RFC4627] to 2913 prevent code injection. 2915 13. Internationalization Considerations 2917 13.1. Character Encoding 2919 The default text encoding for JSON and XML responses in RDAP is UTF-8 2920 [RFC3629], and all servers and clients MUST support UTF-8. Servers 2921 and clients MAY optionally support other character encodings. 2923 13.2. URIs and IRIs 2925 [I-D.ietf-weirds-using-http] defines the use of URIs and IRIs in 2926 RDAP. 2928 13.3. Language Tags 2930 Section 5.4 defines the use of language tags in the JSON responses 2931 defined in this document. 2933 13.4. Internationalized Domain Names 2935 Internationalized Domain Names (IDNs) are denoted in this 2936 specification by the separation of DNS names in LDH form and Unicode 2937 form (see Section 4). Representation of IDNs in registries is 2938 described by the "variants" object in Section 6.3 and the suggested 2939 values listed in Section 11.2.4. 2941 14. Privacy Considerations 2943 This specification suggests status values to denote contact and 2944 registrant information that has been marked as private and/or has 2945 been redacted or obscured. See Section 11.2.1 for the list of status 2946 values. See Appendix A.1 on guidance to apply those values to 2947 contacts and registrants. 2949 15. Contributing Authors and Acknowledgements 2951 This document is derived from original work on RIR responses in JSON 2952 by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew L. 2953 Newton. Additionally, this document incorporates word on DNR 2954 responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean 2955 Shen. 2957 The components of the DNR object classes are derived from a 2958 categorization of WHOIS response formats created by Ning Kong, Linlin 2959 Zhou, and Guangqing Deng, Steve Sheng and Francisco Arias, Ray 2960 Bellis, and Frederico Neves. 2962 Ed Lewis contributed significant review comments and provided 2963 clarifying text. James Mitchell provided text regarding the 2964 processing of unknown JSON attributes and identified issues leading 2965 to the remodeling of events. Ernie Dainow and Francisco Obispo 2966 provided concrete suggestions that led to a better variant model for 2967 domain names. 2969 Ernie Dainow provided the background information on the secure DNSSEC 2970 attributes and objects for domains, informative text on DNSSEC, and 2971 many other attributes that appear throughout the object classes of 2972 this draft. 2974 The switch to and incorporation of JSON vCard was performed by Simon 2975 Perreault. 2977 16. References 2979 16.1. Normative References 2981 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 2982 1981. 2984 [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet 2985 numbers", RFC 1166, July 1990. 2987 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2988 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2989 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2991 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 2992 Internet: Timestamps", RFC 3339, July 2002. 2994 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2995 10646", STD 63, RFC 3629, November 2003. 2997 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2998 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2999 3986, January 2005. 3001 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 3002 Rose, "Resource Records for the DNS Security Extensions", 3003 RFC 4034, March 2005. 3005 [RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity 3006 Clarification", RFC 4343, January 2006. 3008 [RFC4627] Crockford, D., "The application/json Media Type for 3009 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 3011 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 3012 October 2008. 3014 [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of 3015 Autonomous System (AS) Numbers", RFC 5396, December 2008. 3017 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 3018 Languages", BCP 47, RFC 5646, September 2009. 3020 [RFC5890] Klensin, J., "Internationalized Domain Names for 3021 Applications (IDNA): Definitions and Document Framework", 3022 RFC 5890, August 2010. 3024 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 3025 Address Text Representation", RFC 5952, August 2010. 3027 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 3029 [I-D.ietf-jcardcal-jcard] 3030 Kewisch, P., "jCard: The JSON format for vCard", draft- 3031 ietf-jcardcal-jcard-07 (work in progress), October 2013. 3033 [I-D.ietf-weirds-using-http] 3034 Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the 3035 Registration Data Access Protocol (RDAP)", draft-ietf- 3036 weirds-using-http-08 (work in progress), February 2014. 3038 [I-D.ietf-weirds-rdap-query] 3039 Newton, A. and S. Hollenbeck, "Registration Data Access 3040 Protocol Query Format", draft-ietf-weirds-rdap-query-10 3041 (work in progress), February 2014. 3043 [ISO.3166.1988] 3044 International Organization for Standardization, "Codes for 3045 the representation of names of countries, 3rd edition", 3046 ISO Standard 3166, August 1988. 3048 16.2. Informative References 3050 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 3051 September 2004. 3053 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 3054 STD 69, RFC 5730, August 2009. 3056 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 3057 Security Extensions Mapping for the Extensible 3058 Provisioning Protocol (EPP)", RFC 5910, May 2010. 3060 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 3061 August 2011. 3063 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type 3064 Structured Syntax Suffixes", RFC 6839, January 2013. 3066 [JSON_acendancy] 3067 MacVittie, , "The Stealthy Ascendancy of JSON", 04 2011. 3069 [IANA_IDNTABLES] 3070 "IANA IDN Tables", 3071 . 3073 [JSON_performance_study] 3074 Montana State University - Bozeman, Montana State 3075 University - Bozeman, Montana State University - Bozeman, 3076 and Montana State University - Bozeman, "Comparison of 3077 JSON and XML Data Interchange Formats: A Case Study", 3078 2009. 3080 Appendix A. Suggested Data Modeling with the Entity Object Class 3082 A.1. Registrants and Contacts 3084 This document does not provide specific object classes for 3085 registrants and contacts. Instead the entity object class may be 3086 used to represent a registrant or contact. When the entity object is 3087 embedded inside a containing object such as a domain name or IP 3088 network, the 'roles' string array can be used to signify the 3089 relationship. It is recommended that the values from Section 11.2.3 3090 be used. 3092 The following is an example of an elided containing object with an 3093 embedded entity that is both a registrant and administrative contact: 3095 { 3096 ... 3097 "entities" : 3098 [ 3099 { 3100 "handle" : "XXXX", 3101 "vcardArray":[ 3102 "vcard", 3103 [ 3104 ["version", {}, "text", "4.0"], 3105 ["fn", {}, "text", "Joe User"], 3106 ["kind", {}, "text", "individual"], 3107 ["lang", { 3108 "pref":"1" 3109 }, "language-tag", "fr"], 3110 ["lang", { 3111 "pref":"2" 3112 }, "language-tag", "en"], 3113 ["org", { 3114 "type":"work" 3115 }, "text", "Example"], 3116 ["title", {}, "text", "Research Scientist"], 3117 ["role", {}, "text", "Project Lead"], 3118 ["adr", 3119 { "type":"work" }, 3120 "text", 3121 [ 3122 "", 3123 "Suite 1234", 3124 "4321 Rue Somewhere", 3125 "Quebec", 3126 "QC", 3127 "G1V 2M2", 3128 "Canada" 3129 ] 3130 ], 3131 ["tel", 3132 { "type":["work", "voice"], "pref":"1" }, 3133 "uri", "tel:+1-555-555-1234;ext=102" 3134 ], 3135 ["email", 3136 { "type":"work" }, 3137 "text", "joe.user@example.com" 3138 ], 3139 ] 3140 ], 3141 "roles" : [ "registrant", "administrative" ], 3142 "remarks" : 3143 [ 3144 { 3145 "description" : 3146 [ 3147 "She sells sea shells down by the sea shore.", 3148 "Originally written by Terry Sullivan." 3149 ] 3150 } 3151 ], 3152 "events" : 3153 [ 3154 { 3155 "eventAction" : "registration", 3156 "eventDate" : "1990-12-31T23:59:60Z" 3157 }, 3158 { 3159 "eventAction" : "last changed", 3160 "eventDate" : "1991-12-31T23:59:60Z" 3161 } 3162 ] 3163 } 3164 ] 3165 } 3166 In many use cases, it is necessary to hide or obscure the information 3167 of a registrant or contact due to policy or other operational 3168 matters. Registries can denote these situations with 'status' values 3169 (see Section 11.2.1). 3171 The following is an elided example of a registrant with information 3172 changed to reflect that of a third party. 3174 { 3175 ... 3176 "entities" : 3177 [ 3178 { 3179 "handle" : "XXXX", 3180 ... 3181 "roles" : [ "registrant", "administrative" ], 3182 "status" : [ "proxy", "private", "obscured" ] 3183 } 3184 ] 3185 } 3187 A.2. Registrars 3189 This document does not provide a specific object class for 3190 registrars, but like registrants and contacts (see Appendix A.1) the 3191 'roles' string array maybe used. Additionally, many registrars have 3192 publicly assigned identifiers. The 'publicIds' structure 3193 (Section 5.8) represents that information. 3195 The following is an example of an elided containing object with an 3196 embedded entity that is a registrar: 3198 { 3199 ... 3200 "entities":[ 3201 { 3202 "handle":"XXXX", 3203 "vcardArray":[ 3204 "vcard", 3205 [ 3206 ["version", {}, "text", "4.0"], 3207 ["fn", {}, "text", "Joe's Fish, Chips and Domains"], 3208 ["kind", {}, "text", "org"], 3209 ["lang", { 3210 "pref":"1" 3212 }, "language-tag", "fr"], 3213 ["lang", { 3214 "pref":"2" 3215 }, "language-tag", "en"], 3216 ["org", { 3217 "type":"work" 3218 }, "text", "Example"], 3219 ["adr", 3220 { "type":"work" }, 3221 "text", 3222 [ 3223 "", 3224 "Suite 1234", 3225 "4321 Rue Somewhere", 3226 "Quebec", 3227 "QC", 3228 "G1V 2M2", 3229 "Canada" 3230 ] 3231 ], 3232 ["tel", 3233 { 3234 "type":["work", "voice"], 3235 "pref":"1" 3236 }, 3237 "uri", "tel:+1-555-555-1234;ext=102" 3238 ], 3239 ["email", 3240 { "type":"work" }, 3241 "text", "joes_fish_chips_and_domains@example.com" 3242 ], 3243 ] 3244 ], 3245 "roles":[ "registrar" ], 3246 "publicIds":[ 3247 { 3248 "type":"IANA Registrar ID", 3249 "identifier":"1" 3250 } 3251 ], 3252 "remarks":[ 3253 { 3254 "description":[ 3255 "She sells sea shells down by the sea shore.", 3256 "Originally written by Terry Sullivan." 3257 ] 3258 } 3259 ], 3260 "links":[ 3261 { 3262 "value":"http://example.net/entity/XXXX", 3263 "rel":"alternate", 3264 "type":"text/html", 3265 "href":"http://www.example.com" 3266 } 3267 ] 3268 } 3269 ] 3270 } 3272 Appendix B. Modeling Events 3274 Events represent actions that have taken place against a registered 3275 object at a certain date and time. Events have three properties: the 3276 action, the actor, and the date and time of the event (which is 3277 sometimes in the future). In some cases the identity of the actor is 3278 not captured. 3280 Events can be modeled in three ways: 3282 1. events with no designated actor 3284 2. events where the actor is only designated by an identifier 3286 3. events where the actor can be modeled as an entity 3288 For the first use case, the 'events' data structure (Section 5.5) is 3289 used without the 'eventActor' object member. 3291 This is an example of an "events" array without the 'eventActor'. 3293 "events" : 3294 [ 3295 { 3296 "eventAction" : "registration", 3297 "eventDate" : "1990-12-31T23:59:60Z" 3298 } 3299 ] 3301 Figure 21 3303 For the second use case, the 'events' data structure (Section 5.5) is 3304 used with the 'eventActor' object member. 3306 This is an example of an "events" array with the 'eventActor'. 3308 "events" : 3309 [ 3310 { 3311 "eventAction" : "registration", 3312 "eventActor" : "XYZ-NIC", 3313 "eventDate" : "1990-12-31T23:59:60Z" 3314 } 3315 ] 3317 Figure 22 3319 For the third use case, the 'asEventActor' array is used when an 3320 entity (Section 6.1) is embedded into another object class. The 3321 'asEventActor' array follows the same structure as the 'events' array 3322 but does not have 'eventActor' attributes. 3324 The following is an elided example of a domain object with an entity 3325 as an event actor. 3327 { 3328 "handle" : "XXXX", 3329 "ldhName" : "foo.example", 3330 "status" : [ "locked", "transfer Prohibited" ], 3331 ... 3332 "entities" : 3333 [ 3334 { 3335 "handle" : "XXXX", 3336 ... 3337 "asEventActor" : 3338 [ 3339 { 3340 "eventAction" : "last changed", 3341 "eventDate" : "1990-12-31T23:59:60Z" 3342 } 3343 ] 3344 } 3345 ] 3346 } 3348 Appendix C. Structured vs Unstructured Addresses 3350 The entity (Section 6.1) object class uses jCard 3351 [I-D.ietf-jcardcal-jcard] to represent contact information, including 3352 postal addresses. jCard has the ability to represent multiple 3353 language preferences, multiple email address and phone numbers, and 3354 multiple postal addresses in both a structured and unstructured 3355 format. This section describes the use of jCard for representing 3356 structured and unstructured addresses. 3358 The following is an example of a jCard. 3360 { 3361 "vcardArray":[ 3362 "vcard", 3363 [ 3364 ["version", {}, "text", "4.0"], 3365 ["fn", {}, "text", "Joe User"], 3366 ["n", {}, "text", 3367 ["User", "Joe", "", "", ["ing. jr", "M.Sc."]] 3368 ], 3369 ["bday", {}, "date-and-or-time", "--02-03"], 3370 ["anniversary", 3371 {}, "date-and-or-time", "2009-08-08T14:30:00-05:00" 3372 ], 3373 ["gender", {}, "text", "M"], 3374 ["kind", {}, "text", "individual"], 3375 ["lang", { 3376 "pref":"1" 3377 }, "language-tag", "fr"], 3378 ["lang", { 3379 "pref":"2" 3380 }, "language-tag", "en"], 3381 ["org", { 3382 "type":"work" 3383 }, "text", "Example"], 3384 ["title", {}, "text", "Research Scientist"], 3385 ["role", {}, "text", "Project Lead"], 3386 ["adr", 3387 { "type":"work" }, 3388 "text", 3389 [ 3390 "", 3391 "Suite 1234", 3392 "4321 Rue Somewhere", 3393 "Quebec", 3394 "QC", 3395 "G1V 2M2", 3396 "Canada" 3397 ] 3398 ], 3399 ["adr", 3400 { 3401 "type":"home", 3402 "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n" 3403 }, 3404 "text", 3405 [ 3406 "", "", "", "", "", "", "" 3407 ] 3408 ], 3409 ["tel", 3410 { "type":["work", "voice"], "pref":"1" }, 3411 "uri", "tel:+1-555-555-1234;ext=102" 3412 ], 3413 ["tel", 3414 { 3415 "type":["work", "cell", "voice", "video", "text"] 3416 }, 3417 "uri", 3418 "tel:+1-555-555-1234" 3419 ], 3420 ["email", 3421 { "type":"work" }, 3422 "text", "joe.user@example.com" 3423 ], 3424 ["geo", { 3425 "type":"work" 3426 }, "uri", "geo:46.772673,-71.282945"], 3427 ["key", 3428 { "type":"work" }, 3429 "uri", "http://www.example.com/joe.user/joe.asc" 3430 ], 3431 ["tz", {}, 3432 "utc-offset", "-05:00"], 3433 ["url", { "type":"home" }, 3434 "uri", "http://example.org"] 3435 ] 3436 ] 3437 } 3439 Figure 23 3441 The arrays in Figure 23 with the first member of "adr" represent 3442 postal addresses. In the first example, the postal address is given 3443 as a an array of strings and constitutes a structured address. For 3444 components of the structured address that are not applicable, an 3445 empty string is given. Each member of that array aligns with the 3446 positions of a vCard as given in [RFC6350]. In this example, the 3447 following data corresponds to the following positional meanings: 3449 1. post office box - not applicable, empty string 3451 2. extended address (e.g., apartment or suite number) - Suite 1234 3453 3. street address - 4321 Rue Somewhere 3455 4. locality (e.g., city) - Quebec 3457 5. region (e.g., state or province) - QC 3459 6. postal code - G1V 2M2 3461 7. country name (full name) - Canada 3463 The second example is an unstructured address. It uses the label 3464 attribute, which is a string containing a newline (\n) character to 3465 separate address components in an unordered, unspecified manner. 3466 Note that in this example the structured address array is still given 3467 but that each string is an empty string. 3469 Appendix D. Secure DNS 3471 Section 6.3 defines the "secureDNS" member to represent secure DNS 3472 information about domain names. 3474 DNSSEC provides data integrity for DNS through digital signing of 3475 resource records. To enable DNSSEC, the zone is signed by one or 3476 more private keys and the signatures stored as RRSIG records. To 3477 complete the chain of trust in the DNS zone hierarchy, a digest of 3478 each DNSKEY record (which contains the public key) must be loaded 3479 into the parent zone, stored as Delegation Signer (DS) records and 3480 signed by the parent's private key (RRSIG DS record), "Resource 3481 Records for the DNS Security Extensions" [RFC4034]. Creating the DS 3482 records in the parent zone can be done by the registration authority, 3483 "Domain Name System (DNS) Security Extensions Mapping for the 3484 Extensible Provisioning Protocol (EPP)" [RFC5910]. 3486 Only DS related information is provided by RDAP, since other 3487 information is not generally stored in the registration database. 3489 Other DNSSEC related information can be retrieved with other DNS 3490 tools such as dig. 3492 The domain object class (Section 6.3) can represent this information 3493 using either the 'dsData' or 'keyData' object arrays. Client 3494 implementers should be aware that some registries do not collect or 3495 do not publish all of the secure DNS meta-information. 3497 Appendix E. Motivations for Using JSON 3499 This section addresses a common question regarding the use of JSON 3500 over other data formats, most notably XML. 3502 It is often pointed out that many DNRs and one RIR support the EPP 3503 [RFC5730] standard, which is an XML serialized protocol. The logic 3504 is that since EPP is a common protocol in the industry it follows 3505 that XML would be a more natural choice. While EPP does influence 3506 this specification quite a bit, EPP serves a different purpose which 3507 is the provisioning of Internet resources between registries and 3508 accredited registrars and serves a much narrower audience than that 3509 envisioned for RDAP. 3511 By contrast, RDAP has a broader audience and is designed for public 3512 consumption of data. Experience from RIRs with first generation 3513 RESTful web services for Whois indicate a large percentage of clients 3514 operate within browsers and other platforms where full-blown XML 3515 stacks are not readily available and where JSON is a better fit. 3517 Additionally, while EPP is used in much of the DNR community it is 3518 not a universal constant in that industry. And finally, EPP's use of 3519 XML predates the specification of JSON. If EPP had been defined 3520 today, it may very well have used JSON instead of XML. 3522 Beyond the specific DNR and RIR communities, the trend in the broader 3523 Internet industry is also switching to JSON over XML, especially in 3524 the area of RESTful web services (see [JSON_acendancy]). Studies 3525 have also found that JSON is generally less bulky and consequently 3526 faster to parse (see [JSON_performance_study]). 3528 Appendix F. Changelog 3530 Initial -00 Adopted as working group document 2012-September-18. 3532 -01 3534 Minor spelling corrections. Changed "Registry Data" to 3535 "Registration Data" for the sake of consistency. 3537 Transitioned to RFC 5988 links and relationship types from our 3538 own custom "uris" structure. 3540 Some examples had 'status' as a string. Those have been 3541 corrected as 'status' is always an array of strings. 3543 Domain variants can now have a multi-valued relationship with 3544 domain registrations. 3546 "names" in the entity object class was changed to 3547 "entityNames". 3549 Some IP address examples change to IPv6. 3551 Change phone number examples and added reference to E.164. 3553 Added section on motivations for using JSON. 3555 Added error response body section. 3557 Added JSON naming section. 3559 Added common data structures section. 3561 Added the IANA Considerations section and the media type 3562 registration. 3564 Added 'lang' name/value. 3566 Added internationalization considerations section. 3568 -02 3570 Removed level from media type registration. 3572 Textual changes as given by Ed Lewis. 3574 Fixed object class linking example noted by Francisco Obispo 3576 Fixed a lot of other examples called out by Alex Sergeyev 3578 Added a note that JSON names are case sensitive 3580 Added 'status' to IP networks as suggested by Alex Sergeyev 3582 -03 3583 Added jCard verbiage and examples and deleted overlapping 3584 contact information and the appendix on postal addresses 3586 Removed the IANA considerations as they have been moved to 3587 another document 3589 Changed the remarks structure to be like notices 3591 Reordering and rewording some of the sections so they flow 3592 better 3594 Added note about object class "self" links 3596 Changed ipAddresses in nameserver object class to separate out 3597 v6 from v4 3599 Changed IP network version identifier from integer to string to 3600 be more consistent with ipAddresses identifier in nameserver 3601 object classes 3603 Changed DNS names to LDH names and Unicode names 3605 Modified the definition of 'conjoined' variant relationship so 3606 it was circular 3608 Added 'proxy', 'private', 'redacted', and 'obscured' status 3609 values (most useful for entities). 3611 Added a privacy considerations section 3613 Added a security considerations section 3615 Added 'reseller' and 'sponsor' to the list of entity roles 3617 Added the 'events' common data structure 3619 Added 'asEventActor' to entities 3621 Added appendix on event modeling 3623 Removed the subclasses/superclassing between RIRs/DNRs for 3624 entity and domain object classes 3626 Change suggested status/relation/etc values to be case/spacing 3627 consistent 3629 Normalized some of the definitions of object class members 3630 Modifying the JSON signaling section to reference the guidance 3631 in draft-ietf-weirds-using-http 3633 Changed the text regarding the process of unknown JSON 3634 attributes 3636 -04 3638 'description' removed from IP network and autnum because it is 3639 redundant with the remarks structure. 3641 Added 'entities' array to nameservers. 3643 Added 'status' to autnum. 3645 Added 'publicIds' to entity and domain. 3647 Added embedded entities to the entity object class. 3649 Added 'idnTable' to variants objects in domain object class. 3651 Changed the numbers for startNum and endNum in autnum to 3652 numbers instead of strings. 3654 Added an example for error response with full rdapConformance 3655 and notices. 3657 Added a section discussing help. 3659 Changed entities to use vcardArray and changed the examples to 3660 be current with jCard. 3662 Added a section on structured vs unstructured addresses. 3664 Added associated to the list of status values. 3666 Added a secure DNS section changed the 'delegationKey' object 3667 into the 'secureDNS' object. 3669 Changed the suggested values to an IANA registry. 3671 Added 'proxy' to the list of entity roles. 3673 -05 3675 Added IANA registration for RDAP JSON Media Type 3676 Added 'associated' status type. This was done earlier but got 3677 dropped during a reorganization of the document. 3679 Added the following status types: 3681 active 3683 inactive 3685 locked 3687 pending create 3689 pending renew 3691 pending update 3693 pending transfer 3695 pending delete 3697 renew prohibited 3699 Added the following event actions: 3701 locked 3703 unlocked 3705 Added the following roles: 3707 notifications 3709 noc 3711 Changed the 'tech' role to 'technical' 3713 Many document reference changes. 3715 Many examples have been fixed. 3717 Added links to dsData and keyData. 3719 Changed flags and protocols to integers in keyData. 3721 Added 'entities' to the specified list for autnum. 3723 Added SHOULD/SHOULD NOT language about using "type": 3724 "application/rdap+json" for self links. 3726 Added 'port43' to ip networks and autnum. 3728 -06 3730 Fix search response example. 3732 Change the returned search arrays to 'domainSearchResults', 3733 'entitySearchResults', and 'nameserverSearchResults'. 3735 -07 3737 'nameservers' in domain object class was changed to 3738 'nameServers' as in the example (note the camel case) 3740 fixed some example per email from James Mitchel 3742 fixed an example per email from Simon Perreault 3744 Added "network" to domain object class. 3746 Added networks and autnums to the entity object class. 3748 Authors' Addresses 3750 Andrew Lee Newton 3751 American Registry for Internet Numbers 3752 3635 Concorde Parkway 3753 Chantilly, VA 20151 3754 US 3756 Email: andy@arin.net 3757 URI: http://www.arin.net 3759 Scott Hollenbeck 3760 Verisign Labs 3761 12061 Bluemont Way 3762 Reston, VA 20190 3763 US 3765 Email: shollenbeck@verisign.com 3766 URI: http://www.verisignlabs.com/