Internet Engineering Task Force T. Harrison Internet-Draft G. Michaelson Updates: 7483 (if approved) APNIC Intended status: Standards Track July 7, 2019 Expires: January 8, 2020 RDAP jCard Profile draft-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 Harrison & Michaelson Expires January 8, 2020 [Page 1] Internet-Draft RDAP jCard Profile July 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Profile Definition . . . . . . . . . . . . . . . . . . . . . 3 3. Operational Considerations . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Registration Data Access Protocol (RDAP) [RFC7480] 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 [RFC2119]. Harrison & Michaelson Expires January 8, 2020 [Page 2] Internet-Draft RDAP jCard Profile July 2019 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". Harrison & Michaelson Expires January 8, 2020 [Page 3] Internet-Draft RDAP jCard Profile July 2019 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 Harrison & Michaelson Expires January 8, 2020 [Page 4] Internet-Draft RDAP jCard Profile July 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, . [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, . 6.2. Informative References [ICANN-RDAP-PROFILE] ICANN, "RDAP Response Profile", February 2019, . [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, DOI 10.17487/RFC7480, March 2015, . [RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019, . Authors' Addresses Tom Harrison Asia-Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia Email: tomh@apnic.net George G. Michaelson Asia-Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 Australia Email: ggm@apnic.net Harrison & Michaelson Expires January 8, 2020 [Page 5]