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

"Linlin Zhou" <> Fri, 09 October 2015 03:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BBBBA1B2C71 for <>; Thu, 8 Oct 2015 20:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qh-Dcryrc3qk for <>; Thu, 8 Oct 2015 20:00:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0216D1B2C4E for <>; Thu, 8 Oct 2015 19:59:57 -0700 (PDT)
Received: from zll (unknown []) by (Coremail) with SMTP id AQAAf0DZ4DiLLRdWmyErAw--.4865S2; Fri, 09 Oct 2015 10:59:23 +0800 (CST)
Date: Fri, 9 Oct 2015 10:59:25 +0800
From: "Linlin Zhou" <>
To: =?UTF-8?B?SG9sbGVuYmVjaywgU2NvdHQ=?= <>, "Kaveh Ranjbar" <>
References: <>, <>, <>, <>, <>, <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart483344256133_=----"
X-Coremail-Antispam: 1UD129KBjvJXoW3XFWrAw4xtr17Kw4fWry5XFb_yoWxWrWUpa 9xuw1akr98tryxCrn5ZF48ZFyF9393ArWUGF97GryUAa98Gw10qF4Ykws0vFyUGFsYvFW2 qw12vFn8Awn8Z3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQmb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k0 8I80eVW5JVWrJwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4 xG6xAIxVCFxsxG0wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1l Ox8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F2 4lFcxC0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Gr1l42xK82IYc2Ij64vIr41l4I8I3I0E 4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGV WUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_ Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rV WrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_ Gr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUgoUqUUUUU
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <>
Cc: "" <>, "" <>, 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: Fri, 09 Oct 2015 03:00:05 -0000

Hi Scott,
I agree with your suggestions on writing IETF documents of RDAP additional functionality. And a BCP document seems also necessary for registries to implement RDAP servers.

1. one or two RDAP extension documents
Besides the issues you mentioned, I'd like to propose to add the reseller information as an optional extension in the RDAP response. Having discussed in WG and last IETF meeting, I think most of WG agree that it would be good to have the reseller included in RDAP/WHOIS.

2. BCP document
As for the BCP document, we are interested in contributing text and some implementation experience. Since we have already implemented almost all of the necessary and additional RDAP functionality and 
existing technical documents could be provided.


Linlin Zhou
From: Hollenbeck, Scott
Date: 2015-10-07 19:22
To: Kaveh Ranjbar
CC:;; Gustavo Lozano
Subject: Re: [eppext] [gtld-tech] RDAP server of the registry
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.
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.
So I’m suggesting a new for two or three documents: one or two that describe additional needed functionality and one that describes the operational profile. Completion of the operational profile will likely have a dependency on policy development work in ICANN circles.
From: Kaveh Ranjbar [] 
Sent: Tuesday, October 06, 2015 5:57 PM
To: Hollenbeck, Scott
Cc: Gustavo Lozano;;
Subject: Re: [gtld-tech] RDAP server of the registry
Thank you Scott,
I am sold, so +1 on Scott’s suggestion.
All the best,
On 06 Oct 2015, at 14:53, Hollenbeck, Scott <> wrote:
It’s more than just policy, Kaveh – it’s implementation requirements that I’m suggesting should be developed with community consensus. Internet-Drafts can be (and have been) written to document implementations of IETF standards. Here’s one example that became an Informational RFC:
An Informational-intended document that describes protocol option settings could be developed for RDAP in a very similar way. What’s in the document now is incomplete, but it would be a very good start, and as I said – I’m willing to help write.
From: Kaveh Ranjbar [] 
Sent: Tuesday, October 06, 2015 10:05 AM
To: Hollenbeck, Scott
Cc: Gustavo Lozano;;
Subject: Re: [gtld-tech] RDAP server of the registry
Hi Scott,
With all due respect I disagree. The intent of the document is to outline ICANN’s “policy” towards it’s Registries and Registrars. It basically points out the RFC’s they have to comply with and outlines a few issues and provisions, mostly ICANN specific requirements (for example details of address information) which IMHO is out of scope of an I-D. 
On the other hand, there are few issues pointed out in the document (specially the ones from Appendix A) which are good candidates for IETF discussions and possibly updating (or writing new) RFCs.
All the best,
On 05 Oct 2015, at 13:11, Hollenbeck, Scott <> wrote:
Gustavo, I’d very much prefer to see the profile described in an I-D and developed using the IETF’s consensus process. I’m also willing to back up that preference with writing help as needed. I’ll have specific comments on the profile itself “soon”.
From: EppExt [] On Behalf Of Gustavo Lozano
Sent: Monday, October 05, 2015 10:34 AM
Subject: [eppext] RDAP server of the registry
The first version of the ICANN gTLD profile was published days ago, (see:, this document describes basic parameters and objects to be implemented by ICANN-contracted parties.
The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date).
The gTLD profile support the same functionality with the following mechanism:
The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object.
Questions for this group:
* What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group.
* What is your opinion about documenting this mechanism in an I-D?
Gustavo Lozano