Re: [regext] Antwort: RDAP lookup queries for reserved or unassignable domains

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 <sanz@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
>