Hi all,

I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data.

RDAP uses jCard (a json version of the vCard standard) to convey contact information about individuals and organizations in json formatted RDAP Responses.

The vCard spec (and thus jCard) does not mandate or require the inclusion of “kind”. Its inclusion is optional and if it is not present the kind of “individual” is to be assumed. From the vCard spec:

6.1.4. KIND

Purpose: To specify the kind of object the vCard represents.

Value type: A single text value.

Cardinality: *1 [Exactly one instance per vCard MAY be present.]

Special notes: The value may be one of the following:

"individual" for a vCard representing a single person or entity.

This is the default kind of vCard.

"group" for a vCard representing a group of persons or entities.

The group's member entities can be other vCards or other types

of entities, such as email addresses or web sites. A group

vCard will usually contain MEMBER properties to specify the

members of the group, but it is not required to. A group vCard

without MEMBER properties can be considered an abstract

grouping, or one whose members are known empirically (perhaps

"IETF Participants" or "Republican U.S. Senators").

All properties in a group vCard apply to the group as a whole,

and not to any particular MEMBER. For example, an EMAIL

property might specify the address of a mailing list associated

with the group, and an IMPP property might refer to a group

chat room.

"org" for a vCard representing an organization. An organization

vCard will not (in fact, MUST NOT) contain MEMBER properties,

and so these are something of a cross between "individual" and

"group". An organization is a single entity, but not a person.

It might represent a business or government, a department or

division within a business or government, a club, an

association, or the like.

All properties in an organization vCard apply to the

organization as a whole, as is the case with a group vCard.

For example, an EMAIL property might specify the address of a

contact point for the organization.

"location" for a named geographical place. A location vCard will

usually contain a GEO property, but it is not required to. A

location vCard without a GEO property can be considered an

abstract location, or one whose definition is known empirically

(perhaps "New England" or "The Seashore").

All properties in a location vCard apply to the location

itself, and not with any entity that might exist at that

location. For example, in a vCard for an office building, an

ADR property might give the mailing address for the building,

and a TEL property might specify the telephone number of the

receptionist.

An x-name. vCards MAY include private or experimental values for

KIND. Remember that x-name values are not intended for general

use and are unlikely to interoperate.

An iana-token. Additional values may be registered with IANA (see

Section 10.3.4). A new value's specification document MUST

specify which properties make sense for that new kind of vCard

and which do not.

Implementations MUST support the specific string values defined

above. If this property is absent, "individual" MUST be assumed

as the default. If this property is present but the

implementation does not understand its value (the value is an

x-name or iana-token that the implementation does not support),

the implementation SHOULD act in a neutral way, which usually

means treating the vCard as though its kind were "individual".

The presence of MEMBER properties MAY, however, be taken as an

indication that the unknown kind is an extension of "group".

ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts.

If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec. Essentially this would allow us to create two new RDAP specific “kind” values. E.g.

"legal" <We would create a definition that would detail what the kind

value of “legal” means>

"natural" <We would create a definition that would detail what the kind

value of “natural” means>

This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval.

Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF. The regext working group is where all the RDAP technical specs are defined.

This internet-draft, called the RDAP jCard Profile Spec, currently requires the use of kind in all RDAP jCard responses.

“Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".”

Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed.

RDAP Response snippets that use “kind = individual”

godaddy.com example (registrar = GoDaddy)

"entities": [

{

"objectClassName": "entity",

"handle": "1",

"vcardArray": [

"vcard",

[

"version",

{},

"text",

"4.0"

[

"kind",

{},

"text",

"individual"

[

"org",

{

"type": "work"

"text",

"Go Daddy Operating Company, LLC"

[

"adr",

{},

"text",

[

"",

"Arizona",

"",

"United States"

]

"roles": [

"registrant"

"events": [

{

"eventAction": "last update",

"eventDate": "2021-06-22T11:49:32Z"

}

"remarks": [

{

"title": "REDACTED FOR PRIVACY",

"type": "object truncated due to authorization",

"description": [

"Some of the data in this object has been removed."

]

}

]

namecheap.com example (registrar = eNom)

"entities": [

{

"objectClassName": "entity",

"roles": [

"registrant"

"vcardArray": [

"vcard",

[

"version",

{},

"text",

"4.0"

[

"kind",

{},

"text",

"individual"

[

"lang",

{},

"language-tag",

"en"

[

"adr",

{},

"text",

[

"",

"AZ",

"",

"US"

]

[

"contact-uri",

{},

"uri",

"https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d"

]

"remarks": [

{

"title": "REDACTED FOR PRIVACY",

"description": "Some of the data in this object has been removed",

"type": "object redacted due to authorization"

}

]

Brian King

He/Him/His
Head of Policy and Advocacy

T +1 443 761 3726

Time zone: US Eastern

clarivate.com | Accelerating innovation