Hi James, From what I’ve seen, the expectation is that RDAP will substitute port 43 WHOIS.
We (uniregistry) currently do availability checks when the domain is not registered AND we also provide a very specific reason on why a domain is not available. Customers also want to know if a specific domain is under a specific policy that might change in the near future, for instance when we launched out TLDs we had a large set that was held back for a period of time (A.K.A. names collision), and just showing as “object does not exist” did not provide information on why and whether the name would be available in the future. We had to become very explicit when our support queue was growing very large from customers asking for a specific reason and/or dates when they could register the names. For us, RDAP has to cover both use cases. Whether a registry is obligated to provide an availability check or reason why the object is not available, should be mandated by policy and not in anyway by limitations of the protocol. Best regards, — Francisco Obispo Uniregistry Inc. On 16 Dec 2016, at 9:22, Gould, James wrote: > That is one of my concerns, RDAP is a lookup protocol and not the SRS and > should only return data that exists with no reasons why it does not exist > other than scenarios like authorization issues or when data can be found > elsewhere by reference. We have not defined the use cases and it should not > be assumed that because RDAP provides registration data that it should also > support availability logic like the SRS. Can we clearly define the use case > of this undefined service? I view this as a separate service from the SRS > and RDAP to meet the undefined needs of a yet to be defined set of users.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
