RDAP jCard Profile
draft-harrison-regext-rdap-jcard-profile-00

Abstract

The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. RDAP uses jCard to convey information about individuals and other entities: for example, for the technical contact for a domain name. In practice, server operators are only using a small subset of jCard's functionality, so in an effort to simplify the requirements on the client side, this document defines a jCard profile for use with RDAP.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 8, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. Profile Definition
• 3. Operational Considerations
• 4. Security Considerations
• 5. IANA Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. RDAP uses jCard ([RFC7095]) to convey information about individuals and other entities (e.g. organisations and groups). jCard is in turn a way of representing vCard ([RFC6350]) information in JSON.

The core vCard specification defines 36 properties, 11 parameters, 12 data types, and 31 parameter values. More of each are defined in subsequent specifications (see the IANA vCard Elements registry). Due to the lack of supporting libraries for jCard, RDAP client developers often have to implement jCard support themselves, and handling the entire specification is a substantial burden.

This document defines a jCard profile for use with RDAP that will reduce the implementation complexity for client developers. The profile is primarily based on response data from the implementations that are currently included in the IANA RDAP bootstrap files.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Profile Definition

The following properties may be used in jCards included in RDAP responses:

• kind;
• fn;
• n;
• adr;
• tel;
• email;
• lang;
• geo;
• title;
• role;
• org;
• version; and
• contact-uri.

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

A "geo" property MUST have a type of "uri". A "tel" property MUST have a type of "uri" or "text". A "lang" property MUST have a type of "language-tag". A "contact-uri" property MUST have a type of "uri". All other properties MUST have a type of "text".

An "adr" property MUST include a "label" parameter, containing the content of the delivery address as a single string.

Properties may include "language", "altid", and "pref" parameters.

"email", "org" and "adr" properties may include a "type" parameter. The "type" parameter values that may be used are "work" and "home".

A "tel" property may include a "type" parameter. The "type" parameter values that may be used are those defined in [RFC6350].

An "adr" property may include a "cc" parameter. This parameter may be set even when the "country name" component of the property's value is not set.

Properties, types, and parameters not expressly permitted by way of this profile MUST NOT be used.

3. Operational Considerations

An RDAP client that encounters a jCard that is not in conformance with this specification SHOULD treat the jCard as if any non-conforming properties, parameters, or types were not present.

Various server implementations are currently using the non-standard "ISO-3166-1-alpha-2" property for the ISO-3166-1 alpha 2 country code of the country from the "adr" property in the jCard. This behaviour appears to be based on guidance from section 1.4.1 of ICANN's current RDAP response profile ([ICANN-RDAP-PROFILE]). However, that section states that it only applies when the "ISO-3166-1-alpha-2" property "has been published in the vCardProperties registry defined in Section 10.3.1 of RFC 6350", and that property has not yet been published in that way.

Various server implementations are currently setting the "country name" component of the "adr" property to be the ISO-3166-1 alpha 2 country code of the country. This behaviour appears to be based on guidance from section 1.4.2 of ICANN's current RDAP response profile ([ICANN-RDAP-PROFILE]). The "cc" parameter approach to this problem, defined in [RFC8605], is preferred in this profile.

4. Security Considerations

TBD

5. IANA Considerations

TBD

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses