Subject: [weirds] Registrars versus Contacts

From: Ernie Dainow <[email-masked]>
Date: Fri, 31 May 2013 14:31:23 -0400

Registrars and Contacts are represented as Entities (Appendix B.1 in 
draft-ietf-weirds-json-response-03). While this is a neat, concise 
model, I have encountered two problems with it.

1. Contacts often have a 'sponsoring' registrar. There is no field 
within an entity to show this. However, the previous version, 
draft-ietf-weirds-json-response-02, had a "sponsoredBy" field which 
could be used within an entity (example on page 26-27).

2. Some Registrar entities have contacts within them. For example, the 
following Registrar has Tech and Admin contacts:
whois -h whois.pir.org registrar id R63-LROR

One way to address both of these is to allow entities to contain other 
entities, as in:
"entities": [
    {
       "handle": "424-AS",
       "roles": [
          "Tech",
          "Admin"
       ],
       "vcardArray": [
          ...
       ],
       "entities": [
          {
          "handle": "284-RS",
          "roles": [
             "registrar"
          ],
          "vcardArray": [
             ...
          ]
       ]
    },
    ...
]

The other way, which avoids nested entities objects and is probably 
simpler, is to separate out Registrars as separate from Contacts. 
Registrars would have the same structure as Entities, except that the 
roles element would be redundant and unneeded. This approach would also 
require another RDAP url query path for registrars, as distinct from 
entities.

Simply restoring "sponsoredBy" does not provide an adequate solution, 
since it does not provide a way to get the actual Registrar data via a 
handle, a link or the vCard data itself.

-Ernie

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 31 May 2013 18:59:25 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ernie Dainow
> Sent: Friday, May 31, 2013 2:31 PM
> To: [email-masked]
> Subject: [weirds] Registrars versus Contacts
> 

I don't know that I buy the "registrars are special" argument, but nested entities may make sense if entities truly have a hierarchical relationship. It seems silly to duplicate a data structure only to eliminate one element.

Scott

---

From: Andy Newton <[email-masked]>
Date: Fri, 31 May 2013 19:15:20 +0000

>could be used within an entity (example on page 26-27).

That was moved to a "sponsor" role type. See Appendix A.3

>One way to address both of these is to allow entities to contain other

I agree with Scott. Nested entities make more sense. Registrars with
contacts really are no different than ISPs with contacts, which is what we
have in the RIR world (in some RIRs, not all).

-andy

---

From: Pieter Vandepitte <[email-masked]>
Date: Fri, 31 May 2013 22:38:52 +0200

I like the idea of nested entities and would even go one step further 
and define it for all object classes (also nameservers)

Pieter

P.S.
I noticed you used vCardArray, which is currently not part of the 
draft. But It made me thinking that it could probably provide a 
solution for you. If we adapt entities so that it can contain an array 
of vCards, one could make use of ROLES or CATEGORIES to distinguish 
between the different types. Strictly speaking we even don't need an 
array of vCards, since vCard properties can have parameters (most 
notably TYPE).

On the other hand, this might probably lead to a bunch of custom TYPEs 
and or ROLEs/CATEGORIES. Moreover you get in trouble if you want to 
define the handle of the sponsor in vCard... (unless we register vCard 
extensions for RDAP properties ;-))

Open question: is there a need to change vCard to vCardArray?

On Fri 31 May 2013 09:15:20 PM CEST, 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/>

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 31 May 2013 17:18:21 -0400

> Open question: is there a need to change vCard to vCardArray?
It's a minor name change of the RDAP key from vCard to vcardArray, based 
on the following thread: LABEL parameter for ADR (Was: vcard example in 
http://tools.ietf.org/html/draft-ietf-weirds-json-response-03)

On 5/1/2013 8:38 PM, Michael Angstadt wrote:
> @Pete: The syntax of the jCards in your examples aren't *quite*
> correct.  The first element of the jCard array is the string "vcard".
> The second element is an array which contains all of the property
> arrays.  The "vcard" string is redundant in this context, since the
> object field already uses this name, but I am just thinking that
> parsers might have trouble parsing the jCard without it.  The examples
> should look like this:
>
> {
>    "handle" : "XXXX",
>    "vCard" :
>    [
>      "vcard",
>      [
>        [ "version", {}, "text", "4.0" ],
>        [ "fn", {}, "text", "Joe Bob, Inc." ],
>        ...
>      ]
>    ]
>
> Thanks,
> Mike
>

For RDAP, this is confusing and prone to reversal and case errors. We 
should use a different name, as in

{
   "handle" : "XXXX",
   "vcardArray" :
   [
     "vcard",
     [

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Fri, 31 May 2013 21:45:25 +0000

>and define it for all object classes (also nameservers)

I agree. Nameservers needs them too.

There are enough changes queued up for this draft now that I'll try to
respin it as soon as possible.

-andy