Subject: [weirds] 404

From: Pieter Vandepitte <[email-masked]>
Date: Wed, 15 May 2013 18:06:38 +0200

Hi, some stuff is still unclear to me:

Quoting from http://tools.ietf.org/html/draft-ietf-weirds-using-http-05

>        If the receiving server does not have the information being
>        requested and does not have knowledge of where the information
>        can be found, it returns a 404 response.

and

>    If a server wishes to respond that it has no information regarding
>    the query, it MUST return a 404 response code.  Optionally, it MAY
>    include additional information regarding the negative answer in the
>    HTTP entity body.

Strictly speaking, when a receiving server replies with a status equal
to available for a particular request, it DOES have information about
the requested domain: i.e. the domain is available and can be registered.

So in the case of a domain status = available (and if the domain name in
the request does comply to the parent domain policies and if the server
is authoritative for that information), I would implement the current
draft as returning a 200.

On the other hand it is a common practice in restful services to return
a 404 when the object is not found (= the domain is not found = the
domain is available)

This topic was already touched by Maarten Wullink
(http://www.ietf.org/mail-archive/web/weirds/current/msg02444.html) but
I couldn't find any clear answers on that.

Any recommendations?

Kind regards

Pieter

---

From: Byron Ellacott <[email-masked]>
Date: Thu, 16 May 2013 00:26:18 +0000

Hi Pieter,

>the requested domain: i.e. the domain is available and can be registered.

That particular information does not lie in the registration data context,
though.  RDAP answers questions about registration data, and a separate
service could answer questions about name availability.

My exhaustive test of one registrar suggests that their current port 43
behaviour does this: if I search for fdkajsfhlksdjhflsa.com, I get a "no
match" response, not an "available" response.

  Byron

---

From: Maarten Wullink <[email-masked]>
Date: Thu, 16 May 2013 09:23:09 +0200

> My exhaustive test of one registrar suggests that their current
> port 43 behaviour does this: if I search for
> fdkajsfhlksdjhflsa.com, I get a "no match" response, not an
> "available" response.

at the .nl ccTLD we support the "is <domainname>" syntax for our port
43 service. Which returns yes if the name exists otherwise it returns no.

I would be nice to support this with weirds, the current draft says
that when a 404 is returned, additional information may be added to
the entity body. Maybe we can describe a "availability" response? This
is something a number of different user types would be interested in.

something like this for names that are not in the registry and may be
registered?

   {
     "ldhName" : "thisnamedoesnotexist.example.com",
     "available": "yes"
   }

and for currently registered names.

   {
     "ldhName" : "example.com",
     "available": "no"
   }

> 
> Byron
> 
> _______________________________________________ weirds mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/weirds
> 

- -- 
Maarten Wullink MSc|Technical advisor / R&D engineer
SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 45 | M +31 (0)6 21 26 87 55 | F +31 (0)26 352 55 05
[email-masked] | www.sidn.nl

---

From: Andy Newton <[email-masked]>
Date: Thu, 16 May 2013 10:14:11 +0000

>     "ldhName" : "example.com",

There is already an "unregistered" value for variants. We could have the
same value for status.

{
  "ldhName" : "thisnamedoesnotexist.example.com",
  "status": [ "unregistered" ]
   }

But Byron's point still stands. The behavior of current Whois systems is
usually to return no-answer. So for interoperability purposes, is it 404
or a status of "unregistered"? Having some systems do one and some systems
do the other seems like a recipe for confusion. From an RIR perspective,
the answer should be 404 as in-addr.arpa domains aren't available for
registration. Just curious what others think.

This strays into the territory of a separate DAC protocol (started here:
http://www.ietf.org/mail-archive/web/weirds/current/msg02495.html), which
I still think is a good idea.

-andy

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 16 May 2013 13:56:50 +0200

I agree to some degree with Andy and Byron. I would definitely not
invent a new property, but rather extend the existing set of values.
Besides that, a 404 would be appropriate in the case of a "no match".

On the other hand, I'm not a proponent of yet another protocol. I think
it could perfectly fit into this protocol.

Could we combine both approaches (404 and extending status) and specify
something into the draft like:

"A server MUST return a 404 when it is authoritative for the requested
object. It MAY return an object response containing further information."

e.g.

HTTP/1.1 404 Not Found
Content-Type: application/rdap+json

{
  "ldhName": "thisnamedoesnotexist.example.com",
  "status": ["unregistered"],
  "remarks" :
    [
      {
        "description" :
          [
            "You can register your domain name at www.example.com",
            "Originally written by Terry Sullivan."
          ]
      }
    ]
}

There should be several extra statusses, like "unregistered",
"restricted registration", "not allowed"

What do you think?

Pieter

On 05/16/2013 12:14 PM, Andy Newton wrote:
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
> 

-- 
*Pieter Vandepitte*
*Software Engineer*
+32 16 29 89 27
*www.dnsbelgium.be* <http://www.dnsbelgium.be/>