[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/