Subject: Re: [weirds] Entity "Objects"

From: Dmitry Kohmanyuk <[email-masked]>
Date: Fri, 1 Mar 2013 13:24:09 +0200

On Feb 28, 2013, at 11:26 PM, James Mitchell <[email-masked]> wrote:

> Scott,
> 
> Perhaps contact objects and registrar objects share the same identifier space in Verisign's system, however in ours they do not. What object is identified by /entity/R-12345? My answer is both a contact and a registrar; the role does not satisfy the outcome as they will have different names, email addresses etc.
> 
> If I do not care about direct queries for contact/registrar objects (URLs constructed by clients), and instead assume that links will always be obtained in domain response,  then I CAN generate identifiers that separate the two identifier spaces (append C or R as appropriate) - however having to work around this does not feel right to me.
> 
> I believe that registrars should be their own path segments at /registrar/id. Does anyone else have this problem?

I agree with separation of registrar object and contact object - but as others pointed out there may be multiple types of contacts
(registrant, administrative, technical, billing, registrar, reseller) and to establish a namespace convention for each of them would require
WEIRDS to specify now all kinds of contacts there can be (or establish a registry for them with IANA, or both.)

Contacts may reference each other (in EPP schema, person-registrant contact is "owned" by registrar, but cannot be "owned" by admin-c.)

Example (output contains UTF-8 strings in *-loc: fields):

; whois -h whois.ua farm.org.ua 

% This is the Ukrainian Whois query server #B.
% The Whois is subject to Terms of use
% See https://hostmaster.ua/services/
%

domain:           farm.org.ua
dom-public:       NO
registrant:       frh-kpuh6om0dfxz
admin-c:          frh-il67tvusqjxy
tech-c:           frh-il67tvusqjxy
mnt-by:           ua.freehost
nserver:          ns-he.kolo.net
nserver:          ns.kolo.net
status:           clientTransferProhibited
created:          2012-07-30 10:32:25+03
modified:         2013-02-19 18:30:05+02
expires:          2013-07-30 10:32:25+03
source:           UAEPP

% Registrar:
% ==========
registrar:        ua.freehost
organization:     Freehost
organization-loc: ПП "Фріхост"
url:              http://www.freehost.ua
city:             Kyiv
country:          UA
source:           UAEPP

% Registrant:
% ===========
contact-id:       frh-kpuh6om0dfxz
person:           not published
e-mail:           not published
address:          n/a
mnt-by:           ua.freehost
status:           ok
status:           linked
created:          2013-02-19 18:30:03+02
source:           UAEPP

% Administrative Contacts:
% =======================
contact-id:       frh-il67tvusqjxy
person:           not published
e-mail:           not published
address:          n/a
mnt-by:           ua.freehost
status:           ok
status:           linked
created:          2013-02-19 18:30:03+02
source:           UAEPP

% Technical Contacts:
% ===================
contact-id:       frh-il67tvusqjxy
person:           not published
e-mail:           not published
address:          n/a
mnt-by:           ua.freehost
status:           ok
status:           linked
created:          2013-02-19 18:30:03+02
source:           UAEPP

% Query time:     16 msec

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 1 Mar 2013 12:17:18 +0000

Please don't suggest any Verisign bias here. There is none.

Ø  What object is identified by /entity/R-12345?

Your answer will depend on the roles associated with that entity. There may be more than one.

Andy

From: James Mitchell [mailto:[email-masked]]
Sent: Thursday, February 28, 2013 4:27 PM
To: Hollenbeck, Scott; [email-masked]
Subject: Re: Entity "Objects"

Scott,

Regards,
James

From: <Hollenbeck>, Scott <[email-masked]<mailto:[email-masked]>>
Date: Friday, 1 March 2013 12:17 AM
To: James Mitchell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Entity "Objects"

Entity objects can be identified by role. A registrar entity and a contact entity (such as a registrant) would have distinct roles in the context of a domain object.

Scott

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of James Mitchell
Sent: Thursday, February 28, 2013 6:17 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [weirds] Entity "Objects"

All,

I am concerned regarding the use of the entity object as described in the rdap query draft. It appears to me as though two separate objects, contacts and registrars, have been pulled together because they share data. This is problematic for me because
 - Contact objects and Registrar objects do not share the same identifier space.
 - Contact objects and Registrar objects share very little data; one may think of registrar objects as being composed of contact-like (not contact object) data, perhaps even several contact-like objects (registrar-contact objects do not share the same identifier space as domain-contact objects)

What is the motivation for shared query mechanism? Is it to avoid having one less path segment? How would one convey information about a registrar to the client, for example IANA ID without using registry-specific extensions?

Thanks,
James

---

From: James Mitchell <[email-masked]>
Date: Tue, 5 Mar 2013 22:58:07 +1100

Apologies if I have probably confused the problem(s). I do have issue with the protocol's support for non-standard information, such as attributes belonging only to registrar "entities", however I will post such issues in another thread.

I'll repurpose this thread to better explain my issues with the entity path segment. According to the specifications, the path segment /entity/R-12345 matches entities. My issue here is that I do not model "entity" objects. I may have a domain contact that is identified by the string "R-12345", and a registrar that is identified by the string "R-12345" because domain contacts and registrars do not share identifier space. What response is returned to such a query? The protocol does not allow me to return two objects, each with completely different information!

Andy suggested I could prefix identifiers with "contact_R-12345" and "registrar-R-12345", however end users will not be able to construct URLs without knowing the internals of the system they are querying; acceptance of the prefix solution would contradict the definition of URLs within the specification.

My preference would be provide mechanisms for the client to to determine the appropriate path segment in "negotiation" with the server (we can define a mandatory domain path segment if people get too nervous). Failing this, I would prefer separate /contact/R-12345 and /registrar/R-12345 path segments that can both return entity objects, and failing that I would accept it if the /entity/ path segment was explicitly declared OPTIONAL. I do not see a great need for contacts/registrars being an entry point into the system (I'm not running a contact object registry) and I can therefore use a path segment of my choosing in response to domain queries.

Additionally, I have a few comments regarding the example DNR Domain Object in draft-weirds-json-response.

 1.  the entity in the DNR Domain Object example response should include its role(s). I cannot tell whether the entity is a registrant, admin, billing, tech, or registrar, or all of the above.
 2.  The use of the sponsoredBy attribute is inconsistent with the use of domain contacts; apparently both registrar and domain contacts are entities however both are treated completely differently in the response. I would expect registrars and domain contacts are either attributes of domain objects (with full information either available inline or through links) or the sponsoring registrar included in the entities section (both illustrated below). I am leaning towards the use of attributes, however recall some resistance duplicating data for domain contact taking multiple roles. Regardless any method that allows me to return only links would suffice.
 3.  Extending point #2, I would assume that one could lookup a registrar by taking the value of the sponsoredBy attribute and constructing a URL /entity/SponsorXYZ. I would also assume the same could be done for the resoldBy attribute. Refer to this whole email why this does not work, noting that I believe that "sponsoredBy":"registrar_SponsorXYZ" is not acceptable given clients do not have to lookup the registrar information and my current WHOIS server does not impose this hack.

Example with attributes:
{
name:"abc.example",
…
sponsoredBy:{handle:"SponsorXYZ", link:"http://example.net/registrar/SponsorXYZ" },
registrant:{handle:"XXXX", link:"http://example.net/contact/XXXX"},
-- or --
registrant:{handle:"XXXX", entityNames: [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], role:"registrant", …},
…
}

Example with entities:
{
name:"abc.example",
…
entities:
[
{handle:"SponsorXYZ", name:"Registrar 123", role:"registrar", …},
{handle:"XXXX", entityNames: [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], role:"registrant", …}
]
…
}

Regards,
James

From: <Hollenbeck>, Scott <[email-masked]<mailto:[email-masked]>>
Date: Friday, 1 March 2013 11:17 PM
To: James Mitchell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Entity "Objects"

Please don’t suggest any Verisign bias here. There is none.

Andy

From: James Mitchell [mailto:[email-masked]]
Sent: Thursday, February 28, 2013 4:27 PM
To: Hollenbeck, Scott; [email-masked]<mailto:[email-masked]>
Subject: Re: Entity "Objects"

Scott,

Regards,
James

Scott

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of James Mitchell
Sent: Thursday, February 28, 2013 6:17 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [weirds] Entity "Objects"

All,

Thanks,
James