--- 1/draft-ietf-jmap-jscontact-vcard-07.txt 2021-12-01 02:13:19.918424357 -0800 +++ 2/draft-ietf-jmap-jscontact-vcard-08.txt 2021-12-01 02:13:19.982425959 -0800 @@ -1,19 +1,19 @@ jmap M. Loffredo Internet-Draft IIT-CNR/Registro.it Intended status: Standards Track R. Stepanek -Expires: 23 April 2022 FastMail - 20 October 2021 +Expires: 4 June 2022 FastMail + 1 December 2021 JSContact: Converting from and to vCard - draft-ietf-jmap-jscontact-vcard-07 + draft-ietf-jmap-jscontact-vcard-08 Abstract This document defines how to convert contact information as defined in the JSContact [draft-ietf-jmap-jscontact] specification from and to vCard. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,55 +22,55 @@ 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 23 April 2022. + This Internet-Draft will expire on 4 June 2022. Copyright Notice Copyright (c) 2021 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. 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. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope and Caveats . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Extensions . . . . . . . . . . . . . . . . . . . . . 4 1.3. Conventions Used in This Document . . . . . . . . . . . . 4 2. Translating vCard properties to JSContact . . . . . . . . . . 5 2.1. Common Parameters . . . . . . . . . . . . . . . . . . . . 5 2.2. Unmapped JSContact Information . . . . . . . . . . . . . 5 2.3. General Properties . . . . . . . . . . . . . . . . . . . 5 2.3.1. BEGIN and END . . . . . . . . . . . . . . . . . . . . 6 2.3.2. SOURCE . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.3. KIND . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.4. XML . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Identification Properties . . . . . . . . . . . . . . . . 7 2.4.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4.2. N and NICKNAME . . . . . . . . . . . . . . . . . . . 7 - 2.4.3. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.4.3. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.4. BDAY, BIRTHPLACE, DEATHDATE, DEATHPLACE, ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 9 2.4.5. GENDER . . . . . . . . . . . . . . . . . . . . . . . 11 2.5. Delivery Addressing Properties . . . . . . . . . . . . . 11 2.5.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6. Communications Properties . . . . . . . . . . . . . . . . 14 2.6.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . 15 2.6.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . 16 @@ -305,25 +305,26 @@ associated with the full name translations in various languages regardless of the presence of the ALTID parameter. Each translation is mapped according to the rules as defined in (Section 2.1). If the vCard represents a group of contacts, implementers MAY convert the FN property into either "CardGroup.card.fullName" or "CardGroup.name" or both properties. 2.4.2. N and NICKNAME - The N instances are converted into equivalent items of the "name" - array (Figure 3): the N components are transformed into related - "NameComponent" objects as presented in Table 1. Name components - SHOULD be ordered such that their values joined by whitespace produce - a valid full name of this entity. + The N instances are converted into equivalent items of the + "components" array of the "name" property (Figure 3): the N + components are transformed into related "NameComponent" objects as + presented in Table 1. Name components SHOULD be ordered such that + their values joined by whitespace produce a valid full name of this + entity. Each NICKNAME instance is mapped to an item of "nickNames" array. +====================+==============+ | N component | "type" value | +====================+==============+ | Honorific Prefixes | prefix | +--------------------+--------------+ | Given Names | personal | +--------------------+--------------+ @@ -341,27 +342,29 @@ ... FN:Mr. John Q. Public\, Esq. N:Public;John;Quinlan;Mr.;Esq. NICKNAME:Johnny ... END:VCARD { ... "fullName":{ "value": "Mr. John Q. Public, Esq." }, - "name":[ + "name":{ + "components":[ { "value":"Mr.", "type": "prefix" }, { "value":"John", "type": "personal" }, { "value":"Public", "type": "surname" }, { "value":"Quinlan", "type": "additional" }, { "value":"Esq.", "type": "suffix" } - ], + ] + }, "nickNames":[ { "value": "Johnny" } ], ... } Figure 3: FN, N, NICKNAME mapping example 2.4.3. PHOTO @@ -396,23 +399,23 @@ 2.4.4. BDAY, BIRTHPLACE, DEATHDATE, DEATHPLACE, ANNIVERSARY The BDAY and ANNIVERSARY properties and the extensions BIRTHPLACE, DEATHDATE, DEATHPLACE described in [RFC6350] are represented as "Anniversary" objects included in the "anniversaries" map (Figure 5): * BDAY and BIRTHPLACE are mapped to "date" and "place" where "type" is set to "birth"; * DEATHDATE and DEATHPLACE are mapped to "date" and "place" where "type" is set to "death"; - * ANNIVERSARY is mapped to "date" where "type" is set to "other" and - "label" is set to a value describing in detail the kind of - anniversary (e.g. "marriage date" for the wedding anniversary). + * ANNIVERSARY is mapped to "date" where "type" is empty and "label" + is set to a value describing in detail the kind of anniversary + (e.g. "marriage date" for the wedding anniversary). Both birth and death places are represented as instances of the "Address" object. The BIRTHPLACE and DEATHPLACE properties that are represented as geo URIs are converted into "Address" instances including only the "coordinates" member. If the URI value is not a geo URI, the place is ignored. The ALTID and LANGUAGE parameters of both BIRTHPLACE and DEATHPLACE @@ -445,28 +448,26 @@ "ANNIVERSARY-2" : { "type": "birth", "date": "1953-10-15T23:10:00Z", "place":{ "fullAddress":{ "value": "4445 Courtright Street\nNew England, ND 58647\nU.S.A." } } }, "ANNIVERSARY-3" : { - "type": "other", "label": "marriage date", "date": "1986-02-01" } }, ... } - Figure 5: BDAY, BIRTHPLACE, DEATHDATE, DEATHPLACE, ANNIVERSARY mapping example 2.4.5. GENDER The GENDER property doesn't have a direct match with a JSContact feature. 2.5. Delivery Addressing Properties @@ -578,23 +579,22 @@ Figure 6: ADR mapping example 2.6. Communications Properties 2.6.1. TEL A TEL property is represented as an entry of the "phones" map (Figure 7). The entry value is a "Phone" object. The TEL-specific values of the TYPE parameter are mapped to the "features" map keys. The values that don't match a key are represented as comma-separated - values of the "label" member. If the "features" map is empty and the - "label" member is not empty, the "other" feature is added. The - "phone" member is set to the TEL value. + values of the "label" member. The "phone" member is set to the TEL + value. The PREF and TYPE parameters are mapped according to the rules as defined in (Section 2.1). BEGIN:VCARD VERSION:4.0 ... TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555 TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67 ...