Finding Additional Registration Data (RDAP) Service
draft-blanchet-regext-entityid2rdapserver-00

Document Type Active Internet-Draft (individual)
Last updated 2019-03-11
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
On Agenda regext at IETF-104
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        M. Blanchet
Internet-Draft                                                  Viagenie
Intended status: Standards Track                          March 11, 2019
Expires: September 12, 2019

          Finding Additional Registration Data (RDAP) Service
              draft-blanchet-regext-entityid2rdapserver-00

Abstract

   This document specifies a method to find which Registration Data
   Access Protocol (RDAP) server is authoritative to answer additional
   information for a query already answered by another server.  It is
   based on an entity id to RDAP server location mapping registry
   managed by IANA.  One use case of this specification is the domain
   registry RDAP server providing a referral URL to the registrar RDAP
   server, based on the registrar entity id, for information that the
   registrar is authoritative for such as the contact or reseller
   information.

Status of This Memo

   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 https://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 September 12, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (https://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

Blanchet               Expires September 12, 2019               [Page 1]
Internet-Draft       Finding Additional RDAP Service          March 2019

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  High-Level Functional Description . . . . . . . . . . . . . .   3
   4.  Registry of Entity to RDAP server location  . . . . . . . . .   3
   5.  Identifying the Entity  . . . . . . . . . . . . . . . . . . .   4
   6.  Structure of the Entity to RDAP Server Location Registry  . .   4
   7.  Formal Definition . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Imported JSON Terms . . . . . . . . . . . . . . . . . . .   6
     7.2.  Registry Syntax . . . . . . . . . . . . . . . . . . . . .   6
   8.  Recursive Referrals . . . . . . . . . . . . . . . . . . . . .   7
   9.  Merging the Data Received from Multiple RDAP Servers  . . . .   7
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   12. Discussion of this draft  . . . . . . . . . . . . . . . . . .   8
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     13.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     13.2.  Informative References . . . . . . . . . . . . . . . . .  10
     13.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Finding the authoritative Registration Data Access Protocol (RDAP)
   server is specified in [RFC7484].  In some use cases, the
   authoritative server answering an RDAP query may not have all the
   information, but instead another server has the missing information.
   However, the first server may not know the location (URL) of that
   other server, but just an organization identifier, therefore it can
   not send a link or redirect, as described in [RFC7483].
   Operationally, the location of the other server will need to be known
   to many servers, where storing the mapping centrally enables the
   scalable management of the locations..

   The typical use case is for domain registries where the RDAP server
   of the domain registry is not authoritative for or does not have some
   information for the query, but the registrar, a separate entity from
   the domain registry, is authoritative and does have that additional
   information.  The information may include contact, reseller,
Show full document text