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

Versions: 00 draft-harrison-regext-rdap-jcard-profile

Internet Engineering Task Force                              T. Harrison
Internet-Draft                                             G. Michaelson
Updates: 7483 (if approved)                                        APNIC
Intended status: Standards Track                            July 7, 2019
Expires: January 8, 2020


                           RDAP jCard Profile
                      draft-rdap-jcard-profile-00

Abstract

   The Registration Data Access Protocol (RDAP) is used by Regional
   Internet Registries (RIRs) and Domain Name Registries (DNRs) to
   provide access to their resource registration information.  RDAP uses
   jCard to convey information about individuals and other entities: for
   example, for the technical contact for a domain name.  In practice,
   server operators are only using a small subset of jCard's
   functionality, so in an effort to simplify the requirements on the
   client side, this document defines a jCard profile for use with RDAP.

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 January 8, 2020.

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



Harrison & Michaelson    Expires January 8, 2020                [Page 1]


Internet-Draft             RDAP jCard Profile                  July 2019


   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.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Profile Definition  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The Registration Data Access Protocol (RDAP) [RFC7480] is used by
   Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)
   to provide access to their resource registration information.  RDAP
   uses jCard ([RFC7095]) to convey information about individuals and
   other entities (e.g.  organisations and groups).  jCard is in turn a
   way of representing vCard ([RFC6350]) information in JSON.

   The core vCard specification defines 36 properties, 11 parameters, 12
   data types, and 31 parameter values.  More of each are defined in
   subsequent specifications (see the IANA vCard Elements registry).
   Due to the lack of supporting libraries for jCard, RDAP client
   developers often have to implement jCard support themselves, and
   handling the entire specification is a substantial burden.

   This document defines a jCard profile for use with RDAP that will
   reduce the implementation complexity for client developers.  The
   profile is primarily based on response data from the implementations
   that are currently included in the IANA RDAP bootstrap files.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].







Harrison & Michaelson    Expires January 8, 2020                [Page 2]


Internet-Draft             RDAP jCard Profile                  July 2019


2.  Profile Definition

   The following properties may be used in jCards included in RDAP
   responses:

      kind;

      fn;

      n;

      adr;

      tel;

      email;

      lang;

      geo;

      title;

      role;

      org;

      version; and

      contact-uri.

   Each jCard MUST contain a "kind" property.  The value of that
   property MUST be "individual", "group", or "org".

   A "geo" property MUST have a type of "uri".  A "tel" property MUST
   have a type of "uri" or "text".  A "lang" property MUST have a type
   of "language-tag".  A "contact-uri" property MUST have a type of
   "uri".  All other properties MUST have a type of "text".

   An "adr" property MUST include a "label" parameter, containing the
   content of the delivery address as a single string.

   Properties may include "language", "altid", and "pref" parameters.

   "email", "org" and "adr" properties may include a "type" parameter.
   The "type" parameter values that may be used are "work" and "home".





Harrison & Michaelson    Expires January 8, 2020                [Page 3]


Internet-Draft             RDAP jCard Profile                  July 2019


   A "tel" property may include a "type" parameter.  The "type"
   parameter values that may be used are those defined in [RFC6350].

   An "adr" property may include a "cc" parameter.  This parameter may
   be set even when the "country name" component of the property's value
   is not set.

   Properties, types, and parameters not expressly permitted by way of
   this profile MUST NOT be used.

3.  Operational Considerations

   An RDAP client that encounters a jCard that is not in conformance
   with this specification SHOULD treat the jCard as if any non-
   conforming properties, parameters, or types were not present.

   Various server implementations are currently using the non-standard
   "ISO-3166-1-alpha-2" property for the ISO-3166-1 alpha 2 country code
   of the country from the "adr" property in the jCard.  This behaviour
   appears to be based on guidance from section 1.4.1 of ICANN's current
   RDAP response profile ([ICANN-RDAP-PROFILE]).  However, that section
   states that it only applies when the "ISO-3166-1-alpha-2" property
   "has been published in the vCardProperties registry defined in
   Section 10.3.1 of RFC 6350", and that property has not yet been
   published in that way.

   Various server implementations are currently setting the "country
   name" component of the "adr" property to be the ISO-3166-1 alpha 2
   country code of the country.  This behaviour appears to be based on
   guidance from section 1.4.2 of ICANN's current RDAP response profile
   ([ICANN-RDAP-PROFILE]).  The "cc" parameter approach to this problem,
   defined in [RFC8605], is preferred in this profile.

4.  Security Considerations

   TBD

5.  IANA Considerations

   TBD

6.  References

6.1.  Normative References







Harrison & Michaelson    Expires January 8, 2020                [Page 4]


Internet-Draft             RDAP jCard Profile                  July 2019


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

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

6.2.  Informative References

   [ICANN-RDAP-PROFILE]
              ICANN, "RDAP Response Profile", February 2019,
              <https://www.icann.org/en/system/files/files/
              rdap-response-profile-15feb19-en.pdf>.

   [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
              Registration Data Access Protocol (RDAP)", RFC 7480,
              DOI 10.17487/RFC7480, March 2015,
              <https://www.rfc-editor.org/info/rfc7480>.

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

Authors' Addresses

   Tom Harrison
   Asia-Pacific Network Information Centre
   6 Cordelia St
   South Brisbane, QLD  4101
   Australia

   Email: tomh@apnic.net


   George G. Michaelson
   Asia-Pacific Network Information Centre
   6 Cordelia St
   South Brisbane, QLD  4101
   Australia

   Email: ggm@apnic.net



Harrison & Michaelson    Expires January 8, 2020                [Page 5]


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