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

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.

1. Introduction

1.1. Conventions Used in This Document

2. JSON Mapping of EPP Contact Objects

2.1. Postal Address Information
2.2. Example

3. Usage in RDAP

3.1. Example

4. Privacy Considerations
5. IANA Considerations
6. References

6.1. Normative References
6.2. Informative References

Author's Address

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].

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:

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.

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.

5. IANA Considerations