draft-ietf-weirds-json-response-04.txt   draft-ietf-weirds-json-response-05.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: December 14, 2013 Verisign Labs Expires: February 16, 2014 Verisign Labs
June 12, 2013 August 15, 2013
JSON Responses for the Registration Data Access Protocol (RDAP) JSON Responses for the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-json-response-04 draft-ietf-weirds-json-response-05
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 December 14, 2013. This Internet-Draft will expire on February 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 6 4. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 6
5. Common Data Structures . . . . . . . . . . . . . . . . . . . 7 5. Common Data Structures . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.6. Status . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.6. Status . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.7. Port 43 Whois Server . . . . . . . . . . . . . . . . . . 12 5.7. Port 43 Whois Server . . . . . . . . . . . . . . . . . . 12
5.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 12 5.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 13
5.9. An Example . . . . . . . . . . . . . . . . . . . . . . . 13 5.9. An Example . . . . . . . . . . . . . . . . . . . . . . . 13
6. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 14 6. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. The Entity Object Class . . . . . . . . . . . . . . . . . 14 6.1. The Entity Object Class . . . . . . . . . . . . . . . . . 15
6.2. The Nameserver Object Class . . . . . . . . . . . . . . . 20 6.2. The Nameserver Object Class . . . . . . . . . . . . . . . 21
6.3. The Domain Object Class . . . . . . . . . . . . . . . . . 23 6.3. The Domain Object Class . . . . . . . . . . . . . . . . . 25
6.4. The IP Network Object Class . . . . . . . . . . . . . . . 35 6.4. The IP Network Object Class . . . . . . . . . . . . . . . 37
6.5. Autonomous System Number Entity Object Class . . . . . . 39 6.5. Autonomous System Number Entity Object Class . . . . . . 41
7. Error Response Body . . . . . . . . . . . . . . . . . . . . . 42 7. Error Response Body . . . . . . . . . . . . . . . . . . . . . 44
8. Responding to Help Queries . . . . . . . . . . . . . . . . . 43 8. Responding to Help Queries . . . . . . . . . . . . . . . . . 46
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 9. Responding To Searches . . . . . . . . . . . . . . . . . . . 47
9.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 46 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
9.2. Event Actions . . . . . . . . . . . . . . . . . . . . . . 48 10.1. RDAP JSON Media Type Registration . . . . . . . . . . . 49
9.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 50 10.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 50
9.4. Variant Relations . . . . . . . . . . . . . . . . . . . . 53 10.2.1. Status . . . . . . . . . . . . . . . . . . . . . . . 52
10. Security Considerations . . . . . . . . . . . . . . . . . . . 54 10.2.2. Event Actions . . . . . . . . . . . . . . . . . . . 57
11. Internationalization Considerations . . . . . . . . . . . . . 54 10.2.3. Roles . . . . . . . . . . . . . . . . . . . . . . . 60
11.1. Character Encoding . . . . . . . . . . . . . . . . . . . 54 10.2.4. Variant Relations . . . . . . . . . . . . . . . . . 63
11.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 54 11. Security Considerations . . . . . . . . . . . . . . . . . . . 64
11.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 55 12. Internationalization Considerations . . . . . . . . . . . . . 64
11.4. Internationalized Domain Names . . . . . . . . . . . . . 55 12.1. Character Encoding . . . . . . . . . . . . . . . . . . . 64
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 55 12.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 64
13. Contributing Authors and Acknowledgements . . . . . . . . . . 55 12.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 65
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 12.4. Internationalized Domain Names . . . . . . . . . . . . . 65
14.1. Normative References . . . . . . . . . . . . . . . . . . 56 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 65
14.2. Informative References . . . . . . . . . . . . . . . . . 57 14. Contributing Authors and Acknowledgements . . . . . . . . . . 65
Appendix A. Suggested Data Modeling with the Entity Object Class 58 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 58 15.1. Normative References . . . . . . . . . . . . . . . . . . 66
A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 60 15.2. Informative References . . . . . . . . . . . . . . . . . 67
Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 62 Appendix A. Suggested Data Modeling with the Entity Object Class 68
Appendix C. Structured vs Unstructured Addresses . . . . . . . . 64 A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 68
Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 66 A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 70
Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 67 Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 72
Appendix F. Changelog . . . . . . . . . . . . . . . . . . . . . 67 Appendix C. Structured vs Unstructured Addresses . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 76
Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 77
Appendix F. Changelog . . . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
This document describes responses in the JSON [RFC4627] format for This document describes responses in the JSON [RFC4627] 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
skipping to change at page 7, line 44 skipping to change at page 7, line 44
more of the labels are U-labels as described by more of the labels are U-labels as described by
[RFC5890]. Trailing periods are optional. [RFC5890]. Trailing periods are optional.
dates and times: The syntax for values denoting dates and times is dates and times: The syntax for values denoting dates and times is
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.kewisch-vcard-in-json] [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 object
classes. 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
skipping to change at page 9, line 31 skipping to change at page 9, line 31
JSON values are optional. JSON values are optional.
This is an example of the "links" array as it might be found in an This is an example of the "links" array as it might be found in an
object class: object 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"
}, },
{ {
"value" : "http://example.com/ip/2001:db8::123", "value" : "http://example.com/ip/2001:db8::123",
"rel" : "up", "rel" : "up",
"href" : "http://example.com/ip/2001:db8::/48" "href" : "http://example.com/ip/2001:db8::/48",
"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, whereas the "remarks" structure denotes information
about the object class it is contained within (see Section 6 about the object class it is contained within (see Section 6
skipping to change at page 12, line 4 skipping to change at page 12, line 25
"eventDate" : "1991-12-31T23:59:60Z" "eventDate" : "1991-12-31T23:59:60Z"
} }
] ]
Figure 9 Figure 9
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
occurred. occurred.
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.
See Section 9.2 for a list of values for the 'eventAction' string. The 'links' array in this data structure is provided for references
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
"type" of "application/rdap+json".
See Section 10.2.2 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 9.1 for a indicating the state of a registered object (see Section 10.2.1 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
This data structure maps a public identifier to an object class. It This data structure maps a public identifier to an object class. It
is named 'publicIds' and is an array of objects, with each object is named 'publicIds' and is an array of objects, with each object
containing the following members: containing the following members:
skipping to change at page 14, line 4 skipping to change at page 14, line 48
[ [
{ {
"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 11
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 in a response, whether the Section 5.2. For every object class instance in a response, whether
object class is directly representing the response to a query or is the object class instance is directly representing the response to a
embedded in other object classes, servers SHOULD provide a link query or is embedded in other object class instances, servers SHOULD
representing a URI for that object class using the "self" provide a link representing a URI for that object class instance
relationship as specified in the IANA registry specified by using the "self" relationship as specified in the IANA registry
[RFC5988]. As explained in Section 6.2, this may be not always be specified by [RFC5988]. As explained in Section 6.2, this may be not
possible for name server data. Clients MUST be able to process always be possible for name server data. Clients MUST be able to
object instances without a "self" link. When present, clients MAY process object instances without a "self" link. When present,
use the self link for caching data. Servers MAY provide more than clients MAY use the self link for caching data. Servers MAY provide
one "self" link for any given object instance. more than one "self" link for any given object instance.
Self links SHOULD contain a "type" element containing the
"application/rdap+json" media type when referencing RDAP object
instances as defined by this document. Clients SHOULD NOT assume
self links without this media type are represented as RDAP objects as
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"
} }
] ]
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,
skipping to change at page 17, line 4 skipping to change at page 18, line 9
"identifier":"1" "identifier":"1"
} }
], ],
"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."
] ]
} }
], ],
"links":[ "links":[
{ {
"value":"http://example.com/entity/XXXX", "value":"http://example.com/entity/XXXX",
"rel":"self", "rel":"self",
"href":"http://example.com/entity/XXXX" "href":"http://example.com/entity/XXXX",
"type" : "application/rdap+json"
} }
], ],
"events":[ "events":[
{ {
"eventAction":"registration", "eventAction":"registration",
"eventDate":"1990-12-31T23:59:60Z" "eventDate":"1990-12-31T23:59:60Z"
} }
], ],
"asEventActor":[ "asEventActor":[
{ {
skipping to change at page 18, line 15 skipping to change at page 19, line 32
This object has the following members: This object has the following members:
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 9.3 for a list of values) Section 10.2.3 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 19, line 50 skipping to change at page 21, line 19
"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."
] ]
} }
], ],
"links":[ "links":[
{ {
"value":"http://example.com/entity/XXXX", "value":"http://example.com/entity/XXXX",
"rel":"self", "rel":"self",
"href":"http://example.com/entity/XXXX" "href":"http://example.com/entity/XXXX",
"type":"application/rdap+json"
} }
], ],
"port43":"whois.example.net", "port43":"whois.example.net",
"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",
"eventActor":"joe@example.com" "eventActor":"joe@example.com"
} }
] ]
} }
See Appendix A for use of the entity object class to model various
types of entities found in both RIRs and DNRs. See Appendix C
regarding structured vs. unstructured postal addresses in entities.
6.2. The Nameserver Object Class 6.2. The Nameserver Object Class
The nameserver object class represents information regarding DNS name The nameserver object class represents information regarding DNS name
servers used in both forward and reverse DNS. RIRs and some DNRs servers used in both forward and reverse DNS. RIRs and some DNRs
register or expose nameserver information as an attribute of a domain register or expose nameserver information as an attribute of a domain
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.
skipping to change at page 21, line 30 skipping to change at page 23, line 30
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value" : "http://example.net/nameserver/xxxx", "value" : "http://example.net/nameserver/xxxx",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/nameserver/xxxx" "href" : "http://example.net/nameserver/xxxx",
"type" : "application/rdap+json"
} }
], ],
"port43" : "whois.example.net", "port43" : "whois.example.net",
"events" : "events" :
[ [
{ {
"eventAction" : "registration", "eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
}, },
{ {
skipping to change at page 25, line 7 skipping to change at page 27, line 7
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 9.4 for a list of suggested variant object (see Section 10.2.4 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 [1]). 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
Section 6.2 Section 6.2
o secureDNS -- an object with the following members: o secureDNS -- an object with the following members:
skipping to change at page 25, line 51 skipping to change at page 27, line 51
+ digest -- a string as specified by the digest field of a DNS + digest -- a string as specified by the digest field of a DNS
DS record as specified by RFC 4034 in presentation format DS record as specified by RFC 4034 in presentation format
+ digestType -- an integer as specified by the digest type + digestType -- an integer as specified by the digest type
field of a DNS DS record as specified by RFC 4034 in field of a DNS DS record as specified by RFC 4034 in
presentation format presentation format
+ events - see Section 5.5 + events - see Section 5.5
+ links - see Section 5.2
* keyData - an array of objects, each with the following members: * keyData - an array of objects, each with the following members:
+ flags -- a string representing the flags field value in the + flags -- an integer representing the flags field value in
DNSKEY record [RFC4034] in presentation format. the DNSKEY record [RFC4034] in presentation format.
+ protocol - a string representation of the protocol field + protocol - an integer representation of the protocol field
value of the DNSKEY record [RFC4034] in presentation format. value of the DNSKEY record [RFC4034] in presentation format.
+ publicKey - a string representation of the public key in the + publicKey - a string representation of the public key in the
DNSKEY record [RFC4034] in presentation format. DNSKEY record [RFC4034] in presentation format.
+ algorithm -- an integer as specified by the algorithm field + algorithm -- an integer as specified by the algorithm field
of a DNSKEY record as specified by RFC 4034 [RFC4034] in of a DNSKEY record as specified by RFC 4034 [RFC4034] in
presentation format presentation format
+ events - see Section 5.5 + events - see Section 5.5
+ links - see Section 5.2
See Appendix D for background information on these objects. See Appendix D for background information on these objects.
o entities -- an array of entity objects as defined by Section 6.1. o entities -- an array of entity objects as defined by Section 6.1.
o status - see Section 5.6 o status - see Section 5.6
o publicIds - see Section 5.8 o publicIds - see Section 5.8
o remarks - see Section 5.3 o remarks - see Section 5.3
skipping to change at page 27, line 29 skipping to change at page 29, line 34
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value": "http://example.net/domain/XXXX", "value": "http://example.net/domain/XXXX",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/domain/XXXXX" "href" : "http://example.net/domain/XXXXX",
"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",
skipping to change at page 29, line 4 skipping to change at page 31, line 9
[ [
{ {
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value": "http://example.net/entity/xxxx", "value": "http://example.net/entity/xxxx",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/entity/xxxx" "href" : "http://example.net/entity/xxxx",
"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",
skipping to change at page 30, line 20 skipping to change at page 32, line 25
"idnTable": ".EXAMPLE Swedish", "idnTable": ".EXAMPLE Swedish",
"variantNames" : "variantNames" :
[ [
{ {
"ldhName": "xn--fo-8ja.example", "ldhName": "xn--fo-8ja.example",
"unicodeName" : "foo.example" "unicodeName" : "foo.example"
} }
] ]
} }
], ],
"status" : [ "locked", "transferProhibited" ], "status" : [ "locked", "transfer prohibited" ],
"publicIds":[ "publicIds":[
{ {
"type":"ENS_Auth ID", "type":"ENS_Auth ID",
"identifier":"1234567890" "identifier":"1234567890"
} }
], ],
"nameServers" : "nameServers" :
[ [
{ {
"handle" : "XXXX", "handle" : "XXXX",
skipping to change at page 30, line 47 skipping to change at page 33, line 4
}, },
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value" : "http://example.net/nameserver/XXXX", "value" : "http://example.net/nameserver/XXXX",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/nameserver/XXXX" "href" : "http://example.net/nameserver/XXXX",
"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",
skipping to change at page 31, line 43 skipping to change at page 33, line 51
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value" : "http://example.net/nameserver/XXXX", "value" : "http://example.net/nameserver/XXXX",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/nameserver/XXXX" "href" : "http://example.net/nameserver/XXXX",
"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"
} }
] ]
} }
], ],
"secureDNS": "secureDNS":
[ {
"zoneSigned": true, "zoneSigned": true,
"delegationSigned": true, "delegationSigned": true,
"maxSigLife": 604800, "maxSigLife": 604800,
"keyData": "keyData":
[ [
{ {
"flags": 257, "flags": 257,
"protocol": 3, "protocol": 3,
"algorithm": 1, "algorithm": 1,
"publicKey": "AQPJ////4Q==", "publicKey": "AQPJ////4Q==",
"events": "events":
[ [
{ {
"eventAction": "last changed", "eventAction": "last changed",
"eventDate": "2012-07-23T05:15:47Z" "eventDate": "2012-07-23T05:15:47Z"
} }
] ]
} }
] ]
], },
"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."
] ]
} }
], ],
skipping to change at page 32, line 44 skipping to change at page 35, line 4
[ [
{ {
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value": "http://example.net/domain/XXXX", "value": "http://example.net/domain/XXXX",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/domain/XXXX" "href" : "http://example.net/domain/XXXX",
"type" : "application/rdap+json"
} }
], ],
"port43" : "whois.example.net", "port43" : "whois.example.net",
"events" : "events" :
[ [
{ {
"eventAction" : "registration", "eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
}, },
{ {
skipping to change at page 34, line 39 skipping to change at page 36, line 48
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value" : "http://example.net/entity/xxxx", "value" : "http://example.net/entity/xxxx",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/entity/xxxx" "href" : "http://example.net/entity/xxxx",
"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",
skipping to change at page 36, line 19 skipping to change at page 38, line 28
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value" : "http://example.ent/ip/2001:db8::/48", "value" : "http://example.ent/ip/2001:db8::/48",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/ip/2001:db8::/48" "href" : "http://example.net/ip/2001:db8::/48",
"type" : "application/rdap+json"
}, },
{ {
"value" : "http://example.net/ip/2001:db8::/48", "value" : "http://example.net/ip/2001:db8::/48",
"rel" : "up", "rel" : "up",
"href" : "http://example.net/ip/2001:C00::/23" "href" : "http://example.net/ip/2001:C00::/23",
"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",
skipping to change at page 37, line 50 skipping to change at page 40, line 13
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value" : "http://example.net/entity/xxxx", "value" : "http://example.net/entity/xxxx",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/entity/xxxx" "href" : "http://example.net/entity/xxxx",
"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",
skipping to change at page 39, line 9 skipping to change at page 41, line 23
o status -- an array of strings indicating the state of the IP o status -- an array of strings indicating the state of the IP
network network
o entities -- an array of entity objects as defined by Section 6.1. o entities -- an array of entity objects as defined by Section 6.1.
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 port43 - see Section 5.7
o events - see Section 5.5 o events - see Section 5.5
6.5. Autonomous System Number Entity Object Class 6.5. Autonomous System Number Entity Object Class
The Autonomous System Number (autnum) object class models Autonomous The Autonomous System Number (autnum) object class models Autonomous
System Number registrations found in RIRs and represents the expected System Number registrations found in RIRs and represents the expected
response to an "/autnum" query as defined by response to an "/autnum" query as defined by
[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 autnum object class for DNRs. The high level structure of the autnum object class
consists of information about the network registration and entities consists of information about the network registration and entities
skipping to change at page 39, line 50 skipping to change at page 42, line 19
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value" : "http://example.net/autnum/xxxx", "value" : "http://example.net/autnum/xxxx",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/autnum/xxxx" "href" : "http://example.net/autnum/xxxx",
"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"
skipping to change at page 41, line 28 skipping to change at page 43, line 46
"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."
] ]
} }
], ],
"links" : "links" :
[ [
{ {
"value" : "http://example.net/entity/XXXX", "value" : "http://example.net/entity/XXXX",
"rel" : "self", "rel" : "self",
"href" : "http://example.net/entity/XXXX" "href" : "http://example.net/entity/XXXX",
"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",
skipping to change at page 42, line 22 skipping to change at page 44, line 38
registration holder registration holder
o type -- a string containing an RIR-specific classification of the o type -- a string containing an RIR-specific classification of the
autnum autnum
o status -- an array of strings indicating the state of the autnum o status -- an array of strings indicating the state of the autnum
o country -- a string containing the name of the 2 character country o country -- a string containing the name of the 2 character country
code of the autnum code of the autnum
o entities -- an array of entity objects as defined by Section 6.1.
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 port43 - see Section 5.7
o events - see Section 5.5 o events - see Section 5.5
7. Error Response Body 7. Error Response Body
Some non-answer responses may return entity bodies with information Some non-answer responses may return entity bodies with information
that could be more descriptive. that could be more descriptive.
The basic structure of that response is an object class containing an The basic structure of that response is an object class containing an
error code number (corresponding to the HTTP response code) followed error code number (corresponding to the HTTP response code) followed
by a string named "title" followed by an array of strings named by a string named "title" followed by an array of strings named
"description". "description".
This is an example of the common response body. For illustrative This is an example of the common response body. For illustrative
purposes, it does not include rdapConformance or notices data purposes, it does not include rdapConformance or notices data
skipping to change at page 44, line 39 skipping to change at page 47, line 33
"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 19
9. IANA Considerations 9. Responding To Searches
[I-D.ietf-weirds-rdap-query] specifies three types of searches:
domains, nameservers, and entities. Responses to these searches take
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
yields an array of domain object instances). These arrays are
contained within the response object.
The names of the arrays are as follows:
o for /domains searches, the array is "domains"
o for /nameservers searches, the array is "nameservers"
o for /entities searches, the array is "entities"
The following is an elided example of a response to a /domains
search.
{
"rdapConformance" :
[
"rdap_level_0"
],
...
"domains" :
[
{
"handle" : "1-XXXX",
"name" : "1.example.com",
...
},
{
"handle" : "2-XXXX",
"name" : "2.example.com",
...
}
]
}
search_response_example
In addition to the arrays, the response object may contain a member
named "searchResultsTruncated" which is a boolean. When this value
is set to true, it indicates the accompanying array did not contain
all of the data that matched the search criteria. When this value is
true, it is recommended that servers include a textual description
for the truncation in a notices structure.
The following is an elided example of a search response that has been
truncated.
{
"rdapConformance" :
[
"rdap_level_0"
],
"notices" :
[
{
"title" : "Search Policy",
"description" :
[
"Search results are limited to 25 per day per querying IP."
],
"links" :
[
{
"value" : "http://example.net/help",
"rel" : "alternate",
"type" : "text/html",
"href" : "http://www.example.com/search_policy.html"
}
]
}
],
"searchResultsTruncated" : true
"domains" :
[
...
]
}
search_response_truncated_example
10. IANA Considerations
10.1. RDAP JSON Media Type Registration
This specification registers the "application/rdap+json" media type.
Type name: application
Subtype name: rdap+json
Required parameters: n/a
Encoding considerations: See section 3.1 of [RFC6839].
Security considerations: The media represented by this identifier
does not have security considerations beyond that found in section
6 of [RFC4627]
Interoperability considerations: There are no known
interoperability problems regarding this media format.
Published specification: [[ this document ]]
Applications that use this media type: Implementations of the
Registration Data Access Protocol (RDAP)
Additional information: This media type is a product of the IETF
WEIRDS working group. The WEIRDS charter, information on the
WEIRDS mailing list, and other documents produced by the WEIRDS
working group can be found at https://datatracker.ietf.org/wg/
weirds/ [1]
Person & email address to contact for further information: Andy
Newton <andy@hxr.us>
Intended usage: COMMON
Restrictions on usage: none
Author: Andy Newton
Change controller: IETF
Provisional Registration: No (upon publication of this RFC)
10.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 status (Section 5.6), role (Section 6.1),
event action (Section 5.5), and domain variant relation (Section 6.3) event action (Section 5.5), and domain variant relation (Section 6.3)
fields specified in RDAP. 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.
skipping to change at page 46, line 9 skipping to change at page 52, line 9
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.
9.1. Status 10.2.1. 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
* Description: Signifies that the data of the object instance * Description: Signifies that the data of the object instance
has been found to be accurate. This type of status is usually has been found to be accurate. This type of status is
found on entity object instances to note the validity of usually found on entity object instances to note the validity
identifying contact information. of identifying contact information.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
2. 2.
* Value: update prohibited * Value: renew prohibited
* Type: status * Type: status
* Description: Updates to the object instance are forbidden. * Description: Renewal or reregistration of the object instance
is forbidden.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
3. 3.
* Value: transfer prohibited * Value: update prohibited
* Type: status * Type: status
* Description: Transfers of the registration from one registrar * Description: Updates to the object instance are forbidden.
to another are forbidden. This type of status normally
applies to DNR domain names.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
* Registrant Contact Information: andy@hxr.us
4. 4.
* Value: delete prohibited * Value: transfer prohibited
* Type: status * Type: status
* Description: Deletion of the registration of the object * Description: Transfers of the registration from one registrar
instance is forbidden. This type of status normally applies to another are forbidden. This type of status normally
to DNR domain names. applies to DNR domain names.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
5. 5.
* Value: proxy * Value: delete prohibited
* Type: status * Type: status
* Description: The registration of the object instance has been * Description: Deletion of the registration of the object
performed by a third party. This is most commonly applied to instance is forbidden. This type of status normally applies
entities. to DNR domain names.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
6. 6.
* Value: private * Value: proxy
* Type: status * Type: status
* Description: The information of the object instance is not * Description: The registration of the object instance has been
designated for public consumption. This is most commonly performed by a third party. This is most commonly applied to
applied to entities. entities.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
7. 7.
* Value: redacted * Value: private
* Type: status
* Description: Some of the information of the object instance * Type: status
has not been made available. This is most commonly applied to * Description: The information of the object instance is not
entities. designated for public consumption. This is most commonly
applied to entities.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
8. 8.
* Value: obscured * Value: redacted
* Type: status * Type: status
* Description: Some of the information of the object instance * Description: Some of the information of the object instance
has been altered for the purposes of not readily revealing the has not been made available. This is most commonly applied
actual information of the object instance. This is most to entities.
commonly applied to entities.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
9.2. Event Actions 9.
* Value: obscured
* Type: status
* Description: Some of the information of the object instance
has been altered for the purposes of not readily revealing
the actual information of the object instance. This is most
commonly applied to entities.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
10.
* Value: associated
* Type: status
* Description: The object instance is associated with other
object instances in the registry. This is most commonly used
to signify that a nameserver is associated with a domain or
that an entity is associated with a network resource or
domain.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
11.
* Value: active
* Type: status
* Description: The object instance is in use. For domain
names, it signifies that the domain name is published in DNS.
For network and autnum registrations it signifies that they
are allocated or assigned for use in operational networks.
This maps to the EPP 'OK' status.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
12.
* Value: inactive
* Type: status
* Description: The object instance is not in use. See
'active'.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
13.
* Value: locked
* Type: status
* Description: Changes to the object instance cannot be made,
including the assocation of other object instances.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
14.
* Value: pending create
* Type: status
* Description: A request has been received for the creation of
the object instance but this action is not yet complete.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
15.
* Value: pending renew
* Type: status
* Description: A request has been received for the renewal of
the object instance but this action is not yet complete.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
16.
* Value: pending transfer
* Type: status
* Description: A request has been received for the transfer of
the object instance but this action is not yet complete.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
17.
* Value: pending update
* Type: status
* Description: A request has been received for the update or
modification of the object instance but this action is not
yet complete.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
18.
* Value: pending delete
* Type: status
* Description: A request has been received for the deletion or
removal of the object instance but this action is not yet
complete. For domains, this might mean that the name in no
longer published in DNS but has not yet been purged from the
registry database.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
10.2.2. 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 50, line 29 skipping to change at page 59, line 22
* Type: event action * Type: event action
* Description: The object instance was transferred from one * Description: The object instance was transferred from one
registrant to another. registrant to another.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
9.3. Roles 8.
* Value: locked
* Type: event action
* Description: The object instance was locked (see the 'locked'
status).
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
9.
* Value: unlocked
* Type: event action
* Description: The object instance was unlocked (see the
'locked' status).
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
10.2.3. 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
2. 2.
* Value: tech * Value: technical
* Type: role * Type: role
* Description: The entity object instance is a technical contact
for the registration.
* Registrant Name: Andrew Newton * Description: The entity object instance is a technical
contact for the registration.
* Registrant Contact Information: andy@hxr.us * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
3. 3.
* Value: administrative * Value: administrative
* Type: role * Type: role
* Description: The entity object instance is an administrative * Description: The entity object instance is an administrative
contact for the registration. contact for the registration.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
4. 4.
* Value: abuse * Value: abuse
* Type: role
* Type: role
* Description: The entity object instance handles network abuse * Description: The entity object instance handles network abuse
issues on behalf of the registrant of the registration. issues on behalf of the registrant of the registration.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
5. 5.
* Value: billing * Value: billing
* Type: role * Type: role
* Description: The entity object instance handles payment and * Description: The entity object instance handles payment and
billing issues on behalf of the registrant of the billing issues on behalf of the registrant of the
registration. registration.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
6. 6.
* Value: registrar * Value: registrar
* Type: role * Type: role
* Description: The entity object instance represents the * Description: The entity object instance represents the
authority responsible for the registration in the registry. authority responsible for the registration in the registry.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
7. 7.
* Value: reseller * Value: reseller
* Type: role
* Description: The entity object instance represents a third * Type: role
party through which the registration was conducted (i.e. not
the registry or registrar).
* Registrant Name: Andrew Newton * Description: The entity object instance represents a third
party through which the registration was conducted (i.e. not
the registry or registrar).
* Registrant Contact Information: andy@hxr.us * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
8. 8.
* Value: sponsor * Value: sponsor
* Type: role * Type: role
* Description: The entity object instance represents a domain * Description: The entity object instance represents a domain
policy sponsor, such as an ICANN approved sponsor. policy sponsor, such as an ICANN approved sponsor.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
9. 9.
* Value: proxy * Value: proxy
* Type: role * Type: role
* Description: The entity object instance represents a proxy for * Description: The entity object instance represents a proxy
another entity object, such as a registrant. for another entity object, such as a registrant.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
9.4. Variant Relations * Registrant Contact Information: andy@hxr.us
10.
* Value: notifications
* Type: role
* Description: An entity object instance designated to receive
notifications about association object instances.
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
11.
* Value: noc
* Type: role
* Description: The entity object instance handles
communications related to a network operations center (NOC).
* Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us
10.2.4. 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 54, line 27 skipping to change at page 64, line 32
* Type: domain variant relation * Type: domain variant relation
* Description: Registration of the variant names occurs * Description: Registration of the variant names occurs
automatically with the registration of the containing domain automatically with the registration of the containing domain
registration. registration.
* Registrant Name: Andrew Newton * Registrant Name: Andrew Newton
* Registrant Contact Information: andy@hxr.us * Registrant Contact Information: andy@hxr.us
10. Security Considerations 11. 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 [RFC4627] to
prevent code injection. prevent code injection.
11. Internationalization Considerations 12. Internationalization Considerations
11.1. Character Encoding 12.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.
11.2. URIs and IRIs 12.2. URIs and IRIs
[I-D.ietf-weirds-using-http] defines the use of URIs and IRIs in [I-D.ietf-weirds-using-http] defines the use of URIs and IRIs in
RDAP. RDAP.
11.3. Language Tags 12.3. Language Tags
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.
11.4. Internationalized Domain Names 12.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 9.4. values listed in Section 10.2.4.
12. Privacy Considerations 13. 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 9.1 for the list of status been redacted or obscured. See Section 10.2.1 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.
13. Contributing Authors and Acknowledgements 14. 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 L.
Newton. Additionally, this document incorporates word on DNR 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
skipping to change at page 56, line 5 skipping to change at page 66, line 5
domain names. domain names.
Ernie Dainow provided the background information on the secure DNSSEC Ernie Dainow provided the background information on the secure DNSSEC
attributes and objects for domains, informative text on DNSSEC, and attributes and objects for domains, informative text on DNSSEC, and
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.
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 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., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
skipping to change at page 57, line 10 skipping to change at page 67, line 10
[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.
[I-D.kewisch-vcard-in-json] [I-D.ietf-jcardcal-jcard]
Kewisch, P., "jCard: The JSON format for vCard", draft- Kewisch, P., "jCard: The JSON format for vCard", draft-
kewisch-vcard-in-json-01 (work in progress), March 2013. ietf-jcardcal-jcard-05 (work in progress), July 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-05 (work in progress), May 2013. weirds-using-http-07 (work in progress), July 2013.
[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 Lookup Format", draft-ietf-weirds-rdap-query-05 Protocol Lookup Format", draft-ietf-weirds-rdap-query-05
(work in progress), June 2013. (work in progress), June 2013.
[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.
14.2. Informative References 15.2. Informative References
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
September 2004. September 2004.
[RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
RFC 3730, March 2004. STD 69, RFC 5730, August 2009.
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
Security Extensions Mapping for the Extensible Security Extensions Mapping for the Extensible
Provisioning Protocol (EPP)", RFC 5910, May 2010. Provisioning Protocol (EPP)", RFC 5910, May 2010.
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
Internationalized Email", RFC 6530, February 2012. August 2011.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839, January 2013.
[JSON_acendancy] [JSON_acendancy]
MacVittie, ., "The Stealthy Ascendancy of JSON", 04 2011. MacVittie, ., "The Stealthy Ascendancy of JSON", 04 2011.
[IANA_IDNTABLES]
, "IANA IDN Tables", ,
<http://www.iana.org/domains/idn-tables>.
[JSON_performance_study] [JSON_performance_study]
Montana State University - Bozeman, Montana State Montana State University - Bozeman, Montana State
University - Bozeman, Montana State University - Bozeman, University - Bozeman, Montana State University - Bozeman,
Montana State University - Bozeman, "Comparison of JSON Montana State University - Bozeman, "Comparison of JSON
and XML Data Interchange Formats: A Case Study", 2009. and XML Data Interchange Formats: A Case Study", 2009.
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 9.3 be relationship. It is recommended that the values from Section 10.2.3
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 admin contact: embedded entity that is both a registrant and admin contact:
{ {
... ...
"entities" : "entities" :
[ [
{ {
"handle" : "XXXX", "handle" : "XXXX",
skipping to change at page 59, line 43 skipping to change at page 70, line 4
"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 9.1). (see Section 10.2.1).
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" :
[ [
{ {
"handle" : "XXXX", "handle" : "XXXX",
skipping to change at page 60, line 41 skipping to change at page 70, line 45
{ {
... ...
"entities":[ "entities":[
{ {
"handle":"XXXX", "handle":"XXXX",
"vcardArray":[ "vcardArray":[
"vcard", "vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"], ["fn", {}, "text", "Joe's Fish, Chips and Domains"],
["kind", {}, "text", "individual"], ["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"],
["title", {}, "text", "Research Scientist"],
["role", {}, "text", "Project Lead"],
["adr", ["adr",
{ "type":"work" }, { "type":"work" },
"text", "text",
[ [
"", "",
"Suite 1234", "Suite 1234",
"4321 Rue Somewhere", "4321 Rue Somewhere",
"Quebec", "Quebec",
"QC", "QC",
"G1V 2M2", "G1V 2M2",
skipping to change at page 61, line 32 skipping to change at page 71, line 34
], ],
["tel", ["tel",
{ {
"type":["work", "voice"], "type":["work", "voice"],
"pref":"1" "pref":"1"
}, },
"uri", "tel:+1-555-555-1234;ext=102" "uri", "tel:+1-555-555-1234;ext=102"
], ],
["email", ["email",
{ "type":"work" }, { "type":"work" },
"text", "joe.user@example.com" "text", "joes_fish_chips_and_domains@example.com"
], ],
] ]
], ],
"roles":[ "registrar" ], "roles":[ "registrar" ],
"publicIds":[ "publicIds":[
{ {
"type":"IANA Registrar ID", "type":"IANA Registrar ID",
"identifier":"1" "identifier":"1"
} }
], ],
skipping to change at page 64, line 6 skipping to change at page 74, line 4
{ {
"eventAction" : "last changed", "eventAction" : "last changed",
"eventDate" : "1990-12-31T23:59:60Z" "eventDate" : "1990-12-31T23:59:60Z"
} }
] ]
} }
] ]
} }
Appendix C. Structured vs Unstructured Addresses Appendix C. Structured vs Unstructured Addresses
The entity (Section 6.1) object class uses jCard The entity (Section 6.1) object class uses jCard
[I-D.kewisch-vcard-in-json] to represent contact information, [I-D.ietf-jcardcal-jcard] to represent contact information, including
including postal addresses. jCard has the ability to represent postal addresses. jCard has the ability to represent multiple
multiple language preferences, multiple email address and phone language preferences, multiple email address and phone numbers, and
numbers, and multiple postal addresses in both a structured and multiple postal addresses in both a structured and unstructured
unstructured format. This section describes the use of jCard for format. This section describes the use of jCard for representing
representing structured and unstructured addresses. structured and unstructured addresses.
The following is an example of a jCard. The following is an example of a jCard.
{ {
"vcardArray":[ "vcardArray":[
"vcard", "vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"], ["fn", {}, "text", "Joe User"],
["n", {}, "text", ["n", {}, "text",
skipping to change at page 66, line 10 skipping to change at page 76, line 6
] ]
} }
Figure 22 Figure 22
The arrays in Figure 22 with the first member of "adr" represent The arrays in Figure 22 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 [RFC6530]. 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
3. street address - 4321 Rue Somewhere 3. street address - 4321 Rue Somewhere
4. locality (e.g., city) - Quebec 4. locality (e.g., city) - Quebec
skipping to change at page 67, line 21 skipping to change at page 77, line 16
using either the 'dsData' or 'keyData' object arrays. Client using either the 'dsData' or 'keyData' object arrays. Client
implementers should be aware that some registries do not collect or implementers should be aware that some registries do not collect or
do not publish all of the secure DNS meta-information. do not publish all of the secure DNS meta-information.
Appendix E. Motivations for Using JSON Appendix E. Motivations for Using JSON
This section addresses a common question regarding the use of JSON This section addresses a common question regarding the use of JSON
over other data formats, most notably XML. over other data formats, most notably XML.
It is often pointed out that many DNRs and one RIR support the EPP It is often pointed out that many DNRs and one RIR support the EPP
[RFC3730] standard, which is an XML serialized protocol. The logic [RFC5730] standard, which is an XML serialized protocol. The logic
is that since EPP is a common protocol in the industry it follows is that since EPP is a common protocol in the industry it follows
that XML would be a more natural choice. While EPP does influence that XML would be a more natural choice. While EPP does influence
this specification quite a bit, EPP serves a different purpose which this specification quite a bit, EPP serves a different purpose which
is the provisioning of Internet resources between registries and is the provisioning of Internet resources between registries and
accredited registrars and serves a much narrower audience than that accredited registrars and serves a much narrower audience than that
envisioned for RDAP. envisioned for RDAP.
By contrast, RDAP has a broader audience and is designed for public By contrast, RDAP has a broader audience and is designed for public
consumption of data. Experience from RIRs with first generation consumption of data. Experience from RIRs with first generation
RESTful web services for Whois indicate a large percentage of clients RESTful web services for Whois indicate a large percentage of clients
skipping to change at page 70, line 49 skipping to change at page 80, line 44
Added associated to the list of status values. Added associated to the list of status values.
Added a secure DNS section changed the 'delegationKey' object Added a secure DNS section changed the 'delegationKey' object
into the 'secureDNS' object. into the 'secureDNS' object.
Changed the suggested values to an IANA registry. Changed the suggested values to an IANA registry.
Added 'proxy' to the list of entity roles. Added 'proxy' to the list of entity roles.
-05
Added IANA registration for RDAP JSON Media Type
Added 'associated' status type. This was done earlier but got
dropped during a reorganization of the document.
Added the following status types:
active
inactive
locked
pending create
pending renew
pending update
pending transfer
pending delete
renew prohibited
Added the following event actions:
locked
unlocked
Added the following roles:
notifications
noc
Changed the 'tech' role to 'technical'
Many document reference changes.
Many examples have been fixed.
Added links to dsData and keyData.
Changed flags and protocols to integers in keyData.
Added 'entities' to the specified list for autnum.
Added SHOULD/SHOULD NOT language about using "type":
"application/rdap+json" for self links.
Added 'port43' to ip networks and autnum.
Authors' Addresses 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. 168 change blocks. 
242 lines changed or deleted 669 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/