idnits 2.17.1 draft-stepanek-jscontact-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2019) is 1681 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) -- Looks like a reference, but probably isn't: '1' on line 674 == Missing Reference: 'String' is mentioned on line 465, but not defined -- Looks like a reference, but probably isn't: '2' on line 676 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TBD R. Stepanek 3 Internet-Draft FastMail 4 Intended status: Standards Track M. Loffredo 5 Expires: March 15, 2020 IIT-CNR 6 September 12, 2019 8 JSContact: A JSON representation of addressbook data 9 draft-stepanek-jscontact-04 11 Abstract 13 This specification defines a data model and JSON representation of 14 contact card information that can be used for data storage and 15 exchange in address book or directory applications. It aims to be an 16 alternative to the vCard data format and to be unambiguous, 17 extendable and simple to process. In contrast to the JSON-based 18 jCard format, it is not a direct mapping from the vCard data model 19 and expands semantics where appropriate. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 15, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Relation to the xCard and jCard formats . . . . . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. JSCard . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Metadata properties . . . . . . . . . . . . . . . . . . . 4 60 2.1.1. uid . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1.2. prodId . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1.3. updated . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1.4. kind . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Name and Organization properties . . . . . . . . . . . . 5 65 2.2.1. name . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2.2. organization . . . . . . . . . . . . . . . . . . . . 5 67 2.2.3. jobTitle . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2.4. role . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.3. Contact and Resource properties . . . . . . . . . . . . . 6 70 2.3.1. emails . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.3.2. phones . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.3.3. online . . . . . . . . . . . . . . . . . . . . . . . 7 73 2.3.4. preferredContactMethod . . . . . . . . . . . . . . . 7 74 2.4. Address and Location properties . . . . . . . . . . . . . 7 75 2.4.1. addresses . . . . . . . . . . . . . . . . . . . . . . 7 76 2.5. Additional properties . . . . . . . . . . . . . . . . . . 9 77 2.5.1. anniversaries . . . . . . . . . . . . . . . . . . . . 9 78 2.5.2. personalInfo . . . . . . . . . . . . . . . . . . . . 9 79 2.5.3. notes . . . . . . . . . . . . . . . . . . . . . . . . 10 80 2.5.4. categories . . . . . . . . . . . . . . . . . . . . . 10 81 2.6. Common JSCard types . . . . . . . . . . . . . . . . . . . 10 82 2.6.1. LocalizedString . . . . . . . . . . . . . . . . . . . 10 83 2.6.2. Resource . . . . . . . . . . . . . . . . . . . . . . 10 84 3. JSCardGroup . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.1. Properties . . . . . . . . . . . . . . . . . . . . . . . 11 86 3.1.1. uid . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 3.1.2. name . . . . . . . . . . . . . . . . . . . . . . . . 11 88 3.1.3. cardIds . . . . . . . . . . . . . . . . . . . . . . . 11 89 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 90 4.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 12 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 95 7.2. Informative References . . . . . . . . . . . . . . . . . 14 96 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 100 1. Introduction 102 This document defines a data model for contact card data normally 103 used in address book or directory applications and services. It aims 104 to be an alternative to the vCard data format [RFC6350] and to 105 provide a JSON-based standard representation of contact card data. 107 The key design considerations for this data model are as follows: 109 o Most of the initial set of attributes should be taken from the 110 vCard data format [RFC6350] and extensions ([RFC6473], [RFC6474], 111 [RFC6715], [RFC6869], [RFC8605]). The specification should add 112 new attributes or value types, or not support existing ones, where 113 appropriate. Conversion between the data formats need not fully 114 preserve semantic meaning. 116 o The attributes of the cards data represented must be described as 117 a simple key-value pair, reducing complexity of its 118 representation. 120 o The data model should avoid all ambiguities and make it difficult 121 to make mistakes during implementation. 123 o Extensions, such as new properties and components, MUST NOT lead 124 to requiring an update to this document. 126 The representation of this data model is defined in the I-JSON format 127 [RFC7493], which is a strict subset of the JavaScript Object Notation 128 (JSON) Data Interchange Format [RFC8259]. Using JSON is mostly a 129 pragmatic choice: its widespread use makes JSCard easier to adopt, 130 and the availability of production-ready JSON implementations 131 eliminates a whole category of parser-related interoperability 132 issues. 134 1.1. Relation to the xCard and jCard formats 136 The xCard [RFC6351] and jCard [RFC7095] specifications define 137 alternative representations for vCard data, in XML and JSON format 138 respectively. Both explicitly aim to not change the underlying data 139 model. Accordingly, they are regarded as equal to vCard in the 140 context of this document. 142 1.2. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 2. JSCard 152 MIME type: "application/jscontact+json;type=jscard" 154 A JSCard object stores information about a person, organization or 155 company. 157 2.1. Metadata properties 159 2.1.1. uid 161 Type: "String" (mandatory). 163 An identifier, used to associate the object as the same across 164 different systems, addressbooks and views. [RFC4122] describes a 165 range of established algorithms to generate universally unique 166 identifiers (UUID), and the random or pseudo-random version is 167 recommended. For compatibility with [RFC6350] UIDs, implementations 168 MUST accept both URI and free-form text. 170 2.1.2. prodId 172 Type: "String" (optional). 174 The identifier for the product that created the JSCard object. 176 2.1.3. updated 178 Type: "String" (mandatory). 180 The date and time when the data in this JSCard object was last 181 modified. The timestamp MUST be formatted as specified in [RFC3339]. 183 2.1.4. kind 185 Type: "String" (optional). The kind of the entity the Card 186 represents. 188 The value MUST be either one of the following values, registered in a 189 future RFC, or a vendor-specific value: 191 o "individual": a single person 193 o "org": an organization 195 o "location": a named location 197 o "device": a device, such as appliances, computers, or network 198 elements 200 o "application": a software application 202 2.2. Name and Organization properties 204 2.2.1. name 206 Type: Name (mandatory). 208 The name of the entity represented by this JSCard. A Name object has 209 the following properties: 211 o fullName: "LocalizedString" (mandatory). The full name (e.g. the 212 personal name and surname of an individual, the name of an 213 organization) of the entity represented by this card. 215 o prefix: "String[]" (optional). The honorific title(s), e.g. 216 "Mr", "Ms", "Dr". 218 o personalName: "String[]" (optional). The personal name(s), also 219 known as "first name", "give name". 221 o surname: "String[]" (optional). The surname(s) (also known as 222 "last name", "family name"). 224 o additionalName: "String[]" (optional). The additional name(s), 225 also known as "middle name". 227 o suffix: "String[]" (optional). The honorific suffix(es), e.g. 228 "B.A.", "Esq.". 230 o nickname: "String[]" (optional). The nickname(s) of the person 231 represented by this card. 233 2.2.2. organization 235 Type: "LocalizedString[]" (optional). 237 The company or organization name and units associated with this card. 238 The first entry in the list names the organization, and any following 239 entries name organizational units. 241 2.2.3. jobTitle 243 Type : "LocalizedString[]" (optional). 245 The job title(s) or functional position(s) of the entity represented 246 by this card. 248 2.2.4. role 250 Type : "LocalizedString[]" (optional). 252 The role(s), function(s) or part(s) played in a particular situation 253 by the entity represented by this card. In contrast to a job title, 254 the roles might differ for example in project contexts. 256 2.3. Contact and Resource properties 258 2.3.1. emails 260 Type: "Resource[]" (optional). 262 An array of Resource objects where the values are URLs in the 263 [RFC6068] "mailto" scheme or free-text email addresses. Types are: 265 o "personal" The address is for emailing in a personal context. 267 o "work" The address is for emailing in a professional context. 269 o "other" The address is for some other purpose. A label property 270 MAY be included to display next to the address to help the user 271 identify its purpose. 273 2.3.2. phones 275 Type: "Resource[]" (optional). 277 An array of Resource objects where the values are URIs scheme or 278 free-text phone numbers. Typical URI schemes are the [RFC3966] "tel" 279 or [RFC3261] "sip" schemes, but any URI scheme is allowed. Resource 280 types are: 282 o "voice" The number is for calling by voice. 284 o "fax" The number is for sending faxes. 286 o "pager" The number is for a pager or beeper. 288 o "other" The number is for some other purpose. A label property 289 MAY be included to display next to the number to help the user 290 identify its purpose. 292 The following labels are pre-defined for phone resources: 294 o "private" The phone number should be used in a private context. 296 o "work" The phone number should be used in a professional context 298 2.3.3. online 300 Type: "Resource[]" (optional). 302 An array of Resource objects where the values are URIs or usernames 303 associated with the card for online services. Types are: 305 o "uri" The value is a URI, e.g. a website link. 307 o "username" The value is a username associated with the entity 308 represented by this card (e.g. for social media, or an IM client). 309 A label property SHOULD be included to identify what service this 310 is for. For compatibility between clients, this label SHOULD be 311 the canonical service name, including capitalisation. e.g. 312 "Twitter", "Facebook", "Skype", "GitHub", "XMPP". 314 o "other" The value is something else not covered by the above 315 categories. A label property MAY be included to display next to 316 the number to help the user identify its purpose. 318 2.3.4. preferredContactMethod 320 Type : "String" (optional) 322 Defines the preferred contact method or resource with additional 323 information about this card. The value MUST be the property name of 324 one of the Resource lists: "emails", "phones", "online", "other". 326 2.4. Address and Location properties 328 2.4.1. addresses 330 Type: Address[] (optional). 332 An array of Address objects, containing physical locations. An 333 Address object has the following properties: 335 o type: "String" (mandatory). Specifies the context of the address 336 information. The value MUST be either one of the following 337 values, registered in a future RFC, or a vendor-specific value: 339 * "home" An address of a residence. 341 * "work" An address of a workplace. 343 * "billing" An address to be used for billing. 345 * "postal" An address to be used for delivering physical items. 347 * "other" An address not covered by the above categories. 349 o label: "String" (optional). A label describing the value in more 350 detail. 352 o fullAddress: "LocalizedString" (optional). The complete address, 353 excluding type and label. This property is mainly useful to 354 represent addresses of which the individual address components are 355 unknown, or to provide localized representations. 357 o street: "String" (optional). The street address. This MAY be 358 multiple lines; newlines MUST be preserved. 360 o extension: "String" (optional) The extended address, such as an 361 apartment or suite number, or care-of address. 363 o locality: "String" (optional). The city, town, village, post 364 town, or other locality within which the street address may be 365 found. 367 o region: "String" (optional). The province, such as a state, 368 county, or canton within which the locality may be found. 370 o country: "String" (optional). The country name. 372 o postOfficeBox: "String" (optional) The post office box. 374 o postcode: "String" (optional). The postal code, post code, ZIP 375 code or other short code associated with the address by the 376 relevant country's postal system. 378 o countryCode: "String" (optional). The ISO-3166-1 country code. 380 o coordinates: "String" (optional) A [RFC5870] "geo:" URI for the 381 address. 383 o timeZone: "String" (optional) Identifies the time zone this 384 address is located in. This SHOULD be a time zone name registered 385 in the IANA Time Zone Database [1]. Unknown time zone identifiers 386 MAY be ignored by implementations. 388 o isPreferred: Boolean (optional, default: false). Whether this 389 Address is the preferred for its type. This SHOULD only be one 390 per type. 392 2.5. Additional properties 394 2.5.1. anniversaries 396 Type : Anniversary[] (optional). 398 Memorable dates and events for the entity represented by this card. 399 An Anniversary object has the following properties: 401 o type: "String" (mandatory). Specifies the type of the 402 anniversary. This RFC predefines the following types, but 403 implementations MAY use additional values: 405 * "birth": a birth day anniversary 407 * "death": a death day anniversary 409 * "other": an anniversary not covered by any of the known types. 411 o date: "String" (mandatory). The date of this anniversary, in the 412 form "YYYY-MM-DD" (any part may be all 0s for unknown) or a 413 [RFC3339] timestamp. 415 o place: Address (optional). An address associated with this 416 anniversary, e.g. the place of birth or death. 418 2.5.2. personalInfo 420 Type: PersonalInformation[] (optional). 422 A list of personal information about the entity represented by this 423 card. A PersonalInformation object has the following properties: 425 o type: "String" (mandatory). Specifies the type for this personal 426 information. Allowed values are: 428 * "expertise": a field of expertise or credential 430 * "hobby": a hobby 431 * "interest": an interest 433 * "other": an information not covered by the above categories 435 o value: "String" (mandatory). The actual information. This 436 generally is free-text, but future specifications MAY restrict 437 allowed values depending on the type of this PersonalInformation. 439 o level: "String" (optional) Indicates the level of expertise, or 440 engagement in hobby or interest. Allowed values are: "high", 441 "medium" and "low". 443 2.5.3. notes 445 Type: "LocalizedString[]" (optional). 447 Arbitrary notes about the entity represented by this card. 449 2.5.4. categories 451 Type: "String[]" (optional). A list of free-text or URI categories 452 that relate to the card. 454 2.6. Common JSCard types 456 2.6.1. LocalizedString 458 A LocalizedString object has the following properties: 460 o value: "String" (mandatory). The property value. 462 o language: "String" (optional). The [RFC5646] language tag of this 463 value, if any. 465 o localizations: "String[String]" (optional). A map from [RFC5646] 466 language tags to the value localized in that language. 468 2.6.2. Resource 470 A Resource object has the following properties: 472 o type: "String" (mandatory). Specifies the context of the 473 resource. This MUST be taken from the set of values specified for 474 the respective property. 476 o label: "String" (optional). A label describing the value in more 477 detail, especially if the type property has value "other" (but MAY 478 be included with any type). 480 o value: "String" (mandatory). The actual resource value, e.g. an 481 email address or phone number. 483 o mediaType: "String" (optional). Used for properties with URI 484 values. Provides the media type [RFC2046] of the resource 485 identified by the URI. 487 o isPreferred: Boolean (optional, default: false). Whether this 488 resource is the preferred for its type. This SHOULD only be one 489 per type. 491 3. JSCardGroup 493 MIME type: "application/jscontact+json;type=jscardgroup" 495 A JSCardGroup object represents a named set of JSCards. 497 3.1. Properties 499 3.1.1. uid 501 Type : "String" (mandatory). 503 A globally unique identifier. The same requirements as for the 504 JSCard uid property apply. 506 3.1.2. name 508 Type: "String" (optional). 510 The user-visible name for the group, e.g. "Friends". This may be 511 any UTF-8 string of at least 1 character in length and maximum 255 512 octets in size. The same name may be used by two different groups. 514 3.1.3. cardIds 516 Type : "String[]" (mandatory). The ids of the cards in the group. 517 Implementations MUST preserve the order of list entries. 519 4. Implementation Status 521 NOTE: Please remove this section and the reference to [RFC7942] prior 522 to publication as an RFC. This section records the status of known 523 implementations of the protocol defined by this specification at the 524 time of posting of this Internet-Draft, and is based on a proposal 525 described in [RFC7942]. The description of implementations in this 526 section is intended to assist the IETF in its decision processes in 527 progressing drafts to RFCs. Please note that the listing of any 528 individual implementation here does not imply endorsement by the 529 IETF. Furthermore, no effort has been spent to verify the 530 information presented here that was supplied by IETF contributors. 531 This is not intended as, and must not be construed to be, a catalog 532 of available implementations or their features. Readers are advised 533 to note that other implementations may exist. According to 534 [RFC7942], "this will allow reviewers and working groups to assign 535 due consideration to documents that have the benefit of running code, 536 which may serve as evidence of valuable experimentation and feedback 537 that have made the implemented protocols more mature. It is up to 538 the individual working groups to use this information as they see 539 fit". 541 4.1. IIT-CNR/Registro.it 543 o Responsible Organization: Institute of Informatics and Telematics 544 of National Research Council (IIT-CNR)/Registro.it 546 o Location: https://rdap.pubtest.nic.it/ [2] 548 o Description: This implementation includes support for RDAP queries 549 using data from the public test environment of .it ccTLD. The 550 RDAP server does not implement any security policy because data 551 returned by this server are only for experimental testing 552 purposes. The RDAP server returns responses including JSCard in 553 place of jCard when queries contain the parameter jscard=1. 555 o Level of Maturity: This is a "proof of concept" research 556 implementation. 558 o Coverage: This implementation includes all of the features 559 described in this specification. 561 o Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it 563 5. IANA Considerations 565 TBD 567 6. Security Considerations 569 TBD 571 7. References 572 7.1. Normative References 574 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 575 Extensions (MIME) Part Two: Media Types", RFC 2046, 576 DOI 10.17487/RFC2046, November 1996, 577 . 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, 581 DOI 10.17487/RFC2119, March 1997, 582 . 584 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 585 Unique IDentifier (UUID) URN Namespace", RFC 4122, 586 DOI 10.17487/RFC4122, July 2005, 587 . 589 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 590 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 591 September 2009, . 593 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 594 Identifier for Geographic Locations ('geo' URI)", 595 RFC 5870, DOI 10.17487/RFC5870, June 2010, 596 . 598 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 599 DOI 10.17487/RFC6350, August 2011, 600 . 602 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 603 RFC 6351, DOI 10.17487/RFC6351, August 2011, 604 . 606 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 607 DOI 10.17487/RFC7095, January 2014, 608 . 610 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 611 DOI 10.17487/RFC7493, March 2015, 612 . 614 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 615 Code: The Implementation Status Section", BCP 205, 616 RFC 7942, DOI 10.17487/RFC7942, July 2016, 617 . 619 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 620 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 621 May 2017, . 623 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 624 Interchange Format", STD 90, RFC 8259, 625 DOI 10.17487/RFC8259, December 2017, 626 . 628 7.2. Informative References 630 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 631 A., Peterson, J., Sparks, R., Handley, M., and E. 632 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 633 DOI 10.17487/RFC3261, June 2002, 634 . 636 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 637 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 638 . 640 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 641 RFC 3966, DOI 10.17487/RFC3966, December 2004, 642 . 644 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 645 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 646 . 648 [RFC6473] Saint-Andre, P., "vCard KIND:application", RFC 6473, 649 DOI 10.17487/RFC6473, December 2011, 650 . 652 [RFC6474] Li, K. and B. Leiba, "vCard Format Extensions: Place of 653 Birth, Place and Date of Death", RFC 6474, 654 DOI 10.17487/RFC6474, December 2011, 655 . 657 [RFC6715] Cauchie, D., Leiba, B., and K. Li, "vCard Format 658 Extensions: Representing vCard Extensions Defined by the 659 Open Mobile Alliance (OMA) Converged Address Book (CAB) 660 Group", RFC 6715, DOI 10.17487/RFC6715, August 2012, 661 . 663 [RFC6869] Salgueiro, G., Clarke, J., and P. Saint-Andre, "vCard 664 KIND:device", RFC 6869, DOI 10.17487/RFC6869, February 665 2013, . 667 [RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions: 668 ICANN Extensions for the Registration Data Access Protocol 669 (RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019, 670 . 672 7.3. URIs 674 [1] https://www.iana.org/time-zones 676 [2] https://rdap.pubtest.nic.it/ 678 Authors' Addresses 680 Robert Stepanek 681 FastMail 682 PO Box 234, Collins St West 683 Melbourne VIC 8007 684 Australia 686 Email: rsto@fastmailteam.com 688 Mario Loffredo 689 IIT-CNR 690 Via Moruzzi,1 691 Pisa 56124 692 Italy 694 Email: mario.loffredo@iit.cnr.it