draft-ietf-weirds-json-response-10.txt   draft-ietf-weirds-json-response-11.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: April 11, 2015 Verisign Labs Expires: April 30, 2015 Verisign Labs
October 8, 2014 October 27, 2014
JSON Responses for the Registration Data Access Protocol (RDAP) JSON Responses for the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-json-response-10 draft-ietf-weirds-json-response-11
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 April 11, 2015. This Internet-Draft will expire on April 30, 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
skipping to change at page 2, line 51 skipping to change at page 2, line 51
10.2.3. Event Actions . . . . . . . . . . . . . . . . . . . 63 10.2.3. Event Actions . . . . . . . . . . . . . . . . . . . 63
10.2.4. Roles . . . . . . . . . . . . . . . . . . . . . . . 66 10.2.4. Roles . . . . . . . . . . . . . . . . . . . . . . . 66
10.2.5. Variant Relations . . . . . . . . . . . . . . . . . 69 10.2.5. Variant Relations . . . . . . . . . . . . . . . . . 69
11. Security Considerations . . . . . . . . . . . . . . . . . . . 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 70
12. Internationalization Considerations . . . . . . . . . . . . . 71 12. Internationalization Considerations . . . . . . . . . . . . . 71
12.1. Character Encoding . . . . . . . . . . . . . . . . . . . 71 12.1. Character Encoding . . . . . . . . . . . . . . . . . . . 71
12.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 71 12.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 71
12.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 71 12.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 71
12.4. Internationalized Domain Names . . . . . . . . . . . . . 71 12.4. Internationalized Domain Names . . . . . . . . . . . . . 71
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 71 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 71
14. Contributing Authors and Acknowledgements . . . . . . . . . . 71 14. Contributing Authors and Acknowledgements . . . . . . . . . . 72
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 72
15.1. Normative References . . . . . . . . . . . . . . . . . . 72 15.1. Normative References . . . . . . . . . . . . . . . . . . 72
15.2. Informative References . . . . . . . . . . . . . . . . . 73 15.2. Informative References . . . . . . . . . . . . . . . . . 74
Appendix A. Suggested Data Modeling with the Entity Object Class 74 Appendix A. Suggested Data Modeling with the Entity Object Class 74
A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 74 A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 74
A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 76 A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 77
Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 78 Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 79
Appendix C. Structured vs Unstructured Addresses . . . . . . . . 80 Appendix C. Structured vs Unstructured Addresses . . . . . . . . 81
Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 83 Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 83
Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 83 Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 84
Appendix F. Changelog . . . . . . . . . . . . . . . . . . . . . 84 Appendix F. Changelog . . . . . . . . . . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
This document describes responses in the JSON [RFC7159] format for This document describes responses in the JSON [RFC7159] format for
the queries as defined by the Registration Data Access Protocol the queries as defined by the Registration Data Access Protocol
Lookup Format [I-D.ietf-weirds-rdap-query]. Lookup Format [I-D.ietf-weirds-rdap-query].
[I-D.ietf-weirds-using-http] describes a communication protocol for [I-D.ietf-weirds-using-http] describes a communication protocol for
exchanging queries and responses. exchanging queries and responses.
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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
1.2. Data Model 1.2. Data Model
The data model for JSON responses is specified in four sections: The data model for JSON responses is specified in five 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
lookup of a single object lookup of a single object
4. arrays of objects representing structured data corresponding to a 4. arrays of objects representing structured data corresponding to a
search for multiple objects search for multiple objects
5. the response to an error 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 returned by both RIRs and DNRs:
1. domains 1. domains
2. nameservers 2. nameservers
3. entities 3. entities
The information served by both RIRs and DNRs for these object classes The information served by both RIRs and DNRs for these object classes
overlap extensively and are given in this document as a unified model overlap extensively and are given in this document as a unified model
for both classes of service. for both classes of service.
skipping to change at page 5, line 19 skipping to change at page 5, line 19
is the subject of the lookup. A response to a search for multiple is the subject of the lookup. A response to a search for multiple
objects yields a JSON object that contains an array of JSON objects objects yields a JSON object that contains an array of JSON objects
that are the subject of the search. In each type of response, other that are the subject of the search. In each type of response, other
data structures are present within the topmost JSON object. data structures are present within the topmost JSON object.
2. Use of JSON 2. Use of JSON
2.1. Naming 2.1. Naming
Clients of these JSON responses SHOULD ignore unrecognized JSON Clients of these JSON responses SHOULD ignore unrecognized JSON
attributes in responses. Servers can insert values into the JSON members in responses. Servers can insert members into the JSON
responses which are not specified in this document, but that does not responses which are not specified in this document, but that does not
constitute an error in the response. Servers which insert such constitute an error in the response. Servers which insert such
unspecified values into JSON responses SHOULD have names prefixed unspecified members into JSON responses SHOULD have member names
with a short identifier followed by an underscore followed by a prefixed with a short identifier followed by an underscore followed
meaningful name. These short identifiers aid software implementers by a meaningful name. It has been observed that these short
with identifying the specification of the JSON name, and failure to identifiers aid software implementers with identifying the
use one could cause an implementer to assume the server is specification of the JSON member, and failure to use one could cause
erroneously using a name from this specification. This allowance an implementer to assume the server is erroneously using a name from
does not apply to jCard ([RFC7095]) objects. The full JSON name (the this specification. This allowance does not apply to jCard
prefix plus the underscore plus the meaningful name) SHOULD adhere to ([RFC7095]) objects. The full JSON name (the prefix plus the
the character and name limitations of the prefix registry described underscore plus the meaningful name) SHOULD adhere to the character
in [I-D.ietf-weirds-using-http]. Failure to use these limitations and name limitations of the prefix registry described in
could result in slower adoption as these limitations have been given [I-D.ietf-weirds-using-http]. Failure to use these limitations could
to aid some client programming models. result in slower adoption as these limitations have been observed to
aid some client programming models.
Consider the following JSON response with JSON names, all of which Consider the following JSON response with JSON members, all of which
are specified in this document. are specified in this document.
{ {
"handle" : "ABC123", "handle" : "ABC123",
"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 1 Figure 1
If The Registry of the Moon desires to express information not found If The Registry of the Moon desires to express information not found
in this specification, it might select "lunarNic" as its identifying in this specification, it might select "lunarNic" as its identifying
prefix and insert, as an example, the name prefix and insert, as an example, the member named
"lunarNic_beforeOneSmallStep" to signify registrations occurring "lunarNic_beforeOneSmallStep" to signify registrations occurring
before the first moon landing and the name before the first moon landing and the member named
"lunarNic_harshMistressNotes" containing other descriptive text. "lunarNic_harshMistressNotes" containing other descriptive text.
Consider the following JSON response with JSON names, some of which Consider the following JSON response with JSON names, some of which
should be ignored by clients without knowledge of their meaning. should be ignored by clients without knowledge of their meaning.
{ {
"handle" : "ABC123", "handle" : "ABC123",
"lunarNic_beforeOneSmallStep" : "TRUE THAT!", "lunarNic_beforeOneSmallStep" : "TRUE THAT!",
"remarks" : "remarks" :
[ [
skipping to change at page 7, line 30 skipping to change at page 7, line 30
], ],
"lunarNic_harshMistressNotes" : "lunarNic_harshMistressNotes" :
[ [
"In space,", "In space,",
"nobody can hear you scream." "nobody can hear you scream."
] ]
} }
Figure 2 Figure 2
Insertion of unrecognized names ignored by clients may also be used Insertion of unrecognized members ignored by clients may also be used
for future revisions to this specification. for future revisions to this specification.
Clients processing JSON responses need to be prepared for values Clients processing JSON responses need to be prepared for members
specified in this document to be absent from a response, as no JSON representing registration data specified in this document to be
value listed is required to appear in a response. In other words, absent from a response. In other words, servers are free to not
servers are free to not included values based on their own policies. include JSON members containing registration data based on their own
policies.
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.
3. Common Data Types 3. Common Data Types
JSON [RFC7159] 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 common, JSON character strings
document derived from the JSON character string. used in this document.
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 are to be a registry-unique in this document are 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',
'roid', 'nic-handle', 'registrationNo', etc. are 'roid', 'nic-handle', 'registrationNo', etc. are
terms often synonymous with this data type. In terms often synonymous with this data type. In
this document, the term 'handle' is used. The term this document, the term 'handle' is used. The term
skipping to change at page 9, line 12 skipping to change at page 9, line 12
Contact information is defined using jCards (JSON vCards) as Contact information is defined using jCards (JSON vCards) as
described in [RFC7095] described in [RFC7095]
4. Common Data Structures 4. Common Data Structures
This section defines common data structures used in responses and This section defines common data structures used in responses and
object classes. object classes.
4.1. RDAP Conformance 4.1. RDAP Conformance
The first data structure is named "rdapConformance" and is simply an The data structure named "rdapConformance" is an array of strings,
array of strings, each providing a hint as to the specifications used each providing a hint as to the specifications used in the
in the construction of the response. This data structure appears construction of the response. This data structure appears only in
only in the top most object of a response. the top most JSON object of a response.
An example rdapConformance data structure: An example rdapConformance data structure:
"rdapConformance" : "rdapConformance" :
[ [
"rdap_level_0" "rdap_level_0"
] ]
Figure 3 Figure 3
skipping to change at page 14, line 18 skipping to change at page 14, line 18
See Appendix B regarding the various ways events can be modeled. See Appendix B regarding the various ways events can be modeled.
4.6. Status 4.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 10.2.2 for a indicating the state of a registered object (see Section 10.2.2 for a
list of values). list of values).
4.7. Port 43 WHOIS Server 4.7. Port 43 WHOIS Server
This data structure, named 'port43', is a simple string containing This data structure, a member named 'port43', is a simple string
the fully-qualified host name or IP address of the WHOIS [RFC3912] containing the fully-qualified host name or IP address of the WHOIS
server where the containing object instance may be found. Note that [RFC3912] server where the containing object instance may be found.
this is not a URI, as there is no WHOIS URI scheme. Note that this is not a URI, as there is no WHOIS URI scheme.
4.8. Public IDs 4.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:
o type - a string denoting the type of public identifier o type - a string denoting the type of public identifier
o identifier - a public identifier of the type denoted by 'type' o identifier - a public identifier of the type denoted by 'type'
skipping to change at page 14, line 47 skipping to change at page 14, line 47
{ {
"type":"IANA Registrar ID", "type":"IANA Registrar ID",
"identifier":"1" "identifier":"1"
} }
] ]
Figure 11 Figure 11
4.9. Object Class Name 4.9. Object Class Name
This data structure, named "objectClassName", gives the object class This data structure, a member named "objectClassName", gives the
name of a particular object as a string. This identifies the type of object class name of a particular object as a string. This
object being processed. An objectClassName is REQUIRED in all RDAP identifies the type of object being processed. An objectClassName is
response objects so that the type of the object can be interpreted. REQUIRED in all RDAP response objects so that the type of the object
can be interpreted.
4.10. An Example 4.10. 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"
skipping to change at page 17, line 24 skipping to change at page 17, line 24
a search result set, servers SHOULD provide a link representing a URI a search result set, servers SHOULD provide a link representing a URI
for that object class instance using the "self" relationship as for that object class instance using the "self" relationship as
described in the IANA registry specified by [RFC5988]. As explained described in the IANA registry specified by [RFC5988]. As explained
in Section 5.2, this may be not always be possible for name server in Section 5.2, this may be not always be possible for name server
data. Clients MUST be able to process object instances without a data. Clients MUST be able to process object instances without a
"self" link. When present, clients can use the self link for caching "self" link. When present, clients can use the self link for caching
data. Servers MAY provide more than one "self" link for any given data. Servers MAY provide more than one "self" link for any given
object instance. Failure to provide any "self" link by a server may object instance. Failure to provide any "self" link by a server may
result in clients being unable to cache object class instances. result in clients being unable to cache object class instances.
Clients using "self" links for caching SHOULD not cache any object
class instances where the authority of the self link is different
than the authority of the server returning the data. Failing to do
so might result in cache poisoning.
Self links MUST contain a "type" element containing the "application/ Self links MUST contain a "type" element containing the "application/
rdap+json" media type when referencing RDAP object instances as rdap+json" media type when referencing RDAP object instances 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 4.9) string in each object.
5.1. The Entity Object Class 5.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 [RFC7159] with one construct, the entity object class, them in JSON [RFC7159] with one construct, the entity object class,
skipping to change at page 27, line 9 skipping to change at page 27, line 9
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 5.1) objects, they may also have an array of entities (Section 5.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", "objectClassName" : "nameserver",
"handle" : "XXXX", "handle" : "XXXX",
"ldhName" : "ns1.xn--fo-5ja.example", "ldhName" : "ns1.xn--fo-5ja.example",
... ...
"entities" : "entities" :
[ [
... ...
], ],
... ...
} }
skipping to change at page 51, line 16 skipping to change at page 51, line 16
{ {
"rdapConformance" : "rdapConformance" :
[ [
"rdap_level_0" "rdap_level_0"
], ],
... ...
"domainSearchResults" : "domainSearchResults" :
[ [
{ {
"objectClassName" : "domain",
"handle" : "1-XXXX", "handle" : "1-XXXX",
"ldhName" : "1.example.com", "ldhName" : "1.example.com",
... ...
}, },
{ {
"objectClassName" : "domain",
"handle" : "2-XXXX", "handle" : "2-XXXX",
"ldhName" : "2.example.com", "ldhName" : "2.example.com",
... ...
} }
] ]
} }
search_response_example search_response_example
9. Indicating Truncated Responses 9. Indicating Truncated Responses
skipping to change at page 55, line 7 skipping to change at page 55, line 7
Restrictions on usage: none Restrictions on usage: none
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)
10.2. JSON Values Registry 10.2. JSON Values Registry
This section requests that the IANA establish an RDAP JSON Values This section requests that the IANA create a new category in the
Registry for use in the notices and remarks (Section 4.3), status protocol registries labeled "Registration Data Access Protocol
(Section 4.6), role (Section 5.1), event action (Section 4.5), and (RDAP)" (if it does not already exist), and within that category
domain variant relation (Section 5.3) fields specified in RDAP. establish a URL referenceable, stand-alone registry labeled "RDAP
JSON Values". This new registry is for use in the notices and
remarks (Section 4.3), status (Section 4.6), role (Section 5.1),
event action (Section 4.5), and domain variant relation (Section 5.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 * 'notice or remark type' - denotes a type of notice or remark
skipping to change at page 71, line 5 skipping to change at page 71, line 7
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 [RFC7159] to the security considerations outlined in Section 6 of [RFC7159] to
prevent code injection. prevent code injection.
Though not specific to JSON, RDAP implementers should be aware of the Though not specific to JSON, RDAP implementers should be aware of the
security considerations specified in [I-D.ietf-weirds-using-http] and security considerations specified in [I-D.ietf-weirds-using-http] and
the security requirements and considerations in the security requirements and considerations in
[I-D.ietf-weirds-rdap-sec]. [I-D.ietf-weirds-rdap-sec].
Clients caching data, especially clients using RDAP specific caches
(instead of HTTP layer caches), should have safeguards to prevent
cache poisoning. See Section 5 for advice on using the "self" links
for caching.
Finally, service operators should be aware of the privacy mechanisms
noted in Section 13.
12. Internationalization Considerations 12. Internationalization Considerations
12.1. Character Encoding 12.1. Character Encoding
The default text encoding for JSON responses in RDAP is UTF-8 The default text encoding for JSON responses in RDAP is UTF-8
[RFC3629], and all servers and clients MUST support UTF-8. [RFC3629], and all servers and clients MUST support UTF-8.
12.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
skipping to change at page 71, line 51 skipping to change at page 72, line 18
by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew
L. Newton. Additionally, this document incorporates work on DNR L. Newton. Additionally, this document incorporates work 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.
Tom Harrison, Murray Kucherawy, Ed Lewis contributed significant Tom Harrison, Murray Kucherawy, Ed Lewis, Audric Schiltknecht, Naoki
review comments and provided clarifying text. James Mitchell Kambe, and Maarten Bosteels contributed significant review comments
provided text regarding the processing of unknown JSON attributes and and provided clarifying text. James Mitchell provided text regarding
identified issues leading to the remodeling of events. Ernie Dainow the processing of unknown JSON attributes and identified issues
and Francisco Obispo provided concrete suggestions that led to a leading to the remodeling of events. Ernie Dainow and Francisco
better variant model for domain names. Obispo provided concrete suggestions that led to a better variant
model for domain names.
Ernie Dainow provided the background information on the secure DNSSEC Ernie Dainow provided the background information on the secure DNS
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 jCard (JSON vCard) was performed The switch to and incorporation of jCard (JSON vCard) was performed
by Simon Perreault. by Simon Perreault.
Olaf Kolkman and Murray Kucherawy chaired the IETF's WEIRDS working Olaf Kolkman and Murray Kucherawy chaired the IETF's WEIRDS working
group from which this document as been created. group from which this document as been created.
skipping to change at page 73, line 23 skipping to change at page 73, line 37
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
January 2014. January 2014.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[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-12 (work in progress), September 2014. weirds-using-http-13 (work in progress), October 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-14 Protocol Query Format", draft-ietf-weirds-rdap-query-15
(work in progress), September 2014. (work in progress), October 2014.
[I-D.ietf-weirds-rdap-sec] [I-D.ietf-weirds-rdap-sec]
Hollenbeck, S. and N. Kong, "Security Services for the Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol", draft-ietf-weirds- Registration Data Access Protocol", draft-ietf-weirds-
rdap-sec-09 (work in progress), September 2014. rdap-sec-09 (work in progress), September 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.
skipping to change at page 90, line 4 skipping to change at page 90, line 29
"port43" can now be either an domain name or IP address. "port43" can now be either an domain name or IP address.
"objectClassName" is now required. "objectClassName" is now required.
Numerous changes in prose for better readability. Numerous changes in prose for better readability.
Updated the security considerations section to point to using- Updated the security considerations section to point to using-
http and rdap-sec. http and rdap-sec.
-10 -10
Addressing many AD comments. Addressing many AD comments.
Changed IANA registrations to IESG. Changed IANA registrations to IESG.
'href' is now the only MUST in the a link. 'href' is now the only MUST in the a link.
-11
Changes to address IETF Last Call comments.
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
 End of changes. 33 change blocks. 
65 lines changed or deleted 90 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/