Re: [weirds] RDAP registrar entities

Brian Mountford <> Fri, 30 October 2015 17:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C2C151A90B1 for <>; Fri, 30 Oct 2015 10:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L06UFLDPRdsf for <>; Fri, 30 Oct 2015 10:30:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA0681A8986 for <>; Fri, 30 Oct 2015 10:30:47 -0700 (PDT)
Received: by vkgs66 with SMTP id s66so51821404vkg.1 for <>; Fri, 30 Oct 2015 10:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OCNccYdgQIdWMa4rh9dwXWahvuVMrrZsWgWJF2HwPzs=; b=lM0JRVc1YZmTP2C3KQ6pVLPwxr3zqRlcvPExWAfjcDxfR0wTeuTNkhi3ssTXmCwFLK Cyavlnw6G3lY05uax6zh4CF5fjx56hfXLX+KF3SBZmEEmSZaDkziiZrG1e26wtqPBVtA YRpXBAeS1YeTZTItQsuZFXMCs8N/LWtBoQWsU0NDMNO9xm/wvc3nSxnppunc1RF41Xds 5lUFZNQ9Fjd+3OnOhXo/AOducfz0ztfD5U/of4Lb0Z3x/nyOvfBzejdon6en1+xZJ4iB 3hvcsWA9N14h29Nsnk0kUdqxfiCUtMmSLavdQQLeCUsFTV78urYGfh2BAgvX9T2yoQfr e/SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OCNccYdgQIdWMa4rh9dwXWahvuVMrrZsWgWJF2HwPzs=; b=GfI5ix9SVyU6Wg1Jo1rmS+5Ek2EkX6SnNK6WWx454lUnpwrnqigqgBmPW2/KqasHbb 3fcY+S0KNA93twYpb2e3jJFmqT4Dd+cv88VDUNY+WywnF5YQYUaC87dwm+eGdsEXqaSX 8Hrd0JdEH9pAGSW3UJhfsih7ZbkkSFtyYkgyxJk4QHyZ77o9Tg+Hk8KmOyX+LyL3EmDt f360QVCXqKfLULtJHX5H5gxvbKGaEwbUEv01L3oWOEfp7R8m0XdE9P3bzfX994W1YGkW bZav2TxhgVLd6P8jMZLxRVyVmibXdTUvB1I1dnAYzYTMr1SMNZaxTL+87t7uRgtjnT2s 1uVw==
X-Gm-Message-State: ALoCoQmsK48WfUd5aDgHNfAZL8FkMfXX1EUY2oTJvSh8nteHE2edqa+1qioYe+lBbNMHm09S4X8o
X-Received: by with SMTP id j85mr6194031vki.134.1446226246979; Fri, 30 Oct 2015 10:30:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 30 Oct 2015 10:30:27 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Brian Mountford <>
Date: Fri, 30 Oct 2015 13:30:27 -0400
Message-ID: <>
To: Andy Newton <>
Content-Type: multipart/alternative; boundary=001a11478f34b79a1e052355c972
Archived-At: <>
Cc: "" <>
Subject: Re: [weirds] RDAP registrar entities
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Oct 2015 17:30:49 -0000

I see. So an array of child entities is legal inside an entity or
nameserver, not just a domain, correct?

On Fri, Oct 30, 2015 at 1:09 PM, Andy Newton <> wrote:

> Hi Brian,
> On Oct 30, 2015, at 12:01 PM, Brian Mountford <>
> wrote:
> First of all, is there a reason why registrars and contacts were lumped
> together into one type of thing? Just curious.
> The reason is quite simple. All sorts of organizations end up being
> modeled the same way, with only a relationship qualifier differentiating
> them.
> The example in RFC 7483 for a registrar included several addresses and
> phone numbers, as if the sample registrar also had contacts associated with
> it. But none of the addresses and phone numbers were marked with anything
> that would distinguish between the contacts (e.g. a type of "admin",
> "tech", etc.). Should we just take all the data we have for a registrar,
> including all addresses of associated contacts, and throw them into the
> entity JSON object one after another? Can we mark them with the contact
> role as a type? Or does type always need to be "home" or "work”?
> This is similar to how some RIRs model ISPs. The ISP is an entity, that
> then has child entities for the contacts.
> See as an example.
> This type of thing may not be so obvious in the RFC because of the way the
> JSON is described. I have an RDAP JCR draft that might make it more
> readable.
> RFC 7482 describes searching for an entity by name. In the case of our
> registrars, we have two things that could be a "name": the name of the
> registrar itself, and the name of any associated contact. Am I correct that
> the search is confined to the registrar name? Or are we supposed to look
> through to the contact names, and pass back any registrar with a matching
> contact?
> How you limit or broaden the search is your choice. RDAP just specifies
> how the query is formulated by the clients. You may have requirements from
> a policy body about how that is to work, but the protocol is not that
> proscriptive.
> I hope that helps.
> -andy