Subject: [weirds] query optional parameter for existence of record

From: Marc Blanchet <[email-masked]>
Date: Sun, 2 Mar 2014 10:46:19 +0000

Hi,
 while doing the interop session this morning, I saw search results where the servers were sending a "lot" of data, with all the json formatting verbosity. However, one of the use cases for rdap queries is _just_ to know if the record exists (domain name or else), for all the clients that can't do this with EPP.  The Whois "protocol" did not have an explicit provision for this, since there was "no" protocol. I've been told that people were having separate servers (using a different hostnames) that provide just this use case: "whois -h special_server  domainname" and it _only_ returns a binary value: the record exists or does not exist, no registration data sent. Therefore, the use case already exists. And it would be much better to implement it in the protocol than having separate hostnames.

 So I'm proposing to add an optional parameter to the query format that would tell the server just return a binary value of existence of this record. This would help all the clients that only want to know if that record exists or not. This will help servers and infrastructure saving processing and bandwidth. 
 While the probably main use cases is for domain names, it is actually useful for all objects.

 For search queries, it could return either "no records match" or the "short" list of matches, but without the registration data. Given the last case (short list of matches), the response should then be formatted as JSON, whatever there is no match or a list, for consistency.

 If people agree with that idea, I can compose some text to be added to the query draft and the json response draft.

Marc.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sun, 2 Mar 2014 11:28:38 +0000

> -----Original Message-----
> From: weirds [mailto:[email-masked]] On Behalf Of Marc
> Blanchet
> Sent: Sunday, March 02, 2014 5:46 AM
> To: <[email-masked]>
> Subject: [weirds] query optional parameter for existence of record
> 
> Hi,
>  while doing the interop session this morning, I saw search results
> where the servers were sending a "lot" of data, with all the json
> formatting verbosity. However, one of the use cases for rdap queries is
> _just_ to know if the record exists (domain name or else), for all the
> clients that can't do this with EPP.  The Whois "protocol" did not have
> an explicit provision for this, since there was "no" protocol. I've
> been told that people were having separate servers (using a different
> hostnames) that provide just this use case: "whois -h special_server
> domainname" and it _only_ returns a binary value: the record exists or
> does not exist, no registration data sent. Therefore, the use case
> already exists. And it would be much better to implement it in the
> protocol than having separate hostnames.
> 
>  So I'm proposing to add an optional parameter to the query format that
> would tell the server just return a binary value of existence of this
> record. This would help all the clients that only want to know if that
> record exists or not. This will help servers and infrastructure saving
> processing and bandwidth.
>  For search queries, it could return either "no records match" or the
> "short" list of matches, but without the registration data. Given the
> last case (short list of matches), the response should then be
> formatted as JSON, whatever there is no match or a list, for
> consistency.
> 
>  If people agree with that idea, I can compose some text to be added to
> the query draft and the json response draft.

Given that there are WHOIS servers that provide this functionality and it could be used to provide more focused results I think this is a good idea.

Scott

---

From: Patrik Wallström <[email-masked]>
Date: Sun, 2 Mar 2014 12:52:38 +0100

> Given that there are WHOIS servers that provide this functionality and it could be used to provide more focused results I think this is a good idea.

+1

I think it’s very common among the ccTLD community to have such a service. The only component that was actually deployed from the IRIS work was the DCHK (domain check availability).

---

From: Frederico A C Neves <[email-masked]>
Date: Sun, 2 Mar 2014 09:01:47 -0300

> I think it’s very common among the ccTLD community to have such a service. The only component that was actually deployed from the IRIS work was the DCHK (domain check availability).

I agree this is useful but afaik those services are run using
completely different mechanisms from tcp/43, and it's normaly not a
search service.

Fred

---

From: Simon Perreault <[email-masked]>
Date: Sun, 02 Mar 2014 15:26:55 +0000

Le 2014-03-02 10:46, Marc Blanchet a écrit :
>  So I'm proposing to add an optional parameter to the query format that would tell the server just return a binary value of existence of this record.

I agree, and I propose to use the HEAD method for that. The client will
get to see the response code (e.g. 200 or 404) and there will be no body.

That's a thing that building on top of HTTP gives us for free. Anyone
that has implemented a server using HTTP frameworks such as
Tomcat/Jetty/etc. will have no extra code to write, just test and ensure
it already works as it is supposed to, maybe add extra "shortut"
optimization.

Tthe only thing left to do would be to document it in the rdap-query
draft as a good use case of the HEAD method.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 3 Mar 2014 16:01:11 +0800

> From: weirds [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Sunday, March 02, 2014 11:27 PM
> To: [email-masked]
> Subject: Re: [weirds] query optional parameter for existence of record
> 
record.
> I agree, and I propose to use the HEAD method for that. The client will
get to
> see the response code (e.g. 200 or 404) and there will be no body.
> 
+1
I agree this is a simple solution.

> That's a thing that building on top of HTTP gives us for free. Anyone that
has
> implemented a server using HTTP frameworks such as Tomcat/Jetty/etc. will
> have no extra code to write, just test and ensure it already works as it
is
> supposed to, maybe add extra "shortut"
> optimization.
> 
> Tthe only thing left to do would be to document it in the rdap-query draft
as a
> good use case of the HEAD method.
> 
> Simon
> --
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: "John Levine" <[email-masked]>
Date: 3 Mar 2014 09:44:48 -0000

>get to see the response code (e.g. 200 or 404) and there will be no body.

If the response code does indeed reliably tell whether it exists, I
agree, this is way easier than anything else we're going to invent.

R's,
John

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 3 Mar 2014 11:18:03 +0000

There are two use cases:
a) ask for a single object.
b) a search for potentially multiple objects match.
 b.1 just want to know if there is any match for the search string I sent.
 b.2 want to get the list of matches but without the registration data.

a) fits well with HEAD. We don't have to invent anything,  just put some text in the document.
b) could use HEAD. In this context, a positive response would only say there is a match, but would not return the actual matches. This is still useful information for the requestor. (use case b.1) But, if the requestor is only looking for the list of matches (case b.2), then he has to redo another query, normal this time, doing the normal query will return the "large" amount of data, that the requestor might not be interested, but just the object matches (i.e. domain names, not the registrant data). Therefore, HEAD is not sufficient for case b.2.

since I see good support of the overall idea, I'll suggest some text soon.

Marc.

---

From: Patrik Wallström <[email-masked]>
Date: Mon, 3 Mar 2014 12:31:50 +0100

> since I see good support of the overall idea, I'll suggest some text soon.

There is actually one more use case, which I have implemented for .SE. If a user (through a registrar or whatever) lookups a domain for availability, the user also wants to know if the name is allowed for registration (policy issue, or whatever the reason may be). So there is another potential message going back to the user, “not valid”.

---

From: Frederico A C Neves <[email-masked]>
Date: Mon, 3 Mar 2014 08:36:42 -0300

>  b.2 want to get the list of matches but without the registration data.

The use case that I mentioned earlier in this thread is a variation of
your a use case. It's the availabity service that some TLDs have
developed to remove load from whois providing a better service.

Ask for a single object, if not present at the repository (available
for registration), if present available alternatives could be listed.

Fred