vCard RDAP ICANN: vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)
New contact fields for domain registry data according to ICANN policy
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, <https://www.rfc-editor.org/info/rfc8605>.
@misc{rfc8605,
series = {Request for Comments},
number = 8605,
howpublished = {RFC 8605},
publisher = {RFC Editor},
doi = {10.17487/RFC8605},
url = {https://www.rfc-editor.org/info/rfc8605},
author = {S. Hollenbeck and R. Carney},
title = {{vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)}},
pagetotal = 7,
year = 2019,
month = may,
} RFC text
Contents
Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 8605 Verisign Labs
Category: Informational R. Carney
ISSN: 2070-1721 GoDaddy Inc.
May 2019
vCard Format Extensions:
ICANN Extensions for the Registration Data Access Protocol (RDAP)
Abstract
This document defines extensions to the vCard data format for
representing and exchanging contact information used to implement the
Internet Corporation for Assigned Names and Numbers (ICANN)
operational profile for the Registration Data Access Protocol (RDAP).
The property and parameter defined here are used to add values to
RDAP responses that are consistent with ICANN policies.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8605.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology Used in This Document . . . . . . . . . . . . 3
2. vCard Extensions: Properties . . . . . . . . . . . . . . . . 3
2.1. Property: CONTACT-URI . . . . . . . . . . . . . . . . . . 3
3. vCard Extensions: Parameters . . . . . . . . . . . . . . . . 4
3.1. Parameter: CC . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The "Temporary Specification for gTLD Registration Data" available at
<https://www.icann.org/resources/pages/gtld-registration-data-specs-
en> was published by the Internet Corporation for Assigned Named and
Numbers (ICANN) in 2018. The Temporary Specification includes
requirements that cannot currently be met by the Registration Data
Access Protocol (RDAP, [RFC7483]) without extending the underlying
vCard [RFC6350] specification used to represent RDAP entity objects.
This document includes specifications for an additional vCard
property and an additional vCard parameter to meet the requirements
of the Temporary Specification.
1.1. Terminology Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Syntax specifications shown here use the augmented Backus-Naur Form
(ABNF) as described in [RFC5234] and are specified as in the base
vCard specification [RFC6350].
2. vCard Extensions: Properties
This document describes one new vCard extension property.
2.1. Property: CONTACT-URI
Namespace:
Property name: CONTACT-URI
Purpose: RDAP entity information can be redacted under certain
circumstances (e.g., privacy). The Temporary Specification requires
that RDAP entity objects representing "Registrant", "Admin", and
"Tech" contacts contain an email address or a location for a web form
to facilitate email communication with the relevant contact in a way
that does not identify the associated individual. The CONTACT-URI
property can be used to include URIs representing an email address or
a location for a web form.
Value type: A single URI value.
Cardinality: *
Property parameters: PREF
Description: At least one "mailto", "http", or "https" URI value MUST
be provided. Additional CONTACT-URI properties MAY be provided to
describe other contact methods. If multiple CONTACT-URI properties
are used, the vCard PREF parameter MUST be used to describe the most
preferred property as described in Section 5.3 of RFC 6350 [RFC6350].
Format definition:
CONTACT-URI-param = "VALUE=uri" / pref-param ; pref-param from
[RFC6350]
CONTACT-URI-value = uri ; uri from [RFC3986]
Examples:
CONTACT-URI:https://contact.example.com
CONTACT-URI;PREF=1:mailto:contact@example.com
3. vCard Extensions: Parameters
This document describes one new vCard extension parameter.
3.1. Parameter: CC
Namespace:
Parameter name: CC
Purpose: ICANN requires the use of ISO 3166 [ISO.3166.1988] two-
letter codes, not "country names", in RDAP entity responses. This
parameter is used to extend the ADR property described in
Section 6.3.1 of RFC 6350 [RFC6350].
Description: This parameter contains the ISO 3166 [ISO.3166.1988]
two-character country code associated with the "country name" ADR
component described in Section 6.3.1 of RFC 6350 [RFC6350].
Format definition:
CC-param = "CC=" 2ALPHA
Examples:
ADR;TYPE=work;CC=US:;;54321 Oak St;Reston;VA;20190;USA
ADR;TYPE=home;CC=US:;;12345 Elm St;Reston;VA;20190;USA
4. IANA Considerations
IANA has added the following entry to the "vCard Properties" registry
defined in Section 10.3.1 of RFC 6350 [RFC6350].
Namespace:
Property: CONTACT-URI
Reference: Section 2.1 of RFC 8605 (this RFC)
IANA is requested to add the following entry to the vCard Parameters
registry defined in Section 10.3.2 of RFC 6350 [RFC6350].
Namespace:
Property: CC
Reference: Section 3.1 of RFC 8605 (this RFC)
5. Security Considerations
The CONTACT-URI value is purposefully intended to be a publicly
visible contact reference; as such, it cannot require confidentiality
protection. There are, however, privacy implications in the choice
of a URI scheme for the web form contact method. An "https" URI
value can be used to indicate support for confidentiality protection
for connections to the server that publishes the web form. This
document presents no other security considerations beyond those
described in Section 9 of the base vCard specification [RFC6350].
6. References
6.1. Normative References
[ISO.3166.1988]
International Organization for Standardization, "Codes for
the representation of names of countries, 3rd edition",
ISO Standard 3166, August 1988.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", RFC 7483,
DOI 10.17487/RFC7483, March 2015,
<https://www.rfc-editor.org/info/rfc7483>.
Acknowledgements
The author would like to acknowledge the following individuals for
their contributions to the development of this document: Rick
Wilhelm.
Authors' Addresses
Scott Hollenbeck
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: shollenbeck@verisign.com
URI: https://www.verisignlabs.com/
Roger Carney
GoDaddy Inc.
14455 N. Hayden Rd. #219
Scottsdale, AZ 85260
United States of America
Email: rcarney@godaddy.com
URI: http://www.godaddy.com
AI ELI5
On this page
§1ICANN Requirements for Contact Data
The Temporary Specification for gTLD Registration Data published by ICANN in 2018 sets requirements for how generic top-level domain registries must expose contact information. The Registration Data Access Protocol (RDAP) returns entity objects representing Registrant, Admin, and Tech contacts using the vCard format as defined in RFC 6350.
ICANN policy requires that contact information include either an email address or a web form URI for reaching the contact, and that country information use ISO 3166 two-letter country codes rather than country names. The base vCard specification did not support these requirements, so RFC 8605 adds them as extensions.
When someone looks up a domain, they get a contact card. The new rules say the card must show how to reach the contact (email or form) and use short country codes (like US, CA) instead of full names.
§2The CONTACT-URI Property
The new CONTACT-URI property holds a URI (such as a mailto or https URL) for contacting the registrant, admin, or tech contact. It can be a mailto: URI, an http: URI pointing to a web form, or an https: URI for secure web forms. At least one CONTACT-URI property MUST be provided.
The property supports the PREF parameter to indicate which contact method is preferred if multiple CONTACT-URI properties are present. Multiple CONTACT-URI properties MAY be used to list alternative contact methods. Example: CONTACT-URI;PREF=1:mailto:contact@example.com or CONTACT-URI:https://contact.example.com.
Instead of showing an email address directly, the contact field can point to an email link or a form on a website. You can list more than one option and say which is preferred.
§3The CC Parameter for Country Codes
The new CC parameter extends the vCard ADR (address) property. It carries an ISO 3166 two-letter country code (such as US, GB, or JP) to identify the country without using a country name. This meets ICANN requirements for unambiguous, standardized country identification.
The CC parameter is formatted as two uppercase letters. Example: ADR;TYPE=work;CC=US:;;54321 Oak St;Reston;VA;20190;USA. The parameter is simply added to the existing ADR property; it does not change the vCard structure.
On the address part of the contact card, instead of writing "United States", you just add a CC=US label. It is the same as on passports.
§4Usage in RDAP Responses
When an RDAP server returns entity objects for domain contact information, it now includes the CONTACT-URI property for each contact method (email or web form). The IANA registries have been updated to recognize both the CONTACT-URI property (added to the vCard Properties registry) and the CC parameter (added to the vCard Parameters registry).
The extensions are optional additions to vCard. Clients that do not understand CONTACT-URI or CC simply ignore these fields, while compliant RDAP clients parse them to provide the contact information that ICANN requires. The changes are backward compatible.
Servers that look up domain owners can now include the contact link and country code. Old software will still work; it just will not see the new fields.