rfc9555.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" 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>
    <title abbrev="JSContact: Converting from and to vCard">JSContact: Converting from and to vCard</title>
    <seriesInfo name="RFC" value="9555"/>
    <author fullname="Mario Loffredo" initials="M." surname="Loffredo">
      <organization>IIT-CNR/Registro.it</organization>
      <address>
        <postal>
          <street>Via Moruzzi, 1</street>
          <city>Pisa</city>
          <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>
	  <extaddr>PO Box 234</extaddr>
          <street>Collins St. West</street>
          <city>Melbourne</city>
	  <region>VIC</region>
          <code>8007</code>
	  <country>Australia</country>
        </postal>
        <email>rsto@fastmailteam.com</email>
        <uri>https://www.fastmail.com</uri>
      </address>
    </author>
    <date 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.  It defines conversion rules for every JSContact and vCard element registered at IANA at the time of publication.  It also defines new JSContact properties as well as vCard properties and parameters, to support converting arbitrary or unknown JSContact and vCard elements.</t>
    </abstract>
  </front>
  <middle>
    <section>
      <name>Introduction</name>
      <section>
        <name>Motivation</name>
        <t>The JSContact data model and format <xref target="RFC9553"/> aims to be an alternative to the widely used vCard standard <xref target="RFC6350"/> and 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 data in 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 in BCP 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 document are 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 as vCard v4 <xref target="RFC6350"/>.  Properties and parameters of vCard extension RFCs, including those described in "vCard Format Extension for JSContact" <xref target="RFC9554"/>, have been added to the appropriate subsections.</t>
      <section>
        <name>General 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 Card uid Property</name>
          <t>The UID property (<xref target="RFC6350" derivedContent="RFC6350" section="6.7.6" sectionFormat="of"/>) in vCard is optional, but the Card object's uid property (<xref target="RFC9553" derivedContent="RFC9553" section="2.1.9" sectionFormat="of"/>) is mandatory.  Implementations that convert a vCard without a UID property <bcp14>MUST</bcp14> generate a unique identifier as value for the uid 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>Choosing Identifiers</name>
          <t>Multivalued properties in JSContact are typically represented as a JSON object where the object keys are of the Id type (<xref target="RFC9553" derivedContent="RFC9553" section="1.4.1" sectionFormat="of"/>) 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 as key for such entries.  Whatever identifier generation scheme implementations use, they <bcp14>MUST</bcp14> generate values that are valid according to the definition of the Id type in <xref target="RFC9553"/>.  For example, this could be an incrementing number across all identifier keys in the Card object 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>The BOOLEAN type (<xref target="RFC6350" derivedContent="RFC6350" section="4.4" sectionFormat="of"/>) converts to the JSContact Boolean type (<xref target="RFC9553" derivedContent="RFC9553" section="1.3.2" sectionFormat="of"/>).</t>
        </section>
        <section anchor="vcard-type-datetime">
          <name>DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP</name>
          <t>The TIMESTAMP type (<xref target="RFC6350" derivedContent="RFC6350" section="4.3.5" sectionFormat="of"/>) converts to the UTCDateTime type (<xref target="RFC9553" derivedContent="RFC9553" section="1.4.5" sectionFormat="of"/>), unless for anniversaries. For anniversaries, it converts to the Timestamp type (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.1" sectionFormat="of"/>).</t>
	  <t>The DATE type (<xref target="RFC6350" derivedContent="RFC6350" section="4.3.1" sectionFormat="of"/>) converts to a PartialDate object (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.1" sectionFormat="of"/>) when used for an anniversary, unless the DATE value only contains a month or a day (but not both).</t>
	  <t>The following temporal types do not convert to a JSContact datetime type.  Instead, vCard properties or parameters having such value types convert as defined in <xref target="new-jscontact"/>.</t>
	  <ul>
		  <li>TIME (<xref target="RFC6350" derivedContent="RFC6350" section="4.3.2" sectionFormat="of"/>)</li>
		  <li>DATE-TIME (<xref target="RFC6350" derivedContent="RFC6350" section="4.3.3" sectionFormat="of"/>)</li>
		  <li>DATE-AND-OR-TIME (<xref target="RFC6350" derivedContent="RFC6350" section="4.3.4" sectionFormat="of"/>)</li>
		  <li>DATE type values that only define a month or day (but not both)</li>
  </ul>
        </section>
        <section>
          <name>INTEGER</name>
          <t>The INTEGER type (<xref target="RFC6350" derivedContent="RFC6350" section="4.5" sectionFormat="of"/>) converts to the JSContact Int and UnsignedInt types (<xref target="RFC9553" derivedContent="RFC9553" section="1.4.2" sectionFormat="of"/>).</t>
        </section>
        <section>
          <name>FLOAT</name>
          <t>The FLOAT type (<xref target="RFC6350" derivedContent="RFC6350" section="4.6" sectionFormat="of"/>) converts to the JSContact Number type (<xref target="RFC9553" derivedContent="RFC9553" section="1.3.2" sectionFormat="of"/>).</t>
        </section>
        <section>
          <name>LANGUAGE-TAG</name>
          <t>The LANGUAGE-TAG type (<xref target="RFC6350" derivedContent="RFC6350" section="4.8" sectionFormat="of"/>) converts to the JSContact String type (<xref target="RFC9553" derivedContent="RFC9553" section="1.3.2" sectionFormat="of"/>).  The value <bcp14>MUST</bcp14> be a language tag as defined in <xref target="RFC5646"/>.</t>
        </section>
        <section>
          <name>TEXT</name>
          <t>The TEXT type (<xref target="RFC6350" derivedContent="RFC6350" section="4.1" sectionFormat="of"/>) converts to the JSContact String type (<xref target="RFC9553" derivedContent="RFC9553" section="1.3.2" sectionFormat="of"/>).</t>
        </section>
        <section>
          <name>URI</name>
          <t>The URI type (<xref target="RFC6350" derivedContent="RFC6350" section="4.2" sectionFormat="of"/>) converts to the JSContact String type (<xref target="RFC9553" derivedContent="RFC9553" section="1.3.2" sectionFormat="of"/>).  The value <bcp14>MUST</bcp14> be a URI as defined in <xref target="RFC3986" sectionFormat="of" section="3"/></t>
        </section>
        <section>
          <name>UTC-OFFSET</name>
          <t>The UTC-OFFSET type (<xref target="RFC6350" derivedContent="RFC6350" section="4.7" sectionFormat="of"/>) either converts to a String value containing an IANA Time Zone Database entry name (see <xref target="vcard-prop-tz"/>) or does not convert to any JSContact type.  For the latter, vCard properties or parameters having such values convert 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 typically applies 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>The ALTID parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.4" sectionFormat="of"/>) does not convert to an IANA-registered property in JSContact, but several conversion rules make use of this parameter to combine multiple vCard properties into a single JSContact object instance.  For an example of this, see <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 (<xref target="RFC9554" derivedContent="RFC9554" section="4.1" sectionFormat="of"/>) on a NOTE property converts to the Author object's uri property (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.3" sectionFormat="of"/>).  That Author object is set as the value of the Note object's author property (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.3" sectionFormat="of"/>).</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 [RFC9554].

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].
-->	  
        </section>
        <section anchor="vcard-param-author-name">
          <name>AUTHOR-NAME</name>
          <t>The AUTHOR-NAME parameter (<xref target="RFC9554" derivedContent="RFC9554" section="4.2" sectionFormat="of"/>) on a NOTE property converts to the Author object's name property (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.3" sectionFormat="of"/>).  That Author object is set as the value of the Note object's author property.</t>
        </section>
        <section anchor="vcard-param-calscale">
          <name>CALSCALE</name>
          <t>The CALSCALE parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.8" sectionFormat="of"/>) set on a BDAY, DEATHDATE, or ANNIVERSARY property converts to the PartialDate object's calendarScale property (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.1" sectionFormat="of"/>).</t>
        </section>
        <section anchor="vcard-param-cc">
          <name>CC</name>
          <t>The CC parameter (<xref target="RFC8605" derivedContent="RFC8605" section="3.1" sectionFormat="of"/>) on an ADR property converts to the Address object's countryCode property (<xref target="RFC9553" derivedContent="RFC9553" section="2.5.1.1" sectionFormat="of"/>).</t>
        </section>
        <section anchor="vcard-param-created">
          <name>CREATED</name>
          <t>The CREATED parameter (<xref target="RFC9554" derivedContent="RFC9554" section="4.3" sectionFormat="of"/>) on a NOTE property converts to the Note object's created property (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.3" sectionFormat="of"/>).</t>
        </section>
        <section anchor="vcard-param-derived">
          <name>DERIVED</name>
          <t>The DERIVED parameter (<xref target="RFC9554" derivedContent="RFC9554" section="4.4" sectionFormat="of"/>) does not convert to JSContact.  If the DERIVED parameter is set to "true" on a vCard property, then implementations <bcp14>MAY</bcp14> choose not to convert that property.</t>
        </section>
        <section anchor="vcard-param-geo">
          <name>GEO</name>
          <t>The GEO parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.10" sectionFormat="of"/>) set on an ADR property converts to the Address object's coordinates property (<xref target="RFC9553" derivedContent="RFC9553" section="2.5.1.1" sectionFormat="of"/>).</t>
        </section>
        <section anchor="vcard-param-group">
          <name>GROUP</name>
          <t>The GROUP parameter (<xref target="RFC7095" derivedContent="RFC7095" section="7.1" sectionFormat="of"/>) does not convert to JSContact.  It exclusively is for use in jCard and <bcp14>MUST NOT</bcp14> be set in a vCard.</t>
<t>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 jCard "group" parameter in the JSContact properties vCardProps or vCardParams as defined in <xref target="new-jscontact"/>.</t>
          <figure anchor="group_conversion_params">
            <name>Example of How to Preserve the Group Name in vCardParams during 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="vcard"><![CDATA[
item1.TEL;VALUE=uri:tel:+1-555-555-5555
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"phones": {
  "p1": {
    "number": "tel:+1-555-555-5555",
    "vCardParams" : {
     "group" : "item1"
    }
  }
}
]]></sourcecode>
          </figure>
          <figure anchor="group_conversion_props">
            <name>Example of How to Preserve the Group Name in vCardProps during Conversion</name>
            <sourcecode><![CDATA[
item2.X-FOO:bar
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"vCardProps": [
  ["x-foo", {
    "group": "item2"
  }, "unknown", "bar"]
]
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-param-index">
          <name>INDEX</name>
          <t>The INDEX parameter (<xref target="RFC6715" derivedContent="RFC6715" section="3.1" sectionFormat="of"/>) set on the EXPERTISE, HOBBY, INTEREST, and ORG-DIRECTORY properties converts to the PersonalInfo (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.4" sectionFormat="of"/>) and Directory (<xref target="RFC9553" derivedContent="RFC9553" section="2.6.2" sectionFormat="of"/>) objects' listAs property.</t>
        </section>
        <section anchor="vcard-param-language">
          <name>LANGUAGE</name>
          <t>The LANGUAGE parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.1" sectionFormat="of"/>) converts to an entry in the Card object's localizations property (<xref target="RFC9553" derivedContent="RFC9553" section="2.7.1" sectionFormat="of"/>) for that vCard property on which this parameter is set on.  The value of the LANGUAGE parameter defines the language tag key in the localizations 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 Patch per Property: For each vCard property with a LANGUAGE parameter, set the complete path in the PatchObject to the JSContact property that the vCard property converts to.  The value of the patch is the converted property value.  This is simple to process and adequate if the vCard only contains a few properties with the LANGUAGE parameter.</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>LANGUAGE Conversion Example: One Dominant Language</name>
            <sourcecode type="vcard"><![CDATA[
FN;LANGUAGE=EN:John Doe
TITLE;ALTID=1;LANGUAGE=EN:Boss
TITLE;ALTID=1;LANGUAGE=fr:Patron
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"language": "en",
"name": {
  "full": "John Doe"
},
"titles": {
  "t1": {
    "name": "Boss"
  }
},
"localizations": {
  "fr": {
    "titles/t1/name": "Patron"
  }
}
]]></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, add 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>LANGUAGE Conversion Example: Property without Language</name>
            <sourcecode type="vcard"><![CDATA[
FN:John Doe
TITLE;ALTID=1:Boss
TITLE;ALTID=1;LANGUAGE=fr:Patron
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"name": {
  "full": "John Doe"
},
"titles": {
  "t1": {
    "name": "Boss"
  }
},
"localizations": {
  "fr": {
    "titles/t1/name": "Patron"
  }
}
]]></sourcecode>
          </figure>

<!--[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 versions instead.

Current:
   The following example uses non-ASCII characters to demonstrate
   multilingual content.
-->
        </section>
        <section anchor="vcard-param-label">
          <name>LABEL</name>
          <t>The LABEL parameter (<xref target="RFC6350" derivedContent="RFC6350" section="6.3.1" sectionFormat="of"/>) on an ADR property converts to the Address object's full property (<xref target="RFC9553" derivedContent="RFC9553" section="2.5.1" sectionFormat="of"/>).</t>
        </section>
        <section anchor="vcard-param-level">
          <name>LEVEL</name>
          <t>The LEVEL parameter (<xref target="RFC6715" derivedContent="RFC6715" section="3.2" sectionFormat="of"/>) converts to the PersonalInfo object's level property (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.4" sectionFormat="of"/>).  If this parameter is set on the EXPERTISE property, then its values convert as follows:
      </t>
          <ul spacing="compact">
            <li>"beginner" converts to "low";</li>
            <li>"average" converts to "medium"; and</li>
            <li>"expert" converts to "high".</li>
          </ul>
          <t>In all other cases, 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>The MEDIATYPE parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.7" sectionFormat="of"/>) converts to the Resource object's mediaType property (<xref target="RFC9553" derivedContent="RFC9553" section="1.4.4" sectionFormat="of"/>).</t>
        </section>
        <section anchor="vcard-param-phonetic">
          <name>PHONETIC</name>

<!-- [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 (<xref target="RFC9554" derivedContent="RFC9554" section="4.6" sectionFormat="of"/>) converts to the Name (<xref target="RFC9553" derivedContent="RFC9553" section="2.2.1" sectionFormat="of"/>) and Address (<xref target="RFC9553" derivedContent="RFC9553" section="2.5.1" sectionFormat="of"/>) objects' phoneticSystem property unless the parameter value is "script", in which case the phoneticSystem property is not set.</t>
	  <t>The value of the SCRIPT parameter converts to the phoneticScript property (see <xref target="vcard-param-phonetic"/>).</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 component values of the property on which the PHONETIC parameter is set, convert to the respective NameComponent or AddressComponent objects' phonetic properties.</t>
          <t>If more than one property has the PHONETIC parameter set and relates to the same property, then they convert to the Card object's localizations property according to their LANGUAGE parameter values as outlined in <xref target="vcard-param-language"/>.</t>
          <figure anchor="phonetic_conversion">
            <name>PHONETIC Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
LANGUAGE=zh-Hant
N;ALTID=1;LANGUAGE=zh-Hant:孫;中山;文,逸仙;;
N;ALTID=1;PHONETIC=jyut;
  SCRIPT=Latn;LANGUAGE=yue:syun1;zung1saan1;man4,jat6sin1;;
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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"
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-param-pid">
          <name>PID</name>
          <t>The PID parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.5" sectionFormat="of"/>) converts to the vCardParams property; see <xref target="jscontact-prop-vcardparams"/>.</t>
        </section>
        <section anchor="vcard-param-pref">
          <name>PREF</name>
          <t>The PREF parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.3" sectionFormat="of"/>) converts to the pref property of that JSContact object, to which the vCard property having this parameter converts.</t>
        </section>
        <section anchor="vcard-param-propid">
          <name>PROP-ID</name>
	  <t>The PROP-ID parameter (<xref target="RFC9554" derivedContent="RFC9554" section="4.7" sectionFormat="of"/>) converts to the Id-typed key of the JSContact object to which the vCard property having this parameter converts.</t>
          <figure anchor="propid_conversion">
            <name>PROP-ID Conversion Example</name>
            <sourcecode type="vcard"><![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
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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"
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-param-script">	  
          <name>SCRIPT</name>
          <t>The SCRIPT parameter (<xref target="RFC9554" derivedContent="RFC9554" section="4.8" sectionFormat="of"/>) converts to the Name (<xref target="RFC9553" derivedContent="RFC9553" section="2.2.1" sectionFormat="of"/>) or Address (<xref target="RFC9553" derivedContent="RFC9553" section="2.5.1" sectionFormat="of"/>) objects' phoneticScript property.</t>
          <t>Also see <xref target="vcard-param-phonetic"/>.</t>
        </section>
        <section anchor="vcard-param-service-type">
          <name>SERVICE-TYPE</name>
	  <t>The SERVICE-TYPE parameter (<xref target="RFC9554" derivedContent="RFC9554" section="4.9" sectionFormat="of"/>) converts to the OnlineService object's service property (<xref target="RFC9553" derivedContent="RFC9553" section="2.3.2" sectionFormat="of"/>).</t>
        </section>
        <section anchor="vcard-param-sortas">
          <name>SORT-AS</name>
          <t>The SORT-AS parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.9" sectionFormat="of"/>) converts to the Name, Organization, and OrgUnit objects' sortAs properties.</t>
        </section>
        <section anchor="vcard-param-type">
          <name>TYPE</name>

<!--[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 (<xref target="RFC6350" derivedContent="RFC6350" section="5.6" sectionFormat="of"/>) either converts to the contexts property or the kind property, as defined in later sections. If not specified otherwise, the vCard "home" and "work" parameter values convert to the JSContact "private" and "work" contexts, respectively.</t>
        </section>
        <section anchor="vcard-param-tz">
          <name>TZ</name>
          <t>The TZ parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.11" sectionFormat="of"/>) on an ADR property converts to the Address object's timeZone property (<xref target="RFC9553" derivedContent="RFC9553" section="2.5.1" sectionFormat="of"/>).  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>The USERNAME parameter (<xref target="RFC9554" derivedContent="RFC9554" section="4.10" sectionFormat="of"/>) converts to the OnlineService object's user property (<xref target="RFC9553" derivedContent="RFC9553" section="2.3.2" sectionFormat="of"/>).</t>
        </section>
        <section anchor="vcard-param-value">
          <name>VALUE</name>
          <t>The VALUE parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.2" sectionFormat="of"/>) does not convert to an IANA-registered property in JSContact.  To preserve properties with experimental values, see Sections <xref target="jscontact-prop-vcardprops" format="counter"/> and <xref target="jscontact-prop-vcardparams" format="counter"/>.</t>
        </section>
      </section>
      <section>
        <name>General Properties</name>
        <section>
          <name>BEGIN and END</name>
          <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 (<xref target="RFC6350" derivedContent="RFC6350" section="6.1.4" sectionFormat="of"/>) converts to the kind property (<xref target="kind_conversion"/>).  Allowed values are those described in <xref 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>KIND Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
KIND:individual
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"kind": "individual"
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-source">
          <name>SOURCE</name>
          <t>The SOURCE property (<xref target="RFC6350" derivedContent="RFC6350" section="6.1.3" sectionFormat="of"/>) converts to a Directory object (<xref target="RFC9553" derivedContent="RFC9553" section="2.6.2" sectionFormat="of"/>) in the Card object's directories property (<xref target="source_conversion"/>).  The Directory object's kind property is set to "entry".  The uri property is set to the SOURCE property value.</t>
          <t>The PREF and MEDIATYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="source_conversion">
            <name>SOURCE Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
SOURCE:https://dir.example.com/addrbook/jdoe/Jean%20Dupont.vcf
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"directories": {
   "ENTRY-1": {
     "kind": "entry",
     "uri": "https://dir.example.com/addrbook/jdoe/Jean%20Dupont.vcf"
   }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-xml">
          <name>XML</name>
          <t>The XML property (<xref target="RFC6350" derivedContent="RFC6350" section="6.1.5" sectionFormat="of"/>) converts to the vCardProps property; see <xref target="jscontact-prop-vcardprops"/>.</t>
        </section>
      </section>
      <section>
        <name>Identification Properties</name>
        <section anchor="vcard-prop-anniversary">
	<name>ANNIVERSARY, BDAY, BIRTHPLACE, DEATHDATE, and DEATHPLACE</name>
	<t>The following properties all convert to Anniversary objects in the Card object's anniversaries property (<xref target="anniversary_conversion"/>):</t>
		<ul spacing="compact">
			<li>ANNIVERSARY (<xref target="RFC6350" derivedContent="RFC6350" section="6.2.6" sectionFormat="of"/>)</li>
			<li>BDAY (<xref target="RFC6350" derivedContent="RFC6350" section="6.2.5" sectionFormat="of"/>)</li>
			<li>BIRTHPLACE (<xref target="RFC6474" derivedContent="RFC6474" section="2.1" sectionFormat="of"/>)</li>
			<li>DEATHDATE (<xref target="RFC6474" derivedContent="RFC6474" section="2.3" sectionFormat="of"/>)</li>
			<li>DEATHPLACE (<xref target="RFC6474" derivedContent="RFC6474" section="2.2" sectionFormat="of"/>)</li>
	</ul>

            <t>BDAY and BIRTHPLACE convert to an Anniversary object (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.1" sectionFormat="of"/>) having the date and place properties set.  The kind poperty is set to "birth".
            </t>
            <t>DEATHDATE and DEATHPLACE convert to an Anniversary object having the date and place properties set.  The Anniversary object's kind property is set to "death".
            </t>
            <t>ANNIVERSARY converts to the Anniversary object's date property.  The Anniversary object's kind property is set to "wedding".</t>
          <t>If the BIRTHPLACE or DEATHPLACE property value is of type URI using the "geo:" URI scheme, then it converts to the Address object's coordinates property.  If the value type is TEXT then it converts to the Address object's full property.  Otherwise it converts to the vCardProps property; see <xref target="jscontact-prop-vcardprops"/>.</t>
          <t>The ALTID and LANGUAGE parameters of both the BIRTHPLACE and DEATHPLACE properties convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="anniversary_conversion">
            <name>BDAY, BIRTHPLACE, DEATHDATE, DEATHPLACE, and ANNIVERSARY Conversion Example</name>
            <sourcecode type="vcard"><![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
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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
    }
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-fn">
          <name>FN</name>
          <t>The FN property (<xref target="RFC6350" derivedContent="RFC6350" section="6.2.1" sectionFormat="of"/>) converts to the Name object's full 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 case where the vCard contains more than one FN property without the LANGUAGE parameter, convert the FN property that has the least parameters.  If multiple such FN properties are present, choose any of them.  All other FN properties convert to the <xref target="jscontact-prop-vcardprops">vCardProps</xref> property.</t>
          <figure anchor="fn_conversion">
            <name>FN Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
FN:John Q. Public, Esq.
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"name": {
  "full": "John Q. Public, Esq."
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-gender">
          <name>GENDER</name>
          <t>The GENDER property (<xref target="RFC6350" derivedContent="RFC6350" section="6.2.7" sectionFormat="of"/>) does not convert to an IANA-registered property in JSContact.  To convert this property, see <xref target="jscontact-prop-vcardprops"/>.  Alternatively, the Card object's speakToAs property defines how to address and refer to an individual represented by the Card, as do the newly defined vCard GRAMGENDER and PRONOUNS properties of <xref target="RFC9554"/>.</t>
        </section>
        <section anchor="vcard-prop-gramgender">
          <name>GRAMGENDER and PRONOUNS</name>
          <t>The GRAMGENDER property (<xref target="RFC9554" derivedContent="RFC9554" section="3.2" sectionFormat="of"/>) converts to the SpeakToAs object's grammaticalGender property (<xref target="grammatical_gender_pronouns_conversion"/>).</t>
          <t>The PRONOUNS property (<xref target="RFC9554" derivedContent="RFC9554" section="3.4" sectionFormat="of"/>) converts to the SpeakToAs object's pronouns property (<xref target="grammatical_gender_pronouns_conversion"/>).</t>
          <figure anchor="grammatical_gender_pronouns_conversion">
            <name>GRAMGENDER and PRONOUNS Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
GRAMGENDER:NEUTER
PRONOUNS;PREF=2:they/them
PRONOUNS;PREF=1:xe/xir
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"speakToAs": {
  "grammaticalGender": "neuter",
  "pronouns": {
    "PRONOUNS-1": {
      "pronouns": "they/them",
      "pref": 2
    },
    "PRONOUNS-2": {
      "pronouns": "xe/xir",
      "pref": 1
    }
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-n">
          <name>N</name>
          <t>The N property (<xref target="RFC6350" derivedContent="RFC6350" section="6.2.2" sectionFormat="of"/>) converts to a Name object (<xref target="RFC9553" derivedContent="RFC9553" section="2.2.1" sectionFormat="of"/>) in the Card object's name property.
	  Each component in the N property structured value converts to a NameComponent in the Name object's components property.  The following table shows this relation:</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>N 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 "surname2" NameComponent to the Family name component, after all "surname" 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 "generation" NameComponent to the Honorific suffix component.<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 object's isOrdered property value is "true", and the defaultSeparator property and any "separator" NameComponent objects are set according to the parameter value.  The order in the components property <bcp14>MUST</bcp14> adhere to the order of the JSCOMPS parameter value.</t>
          <t>If the JSCOMPS parameter is not set, then the Name object's isOrdered property value is "false", and the defaultSeparator property <bcp14>MUST NOT</bcp14> be set.  The order in the components property <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 object's sortAs 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>N Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
N;SORT-AS="Stevenson,John Philip":Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr.
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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"
  }
}
]]></sourcecode>
          </figure>
          <t>See <xref target="vcard-param-jscomps-examples"/> for examples of using the JSCOMPS parameter for vCard-structured property values.</t>
        </section>
        <section anchor="vcard-prop-nickname">
          <name>NICKNAME</name>
          <t>The NICKNAME property (<xref target="RFC6350" derivedContent="RFC6350" section="6.2.3" sectionFormat="of"/>) converts to a Nickname object (<xref target="RFC9553" derivedContent="RFC9553" section="2.2.2" sectionFormat="of"/>) in the Card object's nicknames property (<xref target="nickname_conversion"/>).  The name property is set to the NICKNAME property value.</t>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="nickname_conversion">
            <name>NICKNAME Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
NICKNAME:Johnny
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"nicknames": {
   "NICK-1": {
    "name": "Johnny"
   }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-photo">
          <name>PHOTO</name>
          <t>The PHOTO property (<xref target="RFC6350" derivedContent="RFC6350" section="6.2.4" sectionFormat="of"/>) converts to a Media object (<xref target="RFC9553" derivedContent="RFC9553" section="2.6.4" sectionFormat="of"/>) in the Card object's media property (<xref target="photo_conversion"/>).  The Media object's kind property is set to "photo" and the uri property is set to the PHOTO value.</t>
          <t>The PREF and MEDIATYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="photo_conversion">
            <name>PHOTO Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
PHOTO:https://www.example.com/pub/photos/jqpublic.gif
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"media": {
   "PHOTO-1": {
     "kind": "photo",
     "uri": "https://www.example.com/pub/photos/jqpublic.gif"
   }
}
]]></sourcecode>
          </figure>
        </section>
      </section>
      <section>
        <name>Delivery Addressing Properties</name>
        <section anchor="vcard-prop-adr">
          <name>ADR</name>
          <t>The ADR property (<xref target="RFC6350" derivedContent="RFC6350" section="6.3.1" sectionFormat="of"/>) converts to an Address object (<xref target="RFC9553" derivedContent="RFC9553" section="2.5.1" sectionFormat="of"/>) in the Card object's addresses property.  Each component in the ADR-structured property value converts to an AddressComponent in the Address object's components property.</t>
          <t><xref target="RFC9554"/> defines new components 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>ADR 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 this is now disputable given the new components.  Instead, set this component and use the new ADR value format defined in <xref target="RFC9554"/>.</td>
              </tr>
              <tr>
                <td align="left">extended address</td>
                <td align="left">apartment</td>
                <td align="left"><t>To vCard: set the values of the following components:</t>
                <ul>
                  <li>room</li>
                  <li>floor</li>
                  <li>apartment</li>
                  <li>building</li>
                </ul>
                <t>From vCard: ignore if the ADR structured value is of the format defined in <xref target="RFC9554"/>.  Otherwise, convert to "apartment".</t></td>
              </tr>
              <tr>
                <td align="left">street address</td>
                <td align="left">name</td>
                <td align="left"><t>To vCard: set 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: ignore if the ADR structured value is of the format defined in <xref target="RFC9554"/>.  Otherwise, convert to "name".</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 <xref target="RFC9554"/>.</td>
              </tr>
              <tr>
                <td align="left">block</td>
                <td align="left">block</td>
                <td>Defined in <xref target="RFC9554"/>.</td>
              </tr>
              <tr>
                <td align="left">building</td>
                <td align="left">building</td>
                <td>Defined in <xref target="RFC9554"/>.</td>
              </tr>
              <tr>
                <td align="left">direction</td>
                <td align="left">direction</td>
                <td>Defined in <xref target="RFC9554"/>.</td>
              </tr>
              <tr>
                <td align="left">district</td>
                <td align="left">district</td>
                <td>Defined in <xref target="RFC9554"/>.</td>
              </tr>
              <tr>
                <td align="left">floor</td>
                <td align="left">floor</td>
                <td>Defined in <xref target="RFC9554"/>.</td>
              </tr>
              <tr>
                <td align="left">landmark</td>
                <td align="left">landmark</td>
                <td>Defined in <xref target="RFC9554"/>.</td>
              </tr>
              <tr>
                <td align="left">room</td>
                <td align="left">room</td>
                <td>Defined in <xref target="RFC9554"/>.</td>
              </tr>
              <tr>
                <td align="left">street number</td>
                <td align="left">number</td>
                <td>Defined in <xref target="RFC9554"/>.</td>
              </tr>
              <tr>
                <td align="left">subdistrict</td>
                <td align="left">subdistrict</td>
                <td>Defined in <xref target="RFC9554"/>.</td>
              </tr>
            </tbody>
          </table>
          <t>If the <xref target="vcard-param-jscomps">JSCOMPS</xref> parameter is set, then the Address object's isOrdered property value is "true", and the defaultSeparator property and any separator name components are set according to the parameter value.  The order in the components property <bcp14>MUST</bcp14> adhere to the order of the JSCOMPS parameter value.</t>
          <t>If the JSCOMPS parameter is not set, then the Address object's isOrdered property value is "false", and the defaultSeparator property <bcp14>MUST NOT</bcp14> be set.  The order in the components property <bcp14>MUST</bcp14> follow the order of values in the ADR structured value when read from left to right.</t>
	  <ul empty="true">
          <li>The LABEL parameter converts to the Address object's full property.</li>
          <li>The GEO parameter converts to the Address object's coordinates property.</li>
          <li>The TZ parameter converts to the Address object's timeZone property.</li>
          <li>The CC parameter converts to the Address object's countryCode property.</li>
	  </ul>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.  The ADR-specific values of the TYPE parameter defined in Sections <xref target="RFC9554" sectionFormat="bare" section="5.1"/> and <xref target="RFC9554" sectionFormat="bare" section="5.2"/> of <xref target="RFC9554"/> convert to the corresponding entries of the contexts property as defined in <xref target="RFC9553" sectionFormat="of" section="2.5.1"/>.</t>
          <t>The ALTID and LANGUAGE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.  Each possible language-dependent alternative converts to an entry of the PatchObject where the key references the full property.</t>
          <figure anchor="adr_conversion">
            <name>ADR Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
ADR;TYPE=work;CC=US:;;54321 Oak St;Reston;VA;20190;USA;;;;54321;Oak St;;;;;;
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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"
  }
}
]]></sourcecode>
          </figure>
          <t>See <xref target="vcard-param-jscomps-examples"/> for examples of using the JSCOMPS parameter for vCard-structured property values.</t>
        </section>
      </section>
      <section>
        <name>Communications Properties</name>
        <section anchor="vcard-prop-email">
          <name>EMAIL</name>
          <t>The EMAIL property (<xref target="RFC6350" derivedContent="RFC6350" section="6.4.2" sectionFormat="of"/>) converts to an EmailAddress object (<xref target="RFC9553" derivedContent="RFC9553" section="2.3.1" sectionFormat="of"/>) in the Card object's emails property (<xref target="email_conversion"/>).  The EmailAddress object's address property is set to the EMAIL value.</t>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="email_conversion">
            <name>EMAIL Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
EMAIL;TYPE=work:jqpublic@xyz.example.com
EMAIL;PREF=1:jane_doe@example.com
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"emails": {
  "EMAIL-1": {
    "contexts": { "work": true },
    "address": "jqpublic@xyz.example.com"
  },
  "EMAIL-2": {
    "address": "jane_doe@example.com",
    "pref": 1
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-impp">
          <name>IMPP</name>
          <t>The IMPP property (<xref target="RFC6350" derivedContent="RFC6350" section="6.4.3" sectionFormat="of"/>) converts to an OnlineService object (<xref target="RFC9553" derivedContent="RFC9553" section="2.3.2" sectionFormat="of"/>) in the Card object's onlineServices property (<xref target="impp_conversion"/>).  The vCardName property is set to "impp", and the uri property is set to the IMPP value.</t>
          <t>The SERVICE-TYPE, USERNAME, PREF, and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="impp_conversion">
            <name>IMPP Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
IMPP;PREF=1:xmpp:alice@example.com
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"onlineServices": {
  "OS-1": {
    "uri": "xmpp:alice@example.com",
    "pref": 1,
    "vCardName": "impp"
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-lang">
          <name>LANG</name>
          <t>The LANG property (<xref target="RFC6350" derivedContent="RFC6350" section="6.4.4" sectionFormat="of"/>) converts to a LanguagePref object (<xref target="RFC9553" derivedContent="RFC9553" section="2.3.4" sectionFormat="of"/>) in the Card object's preferredLanguages property (<xref target="lang_conversion"/>).  The LANG property value converts to the LanguagePref object's language property value.</t>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="lang_conversion">
            <name>LANG Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
LANG;TYPE=work;PREF=1:en
LANG;TYPE=work;PREF=2:fr
LANG;TYPE=home:fr
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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 }
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-language">
          <name>LANGUAGE</name>
	  <t>The LANGUAGE property (<xref target="RFC9554" derivedContent="RFC9554" section="3.3" sectionFormat="of"/>) converts to the Card object's language property (<xref target="languageprop_conversion"/>).</t>
          <figure anchor="languageprop_conversion">
            <name>LANGUAGE Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
LANGUAGE:de-AT
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"language": "de-AT"
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-socialprofile">
          <name>SOCIALPROFILE</name>
	  <t>The SOCIALPROFILE property (<xref target="RFC9554" derivedContent="RFC9554" section="3.5" sectionFormat="of"/>) converts to an OnlineService object (<xref target="RFC9553" derivedContent="RFC9553" section="2.3.2" sectionFormat="of"/>) in the Card object's onlineServices property (<xref target="socialprofile_conversion"/>).  The vCardName property is set to "socialprofile", or it can be omitted.  If the SOCIALPROFILE property value is of type URI, then the OnlineService object's uri property is set, otherwise, the user property is set.</t>
          <t>The SERVICE-TYPE, USERNAME, PREF, and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="socialprofile_conversion">
            <name>SOCIALPROFILE Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
SOCIALPROFILE;SERVICE-TYPE=Mastodon:https://example.com/@foo
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"onlineServices": {
  ...
  "OS-1": {
    "service": "Mastodon",
    "uri": "https://example.com/@foo"
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-tel">
          <name>TEL</name>
          <t>The TEL property (<xref target="RFC6350" derivedContent="RFC6350" section="6.4.1" sectionFormat="of"/>) converts to a Phone object (<xref target="RFC9553" derivedContent="RFC9553" section="2.3.3" sectionFormat="of"/>) in the Card object's phones property (<xref target="tel_conversion"/>).</t>
          <t>The TEL-specific values of the TYPE parameter convert to the features property keys as outlined in <xref target="tel_type_conversion"/>.  Note that <xref target="RFC6350" sectionFormat="of" section="6.4.1"/> defines the default type to be "voice", but the default Phone features property is absent by default.  Accordingly, an implementation <bcp14>SHOULD</bcp14> only set the Phone object's features property if the TEL property actually has a TEL-specific TYPE parameter set.</t>
          <table anchor="tel_type_conversion">
            <name>TEL TYPE 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 object's number property.</t>

          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="tel_conversion">
            <name>TEL Conversion Example</name>
            <sourcecode type="vcard"><![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
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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"
  }
}
]]></sourcecode>
          </figure>
        </section>
      </section>
      <section>
        <name>Geographical Properties</name>
        <section anchor="vcard-prop-geo">
          <name>GEO</name>
          <t>The GEO property (<xref target="RFC6350" derivedContent="RFC6350" section="6.5.2" sectionFormat="of"/>) converts to the Address object's coordinates property (<xref target="RFC9553" derivedContent="RFC9553" section="2.5.1" sectionFormat="of"/>).  Also see <xref target="combine-geo-props"/> to determine which Address object instance to convert to.</t>
        </section>
        <section anchor="vcard-prop-tz">
          <name>TZ</name>
          <t>The TZ property (<xref target="RFC6350" derivedContent="RFC6350" section="6.5.1" sectionFormat="of"/>) converts an Address object (<xref target="RFC9553" derivedContent="RFC9553" section="2.5.1" sectionFormat="of"/>) in the Card object's addresses property.</t>
          <t>A value of type TEXT converts to the Address object's timeZone property.</t>
          <t>A value of type UTC-OFFSET converts to the Address object's timeZone property if the offset has zero minutes and the hour offset is between -12 and +14, both inclusively. Note that:</t>
          <ul>
            <li>If the hour offset is zero, use the time zone name "Etc/UTC".</li>
            <li>Otherwise, construct the time zone name with "Etc/GMT" suffixed with the string representation of the reversed sign hour offset, including the sign but excluding leading zeros and minutes.  For example, the UTC offset value "-0500" converts to "Etc/GMT+5".</li>
          </ul>
          <t>For such property values, also see <xref target="combine-geo-props"/> to determine which Address 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>Combining Geographical Properties</name>
          <t>In vCard, the properties ADR, GEO, and TZ occur independently of each other.  In JSContact, they all convert to properties of an Address object.  It is implementation-specific if these vCard properties convert to <em>separate</em> address instances in 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, GEO, and TZ properties.</li>
          </ul>
        </section>
      </section>
      <section>
        <name>Organizational Properties</name>
        <section anchor="vcard-prop-contact-uri">
          <name>CONTACT-URI</name>
          <t>The CONTACT-URI property (<xref target="RFC8605" derivedContent="RFC8605" section="2.1" sectionFormat="of"/>) converts to a Link object (<xref target="RFC9553" derivedContent="RFC9553" section="2.6.3" sectionFormat="of"/>) in the Card object's links property (<xref target="contact_uri_conversion"/>).  The Link object's kind property is set to "contact" and the uri property is set to the CONTACT-URI property value.</t>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="contact_uri_conversion">
            <name>CONTACT-URI Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
CONTACT-URI;PREF=1:mailto:contact@example.com
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"links": {
  "CONTACT-1": {
    "kind": "contact",
    "uri": "mailto:contact@example.com",
    "pref": 1
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-logo">
          <name>LOGO</name>
          <t>The LOGO property (<xref target="RFC6350" derivedContent="RFC6350" section="6.6.3" sectionFormat="of"/>) converts to a Media object (<xref target="RFC9553" derivedContent="RFC9553" section="2.6.4" sectionFormat="of"/>) in the Card object's media property (<xref target="logo_conversion"/>).  The Media object's kind property is set to "logo" and the uri property is set to the LOGO property value.</t>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="logo_conversion">
            <name>LOGO Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
LOGO:https://www.example.com/pub/logos/abccorp.jpg
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"media": {
  "LOGO-1": {
    "kind": "logo",
    "uri": "https://www.example.com/pub/logos/abccorp.jpg"
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-member">
          <name>MEMBER</name>
	  <t>The MEMBER property (<xref target="RFC6350" derivedContent="RFC6350" section="6.6.5" sectionFormat="of"/>) converts to the Card object's members property (<xref target="group_example"/>).  Each MEMBER property value is a key in the members property.  The PREF parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.3" sectionFormat="of"/>) parameter does not convert to JSContact.</t>
          <figure anchor="group_example">
            <name>Group Example</name>
            <sourcecode type="vcard"><![CDATA[
KIND:group
FN:The Doe family
MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-org">
          <name>ORG</name>
          <t>The ORG property (<xref target="RFC6350" derivedContent="RFC6350" section="6.6.4" sectionFormat="of"/>) converts to an Organization object (<xref target="RFC9553" derivedContent="RFC9553" section="2.2.3" sectionFormat="of"/>) in the Card object's organizations property (<xref target="org_conversion"/>).  The Organization object's name property is set to the ORG property organizational name component.  The Organization object's units property is an array of OrgUnit objects that each contain an organizational unit name component value of the ORG property value.</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>The ALTID and LANGUAGE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <t>The first item of the comma-separated SORT-AS parameter value converts to the sortAs property of the Organization object.  The subsequent items convert to the sortAs property of the corresponding OrgUnit object.</t>
          <t>The TYPE parameter converts according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="org_conversion">
            <name>ORG Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
ORG;SORT-AS="ABC":ABC\, Inc.;North American Division;Marketing
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"organizations": {
  "ORG-1": {
    "name": "ABC, Inc.",
    "units":[
      { "name": "North American Division" },
      { "name": "Marketing" }
    ],
    "sortAs": "ABC"
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-related">
          <name>RELATED</name>
          <t>The RELATED property (<xref target="RFC6350" derivedContent="RFC6350" section="6.6.6" sectionFormat="of"/>) converts to the Card object's relatedTo property (<xref target="related_conversion"/>).  The property value converts to the key in the relatedTo property.  The TYPE parameters convert to the Relation object's relation property (<xref target="RFC9553" derivedContent="RFC9553" section="2.1.8" sectionFormat="of"/>).  Any other parameters convert as defined in <xref target="jscontact-prop-vcardparams"/>.</t>
          <figure anchor="related_conversion">
            <name>RELATED Conversion Example</name>
            <sourcecode type="vcard"><![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.
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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" : { }
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-title">
          <name>TITLE and ROLE</name>
          <t>The TITLE (<xref target="RFC6350" derivedContent="RFC6350" section="6.6.1" sectionFormat="of"/>) and ROLE (<xref target="RFC6350" derivedContent="RFC6350" section="6.6.2" sectionFormat="of"/>) properties convert to a Title object (<xref target="RFC9553" derivedContent="RFC9553" section="2.2.5" sectionFormat="of"/>) in the Card object's titles property (<xref target="title_role_conversion"/>).  The Title object's kind property is set to "title" or "role" for the TITLE and ROLE vCard properties, respectively.  The name property is set to the vCard property value.</t>
          <t>The value of the organizationId property can be derived if the TITLE or ROLE property is a member of a vCard property group and if exactly one other ORG property is also a part of that group.</t>
          <t>The ALTID and LANGUAGE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="title_role_conversion">
            <name>TITLE and ROLE Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
TITLE:Research Scientist
group1.ROLE:Project Leader
group1.ORG:ABC, Inc.
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"titles": {
  "TITLE-1": {
    "kind": "title",
    "name": "Research Scientist"
  },
  "TITLE-2": {
    "kind": "role",
    "name": "Project Leader",
    "organizationId": "ORG-1"
  }
},
"organizations": {
  "ORG-1": {
    "name": "ABC, Inc."
  }
}
]]></sourcecode>
          </figure>
        </section>
      </section>
      <section>
        <name>Personal Information Properties</name>
        <section anchor="vcard-prop-expertise">
          <name>EXPERTISE</name>
          <t>The EXPERTISE property (<xref target="RFC6715" derivedContent="RFC6715" section="2.1" sectionFormat="of"/>) converts to a PersonalInfo object (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.4" sectionFormat="of"/>) in the Card object's personalInfo property (<xref target="expertise_conversion"/>).  The PersonalInfo object's kind property is set to "expertise".</t>
          <t>The INDEX and LEVEL parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="expertise_conversion">
            <name>EXPERTISE Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
EXPERTISE;LEVEL=beginner;INDEX=2:Chinese literature
EXPERTISE;INDEX=1;LEVEL=expert:chemistry
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"personalInfo": {
  "PERSINFO-1" : {
    "kind": "expertise",
    "value": "Chinese literature",
     "level": "low",
     "listAs": 2
  },
  "PERSINFO-2" : {
    "kind": "expertise",
    "value": "chemistry",
    "level": "high",
    "listAs": 1
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-hobby">
          <name>HOBBY</name>
          <t>The HOBBY property (<xref target="RFC6715" derivedContent="RFC6715" section="2.2" sectionFormat="of"/>) converts to a PersonalInfo object (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.4" sectionFormat="of"/>) in the Card object's personalInfo property (<xref target="hobby_conversion"/>).  The PersonalInfo object's kind property is set to "hobby".</t>
          <t>The INDEX and LEVEL parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="hobby_conversion">
            <name>HOBBY Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
HOBBY;INDEX=1;LEVEL=high:reading
HOBBY;INDEX=2;LEVEL=high:sewing
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"personalInfo": {
  "PERSINFO-1" : {
    "kind": "hobby",
    "value": "reading",
    "level": "high",
    "listAs": 1
  },
  "PERSINFO-2" : {
    "kind": "hobby",
    "value": "sewing",
    "level": "high",
    "listAs": 2
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-interest">
          <name>INTEREST</name>
          <t>The INTEREST property (<xref target="RFC6715" derivedContent="RFC6715" section="2.3" sectionFormat="of"/>) converts to a PersonalInfo object (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.4" sectionFormat="of"/>) in the Card object's personalInfo property (<xref target="interest_conversion"/>).  The PersonalInfo object's kind property is set to "interest".</t>
          <t>The INDEX and LEVEL parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="interest_conversion">
            <name>INTEREST Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
INTEREST;INDEX=1;LEVEL=medium:r&b music
INTEREST;INDEX=2;LEVEL=high:rock&roll music
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-org-directory">
          <name>ORG-DIRECTORY</name>
          <t>The ORG-DIRECTORY property (<xref target="RFC6715" derivedContent="RFC6715" section="2.4" sectionFormat="of"/>) <xref target="RFC6715"/> converts to a Directory object (<xref target="RFC9553" derivedContent="RFC9553" section="2.6.2" sectionFormat="of"/>) in the Card object's directories property (<xref target="org_directory_conversion"/>).  The Directory object's kind property is set to "directory".  The uri property is set to the ORG-DIRECTORY property value.</t>
          <t>The INDEX, PREF, and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="org_directory_conversion">
            <name>ORG-DIRECTORY Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
ORG-DIRECTORY;INDEX=1:https://directory.mycompany.example.com
ORG-DIRECTORY;PREF=1:ldap://ldap.tech.example/o=Tech,ou=Engineering
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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
  }
}
]]></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>The CATEGORIES property (<xref target="RFC6350" derivedContent="RFC6350" section="6.7.1" sectionFormat="of"/>) converts to a set of entries of the Card object's keywords 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 entries by order of preference.</t>
          <figure anchor="categories_conversion">
            <name>CATEGORIES Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
CATEGORIES:internet,IETF,Industry,Information Technology
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"keywords": {
  "internet": true,
  "IETF": true,
  "Industry": true,
  "Information Technology": true
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-clientpidmap">
          <name>CLIENTPIDMAP</name>
          <t>The CLIENTPIDMAP property (<xref target="RFC6350" derivedContent="RFC6350" section="6.7.7" sectionFormat="of"/>) converts to the <xref target="jscontact-prop-vcardprops">vCardProps</xref> property.</t>
        </section>
        <section anchor="vcard-prop-created">
          <name>CREATED</name>
	  <t>The CREATED property (<xref target="RFC9554" derivedContent="RFC9554" section="3.1" sectionFormat="of"/>) converts to the Card object's created property (<xref target="created_conversion"/>).</t>
          <figure anchor="created_conversion">
            <name>CREATED Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
CREATED:19940930T143510Z
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"created": "1994-09-30T14:35:10Z"
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-note">
          <name>NOTE</name>
          <t>The NOTE property (<xref target="RFC6350" derivedContent="RFC6350" section="6.7.2" sectionFormat="of"/>) converts to a Note object (<xref target="RFC9553" derivedContent="RFC9553" section="2.8.3" sectionFormat="of"/>) in the Card object's notes property (<xref target="notes_conversion"/>).</t>
          <t>The ALTID and LANGUAGE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="notes_conversion">
            <name>NOTE Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
NOTE;CREATED=20221123T150132Z;AUTHOR-NAME="John":
  Office hours are from 0800 to 1715 EST\, Mon-Fri.
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"notes": {
  "NOTE-1" : {
     "note": "Office hours are from 0800 to 1715 EST, Mon-Fri.",
     "created": "2022-11-23T15:01:32Z",
     "author": {
       "name": "John"
     }
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-prodid">
          <name>PRODID</name>
          <t>The PRODID property (<xref target="RFC6350" derivedContent="RFC6350" section="6.7.3" sectionFormat="of"/>) converts to the Card object's prodId property (<xref target="prodid_conversion"/>).</t>
          <figure anchor="prodid_conversion">
            <name>PRODID Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
PRODID:ACME Contacts App version 1.23.5
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"prodId": "ACME Contacts App version 1.23.5"
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-rev">
          <name>REV</name>
          <t>The REV property (<xref target="RFC6350" derivedContent="RFC6350" section="6.7.4" sectionFormat="of"/>) converts to the Card object's updated property (<xref target="rev_conversion"/>).</t>
          <figure anchor="rev_conversion">
            <name>REV Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
REV:19951031T222710Z
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"updated": "1995-10-31T22:27:10Z"
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-sound">
          <name>SOUND</name>
          <t>The SOUND property (<xref target="RFC6350" derivedContent="RFC6350" section="6.7.5" sectionFormat="of"/>) converts to a Media object (<xref target="RFC9553" derivedContent="RFC9553" section="2.6.4" sectionFormat="of"/>) in the Card object's media property (<xref target="sound_conversion"/>).  The Media object's kind property is set to "sound" and the uri property is set to the SOUND value.</t>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="sound_conversion">
            <name>SOUND Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
SOUND:CID:JOHNQPUBLIC.19960229T080000.xyzMail@example.com
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"media": {
  ...
  "SOUND-1": {
    "kind": "sound",
    "uri": "CID:JOHNQPUBLIC.19960229T080000.xyzMail@example.com"
  }
}
]]></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 (<xref target="RFC6350" derivedContent="RFC6350" section="6.7.6" sectionFormat="of"/>) converts to the Card object's uid property (<xref target="uid_conversion"/>).</t>
          <figure anchor="uid_conversion">
            <name>UID Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"uid": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-url">
          <name>URL</name>
          <t>The URL property (<xref target="RFC6350" derivedContent="RFC6350" section="6.7.8" sectionFormat="of"/>) converts to a Link object (<xref target="RFC9553" derivedContent="RFC9553" section="2.6.3" sectionFormat="of"/>) in the Card object's links property (<xref target="url_conversion"/>).  The Link object's uri property is set to the URL value.</t>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="url_conversion">
            <name>URL Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
URL:https://example.org/restaurant.french/~chezchic.html
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"links": {
  "LINK-1": {
    "uri": "https://example.org/restaurant.french/~chezchic.html"
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-version">
          <name>VERSION</name>
          <t>The VERSION property (<xref target="RFC6350" derivedContent="RFC6350" section="6.7.9" sectionFormat="of"/>) converts to the <xref target="jscontact-prop-vcardprops">vCardProps</xref> property.</t>
        </section>
        <section anchor="vcard-prop-xablabel">
          <name>X-ABLabel</name>
          <t>The X-ABLabel property is experimental but widely in use in existing vCard data.  It converts to the label property of a JSContact object.

<!--[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 of the same group.</t>
          <t>The group name is not preserved; implementations are free to choose any unique group name when converting back to vCard.  For an example on how to preserve the group name, see <xref target="vcard-param-group"/>.</t>
          <figure anchor="xablabel_conversion">
            <name>X-ABLabel Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
item1.TEL;VALUE=uri:tel:+1-555-555-5555
item1.X-ABLabel:foo
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"phones": {
  "p1": {
    "number": "tel:+1-555-555-5555",
    "label": "foo"
  }
}
]]></sourcecode>
          </figure>
        </section>
      </section>
      <section>
        <name>Security Properties</name>
        <section anchor="vcard-prop-key">
          <name>KEY</name>
          <t>The KEY property (<xref target="RFC6350" derivedContent="RFC6350" section="6.8.1" sectionFormat="of"/>) converts to a CryptoKey object (<xref target="RFC9553" derivedContent="RFC9553" section="2.6.1" sectionFormat="of"/>) in the Card object's cryptoKeys property (<xref target="key_conversion"/>).  The CryptoKey object's uri property is set to the KEY property value.</t>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="key_conversion">
            <name>KEY Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
KEY:https://www.example.com/keys/jdoe.cer
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"cryptoKeys": {
  "KEY-1": {
    "uri": "https://www.example.com/keys/jdoe.cer"
  }
}
]]></sourcecode>
          </figure>
        </section>
      </section>
      <section>
        <name>Calendar Properties</name>
        <section anchor="vcard-prop-caladruri">
          <name>CALADRURI</name>
          <t>The CALADRURI property (<xref target="RFC6350" derivedContent="RFC6350" section="6.9.2" sectionFormat="of"/>) converts to a SchedulingAddress object (<xref target="RFC9553" derivedContent="RFC9553" section="2.4.2" sectionFormat="of"/>) in the Card object's schedulingAddresses property (<xref target="caladruri_conversion"/>).  The SchedulingAddress object's uri property is set to the CALADRURI value.</t>
          <t>The PREF parameter (<xref target="RFC6350" derivedContent="RFC6350" section="5.3" sectionFormat="of"/>) converts according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="caladruri_conversion">
            <name>CALADRURI Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
CALADRURI;PREF=1:mailto:janedoe@example.com
CALADRURI:https://example.com/calendar/jdoe
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"schedulingAddresses": {
  "SCHEDULING-1": {
    "uri": "mailto:janedoe@example.com",
    "pref": 1
  },
  "SCHEDULING-2": {
    "uri": "https://example.com/calendar/jdoe"
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-caluri">
          <name>CALURI</name>
          <t>The CALURI property (<xref target="RFC6350" derivedContent="RFC6350" section="6.9.3" sectionFormat="of"/>) converts to a Calendar object (<xref target="RFC9553" derivedContent="RFC9553" section="2.4.1" sectionFormat="of"/>) in the Card object's calendars property (<xref target="caluri_conversion"/>).  The Calendar object's kind property is set to "calendar" and the uri property is set to the CALURI value.</t>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="caluri_conversion">
            <name>CALURI Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
CALURI;PREF=1:https://cal.example.com/calA
CALURI;MEDIATYPE=text/calendar:https://ftp.example.com/calA.ics
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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"
  }
}
]]></sourcecode>
          </figure>
        </section>
        <section anchor="vcard-prop-fburl">
          <name>FBURL</name>
          <t>The FBURL property (<xref target="RFC6350" derivedContent="RFC6350" section="6.9.1" sectionFormat="of"/>) converts to a Calendar object (<xref target="RFC9553" derivedContent="RFC9553" section="2.4.1" sectionFormat="of"/>) in the Card object's calendars property (<xref target="fburl_conversion"/>).  The Calendar object's kind property is set to "freeBusy" and the uri property is set to the FBURL value.</t>
          <t>The PREF and TYPE parameters convert according to the rules defined in <xref target="vcard-parameters"/>.</t>
          <figure anchor="fburl_conversion">
            <name>FBURL Conversion Example</name>
            <sourcecode type="vcard"><![CDATA[
FBURL;PREF=1:https://www.example.com/busy/janedoe
FBURL;MEDIATYPE=text/calendar:https://example.com/busy/project-a.ifb
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"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"
  }
}
]]></sourcecode>
          </figure>
        </section>
      </section>
      <section anchor="vcard-extended">
        <name>Extended Properties and Parameters</name>
        <t>Extended properties and parameters convert as specified in <xref target="new-jscontact"/>.</t>
      </section>
      <section anchor="new-jscontact">
        <name>New JSContact 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>vCardProps</name>
          <dl>
            <dt>vCardProps: JCardProp[] (optional).</dt>
            <dd>Contains vCard properties that are set in the vCard represented by this JSContact object.  The JCardProp type denotes a jCard-encoded vCard property as defined in <xref target="RFC7095" sectionFormat="of" section="3.3"/>.</dd>
            <dt>Example:</dt>
            <dd>
              <t>This illustrates how to convert a vCard extension property:</t>
              <figure anchor="props_conversion">
                <name>JSContact vCardProps Example</name>
                <sourcecode type="vcard"><![CDATA[
item1.X-FOO;X-BAR=Hello:World!
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"vCardProps": [
  ["x-foo", {
    "x-bar": "Hello",
    "group": "item1"
  }, "unknown", "World!"]
]
]]></sourcecode>
              </figure>
            </dd>
          </dl>
        </section>
        <section anchor="jscontact-prop-vcardparams">
          <name>vCardParams</name>
          <dl>
            <dt>vCardParams: String[String|String[]] (optional).</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>Contains vCard parameters that are set on the vCard property represented by this JSContact object.  The value <bcp14>MUST</bcp14> be a JSON object containing vCard property parameters as defined 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 vCardParams Example</name>
                <sourcecode type="vcard"><![CDATA[
EMAIL;X-FOO=Bar:jane_doe@example.com
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"emails": {
  "email1": {
    "address": "jane_doe@example.com",
    "vCardParams": {
      "x-foo": "Bar"
    }
  }
}
]]></sourcecode>
              </figure>
            </dd>
          </dl>
        </section>
        <section anchor="jscontact-prop-vcardname">
          <name>vCardName</name>
          <dl>
            <dt>vCardName: String (optional).</dt>
            <dd>Contains the name of the vCard element that is represented by this JSContact object.  For example, this allows to preserve the name of a vCard property when multiple vCard properties convert the same JSContact type.  The case-insensitive value <bcp14>MUST</bcp14> be valid according to the "name" 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 an OnlineService object (<xref target="RFC9553" derivedContent="RFC9553" section="2.3.2" sectionFormat="of"/>) in JSContact.  The vCardName property value indicates that the vCard source element was IMPP as follows:</t>
              <figure anchor="example-vcardname">
                <name>JSContact vCardName Example</name>
                <sourcecode type="vcard"><![CDATA[
IMPP:xmpp:alice@example.com
]]></sourcecode>
            <sourcecode type="json"><![CDATA[
"onlineServices": {
  "os1": {
    "uri": "xmpp:alice@example.com",
    "vCardName": "impp"
  },
}
]]></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 Card object 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, and each of the PROP-ID parameters <bcp14>MUST</bcp14> be set to the Id-typed key of the converted value (see <xref target="vcard-param-propid"/>).</li>
          <li>
            <t>The full property of the name property in JSContact is optional, but the FN property is mandatory in vCard.  The following rules apply:</t>
            <ul>
              <li>If the Name object's full property is set, then implementations <bcp14>MUST</bcp14> use its value for the vCard FN property.</li>
              <li>If the Name object's full property is not set, then implementations <bcp14>SHOULD</bcp14> derive the full name from the Name object's components property values.  If the isOrdered property is "true", then this can be done by concatenating the name component values.  Otherwise, or alternatively, an implementation can choose any other heuristic to generate the full name from its components such as <xref target="CLDRPersonName"/>.  Implementations <bcp14>MUST</bcp14> set the DERIVED parameter on the FN property.</li>
              <li>Otherwise, the 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>Converting Unknown Properties</name>
          <t>JSContact objects 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">JSPROP</xref> vCard property and <xref target="vcard-param-jsptr">JSPTR</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>Represents a JSContact property in vCard.</dd>
            <dt>Value type:</dt>
            <dd>TEXT; also see "Format definition" below for value restrictions.</dd>
            <dt>Conformance:</dt>
            <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 as defined in <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259" section="2"/>.  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 <xref target="RFC9553"/>.  The value of its JSPTR parameter corresponds to a key in the PatchObject; the value of the JSPROP property corresponds to the value for that key.  When converting from vCard to JSContact, the PatchObject <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 is 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 the top level in a Card object that is unknown to the implementation.</t>
              <figure anchor="jscontact-prop-unknown">
                <name>Unknown Property Example</name>
                <sourcecode type="json"><![CDATA[
"someUnknownProperty": true
]]></sourcecode>
            <sourcecode type="vcard"><![CDATA[
JSPROP;JSPTR="someUnknownProperty":true
]]></sourcecode>
              </figure>
              <t>This illustrates how to convert a vendor-specific property at the top level of a Card object.  Note the required use of quoted string for the JSPTR value, which allows the path to include the COLON (U+003A) character.</t>
              <figure anchor="jscontact-prop-vendor-specific">
                <name>Vendor-Specific Property Conversion Example</name>
                <sourcecode type="json"><![CDATA[
"example.com:foo": {
  "bar": 1234
}
]]></sourcecode>
            <sourcecode type="vcard"><![CDATA[
JSPROP;JSPTR="example.com:foo":{"bar":1234}
]]></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) character, which requires escaping in the JSON pointer.</t>
              <figure anchor="jscontact-prop-nested">
                <name>Nested Vendor-Specific Property Example with a Path Relative to Card</name>
                <sourcecode type="json"><![CDATA[
"phones": {
  "phone1": {
    "number": "tel:+33-01-23-45-67",
    "example.com:foo/bar": "tux hux"
  }
}
]]></sourcecode>
            <sourcecode type="vcard"><![CDATA[
TEL:tel:+33-01-23-45-67
JSPROP;JSPTR="phones/phone1/example.com:foo~1bar":
 "tux hux"
]]></sourcecode>
              </figure>
            </dd>
          </dl>
        </section>
      </section>
      <section>
        <name>New vCard Parameters</name>
        <section anchor="vcard-param-jscomps">
          <name>JSCOMPS</name>
          <dl>
            <dt>Parameter name:</dt>
            <dd>JSCOMPS</dd>
            <dt>Purpose:</dt>
            <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 isOrdered property of the Name or Address object to "true". Otherwise, they <bcp14>MUST</bcp14> set the isOrdered 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 defaultSeparator property.  If it is the empty string, 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 JSContact components and <bcp14>MUST</bcp14> be one of the following two kinds:</t>
              <ol>
                <li>
                  <t>A positional.  This refers to a component value in the vCard structured value.  A position consists of the numeric index of a component in the structured value, optionally followed by a COMMA (U+002C) character and the non-zero index of a value within that component.  The zero index selects the first component or value, respectively.  The second index is zero by default, in which case it <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 <xref target="vcard-param-jscomps-example-positional" format="counter"/> and <xref 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) character, followed by zero or more "param-value" characters (see <xref target="RFC6350" sectionFormat="of" section="3.3"/>), where the COMMA (U+002C) and SEMICOLON (U+003B) characters <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 "separator" 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 <xref 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>Example of a Secondary Positional Index</name>
                <sourcecode name="json"><![CDATA[
"name": {
  "components": [
    { "kind": "given", "value": "Jane" },
    { "kind": "surname", "value": "Doe" }
  ],
  "isOrdered": true
}
]]></sourcecode>
            <sourcecode type="vcard"><![CDATA[
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>Example of Positional Entries</name>
                <sourcecode name="json"><![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
}
]]></sourcecode>
            <sourcecode type="vcard"><![CDATA[
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 " ".  For backwards compatibility, the street address component of the ADR property contains both the street number and name, but it is not referred to in the JSCOMPS parameter and does not contribute to the count of values.</t>
              <figure anchor="vcard-param-jscomps-example-separator">
                <name>Example of Separator Entries</name>
                <sourcecode name="json"><![CDATA[
"addresses": {
  "a1": {
    "components": [
      { "kind": "number", "value": "54321" },
      { "kind": "separator", "value": " " },
      { "kind": "name", "value": "Oak St" },
      { "kind": "locality", "value": "Reston" }
    ],
    "defaultSeparator": ", ",
    "isOrdered": true
  }
}
]]></sourcecode>
            <sourcecode type="vcard"><![CDATA[
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>

<!--[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>This parameter is set on a <xref target="vcard-prop-jsprop">JSPROP</xref> property.  Its value is a JSON pointer <xref target="RFC6901"/> that points to the JSContact property having the value of the JSPROP 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 "param-value" 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, Section 3.3
]]></sourcecode>
            </dd>
            <dt>Example(s):</dt>
            <dd>
              <t>This illustrates a simple example.  For further examples, see <xref target="vcard-prop-jsprop-examples"/>.</t>
              <sourcecode name="" type="vcard"><![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 Section 5 of
   [I-D.ietf-calext-jscontact] and Section 9 of [RFC6350]. 

Current:
   The security considerations for parsing and formatting 
   such data apply and are outlined in Section 4 of
   [RFC9553] and Section 9 of [RFC6350]. 
-->

      The security considerations for parsing and formatting such data apply and are outlined in <xref target="RFC9553" sectionFormat="of" section="4"/> and <xref target="RFC6350" sectionFormat="of" section="9"/>.</t>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <section>
        <name>New vCard Property</name>
        <t>IANA has added the following entry to the "vCard Properties" registry, as defined in <xref target="RFC6350" sectionFormat="of" section="10.3.1"/>.</t>
        <table anchor="new_properties">
          <name>New vCard 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>
              <td align="left">RFC 9555, <xref target="vcard-prop-jsprop"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section>
        <name>New vCard Parameter</name>
        <t>IANA has added the following entry to the "vCard Parameters" registry, as defined in <xref target="RFC6350" sectionFormat="of" section="10.3.2"/>.</t>
        <table anchor="new_parameters">
          <name>New vCard 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>
              <td align="left">RFC 9555, <xref target="vcard-param-jsptr"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section>
        <name>New JSContact Properties</name>
        <t>IANA has added the following entries to the "JSContact Properties" registry.  Note that the Since Version is 1.0, the Until Version is not set, and the Change Controller is IETF for all of these properties.</t>
	
        <table anchor="tab-iana-property-registry" align="center">
          <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>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">vCardName</td>
              <td align="left">String</td>
              <td align="left">Any JSContact object</td>
              <td align="left">common</td>
              <td align="left">RFC 9555, 
                <xref target="jscontact-prop-vcardname" format="default"/></td>
              </tr>
            <tr>
              <td align="left">vCardParams</td>
              <td align="left">String[String|String[]]</td>
              <td align="left">Any JSContact object</td>
	      <td align="left">common</td>
              <td align="left">RFC 9555,
                <xref target="jscontact-prop-vcardparams" format="default"/>
              </td>
            </tr>
            <tr>
              <td align="left">vCardProps</td>
              <td align="left">JCardProp[]</td>
              <td align="left">Card</td>
	      <td align="left">common</td>
              <td align="left">RFC 9555,
                <xref target="jscontact-prop-vcardprops" format="default"/>
              </td>
            </tr>
          </tbody>
        </table>
      </section>
      <section>
        <name>New JSContact Type</name>
        <t>IANA has added the following entry to the "JSContact Types" registry. Note that the Since Version is 1.0, the Until Version is not set, and the Change Controller is IETF for this type.</t>
        <table anchor="tab-iana-jscontact-type-registry" align="left">
          <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>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">JCardProp</td>
	      <td align="left">common</td>
              <td align="left">RFC 9555,
                <xref target="jscontact-prop-vcardprops" format="default"/>
              </td>
            </tr>
          </tbody>
        </table>
      </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:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5646.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6473.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6474.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6715.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6869.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6901.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.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:include 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>Unicode Locale Data Markup Language (LDML) Part 8: Person 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>
          <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 type and property.</t>
      <table anchor="table_convert_jscontact_to_vcard">
        <name>Conversion Rules for JSContact 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>Sections <xref target="vcard-prop-adr" format="counter"/> and
              <xref 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>Sections <xref target="vcard-param-geo" format="counter"/> and <xref 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>Sections <xref 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>Sections <xref 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>Sections 
<xref target="vcard-param-phonetic" format="counter"/> and
<xref 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>Sections <xref 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>Sections <xref target="vcard-prop-caluri" format="counter"/> and <xref 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>Sections <xref target="vcard-prop-caluri" format="counter"/> and <xref 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>Sections <xref target="vcard-prop-caluri"/> and <xref 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>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>Sections <xref target="vcard-prop-contact-uri" format="counter"/> and <xref 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>Sections <xref target="vcard-prop-photo" format="counter"/>, <xref 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-nickname"/>
            </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>Sections <xref target="vcard-prop-expertise" format="counter"/>, <xref 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>Sections <xref 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>Sections <xref 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>
          </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>Sections <xref target="vcard-prop-contact-uri" format="counter"/> and <xref 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>Sections <xref target="vcard-prop-photo" format="counter"/>, <xref 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>Sections <xref target="vcard-prop-photo" format="counter"/>, <xref target="vcard-prop-logo" format="counter"/>, and <xref 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>Sections <xref target="vcard-prop-n" format="counter"/> and
              <xref target="vcard-param-jscomps" format="counter"/></td>
          </tr>
          <tr>
            <td>Name</td>
            <td>defaultSeparator</td>
            <td>Sections <xref target="vcard-prop-n" format="counter"/> and
              <xref 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>Sections
<xref target="vcard-param-phonetic" format="counter"/> and
<xref 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>Sections <xref target="vcard-prop-n" format="counter"/> and
              <xref 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>Sections <xref 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>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>Sections <xref target="vcard-prop-impp" format="counter"/> and <xref 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>Sections <xref target="vcard-prop-expertise" format="counter"/>, <xref target="vcard-prop-hobby" format="counter"/>, and <xref 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>Sections <xref target="vcard-prop-expertise" format="counter"/>, <xref 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>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>