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

[Patrik Wallström]

> On 07 Oct 2015, at 13:22, Hollenbeck, Scott <shollenbeck at verisign.com> 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:
> 
> https://datatracker.ietf.org/doc/draft-gould-epp-rdap-status-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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20151007/68b46d5c/signature.asc>