Internet Engineering Task Force (IETF) M. Loffredo Request for Comments: 9555 IIT-CNR/Registro.it Updates: 6350 R. Stepanek Category: Standards Track Fastmail ISSN: 2070-1721MarchMay 2024 JSContact: Converting from and to vCard Abstract This document defines how to convert contact information between the JSContact and vCard data formats.To achieve this, it updates [RFC9553] ("JSContact: A JSON RepresentationIt defines conversion rules for every JSContact and vCard element registered at IANA at the time ofContact Data") by registeringpublication. It also defines new JSContactproperties. Similarly, it updates RFC 6350 ("vCard Format Specification") by registering newproperties as well as vCard properties andparameters.parameters, to support converting arbitrary or unknown JSContact and vCard elements. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9555. Copyright Notice Copyright (c) 2024 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 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction 1.1. Motivation 1.2. Notational Conventions 1.3. ABNF Notations 2. Converting vCard to JSContact 2.1. General Rules 2.1.1. The Card uid Property 2.1.2. Choosing Identifiers 2.2. vCard Value Data Types 2.2.1. BOOLEAN 2.2.2. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP 2.2.3. INTEGER 2.2.4. FLOAT 2.2.5. LANGUAGE-TAG 2.2.6. TEXT 2.2.7. URI 2.2.8. UTC-OFFSET 2.3. vCard Parameters 2.3.1. ALTID 2.3.2. AUTHOR 2.3.3. AUTHOR-NAME 2.3.4. CALSCALE 2.3.5.CREATEDCC 2.3.6.DERIVEDCREATED 2.3.7.GEODERIVED 2.3.8.GROUPGEO 2.3.9.INDEXGROUP 2.3.10.LANGUAGEINDEX 2.3.11.LEVELLANGUAGE 2.3.12.MEDIATYPELABEL 2.3.13.PHONETICLEVEL 2.3.14.PIDMEDIATYPE 2.3.15.PREFPHONETIC 2.3.16.PROP-IDPID 2.3.17.SCRIPTPREF 2.3.18.SERVICE-TYPEPROP-ID 2.3.19.SORT-ASSCRIPT 2.3.20.TYPESERVICE-TYPE 2.3.21.TZSORT-AS 2.3.22.USERNAMETYPE 2.3.23. TZ 2.3.24. USERNAME 2.3.25. VALUE 2.4. General Properties 2.4.1. BEGIN and END 2.4.2. KIND 2.4.3. SOURCE 2.4.4. XML 2.5. Identification Properties 2.5.1. ANNIVERSARY, BDAY, BIRTHPLACE, DEATHDATE,DEATHPLACE,andANNIVERSARYDEATHPLACE 2.5.2. FN 2.5.3. GENDER 2.5.4. GRAMGENDER and PRONOUNS 2.5.5. N 2.5.6. NICKNAME 2.5.7. PHOTO 2.6. Delivery Addressing Properties 2.6.1. ADR 2.7. Communications Properties 2.7.1. EMAIL 2.7.2. IMPP 2.7.3. LANG 2.7.4. LANGUAGE 2.7.5. SOCIALPROFILE 2.7.6. TEL 2.8. Geographical Properties 2.8.1. GEO 2.8.2. TZ 2.8.3. Combining Geographical Properties 2.9. Organizational Properties 2.9.1. CONTACT-URI 2.9.2. LOGO 2.9.3. MEMBER 2.9.4. ORG 2.9.5. RELATED 2.9.6. TITLE and ROLE 2.10. Personal Information Properties 2.10.1. EXPERTISE 2.10.2. HOBBY 2.10.3. INTEREST 2.10.4. ORG-DIRECTORY 2.11. Explanatory Properties 2.11.1. CATEGORIES 2.11.2. CLIENTPIDMAPand PID Parameters2.11.3. CREATED 2.11.4. NOTE 2.11.5. PRODID 2.11.6. REV 2.11.7. SOUND 2.11.8. UID 2.11.9. URL 2.11.10. VERSION 2.11.11. X-ABLabel 2.12. Security Properties 2.12.1. KEY 2.13. Calendar Properties 2.13.1. CALADRURI 2.13.2. CALURI 2.13.3. FBURL 2.14. Extended Properties and Parameters 2.15. New JSContact Properties 2.15.1.PropertyvCardProps 2.15.2.PropertyvCardParams 2.15.3.PropertyvCardName 3. Converting JSContact to vCard 3.1. Conversion Rules 3.1.1. Converting Unknown Properties 3.2. New vCard Properties 3.2.1. JSPROP 3.3. New vCard Parameters 3.3.1. JSCOMPS 3.3.2. JSPTR 4. Security Considerations 5. IANA Considerations 5.1. New vCard Property 5.2. New vCard Parameter 5.3. New JSContact Properties 5.4. New JSContact Type 6. References 6.1. Normative References 6.2. Informative References Appendix A. Reverse Rules of Converting a vCard to a JSContact Card Acknowledgements Authors' Addresses 1. Introduction 1.1. Motivation The JSContact data model and format [RFC9553] aims to be an alternative to the widely used vCard standard [RFC6350] and jCard format [RFC7095]. While applications might prefer JSContact to exchange contact card data with other systems, they are likely to interoperate with services and clients that only support vCard or jCard. Similarly, existing contact data providers and consumers already using vCard or jCard might also want to represent their contact data in JSContact. To achieve this, this document defines standard rules to convert contact data between JSContact and vCard (and consequently jCard). 1.2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. ABNF Notations The ABNF definitions in this document use the notations of [RFC5234]. ABNF rules not defined in this document are defined in either [RFC5234] (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT) or [RFC6350]. 2. Converting vCard to JSContact This section contains the conversion rules from the vCard to the JSContact Card. It follows the same structure as vCard v4 [RFC6350]. Properties and parameters of vCard extension RFCs, including those described in "vCard Format Extension for JSContact" [RFC9554], have been added to the appropriate subsections. 2.1. General Rules 2.1.1. The Card uid Property The UID property (Section 6.7.6 of [RFC6350]) in vCard is optional, but the Card object's uid propertyin JSContact(Section 2.1.9 of [RFC9553]) is mandatory. Implementations that convert a vCard without a UID property MUST generate a unique identifier asavalue for the uid property. This value SHOULD be the same when converting the same vCard multiple times, but how to achieve this is implementation- specific. 2.1.2. Choosing Identifiers Multivalued properties in JSContact are typically represented as a JSON object where the object keys are of the Id type (Section 1.4.1 of [RFC9553]) and the object values are the converted vCard property. In the absence of thePROP- IDPROP-ID parameter (see Section2.3.16),2.3.18), implementations are free to choose any identifier as key for such entries. Whatever identifier generation scheme implementations use, they MUST generate values that are valid according to the definition of the Id type in [RFC9553]. For example, this could be an incrementing number across allIdsidentifier keys in the Card object or only unique within one JSON object. 2.2. vCard Value Data Types 2.2.1. BOOLEAN The BOOLEAN type (Section 4.4 of [RFC6350]) converts to the JSContact Booleantype.type (Section 1.3.2 of [RFC9553]). 2.2.2. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP The TIMESTAMP typegenerally(Section 4.3.5 of [RFC6350]) converts to the UTCDateTimetype. Ittype (Section 1.4.5 of [RFC9553]), except for anniversaries. For anniversaries, it converts to the Timestamp typefor anniversaries.(Section 2.8.1 of [RFC9553]). The DATE type (Section 4.3.1 of [RFC6350]) converts tothea PartialDatetype, which is only relevantobject (Section 2.8.1 of [RFC9553]) when used foranniversaries. This does not apply toan anniversary, unless the DATEvalues thatvalue onlydefinecontains a month orday. The TIME, DATE-TIME, and DATE-AND-OR-TIME types and DATE type values that only defineamonth orday (but not both). The following temporal types do not convert to a JSContact datetime type. Instead, vCard properties or parameters having suchvaluesvalue types convertto the propertiesas defined in Section 2.15. * TIME (Section 4.3.2 of [RFC6350]) * DATE-TIME (Section 4.3.3 of [RFC6350]) * DATE-AND-OR-TIME (Section 4.3.4 of [RFC6350]) * DATE type values that only define a month or day (but not both) 2.2.3. INTEGER The INTEGER type (Section 4.5 of [RFC6350]) converts to the JSContact Int and UnsignedInttypes.types (Section 1.4.2 of [RFC9553]). 2.2.4. FLOAT The FLOAT type (Section 4.6 of [RFC6350]) converts to the JSContact Numbertype.type (Section 1.3.2 of [RFC9553]). 2.2.5. LANGUAGE-TAG The LANGUAGE-TAG type (Section 4.8 of [RFC6350]) converts to the JSContact Stringtype.type (Section 1.3.2 of [RFC9553]). The value MUST be a language tag as defined in [RFC5646]. 2.2.6. TEXT The TEXT type (Section 4.1 of [RFC6350]) converts to the JSContact Stringtype.type (Section 1.3.2 of [RFC9553]). 2.2.7. URI The URI type (Section 4.2 of [RFC6350]) converts to the JSContact Stringtype.type (Section 1.3.2 of [RFC9553]). The value MUST be a URI as defined in Section 3 of [RFC3986] 2.2.8. UTC-OFFSET The UTC-OFFSET type (Section 4.7 of [RFC6350]) either converts to a String value containing an IANA Time Zone Database entry name (see Section 2.8.2) or does not convert to any JSContact type. For the latter, vCard properties or parameters having such valuesMAYconvertto JSContactas defined in Section 2.15. 2.3. vCard Parameters This section contains the conversion rules for vCard parameters. A rule typically applies only for specific vCard properties. To convert a vCard parameter on an arbitrary vCard property, see Section 2.15.2. 2.3.1. ALTID The ALTID parameter (Section 5.4 of [RFC6350]) does not convert to an IANA-registered property in JSContact, but several conversion rules make use of this parameter to combine multiple vCard properties into a single JSContact object instance. For an example of this, see Section 2.6.1. To preserve the verbatim value of the ALTID parameter, set the JSContact properties defined in Section 2.15. 2.3.2. AUTHOR The AUTHOR parametervalue(Section 4.1 of [RFC9554]) on avCardNOTE property converts to the Author object's uri property (Section 2.8.3 ofthe[RFC9553]). That Author objectfor this note. Note: This parameterisdefined in [RFC9554].set as the value of the Note object's author property (Section 2.8.3 of [RFC9553]). 2.3.3. AUTHOR-NAME The AUTHOR-NAME parametervalue(Section 4.2 of [RFC9554]) on avCardNOTE property converts to the Author object's name property (Section 2.8.3 ofthe[RFC9553]). That Author objectfor this note. Note: This parameterisdefined in [RFC9554].set as the value of the Note object's author property. 2.3.4. CALSCALE The CALSCALE parameter (Section 5.8 of [RFC6350]) set on a BDAY, DEATHDATE, or ANNIVERSARY property converts to the PartialDate object's calendarScale property (Section 2.8.1 ofthe PartialDate object type.[RFC9553]). 2.3.5. CC The CC parameter (Section 3.1 of [RFC8605]) on an ADR property converts to the Address object's countryCode property (Section 2.5.1.1 of [RFC9553]). 2.3.6. CREATED The CREATED parametervalue(Section 4.3 of [RFC9554]) on avCardNOTE property converts to the Note object's created property (Section 2.8.3 ofthe Note object. Note: This parameter is defined in [RFC9554]. 2.3.6.[RFC9553]). 2.3.7. DERIVED The DERIVED parameter (Section 4.4 of [RFC9554]) does not convert to JSContact. If the DERIVED parameter is set totrue"true" on a vCard property, then implementations MAY choose not to convert that property.Note: This parameter is defined in [RFC9554]. 2.3.7.2.3.8. GEO The GEO parameter (Section 5.10 of [RFC6350]) set on an ADR property converts to theJSContactAddress object's coordinates property (Section 2.5.1.1 ofthe Address object that represents the vCard ADR. 2.3.8.[RFC9553]). 2.3.9. GROUP The GROUP parameteris(Section 7.1 of [RFC7095]) does not convert to JSContact. It exclusively is for use in jCard(see Section 7.1 of [RFC7095]). Itand MUST NOT be set in a vCard. Preserving the exact group name when converting from vCard to JSContact and back to vCard is not necessary. Any group identifiers will do, as long as the resulting vCard groups its properties equally to the original vCard. Implementations that still wish to preserve the exact property group name of a vCard property MAY set thegroupjCard "group" parameter in the JSContact properties vCardProps or vCardParams as defined in Section 2.15. item1.TEL;VALUE=uri:tel:+1-555-555-5555 "phones": { "p1": { "number": "tel:+1-555-555-5555", "vCardParams" : { "group" : "item1" } } } Figure 1: Example of How to Preserve the Group Name in vCardParams during Conversion item2.X-FOO:bar "vCardProps": [ ["x-foo", { "group": "item2" }, "unknown", "bar"] ] Figure 2: Example of How to Preserve the Group Name in vCardProps during Conversion2.3.9.2.3.10. INDEX The INDEX parameter (Section 3.1 of [RFC6715]) set on the EXPERTISE, HOBBY, INTEREST, andORG- DIRECTORYORG-DIRECTORY propertiesdefined in [RFC6715]converts to theJSContact listAs property of thePersonalInfo (Section 2.8.4 of [RFC9553]) and Directoryobjects. 2.3.10.(Section 2.6.2 of [RFC9553]) objects' listAs property. 2.3.11. LANGUAGE The LANGUAGE parameter (Section 5.1 of [RFC6350]) converts to an entry in the Card object's localizations property (Section 2.7.1 of [RFC9553]) forthethat vCard propertythaton which this parameter is set on. The value of the LANGUAGE parameter defines the language tag key in the localizations property. This specification does not define a single standard conversion rule for how to convert the property values. Instead, building the localizations value is implementation-specific. Two options to populate the localizations property are: * One Patch per Property: For each vCard property with a LANGUAGE parameter, set the complete path in the PatchObject to the JSContact property that the vCard property converts to. The value of the patch is the converted property value. This is simple to process and adequate if the vCard only contains a few properties with the LANGUAGE parameter. * Bundle Patches by Parent: If a PatchObject contains multiple paths that have the same parent paths, then it might be possible to combine these patches into one patch that patches the parent property. This is possible if the property in the Card is patched in its entirety. Generally, localizations only localize properties that are present in the non-localized version of this Card. Figure 3 illustrates this. FN;LANGUAGE=EN:John DoeTITLE;LANGUAGE=EN:Boss TITLE;LANGUAGE=fr:PatronTITLE;ALTID=1;LANGUAGE=EN:Boss TITLE;ALTID=1;LANGUAGE=fr:Patron "language": "en", "name": { "full": "John Doe" }, "titles": { "t1": { "name": "Boss" } }, "localizations": { "fr": { "titles/t1/name": "Patron" } } Figure 3: LANGUAGE Conversion Example: One Dominant Language As a special case, if one or more vCard properties of the same type do not have the LANGUAGE parameter set,then chooseadd them to thenon- localizednon-localized Card. Convert any with LANGUAGE parameters to the localizations property. Figure 4 illustrates this. FN:John DoeTITLE:Boss TITLE;LANGUAGE=fr:PatronTITLE;ALTID=1:Boss TITLE;ALTID=1;LANGUAGE=fr:Patron "name": { "full": "John Doe" }, "titles": { "t1": { "name": "Boss" } }, "localizations": { "fr": { "titles/t1/name": "Patron" } } Figure 4: LANGUAGE Conversion Example: Property without LanguageAs the least-preferred option, Figure 5 illustrates how all vCard properties of the same type have the LANGUAGE2.3.12. LABEL The LABEL parameterset, but none of their language tags match the language(Section 6.3.1 ofthe main Card. In this case, implementations MAY choose to add the localized vCard properties only[RFC6350]) on an ADR property converts to thelocalizations object. The following example uses non-ASCII characters to demonstrate multilingual content. LANGUAGE:es FN:Gabriel García Márquez TITLE;LANGUAGE=en:Novelist TITLE;LANGUAGE=fr:Écrivain "language": "es", "name" { "full": "Gabriel García Márquez" }, "localizations": { "en": { "titles": { "t1": { "name": "Novelist" } }, "fr": { "titles": { "t1": { "name": "Écrivain" } } } Figure 5: LANGUAGE Conversion Example: Conflicting LANGUAGE Property and Parameter Values 2.3.11.Address object's full property (Section 2.5.1.1 of [RFC9553]). 2.3.13. LEVEL The LEVEL parameter[RFC6715](Section 3.2 of [RFC6715]) converts to the PersonalInfo object's level property (Section 2.8.4 ofthe PersonalInfo type.[RFC9553]). If this parameter is set on the EXPERTISE property, then its values convert as follows: * "beginner" converts to "low"; * "average" converts to "medium"; and * "expert" converts to "high". In all other cases, the values convert verbatim, but lowercase MUST be used for the JSContact value.2.3.12.2.3.14. MEDIATYPE The MEDIATYPE parameter (Section 5.7 of [RFC6350]) converts to the Resource object's mediaType property (Section 1.4.4 ofthe Resource object type. 2.3.13.[RFC9553]). 2.3.15. PHONETIC The PHONETIC parameteras well as the SCRIPT(Section2.3.17) parameter set on an N or ADR property convert4.6 of [RFC9554]) converts toJSContact as follows:thevaluesName (Section 2.2.1 ofthe phonetic, phoneticScript[RFC9553]) and Address (Section 2.5.1 of [RFC9553]) objects' phoneticSystempropertiesproperty unless the parameter value is "script", in which case the phoneticSystem property is not set. The value of theNameComponent and Name or AddressComponent and Address object types, respectively.SCRIPT parameter converts to the phoneticScript property (see Section 2.3.19). The related N or ADR property is defined by the vCard ALTID parameter. The conversion rules for the N (Section 2.5.5) and ADR (Section 2.6.1) properties define how the vCard components convert to JSContact. Thevaluecomponent values of thePHONETIC parameter converts to the phoneticSystempropertyunless it is script, inon whichcase the phoneticSystem property is not set. The value oftheSCRIPTPHONETIC parameterconverts to the phoneticScript property. The values of the components in the property valueis set convert tovalues in the phonetic properties forthe respective NameComponent orAddressComponent.AddressComponent objects' phonetic properties. If more than one property has the PHONETIC parameter set and relates to the same property, then they convert to the Card object's localizations property according to their LANGUAGE parameter values as outlined in Section2.3.10.2.3.11. LANGUAGE=zh-Hant N;ALTID=1;LANGUAGE=zh-Hant:孫;中山;文,逸仙;; N;ALTID=1;PHONETIC=jyut; SCRIPT=Latn;LANGUAGE=yue:syun1;zung1saan1;man4,jat6sin1;; "language": "zh-Hant", "name": { "components": [ { "kind": "surname", "value": "孫" }, { "kind": "given", "value": "中山" }, { "kind": "given2", "value": "文" }, { "kind": "given2", "value": "逸仙" } ] }, "localizations": { "yue": { "name/phoneticSystem": "jyut", "name/phoneticScript": "Latn", "name/components/0/phonetic": "syun1", "name/components/1/phonetic": "zung1saan1", "name/components/2/phonetic": "man4", "name/components/3/phonetic": "jat6sin1" } } Figure6:5: PHONETIC Conversion Example2.3.14.2.3.16. PID The PID parameter (Section 5.5 of [RFC6350]) converts toan entry inthe vCardParams property; see Section 2.15.2.2.3.15.2.3.17. PREF The PREF parameter (Section 5.3 of [RFC6350]) converts to the prefproperty. 2.3.16.property of the derived JSContact object. 2.3.18. PROP-ID The PROP-ID parametervalue(Section 4.7 ofa vCard property[RFC9554]) converts to theIdId- typed key of the derived JSContactproperty to which the vCard property converts.object. TEL;PROP-ID=PHONE-A;VALUE=uri;PREF=1;TYPE="voice,home" :tel:+1-555-555-5555;ext=5555 TEL;PROP-ID=PHONE-B;VALUE=uri;TYPE=home :tel:+33-01-23-45-67 "phones": { "PHONE-A": { "contexts": { "private": true }, "features": { "voice": true }, "number": "tel:+1-555-555-5555;ext=5555", "pref": 1 }, "PHONE-B": { "contexts": { "private": true }, "number": "tel:+33-01-23-45-67" } } Figure7:6: PROP-ID Conversion ExampleNote: This parameter is defined in [RFC9554]. 2.3.17.2.3.19. SCRIPTFor theThe SCRIPTparameter,parameter (Section 4.8 of [RFC9554]) converts to the Name (Section 2.2.1 of [RFC9553]) or Address (Section 2.5.1 of [RFC9553]) objects' phoneticScript property. Also see Section2.3.13. 2.3.18.2.3.15. 2.3.20. SERVICE-TYPE The SERVICE-TYPE parameter (Section 4.9 of [RFC9554]) converts to the OnlineService object's service property (Section 2.3.2 ofthe OnlineService object type. Note: This parameter is defined in [RFC9554]. 2.3.19.[RFC9553]). 2.3.21. SORT-AS The SORT-AS parameter (Section 5.9 of [RFC6350]) converts to thesortAs properties defined for theName, Organization, and OrgUnitobject types. 2.3.20.objects' sortAs properties. 2.3.22. TYPE The TYPE parameter (Section 5.6 of [RFC6350]) converts to either the contexts propertyas well as property-specificor the kindproperty valuesproperty, as defined in later sections. If notspecifiedotherwisefor a specific JSContact property,specified, the vCardhome"home" andwork"work" parameter values convert to the JSContactprivate"private" andwork"work" contexts, respectively.2.3.21.2.3.23. TZ The TZ parameterset(Section 5.11 of [RFC6350]) on an ADR property converts to theJSContactAddress object's timeZone property (Section 2.5.1.1 ofthe Address object that represents the vCard ADR.[RFC9553]). Also see the conversion of the TZ property in Section 2.8.2.2.3.22.2.3.24. USERNAME The USERNAME parameter (Section 4.10 of [RFC9554]) converts to the OnlineService object's user property (Section 2.3.2 ofthe OnlineService object type. Note: This parameter is defined in [RFC9554]. 2.3.23.[RFC9553]). 2.3.25. VALUE The VALUE parameter (Section 5.2 of [RFC6350]) does not convert to an IANA-registered property in JSContact. To preserve properties with experimental values, see Sections 2.15.1 and 2.15.2. 2.4. General Properties 2.4.1. BEGIN and END The BEGIN and END properties do not convert to IANA-registered properties in JSContact. 2.4.2. KIND The KIND property (Section 6.1.4 of [RFC6350]) converts to the kind property (Figure8).7). Allowed values are those described in Section 6.1.4 of [RFC6350] and extended with the values declared in [RFC6473] and [RFC6869]. KIND:individual "kind": "individual" Figure8:7: KIND Conversion Example 2.4.3. SOURCE The SOURCE property (Section 6.1.3 of [RFC6350]) converts to a Directory object (Section 2.6.2 of [RFC9553]) in the Card object's directories property (Figure9).8). The Directory object's kind property is set toentry."entry". The uri property is set to the SOURCE property value. The PREF and MEDIATYPE parameters convert according to the rules defined in Section 2.3. SOURCE:https://dir.example.com/addrbook/jdoe/Jean%20Dupont.vcf "directories": { "ENTRY-1": { "kind": "entry", "uri": "https://dir.example.com/addrbook/jdoe/Jean%20Dupont.vcf" } } Figure9:8: SOURCE Conversion Example 2.4.4. XML The XML property (Section 6.1.5 of [RFC6350]) converts toan entry inthe vCardProps property; see Section 2.15.1. 2.5. Identification Properties 2.5.1. ANNIVERSARY, BDAY, BIRTHPLACE, DEATHDATE,DEATHPLACE,andANNIVERSARYDEATHPLACE TheBDAY and ANNIVERSARYfollowing propertiesand the extensions BIRTHPLACE, DEATHDATE, and DEATHPLACE described in [RFC6474] are represented asall convert to Anniversary objectsand are includedin the Card object's anniversaries property (Figure10):9): * ANNIVERSARY (Section 6.2.6 of [RFC6350]) * BDAY (Section 6.2.5 of [RFC6350]) * BIRTHPLACE (Section 2.1 of [RFC6474]) * DEATHDATE (Section 2.3 of [RFC6474]) * DEATHPLACE (Section 2.2 of [RFC6474]) BDAY and BIRTHPLACE convert to an Anniversary object (Section 2.8.1 of [RFC9553]) having the date and placewhereproperties set. The kind property is set to"birth"; *"birth". DEATHDATE and DEATHPLACE convert to an Anniversary object having the date and placewhereproperties set. The Anniversary object's kind property is set to"death"; and *"death". ANNIVERSARY converts to the Anniversary object's datewhereproperty. The Anniversary object's kind property is set to "wedding".Both birth and death places are represented as instances ofIf theAddress object. TheBIRTHPLACEandor DEATHPLACEproperties that are represented as geo URIs convertproperty value is of type URI using the "geo:" URI scheme, then it converts toAddress instances that only includethe Address object's coordinates property. If theURIvalue type isnot a geo URI,TEXT, then it converts to theplace is ignored.Address object's full property. Otherwise, it converts to the vCardProps property; see Section 2.15.1. The ALTID and LANGUAGE parameters of both the BIRTHPLACE and DEATHPLACE properties convert according to the rules defined in Section 2.3. BDAY:19531015T231000Z BIRTHPLACE: 123 Main Street\nAny Town, CA 91921-1234\nU.S.A. DEATHDATE:19960415 DEATHPLACE: 5 Court Street\nNew England, ND 58647\nU.S.A. ANNIVERSARY:19860201 "anniversaries": { "ANNIVERSARY-1" : { "kind": "birth", "date": { "@type": "Timestamp", "utc": "1953-10-15T23:10:00Z" }, "place": { "full": "123 Main Street\nAny Town, CA 91921-1234\nU.S.A." } }, "ANNIVERSARY-2" : { "kind": "death", "date": { "year": 1996, "month": 4, "year": 15 }, "place": { "full": "5 Court Street\nNew England, ND 58647\nU.S.A." } }, "ANNIVERSARY-3" : { "kind": "wedding", "date": { "year": 1986, "month": 2, "day": 1 } } } Figure10:9: ANNIVERSARY, BDAY, BIRTHPLACE, DEATHDATE,DEATHPLACE,andANNIVERSARYDEATHPLACE Conversion Example 2.5.2. FN The FN property (Section 6.2.1 of [RFC6350]) converts to the Nameobject in the name property. Its value converts to the Name objectobject's full property (Figure11).10). If the LANGUAGE parameter is set, then the FN property converts as outlined in Section2.3.10.2.3.11. In the unexpected case where the vCard contains more than one FN property without the LANGUAGE parameter, convert the FN property that has the leastparameters set to the full property.parameters. If multiple such FN properties are present, choose any of them. All other FN properties convert to the vCardProps (Section 2.15.1) property. FN:John Q. Public, Esq. "name": { "full": "John Q. Public, Esq." } Figure11:10: FN Conversion Example 2.5.3. GENDER The GENDER property (Section 6.2.7 of [RFC6350]) does notmapconvert to an IANA-registered property in JSContact. To convert this property, see Section 2.15.1.NoteAlternatively, thealternative JSContactCard object's speakToAs propertythatdefines how to address and refer to an individual represented by thecard,Card, as do the newly defined vCard GRAMGENDER and PRONOUNS properties of [RFC9554]. 2.5.4. GRAMGENDER and PRONOUNS The GRAMGENDER property (Section 3.2 of [RFC9554]) converts to the SpeakToAs object's grammaticalGender propertyof the SpeakToAs object(Figure12).11). The PRONOUNS property (Section 3.4 of [RFC9554]) converts toan entry inthe SpeakToAs object's pronouns propertyof the SpeakToAs object(Figure12).11). GRAMGENDER:NEUTER PRONOUNS;PREF=2:they/them PRONOUNS;PREF=1:xe/xir "speakToAs": { "grammaticalGender": "neuter", "pronouns": { "PRONOUNS-1": { "pronouns": "they/them", "pref": 2 }, "PRONOUNS-2": { "pronouns": "xe/xir", "pref": 1 } } } Figure12:11: GRAMGENDER and PRONOUNS Conversion Example 2.5.5. N The N property (Section 6.2.2 of [RFC6350]) converts tothea Name object (Section 2.2.1 of [RFC9553]) in the Card object's name property. Each component in the N property structured value converts to a NameComponent in the Name object's components property. The following table shows this relation: +============+===============+==============================+ | N | NameComponent | Remarks | | component | kind | | +============+===============+==============================+ | Family | surname | To vCard: add anysurname2"surname2" | | name | | NameComponentvalue in here,to the Family | | | | name component, after allsurname| | | | "surname" values. | | | | From vCard: ignore any value | | | | that also occurs in the | | | | Secondary surname component. | +------------+---------------+------------------------------+ | Given name | given | | +------------+---------------+------------------------------+ | Additional | given2 | | | name | | | +------------+---------------+------------------------------+ | Honorific | title | | | prefix | | | +------------+---------------+------------------------------+ | Honorific | credential | To vCard: add anygeneration| | suffix | | "generation" NameComponentvalue also in| | | |here.to the Honorific suffix | | | | component. | | | | From vCard: ignore any value | | | | that also occurs in the | | | | Generation component. | +------------+---------------+------------------------------+ | Secondary | surname2 | | | surname | | | +------------+---------------+------------------------------+ | Generation | generation | | +------------+---------------+------------------------------+ Table 1: N Components Conversion If the JSCOMPS (Section 3.3.1) parameter is set, then the Name object's isOrdered property value is "true", and the defaultSeparator property and anyseparator name components"separator" NameComponent objects are set according to the parameter value. The order in the componentslistproperty MUST adhere to the order of the JSCOMPS parameter value. If the JSCOMPS parameter is not set, then the Name object's isOrdered property value is "false", and the defaultSeparator property MUST NOT be set. The order in the componentslistproperty MUST follow the order of values in the N structured value when read from left to right. If the SORT-AS parameter is set, then its structured value converts to the Name object's sortAs property according to Table 1. An empty ornon- existentnon-existent component value indicates that no sort is defined for this kind. N;SORT-AS="Stevenson,JohnPhilip":Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr.Philip": Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr. "name": { "components":[ { "kind": "surname", "value": "Stevenson" }, { "kind": "given", "value": "John" }, { "kind": "given2", "value": "Philip" }, { "kind": "given2", "value": "Paul" }, { "kind": "title", "value": "Dr." }, { "kind": "credential", "value": "M.D." }, { "kind": "credential", "value": "A.C.P." }, { "kind": "generation", "value": "Jr." } ], "sortAs": { "surname": "Stevenson", "given": "John Philip" } } Figure13:12: N Conversion Example See Section 3.3.1 for examples of using the JSCOMPS parameter for vCard-structured property values. 2.5.6. NICKNAME The NICKNAME property (Section 6.2.3 of [RFC6350]) converts to a Nickname object (Section 2.2.2 of [RFC9553]) in the Card object's nicknames property (Figure14).13). The name property is set to the NICKNAME property value. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. NICKNAME:Johnny "nicknames": { "NICK-1": { "name": "Johnny" } } Figure14:13: NICKNAME Conversion Example 2.5.7. PHOTO The PHOTO property (Section 6.2.4 of [RFC6350]) converts toan entrya Media object (Section 2.6.4 of [RFC9553]) in the Card object's media property (Figure15).14). Theentry value is aMediaobject whoseobject's kind property is set tophoto"photo" and the uri property is set to the PHOTO value. The PREF and MEDIATYPE parameters convert according to the rules defined in Section 2.3. PHOTO:https://www.example.com/pub/photos/jqpublic.gif "media": { "PHOTO-1": { "kind": "photo", "uri": "https://www.example.com/pub/photos/jqpublic.gif" } } Figure15:14: PHOTO Conversion Example 2.6. Delivery Addressing Properties 2.6.1. ADR The ADR property (Section 6.3.1 of [RFC6350]) converts to an Address object (Section 2.5.1.1 of [RFC9553]) in the Card object's addresses property. Each component in the ADR-structured property value converts to an AddressComponent in the Address object's components property. [RFC9554] defines new components for the ADR property. Implementations SHOULD set these new components, even if all their values are the empty string. The following table shows how the ADR component and AddressComponent kind relate: +=============+==================+===============================+ | ADR | AddressComponent | Remarks | | component | kind | | +=============+==================+===============================+ | post office | postOfficeBox | [RFC6350] recommends that | | box | | this component not be set, | | | | but this is now disputable | | | | given the new components. | | | | Instead, set this component | | | | and use the new ADR value | | | | format defined in [RFC9554]. | +-------------+------------------+-------------------------------+ | extended | apartment(see| To vCard: set the values of | | address |Remarks)| the following components: | | | | | | | | * room | | | | | | | | * floor | | | | | | | | * apartment | | | | | | | | * building | | | | | | | | From vCard: ignore if the ADR | | | | structured value is of the | | | | format defined in [RFC9554]. | | | | Otherwise, convert to | | | |apartment."apartment". | +-------------+------------------+-------------------------------+ | street | name(see| To vCard: set the values of | | address |Remarks)| the following components: | | | | | | | | * number | | | | | | | | * name | | | | | | | | * block | | | | | | | | * direction | | | | | | | | * landmark | | | | | | | | * subdistrict | | | | | | | | * district | | | | | | | | From vCard: ignore if the ADR | | | | structured value is of the | | | | format defined in [RFC9554]. | | | | Otherwise, convert toname."name". | +-------------+------------------+-------------------------------+ | locality | locality | | +-------------+------------------+-------------------------------+ | region | region | | +-------------+------------------+-------------------------------+ | postal code | postcode | | +-------------+------------------+-------------------------------+ | apartment | apartment | Defined in [RFC9554]. | +-------------+------------------+-------------------------------+ | block | block | Defined in [RFC9554]. | +-------------+------------------+-------------------------------+ | building | building | Defined in [RFC9554]. | +-------------+------------------+-------------------------------+ | direction | direction | Defined in [RFC9554]. | +-------------+------------------+-------------------------------+ | district | district | Defined in [RFC9554]. | +-------------+------------------+-------------------------------+ | floor | floor | Defined in [RFC9554]. | +-------------+------------------+-------------------------------+ | landmark | landmark | Defined in [RFC9554]. | +-------------+------------------+-------------------------------+ | room | room | Defined in [RFC9554]. | +-------------+------------------+-------------------------------+ | street | number | Defined in [RFC9554]. | | number | | | +-------------+------------------+-------------------------------+ | subdistrict | subdistrict | Defined in [RFC9554]. | +-------------+------------------+-------------------------------+ Table 2: ADR Components Conversion If the JSCOMPS (Section 3.3.1) parameter is set, then the Address object's isOrdered property value is "true", and the defaultSeparator property and any separator name components are set according to the parameter value. The order in the componentslistproperty MUST adhere to the order of the JSCOMPS parameter value. If the JSCOMPS parameter is not set, then the Address object's isOrdered property value is "false", and the defaultSeparator property MUST NOT be set. The order in the componentslistproperty MUST follow the order of values in the ADR structured value when read from left to right. The LABEL parameter converts to the Address object's full property. The GEO parameter converts to the Address object's coordinates property. The TZ parameter converts to the Address object's timeZone property. The CCparameter, as defined in [RFC8605],parameter converts to the Address object's countryCode property. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. The ADR-specific values of the TYPE parameter defined in Sections 5.1 and 5.2 of [RFC9554] convert to the corresponding entries of the contexts property as defined in Section 2.5.1 of [RFC9553]. The ALTID and LANGUAGE parameters convert according to the rules defined in Section 2.3. Each possible language-dependent alternativeis represented asconverts to an entry of the PatchObjectmapwhere the key references the full property.ADR;TYPE=work;CC=US:;;54321ADR;TYPE=work;CC=US: ;;54321 OakSt;Reston;VA;20190;USA;;;;Oak St;54321;;;;;St;Reston;VA;20190;USA;;;;54321;Oak St;;;;;; "addresses": { "ADDR-1" : { "contexts": { "work": true }, "components": [ { "kind": "number", "value": "54321" }, { "kind": "name", "value": "Oak St" }, { "kind": "locality", "value": "Reston" }, { "kind": "region", "value": "VA" }, { "kind": "postcode", "value": "20190" }, { "kind": "country", "value": "USA" } ], "countryCode": "US" } } Figure16:15: ADR Conversion Example See Section 3.3.1 for examples of using the JSCOMPS parameter for vCard-structured property values. 2.7. Communications Properties 2.7.1. EMAIL The EMAIL property (Section 6.4.2 of [RFC6350]) converts to anentryEmailAddress object (Section 2.3.1 of [RFC9553]) in the Card object's emails property (Figure17).16). Theentry value is anEmailAddressobject. Theobject's address property is set to the EMAIL value. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. EMAIL;TYPE=work:jqpublic@xyz.example.com EMAIL;PREF=1:jane_doe@example.com "emails": { "EMAIL-1": { "contexts": { "work": true }, "address": "jqpublic@xyz.example.com" }, "EMAIL-2": { "address": "jane_doe@example.com", "pref": 1 } } Figure17:16: EMAIL Conversion Example 2.7.2. IMPP The IMPP property (Section 6.4.3 of [RFC6350]) converts to anentryOnlineService object (Section 2.3.2 of [RFC9553]) in the Card object's onlineServices property (Figure18). The entry value is an OnlineService object.17). The vCardName property is set to "impp", and the uri property is set to the IMPP value. The SERVICE-TYPE, USERNAME, PREF, and TYPE parameters convert according to the rules defined in Section 2.3. IMPP;PREF=1:xmpp:alice@example.com "onlineServices": { "OS-1": { "uri": "xmpp:alice@example.com", "pref": 1, "vCardName": "impp" } } Figure18:17: IMPP Conversion Example 2.7.3. LANG The LANG property (Section 6.4.4 of [RFC6350]) converts toan entrya LanguagePref object (Section 2.3.4 of [RFC9553]) in the Card object's preferredLanguages property (Figure19). The entry value is a LanguagePref object.18). TheLanguagePref languageLANG property valueisconverts to theLANGLanguagePref object's language property value. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. LANG;TYPE=work;PREF=1:en LANG;TYPE=work;PREF=2:fr LANG;TYPE=home:fr "preferredLanguages": { "LANG-1": { "language": "en", "contexts": { "work": true }, "pref": 1 }, "LANG-2": { "language": "fr", "contexts": { "work": true }, "pref": 2 }, "LANG-3": { "language": "fr", "contexts": { "private": true } } } Figure19:18: LANG Conversion Example 2.7.4. LANGUAGE The LANGUAGE property (Section 3.3 of [RFC9554]) converts to the Card object's language property (Figure20).19). LANGUAGE:de-AT "language": "de-AT" Figure20:19: LANGUAGE Conversion ExampleNote: This property is defined in [RFC9554].2.7.5. SOCIALPROFILE The SOCIALPROFILE property (Section 3.5 of [RFC9554]) converts to anentryOnlineService object (Section 2.3.2 of [RFC9553]) in the Card object's onlineServices property (Figure21). The entry value is an OnlineService object.20). The vCardName property is set to "socialprofile", or it can be omitted. If thevalue type of theSOCIALPROFILE property value is of type URI, then the OnlineService object's uri property isset to the SOCIALPROFILE value. Otherwise,set; otherwise, the user property isset to the SOCIALPROFILE value.set. The SERVICE-TYPE, USERNAME, PREF, and TYPE parameters convert according to the rules defined in Section 2.3. SOCIALPROFILE;SERVICE-TYPE=Mastodon:https://example.com/@foo "onlineServices": { ... "OS-1": { "service": "Mastodon", "uri": "https://example.com/@foo" } } Figure21:20: SOCIALPROFILE Conversion ExampleNote: This property is defined in [RFC9554].2.7.6. TEL The TEL property (Section 6.4.1 of [RFC6350]) converts toan entrya Phone object (Section 2.3.3 of [RFC9553]) in the Card object's phones property (Figure22). The entry value is a Phone object.21). The TEL-specific values of the TYPE parameter convert to the features property keys as outlined in Table 3. Note that Section 6.4.1 of [RFC6350] defines the defaultTYPE of TELtype to bevoice,"voice", but the default Phone features property is absent by default. Accordingly, an implementation SHOULD only set the Phone object's features property if the TEL property actually has a TEL-specific TYPE parameter set. +=============+===============+ | TYPE value | Phone feature | +=============+===============+ | cell | mobile | +-------------+---------------+ | fax | fax | +-------------+---------------+ | main-number | main-number | +-------------+---------------+ | pager | pager | +-------------+---------------+ | text | text | +-------------+---------------+ | textphone | textphone | +-------------+---------------+ | video | video | +-------------+---------------+ | voice | voice | +-------------+---------------+ Table 3: TEL TYPE Conversion The value of the TEL property converts to the Phone object's number property. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. 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 "phones": { "PHONE-1": { "contexts": { "private": true }, "features": { "voice": true }, "number": "tel:+1-555-555-5555;ext=5555", "pref": 1 }, "PHONE-2": { "contexts": { "private": true }, "number": "tel:+33-01-23-45-67" } } Figure22:21: TEL Conversion Example 2.8. Geographical Properties 2.8.1. GEO The GEO property (Section 6.5.2 of [RFC6350]) converts to the Address object's coordinates property (Section 2.5.1 ofthe Address object.[RFC9553]). Also see Section 2.8.3 to determine which Address object instance to convert to. 2.8.2. TZ The TZ property (Section 6.5.1 of [RFC6350]) converts an Address object (Section 2.5.1 of [RFC9553]) in the Card object's addresses property. A value of type TEXT converts to thetimeZone property in theAddressobject.object's timeZone property. A value of type UTC-OFFSET converts to the Address object's timeZone propertyin the Address objectif the offset has zero minutes and the hour offset isin the rangebetween -12<= 14.and +14, both inclusively. Note that: * If the hour offset is zero, use the time zone nameEtc/UTC."Etc/UTC". * Otherwise, construct the time zone name withEtc/GMT"Etc/GMT" suffixed with the string representation of the reversed sign hour offset, including the sign but excluding leading zeros and minutes. For example, the UTC offset value-0500"-0500" converts toEtc/GMT+5."Etc/GMT+5". For such property values, also see Section 2.8.3 to determine which Address object instance to convert to. Any other value of type UTC-OFFSET or URI does not convert to an IANA-registered property in JSContact. To convert such property, see Section 2.15.1. 2.8.3. Combining Geographical Properties In vCard, the properties ADR, GEO, and TZ occur independently of each other. In JSContact, they all convert to properties of an Address object. It is implementation-specific if these vCard properties convert to _separate_ address instances in JSContact or if some or all of them convert to the _same_ address. That being said, implementations MUST convert the properties to the _same_ address for the following cases: * The GROUP parameter values of the properties match. * The GROUP parameters are not set, but they are set on any other ADR, GEO, and TZ properties. 2.9. Organizational Properties 2.9.1. CONTACT-URI The CONTACT-URIproperty, as defined in [RFC8605], is represented as an entryproperty (Section 2.1 of [RFC8605]) converts to a Link object (Section 2.6.3 of [RFC9553]) in the Card object's links property (Figure23).22). Theentry value is aLinkobject whoseobject's kind property is set tocontact"contact" and the uri property is set to the CONTACT-URI property value. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. CONTACT-URI;PREF=1:mailto:contact@example.com "links": { "CONTACT-1": { "kind": "contact", "uri": "mailto:contact@example.com", "pref": 1 } } Figure23:22: CONTACT-URI Conversion Example 2.9.2. LOGO The LOGO property (Section 6.6.3 of [RFC6350]) converts toan entrya Media object (Section 2.6.4 of [RFC9553]) in the Card object's media property (Figure24).23). Theentry value is aMediaobject whoseobject's kind property is set tologo"logo" and the uri property is set to the LOGO property value. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. LOGO:https://www.example.com/pub/logos/abccorp.jpg "media": { "LOGO-1": { "kind": "logo", "uri": "https://www.example.com/pub/logos/abccorp.jpg" } } Figure24:23: LOGO Conversion Example 2.9.3. MEMBER TheuidsMEMBER property (Section 6.6.5 of [RFC6350]) converts to thecontact cards composing the group are included in theCard object's members property (Figure25). In this case,24). Each MEMBER property value is a key in the members property. The PREF parameter (Section 5.3 of [RFC6350]) does nothave a JSContact counterpart; however, the implementors MAY insert the map entries by order of preference.convert to JSContact. KIND:group FN:The Doe family MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 "kind": "group", "name": { "full": "The Doe family" }, "uid": "urn:uuid:ab4310aa-fa43-11e9-8f0b-362b9e155667", "members": { "urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af": true, "urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519": true } Figure25:24: Group Example 2.9.4. ORG The ORG property (Section 6.6.4 of [RFC6350]) converts to anentryOrganization object (Section 2.2.3 of [RFC9553]) in the Card object's organizations property (Figure26).25). Theentry value is anOrganizationobject whoseobject's name propertycontainsis set to the ORG property organizationalname, and thename component. The Organization object's units property is an array of OrgUnit objects that each containthean organizational unit nameincomponent value of thename property.ORG property value. Implementations MAY allow representation of organizational units without the organizational name. In this case, the first component of the ORG value MUST be an empty string (e.g., ORG:;DepartmentA). The ALTID and LANGUAGE parameters convert according to the rules defined in Section 2.3. The first item of the comma-separated SORT-AS parameter value converts to the sortAs property of the Organization object. The subsequent items convert to the sortAs property of the corresponding OrgUnit object. The TYPE parameter converts according to the rules defined in Section 2.3. ORG;SORT-AS="ABC":ABC\, Inc.;North American Division;Marketing "organizations": { "ORG-1": { "name": "ABC, Inc.", "units":[ { "name": "North American Division" }, { "name": "Marketing" } ], "sortAs": "ABC" } } Figure26:25: ORG Conversion Example 2.9.5. RELATED The RELATED property (Section 6.6.6 of [RFC6350]) converts toan entry inthe Card object's relatedTo property (Figure27).26). The property value converts to the key in the relatedTo property. The TYPE parameters convert to the Relation object's relation property (Section 2.1.8 ofthe Relation object value.[RFC9553]). Any other parameters convert as defined in Section 2.15.2. RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 RELATED;TYPE=contact:https://example.com/directory/john.vcf RELATED;VALUE=text:Please contact my deputy John for any inquiries. "relatedTo" : { "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" : { "relation" : { "friend" : true } }, "https://example.com/directory/john.vcf" : { "relation" : { "contact" : true } }, "Please contact my deputy John for any inquiries." : { "relation" : { } } } Figure27:26: RELATED Conversion Example 2.9.6. TITLE and ROLEBothThe TITLE (Section 6.6.1 of [RFC6350]) and ROLE (Section 6.6.2 of [RFC6350]) propertiesare represented as entriesconvert to a Title object (Section 2.2.5 of [RFC9553]) in the Card object's titles property (Figure28).27). Theentry value is aTitleobject whoseobject's kind property is set totitle"title" orrole"role" for the TITLE and ROLE vCard properties, respectively. The name property is set to the vCard property value. The value of the organizationId property can be derived if the TITLE or ROLE property is a member of a vCard property group and if exactly one other ORG property is also a part of that group. The ALTID and LANGUAGE parameters convert according to the rules defined in Section 2.3. TITLE:Research Scientist group1.ROLE:Project Leader group1.ORG:ABC, Inc. "titles": { "TITLE-1": { "kind": "title", "name": "Research Scientist" }, "TITLE-2": { "kind": "role", "name": "Project Leader", "organizationId": "ORG-1" } }, "organizations": { "ORG-1": { "name": "ABC, Inc." } } Figure28:27: TITLE and ROLE Conversion Example 2.10. Personal Information Properties 2.10.1. EXPERTISE The EXPERTISEproperty, as defined in [RFC6715], is represented asproperty (Section 2.1 of [RFC6715]) converts to a PersonalInfo object (Section 2.8.4 of [RFC9553]) in the Card object's personalInfo property (Figure29).28). The PersonalInfo object's kind property is set to "expertise". The INDEXparameter convertsand LEVEL parameters convert according to the rules defined in Section 2.3. EXPERTISE;LEVEL=beginner;INDEX=2:Chinese literature EXPERTISE;INDEX=1;LEVEL=expert:chemistry "personalInfo": { "PERSINFO-1" : { "kind": "expertise", "value": "Chinese literature", "level": "low", "listAs": 2 }, "PERSINFO-2" : { "kind": "expertise", "value": "chemistry", "level": "high", "listAs": 1 } } Figure29:28: EXPERTISE Conversion Example 2.10.2. HOBBY The HOBBYproperty, as defined in [RFC6715], is represented asproperty (Section 2.2 of [RFC6715]) converts to a PersonalInfo object (Section 2.8.4 of [RFC9553]) in the Card object's personalInfo property (Figure30).29). The PersonalInfo object's kind property is set to "hobby". The INDEXparameter convertsand LEVEL parameters convert according to the rules defined in Section 2.3. HOBBY;INDEX=1;LEVEL=high:reading HOBBY;INDEX=2;LEVEL=high:sewing "personalInfo": { "PERSINFO-1" : { "kind": "hobby", "value": "reading", "level": "high", "listAs": 1 }, "PERSINFO-2" : { "kind": "hobby", "value": "sewing", "level": "high", "listAs": 2 } } Figure30:29: HOBBY Conversion Example 2.10.3. INTEREST The INTERESTproperty, as defined in [RFC6715], is represented asproperty (Section 2.3 of [RFC6715]) converts to a PersonalInfo object (Section 2.8.4 of [RFC9553]) in the Card object's personalInfo property (Figure31).30). The PersonalInfo object's kind property is set to "interest". The INDEXparameter convertsand LEVEL parameters convert according to the rules defined in Section 2.3. INTEREST;INDEX=1;LEVEL=medium:r&b music INTEREST;INDEX=2;LEVEL=high:rock&roll music "personalInfo": { "PERSINFO-1" : { "kind": "interest", "value": "r&b music", "level": "medium", "listAs": 1 }, "PERSINFO-2" : { "kind": "interest", "value": "rock&roll music", "level": "high", "listAs": 2 } } Figure31:30: INTEREST Conversion Example 2.10.4. ORG-DIRECTORY The ORG-DIRECTORY property (Section 2.4 of [RFC6715]) [RFC6715] converts to a Directory object (Section 2.6.2 of [RFC9553]) in the Card object's directories property (Figure32).31). The Directory object's kind property is set todirectory."directory". The uri property is set to the ORG-DIRECTORY property value. The INDEX, PREF, and TYPE parameters convert according to the rules defined in Section 2.3. ORG-DIRECTORY;INDEX=1:https://directory.mycompany.example.com ORG-DIRECTORY;PREF=1:ldap://ldap.tech.example/o=Tech,ou=Engineering "directories": { "DIRECTORY-1": { "kind": "directory", "uri": "https://directory.mycompany.example.com", "listAs": 1 }, "DIRECTORY-2": { "kind": "directory", "uri": "ldap://ldap.tech.example/o=Tech,ou=Engineering", "pref": 1 } } Figure32:31: ORG-DIRECTORY Conversion Example 2.11. Explanatory Properties 2.11.1. CATEGORIES The CATEGORIES property (Section 6.7.1 of [RFC6350]) converts to a set of entries of the Card object's keywords property (Figure33).32). The keys are the comma-separated text values of the CATEGORIES property. In this case, the PREF parameter does not have a JSContact counterpart; however, the implementors MAY insert themapentries by order of preference. CATEGORIES:internet,IETF,Industry,Information Technology "keywords": { "internet": true, "IETF": true, "Industry": true, "Information Technology": true } Figure33:32: CATEGORIES Conversion Example 2.11.2. CLIENTPIDMAPand PID ParametersThe CLIENTPIDMAPand PID parameters convertproperty (Section 6.7.7 of [RFC6350]) converts to the vCardProps (Section 2.15.1)and vCardParams (Section 2.15.2) properties.property. 2.11.3. CREATED The CREATED property (Section 3.1 of [RFC9554]) converts to the Card object's created property (Figure34).33). CREATED:19940930T143510Z "created": "1994-09-30T14:35:10Z" Figure34:33: CREATED Conversion ExampleNote: This property is defined in [RFC9554].2.11.4. NOTE The NOTE property (Section 6.7.2 of [RFC6350]) converts to a Note object (Section 2.8.3 of [RFC9553]) in the Card object's notesmapproperty (Figure35).34). The ALTID and LANGUAGE parameters convert according to the rules defined in Section 2.3. NOTE;CREATED=20221123T150132Z;AUTHOR-NAME="John": Office hours are from 0800 to 1715 EST\, Mon-Fri. "notes": { "NOTE-1" : { "note": "Office hours are from 0800 to 1715 EST, Mon-Fri.", "created": "2022-11-23T15:01:32Z", "author": { "name": "John" } } } Figure35:34: NOTE Conversion Example 2.11.5. PRODID The PRODID property (Section 6.7.3 of [RFC6350]) converts to the Card object's prodId property (Figure36).35). PRODID:ACME Contacts App version 1.23.5 "prodId": "ACME Contacts App version 1.23.5" Figure36:35: PRODID Conversion Example 2.11.6. REV The REV property (Section 6.7.4 of [RFC6350]) converts to the Card object's updated property (Figure37).36). REV:19951031T222710Z "updated": "1995-10-31T22:27:10Z" Figure37:36: REV Conversion Example 2.11.7. SOUND The SOUND property (Section 6.7.5 of [RFC6350]) converts toan entrya Media object (Section 2.6.4 of [RFC9553]) in the Card object's media property (Figure38).37). Theentry value is aMediaobject whoseobject's kind property is set tosound"sound" and the uri property is set to the SOUND value. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. SOUND:CID:JOHNQPUBLIC.19960229T080000.xyzMail@example.com "media": { ... "SOUND-1": { "kind": "sound", "uri": "CID:JOHNQPUBLIC.19960229T080000.xyzMail@example.com" } } Figure38:37: SOUND Conversion Example 2.11.8. UID The UID propertycorresponds(Section 6.7.6 of [RFC6350]) converts to the Card object's uid property (Figure39).38). UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 "uid": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" Figure39:38: UID Conversion Example 2.11.9. URL The URL property (Section 6.7.8 of [RFC6350]) converts toan entrya Link object (Section 2.6.3 of [RFC9553]) in the Card object's links property (Figure40).39). Theentry value is aLinkobject whoseobject's uri property is set to the URL value. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. URL:https://example.org/restaurant.french/~chezchic.html "links": { "LINK-1": { "uri": "https://example.org/restaurant.french/~chezchic.html" } } Figure40:39: URL Conversion Example 2.11.10. VERSION The VERSION property (Section 6.7.9 of [RFC6350]) converts toan entry inthe vCardProps (Section 2.15.1) property. 2.11.11. X-ABLabel The X-ABLabel property is experimental but widely in use in existing vCard data. It converts to the label property of a JSContactobject type.object. The X-ABLabel property is preceded by a vCard property group name, and the label converts to the JSContact object, which was converted from a vCard propertyhavingof the same group. The group name is not preserved; implementations are free to choose any unique group name when converting back to vCard. For an example on how to preserve the group name, see Section2.3.8.2.3.9. item1.TEL;VALUE=uri:tel:+1-555-555-5555 item1.X-ABLabel:foo "phones": { "p1": { "number": "tel:+1-555-555-5555", "label": "foo" } } Figure41:40: X-ABLabel Conversion Example 2.12. Security Properties 2.12.1. KEY The KEY property (Section 6.8.1 of [RFC6350]) converts toan entrya CryptoKey object (Section 2.6.1 of [RFC9553]) in the Card object's cryptoKeys property (Figure42).41). Theentry value is aCryptoKeyobject whoseobject's uri property is set to the KEY property value. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. KEY:https://www.example.com/keys/jdoe.cer "cryptoKeys": { "KEY-1": { "uri": "https://www.example.com/keys/jdoe.cer" } } Figure42:41: KEY Conversion Example 2.13. Calendar Properties 2.13.1. CALADRURI The CALADRURI property (Section 6.9.2 of [RFC6350]) converts toan entrya SchedulingAddress object (Section 2.4.2 of [RFC9553]) in the Card object's schedulingAddresses property (Figure43).42). Theentry value is aSchedulingAddressobject whoseobject's uri property is set to the CALADRURI value. The PREF parameter (Section 5.3 of [RFC6350]) converts according to the rules defined in Section 2.3. CALADRURI;PREF=1:mailto:janedoe@example.com CALADRURI:https://example.com/calendar/jdoe "schedulingAddresses": { "SCHEDULING-1": { "uri": "mailto:janedoe@example.com", "pref": 1 }, "SCHEDULING-2": { "uri": "https://example.com/calendar/jdoe" } } Figure43:42: CALADRURI Conversion Example 2.13.2. CALURI The CALURI property (Section 6.9.3 of [RFC6350]) converts toan entrya Calendar object (Section 2.4.1 of [RFC9553]) in the Card object's calendars property (Figure44).43). Theentry value is aCalendarobject whoseobject's kind property is set tocalendar"calendar" and the uri property is set to the CALURI value. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. CALURI;PREF=1:https://cal.example.com/calA CALURI;MEDIATYPE=text/calendar:https://ftp.example.com/calA.ics "calendars": { "CAL-1": { "kind": "calendar", "uri": "https://cal.example.com/calA", "pref": 1 }, "CAL-2": { "kind": "calendar", "uri": "https://ftp.example.com/calA.ics", "mediaType": "text/calendar" } } Figure44:43: CALURI Conversion Example 2.13.3. FBURL The FBURL property (Section 6.9.1 of [RFC6350]) converts toan entrya Calendar object (Section 2.4.1 of [RFC9553]) in the Card object's calendars property (Figure45).44). Theentry value is aCalendarobject whoseobject's kind property is set tofreeBusy"freeBusy" and the uri property is set to the FBURL value. The PREF and TYPE parameters convert according to the rules defined in Section 2.3. FBURL;PREF=1:https://www.example.com/busy/janedoe FBURL;MEDIATYPE=text/calendar:https://example.com/busy/project-a.ifb "calendars": { "FBURL-1": { "kind": "freeBusy", "uri": "https://www.example.com/busy/janedoe", "pref": 1 }, "FBURL-2": { "kind": "freeBusy", "uri": "https://example.com/busy/project-a.ifb", "mediaType": "text/calendar" } } Figure45:44: FBURL Conversion Example 2.14. Extended Properties and Parameters Extended properties and parameters convert as specified in Section 2.15. 2.15. New JSContact Properties vCards may contain properties or parameters for which no IANA- registered JSContact property is defined. For example, a vCard may contain properties and parameters of which the semantics or purposes are unknown to the implementation; see Section 6.10 of [RFC6350]. This section defines JSContact properties by which such vCard properties and parameters MAY be represented in JSContact. Implementations MAY choose to convert differently if they deem that more appropriate. 2.15.1.Property vCardProps Name:vCardPropsType: JCardProp[], where JCardProp denotes a jCard-encodedvCardProps: JCardProp[] (optional). Contains vCardproperty as defined in Section 3.3 of [RFC7095]. Definition: This property is set on a JSContact object that represents a vCard. It containsproperties that are set in the vCard represented by this JSContact object.Each entry in this list typically representsThe JCardProp type denotes a jCard-encoded vCard propertyfor which no conversion to an IANA-registered JSContact property is defined.as defined in Section 3.3 of [RFC7095]. Example: This illustrates how to convert a vCard extension property: item1.X-FOO;X-BAR=Hello:World! "vCardProps": [ ["x-foo", { "x-bar": "Hello", "group": "item1" }, "unknown", "World!"] ] Figure46:45: JSContact vCardProps Example 2.15.2.PropertyvCardParamsName: vCardParams Type:vCardParams: String[String|String[]]Definition: This property is(optional). Contains vCard parameters that are set ona JSContact object that represents athe vCardproperty. Itsproperty represented by this JSContact object. The value MUST be a JSON object containing vCard propertyparameters, definedparameters asarray element 2defined in Section 3.3 of [RFC7095]. Each entry represents a parameter of the vCard property that converts to the JSContact object. Example: This illustrates how to convert a vCard extension parameter: EMAIL;X-FOO=Bar:jane_doe@example.com "emails": { "email1": { "address": "jane_doe@example.com", "vCardParams": { "x-foo": "Bar" } } } Figure47:46: JSContact vCardParams Example 2.15.3.Property vCardName Name:vCardNameType:vCardName: StringDefinition: This property is set on a JSContact object that represents a vCard property or parameter, and its value contains(optional). Contains the name ofthatthe vCardelement. Thiselement that is represented by this JSContact object. For example, this allows to preserve the name of a vCardelement to be preservedproperty when multipleelementsvCard properties convert the same JSContactobjecttype. Thecase-insensitivecase- insensitive value MUST be valid according to thename"name" ABNF defined in Section 3.3 of [RFC6350]. Example: Both vCard IMPP and SOCIALPROFILE convert to an OnlineService object (Section 2.3.2 of [RFC9553]) in JSContact. The vCardName property value indicates that the vCard source element was IMPP as follows: IMPP:xmpp:alice@example.com "onlineServices": { "os1": { "uri": "xmpp:alice@example.com", "vCardName": "impp" }, } Figure48:47: JSContact vCardName Example 3. Converting JSContact to vCard 3.1. Conversion Rules A Card object converts to vCard by applying the reverse rules of converting vCard to JSContact. In addition to those listed in Appendix A, the following rules apply: * Multivalued JSContact properties convert to separate instances of their equivalent vCard property, and each of the PROP-ID parameters MUST be set to theIdId-typed key of the converted value (see Section2.3.16).2.3.18). * The full property of the name property in JSContact is optional, but the FN property is mandatory in vCard. The following rules apply: - If the Name object's full property is set, then implementations MUST use its value for the vCard FN property. - If the Name object's full property is not set, then implementations SHOULD derive the full name from the Name object's components property values. If the isOrdered property is "true", then this can be done by concatenating the name component values. Otherwise, or alternatively, an implementation can choose any other heuristic to generate the full name from its components such as [CLDRPersonName]. Implementations MUST set the DERIVED parameter on the FN property. - Otherwise, the FN property MUST be set to the empty value. * Vendor-specific and unknown properties convert to vCard as outlined in Section 3.1.1. 3.1.1. Converting Unknown Properties JSContactobject typesobjects may contain properties for which noIANA- registeredIANA-registered vCard property is defined. For example, a JSContact object may contain vendor-specific properties of which the semantics or purpose are unknown. This specification defines the new JSPROP (Section 3.2.1) vCard property and JSPTR (Section 3.3.2) vCard parameter by which such JSContact properties MAY be represented in vCard. Implementations MAY choose to convert differently if they deem that more appropriate. 3.2. New vCard Properties 3.2.1. JSPROP Property name: JSPROP Purpose: Represents a JSContact property in vCard. Value type: TEXT; also see "Format definition" below for value restrictions. Conformance: Can be specified multiple times in a vCard. Property parameters: The JSPTR parameter MUST be set for this property. Other IANA-registered and experimental property parameters can be specified on this property. Description: This property converts an arbitrary JSContact property from and to vCard. The vCard property value is the JSON-encoded value of the JSContact property, represented as a TEXT value. The format of the JSON value MUST be compact, e.g., without insignificantwhitespace.whitespace as defined in Section 2 of [RFC8259]. The value of the JSPTR parameter points to the JSContact property within the Card. The root of the JSON pointer is always the Card object that this vCard converts to, irrespective if the JSON pointer starts with the SOLIDUS (U+002F) character. The pointer MUST NOT reference into an array. All JSPROP properties in a vCard together form a PatchObject as defined in [RFC9553]. The value of its JSPTR parameter corresponds to a key in the PatchObject; the value of the JSPROP property corresponds to the value for that key. When converting from vCard to JSContact, the PatchObject MUST only be applied after all other vCard properties have already been converted. The PatchObject MUST be valid, including the restriction that an invalid PatchObject MUST NOT be applied. Format definition: This property is defined by the following notation: jsprop = "JSPROP" jsprop-param ":" TEXT jsprop-param = *( ; The following areMANDATORYREQUIRED and MUST NOT ; occur more than once ( ";" jsptr-param ) / ; see next section ( ";" "VALUE" "=" "TEXT") ; ; The following is OPTIONAL ; and MAY occur more than once. ; (";" other-param) ; ) Example(s): This illustrates how to convert a property at the top level in a Card object that is unknown to the implementation. "someUnknownProperty": true JSPROP;JSPTR="someUnknownProperty":true Figure49:48: Unknown Property Example This illustrates how to convert a vendor-specific property at the top level of a Card object. Note the required use of quoted string for the JSPTR value, which allows the path to include the COLON (U+003A) character. "example.com:foo": { "bar": 1234 } JSPROP;JSPTR="example.com:foo":{"bar":1234} Figure50:49: Vendor-Specific Property Conversion Example This illustrates how to convert a vendor-specific property at a nested level in a Card object using a path relative to the Card object. Although not recommended, the property name includes the SOLIDUS (U+002F) character, which requires escaping in the JSON pointer. "phones": { "phone1": { "number": "tel:+33-01-23-45-67", "example.com:foo/bar": "tux hux" } } TEL:tel:+33-01-23-45-67 JSPROP;JSPTR="phones/phone1/example.com:foo~1bar": "tux hux" Figure51:50: Nested Vendor-Specific Property Example with a Path Relative to Card 3.3. New vCard Parameters 3.3.1. JSCOMPS Parameter name: JSCOMPS Purpose: Defines the order and separators for the elements of a structured property value. Description: The JSCOMPS parameter value facilitates converting name and address components between JSContact and vCard. It preserves the order of the components of the JSContact property and contains the verbatim values of separator components. If this parameter is set and its value is valid (see later), then implementations MUST set the isOrdered property of the Name or Address object to "true". Otherwise, they MUST set the isOrdered property value to "false". The JSCOMPS parameter value is a structured type value. Its value MUST be quoted. The parameter value consists of a sequence of entries, separated by the SEMICOLON character (U+003B). The first entry defines the value of the defaultSeparator property. If it is the empty string, then no default separator is defined. Otherwise, the first entry MUST be a separator entry. All following entries processed in order result in an ordered list of JSContact components and MUST be one of the following two kinds: 1. A positional. This refers to a component value in the vCard structured value. A position consists of the numeric index of a component in the structured value, optionally followed by a COMMA (U+002C) character and the non-zero index of a value within that component. The zero index selects the first component or value, respectively. The second index is zero by default, in which case it MUST be omitted (as well as the leading COMMA). The resulting JSContact component is formed by determining its kind by the position in the vCard structured value. The component value is the verbatim value of the vCard component. Figures5251 and5352 illustrate this by example. 2. A separator. This contains the verbatim value of a separator component. It starts with the LATIN SMALL LETTER S (U+0073) character, followed by the COMMA (U+002C) character, followed by zero or moreparam-value"param-value" characters (see Section 3.3 of [RFC6350]), where the COMMA (U+002C) and SEMICOLON (U+003B) characters MUST be escaped according to the rules defined in Section 3.4 of [RFC6350]. Figure5453 illustrates this by example. The resulting JSContact component is formed by setting its kind toseparator"separator" and its value to the verbatim value of the entry. A JSCOMPS parameter value is valid if and only if: * All indexes in the positional entries refer to an existing component value in the vCard property value. * The count of positional entries equals the count of deduplicated component values. Deduplication is required because some values may occur in both their designated and backwards-compatible components in the vCard property value: - A value that occurs in both the N property secondary surname component and the family name component only counts once. - A value that occurs in both the N property generation component and the honorific suffix component only counts once. - A value in the ADR property street address component does not count if the ADR property value contains a value in one of the new components defined in [RFC9554]. - All other values count once each. Format definition: jscomps-param = "JSCOMPS" "=" DQUOTE( (jscomps-entry-sep / "")[jscomps-entry-sep ] ";" jscomps-entrylist)DQUOTE jscomps-entrylist = jscomps-entry *(";" jscomps-entry) jscomps-entry = jscomps-entry-pos / jscomps-entry-sep jscomps-entry-pos = 1*DIGIT [ "," 1*DIGIT ] jscomps-entry-sep = "s" "," jscomps-entry-verb jscomps-entry-verb = *QSAFE-CHAR ; encodespecial charactersaccording to RFC 6868 Example(s): The following example demonstrates the use of positional entries for the name "Jane Doe". The given name is ordered before the surname. No secondary index is required for either positional because both are zero. "name": { "components": [ { "kind": "given", "value": "Jane" }, { "kind": "surname", "value": "Doe" } ], "isOrdered": true } N;JSCOMPS=";1;0":Doe;Jane;;;;;; FN;DERIVED=TRUE:Jane Doe Figure52:51: Example of a Secondary PositionalEntriesIndex The following example demonstrates a secondary positional index. The "Jr." generation marker only counts once because it occurs in both the designated generation component and the backwards- compatible honorific suffixes component. "name": { "components": [ { "kind": "given", "value": "John" }, { "kind": "given2", "value": "Philip" }, { "kind": "given2", "value": "Paul" }, { "kind": "surname", "value": "Stevenson" }, { "kind": "generation", "value": "Jr." }, { "kind": "credential", "value": "M.D." } ], "isOrdered": true }N;JSCOMPS=";1;2;2,1;0;6;4,1":Stevenson;John;Philip,Paul;;Jr.,M.D.;;Jr.N;JSCOMPS=";1;2;2,1;0;6;4,1": Stevenson;John;Philip,Paul;;Jr.,M.D.;;Jr. Figure53:52: Example of Positional Entries The following example demonstrates the use of separator entries for the (shortened for brevity) address "54321 Oak St, Reston". The first entry defines the default separator to be ", ". The second and fourth positional entries are separated with the separator value " ". For backwards compatibility, the street address component of the ADR property contains both the street number and name, but it is not referred to in the JSCOMPS parameter and does not contribute to the count of values. "addresses": { "a1": { "components": [ { "kind": "number", "value": "54321" }, { "kind": "separator", "value": " " }, { "kind": "name", "value": "Oak St" }, { "kind": "locality", "value": "Reston" } ], "defaultSeparator": ", ", "isOrdered": true } } ADR;JSCOMPS="s,\, ;11;s,;10;3":;;54321;10;3": ;;54321 Oak St;Reston;;;;;;;Oak St;54321;;;;;; Figure54:53: Example of Separator Entries 3.3.2. JSPTR Parameter name: JSPTR Purpose:ContainsThis parameter is set on a JSPROP (Section 3.2.1) property. Its value is a JSON pointer [RFC6901] thatrelates the vCard JSPROP (Section 3.2.1) propertypoints toathe JSContact property that has the value of the JSPROP property. Description: This parameter has a single value that MUST be a valid JSON pointer as defined in [RFC6901]. Note that the value MUST be quoted according to theparam-value"param-value" ABNF in [RFC6350]. Format definition: jsptr-param = "JSPTR" "=" param-value ; also see param-value in RFC 6350, Section 3.3 Example(s): This illustrates a simple example. For further examples, see Section 3.2.1. JSPROP;JSPTR="example.com:foo":"bar" 4. Security Considerations This specification defines how to convert between the JSContact and vCard formats. The security considerations for parsing and formatting such data apply and are outlined in Section 4 of [RFC9553] and Section 9 of [RFC6350]. 5. IANA Considerations 5.1. New vCard Property IANA has added the following entry to the "vCard Properties" registry, as defined in Section 10.3.1 of [RFC6350]. +===========+==========+=========================+ | Namespace | Property | Reference | +===========+==========+=========================+ | | JSPROP | RFC 9555, Section 3.2.1 | +-----------+----------+-------------------------+ Table 4: New vCard Property 5.2. New vCard Parameter IANA has added the following entry to the "vCard Parameters" registry, as defined in Section 10.3.2 of [RFC6350]. +===========+===========+=========================+ | Namespace | Parameter | Reference | +===========+===========+=========================+ | | JSPTR | RFC 9555, Section 3.3.2 | +-----------+-----------+-------------------------+ Table 5: New vCard Parameter 5.3. New JSContact Properties IANA has added the following entries to the "JSContact Properties" registry. Note that the Since Version is 1.0, the Until Version is not set, and the Change Controller is IETF for all of these properties.+===========+=======================+=========+========+============++===========+=======================+=========+========+===========+ |Property |Property Type |Property|Intended|Reference|Intended|Reference/ | |Name | |Context |Usage|or | | | | | |Description | +===========+=======================+=========+========+============+|Description| +===========+=======================+=========+========+===========+ |vCardName |String |Any |common |RFC 9555, | | | |JSContact| |Section | | | |object | |2.15.3 |+-----------+-----------------------+---------+--------+------------++-----------+-----------------------+---------+--------+-----------+ |vCardParams|String[String|String[]]|Any |common |RFC 9555, | | | |JSContact| |Section | | | |object | |2.15.2 |+-----------+-----------------------+---------+--------+------------++-----------+-----------------------+---------+--------+-----------+ |vCardProps |JCardProp[] |Card |common |RFC 9555, | | | | | |Section | | | | | |2.15.1 |+-----------+-----------------------+---------+--------+------------++-----------+-----------------------+---------+--------+-----------+ Table 6: JSContact Properties Registry 5.4. New JSContact Type IANA has added the following entry to the "JSContact Types" registry. Note that the Since Version is 1.0, the Until Version is not set, and the Change Controller is IETF for this type. +===========+================+==========================+ | Type Name | Intended Usage |Reference or DescriptionReference/Description | +===========+================+==========================+ | JCardProp | common | RFC 9555, Section 2.15.1 | +-----------+----------------+--------------------------+ Table 7: JSContact Types Registry 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>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>. [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <https://www.rfc-editor.org/info/rfc6350>. [RFC6473] Saint-Andre, P., "vCard KIND:application", RFC 6473, DOI 10.17487/RFC6473, December 2011, <https://www.rfc-editor.org/info/rfc6473>. [RFC6474] Li, K. and B. Leiba, "vCard Format Extensions: Place of Birth, Place and Date of Death", RFC 6474, DOI 10.17487/RFC6474, December 2011, <https://www.rfc-editor.org/info/rfc6474>. [RFC6715] Cauchie, D., Leiba, B., and K. Li, "vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group", RFC 6715, DOI 10.17487/RFC6715, August 2012, <https://www.rfc-editor.org/info/rfc6715>. [RFC6869] Salgueiro, G., Clarke, J., and P. Saint-Andre, "vCard KIND:device", RFC 6869, DOI 10.17487/RFC6869, February 2013, <https://www.rfc-editor.org/info/rfc6869>. [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <https://www.rfc-editor.org/info/rfc6901>. [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, <https://www.rfc-editor.org/info/rfc7095>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>. [RFC9553] Stepanek, R. and M. Loffredo, "JSContact: A JSON Representation of Contact Data", RFC 9553, DOI 10.17487/RFC9553,MarchMay 2024, <https://www.rfc-editor.org/info/rfc9553>. [RFC9554] Stepanek, R. and M. Loffredo, "vCard FormatExtensionExtensions for JSContact", RFC 9554, DOI 10.17487/RFC9554,MarchMay 2024, <https://www.rfc-editor.org/info/rfc9554>. 6.2. Informative References [CLDRPersonName] Davis, M., Edberg, P., Gillam, R., Kolisnychenko, A., McKenna, M., and other CLDR committee members, "Unicode Locale Data Markup Language (LDML) Part 8: Person Names", Unicode Technical Standard #35, Version 44.1, July 2023, <https://www.unicode.org/reports/tr35/ tr35-personNames.html>. [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>. [vOBJECT] Tse, R., Tam, P., and M. Douglass, "vObject Internationalization", Work in Progress, Internet-Draft, draft-calconnect-vobject-i18n-00,78 June 2018, <https://datatracker.ietf.org/doc/html/draft-calconnect- vobject-i18n-00>. Appendix A. Reverse Rules of Converting a vCard to a JSContact Card Table 8 lists the relevant document sections for each JSContactobjecttype and property.+===================+=====================+=========================++===================+=====================+=====================+ | JSContact Type | Property Name | Relevant| | | |Section(s) |+===================+=====================+=========================++===================+=====================+=====================+ | Address | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | components | Sections 2.6.1 and | | | |and3.3.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | coordinates | Sections2.3.72.3.8 and | | | |and2.8.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | country | Section 2.6.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | countryCode | Section 2.6.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | defaultSeparator | Sections 2.6.1 and | | | |and3.3.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | full | Section 2.6.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | isOrdered | Sections 2.6.1 and | | | |and3.3.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | locality | Section 2.6.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | phoneticScript | Sections2.3.132.3.15 and | | | |and 2.3.172.3.19 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | phoneticSystem | Section2.3.132.3.15 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | postcode | Section 2.6.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | region | Section 2.6.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Address | timeZone | Sections2.3.212.3.23 and | | | |and2.8.2 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | AddressComponent | phonetic | Section2.3.132.3.15 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Anniversary | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Anniversary | date | Section 2.5.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Anniversary | kind | Section 2.5.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Anniversary | place | Section 2.5.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Author | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Author | name | Section 2.3.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Author | uri | Section 2.3.2 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Calendar | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Calendar | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Calendar | kind | Sections2.13.12.13.2 and | | | |and2.13.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Calendar | label | Section 2.11.11 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Calendar | mediaType | Section2.3.122.3.14 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Calendar | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Calendar | uri | Sections2.13.12.13.2 and | | | |and2.13.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | @version | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | addresses | Section 2.6.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | anniversaries | Section 2.5.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | calendars | Sections 2.13.2 and | | | |Section 2.13.1 | | | | and2.13.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | created | Section 2.11.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | directories | Sections| | | | Section2.4.3 and | | | |Section2.10.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | emails | Section 2.7.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | keywords | Section 2.11.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | kind | Section 2.4.2 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | language | Section 2.7.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | links | Sections 2.9.1 and | | | |and2.11.9 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | localizations | Section2.3.102.3.11 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | media | Sections 2.5.7, | | | | 2.9.2, and 2.11.7 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | members | Section 2.9.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | name | Section 2.5.5 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | nicknames | Section2.5.52.5.6 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | notes | Section 2.11.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | onlineServices | Section 2.7.2 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | organizations | Section 2.9.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | personalInfo | Sections 2.10.1, | | | | 2.10.2, and| | | |2.10.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | phones | Section 2.7.6 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | preferredLanguages | Section 2.7.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | prodId | Section 2.11.5 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | relatedTo | Section 2.9.5 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | schedulingAddresses | Section 2.13.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | speakToAs | Section 2.5.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | titles | Section 2.9.6 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | uid | Section 2.11.8 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Card | updated | Section 2.11.6 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | CryptoKey | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | CryptoKey | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | CryptoKey | kind | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | CryptoKey | label | Section 2.11.11 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | CryptoKey | mediaType | Section2.3.122.3.14 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | CryptoKey | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | CryptoKey | uri | Section 2.12.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Directory | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Directory | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Directory | kind | Sections 2.4.3 and | | | |and2.10.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Directory | label | Section 2.11.11 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Directory | listAs | Section2.3.92.3.10 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Directory | mediaType | Section2.3.122.3.14 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Directory | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Directory | uri | Sections 2.4.3 and | | | |and2.10.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | EmailAddress | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | EmailAddress | address | Section 2.7.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | EmailAddress | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | EmailAddress | label | Section 2.11.11 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | EmailAddress | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | LanguagePref | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | LanguagePref | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | LanguagePref | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Link | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Link | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Link | kind |SectionsSection 2.9.1 || | | and 2.11.9 | +-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Link | label | Section 2.11.11 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Link | mediaType | Section2.3.122.3.14 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Link | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Link | uri | Sections 2.9.1 and | | | |and2.11.9 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Media | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Media | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Media | kind | Sections 2.5.7, | | | | 2.9.2, and 2.11.7 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Media | label | Section 2.11.11 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Media | mediaType | Section2.3.122.3.14 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Media | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Media | uri | Sections 2.5.7, | | | | 2.9.2, and 2.11.7 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Name | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Name | components | Sections 2.5.5 and | | | |and3.3.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Name | defaultSeparator | Sections 2.5.5 and | | | |and3.3.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Name | full | Section 2.5.2 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Name | phoneticScript | Sections2.3.132.3.15 and | | | |and 2.3.172.3.19 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Name | phoneticSystem | Section2.3.132.3.15 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Name | isOrdered | Sections 2.5.5 and | | | |and3.3.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Name | sortAs | Section2.3.192.3.21 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | NameComponent | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | NameComponent | kind | Section 2.5.5 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | NameComponent | phonetic | Section2.3.132.3.15 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | NameComponent | value | Section 2.5.5 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Nickname | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Nickname | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Nickname | name | Section 2.5.5 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Nickname | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Note | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Note | author | Sections 2.3.2 and | | | |and2.3.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Note | created | Section2.3.52.3.6 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Note | note | Section 2.11.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | OnlineService | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | OnlineService | contexts | Section2.3.20 | +-------------------+---------------------+-------------------------+ | OnlineService | kind | Sections 2.7.2 | | | | and 2.7.52.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | OnlineService | label | Section 2.11.11 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | OnlineService | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | OnlineService | service | Section2.3.182.3.20 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | OnlineService | uri | Sections 2.7.2 and | | | |and2.7.5 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | OnlineService | user | Section2.3.222.3.24 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | OrgUnit | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | OrgUnit | name | Section 2.9.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | OrgUnit | sortAs | Section2.3.192.3.21 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Organization | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Organization | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Organization | name | Section 2.9.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Organization | sortAs | Section2.3.192.3.21 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Organization | units | Section 2.9.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PartialDate | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PartialDate | calendarScale | Section 2.3.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PartialDate | day | Section 2.2.2 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PartialDate | month | Section 2.2.2 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PartialDate | year | Section 2.2.2 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PatchObject | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PersonalInfo | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PersonalInfo | kind | Sections 2.10.1, | | | | 2.10.2, and| | | |2.10.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PersonalInfo | listAs | Section2.3.92.3.10 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PersonalInfo | level | Section2.3.112.3.13 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | PersonalInfo | value | Sections 2.10.1, | | | | 2.10.2, and| | | |2.10.3 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Phone | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Phone | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Phone | features | Section 2.7.6 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Phone | label | Section 2.11.11 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Phone | number | Section 2.7.6 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Phone | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Pronouns | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Pronouns | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Pronouns | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Pronouns | pronouns | Section 2.5.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Relation | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Relation | relation | Section 2.9.5 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Resource | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | SchedulingAddress | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | SchedulingAddress | contexts | Section2.3.202.3.22 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | SchedulingAddress | label | Section 2.11.11 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | SchedulingAddress | pref | Section2.3.152.3.17 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | SchedulingAddress | uri | Section 2.13.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | SpeakToAs | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | SpeakToAs | grammaticalGender | Section 2.5.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | SpeakToAs | pronouns | Section 2.5.4 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | AddressComponent | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | AddressComponent | kind | Section 2.6.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | AddressComponent | value | Section 2.6.1 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Timestamp | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Timestamp | utc | Section 2.2.2 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Title | @type | not applicable |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Title | kind | Section 2.9.6 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Title | name | Section 2.9.6 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ | Title | organizationId | Section 2.9.6 |+-------------------+---------------------+-------------------------++-------------------+---------------------+---------------------+ Table 8: Conversion Rules for JSContact Types and Properties Acknowledgements The definition and examples of the PHONETIC (Section2.3.13)2.3.15) and SCRIPT (Section2.3.17)2.3.19) parameters are based on the initial draft version of [vOBJECT]. Authors' Addresses Mario Loffredo IIT-CNR/Registro.it Via Moruzzi, 1 56124 Pisa Italy Email: mario.loffredo@iit.cnr.it URI: https://www.iit.cnr.it Robert Stepanek Fastmail PO Box 234 Collins St. West Melbourne VIC 8007 Australia Email: rsto@fastmailteam.com URI: https://www.fastmail.com