Re: [eppext] [gtld-tech] RDAP server of the registry

Patrik Wallström <> Wed, 07 October 2015 12:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BD50D1A0092 for <>; Wed, 7 Oct 2015 05:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.736
X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o0aZWb3up4M8 for <>; Wed, 7 Oct 2015 05:33:17 -0700 (PDT)
Received: from ( [IPv6:2001:16d8:ff00:2a9::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 016121A00E4 for <>; Wed, 7 Oct 2015 05:33:17 -0700 (PDT)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 3C15E381D7; Wed, 7 Oct 2015 14:33:12 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_16981BA2-BB5F-47E4-BEBB-510AA9540215"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5.2
From: =?utf-8?Q?Patrik_Wallstr=C3=B6m?= <>
In-Reply-To: <>
Date: Wed, 7 Oct 2015 14:33:08 +0200
Message-Id: <>
References: <> <> <> <> <> <>
To: "Hollenbeck, Scott" <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: Kaveh Ranjbar <>, "" <>, "" <>, Gustavo Lozano <>
Subject: Re: [eppext] [gtld-tech] RDAP server of the registry
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Oct 2015 12:33:18 -0000

> On 07 Oct 2015, at 13:22, Hollenbeck, Scott <> wrote:
> Another possibility: a Best Current Practice (BCP) document. We’ll need to think about what we think the “best practices” should be, but that would be time well spent. Back to Gustavo’s original question…
> Yes, I’d like to see bits like this documented in an I-D that describes things that need to be added to RDAP for use by gTLD registries and registrars. However, I’m going to suggest that we take an inventory of those omissions and try to organize them in some way so that we don’t end up with multiple small documents that might instead be represented as a smaller number of larger documents. The profile document already has a good list of open issues; here’s a thought on how to organize and address them.

I think two documents might be good, one BCP for implementors (however, remembering RFC 4641 for DNSSEC, it is way to early in the deployment process to create a BCP) and an informational document for ICANNs requirements for gTLDs. I don’t think that the IETF ever distinguishes between gTLDs and other TLDs, since this is purely an ICANN distinction..

> 1. Gustavo’s links suggestion below.
> 2. Jim Gould’s status value mapping:
> 3. The “the last update date and time of the database used to generate the RDAP responses” event.
> 4. An event with the expiration date of the Registrar.
> 5. If a Registry supports multiple host objects with the same name, the Registry MUST support the capability to respond with a set of host objects in response to a name server lookup.
> I think these could be combined into one “RDAP extensions for gTLD Registries and Registrars” document. Additional search functionality, including Boolean search support, could be described in either this document or another document. If it’s simple, include it all in one document. If it isn’t, separate the topics so that the simpler ones can move ahead more quickly.

I would prefer if draft-gould-epp-rdap-status-mapping can go to standards track as a separate document, as it is beneficial for all TLD registries using EPP.

> So I’m suggesting a new for two or three documents: one or two that describe additional needed functionality and one that describes the op

Yes, agree.