| Network Working Group | B. Ellacott |
| Internet-Draft | T. Harrison |
| Intended status: Standards Track | APNIC Pty Ltd |
| Expires: December 30, 2017 | June 28, 2017 |
History of records in the Registration Data Access Protocol
draft-ellacott-historical-rdap-00
The Registration Data Access Protocol (RDAP) provides current registration information. This document describes an RDAP query and response extension that allows retrieving historical registration records.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 30, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Registration Data Access Protocol (RDAP) offers simple search and responses as defined in [RFC7482] and [RFC7483] respectively. Both the search and response documents implicitly describe current registration information. This document provides an extension to RDAP allowing the discovery of historical registration information.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
The JSON responses described in [RFC7483] are extended with one additional object class, the History object class, described below.
The history object class is a container in which individual registration records are listed, together comprising a history of registration. The registration records are represented in the form given in [RFC7483], without change.
The history object class can contain the following members:
In addition, any of the common data structures defined in section 4 of [RFC7483] may be included in accordance with the constraints of that section, with the following additional considerations.
The record data structure describes one historical registration record. It is an object containing the date range during which this record was current, and the record's content. The content of a historical record is a JSON response element as defined in [RFC7483]. In this way, history is defined for all RDAP object classes, and may be extended to apply to non-standard or new RDAP object classes without requiring a revision to the history specification.
The date range of the historical registration record consists of an element indicating the first moment at which the contained record was current, in the "applicableFrom" element, and an element indicating the first moment at which the contained record was no longer current, in the "applicableUntil" element. The date range is half-open, including the "applicableFrom" date but excluding the "applicableUntil" date. If the "applicableUntil" date is not included in the response, this indicates that the associated content was current at the time the response was generated.
An example of the record data structure:
{
"applicableFrom": "2008-09-04T06:51:49Z",
"applicableUntil": "2008-09-04T07:27:55Z",
"content": {
"objectClassName": "ip network",
...
}
}
Path segments for querying registration data are defined in [RFC7482] for five resource types (ip, autnum, domain, nameserver, and entity). In addition to these segments, this document defines one additional path segment, 'history', for querying the historical data of any of the five resource types, where supported by the server.
The history access specified in this document does not support searches.
Syntax: history/ip/<IP address> or history/ip/<CIDR prefix>/<CIDR length>
Queries for the history of IP networks follow the same form as for the current registration of IP networks. However, while the current registration query will select the "most-specific" or smallest IP network that completely encompasses the query network, an historical query selects all networks intersecting the query range.
A server MAY choose to limit the number of networks selected by a query, by limiting the size of sub-networks, or the total number, or some other means.
Syntax: history/autnum/<autonomous system number>
Queries for the history of an autonomous system number follow the same form as for the current registration of autonomous system numbers.
Syntax: history/domain/<domain name>
Queries for the history of a domain registration. As with [RFC7482] the domain is fully qualified, and SHOULD NOT be represented as a mixture of A-labels and U-labels.
Syntax: history/nameserver/<nameserver name>
Queries for the history of a nameserver. As with [RFC7482] the name is a fully qualified host name represented in either A-label or U-label format.
Syntax: history/entity/<handle>
Queries for the history of an entity. The syntax of the handle is specific to the registration provider.
The processing of queries proceeds as in [RFC7482] and [RFC7480]. Associated records, as documented in section 4.2 of [RFC7482], contribute to the history of a registration record, and so any change to the record or any of its associated records SHOULD be included in the response to a history query.
A server MAY choose to limit the responses given to a history query. For example, the date range of returned records may be restricted, or the number of distinct records may be limited. A server MAY choose to abridge history, such as eliding a short-lived record state. If a server limites responses in this way, it SHOULD indicate to the user that it has done so, either through the "help" path segment documented in [RFC7482], or in a "notice" element as documented in section 4.3 of [RFC7483] using an appropriate notice type such as "result set truncated due to unexplainable reasons".
Character encoding considerations are described in section 6.1 of [RFC7482].
The IANA is requested to add this document to the IANA RDAP Extensions Registry.
TO BE REMOVED: This registration should take place at <https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml>
Extension identifier: history_0
Registry operator: Asia Pacific Network Information Center
Published specification: TBD
Person & email address to contact for further information: Byron Ellacott <mailto:bje@apnic.net>
Intended usage: This extension allows an RDAP operator to provide historical registration data.
Historical records may contain information which was inadvertently entered into a record, and subsequently amended. It may contain information which was removed by request of the information holder. Additional privacy constraints may apply to data held for a long period. Operators of a history-capable RDAP service SHOULD ensure they have understood the privacy implications of this facility.
A query for historical records may consume more computing resources than a query for current records. Implementations SHOULD take care to offer operators the appropriate means to manage the operational cost of a historical service, limiting query rates or response sizes or both, where appropriate.
Substantial feedback on the initial draft was provided by Andrew Newton of ARIN.
| [RFC7480] | Newton, A., Ellacott, B. and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, DOI 10.17487/RFC7480, March 2015. |
| [RFC7482] | Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, DOI 10.17487/RFC7482, March 2015. |
| [RFC7483] | Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, DOI 10.17487/RFC7483, March 2015. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
{
"rdapConformance": [
"history_0",
"rdap_level_0"
],
"notices": [
{
"title": "Example Only",
"description": [
"This is an example object only."
]
}
],
"objectClassName": "history",
"records": [
{
"applicableFrom": "2009-01-20T07:00:00Z",
"applicableUntil": "2017-01-20T07:00:00Z",
"content": {
"objectClassName": "entity",
"handle": "POTUS",
"vcardArray": [
"vcard",
[
[ "version", {}, "text", "4.0" ],
[ "fn", {}, "text", "Barack Obama" ]
]
]
}
},
{
"applicableFrom": "2017-01-20T07:00:00Z",
"content": {
"objectClassName": "entity",
"handle": "POTUS",
"vcardArray": [
"vcard",
[
[ "version", {}, "text", "4.0" ],
[ "fn", {}, "text", "Donald Trump" ]
]
]
}
}
]
}
In this example, the "POTUS" entity has two historical records. The applicability range of the first record is left-closed, indicating that the "POTUS" entity had the first record's contents at noon EST on the 20th of January, 2009, and right-open, indicating that the "POTUS" entity no longer had the first record's contents at noon EST on the 20th of Janauary, 2017. The absence of a gap between the "applicableUntil" date of the first record and the "applicableFrom" date of the second record indicates that the record was updated, while a gap may indicate that the record was removed, then a similar record with the same key was subsequently added. The second record has no "applicableUntil" element, which indicates that, as of the time that this RDAP History response was prepared, the second record was still in effect.
This example also suggests that this response elides a number of previous versions of this record. A registry's local policy will determine what historical registration information is available, and may vary based on the identity of the entity retrieving the information.