draft-ietf-weirds-json-response-07.txt   draft-ietf-weirds-json-response-08.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft ARIN Internet-Draft ARIN
Intended status: Standards Track S. Hollenbeck Intended status: Standards Track S. Hollenbeck
Expires: November 1, 2014 Verisign Labs Expires: February 15, 2015 Verisign Labs
April 30, 2014 August 14, 2014
JSON Responses for the Registration Data Access Protocol (RDAP) JSON Responses for the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-json-response-07 draft-ietf-weirds-json-response-08
Abstract Abstract
This document describes JSON data structures representing This document describes JSON data structures representing
registration information maintained by Regional Internet Registries registration information maintained by Regional Internet Registries
(RIRs) and Domain Name Registries (DNRs). These data structures are (RIRs) and Domain Name Registries (DNRs). These data structures are
used to form Registration Data Access Protocol (RDAP) query used to form Registration Data Access Protocol (RDAP) query
responses. responses.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 1, 2014. This Internet-Draft will expire on February 15, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4
3. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 6 4. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 6
5. Common Data Structures . . . . . . . . . . . . . . . . . . . 8 5. Common Data Structures . . . . . . . . . . . . . . . . . . . 8
5.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 8 5.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 8
5.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Notices And Remarks . . . . . . . . . . . . . . . . . . . 9 5.3. Notices And Remarks . . . . . . . . . . . . . . . . . . . 9
5.4. Language Identifier . . . . . . . . . . . . . . . . . . . 11 5.4. Language Identifier . . . . . . . . . . . . . . . . . . . 11
5.5. Events . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Events . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. Status . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.6. Status . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. Port 43 Whois Server . . . . . . . . . . . . . . . . . . 13 5.7. Port 43 Whois Server . . . . . . . . . . . . . . . . . . 13
5.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 13 5.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 13
5.9. An Example . . . . . . . . . . . . . . . . . . . . . . . 13 5.9. Object Class Name . . . . . . . . . . . . . . . . . . . . 13
6. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 15 5.10. An Example . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. The Entity Object Class . . . . . . . . . . . . . . . . . 15 6. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. The Nameserver Object Class . . . . . . . . . . . . . . . 22 6.1. The Entity Object Class . . . . . . . . . . . . . . . . . 16
6.3. The Domain Object Class . . . . . . . . . . . . . . . . . 26 6.2. The Nameserver Object Class . . . . . . . . . . . . . . . 23
6.4. The IP Network Object Class . . . . . . . . . . . . . . . 37 6.3. The Domain Object Class . . . . . . . . . . . . . . . . . 27
6.5. Autonomous System Number Entity Object Class . . . . . . 41 6.4. The IP Network Object Class . . . . . . . . . . . . . . . 39
7. Error Response Body . . . . . . . . . . . . . . . . . . . . . 45 6.5. Autonomous System Number Entity Object Class . . . . . . 43
8. Responding to Help Queries . . . . . . . . . . . . . . . . . 46 7. Error Response Body . . . . . . . . . . . . . . . . . . . . . 46
9. Responding To Searches . . . . . . . . . . . . . . . . . . . 47 8. Responding to Help Queries . . . . . . . . . . . . . . . . . 48
10. Indicating Truncated Responses . . . . . . . . . . . . . . . 48 9. Responding To Searches . . . . . . . . . . . . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 10. Indicating Truncated Responses . . . . . . . . . . . . . . . 50
11.1. RDAP JSON Media Type Registration . . . . . . . . . . . 50 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
11.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 51 11.1. RDAP JSON Media Type Registration . . . . . . . . . . . 53
11.2.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 11.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 54
11.2.2. Event Actions . . . . . . . . . . . . . . . . . . . 58 11.2.1. Notice and Remark Types . . . . . . . . . . . . . . 55
11.2.3. Roles . . . . . . . . . . . . . . . . . . . . . . . 60 11.2.2. Status . . . . . . . . . . . . . . . . . . . . . . . 57
11.2.4. Variant Relations . . . . . . . . . . . . . . . . . 64 11.2.3. Event Actions . . . . . . . . . . . . . . . . . . . 62
12. Security Considerations . . . . . . . . . . . . . . . . . . . 65 11.2.4. Roles . . . . . . . . . . . . . . . . . . . . . . . 65
13. Internationalization Considerations . . . . . . . . . . . . . 65 11.2.5. Variant Relations . . . . . . . . . . . . . . . . . 68
13.1. Character Encoding . . . . . . . . . . . . . . . . . . . 65 12. Security Considerations . . . . . . . . . . . . . . . . . . . 69
13.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 65 13. Internationalization Considerations . . . . . . . . . . . . . 69
13.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 65 13.1. Character Encoding . . . . . . . . . . . . . . . . . . . 69
13.4. Internationalized Domain Names . . . . . . . . . . . . . 66 13.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 70
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 66 13.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 70
15. Contributing Authors and Acknowledgements . . . . . . . . . . 66 13.4. Internationalized Domain Names . . . . . . . . . . . . . 70
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 70
16.1. Normative References . . . . . . . . . . . . . . . . . . 67 15. Contributing Authors and Acknowledgements . . . . . . . . . . 70
16.2. Informative References . . . . . . . . . . . . . . . . . 68 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
Appendix A. Suggested Data Modeling with the Entity Object Class 69 16.1. Normative References . . . . . . . . . . . . . . . . . . 71
A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 69 16.2. Informative References . . . . . . . . . . . . . . . . . 72
A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 71 Appendix A. Suggested Data Modeling with the Entity Object Class 73
Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 73 A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 73
Appendix C. Structured vs Unstructured Addresses . . . . . . . . 75 A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 77 Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 77
Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 78 Appendix C. Structured vs Unstructured Addresses . . . . . . . . 79
Appendix F. Changelog . . . . . . . . . . . . . . . . . . . . . 78 Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 82
Appendix F. Changelog . . . . . . . . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction 1. Introduction
This document describes responses in the JSON [RFC4627] format for This document describes responses in the JSON [RFC7159] format for
the RESTful web queries as defined by the Registration Data Access the RESTful web queries as defined by the Registration Data Access
Protocol Lookup Format [I-D.ietf-weirds-rdap-query]. Protocol Lookup Format [I-D.ietf-weirds-rdap-query].
The data model for JSON responses is specified in four sections: The data model for JSON responses is specified in four sections:
1. simple data types conveyed in JSON strings 1. simple data types conveyed in JSON strings
2. data structures specified as JSON arrays or objects that are used 2. data structures specified as JSON arrays or objects that are used
repeatedly when building up larger objects repeatedly when building up larger objects
3. object classes representing structured data corresponding to a 3. object classes representing structured data corresponding to a
given query lookup of a single object
4. the response to an error 4. arrays of objects representing structured data corresponding to a
search for multiple objects
5. the response to an error
The object classes represent responses for two major categories of The object classes represent responses for two major categories of
data: responses returned by Regional Internet Registries (RIRs) for data: responses returned by Regional Internet Registries (RIRs) for
registrations data related to IP addresses, reverse DNS names, and registrations data related to IP addresses, reverse DNS names, and
Autonomous System numbers; and responses returned by Domain Name Autonomous System numbers; and responses returned by Domain Name
Registries (DNRs) for registration data related to forward DNS names. Registries (DNRs) for registration data related to forward DNS names.
The following object classes are served by both RIRs and DNRs: The following object classes are served by both RIRs and DNRs:
1. domains 1. domains
skipping to change at page 4, line 16 skipping to change at page 4, line 22
2. Autonomous System numbers 2. Autonomous System numbers
Object classes defined in this document represent a minimal set of Object classes defined in this document represent a minimal set of
what a compliant client/server MUST understand to function correctly, what a compliant client/server MUST understand to function correctly,
however some deployments may want to include additional object however some deployments may want to include additional object
classes to suit individual needs. Anticipating this need for classes to suit individual needs. Anticipating this need for
extension, Section 3.2 of this document defines a mechanism for extension, Section 3.2 of this document defines a mechanism for
extending the JSON objects that are described in this document. extending the JSON objects that are described in this document.
Positive responses take two forms. A response to a lookup of a
single object in the registration system yeilds an JSON object which
is the subject of the lookup. A response to a search for multiple
objects yields a JSON object which contains an array of JSON objects
that are the subject of the search. In each type of response, other
data structures are present within the topmost JSON object.
2. Terminology and Definitions 2. Terminology and Definitions
The following list describes terminology and definitions used The following list describes terminology and definitions used
throughout this document: throughout this document:
DNR: "Domain Name Registry". DNR: "Domain Name Registry".
LDH: "Letters, Digits, Hyphen". LDH: "Letters, Digits, Hyphen".
member: data found with in an object as defined by JSON member: data found with in an object as defined by JSON
[RFC4627]. [RFC7159].
object: a data structure as defined by JSON [RFC4627]. object: a data structure as defined by JSON [RFC7159].
object class: the definition of members that may be found in JSON object class: the definition of members that may be found in JSON
objects described in this document. objects described in this document.
object instance: an instantiation or specific instance of an object object instance: an instantiation or specific instance of an object
class. class.
RDAP: "Registration Data Access Protocol". RDAP: "Registration Data Access Protocol".
RIR: "Regional Internet Registry". RIR: "Regional Internet Registry".
3. Use of JSON 3. Use of JSON
3.1. Signaling 3.1. Signaling
Media type signaling for the JSON data specified in this document is Media type signaling for the JSON data specified in this document is
specified in [I-D.ietf-weirds-using-http]. specified in [I-D.ietf-weirds-using-http].
3.2. Naming 3.2. Naming
Clients processing JSON [RFC4627] responses are under no obligation Clients processing JSON [RFC7159] responses are under no obligation
to process unrecognized JSON attributes but SHOULD NOT treat them as to process unrecognized JSON attributes but SHOULD NOT treat them as
an error. Servers MAY insert values signified by names into the JSON an error. Servers MAY insert values signified by names into the JSON
responses which are not specified in this document. Insertion of responses which are not specified in this document. Insertion of
unspecified values into JSON responses SHOULD have names prefixed unspecified values into JSON responses SHOULD have names prefixed
with a short identifier followed by an underscore followed by a with a short identifier followed by an underscore followed by a
meaningful name. The full JSON name (the prefix plus the underscore meaningful name. The full JSON name (the prefix plus the underscore
plus the meaningful name) SHOULD adhere to the character and name plus the meaningful name) SHOULD adhere to the character and name
limitations of the prefix registry described in limitations of the prefix registry described in
[I-D.ietf-weirds-using-http]. [I-D.ietf-weirds-using-http].
skipping to change at page 6, line 45 skipping to change at page 6, line 45
value listed is required to appear in a response. In other words, value listed is required to appear in a response. In other words,
servers MAY remove values as is needed by the policies of the server servers MAY remove values as is needed by the policies of the server
operator. operator.
Finally, all JSON names specified in this document are case Finally, all JSON names specified in this document are case
sensitive. Both servers and clients MUST transmit and process them sensitive. Both servers and clients MUST transmit and process them
using the specified character case. using the specified character case.
4. Common Data Types 4. Common Data Types
JSON [RFC4627] defines the data types of a number, character string, JSON [RFC7159] defines the data types of a number, character string,
boolean, array, object and null. This section describes the boolean, array, object and null. This section describes the
semantics and/or syntax reference for data types used in this semantics and/or syntax reference for data types used in this
document derived from the JSON character string. document derived from the JSON character string.
'handle': DNRs and RIRs have registry-unique identifiers that 'handle': DNRs and RIRs have registry-unique identifiers that
may be used to specifically reference an object may be used to specifically reference an object
instance. The semantics of this data type as found instance. The semantics of this data type as found
in this document is to be a registry-unique in this document is to be a registry-unique
reference to the closest enclosing object where the reference to the closest enclosing object where the
value is found. The data type names 'registryId', value is found. The data type names 'registryId',
skipping to change at page 8, line 7 skipping to change at page 8, line 7
defined in [RFC3339]. defined in [RFC3339].
URIs: The syntax for values denoting a Uniform Resource URIs: The syntax for values denoting a Uniform Resource
Identifier (URI) is defined by [RFC3986]. Identifier (URI) is defined by [RFC3986].
Contact information is defined using JSON vCards as described in Contact information is defined using JSON vCards as described in
[I-D.ietf-jcardcal-jcard] [I-D.ietf-jcardcal-jcard]
5. Common Data Structures 5. Common Data Structures
This section defines common data structures used commonly in object This section defines common data structures used commonly in
classes. responses and object classes.
5.1. RDAP Conformance 5.1. RDAP Conformance
The first data structure is named "rdapConformance" and is simply an The first data structure is named "rdapConformance" and is simply an
array of strings, each providing a hint as to the specifications used array of strings, each providing a hint as to the specifications used
in the construction of the response. This data structure appears in the construction of the response. This data structure appears
only in the top most object of a response. only in the top most object of a response.
An example rdapConformance data structure: An example rdapConformance data structure:
skipping to change at page 9, line 49 skipping to change at page 9, line 49
"href" : "http://example.com/ip/2001:db8::/48", "href" : "http://example.com/ip/2001:db8::/48",
"type" : "application/rdap+json" "type" : "application/rdap+json"
} }
] ]
5.3. Notices And Remarks 5.3. Notices And Remarks
The "notices" and "remarks" data structures take the same form. The The "notices" and "remarks" data structures take the same form. The
"notices" structure denotes information about the service providing "notices" structure denotes information about the service providing
RDAP information, whereas the "remarks" structure denotes information RDAP information and/or information about the entire response,
about the object class it is contained within (see Section 6 whereas the "remarks" structure denotes information about the object
regarding object classes). class it is contained within (see Section 6 regarding object
classes).
Both are an array of objects. Each object contains an optional Both are an array of objects. Each object contains an optional
"title" string representing the title of the object, an array of "title" string representing the title of the object, an optional
strings named "description" for the purposes of conveying any "type" string denoting a registered type of remark or notice (see
descriptive text, and an optional "links" array as described in Section 11.2.1), an array of strings named "description" for the
Section 5.2. purposes of conveying any descriptive text, and an optional "links"
array as described in Section 5.2.
An example of the notices data structure: An example of the notices data structure:
"notices" : "notices" :
[ [
{ {
"title" : "Terms of Use", "title" : "Terms of Use",
"description" : "description" :
[ [
"Service subject to The Registry of the Moon's TOS.", "Service subject to The Registry of the Moon's TOS.",
skipping to change at page 11, line 23 skipping to change at page 11, line 23
"Originally written by Terry Sullivan." "Originally written by Terry Sullivan."
] ]
} }
] ]
Figure 7 Figure 7
Note that objects in the "remarks" array may also have a "links" Note that objects in the "remarks" array may also have a "links"
array. array.
While the "title" and "description" fields are intended primarily for
human consumption, the "type" string contains a well-known value to
be registered with IANA (see Section 11.2.1) for programattic use.
An example of the remarks data structure:
"remarks" :
[
{
"type" : "object truncated due to authorization",
"description" :
[
"Some registration data may not have been given.",
"Use proper authorization credentials to see all of it."
]
}
]
Figure 8
While the "remarks" array will appear in many object classes in a While the "remarks" array will appear in many object classes in a
response, the "notices" array appears only in the top most object of response, the "notices" array appears only in the top most object of
a response. a response.
5.4. Language Identifier 5.4. Language Identifier
This data structure is a simple JSON name/value of "lang" with a This data structure is a simple JSON name/value of "lang" with a
string containing a language identifier as described by [RFC5646]. string containing a language identifier as described by [RFC5646].
"lang" : "mn-Cyrl-MN" "lang" : "mn-Cyrl-MN"
Figure 8 Figure 9
The 'lang' attribute may appear anywhere in an object class or data The 'lang' attribute may appear anywhere in an object class or data
structure. structure.
5.5. Events 5.5. Events
This data structure represents events that have occurred on an This data structure represents events that have occurred on an
instance of an object class (see Section 6 regarding object classes). instance of an object class (see Section 6 regarding object classes).
This is an example of an "events" array. This is an example of an "events" array.
skipping to change at page 12, line 21 skipping to change at page 12, line 33
"eventActor" : "SOMEID-LUNARNIC", "eventActor" : "SOMEID-LUNARNIC",
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
}, },
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventActor" : "OTHERID-LUNARNIC", "eventActor" : "OTHERID-LUNARNIC",
"eventDate" : "1991-12-31T23:59:60Z" "eventDate" : "1991-12-31T23:59:60Z"
} }
] ]
Figure 9 Figure 10
The "events" array consists of objects, each with the following The "events" array consists of objects, each with the following
members: members:
o 'eventAction' -- a string denoting the reason for the event o 'eventAction' -- a string denoting the reason for the event
o 'eventActor' -- an optional identifier denoting the actor o 'eventActor' -- an optional identifier denoting the actor
responsible for the event responsible for the event
o 'eventDate' -- a string containing the time and date the event o 'eventDate' -- a string containing the time and date the event
skipping to change at page 12, line 44 skipping to change at page 13, line 7
o 'links' -- see Section 5.2. o 'links' -- see Section 5.2.
Events can be future dated. One use case for future dating of events Events can be future dated. One use case for future dating of events
is to denote when an object expires from a registry. is to denote when an object expires from a registry.
The 'links' array in this data structure is provided for references The 'links' array in this data structure is provided for references
to the event actor. If the event actor being referenced is an RDAP to the event actor. If the event actor being referenced is an RDAP
entity, the link reference SHOULD be made with "rel" of "related" and entity, the link reference SHOULD be made with "rel" of "related" and
"type" of "application/rdap+json". "type" of "application/rdap+json".
See Section 11.2.2 for a list of values for the 'eventAction' string. See Section 11.2.3 for a list of values for the 'eventAction' string.
See Appendix B regarding the various ways events can be modeled. See Appendix B regarding the various ways events can be modeled.
5.6. Status 5.6. Status
This data structure, named 'status', is an array of strings This data structure, named 'status', is an array of strings
indicating the state of a registered object (see Section 11.2.1 for a indicating the state of a registered object (see Section 11.2.2 for a
list of values). list of values).
5.7. Port 43 Whois Server 5.7. Port 43 Whois Server
This data structure, named 'port43', is a simple string containing This data structure, named 'port43', is a simple string containing
the fully-qualified host name of the WHOIS [RFC3912] server where the the fully-qualified host name of the WHOIS [RFC3912] server where the
containing object instance may be found. Note that this is not a containing object instance may be found. Note that this is not a
URI, as there is no WHOIS URI scheme. URI, as there is no WHOIS URI scheme.
5.8. Public IDs 5.8. Public IDs
skipping to change at page 13, line 32 skipping to change at page 13, line 43
The following is an example of a 'publicIds' structure. The following is an example of a 'publicIds' structure.
"publicIds": "publicIds":
[ [
{ {
"type":"IANA Registrar ID", "type":"IANA Registrar ID",
"identifier":"1" "identifier":"1"
} }
] ]
Figure 10 Figure 11
5.9. Object Class Name
This data structure, named "objectClassName", gives the object class
name of a particular object as a string. This aids clients in
identifying the type of object being processed. Servers SHOULD NOT
omit this string so that clients can more easily identify the type of
object.
5.10. An Example
5.9. An Example
This is an example response with both rdapConformance and notices This is an example response with both rdapConformance and notices
embedded: embedded:
{ {
"rdapConformance" : "rdapConformance" :
[ [
"rdap_level_0" "rdap_level_0"
], ],
"notices" : "notices" :
[ [
skipping to change at page 14, line 33 skipping to change at page 15, line 31
{ {
"value" : "http://example.net/ip/192.0.2.0/24", "value" : "http://example.net/ip/192.0.2.0/24",
"rel" : "alternate", "rel" : "alternate",
"type" : "text/html", "type" : "text/html",
"href" : "http://www.example.com/redaction_policy.html" "href" : "http://www.example.com/redaction_policy.html"
} }
] ]
} }
], ],
"lang" : "en", "lang" : "en",
"objectClassName" : "ip network",
"startAddress" : "192.0.2.0", "startAddress" : "192.0.2.0",
"endAddress" : "192.0.2.255", "endAddress" : "192.0.2.255",
"handle" : "XXXX-RIR", "handle" : "XXXX-RIR",
"ipVersion" : "v4", "ipVersion" : "v4",
"name": "NET-RTR-1", "name": "NET-RTR-1",
"parentHandle" : "YYYY-RIR", "parentHandle" : "YYYY-RIR",
"remarks" : "remarks" :
[ [
{ {
"description" : "description" :
[ [
"She sells sea shells down by the sea shore.", "She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan." "Originally written by Terry Sullivan."
] ]
} }
] ]
} }
Figure 11 Figure 12
6. Object Classes 6. Object Classes
Object classes represent structures appropriate for a response from Object classes represent structures appropriate for a response from
the queries specified in [I-D.ietf-weirds-rdap-query]. the queries specified in [I-D.ietf-weirds-rdap-query].
Each object class contains a "links" array as specified in Each object class contains a "links" array as specified in
Section 5.2. For every object class instance in a response, whether Section 5.2. For every object class instance in a response, whether
the object class instance is directly representing the response to a the object class instance is directly representing the response to a
query or is embedded in other object class instances, servers SHOULD query or is embedded in other object class instances or is an item in
provide a link representing a URI for that object class instance a search result set, servers SHOULD provide a link representing a URI
using the "self" relationship as specified in the IANA registry for that object class instance using the "self" relationship as
specified by [RFC5988]. As explained in Section 6.2, this may be not specified in the IANA registry specified by [RFC5988]. As explained
always be possible for name server data. Clients MUST be able to in Section 6.2, this may be not always be possible for name server
process object instances without a "self" link. When present, data. Clients MUST be able to process object instances without a
clients MAY use the self link for caching data. Servers MAY provide "self" link. When present, clients MAY use the self link for caching
more than one "self" link for any given object instance. data. Servers MAY provide more than one "self" link for any given
object instance.
Self links SHOULD contain a "type" element containing the Self links SHOULD contain a "type" element containing the
"application/rdap+json" media type when referencing RDAP object "application/rdap+json" media type when referencing RDAP object
instances as defined by this document. Clients SHOULD NOT assume instances as defined by this document. Clients SHOULD NOT assume
self links without this media type are represented as RDAP objects as self links without this media type are represented as RDAP objects as
defined by this document. defined by this document.
This is an example of the "links" array with a self link to an object This is an example of the "links" array with a self link to an object
class: class:
"links" : "links" :
[ [
{ {
"value" : "http://example.com/ip/2001:db8::123", "value" : "http://example.com/ip/2001:db8::123",
"rel" : "self", "rel" : "self",
"href" : "http://example.com/ip/2001:db8::123", "href" : "http://example.com/ip/2001:db8::123",
"type" : "application/rdap+json" "type" : "application/rdap+json"
} }
] ]
In addition to the "links" array with a self link, servers SHOULD
provide an "objectClassName" (see Section 5.9) string in each object.
6.1. The Entity Object Class 6.1. The Entity Object Class
The entity object class appears throughout this document and is an The entity object class appears throughout this document and is an
appropriate response for the /entity/XXXX query defined in appropriate response for the /entity/XXXX query defined in
Registration Data Access Protocol Lookup Format Registration Data Access Protocol Lookup Format
[I-D.ietf-weirds-rdap-query]. This object class represents the [I-D.ietf-weirds-rdap-query]. This object class represents the
information of organizations, corporations, governments, non-profits, information of organizations, corporations, governments, non-profits,
clubs, individual persons, and informal groups of people. All of clubs, individual persons, and informal groups of people. All of
these representations are so similar that it is best to represent these representations are so similar that it is best to represent
them in JSON [RFC4627] with one construct, the entity object class, them in JSON [RFC7159] with one construct, the entity object class,
to aid in the re-use of code by implementers. to aid in the re-use of code by implementers.
The entity object is served by both RIRs and DNRs. The following is The entity object is served by both RIRs and DNRs. The following is
an example of an entity that might be served by an RIR. For an example of an entity that might be served by an RIR. For
illustrative purposes, it does not include rdapConformance or notices illustrative purposes, it does not include rdapConformance or notices
data structures. data structures.
{ {
"objectClassName" : "entity",
"handle":"XXXX", "handle":"XXXX",
"vcardArray":[ "vcardArray":[
"vcard", "vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"], ["fn", {}, "text", "Joe User"],
["n", {}, "text", ["n", {}, "text",
["User", "Joe", "", "", ["ing. jr", "M.Sc."]] ["User", "Joe", "", "", ["ing. jr", "M.Sc."]]
], ],
["bday", {}, "date-and-or-time", "--02-03"], ["bday", {}, "date-and-or-time", "--02-03"],
skipping to change at page 19, line 9 skipping to change at page 20, line 9
} }
Entities may also have other entities embedded with them in an array. Entities may also have other entities embedded with them in an array.
This can be used to model an organization with specific individuals This can be used to model an organization with specific individuals
fulfilling designated roles of responsibility. fulfilling designated roles of responsibility.
The following is an elided example of an entity with embedded The following is an elided example of an entity with embedded
entities. entities.
{ {
"objectClassName" : "entity",
"handle" : "ANENTITY", "handle" : "ANENTITY",
"roles" : [ "registrar" ], "roles" : [ "registrar" ],
... ...
"entities" : "entities" :
[ [
{ {
"objectClassName" : "entity",
"handle": "ANEMBEDDEDENTITY", "handle": "ANEMBEDDEDENTITY",
"roles" : [ "technical" ], "roles" : [ "technical" ],
... ...
}, },
... ...
], ],
... ...
} }
Figure 12 Figure 13
This object has the following members: This object has the following members:
o objectClassName -- which should be the string "entity"
o handle -- a string representing an registry unique identifier of o handle -- a string representing an registry unique identifier of
the entity the entity
o vcardArray -- a JSON vCard with the entity's contact information o vcardArray -- a JSON vCard with the entity's contact information
o roles -- an array of strings, each signifying the relationship an o roles -- an array of strings, each signifying the relationship an
object would have with its closest containing object (see object would have with its closest containing object (see
Section 11.2.3 for a list of values) Section 11.2.4 for a list of values)
o publicIds - see Section 5.8 o publicIds - see Section 5.8
o entities - an array of entity objects as defined by this section. o entities - an array of entity objects as defined by this section.
o remarks -- see Section 5.3 o remarks -- see Section 5.3
o links -- see Section 5.2 o links -- see Section 5.2
o events -- see Section 5.5 o events -- see Section 5.5
skipping to change at page 20, line 21 skipping to change at page 21, line 24
o networks -- an array of IP network objects as defined in o networks -- an array of IP network objects as defined in
Section 6.4 Section 6.4
o autnums -- an array of autnum objects as defined in Section 6.5 o autnums -- an array of autnum objects as defined in Section 6.5
The following is an example of a entity that might be served by a The following is an example of a entity that might be served by a
DNR. For illustrative purposes, it does not include rdapConformance DNR. For illustrative purposes, it does not include rdapConformance
or notices data structures. or notices data structures.
{ {
"objectClassName" : "entity",
"handle":"XXXX", "handle":"XXXX",
"vcardArray":[ "vcardArray":[
"vcard", "vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"], ["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"], ["kind", {}, "text", "individual"],
["lang", { ["lang", {
"pref":"1" "pref":"1"
}, "language-tag", "fr"], }, "language-tag", "fr"],
skipping to change at page 23, line 6 skipping to change at page 24, line 6
name, while other DNRs model nameservers as "first class objects". name, while other DNRs model nameservers as "first class objects".
The nameserver object class accommodates both models and degrees of The nameserver object class accommodates both models and degrees of
variation in between. variation in between.
The following is an example of a nameserver object. For illustrative The following is an example of a nameserver object. For illustrative
purposes, it does not include rdapConformance or notices data purposes, it does not include rdapConformance or notices data
structures. structures.
{ {
"objectClassName" : "nameserver",
"handle" : "XXXX", "handle" : "XXXX",
"ldhName" : "ns1.xn--fo-5ja.example", "ldhName" : "ns1.xn--fo-5ja.example",
"unicodeName" : "foo.example", "unicodeName" : "foo.example",
"status" : [ "active" ], "status" : [ "active" ],
"ipAddresses" : "ipAddresses" :
{ {
"v4": [ "192.0.2.1", "192.0.2.2" ], "v4": [ "192.0.2.1", "192.0.2.2" ],
"v6": [ "2001:db8::123" ] "v6": [ "2001:db8::123" ]
}, },
"remarks" : "remarks" :
skipping to change at page 23, line 49 skipping to change at page 24, line 50
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
}, },
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:60Z", "eventDate" : "1991-12-31T23:59:60Z",
"eventActor" : "joe@example.com" "eventActor" : "joe@example.com"
} }
] ]
} }
Figure 13 Figure 14
Figure 13 is an example of a nameserver object with all values given. Figure 14 is an example of a nameserver object with all values given.
Registries using a first-class nameserver data model would embed this Registries using a first-class nameserver data model would embed this
in domain objects as well as allowing references to it with the "/ in domain objects as well as allowing references to it with the
nameserver" query type (all depending on the registry operators "/nameserver" query type (all depending on the registry operators
policy). Other registries may pare back the information as needed. policy). Other registries may pare back the information as needed.
Figure 14 is an example of a nameserver object as would be found in Figure 15 is an example of a nameserver object as would be found in
RIRs and some DNRs, while Figure 15 is an example of a nameserver RIRs and some DNRs, while Figure 16 is an example of a nameserver
object as would be found in other DNRs. object as would be found in other DNRs.
The following is an example of the simplest nameserver object: The following is an example of the simplest nameserver object:
{ {
"objectClassName" : "nameserver",
"ldhName" : "ns1.example.com" "ldhName" : "ns1.example.com"
} }
Figure 14 Figure 15
The following is an example of a simple nameserver object that might The following is an example of a simple nameserver object that might
be commonly used by DNRs: be commonly used by DNRs:
{ {
"objectClassName" : "nameserver",
"ldhName" : "ns1.example.com", "ldhName" : "ns1.example.com",
"ipAddresses" : { "v6" : [ "2001:db8::123", "2001:db8::124" ] } "ipAddresses" : { "v6" : [ "2001:db8::123", "2001:db8::124" ] }
} }
Figure 15 Figure 16
As nameservers can be modeled by some registries to be first-class As nameservers can be modeled by some registries to be first-class
objects, they may also have an array of entities (Section 6.1) objects, they may also have an array of entities (Section 6.1)
embedded to signify parties responsible for the maintenance, embedded to signify parties responsible for the maintenance,
registrations, etc. of the nameservers. registrations, etc. of the nameservers.
The following is an elided example of a nameserver with embedded The following is an elided example of a nameserver with embedded
entities. entities.
{ {
"objectClassName", "nameserver",
"handle" : "XXXX", "handle" : "XXXX",
"ldhName" : "ns1.xn--fo-5ja.example", "ldhName" : "ns1.xn--fo-5ja.example",
... ...
"entities" : "entities" :
[ [
... ...
], ],
... ...
} }
Figure 16 Figure 17
The nameserver object class has the following members: The nameserver object class has the following members:
o objectClassName - should be the string "nameserver"
o handle -- a string representing an registry unique identifier of o handle -- a string representing an registry unique identifier of
the nameserver the nameserver
o ldhName -- a string containing the LDH name of the nameserver (see o ldhName -- a string containing the LDH name of the nameserver (see
Section 4) Section 4)
o unicodeName -- a string containing a DNS Unicode name of the o unicodeName -- a string containing a DNS Unicode name of the
nameserver (see Section 4) nameserver (see Section 4)
o ipAddresses -- an object containing the following members: o ipAddresses -- an object containing the following members:
skipping to change at page 26, line 21 skipping to change at page 27, line 24
In both cases, the high level structure of the domain object class In both cases, the high level structure of the domain object class
consists of information about the domain registration, nameserver consists of information about the domain registration, nameserver
information related to the domain name, and entities related to the information related to the domain name, and entities related to the
domain name (e.g. registrant information, contacts, etc.). domain name (e.g. registrant information, contacts, etc.).
The following is an elided example of the domain object showing the The following is an elided example of the domain object showing the
high level structure: high level structure:
{ {
"objectClassName" : "domain",
"handle" : "XXX", "handle" : "XXX",
"ldhName" : "blah.example.com", "ldhName" : "blah.example.com",
... ...
"nameServers" : "nameServers" :
[ [
... ...
], ],
... ...
"entities" : "entities" :
[ [
... ...
] ]
} }
The following is a description of the members of this object: The following is a description of the members of this object:
o objectClassName -- should be the string "domain"
o handle -- a string representing a registry unique identifier of o handle -- a string representing a registry unique identifier of
the domain object instance the domain object instance
o ldhName -- a string describing a domain name in LDH form as o ldhName -- a string describing a domain name in LDH form as
described in Section 4 described in Section 4
o unicodeName -- a string containing a domain name with U-labels as o unicodeName -- a string containing a domain name with U-labels as
described in Section 4 described in Section 4
o variants -- an array of objects, each containing the following o variants -- an array of objects, each containing the following
values: values:
* relation -- an array of strings, with each string denoting the * relation -- an array of strings, with each string denoting the
relationship between the variants and the containing domain relationship between the variants and the containing domain
object (see Section 11.2.4 for a list of suggested variant object (see Section 11.2.5 for a list of suggested variant
relations). relations).
* idnTable -- the name of the IDN table of codepoints, such as * idnTable -- the name of the IDN table of codepoints, such as
one listed with the IANA (see IDN tables [IANA_IDNTABLES]). one listed with the IANA (see IDN tables [IANA_IDNTABLES]).
* variantNames -- an array of objects, with each object * variantNames -- an array of objects, with each object
containing an "ldhName" member and a "unicodeName" member (see containing an "ldhName" member and a "unicodeName" member (see
Section 4). Section 4).
o nameServers -- an array of nameserver objects as defined by o nameServers -- an array of nameserver objects as defined by
skipping to change at page 28, line 47 skipping to change at page 30, line 8
o network - represents the IP network for which a reverse DNS domain o network - represents the IP network for which a reverse DNS domain
is referenced. See Section 6.4 is referenced. See Section 6.4
The following is an example of a JSON domain object representing a The following is an example of a JSON domain object representing a
reverse DNS delegation point that might be served by an RIR. For reverse DNS delegation point that might be served by an RIR. For
illustrative purposes, it does not include rdapConformance or notices illustrative purposes, it does not include rdapConformance or notices
data structures. data structures.
{ {
"objectClassName" : "domain",
"handle" : "XXXX", "handle" : "XXXX",
"ldhName" : "192.in-addr.arpa", "ldhName" : "192.in-addr.arpa",
"nameServers" : "nameServers" :
[ [
{ "ldhName" : "ns1.rir.example" }, {
{ "ldhName" : "ns2.rir.example" } "objectClassName" : "nameserver",
"ldhName" : "ns1.rir.example"
},
{
"objectClassName" : "nameserver",
"ldhName" : "ns2.rir.example"
}
], ],
"secureDNS": "secureDNS":
{ {
"delegationSigned": true, "delegationSigned": true,
"dsData": "dsData":
[ [
{ {
"keyTag": 12345, "keyTag": 12345,
"algorithm": 3, "algorithm": 3,
"digestType": 1, "digestType": 1,
skipping to change at page 30, line 5 skipping to change at page 31, line 22
}, },
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:60Z", "eventDate" : "1991-12-31T23:59:60Z",
"eventActor" : "joe@example.com" "eventActor" : "joe@example.com"
} }
], ],
"entities" : "entities" :
[ [
{ {
"objectClassName" : "entity",
"handle" : "XXXX", "handle" : "XXXX",
"vcardArray":[ "vcardArray":[
"vcard", "vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"], ["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"], ["kind", {}, "text", "individual"],
["lang", { ["lang", {
"pref":"1" "pref":"1"
}, "language-tag", "fr"], }, "language-tag", "fr"],
skipping to change at page 31, line 34 skipping to change at page 33, line 4
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:60Z", "eventDate" : "1991-12-31T23:59:60Z",
"eventActor" : "joe@example.com" "eventActor" : "joe@example.com"
} }
] ]
} }
], ],
"network" : "network" :
{ {
"objectClassName" : "ip network",
"handle" : "XXXX-RIR", "handle" : "XXXX-RIR",
"startAddress" : "2001:db8::0", "startAddress" : "2001:db8::0",
"endAddress" : "2001:db8::0:FFFF:FFFF:FFFF:FFFF:FFFF", "endAddress" : "2001:db8::0:FFFF:FFFF:FFFF:FFFF:FFFF",
"ipVersion" : "v6", "ipVersion" : "v6",
"name": "NET-RTR-1", "name": "NET-RTR-1",
"type" : "DIRECT ALLOCATION", "type" : "DIRECT ALLOCATION",
"country" : "AU", "country" : "AU",
"parentHandle" : "YYYY-RIR", "parentHandle" : "YYYY-RIR",
"status" : [ "allocated" ] "status" : [ "allocated" ]
} }
} }
The following is an example of a JSON domain object representing a The following is an example of a JSON domain object representing a
forward DNS delegation point that might be served by a DNR. For forward DNS delegation point that might be served by a DNR. For
illustrative purposes, it does not include rdapConformance or notices illustrative purposes, it does not include rdapConformance or notices
data structures. data structures.
{ {
"objectClassName" : "domain",
"handle" : "XXXX", "handle" : "XXXX",
"ldhName" : "xn--fo-5ja.example", "ldhName" : "xn--fo-5ja.example",
"unicodeName" : "foo.example", "unicodeName" : "foo.example",
"variants" : "variants" :
[ [
{ {
"relation" : [ "registered", "conjoined" ], "relation" : [ "registered", "conjoined" ],
"variantNames" : "variantNames" :
[ [
{ {
skipping to change at page 32, line 47 skipping to change at page 34, line 19
"status" : [ "locked", "transfer prohibited" ], "status" : [ "locked", "transfer prohibited" ],
"publicIds":[ "publicIds":[
{ {
"type":"ENS_Auth ID", "type":"ENS_Auth ID",
"identifier":"1234567890" "identifier":"1234567890"
} }
], ],
"nameServers" : "nameServers" :
[ [
{ {
"objectClassName" : "nameserver",
"handle" : "XXXX", "handle" : "XXXX",
"ldhName" : "ns1.example.com", "ldhName" : "ns1.example.com",
"status" : [ "active" ], "status" : [ "active" ],
"ipAddresses" : "ipAddresses" :
{ {
"v6": [ "2001:db8::123", "2001:db8::124" ], "v6": [ "2001:db8::123", "2001:db8::124" ],
"v4": [ "192.0.2.1", "192.0.2.2" ] "v4": [ "192.0.2.1", "192.0.2.2" ]
}, },
"remarks" : "remarks" :
[ [
skipping to change at page 33, line 30 skipping to change at page 35, line 4
"rel" : "self", "rel" : "self",
"href" : "http://example.net/nameserver/XXXX", "href" : "http://example.net/nameserver/XXXX",
"type" : "application/rdap+json" "type" : "application/rdap+json"
} }
], ],
"events" : "events" :
[ [
{ {
"eventAction" : "registration", "eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
}, },
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:60Z" "eventDate" : "1991-12-31T23:59:60Z"
} }
] ]
}, },
{ {
"objectClassName" : "nameserver",
"handle" : "XXXX", "handle" : "XXXX",
"ldhName" : "ns2.example.com", "ldhName" : "ns2.example.com",
"status" : [ "active" ], "status" : [ "active" ],
"ipAddresses" : "ipAddresses" :
{ {
"v6" : [ "2001:db8::125", "2001:db8::126" ], "v6" : [ "2001:db8::125", "2001:db8::126" ],
"v4" : [ "192.0.2.3", "192.0.2.4" ] "v4" : [ "192.0.2.3", "192.0.2.4" ]
}, },
"remarks" : "remarks" :
[ [
skipping to change at page 35, line 49 skipping to change at page 37, line 25
}, },
{ {
"eventAction" : "expiration", "eventAction" : "expiration",
"eventDate" : "2016-12-31T23:59:60Z", "eventDate" : "2016-12-31T23:59:60Z",
"eventActor" : "joe@example.com" "eventActor" : "joe@example.com"
} }
], ],
"entities" : "entities" :
[ [
{ {
"objectClassName" : "entity",
"handle" : "XXXX", "handle" : "XXXX",
"vcardArray":[ "vcardArray":[
"vcard", "vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"], ["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"], ["kind", {}, "text", "individual"],
["lang", { ["lang", {
"pref":"1" "pref":"1"
}, "language-tag", "fr"], }, "language-tag", "fr"],
["lang", { ["lang", {
"pref":"2" "pref":"2"
}, "language-tag", "en"], }, "language-tag", "en"],
skipping to change at page 38, line 9 skipping to change at page 39, line 21
[I-D.ietf-weirds-rdap-query]. There is no equivalent object class [I-D.ietf-weirds-rdap-query]. There is no equivalent object class
for DNRs. The high level structure of the IP network object class for DNRs. The high level structure of the IP network object class
consists of information about the network registration and entities consists of information about the network registration and entities
related to the IP network (e.g. registrant information, contacts, related to the IP network (e.g. registrant information, contacts,
etc...). etc...).
The following is an elided example of the IP network object type The following is an elided example of the IP network object type
showing the high level structure: showing the high level structure:
{ {
"objectClassName" : "ip network",
"handle" : "XXX", "handle" : "XXX",
... ...
"entities" : "entities" :
[ [
... ...
] ]
} }
The following is an example of the JSON object for the network The following is an example of the JSON object for the network
registration information. For illustrative purposes, it does not registration information. For illustrative purposes, it does not
include rdapConformance or notices data structures. include rdapConformance or notices data structures.
{ {
"objectClassName" : "ip network",
"handle" : "XXXX-RIR", "handle" : "XXXX-RIR",
"startAddress" : "2001:db8::0", "startAddress" : "2001:db8::0",
"endAddress" : "2001:db8::0:FFFF:FFFF:FFFF:FFFF:FFFF", "endAddress" : "2001:db8::0:FFFF:FFFF:FFFF:FFFF:FFFF",
"ipVersion" : "v6", "ipVersion" : "v6",
"name": "NET-RTR-1", "name": "NET-RTR-1",
"type" : "DIRECT ALLOCATION", "type" : "DIRECT ALLOCATION",
"country" : "AU", "country" : "AU",
"parentHandle" : "YYYY-RIR", "parentHandle" : "YYYY-RIR",
"status" : [ "allocated" ], "status" : [ "allocated" ],
"remarks" : "remarks" :
skipping to change at page 39, line 24 skipping to change at page 40, line 40
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
}, },
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:60Z" "eventDate" : "1991-12-31T23:59:60Z"
} }
], ],
"entities" : "entities" :
[ [
{ {
"objectClassName" : "entity",
"handle" : "XXXX", "handle" : "XXXX",
"vcardArray":[ "vcardArray":[
"vcard", "vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"], ["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"], ["kind", {}, "text", "individual"],
["lang", { ["lang", {
"pref":"1" "pref":"1"
}, "language-tag", "fr"], }, "language-tag", "fr"],
skipping to change at page 41, line 4 skipping to change at page 42, line 20
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
}, },
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:60Z" "eventDate" : "1991-12-31T23:59:60Z"
} }
] ]
} }
] ]
} }
The following is a description of the members of this object: The following is a description of the members of this object:
o objectClassName -- should be the string "ip network"
o handle -- a string representing an RIR unique identifier of the o handle -- a string representing an RIR unique identifier of the
network registration network registration
o startAddress -- the starting IP address of the network, either o startAddress -- the starting IP address of the network, either
IPv4 or IPv6 IPv4 or IPv6
o endAddress -- the ending IP address of the network, either IPv4 or o endAddress -- the ending IP address of the network, either IPv4 or
IPv6 IPv6
o ipVersion -- a string signifying the IP protocol version of the o ipVersion -- a string signifying the IP protocol version of the
skipping to change at page 42, line 13 skipping to change at page 43, line 32
consists of information about the network registration and entities consists of information about the network registration and entities
related to the autnum registration (e.g. registrant information, related to the autnum registration (e.g. registrant information,
contacts, etc.), and is similar to the IP Network entity object contacts, etc.), and is similar to the IP Network entity object
class. class.
The following is an example of a JSON object representing an autnum. The following is an example of a JSON object representing an autnum.
For illustrative purposes, it does not include rdapConformance or For illustrative purposes, it does not include rdapConformance or
notices data structures. notices data structures.
{ {
"objectClassName" : "autnum",
"handle" : "XXXX-RIR", "handle" : "XXXX-RIR",
"startAutnum" : 10, "startAutnum" : 10,
"endAutnum" : 15, "endAutnum" : 15,
"name": "AS-RTR-1", "name": "AS-RTR-1",
"type" : "DIRECT ALLOCATION", "type" : "DIRECT ALLOCATION",
"status" : [ "allocated" ], "status" : [ "allocated" ],
"country": "AU", "country": "AU",
"remarks" : "remarks" :
[ [
{ {
skipping to change at page 43, line 4 skipping to change at page 44, line 23
{ {
"eventAction" : "registration", "eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
}, },
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:60Z" "eventDate" : "1991-12-31T23:59:60Z"
} }
], ],
"entities" : "entities" :
[ [
{ {
"objectClassName" : "entity",
"handle" : "XXXX", "handle" : "XXXX",
"vcardArray":[ "vcardArray":[
"vcard", "vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"], ["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"], ["kind", {}, "text", "individual"],
["lang", { ["lang", {
"pref":"1" "pref":"1"
}, "language-tag", "fr"], }, "language-tag", "fr"],
skipping to change at page 44, line 33 skipping to change at page 46, line 4
"eventAction" : "registration", "eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
}, },
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:60Z" "eventDate" : "1991-12-31T23:59:60Z"
} }
] ]
} }
] ]
} }
The following is a description of the members of this object: The following is a description of the members of this object:
o objectClassName -- should be the string "autnum"
o handle -- a string representing an RIR-unique identifier of the o handle -- a string representing an RIR-unique identifier of the
autnum registration autnum registration
o startAutnum -- a number representing the starting number [RFC5396] o startAutnum -- a number representing the starting number [RFC5396]
in the block of autonomous system numbers in the block of autonomous system numbers
o endAutnum -- a number representing the ending number [RFC5396] in o endAutnum -- a number representing the ending number [RFC5396] in
the block of autonomous system numbers the block of autonomous system numbers
o name -- an identifier assigned to the autnum registration by the o name -- an identifier assigned to the autnum registration by the
skipping to change at page 45, line 44 skipping to change at page 47, line 19
{ {
"errorCode": 418, "errorCode": 418,
"title": "Your beverage choice is not available", "title": "Your beverage choice is not available",
"description": "description":
[ [
"I know coffee has more ummppphhh.", "I know coffee has more ummppphhh.",
"Sorry, dude!" "Sorry, dude!"
] ]
} }
Figure 17 Figure 18
A client MAY simply use the HTTP response code as the server is not A client MAY simply use the HTTP response code as the server is not
required to include error data in the response body. However, if a required to include error data in the response body. However, if a
client wishes to parse the error data, it SHOULD first check that the client wishes to parse the error data, it SHOULD first check that the
Content-Type header contains the appropriate media type. Content-Type header contains the appropriate media type.
This is an example of the common response body with and This is an example of the common response body with and
rdapConformance and notices data structures: rdapConformance and notices data structures:
{ {
skipping to change at page 46, line 42 skipping to change at page 48, line 42
"lang" : "en", "lang" : "en",
"errorCode": 418, "errorCode": 418,
"title": "Your beverage choice is not available", "title": "Your beverage choice is not available",
"description": "description":
[ [
"I know coffee has more ummppphhh.", "I know coffee has more ummppphhh.",
"Sorry, dude!" "Sorry, dude!"
] ]
} }
Figure 18 Figure 19
8. Responding to Help Queries 8. Responding to Help Queries
The appropriate response to /help queries as defined by The appropriate response to /help queries as defined by
[I-D.ietf-weirds-rdap-query] is to use the notices structure as [I-D.ietf-weirds-rdap-query] is to use the notices structure as
defined in Section 5.3. defined in Section 5.3.
This is an example of a response to a /help query including the This is an example of a response to a /help query including the
rdapConformance data structure. rdapConformance data structure.
skipping to change at page 47, line 34 skipping to change at page 49, line 34
"value" : "http://example.net/help", "value" : "http://example.net/help",
"rel" : "alternate", "rel" : "alternate",
"type" : "text/html", "type" : "text/html",
"href" : "http://www.example.com/auth_policy.html" "href" : "http://www.example.com/auth_policy.html"
} }
] ]
} }
] ]
} }
Figure 19 Figure 20
9. Responding To Searches 9. Responding To Searches
[I-D.ietf-weirds-rdap-query] specifies three types of searches: [I-D.ietf-weirds-rdap-query] specifies three types of searches:
domains, nameservers, and entities. Responses to these searches take domains, nameservers, and entities. Responses to these searches take
the form of an array of object instances where each instance is an the form of an array of object instances where each instance is an
appropriate object class for the search (i.e. a search for /domains appropriate object class for the search (i.e. a search for /domains
yields an array of domain object instances). These arrays are yields an array of domain object instances). These arrays are
contained within the response object. contained within the response object.
skipping to change at page 48, line 34 skipping to change at page 50, line 34
} }
] ]
} }
search_response_example search_response_example
10. Indicating Truncated Responses 10. Indicating Truncated Responses
In cases where the data of a response has been truncated (i.e. not In cases where the data of a response has been truncated (i.e. not
all of it has been included in the response), a server may indicate all of it has been included in the response), a server may indicate
this by including the boolean "resultsTruncated" in the response this by including a typed notice in the response object.
object. Whe this value is set to true, it indicates the data of the
response has been truncated. When this value is true, it is
recommended that servers include a textual description describing the
nature of the truncation in a notices structure.
The following is an elided example of a search response that has been The following is an elided example of a search response that has been
truncated. truncated.
{ {
"rdapConformance" : "rdapConformance" :
[ [
"rdap_level_0" "rdap_level_0"
], ],
"notices" : "notices" :
[ [
{ {
"title" : "Search Policy", "title" : "Search Policy",
"type" : "result set truncated due to authorization",
"description" : "description" :
[ [
"Search results are limited to 25 per day per querying IP." "Search results are limited to 25 per day per querying IP."
], ],
"links" : "links" :
[ [
{ {
"value" : "http://example.net/help", "value" : "http://example.net/help",
"rel" : "alternate", "rel" : "alternate",
"type" : "text/html", "type" : "text/html",
"href" : "http://www.example.com/search_policy.html" "href" : "http://www.example.com/search_policy.html"
} }
] ]
} }
], ],
"resultsTruncated" : true
"domainSearchResults" : "domainSearchResults" :
[ [
... ...
] ]
} }
search_response_truncated_example search_response_truncated_example
Note that "resultsTruncated" can be used where a single object has A similar technique can be used with a typed remark where a single
been returned and data in that object has been truncated. Such an object has been returned and data in that object has been truncated.
example might be an entity object with only a partial set of the IP Such an example might be an entity object with only a partial set of
networks associated with it. the IP networks associated with it.
The following is an elided example of an entity truncated data. The following is an elided example of an entity truncated data.
{ {
"objectClassName" : "entity",
"handle" : "ANENTITY", "handle" : "ANENTITY",
"roles" : [ "registrant" ], "roles" : [ "registrant" ],
... ...
"entities" : "entities" :
[ [
{ {
"objectClassName" : "entity",
"handle": "ANEMBEDDEDENTITY", "handle": "ANEMBEDDEDENTITY",
"roles" : [ "technical" ], "roles" : [ "technical" ],
... ...
}, },
... ...
], ],
"networks" : "networks" :
[ [
... ...
], ],
... ...
"resultsTruncated": true "remarks" :
[
{
"title" : "Data Policy",
"type" : "object truncated due to unexplainable reason",
"description" :
[
"Some of the data in this object has been removed."
],
"links" :
[
{
"value" : "http://example.net/help",
"rel" : "alternate",
"type" : "text/html",
"href" : "http://www.example.com/data_policy.html"
}
]
}
]
} }
Figure 20 Figure 21
11. IANA Considerations 11. IANA Considerations
11.1. RDAP JSON Media Type Registration 11.1. RDAP JSON Media Type Registration
This specification registers the "application/rdap+json" media type. This specification registers the "application/rdap+json" media type.
Type name: application Type name: application
Subtype name: rdap+json Subtype name: rdap+json
Required parameters: n/a Required parameters: n/a
Encoding considerations: See section 3.1 of [RFC6839]. Encoding considerations: See section 3.1 of [RFC6839].
Security considerations: The media represented by this identifier Security considerations: The media represented by this identifier
does not have security considerations beyond that found in section does not have security considerations beyond that found in section
6 of [RFC4627] 6 of [RFC7159]
Interoperability considerations: There are no known Interoperability considerations: There are no known
interoperability problems regarding this media format. interoperability problems regarding this media format.
Published specification: [[ this document ]] Published specification: [[ this document ]]
Applications that use this media type: Implementations of the Applications that use this media type: Implementations of the
Registration Data Access Protocol (RDAP) Registration Data Access Protocol (RDAP)
Additional information: This media type is a product of the IETF Additional information: This media type is a product of the IETF
skipping to change at page 51, line 32 skipping to change at page 54, line 8
Author: Andy Newton Author: Andy Newton
Change controller: IETF Change controller: IETF
Provisional Registration: No (upon publication of this RFC) Provisional Registration: No (upon publication of this RFC)
11.2. JSON Values Registry 11.2. JSON Values Registry
This section requests that the IANA establish an RDAP JSON Values This section requests that the IANA establish an RDAP JSON Values
Registry for use in the status (Section 5.6), role (Section 6.1), Registry for use in the notices and remarks (Section 5.3), status
event action (Section 5.5), and domain variant relation (Section 6.3) (Section 5.6), role (Section 6.1), event action (Section 5.5), and
fields specified in RDAP. domain variant relation (Section 6.3) fields specified in RDAP.
Each entry in the registry should contain the following fields: Each entry in the registry should contain the following fields:
1. Value - the string value being registered. 1. Value - the string value being registered.
2. Type - the type of value being registered. It should be one of 2. Type - the type of value being registered. It should be one of
the following: the following:
* 'notice or remark type' - denotes a type of notice or remark
* 'status' - denotes a value for the 'status' object member as * 'status' - denotes a value for the 'status' object member as
defined by Section 5.6. defined by Section 5.6.
* 'role' - denotes a value for the 'role' array as defined in * 'role' - denotes a value for the 'role' array as defined in
Section 6.1. Section 6.1.
* 'event action' - denotes a value for an event action as * 'event action' - denotes a value for an event action as
defined in Section 5.5. defined in Section 5.5.
* 'domain variant relation' - denotes a relationship between a * 'domain variant relation' - denotes a relationship between a
skipping to change at page 52, line 29 skipping to change at page 55, line 5
designated experts. Registration of values into this registry should designated experts. Registration of values into this registry should
be accomplished by providing the information above to the designated be accomplished by providing the information above to the designated
expert(s). expert(s).
Review of registrations into this registry by the designated Review of registrations into this registry by the designated
expert(s) should be narrowly judged on the following criteria: expert(s) should be narrowly judged on the following criteria:
1. Values in need of being placed into multiple types must be 1. Values in need of being placed into multiple types must be
assigned a separate registration for each type. assigned a separate registration for each type.
2. Values must be strings. They can be multiple words separated by 2. Values must be strings. They should be multiple words separated
single space characters. Every character should be lowercased. by single space characters. Every character should be
If possible, every word should be given in English and each lowercased. If possible, every word should be given in English
character should be US ASCII. and each character should be US ASCII.
3. Registrations should not duplicate the meaning of any existing 3. Registrations should not duplicate the meaning of any existing
registration. That is, if a request for a registration is registration. That is, if a request for a registration is
significantly similar in nature to an existing registration, the significantly similar in nature to an existing registration, the
request should be denied. For example, the terms 'maintainer' request should be denied. For example, the terms 'maintainer'
and 'registrant' are significantly similar in nature as they both and 'registrant' are significantly similar in nature as they both
denote a holder of a domain name or Internet number resource. In denote a holder of a domain name or Internet number resource. In
cases where it may be reasonably argued that machine cases where it may be reasonably argued that machine
interpretation of two similar values may alter the operation of interpretation of two similar values may alter the operation of
client software, designated experts should not judge the values client software, designated experts should not judge the values
to be of significant similarity. to be of significant similarity.
4. Registrations should be relevant to the common usages of RDAP. 4. Registrations should be relevant to the common usages of RDAP.
Designated experts may rely upon the serving of the value by a Designated experts may rely upon the serving of the value by a
DNR or RIR to make this determination. DNR or RIR to make this determination.
11.2.1. Status 11.2.1. Notice and Remark Types
This section registers the following values into the RDAP JSON Values
Registry:
1.
* Value: result set truncated due to authorization
* Type: notice and remark type
* Description: The list of results does not contain all results
due to lack of authorization. This may indicate to some
clients that proper authorization will yeild a longer result
set.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
2.
* Value: result set truncated due to excessive load
* Type: notice and remark type
* Description: The list of results does not contain all results
due to excessively heavy load on the server. This may
indicate to some clients that requerying at a later time will
yeild a longer result set.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
3.
* Value: result set truncated due to unexplainable reasons
* Type: notice and remark type
* Description: The list of results does not contain all results
for an unexplainable reason. This may indicate to some
clients that requerying for any reason will not yield a longer
result set.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
4.
* Value: object truncated due to authorization
* Type: notice and remark type
* Description: The object does not contain all data due to lack
of authorization. This may indicate to some clients that
proper authorization will yeild all data of the object.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
5.
* Value: object truncated due to excessive load
* Type: notice and remark type
* Description: The object does not contain all data due to
excessively heavy load on the server. This may indicate to
some clients that requerying at a later time will yeild all
data of the object.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
6.
* Value: object truncated due to unexplainable reasons
* Type: notice and remark type
* Description: The object does not contain all data for an
unexplainable reason. This may indicate to some clients that
requerying for any reason will not yield any more data.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
11.2.2. Status
This section registers the following values into the RDAP JSON Values This section registers the following values into the RDAP JSON Values
Registry: Registry:
1. 1.
* Value: validated * Value: validated
* Type: status * Type: status
skipping to change at page 58, line 19 skipping to change at page 62, line 36
* Description: A request has been received for the deletion or * Description: A request has been received for the deletion or
removal of the object instance but this action is not yet removal of the object instance but this action is not yet
complete. For domains, this might mean that the name in no complete. For domains, this might mean that the name in no
longer published in DNS but has not yet been purged from the longer published in DNS but has not yet been purged from the
registry database. registry database.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
11.2.2. Event Actions 11.2.3. Event Actions
This section registers the following values into the RDAP JSON Values This section registers the following values into the RDAP JSON Values
Registry: Registry:
1. 1.
* Value: registration * Value: registration
* Type: event action * Type: event action
skipping to change at page 60, line 36 skipping to change at page 65, line 4
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
9. 9.
* Value: unlocked * Value: unlocked
* Type: event action * Type: event action
* Description: The object instance was unlocked (see the * Description: The object instance was unlocked (see the
'locked' status). 'locked' status).
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
11.2.3. Roles 11.2.4. Roles
This section registers the following values into the RDAP JSON Values This section registers the following values into the RDAP JSON Values
Registry: Registry:
1. 1.
* Value: registrant * Value: registrant
* Type: role * Type: role
* Description: The entity object instance is the registrant of * Description: The entity object instance is the registrant of
the registration. In some registries, this is known as a the registration. In some registries, this is known as a
maintainer. maintainer.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
skipping to change at page 64, line 5 skipping to change at page 68, line 18
* Type: role * Type: role
* Description: The entity object instance handles * Description: The entity object instance handles
communications related to a network operations center (NOC). communications related to a network operations center (NOC).
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
11.2.4. Variant Relations 11.2.5. Variant Relations
This section registers the following values into the RDAP JSON Values This section registers the following values into the RDAP JSON Values
Registry: Registry:
1. 1.
* Value: registered * Value: registered
* Type: domain variant relation * Type: domain variant relation
skipping to change at page 65, line 29 skipping to change at page 69, line 42
registration. registration.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
12. Security Considerations 12. Security Considerations
This specification models information serialized in JSON format. As This specification models information serialized in JSON format. As
JSON is a subset of Javascript, implementations are advised to follow JSON is a subset of Javascript, implementations are advised to follow
the security considerations outlined in Section 6 of [RFC4627] to the security considerations outlined in Section 6 of [RFC7159] to
prevent code injection. prevent code injection.
13. Internationalization Considerations 13. Internationalization Considerations
13.1. Character Encoding 13.1. Character Encoding
The default text encoding for JSON and XML responses in RDAP is UTF-8 The default text encoding for JSON and XML responses in RDAP is UTF-8
[RFC3629], and all servers and clients MUST support UTF-8. Servers [RFC3629], and all servers and clients MUST support UTF-8. Servers
and clients MAY optionally support other character encodings. and clients MAY optionally support other character encodings.
skipping to change at page 66, line 11 skipping to change at page 70, line 21
Section 5.4 defines the use of language tags in the JSON responses Section 5.4 defines the use of language tags in the JSON responses
defined in this document. defined in this document.
13.4. Internationalized Domain Names 13.4. Internationalized Domain Names
Internationalized Domain Names (IDNs) are denoted in this Internationalized Domain Names (IDNs) are denoted in this
specification by the separation of DNS names in LDH form and Unicode specification by the separation of DNS names in LDH form and Unicode
form (see Section 4). Representation of IDNs in registries is form (see Section 4). Representation of IDNs in registries is
described by the "variants" object in Section 6.3 and the suggested described by the "variants" object in Section 6.3 and the suggested
values listed in Section 11.2.4. values listed in Section 11.2.5.
14. Privacy Considerations 14. Privacy Considerations
This specification suggests status values to denote contact and This specification suggests status values to denote contact and
registrant information that has been marked as private and/or has registrant information that has been marked as private and/or has
been redacted or obscured. See Section 11.2.1 for the list of status been redacted or obscured. See Section 11.2.2 for the list of status
values. See Appendix A.1 on guidance to apply those values to values. See Appendix A.1 on guidance to apply those values to
contacts and registrants. contacts and registrants.
15. Contributing Authors and Acknowledgements 15. Contributing Authors and Acknowledgements
This document is derived from original work on RIR responses in JSON This document is derived from original work on RIR responses in JSON
by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew L. by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew
Newton. Additionally, this document incorporates word on DNR L. Newton. Additionally, this document incorporates word on DNR
responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean
Shen. Shen.
The components of the DNR object classes are derived from a The components of the DNR object classes are derived from a
categorization of WHOIS response formats created by Ning Kong, Linlin categorization of WHOIS response formats created by Ning Kong, Linlin
Zhou, and Guangqing Deng, Steve Sheng and Francisco Arias, Ray Zhou, and Guangqing Deng, Steve Sheng and Francisco Arias, Ray
Bellis, and Frederico Neves. Bellis, and Frederico Neves.
Ed Lewis contributed significant review comments and provided Ed Lewis contributed significant review comments and provided
clarifying text. James Mitchell provided text regarding the clarifying text. James Mitchell provided text regarding the
skipping to change at page 67, line 9 skipping to change at page 71, line 14
many other attributes that appear throughout the object classes of many other attributes that appear throughout the object classes of
this draft. this draft.
The switch to and incorporation of JSON vCard was performed by Simon The switch to and incorporation of JSON vCard was performed by Simon
Perreault. Perreault.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet
numbers", RFC 1166, July 1990. numbers", RFC 1166, July 1990.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4343] Eastlake, D., "Domain Name System (DNS) Case Insensitivity
Clarification", RFC 4343, January 2006.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
Autonomous System (AS) Numbers", RFC 5396, December 2008. Autonomous System (AS) Numbers", RFC 5396, December 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[I-D.ietf-jcardcal-jcard] [I-D.ietf-jcardcal-jcard]
Kewisch, P., "jCard: The JSON format for vCard", draft- Kewisch, P., "jCard: The JSON format for vCard", draft-
ietf-jcardcal-jcard-07 (work in progress), October 2013. ietf-jcardcal-jcard-07 (work in progress), October 2013.
[I-D.ietf-weirds-using-http] [I-D.ietf-weirds-using-http]
Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the
Registration Data Access Protocol (RDAP)", draft-ietf- Registration Data Access Protocol (RDAP)", draft-ietf-
weirds-using-http-08 (work in progress), February 2014. weirds-using-http-09 (work in progress), August 2014.
[I-D.ietf-weirds-rdap-query] [I-D.ietf-weirds-rdap-query]
Newton, A. and S. Hollenbeck, "Registration Data Access Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol Query Format", draft-ietf-weirds-rdap-query-10 Protocol Query Format", draft-ietf-weirds-rdap-query-11
(work in progress), February 2014. (work in progress), July 2014.
[ISO.3166.1988] [ISO.3166.1988]
International Organization for Standardization, "Codes for International Organization for Standardization, "Codes for
the representation of names of countries, 3rd edition", the representation of names of countries, 3rd edition",
ISO Standard 3166, August 1988. ISO Standard 3166, August 1988.
16.2. Informative References 16.2. Informative References
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
September 2004. September 2004.
skipping to change at page 69, line 21 skipping to change at page 73, line 14
Appendix A. Suggested Data Modeling with the Entity Object Class Appendix A. Suggested Data Modeling with the Entity Object Class
A.1. Registrants and Contacts A.1. Registrants and Contacts
This document does not provide specific object classes for This document does not provide specific object classes for
registrants and contacts. Instead the entity object class may be registrants and contacts. Instead the entity object class may be
used to represent a registrant or contact. When the entity object is used to represent a registrant or contact. When the entity object is
embedded inside a containing object such as a domain name or IP embedded inside a containing object such as a domain name or IP
network, the 'roles' string array can be used to signify the network, the 'roles' string array can be used to signify the
relationship. It is recommended that the values from Section 11.2.3 relationship. It is recommended that the values from Section 11.2.4
be used. be used.
The following is an example of an elided containing object with an The following is an example of an elided containing object with an
embedded entity that is both a registrant and administrative contact: embedded entity that is both a registrant and administrative contact:
{ {
... ...
"entities" : "entities" :
[ [
{ {
"objectClassName" : "entity",
"handle" : "XXXX", "handle" : "XXXX",
"vcardArray":[ "vcardArray":[
"vcard", "vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"], ["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"], ["kind", {}, "text", "individual"],
["lang", { ["lang", {
"pref":"1" "pref":"1"
}, "language-tag", "fr"], }, "language-tag", "fr"],
skipping to change at page 71, line 4 skipping to change at page 74, line 44
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
}, },
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:60Z" "eventDate" : "1991-12-31T23:59:60Z"
} }
] ]
} }
] ]
} }
In many use cases, it is necessary to hide or obscure the information In many use cases, it is necessary to hide or obscure the information
of a registrant or contact due to policy or other operational of a registrant or contact due to policy or other operational
matters. Registries can denote these situations with 'status' values matters. Registries can denote these situations with 'status' values
(see Section 11.2.1). (see Section 11.2.2).
The following is an elided example of a registrant with information The following is an elided example of a registrant with information
changed to reflect that of a third party. changed to reflect that of a third party.
{ {
... ...
"entities" : "entities" :
[ [
{ {
"objectClassName" : "entity",
"handle" : "XXXX", "handle" : "XXXX",
... ...
"roles" : [ "registrant", "administrative" ], "roles" : [ "registrant", "administrative" ],
"status" : [ "proxy", "private", "obscured" ] "status" : [ "proxy", "private", "obscured" ]
} }
] ]
} }
A.2. Registrars A.2. Registrars
skipping to change at page 71, line 40 skipping to change at page 75, line 37
publicly assigned identifiers. The 'publicIds' structure publicly assigned identifiers. The 'publicIds' structure
(Section 5.8) represents that information. (Section 5.8) represents that information.
The following is an example of an elided containing object with an The following is an example of an elided containing object with an
embedded entity that is a registrar: embedded entity that is a registrar:
{ {
... ...
"entities":[ "entities":[
{ {
"objectClassName" : "entity",
"handle":"XXXX", "handle":"XXXX",
"vcardArray":[ "vcardArray":[
"vcard", "vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe's Fish, Chips and Domains"], ["fn", {}, "text", "Joe's Fish, Chips and Domains"],
["kind", {}, "text", "org"], ["kind", {}, "text", "org"],
["lang", { ["lang", {
"pref":"1" "pref":"1"
}, "language-tag", "fr"], }, "language-tag", "fr"],
["lang", { ["lang", {
"pref":"2" "pref":"2"
}, "language-tag", "en"], }, "language-tag", "en"],
["org", { ["org", {
"type":"work" "type":"work"
}, "text", "Example"], }, "text", "Example"],
["adr", ["adr",
{ "type":"work" }, { "type":"work" },
"text", "text",
[ [
"", "",
"Suite 1234", "Suite 1234",
skipping to change at page 73, line 45 skipping to change at page 77, line 42
This is an example of an "events" array without the 'eventActor'. This is an example of an "events" array without the 'eventActor'.
"events" : "events" :
[ [
{ {
"eventAction" : "registration", "eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
} }
] ]
Figure 21 Figure 22
For the second use case, the 'events' data structure (Section 5.5) is For the second use case, the 'events' data structure (Section 5.5) is
used with the 'eventActor' object member. used with the 'eventActor' object member.
This is an example of an "events" array with the 'eventActor'. This is an example of an "events" array with the 'eventActor'.
"events" : "events" :
[ [
{ {
"eventAction" : "registration", "eventAction" : "registration",
"eventActor" : "XYZ-NIC", "eventActor" : "XYZ-NIC",
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
} }
] ]
Figure 22 Figure 23
For the third use case, the 'asEventActor' array is used when an For the third use case, the 'asEventActor' array is used when an
entity (Section 6.1) is embedded into another object class. The entity (Section 6.1) is embedded into another object class. The
'asEventActor' array follows the same structure as the 'events' array 'asEventActor' array follows the same structure as the 'events' array
but does not have 'eventActor' attributes. but does not have 'eventActor' attributes.
The following is an elided example of a domain object with an entity The following is an elided example of a domain object with an entity
as an event actor. as an event actor.
{ {
"objectClassName" : "domain",
"handle" : "XXXX", "handle" : "XXXX",
"ldhName" : "foo.example", "ldhName" : "foo.example",
"status" : [ "locked", "transfer Prohibited" ], "status" : [ "locked", "transfer Prohibited" ],
... ...
"entities" : "entities" :
[ [
{ {
"handle" : "XXXX", "handle" : "XXXX",
... ...
"asEventActor" : "asEventActor" :
skipping to change at page 76, line 48 skipping to change at page 80, line 48
"uri", "http://www.example.com/joe.user/joe.asc" "uri", "http://www.example.com/joe.user/joe.asc"
], ],
["tz", {}, ["tz", {},
"utc-offset", "-05:00"], "utc-offset", "-05:00"],
["url", { "type":"home" }, ["url", { "type":"home" },
"uri", "http://example.org"] "uri", "http://example.org"]
] ]
] ]
} }
Figure 23 Figure 24
The arrays in Figure 23 with the first member of "adr" represent The arrays in Figure 24 with the first member of "adr" represent
postal addresses. In the first example, the postal address is given postal addresses. In the first example, the postal address is given
as a an array of strings and constitutes a structured address. For as a an array of strings and constitutes a structured address. For
components of the structured address that are not applicable, an components of the structured address that are not applicable, an
empty string is given. Each member of that array aligns with the empty string is given. Each member of that array aligns with the
positions of a vCard as given in [RFC6350]. In this example, the positions of a vCard as given in [RFC6350]. In this example, the
following data corresponds to the following positional meanings: following data corresponds to the following positional meanings:
1. post office box - not applicable, empty string 1. post office box - not applicable, empty string
2. extended address (e.g., apartment or suite number) - Suite 1234 2. extended address (e.g., apartment or suite number) - Suite 1234
skipping to change at page 83, line 30 skipping to change at page 87, line 30
'nameServers' as in the example (note the camel case) 'nameServers' as in the example (note the camel case)
fixed some example per email from James Mitchel fixed some example per email from James Mitchel
fixed an example per email from Simon Perreault fixed an example per email from Simon Perreault
Added "network" to domain object class. Added "network" to domain object class.
Added networks and autnums to the entity object class. Added networks and autnums to the entity object class.
Authors' Addresses Created a section for "resultsTruncated".
-08
Added typed remarks and notices, removed "resultTruncated" in
favor of them.
Added "objectClassName".
Changed JSON reference to RFC 7159.
Removed unused references to RFC 0791, RFC 2616, RFC 4343, RFC
5322.
Authors' Addresses
Andrew Lee Newton Andrew Lee Newton
American Registry for Internet Numbers American Registry for Internet Numbers
3635 Concorde Parkway 3635 Concorde Parkway
Chantilly, VA 20151 Chantilly, VA 20151
US US
Email: andy@arin.net Email: andy@arin.net
URI: http://www.arin.net URI: http://www.arin.net
Scott Hollenbeck Scott Hollenbeck
 End of changes. 117 change blocks. 
155 lines changed or deleted 357 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/