idnits 2.17.1 draft-harrison-regext-rdap-jcard-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7483, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2019) is 1755 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Harrison 3 Internet-Draft G. Michaelson 4 Updates: 7483 (if approved) APNIC 5 Intended status: Standards Track July 7, 2019 6 Expires: January 8, 2020 8 RDAP jCard Profile 9 draft-harrison-regext-rdap-jcard-profile-00 11 Abstract 13 The Registration Data Access Protocol (RDAP) is used by Regional 14 Internet Registries (RIRs) and Domain Name Registries (DNRs) to 15 provide access to their resource registration information. RDAP uses 16 jCard to convey information about individuals and other entities: for 17 example, for the technical contact for a domain name. In practice, 18 server operators are only using a small subset of jCard's 19 functionality, so in an effort to simplify the requirements on the 20 client side, this document defines a jCard profile for use with RDAP. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 8, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 58 2. Profile Definition . . . . . . . . . . . . . . . . . . . . . 3 59 3. Operational Considerations . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 6.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 The Registration Data Access Protocol (RDAP) [RFC7480] is used by 70 Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) 71 to provide access to their resource registration information. RDAP 72 uses jCard ([RFC7095]) to convey information about individuals and 73 other entities (e.g. organisations and groups). jCard is in turn a 74 way of representing vCard ([RFC6350]) information in JSON. 76 The core vCard specification defines 36 properties, 11 parameters, 12 77 data types, and 31 parameter values. More of each are defined in 78 subsequent specifications (see the IANA vCard Elements registry). 79 Due to the lack of supporting libraries for jCard, RDAP client 80 developers often have to implement jCard support themselves, and 81 handling the entire specification is a substantial burden. 83 This document defines a jCard profile for use with RDAP that will 84 reduce the implementation complexity for client developers. The 85 profile is primarily based on response data from the implementations 86 that are currently included in the IANA RDAP bootstrap files. 88 1.1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 2. Profile Definition 96 The following properties may be used in jCards included in RDAP 97 responses: 99 kind; 101 fn; 103 n; 105 adr; 107 tel; 109 email; 111 lang; 113 geo; 115 title; 117 role; 119 org; 121 version; and 123 contact-uri. 125 Each jCard MUST contain a "kind" property. The value of that 126 property MUST be "individual", "group", or "org". 128 A "geo" property MUST have a type of "uri". A "tel" property MUST 129 have a type of "uri" or "text". A "lang" property MUST have a type 130 of "language-tag". A "contact-uri" property MUST have a type of 131 "uri". All other properties MUST have a type of "text". 133 An "adr" property MUST include a "label" parameter, containing the 134 content of the delivery address as a single string. 136 Properties may include "language", "altid", and "pref" parameters. 138 "email", "org" and "adr" properties may include a "type" parameter. 139 The "type" parameter values that may be used are "work" and "home". 141 A "tel" property may include a "type" parameter. The "type" 142 parameter values that may be used are those defined in [RFC6350]. 144 An "adr" property may include a "cc" parameter. This parameter may 145 be set even when the "country name" component of the property's value 146 is not set. 148 Properties, types, and parameters not expressly permitted by way of 149 this profile MUST NOT be used. 151 3. Operational Considerations 153 An RDAP client that encounters a jCard that is not in conformance 154 with this specification SHOULD treat the jCard as if any non- 155 conforming properties, parameters, or types were not present. 157 Various server implementations are currently using the non-standard 158 "ISO-3166-1-alpha-2" property for the ISO-3166-1 alpha 2 country code 159 of the country from the "adr" property in the jCard. This behaviour 160 appears to be based on guidance from section 1.4.1 of ICANN's current 161 RDAP response profile ([ICANN-RDAP-PROFILE]). However, that section 162 states that it only applies when the "ISO-3166-1-alpha-2" property 163 "has been published in the vCardProperties registry defined in 164 Section 10.3.1 of RFC 6350", and that property has not yet been 165 published in that way. 167 Various server implementations are currently setting the "country 168 name" component of the "adr" property to be the ISO-3166-1 alpha 2 169 country code of the country. This behaviour appears to be based on 170 guidance from section 1.4.2 of ICANN's current RDAP response profile 171 ([ICANN-RDAP-PROFILE]). The "cc" parameter approach to this problem, 172 defined in [RFC8605], is preferred in this profile. 174 4. Security Considerations 176 TBD 178 5. IANA Considerations 180 TBD 182 6. References 184 6.1. Normative References 186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 187 Requirement Levels", BCP 14, RFC 2119, 188 DOI 10.17487/RFC2119, March 1997, 189 . 191 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 192 DOI 10.17487/RFC6350, August 2011, 193 . 195 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 196 DOI 10.17487/RFC7095, January 2014, 197 . 199 6.2. Informative References 201 [ICANN-RDAP-PROFILE] 202 ICANN, "RDAP Response Profile", February 2019, 203 . 206 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 207 Registration Data Access Protocol (RDAP)", RFC 7480, 208 DOI 10.17487/RFC7480, March 2015, 209 . 211 [RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions: 212 ICANN Extensions for the Registration Data Access Protocol 213 (RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019, 214 . 216 Authors' Addresses 218 Tom Harrison 219 Asia-Pacific Network Information Centre 220 6 Cordelia St 221 South Brisbane, QLD 4101 222 Australia 224 Email: tomh@apnic.net 226 George G. Michaelson 227 Asia-Pacific Network Information Centre 228 6 Cordelia St 229 South Brisbane, QLD 4101 230 Australia 232 Email: ggm@apnic.net