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<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> (a json version of the vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>. The vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec (and thus jCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>) 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...> spec: 6.1.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>. 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_do...>). 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft...>, currently requires the use of kind in all RDAP jCard responses. 1. “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<https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=O...> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c...> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contact_ccfaafca-2Db98c-2D4a8f-2D8746-2Dbdaa321c628d&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=sODG-xyeBvBKzfJnJHIuAIblUNvbBZ9Nfrrc9bzL5lo&e=>" ] ] ], "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<http://www.clarivate.com> | Accelerating innovation Follow us on LinkedIn<https://www.linkedin.com/company/clarivate>, Twitter<https://twitter.com/clarivate?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%...>, Facebook<https://www.facebook.com/clarivate/> and Instagram<https://www.instagram.com/clarivateofficial/?hl=en> Confidentiality note: This e-mail may contain confidential information from Clarivate. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is strictly prohibited. If you have received this e-mail in error, please delete this e-mail and notify the sender immediately.