<?xml version="1.0"encoding="utf-8"?>encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="4"?> <?rfc compact="yes"?> <?rfc subcompact="yes"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?> <?rfc iprnotified="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true"docName="draft-ietf-calext-jscontact-vcard-13"docName="draft-ietf-calext-jscontact-vcard-14" number="9555" ipr="pre5378Trust200902" tocInclude="true" tocDepth="4" sortRefs="true" symRefs="true" updates="6350" obsoletes="" xml:lang="en" version="3"> <!--[rfced] *AD, please review the following changes that were submitted after the document was approved and let us know if you approve. The updates can be viewed in this diff file: https://www.rfc-editor.org/authors/rfc9555-ad-diff.html Section 2.3.10 ("Novelist" instead of "Boss" and "Écrivain" instead of "Patron" in Figure 5) Section 2.5.2 (removal of comma in Figure 11) Section 2.6.1 (removal of comma in Figure 16) Section 2.9.6 ("organizationId" instead of "organization" - two instances; "Research Scientist" instead of "Project Leader" and "Project Leader" instead of "Research Scientist" in Figure 28) Section 3.2.1 (addition of comma in Figure 51) Section 3.3.1 (addition of text under "Format definition") Appendix A ("organizationId" instead of "organization") --> <!--[rfced] Would you like to update the short title that spans the header of the PDF file to be more descriptive? Note that there is ample room if you want to use the document's title instead. Please let us know your preference. Original: jscontact-vcard Perhaps: Converting JSContact and vCard --> <!-- xml2rfc v2v3 conversion 3.12.10 --> <front> <titleabbrev="jscontact-vcard">JSContact:abbrev="JSContact-vCard">JSContact: Converting from and to vCard</title> <seriesInfoname="Internet-Draft" value="draft-ietf-calext-jscontact-vcard-13"/>name="RFC" value="9555"/> <author fullname="Mario Loffredo" initials="M." surname="Loffredo"> <organization>IIT-CNR/Registro.it</organization> <address> <postal> <street>ViaMoruzzi,1</street>Moruzzi, 1</street> <city>Pisa</city><country>IT</country><country>Italy</country> <code>56124</code> </postal> <email>mario.loffredo@iit.cnr.it</email> <uri>https://www.iit.cnr.it</uri> </address> </author> <author fullname="Robert Stepanek" initials="R." surname="Stepanek"> <organization>Fastmail</organization> <address> <postal><street>PO<extaddr>PO Box234, Collins St234</extaddr> <street>Collins St. West</street> <city>Melbourne</city><country>AU</country> <code>VIC 8007</code><region>VIC</region> <code>8007</code> <country>Australia</country> </postal> <email>rsto@fastmailteam.com</email> <uri>https://www.fastmail.com</uri> </address> </author> <dateyear="2023" month="September" day="18"/> <area>Applications</area>year="2024" month="March"/> <area>art</area> <workgroup>calext</workgroup> <keyword>JSON</keyword> <keyword>contacts</keyword> <keyword>vCard</keyword> <keyword>jCard</keyword> <abstract> <!--[rfced] Since this document does not officially "update" RFC 9553, should "it updates" be changed to "it expands on" or "it builds upon" to avoid any confusion for the reader? Please review and let us know your preference. Original: To achieve this, it updates RFC I-D.ietf-calext-jscontact (JSContact) by registering new JSContact properties. Perhaps: To achieve this, it expands on RFC 9553 ("JSContact: A JSON Representation of Contact Data") by registering new JSContact properties. --> <t>This document defines how to convert contact information between the JSContact and vCard data formats. To achieve this, it updatesRFC I-D.ietf-calext-jscontact (JSContact)<xref target="RFC9553"/> ("JSContact: A JSON Representation of Contact Data") by registering new JSContact properties. Similarly, it updates RFC 6350(vCard)("vCard Format Specification") by registering new vCard properties and parameters.</t> </abstract> </front> <middle> <section> <name>Introduction</name> <section> <name>Motivation</name> <t>The JSContact data model and format <xreftarget="I-D.ietf-calext-jscontact"/>target="RFC9553"/> aims to be an alternative to the widely used vCard standard <xref target="RFC6350"/>standardand jCard format <xref target="RFC7095"/>.</t> <t>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 dataalsoin JSContact.</t> <t>To achieve this, this document defines standard rules to convert contact data between JSContact and vCard (and consequently jCard). </t> </section> <section anchor="notational-conventions" numbered="true" toc="default"> <name>Notational Conventions</name> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </section> <section anchor="abnf-notations"> <name>ABNF Notations</name> <t>The ABNF definitions in this document use the notations of <xref target="RFC5234"/>. ABNF rules not defined in this documenteitherare defined in either <xref target="RFC5234"/> (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT) or <xref target="RFC6350"/>. </t> </section> </section> <section anchor="vcard-jscontact-conversion"> <name>Converting vCard to JSContact</name> <t>This section contains the conversion rules from the vCard to the JSContact Card. It follows the same structure asthevCard v4 <xreftarget="RFC6350">vCard v4</xref>.target="RFC6350"/>. Properties and parameters of vCard extension RFCs, includingthethose described in "vCard Format Extension for JSContact" <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions">vCard JSContact Extension</xref> aretarget="RFC9554"/>, have been added to the appropriate subsections.</t> <section> <name>Generalrules</name>Rules</name> <section> <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in fixed-width font. In the txt output, there are no changes to the font, and the quotation marks have been removed. In the html and pdf outputs, the text enclosed in <em> is output in italics. In the txt output, the text enclosed in <em> appears with an underscore before and after. Please review carefully and let us know if the output is acceptable. Also, please review if each term is consistently tagged and let us know if any updates are needed. For instance, we notice that some terms are enclosed with <tt> whereas others are not or are enclosed with quote marks. Below are a few examples; please see the text for more instances. In the XML file (Sections 2.4.3, 2.10.3, and 2.10.4, respectively): The <tt>kind</tt> property is set to <tt>entry</tt> The <tt>kind</tt> property is set to "interest". The kind property is set to directory. --> <name>The <tt>uid</tt>property</name>Property</name> <t>The UID property in vCard is optional, but the <tt>uid</tt> property in JSContact is mandatory. Implementations that convert a vCard without a UID property <bcp14>MUST</bcp14> generate a unique identifier as a value for the <tt>uid</tt> property. This value <bcp14>SHOULD</bcp14> be the same when converting the same vCard multiple times, but how to achieve this is implementation-specific.</t> </section> <section> <name>Choosingidentifiers</name>Identifiers</name> <t>Multivalued properties in JSContacttypicallyare typically represented as a JSON object where the object keys are of the <tt>Id</tt> type and the object values are the converted vCard property. In the absence of the PROP-ID parameter (see <xref target="vcard-param-propid"/>), implementations are free to choose any identifier for such entries. Whatever identifier generation scheme implementations use, they <bcp14>MUST</bcp14> generate values that are valid according to the definition of the <tt>Id</tt> type in <xreftarget="I-D.ietf-calext-jscontact"/>.target="RFC9553"/>. For example, this could be an incrementing number across all <tt>Id</tt>s or only unique within one JSON object.</t> </section> </section> <!--[rfced] Within Sections 2.1 to 2.14, there is inconsistency in the way the property and parameter names are introduced, i.e., some of the lead-in sentences begin with "This" and some begin with the names. We made this consistent by replacing "This" with the property/parameter names. Please review. One example Original: This converts to the JSContact Boolean type. Current: The BOOLEAN type converts to the JSContact Boolean type. --> <section anchor="vcard-types"> <name>vCard Value Data Types</name> <section> <name>BOOLEAN</name><t>This<t>The BOOLEAN type converts to the JSContact <tt>Boolean</tt> type.</t> </section> <section anchor="vcard-type-datetime"> <name>DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP</name> <t>The TIMESTAMP type generally converts to the<tt>UTCDateTime</tt>.<tt>UTCDateTime</tt> type. It converts to the <tt>Timestamp</tt> type for anniversaries.</t> <t>The DATE type converts to the <tt>PartialDate</tt> type, whichonlyis only relevant for anniversaries. This does not apply to DATE values that only define a month oraday.</t> <t>The TIME, DATE-TIME, and DATE-AND-OR-TIME types and DATE type values that only define a month or day do not convert to a JSContact datetime type. Instead, vCard properties or parameters having such values convert to the properties defined in <xref target="new-jscontact"/>.</t> </section> <section> <name>INTEGER</name><t>This<t>The INTEGER type converts to the JSContact <tt>Int</tt> and <tt>UnsignedInt</tt> types.</t> </section> <section> <name>FLOAT</name><t>This<t>The FLOAT type converts to the JSContact <tt>Number</tt> type.</t> </section> <section> <name>LANGUAGE-TAG</name><t>This<t>The LANGUAGE-TAG type converts to the JSContact <tt>String</tt> type.</t> </section> <section> <name>TEXT</name><t>This<t>The TEXT type converts to the JSContact <tt>String</tt> type.</t> </section> <section> <name>URI</name><t>This<t>The URI type converts to the JSContact <tt>String</tt> type.</t> </section> <section> <name>UTC-OFFSET</name><t>This<t>The UTC-OFFSET type either converts to a <tt>String</tt> containing an IANATimeZoneTime Zone Database entry name (see <xreftarget="vcard-prop-tz"/>),target="vcard-prop-tz"/>) oritdoes not convert to any JSContact type. For the latter, vCard properties or parameters having such values <bcp14>MAY</bcp14> convert to JSContact as defined in <xref target="new-jscontact"/>. </t> </section> </section> <section anchor="vcard-parameters"> <name>vCard Parameters</name> <t>This section contains the conversion rules for vCard parameters. A rule typicallyonlyapplies only for specific vCard properties. To convert a vCard parameter on an arbitrary vCard property, see <xref target="jscontact-prop-vcardparams"/>.</t> <section anchor="vcard-param-altid"> <name>ALTID</name><t>This<t>The ALTID parameter 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 ofthisthis, see <xref target="vcard-prop-adr"/>. To preserve the verbatim value of the ALTID parameter, set the JSContact properties defined in <xref target="new-jscontact"/>.</t> </section> <section anchor="vcard-param-author"> <name>AUTHOR</name> <t>The AUTHOR parameter value of a vCard NOTE property converts to the <tt>uri</tt> property of the Author object for this note.</t> <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). Please also consider if any of the notes should perhaps be combined with the preceding paragraphs. For example: Original: The AUTHOR parameter value of a vCard NOTE property converts to the uri property of the Author object for this note. Note: This parameter is defined in [RFCYYY2]. Perhaps: A) The AUTHOR parameter value [RFC9554] of a vCard NOTE property converts to the uri property of the Author object for this note. or B) The AUTHOR parameter value of a vCard NOTE property converts to the uri property of the Author object for this note. The AUTHOR parameter is defined in [RFC9554]. --> <t>Note: This parameter is defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-param-author-name"> <name>AUTHOR-NAME</name> <t>The AUTHOR-NAME parameter value of a vCard NOTE property converts to the <tt>name</tt> property of the Author object for this note.</t> <t>Note: This parameter is defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-param-calscale"> <name>CALSCALE</name><t>This<t>The CALSCALE parameter set on a BDAY,DEATHDATEDEATHDATE, or ANNIVERSARY property converts to the <tt>calendarScale</tt> property of the <tt>PartialDate</tt> object type.</t> </section> <section anchor="vcard-param-created"> <name>CREATED</name> <t>The CREATED parameter value of a vCard NOTE property converts to the <tt>created</tt> property of the Note object.</t> <t>Note: This parameter is defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-param-derived"> <name>DERIVED</name> <t>Ifthisthe DERIVED parameter is set to <tt>true</tt> on a vCard property, then implementations <bcp14>MAY</bcp14> choosetonot to convert thatproperty. Note:property.</t> <t>Note: This parameter is defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-param-geo"> <name>GEO</name><t>This<t>The GEO parameter set on an ADR property converts to the JSContact <tt>coordinates</tt> property of the <tt>Address</tt> object that represents the vCard ADR.</t> </section> <section anchor="vcard-param-group"> <name>GROUP</name><t>This<t>The GROUP parameterexclusivelyis exclusively for use in jCard (see <xref target="RFC7095" sectionFormat="of" section="7.1"/>). It <bcp14>MUST NOT</bcp14> 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 <bcp14>MAY</bcp14> set the <tt>group</tt> parameter in the JSContact properties <tt>vCardProps</tt> or <tt>vCardParams</tt> as defined in <xref target="new-jscontact"/>.</t> <figure anchor="group_conversion_params"><name>An example how<name>Example of How topreservePreserve thegroup nameGroup Name in <tt>vCardParams</tt> duringconversion.</name> <artwork><![CDATA[Conversion</name> <!-- [rfced] We updated <artwork> to <sourcecode> for all examples; please review and let us know if any further updates are needed. In addition, please consider whether the "type" attribute should be set for all sourcecode elements in the XML file. The current list of preferred values for "type" is available at https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> <sourcecode type=""><![CDATA[ item1.TEL;VALUE=uri:tel:+1-555-555-5555 "phones": { "p1": { "number": "tel:+1-555-555-5555", "vCardParams" : { "group" : "item1" } } }]]></artwork>]]></sourcecode> </figure> <figure anchor="group_conversion_props"><name>An example how<name>Example of How topreservePreserve thegroup nameGroup Name in <tt>vCardProps</tt> duringconversion.</name> <artwork><![CDATA[Conversion</name> <sourcecode><![CDATA[ item2.X-FOO:bar "vCardProps": [ ["x-foo", { "group": "item2" }, "unknown", "bar"] ]]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-param-index"> <name>INDEX</name><t>This<t>The INDEX parameter set on the EXPERTISE, HOBBY,INTERESTINTEREST, and ORG-DIRECTORY properties defined in <xref target="RFC6715"/> converts to the JSContact <tt>listAs</tt> property of the <tt>PersonalInfo</tt> and <tt>Directory</tt> objects.</t> </section> <section anchor="vcard-param-language"> <name>LANGUAGE</name><t>This<t>The LANGUAGE parameter converts to an entry in the <tt>localizations</tt> property for the vCard property that this parameter is set on. The value of the LANGUAGE parameter defines the language tag key in the <tt>localizations</tt> property.</t> <t>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.</t> <t>Two options to populate the localizations property are:</t> <ul> <li>One PatchPerper 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.</li> <li>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.</li> </ul> <t>Generally, localizations only localize properties that are present in the non-localized version of this Card. <xref target="language-patch-dominant-language"/> illustrates this.</t> <figure anchor="language-patch-dominant-language"> <name>LANGUAGEconversion example: one dominant language</name> <artwork><![CDATA[Conversion Example: One Dominant Language</name> <sourcecode type=""><![CDATA[ FN;LANGUAGE=EN:John Doe TITLE;LANGUAGE=EN:Boss TITLE;LANGUAGE=fr:Patron "language": "en", "name": { "full": "John Doe" }, "titles": { "t1": { "name": "Boss" } }, "localizations": { "fr": { "titles/t1/name": "Patron" } }]]></artwork>]]></sourcecode> </figure> <!--[rfced] Please clarify "choose them to" in the following sentence. Does this perhaps mean "add them to" or "place them under"? Original: As a special case, if one or more vCard properties of the same type do not have the LANGUAGE parameter set, then choose them to the non-localized Card. Perhaps: As a special case, if one or more vCard properties of the same type do not have the LANGUAGE parameter set, add them to the non-localized Card. --> <t>As a special case, if one or more vCard properties of the same type do not have the LANGUAGE parameter set, then choose them to the non-localized Card. Convert any with LANGUAGE parameters to the localizations property. <xref target="language-patch-no-language"/> illustrates this.</t> <figure anchor="language-patch-no-language"> <name>LANGUAGEconversion example: propertyConversion Example: Property withoutlanguage</name> <artwork><![CDATA[Language</name> <sourcecode type=""><![CDATA[ FN:John Doe TITLE:Boss TITLE;LANGUAGE=fr:Patron "name": { "full": "John Doe" }, "titles": { "t1": { "name": "Boss" } }, "localizations": { "fr": { "titles/t1/name": "Patron" } }]]></artwork>]]></sourcecode> </figure> <t>As theleast preferredleast-preferred option, <xref target="language-patch-no-dominant"/> illustrates how all vCard properties of the same type have the LANGUAGE parameter set, but none of their language tags match the language of the main Card. In this case, implementations <bcp14>MAY</bcp14> choose to add the localized vCard properties only to the localizations object.</t><t>The<!--[rfced] We updated the following text as shown below since the non-ASCII characters (in Figures 5 and 6) display in the .txt file as well as in the HTML and PDF files. Please let us know of any concerns. Original: The following example uses non-ASCII characters to demonstrate multilingual content. The ASCII-formatted version of this specification might not show the correct characters. Please refer to the HTML or PDF versionsinstead.</t>instead. Current: The following example uses non-ASCII characters to demonstrate multilingual content. --> <t>The following example uses non-ASCII characters to demonstrate multilingual content.</t> <figure anchor="language-patch-no-dominant"> <name>LANGUAGEconversion example: conflictingConversion Example: Conflicting LANGUAGEpropertyProperty andparameter values</name> <artwork><![CDATA[Parameter Values</name> <sourcecode type=""><![CDATA[ LANGUAGE:es FN:Gabriel García MárquezTITLE;LANGUAGE=en:Boss TITLE;LANGUAGE=fr:PatronTITLE;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" } } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-param-level"> <name>LEVEL</name> <t>The LEVEL parameter <xref target="RFC6715"/> converts to the <tt>level</tt> property of the <tt>PersonalInfo</tt> type. If this parameter is set on the EXPERTISE property, then its values convertas:as follows: </t> <ul spacing="compact"> <li>"beginner" converts to "low";</li> <li>"average" converts to"medium";</li>"medium"; and</li> <li>"expert" converts to "high".</li> </ul> <t>In all othercasescases, the values convert verbatim, but lowercase <bcp14>MUST</bcp14> be used for the JSContact value.</t> </section> <section anchor="vcard-param-mediatype"> <name>MEDIATYPE</name><t>This<t>The MEDIATYPE parameter converts to the <tt>mediaType</tt> property of the <tt>Resource</tt> object type.</t> </section> <section anchor="vcard-param-phonetic"> <name>PHONETIC</name><t>This<!-- [rfced] May we update these 2 sentences for clarity by rephrasing the lead-in sentence and making the second sentence a complete sentence as shown below? Original: This parameter as well as the SCRIPT (Section 2.3.17) parameter set on a N or ADR property convert to JSContact as follows: the values of the phonetic, phoneticScript and phoneticSystem properties of the NameComponent and Name or AddressComponent and Address object types, respectively. Perhaps: When the PHONETIC parameter as well as the SCRIPT (Section 2.3.17) parameter are set on an N or ADR property, they convert to JSContact as described below. The values of the phonetic, phoneticScript, and phoneticSystem properties convert to values in the NameComponent, Name or AddressComponent, and Address object types, respectively. --> <t>The PHONETIC parameter as well as the <xref target="vcard-param-script">SCRIPT</xref> parameter set onaan N or ADR property convert to JSContact as follows:</t> <t>the values of the <tt>phonetic</tt>, <tt>phoneticScript</tt> and <tt>phoneticSystem</tt> properties of the NameComponent and Name or AddressComponent and Address object types, respectively.</t> <t>The related N or ADR property is defined by the vCard ALTID parameter. The conversion rules for the <xref target="vcard-prop-n">N</xref> and <xref target="vcard-prop-adr">ADR</xref> properties define how the vCard components convert to JSContact.</t> <t>The value of the PHONETIC parameter converts to the <tt>phoneticSystem</tt> property unless it is <tt>script</tt>, in which case the <tt>phoneticSystem</tt> property is not set. The value of the SCRIPT parameter converts to the <tt>phoneticScript</tt> property.</t> <t>The values of the components in the property value convert to values in the <tt>phonetic</tt> properties for the respective NameComponent or AddressComponent.</t> <t>If more than one propertyhavinghas the PHONETIC parameter set and relates to the same property, then they convert to the Card <tt>localizations</tt> property according to their LANGUAGE parameter values as outlined in <xref target="vcard-param-language"/>.</t> <figure anchor="phonetic_conversion"> <name>PHONETICconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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" } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-param-pid"> <name>PID</name><t>This<t>The PID parameter converts to an entry in the <tt>vCardParams</tt>property,property; see <xref target="jscontact-prop-vcardparams"/>.</t> </section> <section anchor="vcard-param-pref"> <name>PREF</name><t>This<t>The PREF parameter converts to the <tt>pref</tt> property.</t> </section> <section anchor="vcard-param-propid"> <name>PROP-ID</name> <t>The PROP-ID parameter value of a vCard property converts to the <tt>Id</tt> of the JSContact property to which the vCard property converts.</t> <figure anchor="propid_conversion"> <name>PROP-IDconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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" } }]]></artwork>]]></sourcecode> </figure> <t>Note: This parameter is defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-param-script"> <name>SCRIPT</name><t>See<t>For the SCRIPT parameter, see <xref target="vcard-param-phonetic"/>.</t> </section> <section anchor="vcard-param-service-type"> <name>SERVICE-TYPE</name><t>This<t>The SERVICE-TYPE parameter converts to the <tt>service</tt> property of the <tt>OnlineService</tt> object type.Note:</t> <t>Note: This parameter is defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-param-sortas"> <name>SORT-AS</name><t>This<t>The SORT-AS parameter converts to the <tt>sortAs</tt> properties defined for the <tt>Name</tt>,<tt>Organization</tt><tt>Organization</tt>, and <tt>OrgUnit</tt> object types.</t> </section> <section anchor="vcard-param-type"> <name>TYPE</name><t>This<!--[rfced] Would it be correct to say "property-specific kind values" instead of "property-specific kind property values" to avoid redundancy? Original: This converts to the contexts property as well as property-specific kind property values defined in later sections. Perhaps: The TYPE parameter converts to the contexts property as well as property-specific kind values defined in later sections. --> <t>The TYPE parameter converts to the <tt>contexts</tt> property as well as property-specific <tt>kind</tt> property values defined in later sections. If not specified otherwise for a specific JSContact property, the vCard <tt>home</tt> and <tt>work</tt> parameter values convert to the JSContact <tt>private</tt> and <tt>work</tt> contexts, respectively.</t> </section> <section anchor="vcard-param-tz"> <name>TZ</name><t>This<t>The TZ parameter set on an ADR property converts to the JSContact <tt>timeZone</tt> property of the <tt>Address</tt> object that represents the vCard ADR. Also see the conversion of the TZ property in <xref target="vcard-prop-tz"/>.</t> </section> <section anchor="vcard-param-username"> <name>USERNAME</name><t>This<t>The USERNAME parameter converts to the <tt>user</tt> property of the <tt>OnlineService</tt> objecttype. Note:type.</t> <t>Note: This parameter is defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-param-value"> <name>VALUE</name><t>This<t>The VALUE parameter does not convert to an IANA-registered property in JSContact. To preserve properties with experimental values, see Sections <xreftarget="jscontact-prop-vcardparams"/>target="jscontact-prop-vcardprops" format="counter"/> and <xreftarget="jscontact-prop-vcardprops"/>.</t>target="jscontact-prop-vcardparams" format="counter"/>.</t> </section> </section> <section> <name>General Properties</name> <section> <name>BEGIN and END</name><t>These<t>The BEGIN and END properties do not convert to IANA-registered properties in JSContact.</t> </section> <section anchor="vcard-prop-kind"> <name>KIND</name> <t>The KIND property converts to the <tt>kind</tt> property (<xref target="kind_conversion"/>). Allowed values are those described inSection 6.1.4 of<xreftarget="RFC6350"/>target="RFC6350" sectionFormat="of" section="6.1.4"/> and extended with the values declared in <xref target="RFC6473"/> and <xref target="RFC6869"/>.</t> <figure anchor="kind_conversion"> <name>KINDconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ KIND:individual "kind": "individual"]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-source"> <name>SOURCE</name> <t>The SOURCE property converts to a Directory object in the <tt>directories</tt> property (<xref target="source_conversion"/>). The <tt>kind</tt> property is set to <tt>entry</tt>. The <tt>uri</tt> property is set to the SOURCE property value.</t> <t>The PREF and MEDIATYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="source_conversion"> <name>SOURCEconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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" } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-xml"> <name>XML</name><t>This<t>The XML property converts to an entry in the <tt>vCardProps</tt>property,property; see <xref target="jscontact-prop-vcardprops"/>.</t> </section> </section> <section> <name>Identification Properties</name> <section anchor="vcard-prop-anniversary"> <name>BDAY, BIRTHPLACE, DEATHDATE, DEATHPLACE, and ANNIVERSARY</name> <t>The BDAY and ANNIVERSARY properties and the extensions BIRTHPLACE, DEATHDATE, and DEATHPLACE described in <xref target="RFC6474"/> are represented as <tt>Anniversary</tt> objects and are included in the <tt>anniversaries</tt> property (<xref target="anniversary_conversion"/>):</t> <ul spacing="compact"><li> <t>BDAY<li>BDAY and BIRTHPLACE convert to <tt>date</tt> and <tt>place</tt> where <tt>kind</tt> is set to"birth";</t> <t/>"birth"; </li><li> <t>DEATHDATE<li>DEATHDATE and DEATHPLACE convert to <tt>date</tt> and <tt>place</tt> where <tt>kind</tt> is set to"death";</t> <t/>"death"; and </li> <li>ANNIVERSARY converts to <tt>date</tt> where <tt>kind</tt> is set to "wedding".</li> </ul> <t>Both birth and death places are represented as instances of the <tt>Address</tt> object.</t> <t>The BIRTHPLACE and DEATHPLACE properties that are represented as geo URIs convert to <tt>Address</tt> instancesincludingthat only include the <tt>coordinates</tt> property. If the URI value is not a geo URI, the place is ignored.</t> <t>The ALTID and LANGUAGE parameters of both the BIRTHPLACE and DEATHPLACE properties convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="anniversary_conversion"> <name>BDAY, BIRTHPLACE, DEATHDATE, DEATHPLACE, and ANNIVERSARYconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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 } } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-fn"> <name>FN</name> <t>The FN property converts to the Name object in the <tt>name</tt> property. Its value converts to the Name object <tt>full</tt> property (<xref target="fn_conversion"/>). If the LANGUAGE parameter is set, then the FN property converts as outlined in <xref target="vcard-param-language"/>. In the unexpected casethatwhere the vCard contains more than one FN property without the LANGUAGE parameter,thenconvert the FN property that has the least parameters set to the <tt>full</tt> property. If multiple such FN properties are present, choose any of them. All other FN properties convert to the <xref target="jscontact-prop-vcardprops"><tt>vCardProps</tt></xref> property.</t> <figure anchor="fn_conversion"> <name>FNconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ FN:John Q. Public, Esq. "name": { "full": "John Q. Public,Esq.",Esq." }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-gender"> <name>GENDER</name><t>This<t>The GENDER property does not map to an IANA-registered property in JSContact. To convert this property, see <xref target="jscontact-prop-vcardprops"/>. Note the alternative JSContact <tt>speakToAs</tt> propertywhichthat defines how to address and refer to an individual represented by the card, as do the newly defined vCard GRAMGENDER and PRONOUNS properties of <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-prop-gramgender"> <name>GRAMGENDER and PRONOUNS</name> <t>The GRAMGENDER property converts to the <tt>grammaticalGender</tt> property of the <tt>SpeakToAs</tt> object (<xref target="grammatical_gender_pronouns_conversion"/>).</t> <t>The PRONOUNS property converts to an entry in the <tt>pronouns</tt> property of the <tt>SpeakToAs</tt> object (<xref target="grammatical_gender_pronouns_conversion"/>).</t> <figure anchor="grammatical_gender_pronouns_conversion"> <name>GRAMGENDER and PRONOUNSconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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 } } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-n"> <name>N</name> <t>The N property converts to the Name object in the <tt>name</tt> property. Each component in the N property structured value converts to a NameComponent in the Name <tt>components</tt> property. The following table shows this relation:</t> <!--[rfced] In Table 1, does "in here" mean "listed in this table" as shown below? Original: To vCard: add any surname2 NameComponent value in here, after all surname values. To vCard: add any generation NameComponent value also in here. Perhaps: To vCard: add any surname2 NameComponent value listed in this table, after all surname values. To vCard: add any generation NameComponent value listed in this table. --> <table anchor="n_kind_conversion"> <name>Ncomponents conversion</name>Components Conversion</name> <thead> <tr> <th align="left">N component</th> <th align="left">NameComponent kind</th> <th align="left">Remarks</th> </tr> </thead> <tbody> <tr> <td align="left">Family name</td> <td align="left">surname</td> <td align="left">To vCard: add any <tt>surname2</tt> NameComponent value in here, after all <tt>surname</tt> values.<br/>From vCard: ignore any value that also occurs in the Secondary surname component.</td> </tr> <tr> <td align="left">Given name</td> <td align="left">given</td> <td align="left"/> </tr> <tr> <td align="left">Additional name</td> <td align="left">given2</td> <td align="left"/> </tr> <tr> <td align="left">Honorific prefix</td> <td align="left">title</td> <td align="left"/> </tr> <tr> <td align="left">Honorific suffix</td> <td align="left">credential</td> <td align="left">To vCard: add any <tt>generation</tt> NameComponent value also in here.<br/>From vCard: ignore any value that also occurs in the Generation component.</td> </tr> <tr> <td align="left">Secondary surname</td> <td align="left">surname2</td> <td align="left"/> </tr> <tr> <td align="left">Generation</td> <td align="left">generation</td> <td align="left"/> </tr> </tbody> </table> <t>If the <xref target="vcard-param-jscomps">JSCOMPS</xref> parameter is set, then the Name <tt>isOrdered</tt> property value is "true", and the <tt>defaultSeparator</tt> and any separator name components are set according to the parameter value. The <tt>components</tt> list <bcp14>MUST</bcp14> adhere to the order of the JSCOMPS parameter value.</t> <t>If the JSCOMPS parameter is not set, then the Name <tt>isOrdered</tt> property value is"false""false", and the <tt>defaultSeparator</tt> property <bcp14>MUST NOT</bcp14> be set. The <tt>components</tt> list <bcp14>MUST</bcp14> follow the order of values in the N structured value when read from left to right.</t> <t>If the SORT-AS parameter is set, then its structured value converts to the Name <tt>sortAs</tt> property according to <xref target="n_kind_conversion"/>. An empty or non-existent component value indicates that no sort is defined for this kind.</t> <!--[rfced] The following lines are longer than the 72-character limit for sourcecode. Please let us know where breaks should be placed for the following lines: Original: (Figure 13) N;SORT-AS="Stevenson,John Philip":Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr. (16 over) (Figure 16) ADR;TYPE=work;CC=US:;;54321 Oak St;Reston;VA;20190;USA;;;;Oak St;54321;;;;; (6 over) (Under "Format definition" in Section 3.3.1) (jscomps-entry-sep / "") ";" jscomps-entrylist (4 over) jscomps-entry-verb = *QSAFE-CHAR ; encode special characters according to RFC 6868 (16 over) (Figure 53) N;JSCOMPS=";1;2;2,1;0;6;4,1":Stevenson;John;Philip,Paul;;Jr.,M.D.;;Jr. (4 over) (Figure 54) ADR;JSCOMPS="s,\, ;11;s, ;10;3":;;54321 Oak St;Reston;;;;;;;Oak St;54321;;;;;; (12 over) --> <figure anchor="n_conversion"> <name>Nconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ N;SORT-AS="Stevenson,John 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" } }]]></artwork>]]></sourcecode> </figure> <t>See <xref target="vcard-param-jscomps-examples"/> for examples of using the JSCOMPS parameter forvCard structuredvCard-structured property values.</t> </section> <section anchor="vcard-prop-nickname"> <name>NICKNAME</name><t>A<t>The NICKNAME property converts to a Nickname object in the <tt>nicknames</tt> property (<xref target="nickname_conversion"/>). The <tt>name</tt> property is set to the NICKNAME property value.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="nickname_conversion"> <name>NICKNAMEconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ NICKNAME:Johnny "nicknames": { "NICK-1": { "name": "Johnny" } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-photo"> <name>PHOTO</name><t>A<t>The PHOTO property converts to an entry in the <tt>media</tt> property (<xref target="photo_conversion"/>). The entry value is a <tt>Media</tt> object whose <tt>kind</tt> property is set to <tt>photo</tt> and <tt>uri</tt> property is set to the PHOTO value.</t> <t>The PREF and MEDIATYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="photo_conversion"> <name>PHOTOconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ PHOTO:https://www.example.com/pub/photos/jqpublic.gif "media": { "PHOTO-1": { "kind": "photo", "uri": "https://www.example.com/pub/photos/jqpublic.gif" } }]]></artwork>]]></sourcecode> </figure> </section> </section> <section> <name>Delivery Addressing Properties</name> <section anchor="vcard-prop-adr"> <name>ADR</name> <t>The ADR property converts to an Address object in the <tt>addresses</tt> property. Each component in theADRADR-structured propertystructuredvalue converts to an AddressComponent in the Address <tt>components</tt> property.</t> <t><xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>target="RFC9554"/> defines newcomponentcomponents for the ADR property. Implementations <bcp14>SHOULD</bcp14> set these new components, even if all their values are the empty string.</t> <t>The following table shows how the ADR component and AddressComponent kind relate:</t> <!--[rfced] In Table 2 (Section 2.6.1), is it necessary to include two instances of "see Remarks" since the Remarks column is adjacent to the cells? Please review and let us know these instances may be deleted as shown below. Original: apartment (see Remarks) name (see Remarks) Perhaps: apartment name --> <table anchor="adr_kind_conversion"> <name>ADRcomponents conversion</name>Components Conversion</name> <thead> <tr> <th align="left">ADR component</th> <th align="left">AddressComponent kind</th> <th align="left">Remarks</th> </tr> </thead> <tbody> <tr> <td align="left">post office box</td> <td align="left">postOfficeBox</td> <td align="left"><xref target="RFC6350"/> recommends that this component not be set, but thisnowis now disputable given the new components. Instead, set this component and use the new ADR value format defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> <tr> <td align="left">extended address</td> <td align="left">apartment (see Remarks)</td> <td align="left"><t>To vCard:Setset the values of the following components:</t> <ul> <li>room</li> <li>floor</li> <li>apartment</li> <li>building</li> </ul> <t>From vCard:Ignoreignore if the ADR structured value is of the format defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>. Otherwisetarget="RFC9554"/>. Otherwise, convert to <tt>apartment</tt>.</t></td> </tr> <tr> <td align="left">street address</td> <td align="left">name (see Remarks)</td> <td align="left"><t>To vCard:Setset the values of the following components:</t> <ul> <li>number</li> <li>name</li> <li>block</li> <li>direction</li> <li>landmark</li> <li>subdistrict</li> <li>district</li> </ul> <t>From vCard:Ignoreignore if the ADR structured value is of the format defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>. Otherwisetarget="RFC9554"/>. Otherwise, convert to <tt>name</tt>.</t></td> </tr> <tr> <td align="left">locality</td> <td align="left">locality</td> <td align="left"/> </tr> <tr> <td align="left">region</td> <td align="left">region</td> <td align="left"/> </tr> <tr> <td align="left">postal code</td> <td align="left">postcode</td> <td align="left"/> </tr> <tr> <td align="left">apartment</td> <td align="left">apartment</td> <td>Defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> <tr> <td align="left">block</td> <td align="left">block</td> <td>Defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> <tr> <td align="left">building</td> <td align="left">building</td> <td>Defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> <tr> <td align="left">direction</td> <td align="left">direction</td> <td>Defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> <tr> <td align="left">district</td> <td align="left">district</td> <td>Defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> <tr> <td align="left">floor</td> <td align="left">floor</td> <td>Defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> <tr> <td align="left">landmark</td> <td align="left">landmark</td> <td>Defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> <tr> <td align="left">room</td> <td align="left">room</td> <td>Defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> <tr> <td align="left">street number</td> <td align="left">number</td> <td>Defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> <tr> <td align="left">subdistrict</td> <td align="left">subdistrict</td> <td>Defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</td>target="RFC9554"/>.</td> </tr> </tbody> </table> <t>If the <xref target="vcard-param-jscomps">JSCOMPS</xref> parameter is set, then the Address <tt>isOrdered</tt> property value is "true", and the <tt>defaultSeparator</tt> and any separator name components are set according to the parameter value. The <tt>components</tt> list <bcp14>MUST</bcp14> adhere to the order of the JSCOMPS parameter value.</t> <t>If the JSCOMPS parameter is not set, then the Address <tt>isOrdered</tt> property value is"false""false", and the <tt>defaultSeparator</tt> property <bcp14>MUST NOT</bcp14> be set. The <tt>components</tt> list <bcp14>MUST</bcp14> follow the order of values in the ADR structured value when read from left to right.</t><t>The<ul empty="true"> <li>The LABEL parameter converts to the Address <tt>full</tt>property.</t> <t>Theproperty.</li> <li>The GEO parameter converts to the Address <tt>coordinates</tt>property.</t> <t>Theproperty.</li> <li>The TZ parameter converts to the Address <tt>timeZone</tt>property.</t> <t>Theproperty.</li> <li>The CCparameterparameter, as defined in <xreftarget="RFC8605"/>target="RFC8605"/>, converts to the Address <tt>countryCode</tt>property.</t>property.</li> </ul> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>. The ADR-specific values of the TYPE parameter defined in Sections5.1<xref target="RFC9554" sectionFormat="bare" section="5.1"/> and5.2<xref target="RFC9554" sectionFormat="bare" section="5.2"/> of <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>target="RFC9554"/> convert to the corresponding entries of the <tt>contexts</tt> property as defined inSection 2.5.1 of<xreftarget="I-D.ietf-calext-jscontact"/>.</t>target="RFC9553" sectionFormat="of" section="2.5.1"/>.</t> <t>The ALTID and LANGUAGE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>. Each possible language-dependent alternative is represented as an entry of the PatchObject map where the key references the <tt>full</tt> property.</t> <figure anchor="adr_conversion"> <name>ADRconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ ADR;TYPE=work;CC=US:;;54321 Oak St;Reston;VA;20190;USA;;;;Oak St;54321;;;;; "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","US" } }]]></artwork>]]></sourcecode> </figure> <t>See <xref target="vcard-param-jscomps-examples"/> for examples of using the JSCOMPS parameter forvCard structuredvCard-structured property values.</t> </section> </section> <section> <name>Communications Properties</name> <section anchor="vcard-prop-email"> <name>EMAIL</name><t>An<t>The EMAIL property converts to an entry in the <tt>emails</tt> property (<xref target="email_conversion"/>). The entry value is an <tt>EmailAddress</tt> object. The <tt>address</tt> property is set to the EMAIL value.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="email_conversion"> <name>EMAILconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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 } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-impp"> <name>IMPP</name><t>An<t>The IMPP property converts to an entry in the <tt>onlineServices</tt> property (<xref target="impp_conversion"/>). The entry value is an <tt>OnlineService</tt> object. The <tt>vCardName</tt> property is set to"impp""impp", and the <tt>uri</tt> property is set to the IMPP value.</t> <t>The SERVICE-TYPE, USERNAME,PREFPREF, and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="impp_conversion"> <name>IMPPconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ IMPP;PREF=1:xmpp:alice@example.com "onlineServices": { "OS-1": { "uri": "xmpp:alice@example.com", "pref": 1, "vCardName": "impp" } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-lang"> <name>LANG</name><t>A<t>The LANG property converts to an entry in the <tt>preferredLanguages</tt> property (<xref target="lang_conversion"/>). The entry value isana <tt>LanguagePref</tt> object. The LanguagePref <tt>language</tt> property value is the LANG property value.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="lang_conversion"> <name>LANGconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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 } } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-language"> <name>LANGUAGE</name> <t>The LANGUAGE property converts to the <tt>language</tt> property (<xref target="languageprop_conversion"/>).</t> <figure anchor="languageprop_conversion"> <name>LANGUAGEconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ LANGUAGE:de-AT "language": "de-AT"]]></artwork>]]></sourcecode> </figure> <t>Note: This property is defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-prop-socialprofile"> <name>SOCIALPROFILE</name><t>A<t>The SOCIALPROFILE property converts to an entry in the <tt>onlineServices</tt> property (<xref target="socialprofile_conversion"/>). The entry value is an <tt>OnlineService</tt> object. The <tt>vCardName</tt> property is set to"socialprofile""socialprofile", or it can be omitted. If the value type of the SOCIALPROFILE is URI, the <tt>uri</tt> property is set to the SOCIALPROFILE value. Otherwise, the <tt>user</tt> property is set to the SOCIALPROFILE value.</t> <t>The SERVICE-TYPE, USERNAME,PREFPREF, and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="socialprofile_conversion"> <name>SOCIALPROFILEconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ SOCIALPROFILE;SERVICE-TYPE=Mastodon:https://example.com/@foo "onlineServices": { ... "OS-1": { "service": "Mastodon", "uri": "https://example.com/@foo" } }]]></artwork>]]></sourcecode> </figure> <t>Note: This property is defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-prop-tel"> <name>TEL</name><t>A<t>The TEL property converts to an entry in the <tt>phones</tt> property (<xref target="tel_conversion"/>). The entry value is a <tt>Phone</tt> object.</t> <t>The TEL-specific values of the TYPE parameter convert to the <tt>features</tt> property keys as outlined intable<xref target="tel_type_conversion"/>. Note that <xref target="RFC6350" sectionFormat="of" section="6.4.1"/> defines the default TYPE of TEL to be <tt>voice</tt>, but the default Phone features property is absent by default. Accordingly, an implementation <bcp14>SHOULD</bcp14> only set the Phone <tt>features</tt> property if the TEL property actually has a TEL-specific TYPE parameter set.</t> <table anchor="tel_type_conversion"> <name>TEL TYPEconversion</name>Conversion</name> <thead> <tr> <th align="left">TYPE value</th> <th align="left">Phone feature</th> </tr> </thead> <tbody> <tr> <td align="left">cell</td> <td align="left">mobile</td> </tr> <tr> <td align="left">fax</td> <td align="left">fax</td> </tr> <tr> <td align="left">main-number</td> <td align="left">main-number</td> </tr> <tr> <td align="left">pager</td> <td align="left">pager</td> </tr> <tr> <td align="left">text</td> <td align="left">text</td> </tr> <tr> <td align="left">textphone</td> <td align="left">textphone</td> </tr> <tr> <td align="left">video</td> <td align="left">video</td> </tr> <tr> <td align="left">voice</td> <td align="left">voice</td> </tr> </tbody> </table> <t>The value of the TEL property converts to the Phone <tt>number</tt> property.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="tel_conversion"> <name>TELconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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" } }]]></artwork>]]></sourcecode> </figure> </section> </section> <section> <name>Geographical Properties</name> <section anchor="vcard-prop-geo"> <name>GEO</name><t>This<t>The GEO property converts to the <tt>coordinates</tt> property of the <tt>Address</tt> object. Also see <xref target="combine-geo-props"/> to determine which <tt>Address</tt> object instance to convert to.</t> </section> <section anchor="vcard-prop-tz"> <name>TZ</name> <t>A value of type TEXT converts to the <tt>timeZone</tt> property in the <tt>Address</tt> object.</t> <t>A value of type UTC-OFFSET converts to the <tt>timeZone</tt> property in the <tt>Address</tt> object if the offset has zero minutes and the hour offset is in the range -12 <=14:</t>14. Note that:</t> <ul> <li>If the hour offset is zero, use the time zone name <tt>Etc/UTC</tt>.</li><li>Otherwise<li>Otherwise, construct the time zone name with <tt>Etc/GMT</tt> 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 <tt>-0500</tt> converts to <tt>Etc/GMT+5</tt>.</li> </ul> <t>For such property values, also see <xref target="combine-geo-props"/> to determine which <tt>Address</tt> object instance to convert to.</t> <t>Any other value of type UTC-OFFSET or URI does not convert to an IANA-registered property in JSContact. To convert such property, see <xref target="jscontact-prop-vcardprops"/>.</t> </section> <section anchor="combine-geo-props"> <name>Combininggeographical properties</name>Geographical Properties</name> <t>InvCardvCard, the properties ADR,GEOGEO, and TZ occur independently of each other. In JSContact, they all convert to properties of an <tt>Address</tt> object. It is implementation-specific if these vCard properties convert to <em>separate</em> address instances inJSContact,JSContact or if some or all of them convert to the <em>same</em> address. That being said, implementations <bcp14>MUST</bcp14> convert the properties to the <em>same</em> address for the following cases:</t> <ul> <li>The GROUP parameter values of the properties match.</li> <li>The GROUP parameters are not set, but they are set on any other ADR,GEOGEO, and TZ properties.</li> </ul> </section> </section> <section> <name>Organizational Properties</name> <section anchor="vcard-prop-contact-uri"> <name>CONTACT-URI</name><t>A<t>The CONTACT-URIpropertyproperty, as defined in <xreftarget="RFC8605"/>target="RFC8605"/>, is represented as an entry of the <tt>links</tt> property (<xref target="contact_uri_conversion"/>). The entry value is a <tt>Link</tt> object whose <tt>kind</tt> property is set to <tt>contact</tt> and <tt>uri</tt> property is set to the CONTACT-URI value.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="contact_uri_conversion"> <name>CONTACT-URIconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ CONTACT-URI;PREF=1:mailto:contact@example.com "links": { "CONTACT-1": { "kind": "contact", "uri": "mailto:contact@example.com", "pref": 1 } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-logo"> <name>LOGO</name><t>A<t>The LOGO property converts to an entry in the <tt>media</tt> property (<xref target="logo_conversion"/>). The entry value is a <tt>Media</tt> object whose <tt>kind</tt> property is set to <tt>logo</tt> and <tt>uri</tt> property is set to the LOGO value.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="logo_conversion"> <name>LOGOconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ LOGO:https://www.example.com/pub/logos/abccorp.jpg "media": { "LOGO-1": { "kind": "logo", "uri": "https://www.example.com/pub/logos/abccorp.jpg" } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-member"> <name>MEMBER</name> <t>The uids of the contact cards composing the group are included in the <tt>members</tt> property (<xref target="group_example"/>).</t> <t>In this case, the PREF parameter does not have a JSContact counterpart; however, the implementors <bcp14>MAY</bcp14> insert the map entries by order of preference.</t> <figure anchor="group_example"> <name>Groupexample</name> <artwork><![CDATA[Example</name> <sourcecode type=""><![CDATA[ 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 }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-org"> <name>ORG</name><t>An<t>The ORG property converts to an entry in the <tt>organizations</tt> property (<xref target="org_conversion"/>). The entry value is an <tt>Organization</tt> object whose <tt>name</tt> property contains the organizational name, and the <tt>units</tt> property is an array of <tt>OrgUnit</tt> objects that eachcontainingcontain the organizational unit name in the <tt>name</tt> property.</t> <t>Implementations <bcp14>MAY</bcp14> allow representation of organizational units without the organizational name. In this case, the first component of the ORG value <bcp14>MUST</bcp14> be an empty string (e.g., ORG:;DepartmentA).</t> <t>TheALTID,ALTID and LANGUAGE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <t>The first item of the comma-separated SORT-AS parameter value converts to the <tt>sortAs</tt> property of the <tt>Organization</tt> object. The subsequent items convert to the <tt>sortAs</tt> property of the corresponding <tt>OrgUnit</tt> object.</t> <t>The TYPE parameter converts according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="org_conversion"> <name>ORGconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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" } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-related"> <name>RELATED</name><t>This<t>The RELATED property converts to an entry in the <tt>relatedTo</tt> property (<xref target="related_conversion"/>). The property value converts to the key in the <tt>relatedTo</tt> property. The TYPE parameters convert to the <tt>relation</tt> of the <tt>Relation</tt> object value. Any other parameters convert as defined in <xref target="jscontact-prop-vcardparams"/>.</t> <figure anchor="related_conversion"> <name>RELATEDconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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" : { } } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-title"> <name>TITLE and ROLE</name> <t>Both TITLE and ROLE properties are represented as entries of the <tt>titles</tt> property (<xref target="title_role_conversion"/>). The entry value is a <tt>Title</tt> object whose <tt>kind</tt> property is set to <tt>title</tt> or <tt>role</tt> for the TITLE and ROLE vCard properties, respectively. The <tt>name</tt> property is set to the vCard property value.</t> <t>The value of the<tt>organization</tt><tt>organizationId</tt> property can be derived if the TITLE or ROLE property is a member of a vCard property group and if exactly one other ORG propertyalsois also a part of that group.</t> <t>The ALTID and LANGUAGE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="title_role_conversion"> <name>TITLE and ROLEconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ TITLE:Research Scientist group1.ROLE:Project Leader group1.ORG:ABC, Inc. "titles": { "TITLE-1": { "kind": "title", "name":"Project Leader""Research Scientist" }, "TITLE-2": { "kind": "role", "name":"Research Scientist", "organization":"Project Leader", "organizationId": "ORG-1" } }, "organizations": { "ORG-1": { "name": "ABC, Inc." } }]]></artwork>]]></sourcecode> </figure> </section> </section> <section> <name>Personal Information Properties</name> <section anchor="vcard-prop-expertise"> <name>EXPERTISE</name><t>An<t>The EXPERTISEpropertyproperty, as defined in <xreftarget="RFC6715"/>target="RFC6715"/>, is represented as a <tt>PersonalInfo</tt> object in the <tt>personalInfo</tt> property (<xref target="expertise_conversion"/>). The <tt>kind</tt> property is set to "expertise".</t> <t>The INDEX parameter converts according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="expertise_conversion"> <name>EXPERTISEconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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 } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-hobby"> <name>HOBBY</name><t>A<t>The HOBBYpropertyproperty, as defined in <xreftarget="RFC6715"/>target="RFC6715"/>, is represented as a <tt>PersonalInfo</tt> object in the <tt>personalInfo</tt> property (<xref target="hobby_conversion"/>). The <tt>kind</tt> property is set to "hobby".</t> <t>The INDEX parameter converts according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="hobby_conversion"> <name>HOBBYconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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 } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-interest"> <name>INTEREST</name><t>An<t>The INTERESTpropertyproperty, as defined in <xreftarget="RFC6715"/>target="RFC6715"/>, is represented as a <tt>PersonalInfo</tt> object in the <tt>personalInfo</tt> property (<xref target="interest_conversion"/>). The <tt>kind</tt> property is set to "interest".</t> <t>The INDEX parameter converts according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="interest_conversion"> <name>INTERESTconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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 } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-org-directory"> <name>ORG-DIRECTORY</name> <t>The ORG-DIRECTORY property <xref target="RFC6715"/> converts to a Directory object in the <tt>directories</tt> property (<xref target="org_directory_conversion"/>). The <tt>kind</tt> property is set to <tt>directory</tt>. The <tt>uri</tt> property is set to the ORG-DIRECTORY property value.</t> <t>The INDEX,PREFPREF, and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="org_directory_conversion"> <name>ORG-DIRECTORYconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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 } }]]></artwork>]]></sourcecode> </figure> </section> </section> <section> <!--[rfced] Section Titles a) Should the title of Section 2.11 ("Explanatory Properties") be updated to include "Parameters" since Section 2.11.2 discusses the CLIENTPIDMAP and PID parameters? And should "Parameter" be removed from the title of Section 2.11.2 for consistency with the other titles as shown below? Original: 2.11 Explanatory Properties 2.11.1 CATEGORIES 2.11.2 CLIENTPIDMAP and PID Parameter Perhaps: 2.11 Explanatory Properties and Parameters 2.11.1 CATEGORIES 2.11.2 CLIENTPIDMAP and PID b) In the titles of Sections 2.15.1, 2.15.2, and 2.15.3, should "Property" be removed for consistency with the other section titles? Original: 2.15. New JSContact properties 2.15.1. Property vCardProps 2.15.2. Property vCardParams 2.15.3. Property vCardName Perhaps: 2.15. New JSContact Properties 2.15.1. vCardProps 2.15.2. vCardParams 2.15.3. vCardName --> <name>Explanatory Properties</name> <section anchor="vcard-prop-categories"> <name>CATEGORIES</name><t>A<t>The CATEGORIES property converts to a set of entries of the <tt>keywords</tt> property (<xref target="categories_conversion"/>). The keys are the comma-separated text values of the CATEGORIES property.</t> <t>In this case, the PREF parameter does not have a JSContact counterpart; however, the implementors <bcp14>MAY</bcp14> insert the map entries by order of preference.</t> <figure anchor="categories_conversion"> <name>CATEGORIESconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ CATEGORIES:internet,IETF,Industry,Information Technology "keywords": { "internet": true, "IETF": true, "Industry": true, "Information Technology": true }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-pid"> <name>CLIENTPIDMAP and PIDParameter</name> <t>TheseParameters</name> <t>The CLIENTPIDMAP and PID parameters convert to the <xref target="jscontact-prop-vcardprops"><tt>vCardProps</tt></xref> and <xref target="jscontact-prop-vcardparams"><tt>vCardParams</tt></xref> properties.</t> </section> <section anchor="vcard-prop-created"> <name>CREATED</name> <t>The CREATED property converts to the <tt>created</tt> property (<xref target="created_conversion"/>).</t> <figure anchor="created_conversion"> <name>CREATEDconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ CREATED:19940930T143510Z "created": "1994-09-30T14:35:10Z"]]></artwork>]]></sourcecode> </figure> <t>Note: This property is defined in <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</t>target="RFC9554"/>.</t> </section> <section anchor="vcard-prop-note"> <name>NOTE</name><t>A<t>The NOTE property converts to a <tt>Note</tt> object in the <tt>notes</tt> map (<xref target="notes_conversion"/>).</t> <t>The ALTID and LANGUAGE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="notes_conversion"> <name>NOTEconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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" } } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-prodid"> <name>PRODID</name> <t>The PRODID property converts to the <tt>prodId</tt> property (<xref target="prodid_conversion"/>).</t> <figure anchor="prodid_conversion"> <name>PRODIDconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ PRODID:ACME Contacts App version 1.23.5 "prodId": "ACME Contacts App version 1.23.5"]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-rev"> <name>REV</name> <t>The REV property converts to the <tt>updated</tt> property (<xref target="rev_conversion"/>).</t> <figure anchor="rev_conversion"> <name>REVconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ REV:19951031T222710Z "updated": "1995-10-31T22:27:10Z"]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-sound"> <name>SOUND</name><t>A<t>The SOUND property converts to an entry in the <tt>media</tt> property (<xref target="sound_conversion"/>). The entry value is a <tt>Media</tt> object whose <tt>kind</tt> property is set to <tt>sound</tt> and <tt>uri</tt> property is set to the SOUND value.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="sound_conversion"> <name>SOUNDconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ SOUND:CID:JOHNQPUBLIC.19960229T080000.xyzMail@example.com "media": { ... "SOUND-1": { "kind": "sound", "uri": "CID:JOHNQPUBLIC.19960229T080000.xyzMail@example.com" } }]]></artwork>]]></sourcecode> </figure> </section> <!--[rfced] Is "corresponds" the correct wording or should it be "converts" for consistency with the other related sections? Original: The UID property corresponds to the uid property (Figure 39). Perhaps: The UID property converts to the uid property (Figure 39). --> <section anchor="vcard-prop-uid"> <name>UID</name> <t>The UID property corresponds to the <tt>uid</tt> property (<xref target="uid_conversion"/>).</t> <figure anchor="uid_conversion"> <name>UIDconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 "uid": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-url"> <name>URL</name><t>A<t>The URL property converts to an entry in the <tt>links</tt> property (<xref target="url_conversion"/>). The entry value is a <tt>Link</tt> object whose <tt>uri</tt> property is set to the URL value.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="url_conversion"> <name>URLconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ URL:https://example.org/restaurant.french/~chezchic.html "links": { "LINK-1": { "uri": "https://example.org/restaurant.french/~chezchic.html" } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-version"> <name>VERSION</name><t>This<t>The VERSION property converts to an entry in the <xref target="jscontact-prop-vcardprops"><tt>vCardProps</tt></xref> property.</t> </section> <section anchor="vcard-prop-xablabel"> <name>X-ABLabel</name><t>This<t>The X-ABLabel property is experimental but widely in use in existing vCard data. It converts to the <tt>label</tt> property of a JSContact object type. <!--[rfced] We are having some trouble understanding "a vCard property having the same group". To clarify, may we update the sentence as follows? Original: The X-ABLabel property is preceded by a vCard property group name, and the label converts to the JSContact object which got converted from a vCard property having the same group. Perhaps: 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 property of the same group. --> 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 property having the same group.</t> <t>The group name is notpreserved,preserved; implementations are free to choose any unique group name when converting back to vCard. For an example on how to preserve the groupnamename, see <xref target="vcard-param-group"/>.</t> <figure anchor="xablabel_conversion"> <name>X-ABLabelconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ item1.TEL;VALUE=uri:tel:+1-555-555-5555 item1.X-ABLabel:foo "phones": { "p1": { "number": "tel:+1-555-555-5555", "label": "foo" } }]]></artwork>]]></sourcecode> </figure> </section> </section> <section> <name>Security Properties</name> <section anchor="vcard-prop-key"> <name>KEY</name><t>A<t>The KEY property converts to an entry in the <tt>cryptoKeys</tt> property (<xref target="key_conversion"/>). The entry value is a <tt>CryptoKey</tt> object whose <tt>uri</tt> property is set to the KEY value.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="key_conversion"> <name>KEYconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ KEY:https://www.example.com/keys/jdoe.cer "cryptoKeys": { "KEY-1": { "uri": "https://www.example.com/keys/jdoe.cer" } }]]></artwork>]]></sourcecode> </figure> </section> </section> <section> <name>Calendar Properties</name> <section anchor="vcard-prop-caladruri"> <name>CALADRURI</name><t>A<t>The CALADRURI property converts to an entry in the <tt>schedulingAddresses</tt> property (<xref target="caladruri_conversion"/>). The entry value is a <tt>SchedulingAddress</tt> object whose <tt>uri</tt> property is set to the CALADRURI value.</t> <t>The PREF parameter converts according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="caladruri_conversion"> <name>CALADRURIconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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" } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-caluri"> <name>CALURI</name><t>A<t>The CALURI property converts to an entry in the <tt>calendars</tt> property (<xref target="caluri_conversion"/>). The entry value is a <tt>Calendar</tt> object whose <tt>kind</tt> property is set to <tt>calendar</tt> and <tt>uri</tt> property is set to the CALURI value.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="caluri_conversion"> <name>CALURIconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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" } }]]></artwork>]]></sourcecode> </figure> </section> <section anchor="vcard-prop-fburl"> <name>FBURL</name><t>An<t>The FBURL property converts to an entry in the <tt>calendars</tt> property (<xref target="fburl_conversion"/>). The entry value is a <tt>Calendar</tt> object whose <tt>kind</tt> property is set to <tt>freeBusy</tt> and <tt>uri</tt> property is set to the FBURL value.</t> <t>The PREF and TYPE parameters convert according to the rulesasdefined in <xref target="vcard-parameters"/>.</t> <figure anchor="fburl_conversion"> <name>FBURLconversion example</name> <artwork><![CDATA[Conversion Example</name> <sourcecode type=""><![CDATA[ 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" } }]]></artwork>]]></sourcecode> </figure> </section> </section> <section anchor="vcard-extended"> <name>Extended Properties and Parameters</name><t>These<t>Extended properties and parameters convert as specified in <xref target="new-jscontact"/>.</t> </section> <section anchor="new-jscontact"> <name>New JSContactproperties</name>Properties</name> <t>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 <xref target="RFC6350" sectionFormat="of" section="6.10"/>.</t> <t>This section defines JSContact properties by which such vCard properties and parameters <bcp14>MAY</bcp14> be represented in JSContact. Implementations <bcp14>MAY</bcp14> choose to convert differently if they deem that more appropriate.</t> <section anchor="jscontact-prop-vcardprops"> <name>Property <tt>vCardProps</tt></name> <dl> <dt>Name:</dt> <dd> <tt>vCardProps</tt> </dd> <dt>Type:</dt> <dd><tt>JCardProp[]</tt>, where <tt>JCardProp</tt> denotes a jCard-encoded vCard property as defined in <xref target="RFC7095" sectionFormat="of" section="3.3"/>. </dd> <dt>Definition:</dt> <dd>This property is set on a JSContact object that represents a vCard. It contains properties that are set in the vCard represented by this JSContact object. Each entry in this list typically represents a vCard property for which no conversion to an IANA-registered JSContact property is defined.</dd> <dt>Example:</dt> <dd> <t>This illustrates how to convert a vCard extension property:</t> <figure anchor="props_conversion"> <name>JSContact <tt>vCardProps</tt>example</name> <artwork><![CDATA[Example</name> <sourcecode type=""><![CDATA[ item1.X-FOO;X-BAR=Hello:World! "vCardProps": [ ["x-foo", { "x-bar": "Hello", "group": "item1" }, "unknown", "World!"] ]]]></artwork>]]></sourcecode> </figure> </dd> </dl> </section> <section anchor="jscontact-prop-vcardparams"> <name>Property <tt>vCardParams</tt></name> <dl> <dt>Name:</dt> <dd> <tt>vCardParams</tt> </dd> <dt>Type:</dt> <dd> <tt>String[String|String[]]</tt> </dd> <dt>Definition:</dt> <!--[rfced] We do not see mention of "array element 2" in Section 3.3 of RFC 7095. We do see mention of "array element values" in Section 3.3.1.3. Please confirm if an update is needed to the name of the term or section number. Original: This property is set on a JSContact object that represents a vCard property. Its value MUST be a JSON object containing vCard property parameters, defined as array element 2 in Section 3.3 of [RFC7095]. --> <dd>This property is set on a JSContact object that represents a vCard property. Its value <bcp14>MUST</bcp14> be a JSON object containing vCard property parameters, defined as array element 2 in <xref target="RFC7095" sectionFormat="of" section="3.3"/>. Each entry represents a parameter of the vCard property that converts to the JSContact object.</dd> <dt>Example:</dt> <dd> <t>This illustrates how to convert a vCard extension parameter:</t> <figure anchor="params_conversion"> <name>JSContact <tt>vCardParams</tt>example</name> <artwork><![CDATA[Example</name> <sourcecode type=""><![CDATA[ EMAIL;X-FOO=Bar:jane_doe@example.com "emails": { "email1": { "address": "jane_doe@example.com", "vCardParams": { "x-foo": "Bar" } } }]]></artwork>]]></sourcecode> </figure> </dd> </dl> </section> <section anchor="jscontact-prop-vcardname"> <name>Property <tt>vCardName</tt></name> <dl> <dt>Name:</dt> <dd> <tt>vCardName</tt> </dd> <dt>Type:</dt> <dd> <tt>String</tt> </dd> <dt>Definition:</dt> <dd>This property is set on a JSContact object that represents a vCard property orparameterparameter, and its value contains the name of that vCard element. This allowsto preservethe name of a vCard element to be preserved when multiple elements convert the same JSContact object type. The case-insensitive value <bcp14>MUST</bcp14> be valid according to the <tt>name</tt> ABNF defined in <xref target="RFC6350" sectionFormat="of" section="3.3"/>.</dd> <dt>Example:</dt> <!--[rfced] In the following sentence, should "OnlineService" perhaps be updated as "OnlineService object" or "OnlineService object type" for consistency? Original: Example: Both vCard IMPP and SOCIALPROFILE convert to OnlineService in JSContact. Perhaps: Example: Both vCard IMPP and SOCIALPROFILE convert to an OnlineService object in JSContact. --> <dd> <t>Both vCard IMPP and SOCIALPROFILE convert to OnlineService in JSContact. The <tt>vCardName</tt> property value indicates that the vCard source element wasIMPP:</t>IMPP as follows:</t> <figure anchor="example-vcardname"> <name>JSContact <tt>vCardName</tt>example</name> <artwork><![CDATA[Example</name> <sourcecode type=""><![CDATA[ IMPP:xmpp:alice@example.com "onlineServices": { "os1": { "uri": "xmpp:alice@example.com", "vCardName": "impp" }, }]]></artwork>]]></sourcecode> </figure> </dd> </dl> </section> </section> </section> <section anchor="convert-jscontact-to-vcard"> <name>Converting JSContact to vCard</name> <section> <name>Conversion Rules</name> <t>A <tt>Card</tt> converts to vCard by applying the reverse rules of converting vCard to JSContact. In addition to those listed in <xref target="convert_jscontact_to_vcard-reverse-rules"/>, the following rules apply:</t> <ul> <li>Multivalued JSContact properties convert to separate instances of their equivalent vCard property, andforeach of the PROP-IDparameterparameters <bcp14>MUST</bcp14> be set to the <tt>Id</tt> of the converted value (see <xref target="vcard-param-propid"/>).</li> <li> <t>The <tt>full</tt> property of the <tt>name</tt> property in JSContact is optional, but the FN property is mandatory in vCard. The following rules apply:</t> <ul> <li>If the Name <tt>full</tt> property is set, then implementations <bcp14>MUST</bcp14> use its value for the vCard FN property.</li> <li>If the Name <tt>full</tt> property is not set, then implementations <bcp14>SHOULD</bcp14> derive the full name from the Name <tt>components</tt> values. If the <tt>isOrdered</tt> property istrue,"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 itscomponents,components such as <xref target="CLDRPersonName"/>. Implementations <bcp14>MUST</bcp14> set the DERIVED parameter on the FN property.</li> <li>Otherwise,they <bcp14>MUST</bcp14> setthe FN property <bcp14>MUST</bcp14> be set to the empty value.</li> </ul> </li> <li>Vendor-specific and unknown properties convert to vCard as outlined in <xref target="jscontact-convert-unknown"/>.</li> </ul> <section anchor="jscontact-convert-unknown"> <name>Convertingunknown properties</name>Unknown Properties</name> <t>JSContact object types may contain properties for which no IANA-registered vCard property is defined. For example, a JSContact object may contain vendor-specific properties of which the semantics or purpose are unknown.</t> <t>This specification defines the new <xref target="vcard-prop-jsprop"><tt>JSPROP</tt></xref> vCard property and <xref target="vcard-param-jsptr"><tt>JSPTR</tt></xref> vCard parameter by which such JSContact properties <bcp14>MAY</bcp14> be represented in vCard. Implementations <bcp14>MAY</bcp14> choose to convert differently if they deem that more appropriate.</t> </section> </section> <section anchor="new-vcard-props"> <name>New vCard Properties</name> <section anchor="vcard-prop-jsprop"> <name>JSPROP</name> <dl> <dt>Property name:</dt> <dd>JSPROP</dd> <dt>Purpose:</dt><dd>This property represents<dd>Represents a JSContact property in vCard.</dd> <dt>Value type:</dt><dd>TEXT,<dd>TEXT; also seeFormat Definition"Format definition" below for value restrictions.</dd> <dt>Conformance:</dt><dd>The property can<dd>Can be specified multiple times in a vCard.</dd> <dt>Property parameters:</dt> <dd> The JSPTR parameter <bcp14>MUST</bcp14> be set for this property. Other IANA-registered and experimental property parameters can be specified on this property. </dd> <dt>Description:</dt> <dd> <t>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 <bcp14>MUST</bcp14> be compact, e.g., without insignificant whitespace. The value of the JSPTR parameter points to the JSContact property within the Card.</t> <t>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 <bcp14>MUST NOT</bcp14> reference into an array.</t> <t>All JSPROP properties in a vCard together form a PatchObject as defined in <xreftarget="I-D.ietf-calext-jscontact"/>.target="RFC9553"/>. The value of its JSPTR parameter corresponds to a key in thePatchObject,PatchObject; the value of the JSPROP property corresponds to the value for that key. When converting from vCard to JSContact, the PatchObject <bcp14>MUST</bcp14> only be applied after all other vCard properties have already been converted. The PatchObject <bcp14>MUST</bcp14> be valid, including the restriction that an invalid PatchObject <bcp14>MUST NOT</bcp14> be applied.</t> </dd> <dt>Format definition:</dt> <dd> <t>This property is defined by the following notation:</t> <!--[rfced] When we attempted to validate the ABNF using <https://author-tools.ietf.org/abnf>, we received the following error. Please review and let us know how we may fix this. (20:53): warning: zero-length char-val --> <sourcecode name="" type="abnf"><![CDATA[ jsprop = "JSPROP" jsprop-param ":" TEXT jsprop-param = *( ; The following are MANDATORY and MUST NOT ; occur more than once ( ";" jsptr-param ) / ; see next section ( ";" "VALUE" "=" "TEXT") ; ; The following isOPTIONAL,OPTIONAL ; and MAY occur more than once. ; (";" other-param) ; ) ]]></sourcecode> </dd> <dt anchor="vcard-prop-jsprop-examples">Example(s):</dt> <dd> <t>This illustrates how to convert a property at thetop-leveltop level in a Card object that is unknown to the implementation.</t> <figure anchor="jscontact-prop-unknown"> <name>Unknownproperty example</name> <artwork><![CDATA[Property Example</name> <sourcecode type=""><![CDATA[ "someUnknownProperty": true JSPROP;JSPTR="someUnknownProperty":true]]></artwork>]]></sourcecode> </figure> <t>This illustrates how to convert a vendor-specific property at thetop-leveltop level of a Card object. Note the required use of quoted string for the JSPTRvaluevalue, which allows the path to include the COLON (U+003A) character.</t> <figure anchor="jscontact-prop-vendor-specific"><name>Vendor-specific property conversion example</name> <artwork><![CDATA[<name>Vendor-Specific Property Conversion Example</name> <sourcecode type=""><![CDATA[ "example.com:foo": { "bar": 1234 } JSPROP;JSPTR="example.com:foo":{"bar":1234}]]></artwork>]]></sourcecode> </figure> <t>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)charactercharacter, which requires escaping in the JSON pointer.</t> <figure anchor="jscontact-prop-nested"> <name>Nestedvendor-specific property exampleVendor-Specific Property Example withpath relativea Path Relative to Card</name><artwork><![CDATA[<sourcecode type=""><![CDATA[ "phones": { "phone1": { "number":"tel:+33-01-23-45-67""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"]]></artwork>]]></sourcecode> </figure> </dd> </dl> </section> </section> <section> <name>New vCardParameter</name>Parameters</name> <section anchor="vcard-param-jscomps"> <name>JSCOMPS</name> <dl> <dt>Parameter name:</dt> <dd>JSCOMPS</dd> <dt>Purpose:</dt><dd>This parameter defines<dd>Defines the order and separators for the elements of a structured property value.</dd> <dt>Description:</dt> <dd> <t>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.</t> <t>If this parameter is set and its value is valid (see later), then implementations <bcp14>MUST</bcp14> set the <tt>isOrdered</tt> property of the Name or Address object to "true". Otherwise, they <bcp14>MUST</bcp14> set the <tt>isOrdered</tt> property value to "false".</t> <t>The JSCOMPS parameter value is a structured type value. Its value <bcp14>MUST</bcp14> 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 <tt>defaultSeparator</tt> property. If it is the emptystringstring, then no default separator is defined. Otherwise, the first entry <bcp14>MUST</bcp14> be a separator entry. All following entries processed in order result in an ordered list of JSContactcomponents,components and <bcp14>MUST</bcp14> be one oftwothe following two kinds:</t> <ol> <li> <t>A positional. This refers to a component value in the vCard structuredvaluevalue. 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 indexby defaultiszero,zero by default, in which case it <bcp14>MUST</bcp14> be omitted (as well as the leading COMMA).</t> <t>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. Figures <xreftarget="vcard-param-jscomps-example-positional"/>target="vcard-param-jscomps-example-positional" format="counter"/> and <xreftarget="vcard-param-jscomps-example-n-secondary-index"/>target="vcard-param-jscomps-example-n-secondary-index" format="counter"/> illustrate this by example.</t> </li> <li> <t>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),(U+002C) character, followed by zero or more <tt>param-value</tt> characters (see <xref target="RFC6350"section="3.3"><tt>param-value</tt></xref> characters,sectionFormat="of" section="3.3"/>), where the COMMA(U+002c)(U+002C) and SEMICOLON (U+003B)charactercharacters <bcp14>MUST</bcp14> be escaped according to the rules defined in <xref target="RFC6350" sectionFormat="of" section="3.4"/>. <xref target="vcard-param-jscomps-example-separator"/> illustrates this by example.</t> <t>The resulting JSContact component is formed by setting its kind to <tt>separator</tt> and its value to the verbatim value of the entry.</t> </li> </ol> <t>A JSCOMPS parameter value is valid if and only if:</t> <ul> <li>All indexes in the positional entries refer to an existing component value in the vCard property value.</li> <li> <t>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:</t> <ul> <li>A value that occurs in both the N property secondary surname component and the family name component only counts once.</li> <li>A value that occurs in both the N property generation component and the honorific suffix component only counts once.</li> <li>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 <xreftarget="I-D.ietf-calext-vcard-jscontact-extensions"/>.</li>target="RFC9554"/>.</li> <li>All other values count once each.</li> </ul> </li> </ul> </dd> <dt>Format definition:</dt> <dd> <sourcecode name="" type="abnf"><![CDATA[ jscomps-param = "JSCOMPS" "=" DQUOTE ( (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 ; encode special characters according to RFC 6868 ]]></sourcecode> </dd> <dt anchor="vcard-param-jscomps-examples">Example(s):</dt> <dd> <t>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.</t> <figure anchor="vcard-param-jscomps-example-positional"> <name>Examplefor positional entries</name>of Positional Entries</name> <sourcecode name=""><![CDATA[ "name": { "components": [ { "kind": "given", "value": "Jane" }, { "kind": "surname", "value": "Doe" } ], "isOrdered": true } N;JSCOMPS=";1;0":Doe;Jane;;;;;; FN;DERIVED=TRUE:Jane Doe ]]></sourcecode> </figure> <t>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.</t> <!--[rfced] The title of Figures 52 and 53 are the same. Should Figure 53 be updated as follows to denote the difference between the figures? Original: Figure 53: Example for Positional Entries Perhaps: Figure 53: Example of a Secondary Positional Index --> <figure anchor="vcard-param-jscomps-example-n-secondary-index"> <name>Examplefor positional entries</name>of Positional Entries</name> <sourcecode name=""><![CDATA[ "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. ]]></sourcecode> </figure> <t>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 " ". Forbackwards-compatibility,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.</t> <figure anchor="vcard-param-jscomps-example-separator"> <name>Examplefor separator entries</name>of Separator Entries</name> <sourcecode name=""><![CDATA[ "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 Oak St;Reston;;;;;;;Oak St;54321;;;;;; ]]></sourcecode> </figure> </dd> </dl> </section> <section anchor="vcard-param-jsptr"> <name>JSPTR</name> <dl> <dt>Parameter name:</dt> <dd>JSPTR</dd> <dt>Purpose:</dt><dd><!--[rfced] Is "relates" the correct wording here or should it be "converts" for consistency with the other related sections? Original: Parameter name: JSPTR Purpose: This parameter contains a JSON pointer [RFC6901] that relates the vCard JSPROP (Section 3.2.1) property to a JSContact property. Perhaps: Parameter name: JSPTR Purpose: Contains a JSON pointer [RFC6901] that converts the vCard JSPROP (Section 3.2.1) property to a JSContact property. --> <dd>Contains a JSON pointer <xref target="RFC6901"/> that relates the vCard <xref target="vcard-prop-jsprop">JSPROP</xref> property to a JSContact property. </dd> <dt>Description:</dt> <dd> <t>This parameter has a single value that <bcp14>MUST</bcp14> be a valid JSON pointer as defined in <xref target="RFC6901"/>. Note that the value <bcp14>MUST</bcp14> be quoted according to the <tt>param-value</tt> ABNF in <xref target="RFC6350"/>.</t> </dd> <dt>Format definition:</dt> <dd> <sourcecode name="" type="abnf"><![CDATA[ jsptr-param = "JSPTR" "=" param-value ; also see param-value in RFC 6350,sectionSection 3.3 ]]></sourcecode> </dd> <dt>Example(s):</dt> <dd> <t>This illustrates a simple example. For furtherexamplesexamples, see <xref target="vcard-prop-jsprop-examples"/>.</t> <sourcecode name=""><![CDATA[ JSPROP;JSPTR="example.com:foo":"bar" ]]></sourcecode> </dd> </dl> </section> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This specification defines how to convert between the JSContact and vCard formats. <!--[rfced] FYI: Since the security considerations can be found in Section 4 of RFC 9553, we updated "Section 5" to "Section 4" below. Original: The security considerations for parsing and formatting such data apply and are outlined in<xref target="I-D.ietf-calext-jscontact" section="5"/> and <xref target="RFC6350" section="9"/>.</t> </section> <section> <name>Acknowledgements</name> <t>The definitionSection 5 of [I-D.ietf-calext-jscontact] andexamplesSection 9 ofthe <xref target="vcard-param-phonetic">PHONETIC</xref>[RFC6350]. Current: The security considerations for parsing and formatting such data apply and<xref target="vcard-param-script">SCRIPT</xref> parametersarebased on the initial versionoutlined in Section 4 of [RFC9553] and Section 9 of [RFC6350]. --> The security considerations for parsing and formatting such data apply and are outlined in <xreftarget="I-D.calconnect-vobject-i18n"/>.</t>target="RFC9553" sectionFormat="of" section="4"/> and <xref target="RFC6350" sectionFormat="of" section="9"/>.</t> </section> <section anchor="IANA"><!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.--><name>IANA Considerations</name> <section> <name>New vCardProperties</name>Property</name> <t>IANAis requested to addhas added the followingentriesentry to the "vCard Properties" registry, as defined inSection 10.3.1. of<xreftarget="RFC6350"/>.</t>target="RFC6350" sectionFormat="of" section="10.3.1"/>.</t> <table anchor="new_properties"> <name>New vCardProperties</name>Property</name> <thead> <tr> <th align="left">Namespace</th> <th align="left">Property</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td/> <td align="left">JSPROP</td> <tdalign="left">This document,align="left">RFC 9555, <xref target="vcard-prop-jsprop"/></td> </tr> </tbody> </table> </section> <section> <name>New vCardParameters</name>Parameter</name> <t>IANAis requested to addhas added the followingentriesentry to the "vCard Parameters" registry, as defined inSection 10.3.2. of<xreftarget="RFC6350"/>.</t>target="RFC6350" sectionFormat="of" section="10.3.2"/>.</t> <table anchor="new_parameters"> <name>New vCardParameters</name>Parameter</name> <thead> <tr> <th align="left">Namespace</th> <th align="left">Parameter</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td/> <td align="left">JSPTR</td> <tdalign="left">This document,align="left">RFC 9555, <xref target="vcard-param-jsptr"/></td> </tr> </tbody> </table> </section> <section> <name>New JSContact Properties</name> <t>IANAis requested to addhas added the following entries to the "JSContact Properties" registry.TheNote that the Since Versionfor all propertiesis1.0. The1.0, the Until Versionfor all propertiesis notset. All RFC section references are for this document. The change controllerset, and the Change Controller is IETF for all of theseproperties is IETF.</t>properties.</t> <table anchor="tab-iana-property-registry" align="center"><name>Initial Contents of the "JSContact Properties"<name>JSContact Properties Registry</name> <thead> <tr> <th align="left">Property Name</th> <th align="left">Property Type</th> <th align="left">Property Context</th> <th align="left">Intended Usage</th> <th align="left">Reference or Description</th><th align="left">Intended Usage</th></tr> </thead><!-- Everything in here should be sorted alphabetically: table entries by property name, the references for each property alphabetically by the object type or property they refer to --><tbody> <tr> <td align="left">vCardName</td> <td align="left">String</td> <td align="left">Any JSContact object</td> <tdalign="left">align="left">common</td> <td align="left">RFC 9555, <xref target="jscontact-prop-vcardname"format="default"/> </td> <td align="left">common</td>format="default"/></td> </tr> <tr> <td align="left">vCardParams</td> <tdalign="left">String[String]</td>align="left">String[String|String[]]</td> <td align="left">Any JSContact object</td> <tdalign="left">align="left">common</td> <td align="left">RFC 9555, <xref target="jscontact-prop-vcardparams" format="default"/> </td><td align="left">common</td></tr> <tr> <td align="left">vCardProps</td> <td align="left">JCardProp[]</td> <td align="left">Card</td> <tdalign="left">align="left">common</td> <td align="left">RFC 9555, <xref target="jscontact-prop-vcardprops" format="default"/> </td><td align="left">common</td></tr> </tbody> </table> </section> <section> <name>New JSContactTypes</name>Type</name> <t>IANAis requested to addhas added the followingentriesentry to the "JSContact Types" registry.TheNote that the Since Versionfor all propertiesis1.0. The1.0, the Until Versionfor all propertiesis notset. All RFC section references areset, and the Change Controller is IETF for thisdocument. The change controller for all these properties is IETF.</t>type.</t> <table anchor="tab-iana-jscontact-type-registry" align="left"><name>Additional Contents of the "JSContact Types"<name>JSContact Types Registry</name> <thead> <tr> <th align="left">Type Name</th> <th align="left">Intended Usage</th> <th align="left">Reference or Description</th><th align="left">Intended Usage</th></tr> </thead> <tbody> <tr> <td align="left">JCardProp</td> <tdalign="left">align="left">common</td> <td align="left">RFC 9555, <xref target="jscontact-prop-vcardprops" format="default"/> </td><td align="left">common</td></tr> </tbody> </table> </section> </section><section anchor="impl-status"> <name>Implementation Status</name> <t>NOTE: Please remove this section and the reference to RFC 7942 prior to publication as an RFC.</t> <t>This section records the status of known implementations of the protocol as defined in this specification at the time of posting of this Internet-Draft, and is based on a proposal described in <xref target="RFC7942"/>. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.</t> <t>According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".</t> <section anchor="it-cnr-iit"> <name>CNR</name> <ul spacing="compact"> <li>Responsible Organization: National Research Council (CNR) of Italy</li> <li>Location: https://github.com/consiglionazionaledellericerche/jscontact-tools</li> <li>Description: This implementation includes tools for JSContact creation, validation, serialization/deserialization, and conversion from vCard, xCard and jCard.</li> <li>Level of Maturity: This is an "alpha" test implementation.</li> <li>Coverage: This implementation includes all features described in this specification.</li> <li>Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it</li> </ul> </section> </section></middle> <back> <displayreference target="I-D.calconnect-vobject-i18n" to="vOBJECT"/> <references> <name>References</name> <references> <name>Normative References</name> <!-- [I-D.ietf-calext-jscontact] in EDIT state as of 2/12/24; companion document RFC 9553 --> <reference anchor="RFC9553" target="https://www.rfc-editor.org/info/rfc9553"> <front> <title>JSContact: A JSON Representation of Contact Data</title> <author initials='R' surname='Stepanek' fullname='Robert Stepanek'> <organization /> </author> <author initials='M' surname='Loffredo' fullname='Mario Loffredo'> <organization /> </author> <date month='March' year='2024' /> </front> <seriesInfo name="RFC" value="9553"/> <seriesInfo name="DOI" value="10.17487/RFC9553"/> </reference> <!-- [I-D.ietf-calext-vcard-jscontact-extensions] in REF state as of 2/12/24; companion document RFC 9554 --> <reference anchor="RFC9554" target="https://www.rfc-editor.org/info/rfc9554"> <front> <title>vCard Format Extension for JSContact</title> <author initials="R." surname="Stepanek" fullname="Robert Stepanek"> <organization>Fastmail</organization> </author> <author initials="M." surname="Loffredo" fullname="Mario Loffredo"> <organization>IIT-CNR</organization> </author> <date month="March" year="2024"/> </front> <seriesInfo name="RFC" value="9554"/> <seriesInfo name="DOI" value="10.17487/RFC9554"/> </reference> <xi:includehref="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-calext-jscontact.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-calext-vcard-jscontact-extensions.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6473.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6474.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6473.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6715.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6474.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6869.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6715.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6901.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6869.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6901.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references> <name>Informative References</name> <!--[I-D.calconnect-vobject-i18n] IESG state Expired. Entered the long way to get the correct initials--> <reference anchor="I-D.calconnect-vobject-i18n" target="https://datatracker.ietf.org/doc/html/draft-calconnect-vobject-i18n-00"> <front> <title>vObject Internationalization</title> <author fullname="Ronald Henry Tse" initials="R." surname="Tse"> <organization>Ribose</organization> </author> <author fullname="Peter Tam" initials="P." surname="Tam"> <organization>Ribose</organization> </author> <author fullname="Michael Douglass" initials="M." surname="Douglass"> <organization>Spherical Cow Group</organization> </author> <date day="7" month="June" year="2018"/> </front> <seriesInfo name="Internet-Draft" value="draft-calconnect-vobject-i18n-00"/> </reference> <xi:includehref="https://datatracker.ietf.org/doc/bibxml3/draft-calconnect-vobject-i18n.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8605.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8605.xml"/> <reference anchor="CLDRPersonName" target="https://www.unicode.org/reports/tr35/tr35-personNames.html"> <front><title>Technical Standard #35: Unicode<title>Unicode Locale Data Markup Language (LDML) Part 8: PersonNames, Version 43.1</title>Names</title> <author fullname="M. Davis"> <organization/> </author> <author fullname="P. Edberg"> <organization/> </author> <author fullname="R. Gillam"> <organization/> </author> <author fullname="A. Kolisnychenko"> <organization/> </author> <author fullname="M. McKenna"> <organization/> </author><author fullname="others"> <organization/><author> <organization>other CLDR committee members</organization> </author> <date year="2023" month="July"/> </front> <seriesInfo name="Unicode Technical Standard" value="#35"/> <seriesInfo name="Version" value="44.1"/> </reference> </references> </references> <section anchor="convert_jscontact_to_vcard-reverse-rules"> <name>Reverse Rules of Converting a vCard to a JSContact Card</name> <t><xref target="table_convert_jscontact_to_vcard"/> lists the relevant document sections for each JSContact object type and property.</t> <table anchor="table_convert_jscontact_to_vcard"> <name>Conversionrules byRules for JSContactproperty</name>Types and Properties</name> <thead> <tr> <th align="left">JSContact Type</th> <th align="left">Property Name</th> <th align="left">Relevant Section(s)</th> </tr> </thead> <tbody> <tr> <td>Address</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Address</td> <td>components</td><td><xref target="vcard-prop-adr"/>,<td>Sections <xref target="vcard-prop-adr" format="counter"/> and <xreftarget="vcard-param-jscomps"/></td>target="vcard-param-jscomps" format="counter"/></td> </tr> <tr> <td>Address</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>Address</td> <td>coordinates</td><td><xref target="vcard-param-geo"/>,<td>Sections <xref target="vcard-param-geo" format="counter"/> and <xreftarget="vcard-prop-geo"/></td>target="vcard-prop-geo" format="counter"/></td> </tr> <tr> <td>Address</td> <td>country</td> <td> <xref target="vcard-prop-adr"/> </td> </tr> <tr> <td>Address</td> <td>countryCode</td> <td> <xref target="vcard-prop-adr"/> </td> </tr> <tr> <td>Address</td> <td>defaultSeparator</td><td><xref target="vcard-prop-adr"/>,<td>Sections <xreftarget="vcard-param-jscomps"/></td>target="vcard-prop-adr" format="counter"/> and <xref target="vcard-param-jscomps" format="counter"/></td> </tr> <tr> <td>Address</td> <td>full</td> <td> <xref target="vcard-prop-adr"/> </td> </tr> <tr> <td>Address</td> <td>isOrdered</td><td><xref target="vcard-prop-adr"/>,<td>Sections <xreftarget="vcard-param-jscomps"/></td>target="vcard-prop-adr" format="counter"/> and <xref target="vcard-param-jscomps" format="counter"/></td> </tr> <tr> <td>Address</td> <td>locality</td> <td> <xref target="vcard-prop-adr"/> </td> </tr> <tr> <td>Address</td> <td>phoneticScript</td><td><td>Sections <xreftarget="vcard-param-phonetic"/>,target="vcard-param-phonetic" format="counter"/> and <xreftarget="vcard-param-script"/>target="vcard-param-script" format="counter"/> </td> </tr> <tr> <td>Address</td> <td>phoneticSystem</td> <td><xref target="vcard-param-phonetic"/></td> </tr> <tr> <td>Address</td> <td>postcode</td> <td> <xref target="vcard-prop-adr"/> </td> </tr> <tr> <td>Address</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>Address</td> <td>region</td> <td> <xref target="vcard-prop-adr"/> </td> </tr> <tr> <td>Address</td> <td>timeZone</td><td><xref target="vcard-param-tz"/>,<td>Sections <xreftarget="vcard-prop-tz"/></td>target="vcard-param-tz" format="counter"/> and <xref target="vcard-prop-tz" format="counter"/></td> </tr> <tr> <td>AddressComponent</td> <td>phonetic</td> <td><xref target="vcard-param-phonetic"/></td> </tr> <tr> <td>Anniversary</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Anniversary</td> <td>date</td> <td> <xref target="vcard-prop-anniversary"/> </td> </tr> <tr> <td>Anniversary</td> <td>kind</td> <td> <xref target="vcard-prop-anniversary"/> </td> </tr> <tr> <td>Anniversary</td> <td>place</td> <td> <xref target="vcard-prop-anniversary"/> </td> </tr> <tr> <td>Author</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Author</td> <td>name</td> <td> <xref target="vcard-param-author-name"/> </td> </tr> <tr> <td>Author</td> <td>uri</td> <td> <xref target="vcard-param-author"/> </td> </tr> <tr> <td>Calendar</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Calendar</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <!--[rfced] Please review the following questions regarding the text in Table 8 (Appendix A). a) For "Calendar/kind" and "Card/calendars", are the references to Sections 2.13.1 and 2.13.3 correct? We see mention of the kind and calendar properties only in Sections 2.13.2 and 2.13.3. Please let us know if an update is needed. b) For "Card/nicknames", is Section 2.5.5 correct, or should it perhaps be Section 2.5.6? c) For "Link/kind", is Section 2.11.9 correct? We do not see the "kind" property mentioned in that section. Please let us know if an update is needed. d) For "Note/note", please confirm if "note" (singular form) is correct or if it should be "notes" (plural form) per Section 2.11.4. e) For "OnlineService/kind", are Sections 2.7.2 and 2.7.5 correct? We do not see the "kind" property mentioned in either section. Original: Calendar kind Section 2.13.1, Section 2.13.3 Card calendars Section 2.13.1, Section 2.13.3 Card nicknames Section 2.5.5 Link kind Section 2.9.1, Section 2.11.9 Note note Section 2.11.4 OnlineService kind Section 2.7.2, Section 2.7.5 --> <tr> <td>Calendar</td> <td>kind</td><td><xref target="vcard-prop-caladruri"/>,<td>Sections <xref target="vcard-prop-caladruri" format="counter"/> and <xreftarget="vcard-prop-fburl"/></td>target="vcard-prop-fburl" format="counter"/></td> </tr> <tr> <td>Calendar</td> <td>label</td> <td> <xref target="vcard-prop-xablabel"/> </td> </tr> <tr> <td>Calendar</td> <td>mediaType</td> <td> <xref target="vcard-param-mediatype"/> </td> </tr> <tr> <td>Calendar</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>Calendar</td> <td>uri</td><td><xref target="vcard-prop-caladruri"/>,<td>Sections <xref target="vcard-prop-caladruri" format="counter"/> and <xreftarget="vcard-prop-fburl"/></td>target="vcard-prop-fburl" format="counter"/></td> </tr> <tr> <td>Card</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Card</td> <td>@version</td> <td>not applicable</td> </tr> <tr> <td>Card</td> <td>addresses</td> <td> <xref target="vcard-prop-adr"/> </td> </tr> <tr> <td>Card</td> <td>anniversaries</td> <td> <xref target="vcard-prop-anniversary"/> </td> </tr> <tr> <td>Card</td> <td>calendars</td><td><xref target="vcard-prop-caladruri"/>,<td>Sections <xref target="vcard-prop-caladruri"/> and <xreftarget="vcard-prop-fburl"/></td>target="vcard-prop-fburl" format="counter"/></td> </tr> <tr> <td>Card</td> <td>created</td> <td> <xref target="vcard-prop-created"/> </td> </tr> <tr> <td>Card</td> <td>directories</td><td><xref target="vcard-prop-source"/>,<td>Sections <xref target="vcard-prop-source"/> and <xref target="vcard-prop-org-directory"/></td> </tr> <tr> <td>Card</td> <td>emails</td> <td> <xref target="vcard-prop-email"/> </td> </tr> <tr> <td>Card</td> <td>keywords</td> <td> <xref target="vcard-prop-categories"/> </td> </tr> <tr> <td>Card</td> <td>kind</td> <td> <xref target="vcard-prop-kind"/> </td> </tr> <tr> <td>Card</td> <td>language</td> <td> <xref target="vcard-prop-language"/> </td> </tr> <tr> <td>Card</td> <td>links</td><td><xref target="vcard-prop-contact-uri"/>,<td>Sections <xref target="vcard-prop-contact-uri" format="counter"/> and <xreftarget="vcard-prop-url"/></td>target="vcard-prop-url" format="counter"/></td> </tr> <tr> <td>Card</td> <td>localizations</td> <td> <xref target="vcard-param-language"/> </td> </tr> <tr> <td>Card</td> <td>media</td><td><xref target="vcard-prop-photo"/>,<td>Sections <xreftarget="vcard-prop-logo"/>,target="vcard-prop-photo" format="counter"/>, <xreftarget="vcard-prop-sound"/></td>target="vcard-prop-logo" format="counter"/>, and <xref target="vcard-prop-sound" format="counter"/></td> </tr> <tr> <td>Card</td> <td>members</td> <td> <xref target="vcard-prop-member"/> </td> </tr> <tr> <td>Card</td> <td>name</td> <td> <xref target="vcard-prop-n"/> </td> </tr> <tr> <td>Card</td> <td>nicknames</td> <td> <xref target="vcard-prop-n"/> </td> </tr> <tr> <td>Card</td> <td>notes</td> <td> <xref target="vcard-prop-note"/> </td> </tr> <tr> <td>Card</td> <td>onlineServices</td> <td> <xref target="vcard-prop-impp"/> </td> </tr> <tr> <td>Card</td> <td>organizations</td> <td> <xref target="vcard-prop-org"/> </td> </tr> <tr> <td>Card</td> <td>personalInfo</td><td><xref target="vcard-prop-expertise"/>,<td>Sections <xreftarget="vcard-prop-hobby"/>,target="vcard-prop-expertise" format="counter"/>, <xreftarget="vcard-prop-interest"/></td>target="vcard-prop-hobby" format="counter"/>, and <xref target="vcard-prop-interest" format="counter"/></td> </tr> <tr> <td>Card</td> <td>phones</td> <td> <xref target="vcard-prop-tel"/> </td> </tr> <tr> <td>Card</td> <td>preferredLanguages</td> <td> <xref target="vcard-prop-lang"/> </td> </tr> <tr> <td>Card</td> <td>prodId</td> <td> <xref target="vcard-prop-prodid"/> </td> </tr> <tr> <td>Card</td> <td>relatedTo</td> <td> <xref target="vcard-prop-related"/> </td> </tr> <tr> <td>Card</td> <td>schedulingAddresses</td> <td> <xref target="vcard-prop-caladruri"/> </td> </tr> <tr> <td>Card</td> <td>speakToAs</td> <td> <xref target="vcard-prop-gramgender"/> </td> </tr> <tr> <td>Card</td> <td>titles</td> <td> <xref target="vcard-prop-title"/> </td> </tr> <tr> <td>Card</td> <td>uid</td> <td> <xref target="vcard-prop-uid"/> </td> </tr> <tr> <td>Card</td> <td>updated</td> <td> <xref target="vcard-prop-rev"/> </td> </tr> <tr> <td>CryptoKey</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>CryptoKey</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>CryptoKey</td> <td>kind</td> <td>not applicable</td> </tr> <tr> <td>CryptoKey</td> <td>label</td> <td> <xref target="vcard-prop-xablabel"/> </td> </tr> <tr> <td>CryptoKey</td> <td>mediaType</td> <td> <xref target="vcard-param-mediatype"/> </td> </tr> <tr> <td>CryptoKey</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>CryptoKey</td> <td>uri</td> <td> <xref target="vcard-prop-key"/> </td> </tr> <tr> <td>Directory</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Directory</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>Directory</td> <td>kind</td><td><xref target="vcard-prop-source"/>,<td>Sections <xreftarget="vcard-prop-org-directory"/></td>target="vcard-prop-source" format="counter"/> and <xref target="vcard-prop-org-directory" format="counter"/></td> </tr> <tr> <td>Directory</td> <td>label</td> <td> <xref target="vcard-prop-xablabel"/> </td> </tr> <tr> <td>Directory</td> <td>listAs</td> <td> <xref target="vcard-param-index"/> </td> </tr> <tr> <td>Directory</td> <td>mediaType</td> <td> <xref target="vcard-param-mediatype"/> </td> </tr> <tr> <td>Directory</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>Directory</td> <td>uri</td><td><xref target="vcard-prop-source"/>,<td>Sections <xreftarget="vcard-prop-org-directory"/></td>target="vcard-prop-source" format="counter"/> and <xref target="vcard-prop-org-directory" format="counter"/></td> </tr> <tr> <td>EmailAddress</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>EmailAddress</td> <td>address</td> <td> <xref target="vcard-prop-email"/> </td> </tr> <tr> <td>EmailAddress</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>EmailAddress</td> <td>label</td> <td> <xref target="vcard-prop-xablabel"/> </td> </tr> <tr> <td>EmailAddress</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>LanguagePref</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>LanguagePref</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>LanguagePref</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>Link</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Link</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>Link</td> <td>kind</td><td><xref target="vcard-prop-contact-uri"/>,<td>Sections <xref target="vcard-prop-contact-uri" format="counter"/> and <xreftarget="vcard-prop-url"/></td>target="vcard-prop-url" format="counter"/></td> </tr> <tr> <td>Link</td> <td>label</td> <td> <xref target="vcard-prop-xablabel"/> </td> </tr> <tr> <td>Link</td> <td>mediaType</td> <td> <xref target="vcard-param-mediatype"/> </td> </tr> <tr> <td>Link</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>Link</td> <td>uri</td><td><xref target="vcard-prop-contact-uri"/>,<td>Sections <xref target="vcard-prop-contact-uri" format="counter"/> and <xreftarget="vcard-prop-url"/>></td>target="vcard-prop-url" format="counter"/></td> </tr> <tr> <td>Media</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Media</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>Media</td> <td>kind</td><td><xref target="vcard-prop-photo"/>,<td>Sections <xreftarget="vcard-prop-logo"/>,target="vcard-prop-photo" format="counter"/>, <xreftarget="vcard-prop-sound"/></td>target="vcard-prop-logo" format="counter"/>, and <xref target="vcard-prop-sound" format="counter"/></td> </tr> <tr> <td>Media</td> <td>label</td> <td> <xref target="vcard-prop-xablabel"/> </td> </tr> <tr> <td>Media</td> <td>mediaType</td> <td> <xref target="vcard-param-mediatype"/> </td> </tr> <tr> <td>Media</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>Media</td> <td>uri</td><td><xref target="vcard-prop-photo"/>,<td>Sections <xreftarget="vcard-prop-logo"/>,target="vcard-prop-photo" format="counter"/>, <xref target="vcard-prop-logo" format="counter"/>, and <xreftarget="vcard-prop-sound"/></td>target="vcard-prop-sound" format="counter"/></td> </tr> <tr> <td>Name</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Name</td> <td>components</td><td><xref target="vcard-prop-n"/>,<td>Sections <xref target="vcard-prop-n" format="counter"/> and <xreftarget="vcard-param-jscomps"/></td>target="vcard-param-jscomps" format="counter"/></td> </tr> <tr> <td>Name</td> <td>defaultSeparator</td><td><xref target="vcard-prop-n"/>,<td>Sections <xref target="vcard-prop-n" format="counter"/> and <xreftarget="vcard-param-jscomps"/></td>target="vcard-param-jscomps" format="counter"/></td> </tr> <tr> <td>Name</td> <td>full</td> <td> <xref target="vcard-prop-fn"/> </td> </tr> <tr> <td>Name</td> <td>phoneticScript</td><td><td>Sections <xreftarget="vcard-param-phonetic"/>,target="vcard-param-phonetic" format="counter"/> and <xreftarget="vcard-param-script"/>target="vcard-param-script" format="counter"/> </td> </tr> <tr> <td>Name</td> <td>phoneticSystem</td> <td><xref target="vcard-param-phonetic"/></td> </tr> <tr> <td>Name</td> <td>isOrdered</td><td><xref target="vcard-prop-n"/>,<td>Sections <xref target="vcard-prop-n" format="counter"/> and <xreftarget="vcard-param-jscomps"/></td>target="vcard-param-jscomps" format="counter"/></td> </tr> <tr> <td>Name</td> <td>sortAs</td> <td> <xref target="vcard-param-sortas"/> </td> </tr> <tr> <td>NameComponent</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>NameComponent</td> <td>kind</td> <td> <xref target="vcard-prop-n"/> </td> </tr> <tr> <td>NameComponent</td> <td>phonetic</td> <td><xref target="vcard-param-phonetic"/></td> </tr> <tr> <td>NameComponent</td> <td>value</td> <td> <xref target="vcard-prop-n"/> </td> </tr> <tr> <td>Nickname</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Nickname</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>Nickname</td> <td>name</td> <td> <xref target="vcard-prop-n"/> </td> </tr> <tr> <td>Nickname</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>Note</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Note</td> <td>author</td><td><xref target="vcard-param-author"/>,<td>Sections <xreftarget="vcard-param-author-name"/></td>target="vcard-param-author" format="counter"/> and <xref target="vcard-param-author-name" format="counter"/></td> </tr> <tr> <td>Note</td> <td>created</td> <td> <xref target="vcard-param-created"/> </td> </tr> <tr> <td>Note</td> <td>note</td> <td> <xref target="vcard-prop-note"/> </td> </tr> <tr> <td>OnlineService</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>OnlineService</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>OnlineService</td> <td>kind</td><td><xref target="vcard-prop-impp"/>,<td>Sections <xreftarget="vcard-prop-socialprofile"/></td>target="vcard-prop-impp" format="counter"/> and <xref target="vcard-prop-socialprofile" format="counter"/></td> </tr> <tr> <td>OnlineService</td> <td>label</td> <td> <xref target="vcard-prop-xablabel"/> </td> </tr> <tr> <td>OnlineService</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>OnlineService</td> <td>service</td> <td> <xref target="vcard-param-service-type"/> </td> </tr> <tr> <td>OnlineService</td> <td>uri</td><td><xref target="vcard-prop-impp"/>,<td>Sections <xref target="vcard-prop-impp" format="counter"/> and <xreftarget="vcard-prop-socialprofile"/></td>target="vcard-prop-socialprofile" format="counter"/></td> </tr> <tr> <td>OnlineService</td> <td>user</td> <td> <xref target="vcard-param-username"/> </td> </tr> <tr> <td>OrgUnit</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>OrgUnit</td> <td>name</td> <td> <xref target="vcard-prop-org"/> </td> </tr> <tr> <td>OrgUnit</td> <td>sortAs</td> <td> <xref target="vcard-param-sortas"/> </td> </tr> <tr> <td>Organization</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Organization</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>Organization</td> <td>name</td> <td> <xref target="vcard-prop-org"/> </td> </tr> <tr> <td>Organization</td> <td>sortAs</td> <td> <xref target="vcard-param-sortas"/> </td> </tr> <tr> <td>Organization</td> <td>units</td> <td> <xref target="vcard-prop-org"/> </td> </tr> <tr> <td>PartialDate</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>PartialDate</td> <td>calendarScale</td> <td> <xref target="vcard-param-calscale"/> </td> </tr> <tr> <td>PartialDate</td> <td>day</td> <td> <xref target="vcard-type-datetime"/> </td> </tr> <tr> <td>PartialDate</td> <td>month</td> <td> <xref target="vcard-type-datetime"/> </td> </tr> <tr> <td>PartialDate</td> <td>year</td> <td> <xref target="vcard-type-datetime"/> </td> </tr> <tr> <td>PatchObject</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>PersonalInfo</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>PersonalInfo</td> <td>kind</td><td><xref target="vcard-prop-expertise"/>,<td>Sections <xref target="vcard-prop-expertise" format="counter"/>, <xreftarget="vcard-prop-hobby"/>,target="vcard-prop-hobby" format="counter"/>, and <xreftarget="vcard-prop-interest"/></td>target="vcard-prop-interest" format="counter"/></td> </tr> <tr> <td>PersonalInfo</td> <td>listAs</td> <td> <xref target="vcard-param-index"/> </td> </tr> <tr> <td>PersonalInfo</td> <td>level</td> <td> <xref target="vcard-param-level"/> </td> </tr> <tr> <td>PersonalInfo</td> <td>value</td><td><xref target="vcard-prop-expertise"/>,<td>Sections <xreftarget="vcard-prop-hobby"/>,target="vcard-prop-expertise" format="counter"/>, <xreftarget="vcard-prop-interest"/></td>target="vcard-prop-hobby" format="counter"/>, and <xref target="vcard-prop-interest" format="counter"/></td> </tr> <tr> <td>Phone</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Phone</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>Phone</td> <td>features</td> <td> <xref target="vcard-prop-tel"/> </td> </tr> <tr> <td>Phone</td> <td>label</td> <td> <xref target="vcard-prop-xablabel"/> </td> </tr> <tr> <td>Phone</td> <td>number</td> <td> <xref target="vcard-prop-tel"/> </td> </tr> <tr> <td>Phone</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>Pronouns</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Pronouns</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>Pronouns</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>Pronouns</td> <td>pronouns</td> <td> <xref target="vcard-prop-gramgender"/> </td> </tr> <tr> <td>Relation</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Relation</td> <td>relation</td> <td> <xref target="vcard-prop-related"/> </td> </tr> <tr> <td>Resource</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>SchedulingAddress</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>SchedulingAddress</td> <td>contexts</td> <td> <xref target="vcard-param-type"/> </td> </tr> <tr> <td>SchedulingAddress</td> <td>label</td> <td> <xref target="vcard-prop-xablabel"/> </td> </tr> <tr> <td>SchedulingAddress</td> <td>pref</td> <td> <xref target="vcard-param-pref"/> </td> </tr> <tr> <td>SchedulingAddress</td> <td>uri</td> <td> <xref target="vcard-prop-caladruri"/> </td> </tr> <tr> <td>SpeakToAs</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>SpeakToAs</td> <td>grammaticalGender</td> <td> <xref target="vcard-prop-gramgender"/> </td> </tr> <tr> <td>SpeakToAs</td> <td>pronouns</td> <td> <xref target="vcard-prop-gramgender"/> </td> </tr> <tr> <td>AddressComponent</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>AddressComponent</td> <td>kind</td> <td> <xref target="vcard-prop-adr"/> </td> </tr> <tr> <td>AddressComponent</td> <td>value</td> <td> <xref target="vcard-prop-adr"/> </td> </tr> <tr> <td>Timestamp</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Timestamp</td> <td>utc</td> <td> <xref target="vcard-type-datetime"/> </td> </tr> <tr> <td>Title</td> <td>@type</td> <td>not applicable</td> </tr> <tr> <td>Title</td> <td>kind</td> <td> <xref target="vcard-prop-title"/> </td> </tr> <tr> <td>Title</td> <td>name</td> <td> <xref target="vcard-prop-title"/> </td> </tr> <tr> <td>Title</td><td>organization</td><td>organizationId</td> <td> <xref target="vcard-prop-title"/> </td> </tr> </tbody> </table> </section> <section anchor="Acknowledgments" numbered="false"> <name>Acknowledgements</name> <t>The definition and examples of the <xref target="vcard-param-phonetic">PHONETIC</xref> and <xref target="vcard-param-script">SCRIPT</xref> parameters are based on the initial draft version of <xref target="I-D.calconnect-vobject-i18n"/>.</t> </section> <!-- [rfced] Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. address property vs. addresses property Boolean type vs. boolean type (per RFC-to-be 9553) [Note: may we make 1 instance of "Boolean" type lowercase to match use in the companion document? Card vs. card [Note: should this lowercased instance (in Section 2.5.3) perhaps be capitalized for consistency: ...to an individual represented by the card, as do... --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. For example, please consider whether "whitespace" should be updated. --> </back> </rfc>