vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)
RFC 8605
| Document | Type |
RFC - Informational
(May 2019)
Was
draft-hollenbeck-vcarddav-icann-rdap-extensions
(individual in art area)
|
|
|---|---|---|---|
| Authors | Scott Hollenbeck , Roger Carney | ||
| Last updated | 2019-05-14 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | Richard Wilhelm | ||
| Shepherd write-up | Show Last changed 2019-01-30 | ||
| IESG | IESG state | RFC 8605 (Informational) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Alexey Melnikov | ||
| Send notices to | (None) | ||
| IANA | IANA review state | IANA OK - Actions Needed | |
| IANA action state | RFC-Ed-Ack |
RFC 8605
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.
Hollenbeck & Carney Informational [Page 1]
RFC 8605 ICANN RDAP vCard Extensions May 2019
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.
Hollenbeck & Carney Informational [Page 2]
RFC 8605 ICANN RDAP vCard Extensions May 2019
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].
Hollenbeck & Carney Informational [Page 3]
RFC 8605 ICANN RDAP vCard Extensions May 2019
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
Hollenbeck & Carney Informational [Page 4]
RFC 8605 ICANN RDAP vCard Extensions May 2019
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>.
Hollenbeck & Carney Informational [Page 5]
RFC 8605 ICANN RDAP vCard Extensions May 2019
[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.
Hollenbeck & Carney Informational [Page 6]
RFC 8605 ICANN RDAP vCard Extensions May 2019
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
Hollenbeck & Carney Informational [Page 7]