If the goals of a domain availability check are: 1) use a simple technology such as HTTP (and RDAP) 2) keep the payload small
One solution may be to simply put a query parameter on the GET such as ?availability=true. Then the server would know to send back the minimum payload necessary, thus avoiding excessive bandwidth and allowing the server to execute a tighter code path for that specific purpose (i.e. no database fetches of entities, etc...). -andy On Wed, Dec 7, 2016 at 8:51 AM, Marcos Sanz <s...@denic.de> wrote: > Hello Mario, > >>I have a question about how to deal with RDAP lookup queries for >>reserved or unassignable domains. >> >>If a client submits a query about a reserved or unassignable domain, >>which response code should the server return? >> >>In my opinion, if the server returns a 404 response, it could be >>misunderstood. The client could undestand the domain is available. > > a very valid question. Even if you are able to signalize that the domain is > not available, you would like to further communicate the clients that they > don't need to query over and over again to find out if it's expired or > become free. > > RFC 7483 offers status "renew prohibited" > > Description: Renewal or reregistration of the object instance is > forbidden. > > > draft-ietf-regext-epp-rdap-status-mapping refines that and introduces > "server renew prohibited", which in my opinion is probably what you want to > communicate (server policy). > >>In the GET method, the server may include additional information >>regarding the negative answer > > See above. > >>, but it can't in the HEAD method. >> Maybe the 410 response code could be used in this case ? > > If we agree on the above, then the HEAD answer must be a 200. > > Best, > Marcos > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
