Unverified Commit b3b662e4 authored by Gavin Brown's avatar Gavin Brown
Browse files

initial version

parents
Pipeline #24 failed with stages
This diff is collapsed.
Internet Engineering Task Force G. Brown
Internet-Draft CentralNic Group plc
Intended status: Experimental February 18, 2019
Expires: August 22, 2019
Extensible Provisioning Protocol (EPP) Contact Mapping for Registration
Data Access Protocol (RDAP) JSON Responses
draft-brown-epp-contacts-in-rdap-00
Abstract
This document describes how EPP contact objects can be represented in
RDAP entities.
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 August 22, 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.
Brown Expires August 22, 2019 [Page 1]
Internet-Draft EPP Contact Mapping for RDAP February 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
2. JSON Mapping of EPP Contact Objects . . . . . . . . . . . . . 3
2.1. Postal Address Information . . . . . . . . . . . . . . . 3
2.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Usage in RDAP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The Registration Data Access Protocol (RDAP, [RFC7483]) represents
contact information pertaining to the entities associated with
internet identifiers (such as domain names, IP address blocks, and
autonmymous system numbers) using jCard ([RFC7095]). jCard is a JSON
mapping of vCard ([RFC6350]) into JSON ([RFC4627]).
vCard is a generalised specification for entries in an "address
book", and provides a broad and extensible framework for storing
attributes associated with an individual, group or organisation.
However, as RDAP has been deployed by Regional Internet Registries
(RIRs) and domain name registries (DNRs), the complexity of the jCard
has been identified as having a negative effect on the ease of
implementing the RDAP specifications.
The Extensible Provisioning Protocol (EPP) is widely deployed by
domain name registries to facilitate provisioning of domain names and
other objects by registrars. The EPP Contact Mapping, defined in
[RFC5733], provides a lightweight structure to describe contact
information such as name, organization, postal and addresses, and
voice and fax numbers.
This document describes a way to map the structure of contact
information described in RFC5733 into JSON, and also how this
representation can be used in RDAP entity objects instead of jCard.
1.1. Conventions Used in This Document
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 [RFC2119].
Brown Expires August 22, 2019 [Page 2]
Internet-Draft EPP Contact Mapping for RDAP February 2019
2. JSON Mapping of EPP Contact Objects
This mapping is limited to the attributes of contact objects
described in sections 2.3 - 2.6 of RFC 5733. Other attributes, such
as unique IDs, status codes, and event actions, are already
adequately mapped to generic RDAP object attributes.
An EPP contact object may be represented in JSON by constructing a
JSON object with the following properties:
postalInfo this property is an object that contains the postal
address information.
voice this property is a string containing the voice number.
fax this property is a string containing the facsimile number.
email this property is a string containing the email address.
The "voice", "fax" and "email" properties MAY be omitted or NULL, but
if present, MUST be valid as per the validation rules described in
the XML schema in RFC 5733.
2.1. Postal Address Information
Every contact has associated postal-address information which may be
represented in either ASCII (for international use) or UTF-8 (for
domestic use).
The "postalInfo" property is an object with two properties: "int" and
"loc". These properties may contain postal information or may either
be omitted or NULL, but at least one MUST be present and contain
valid postal address information.
The postal address information in the "loc" object may contain any
valid UTF-8 sequence, but the data in the "int" object MUST NOT
contain any characters outside the ASCII range (U+0000 - U+007F).
The "int" and "loc" properties are JSON objects which may contain any
of the following:
name a string containing the contact name.
org a string containing the organization.
addr an object containing the following properties:
Brown Expires August 22, 2019 [Page 3]
Internet-Draft EPP Contact Mapping for RDAP February 2019
street a JSON array containing between one and three strings
contain the street address.
city a string containing the city.
sp a string containing the state or province.
pc a string containing the postal code.
cc the two-character country identifier specified in ISO 3166.
2.2. Example
The following is a JSON representation of the example contact object
shown in Section 3.1.2 of RFC 5733:
{
"postalInfo": {
"int": {
"name": "John Doe",
"org": "Example Inc.",
"addr": {
"street": [
"123 Example Dr.",
"Suite 100"
],
"city": "Dulles",
"sp": "VA",
"pc": "20166-6503",
"cc": "US",
},
},
"loc": NULL
},
"voice": "+1.7035555555x1234",
"fax": "+1.7035555556",
"email": "jdoe@example.com"
}
3. Usage in RDAP
RDAP servers MAY use the contact object representation described in
this document in entity object instead of jCard.
RDAP servers which do so MUST add the
"epp_entity_contact_info_level_0" string to the "rdapConformance"
array at the top-level of the RDAP response. This string as has been
registered with IANA.
Brown Expires August 22, 2019 [Page 4]
Internet-Draft EPP Contact Mapping for RDAP February 2019
In place of the "vCardArray" property, servers may then insert an
"eppContactInfo" property, whose value is a JSON object described in
this document.
3.1. Example
The following is an example of an RDAP entity which uses the EPP
contact mapping instead of jCard:
{
"rdapConformance": [
"rdap_level_0",
"epp_entity_contact_info_level_0"
],
"objectClassName": "entity",
"handle": "SH8013-REP",
"eppContactInfo": {
"postalInfo": {
"int": {
"name": "John Doe",
"org": "Example Inc.",
"addr": {
"street": [
"123 Example Dr.",
"Suite 100"
],
"city": "Dulles",
"sp": "VA",
"pc": "20166-6503",
"cc": "US",
},
},
"loc": NULL
},
"voice": "+1.7035555555x1234",
"fax": "+1.7035555556",
"email": "jdoe@example.com"
},
// rest of entity
}
4. Privacy Considerations
TODO.
Brown Expires August 22, 2019 [Page 5]
Internet-Draft EPP Contact Mapping for RDAP February 2019
5. IANA Considerations
TODO.
6. References
6.1. Normative References
[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>.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006,
<https://www.rfc-editor.org/info/rfc4627>.
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
August 2009, <https://www.rfc-editor.org/info/rfc5733>.
[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>.
6.2. Informative References
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>.
Author's Address
Gavin Brown
CentralNic Group plc
35-39 Moorgate
London, England EC2R 6AR
GB
Phone: +44 20 33 88 0600
Email: gavin.brown@centralnic.com
URI: https://www.centralnic.com
Brown Expires August 22, 2019 [Page 6]
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!ENTITY RFC2119 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4627 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4627.xml">
<!ENTITY RFC5733 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5733.xml">
<!ENTITY RFC6350 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml">
<!ENTITY RFC7095 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml">
<!ENTITY RFC7483 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7483.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<rfc category="exp" docName="draft-brown-epp-contacts-in-rdap-00"
ipr="trust200902" submissionType="independent">
<front>
<title abbrev="EPP Contact Mapping for RDAP">Extensible Provisioning
Protocol (EPP) Contact Mapping for Registration Data Access Protocol
(RDAP) JSON Responses</title>
<author fullname="Gavin Brown" initials="G" surname="Brown">
<organization>CentralNic Group plc</organization>
<address>
<postal>
<street>35-39 Moorgate</street>
<city>London</city>
<region>England</region>
<code>EC2R 6AR</code>
<country>GB</country>
</postal>
<phone>+44 20 33 88 0600</phone>
<email>gavin.brown@centralnic.com</email>
<uri>https://www.centralnic.com</uri>
</address>
</author>
<date month="February" year="2019" />
<area>Applications</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract><t>This document describes how EPP contact objects can be
represented in RDAP entities.</t></abstract>
</front>
<middle>
<section title="Introduction">
<t>The Registration Data Access Protocol (RDAP, <xref
target="RFC7483"/>) represents contact information pertaining to
the entities associated with internet identifiers (such as domain
names, IP address blocks, and autonmymous system numbers) using
jCard (<xref target="RFC7095"/>). jCard is a JSON mapping of vCard
(<xref target="RFC6350"/>) into JSON
(<xref target="RFC4627"/>).</t>
<t>vCard is a generalised specification for entries in an
"address book", and provides a broad and extensible framework for
storing attributes associated with an individual, group or
organisation. However, as RDAP has been deployed by Regional
Internet Registries (RIRs) and domain name registries (DNRs), the
complexity of the jCard has been identified as having a negative
effect on the ease of implementing the RDAP specifications.</t>
<t>The Extensible Provisioning Protocol (EPP) is widely deployed
by domain name registries to facilitate provisioning of domain
names and other objects by registrars. The EPP Contact Mapping,
defined in <xref target="RFC5733"/>, provides a lightweight
structure to describe contact information such as name,
organization, postal and addresses, and voice and fax numbers.</t>
<t>This document describes a way to map the structure of contact
information described in RFC5733 into JSON, and also how this
representation can be used in RDAP entity objects instead of
jCard.</t>
<section title="Conventions Used in This Document">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="JSON Mapping of EPP Contact Objects">
<t>This mapping is limited to the attributes of contact objects
described in sections 2.3 - 2.6 of RFC 5733. Other attributes,
such as unique IDs, status codes, and event actions, are already
adequately mapped to generic RDAP object attributes.</t>
<t>An EPP contact object may be represented in JSON by
constructing a JSON object with the following properties:</t>
<t><list style="hanging">
<t hangText="postalInfo">this property is an object that
contains the postal address information.</t>
<t hangText="voice">this property is a string containing the
voice number.</t>
<t hangText="fax">this property is a string containing the
facsimile number.</t>
<t hangText="email">this property is a string containing the
email address.</t>
</list></t>
<t>The "voice", "fax" and "email" properties MAY be omitted or NULL,
but if present, MUST be valid as per the validation rules described
in the XML schema in RFC 5733.</t>
<section title="Postal Address Information">
<t>Every contact has associated postal-address information which
may be represented in either ASCII (for international use) or
UTF-8 (for domestic use).</t>
<t>The "postalInfo" property is an object with two properties:
"int" and "loc". These properties may contain postal information
or may either be omitted or NULL, but at least one MUST be
present and contain valid postal address information.</t>
<t>The postal address information in the "loc" object may
contain any valid UTF-8 sequence, but the data in the "int"
object MUST NOT contain any characters outside the ASCII range
(U+0000 - U+007F).</t>
<t>The "int" and "loc" properties are JSON objects which may
contain any of the following:</t>
<t><list style="hanging">
<t hangText="name">a string containing the contact name.</t>
<t hangText="org">a string containing the organization.</t>
<t hangText="addr">an object containing the following
properties:
<list style="hanging">
<t hangText="street">a JSON array containing between one
and three strings contain the street address.</t>
<t hangText="city">a string containing the city.</t>
<t hangText="sp">a string containing the state or
province.</t>
<t hangText="pc">a string containing the postal code.</t>
<t hangText="cc">the two-character country identifier
specified in ISO 3166.</t>
</list>
</t>
</list></t>
</section>
<section title="Example">
<t>The following is a JSON representation of the example contact
object shown in Section 3.1.2 of RFC 5733:</t>
<figure><artwork>
{
"postalInfo": {
"int": {
"name": "John Doe",
"org": "Example Inc.",
"addr": {
"street": [
"123 Example Dr.",
"Suite 100"
],
"city": "Dulles",
"sp": "VA",
"pc": "20166-6503",
"cc": "US",
},
},
"loc": NULL
},
"voice": "+1.7035555555x1234",
"fax": "+1.7035555556",
"email": "jdoe@example.com"
}
</artwork></figure>
</section>
</section>
<section title="Usage in RDAP">
<t>RDAP servers MAY use the contact object representation
described in this document in entity object instead of jCard.</t>
<t>RDAP servers which do so MUST add the "epp_entity_contact_info_level_0"
string to the "rdapConformance" array at the top-level of the RDAP
response. This string as has been registered with IANA.</t>
<t>In place of the "vCardArray" property, servers may then insert
an "eppContactInfo" property, whose value is a JSON object
described in this document.</t>
<section title="Example">
<t>The following is an example of an RDAP entity which uses the
EPP contact mapping instead of jCard:</t>
<figure><artwork>
{
"rdapConformance": [
"rdap_level_0",
"epp_entity_contact_info_level_0"
],
"objectClassName": "entity",
"handle": "SH8013-REP",
"eppContactInfo": {
"postalInfo": {
"int": {
"name": "John Doe",
"org": "Example Inc.",
"addr": {
"street": [
"123 Example Dr.",
"Suite 100"
],
"city": "Dulles",
"sp": "VA",
"pc": "20166-6503",
"cc": "US",
},
},
"loc": NULL
},
"voice": "+1.7035555555x1234",
"fax": "+1.7035555556",
"email": "jdoe@example.com"
},
// rest of entity
}
</artwork></figure>
</section>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>TODO.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>TODO.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4627;
&RFC5733;
&RFC7483;
</references>
<references title="Informative References">
&RFC6350;
&RFC7095;
</references>
</back>
</rfc>
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment