rfc9554.original.xml   rfc9554.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" submiss <!DOCTYPE rfc [
ionType="IETF" category="std" xml:lang="en" consensus="true" docName="draft-ietf <!ENTITY nbsp "&#160;">
-calext-vcard-jscontact-extensions-10" obsoletes="" updates="6350" tocInclude="t <!ENTITY zwsp "&#8203;">
rue" symRefs="true" sortRefs="true" version="3"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" submiss
ionType="IETF" category="std" consensus="true" xml:lang="en" docName="draft-ietf
-calext-vcard-jscontact-extensions-11" number="9554" obsoletes="" updates="6350"
tocInclude="true" symRefs="true" sortRefs="true" version="3">
<front> <front>
<!--[rfced] *AD, changes were submitted twice after the document was
initially approved. Please review the updates from version 10 to
version 12 and let us know if you approve. The updates can be
viewed in this diff file:
https://www.rfc-editor.org/authors/rfc9554-ad-diff.html
-->
<!--[rfced] Would it be correct to make "Extension" plural in the
document title since the document discusses several extensions?
If not, should "Extensions" be made singular in the short title
for consistency? Please review.
Document Title
Original:
vCard Format Extension for JSContact
Perhaps:
vCard Format Extensions for JSContact
...
Short Title
Original:
vCard JSContact Extensions
-->
<title abbrev="vCard JSContact Extensions">vCard Format Extension for JSCont act</title> <title abbrev="vCard JSContact Extensions">vCard Format Extension for JSCont act</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-calext-vcard-jscontact-e xtensions-10"/> <seriesInfo name="RFC" value="9554"/>
<author initials="R." surname="Stepanek" fullname="Robert Stepanek"> <author initials="R." surname="Stepanek" fullname="Robert Stepanek">
<organization>Fastmail</organization> <organization>Fastmail</organization>
<address> <address>
<postal> <postal>
<street>PO Box 234, Collins St West</street> <extaddr>PO Box 234</extaddr>
<street>Collins St. West</street>
<city>Melbourne</city> <city>Melbourne</city>
<code>VIC 8007</code> <region>VIC</region>
<code>8007</code>
<country>Australia</country> <country>Australia</country>
<region> </region>
</postal> </postal>
<email>rsto@fastmailteam.com</email> <email>rsto@fastmailteam.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Loffredo" fullname="Mario Loffredo"> <author initials="M." surname="Loffredo" fullname="Mario Loffredo">
<organization>IIT-CNR</organization> <organization>IIT-CNR</organization>
<address> <address>
<postal> <postal>
<street>Via Moruzzi,1</street> <street>Via Moruzzi, 1</street>
<city>Pisa</city> <city>Pisa</city>
<code>56124</code> <code>56124</code>
<country>Italy</country> <country>Italy</country>
<region> </region> <region></region>
</postal> </postal>
<email>mario.loffredo@iit.cnr.it</email> <email>mario.loffredo@iit.cnr.it</email>
</address> </address>
</author> </author>
<date year="2023" month="August" day="31"/> <date year="2024" month="March"/>
<area>Applications</area> <area>art</area>
<workgroup>Calendaring Extensions</workgroup> <workgroup>calext</workgroup>
<keyword>addressbook</keyword> <keyword>addressbook</keyword>
<keyword>contacts</keyword> <keyword>contacts</keyword>
<keyword>cards</keyword> <keyword>cards</keyword>
<keyword>vCard</keyword> <keyword>vCard</keyword>
<keyword>JSContact</keyword> <keyword>JSContact</keyword>
<abstract> <abstract>
<t> <t>
This document defines a set of new properties for vCard and extends the This document defines a set of new properties for vCard and extends the
use of existing ones. use of existing ones. Their primary purpose is to align the same set of features
Their primary purpose is to align the same set of features between the J between the JSContact and vCard formats, but the new definitions also aim to be
SContact and vCard formats, useful within just the vCard format. This document updates RFC 6350 ("vCard Fo
but the new definitions also aim to be useful within just the vCard form rmat Specification").
at. This document updates
RFC 6350 (vCard).
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <name>Introduction</name>
<t> <t>
The JSContact <xref target="I-D.ietf-calext-jscontact"/> format aims to be an alternative to the The JSContact <xref target="RFC9553"/> format aims to be an alternative to the
vCard <xref target="RFC6350"/> format for representation of contact and address book vCard <xref target="RFC6350"/> format for representation of contact and address book
data. As such, it introduces new semantics that are not covered in the current data. As such, it introduces new semantics that are not covered in the current
definition of vCard and its various extensions. Converting contact data between definition of vCard and its various extensions. Converting contact data between
the two formats is defined in <xref target="I-D.ietf-calext-jscontact-vc the two formats is defined in <xref target="RFC9555"/> with the goal of
ard"/> with the goal of not losing any semantics during conversion. To achieve this, this docume
not losing any semantics during conversion. To do so, this document nt
defines a new set of properties for vCard and extends existing definitio ns. defines a new set of properties for vCard and extends existing definitio ns.
</t> </t>
<section anchor="notational-conventions" numbered="true" toc="default"> <section anchor="notational-conventions" numbered="true" toc="default">
<name>Notational Conventions</name> <name>Notational Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp1 4>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "< bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp1 4>" in this document are to be interpreted as described in BCP 14 <xref target=" RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref ta rget="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> wh en, and only when, they appear in all capitals, as shown here.</t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp1 4>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "< bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp1 4>" in this document are to be interpreted as described in BCP 14 <xref target=" RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref ta rget="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> wh en, and only when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="abnf-notations"> <section anchor="abnf-notations">
<name>ABNF Notations</name> <name>ABNF Notations</name>
<t>The ABNF definitions in this document use the notations of <xref targ et="RFC5234"/>. ABNF rules not defined in this document either are defined in <x ref target="RFC5234"/> (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, an d DIGIT) or <xref target="RFC6350"/>. <t>The ABNF definitions in this document use the notations of <xref targ et="RFC5234"/>. ABNF rules not defined in this document are defined in either <x ref target="RFC5234"/> (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, an d DIGIT) or <xref target="RFC6350"/>.
</t> </t>
</section> </section>
</section> </section>
<section> <section>
<name>Updated Properties</name> <name>Updated Properties</name>
<section anchor="prop-adr"> <section anchor="prop-adr">
<name>ADR</name> <name>ADR</name>
<t>This specification modifies the definition of the "ADR" property. It
extends its structured value with additional address components to better suppo <!--[rfced] For consistency and to match the companion documents, we
rt the variety of international addresses. It separates the address parts that removed the quote marks from the "ADR" property, "N" property,
currently typically are combined in street address component values into distinc and "TYPE" parameter. Please let us know of any objections.
t components.</t> -->
<t>Implementations <bcp14>SHOULD</bcp14> write a
combined value of these components in the street address component for backwards <t>This specification modifies the definition of the ADR property. It e
compatibility, but <bcp14>SHOULD</bcp14> ignore the street component during rea xtends its structured value with additional address components to better support
d if the ADR property value contains any of the new components.</t> the variety of international addresses. It separates the address parts, which
<t>The following change is made to the first paragraph in the "Special N currently are typically combined in street address component values, into distin
otes" section, originally specified in <xref target="RFC6350" section="6.3.1"/>. ct components.</t>
All remaining paragraphs of that section in the original specification still a
pply.</t> <t>Implementations <bcp14>SHOULD</bcp14> write a combined value of these compone
<dl> nts in the street address component for backwards compatibility, but they <bcp14
<dt>Special notes:</dt> >SHOULD</bcp14> ignore the street component during reads if the ADR property val
<dd>The structured type value consists of a sequence of ue contains any of the new components.</t>
address components. The component values MUST be specified in <t>The following change is made to the first paragraph under "Special notes", as
their corresponding position. The structured type value originally specified in <xref target="RFC6350" sectionFormat="of" section="6.3.
corresponds, in sequence, to<br/> 1"/>. The remaining paragraphs of that section in the original specification st
the post office box;<br/> ill apply.</t>
the extended address (e.g., apartment or suite number);<br/> <t>
the street address;<br/>
the locality (e.g., city);<br/> <!-- [rfced] Please review whether any of the notes in this document
the region (e.g., state or province);<br/> should be in the <aside> element. It is defined as "a container for
the postal code;<br/> content that is semantically less important or tangential to the
the country name (full name in the language specified in content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
<xref target="RFC6350" section="5.1"/>);<br/> .
the room or suite number or identifier<br/> -->
the apartment number, extension designation or box number.<br/>
the building floor or level;<br/> Special notes: The structured type value consists of a sequence of
the street number;<br/> address components. The component values <bcp14>MUST</bcp14> be spe
the street name;<br/> cified in
the building, tower, condominium;<br/> their corresponding position. The structured type value
the block name or number;<br/> corresponds, in sequence, to the</t>
the subdistrict;<br/> <ul spacing="compact" empty="true">
the district;<br/> <li> post office box;</li>
the landmark or another publicly known prominent feature that ca <li> extended address (e.g., apartment or suite number);</li>
n substitute the street name and number, e.g., "White House"", "Taj Mahal"";<br/ <li> street address;</li>
> <li> locality (e.g., city);</li>
the cardinal direction or quadrant, e.g., "North"<br/> <li> region (e.g., state or province);</li>
</dd> <li> postal code;</li>
</dl> <li> country name (full name in the language specified in
<t>The following change is made to the definition of "ADR-value" in the <xref target="RFC6350" sectionFormat="of" section="5.1"/>);<
"ABNF" section, originally specified in <xref target="RFC6350" section="6.3.1"/> /li>
.</t> <li> room, suite number, or identifier;</li>
<dl> <li> apartment number, extension designation, or box number;</li>
<dt>ABNF</dt> <li> building floor or level;</li>
<dd> <li> street number;</li>
<li> street name;</li>
<li> building, tower, or condominium;</li>
<li> block name or number;</li>
<li> subdistrict;</li>
<li> district;</li>
<li> landmark or another publicly known prominent feature that ca
n substitute the street name and number (e.g., "White House" and "Taj Mahal"); a
nd </li>
<li> the cardinal direction or quadrant (e.g., "north").</li>
</ul>
<t>The following change is made to the definition of "ADR-value" under "
ABNF", as originally specified in <xref target="RFC6350" sectionFormat="of" sect
ion="6.3.1"/>.</t>
<!-- [rfced] Please review whether the "type" attribute should be set for
all sourcecode elements in the XML file. If the current list of preferred
values for "type"
(https://www.rfc-editor.org/materials/sourcecode-types.txt) does not
contain an applicable type, then feel free to suggest a new one.
Also, it is acceptable to leave the "type" attribute not set. -->
<!--[rfced] When we attempted to validate the ABNF using <https://author-tools.i
etf.org/abnf>, we received the following error.
Please review and let us know how we may fix this.
(130:0): error: Rule SCRIPT was already defined on line 123 of
parsing failed: 1 errors encountered
-->
<!--[rfced] The following three lines exceed the 72-character limit
within the sourcecode. Please review and let us know where you
prefer to place the line breaks.
Original
Section 2.1:
ADR-component-streetnumber ";" ADR-component-streetname ";" (2 characters ov
er)
;;123 Main Street;Any Town;CA;91921-1234;U.S.A.;;123;Main Street;;;;;;; (4
over)
Section 4.6:
phonetic-value = "ipa" / "piny" / "jyut" / "script" / iana-token / x-name (7
over)
-->
<t>ABNF</t>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
ADR-value = ADR-component-pobox ";" ADR-component-ext ";" ADR-value = ADR-component-pobox ";" ADR-component-ext ";"
ADR-component-street ";" ADR-component-locality ";" ADR-component-street ";" ADR-component-locality ";"
ADR-component-region ";" ADR-component-code ";" ADR-component-region ";" ADR-component-code ";"
ADR-component-country ";" ADR-component-country ";"
; above components are defined in RFC 6350, section 6.3.1 ; above components are defined in RFC 6350, Section 6.3.1
ADR-component-room ";" ADR-component-apartment ";" ADR-component-room ";" ADR-component-apartment ";"
ADR-component-floor ";" ADR-component-floor ";"
ADR-component-streetnumber ";" ADR-component-streetname ";" ADR-component-streetnumber ";" ADR-component-streetname ";"
ADR-component-building ";" ADR-component-block ";" ADR-component-building ";" ADR-component-block ";"
ADR-component-subdistrict ";" ADR-component-district ";" ADR-component-subdistrict ";" ADR-component-district ";"
ADR-component-landmark ";" ADR-component-direction ADR-component-landmark ";" ADR-component-direction
ADR-component-pobox = list-component ADR-component-pobox = list-component
ADR-component-ext = list-component ADR-component-ext = list-component
ADR-component-street = list-component ADR-component-street = list-component
ADR-component-locality = list-component ADR-component-locality = list-component
skipping to change at line 141 skipping to change at line 213
ADR-component-floor = list-component ADR-component-floor = list-component
ADR-component-streetnumber = list-component ADR-component-streetnumber = list-component
ADR-component-streetname = list-component ADR-component-streetname = list-component
ADR-component-building = list-component ADR-component-building = list-component
ADR-component-block = list-component ADR-component-block = list-component
ADR-component-subdistrict = list-component ADR-component-subdistrict = list-component
ADR-component-district = list-component ADR-component-district = list-component
ADR-component-landmark = list-component ADR-component-landmark = list-component
ADR-component-direction = list-component ADR-component-direction = list-component
]]></sourcecode> ]]></sourcecode>
</dd>
</dl>
<t>The following change is made to the "Example" section, originally spe
cified in <xref target="RFC6350" section="6.2.2"/>.</t>
<dl>
<dt>Example: In this example, the post office box and the extended add <!--[rfced] We updated Section "6.2.2" to "6.3.1" in the following
ress components are absent. The street number and name are added both as separa text as Section "6.2.2" is not the correct section reference
te components, as well as combined in the street component for backwards-compati (note that the second paragraph is included for context). Please
bility.</dt> let us know of any objections.
<dd>
Original:
The following change is made to the "Example" section, originally
specified in Section 6.2.2 of [RFC6350].
Example: In this example, the post office box and the extended address
components are absent. The street number and name are both added as
separate components and are combined in the street component for backwards
compatibility.
Current:
The following change is made under "Example", as originally
specified in Section 6.3.1 of [RFC6350].
Example: In this example, the post office box and the extended address
components are absent. The street number and name are both added as
separate components and are combined in the street component for
backwards compatibility.
-->
<t>The following change is made under "Example", as originally specified
in <xref target="RFC6350" sectionFormat="of" section="6.3.1"/>.</t>
<t>Example: In this example, the post office box and the extended addr
ess components are absent. The street number and name are both added as separat
e components and are combined in the street component for backwards compatibilit
y.</t>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
ADR;GEO="geo:12.3457,78.910": ADR;GEO="geo:12.3457,78.910":
;;123 Main Street;Any Town;CA;91921-1234;U.S.A.;;123;Main Street;;;;;;; ;;123 Main Street;Any Town;CA;91921-1234;U.S.A.;;123;Main Street;;;;;;;
]]></sourcecode> ]]></sourcecode>
</dd>
</dl>
</section> </section>
<section anchor="prop-n"> <section anchor="prop-n">
<name>N</name> <name>N</name>
<t>This specification modifies the definition of the "N" property. It e <t>This specification modifies the definition of the N property. It ext
xtends its structured value with additional name components to better support in ends its structured value with additional name components to better support inte
ternational names and generation markers. Doing so, this also facilitates forma rnational names and generation markers. In doing so, this also facilitates form
tting N property values using the <xref target="CLDRPersonName">Unicode CLDR Per atting N property values using the Unicode Common Locale Data Repository (CLDR)
son Name</xref> formatting standard.</t> Person Name <xref target="CLDRPersonName"/> formatting standard.</t>
<t>One new component is for secondary surnames, as in some cultures, suc <t>One new component is for secondary surnames, because in some cultures
h secondary surname kinds are used to indicate the paternal and maternal family , such secondary surname kinds are used to indicate the paternal and maternal fa
names or generational names indicating father, grandfather. Another new compone mily names or generational names indicating father or grandfather. Another new
nt indicates a generation ("II", "XVI") or parental relation ("Jr.", "Sr.").</t> component indicates a generation ("II", "XVI") or parental relation ("Jr.", "Sr.
<t>Currently, implementations typically place secondary surnames in the ").</t>
family name components, and generational markers in the honorific suffixes compo <t>Currently, implementations typically place secondary surnames in the
nent. For backwards compatibility, implementations <bcp14>SHOULD</bcp14> add su family name component and generational markers in the honorific suffixes compone
ch values to both the newly defined components and their backwards-compatible co nt. For backwards compatibility, implementations <bcp14>SHOULD</bcp14> add such
unterpart. Reading N property values, implementations <bcp14>SHOULD</bcp14> ign values to both the newly defined components and their backwards-compatible coun
ore any value in the backward-compatible component if an equal value is set in t terpart. Reading N property values, implementations <bcp14>SHOULD</bcp14> ignor
he according new component. For example, a "Jr." that occurs in both honorific e any value in the backwards-compatible component if an equal value is set in th
suffixes and generation should only be handled as a generational marker.</t> e new component accordingly. For example, a "Jr." that occurs in both honorific
<t>The following change is made to the first paragraph in the "Special N suffixes and generation should only be handled as a generational marker.</t>
otes" section, originally specified in <xref target="RFC6350" section="6.2.2"/>. <t>The following change is made to the first paragraph under "Special no
All remaining text of this and the following paragraphs of that section in the te", as originally specified in <xref target="RFC6350" sectionFormat="of" sectio
original specification still apply.</t> n="6.2.2"/>. The remaining paragraphs of that section in the original specificat
<dl> ion still apply.</t>
<dt>Special notes:</dt>
<dd> <!--[rfced] In Section 6.2.2 of RFC 6350, "Special note" is singular,
The structured property value corresponds, in but Section 2.2 of this document uses the plural form. Should
sequence, to the<br/> "notes" be updated to "note" to match RFC 6350 as shown below, or
family names (also known as surnames),<br/> do you prefer the plural form?
given names,<br/>
additional names,<br/> Original:
honorific prefixes,<br/> Special notes: The structured property value corresponds, in
honorific suffixes,<br/> sequence, to the
secondary surname,<br/>
and generation.<br/> Perhaps:
</dd> Special note: The structured property value corresponds, in
</dl> sequence, to the
<t>The following change is made to the "ABNF" section, originally specif -->
ied in <xref target="RFC6350" section="6.2.2"/>.</t> <t>Special notes: The structured property value corresponds, in
<dl> sequence, to the</t>
<dt>ABNF</dt> <ul spacing="compact" empty="true">
<dd> <li>family names (also known as surnames);</li>
<li>given names;</li>
<li>additional names;</li>
<li>honorific prefixes;</li>
<li>honorific suffixes;</li>
<li>secondary surname; and</li>
<li>generation.</li>
</ul>
<t>The following change is made under "ABNF", as originally specified in
<xref target="RFC6350" sectionFormat="of" section="6.2.2"/>.</t>
<t>ABNF</t>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
N-param = "VALUE=text" / sort-as-param / language-param N-param = "VALUE=text" / sort-as-param / language-param
/ altid-param / any-param / altid-param / any-param
N-value = list-component 6(";" list-component) N-value = list-component 6(";" list-component)
]]></sourcecode> ]]></sourcecode>
</dd> <t>The following change is made under "Examples", as originally specifie
</dl> d in <xref target="RFC6350" section="6.2.2"/>.</t>
<t>The following change is made to the "Example" section, originally spe <t>Examples</t>
cified in <xref target="RFC6350" section="6.2.2"/>.</t>
<dl>
<dt>Example</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
N:Public;John;Quinlan;Mr.;Esq. N:Public;John;Quinlan;Mr.;Esq.
N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr. N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr.
]]></sourcecode> ]]></sourcecode>
</dd>
</dl>
<t>No change is required for the definition of the SORT-AS parameter, bu t the new components also apply for use with this parameter.</t> <t>No change is required for the definition of the SORT-AS parameter, bu t the new components also apply for use with this parameter.</t>
</section> </section>
</section> </section>
<section anchor="new-properties"> <section anchor="new-properties">
<name>New Properties</name> <name>New Properties</name>
<section anchor="prop-created"> <section anchor="prop-created">
<name>CREATED</name> <name>CREATED</name>
<dl> <dl>
<dt>Property name:</dt> <dt>Property name:</dt>
<dd>CREATED</dd> <dd>CREATED</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This property defines the date and time when the vCard was created </dd> <dd>Defines the date and time when the vCard was created.</dd>
<dt>Value type:</dt> <dt>Value type:</dt>
<dd>A single timestamp value.</dd> <dd>A single timestamp value.</dd>
<dt>Cardinality:</dt> <dt>Cardinality:</dt>
<dd>*1</dd> <dd>*1</dd>
<dt>Property parameters:</dt> <dt>Property parameters:</dt>
<dd>VALUE</dd> <dd>VALUE</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
This is the time stamp when the vCard was created. Copying the This is the timestamp when the vCard was created. Copying the
vCard across systems does not count as a new creation, nor does vCard across systems does not count as a new creation nor
a new revision. Instead, the time stamp value typically a new revision. Instead, the timestamp value typically
stays unchanged for the existence of the vCard. stays unchanged for the existence of the vCard.
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<t>This property is defined by the following notation:</t> <t>This property is defined by the following notation:</t>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
created = "CREATED" createdparam ":" timestamp created = "CREATED" createdparam ":" timestamp
createdparam = *( createdparam = *(
; ;
; The following are OPTIONAL, ; The following are OPTIONAL
; but MUST NOT occur more than once. ; but MUST NOT occur more than once.
; ;
(";" "VALUE" "=" "timestamp") / (";" "VALUE" "=" "timestamp") /
; ;
; The following are OPTIONAL, ; The following are OPTIONAL
; and MAY occur more than once. ; and MAY occur more than once.
; ;
(";" any-param) (";" any-param)
; ;
) )
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
CREATED:20220705T093412Z CREATED:20220705T093412Z
CREATED;VALUE=TIMESTAMP:20211022T140000-05 CREATED;VALUE=TIMESTAMP:20211022T140000-05
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="prop-gramgender"> <section anchor="prop-gramgender">
<name>GRAMGENDER</name> <name>GRAMGENDER</name>
<dl> <dl>
<dt>Property name:</dt> <dt>Property name:</dt>
<dd>GRAMGENDER</dd> <dd>GRAMGENDER</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd> <dd>Defines which grammatical gender to use in salutations and other g
This property defines which grammatical gender to use in salutations rammatical constructs.
and other grammatical constructs.
</dd> </dd>
<dt>Value type:</dt> <dt>Value type:</dt>
<dd>A single text value, restricted to an enumerated list of allowed v alues.</dd> <dd>A single text value that is restricted to an enumerated list of al lowed values.</dd>
<dt>Cardinality:</dt> <dt>Cardinality:</dt>
<dd>*</dd> <dd>*</dd>
<dt>Property parameters:</dt> <dt>Property parameters:</dt>
<dd>LANG</dd> <dd>LANG, ALTID</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t> <t>
This property defines the grammatical gender that the contact pref ers This property defines the grammatical gender that the contact pref ers
to be addressed by or referred at in written or spoken form. to be addressed by or referred to as in written or spoken form.
For example, the German language distinguishes by grammatical gend er in salutations such as "Sehr geehrte" (feminine) and "Sehr geehrter" (masculi ne). For example, the German language distinguishes by grammatical gend er in salutations such as "Sehr geehrte" (feminine) and "Sehr geehrter" (masculi ne).
Multiple occurrences of this property Multiple occurrences of this property
<bcp14>MUST</bcp14> be distinguished by the LANG parameter. <bcp14>MUST</bcp14> be distinguished by the LANG parameter.
</t> </t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd><t>This property is defined by the following notation:</t>
<t>This property is defined by the following notation:</t>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
gramgender = "GRAMGENDER" gramgender-param gramgender = "GRAMGENDER" gramgender-param
":" gramgender-value ":" gramgender-value
gramgender-param = gramgender-param =
*( *(
; ;
; The following are OPTIONAL, ; The following are OPTIONAL
; but MUST NOT occur more than once. ; but MUST NOT occur more than once.
; ;
(";" language-param) / (";" language-param) /
(";" altid-param) /
; ;
; The following are OPTIONAL, ; The following are OPTIONAL
; and MAY occur more than once. ; and MAY occur more than once.
; ;
(";" any-param) (";" any-param)
; ;
) )
gramgender-value = "animate" / gramgender-value = "animate" /
"common" / "common" /
"feminine" / "feminine" /
"inanimate" / "inanimate" /
"masculine" / "masculine" /
"neuter" / "neuter" /
iana-token / iana-token /
x-name x-name
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
GRAMGENDER:neuter GRAMGENDER:neuter
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="prop-language"> <section anchor="prop-language">
<name>LANGUAGE</name> <name>LANGUAGE</name>
<dl> <dl>
<dt>Property name:</dt> <dt>Property name:</dt>
<dd>LANGUAGE</dd> <dd>LANGUAGE</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This property defines the default language that human-readable tex t values in this vCard should be assumed written in.</dd> <dd>Defines the default language that human-readable text values in th is vCard are assumed to be written in.</dd>
<dt>Value type:</dt> <dt>Value type:</dt>
<dd>A single Language-Tag value as defined in <xref target="RFC6350" s ection="4"/>.</dd> <dd>A single Language-Tag value as defined in <xref target="RFC6350" s ectionFormat="of" section="4"/>.</dd>
<dt>Cardinality:</dt> <dt>Cardinality:</dt>
<dd>*1</dd> <dd>*1</dd>
<dt>Property parameters:</dt> <dt>Property parameters:</dt>
<dd>The LANGUAGE parameter <bcp14>MUST NOT</bcp14> be assigned to this property.</dd> <dd>The LANGUAGE parameter <bcp14>MUST NOT</bcp14> be assigned to this property.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd>
This property defines the language in which property values of type <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in
<tt>TEXT</tt> shall be assumed to be written for this vCard. fixed-width font. In the txt output, there are no changes to the font,
and the quotation marks have been removed.
Please review carefully and let us know if the output is acceptable or if any
updates are needed.
Additionally, note that <tt> appears to be used inconsistently. For example,
some instances of "LANGUAGE" are enclosed with <tt> and some are not.
Please review the terms and let us know if any further updates are needed
for consistency.
-->
<dd>
This property defines the language that property values of type
<tt>TEXT</tt> are assumed to be written in for this vCard.
If a vCard property includes the <tt>LANGUAGE</tt> parameter, then t he If a vCard property includes the <tt>LANGUAGE</tt> parameter, then t he
parameter value has higher precedence than the <tt>LANGUAGE</tt> parameter value has higher precedence than the <tt>LANGUAGE</tt>
property value. property value.
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<t>This property is defined by the following notation:</t> <t>This property is defined by the following notation:</t>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
language-prop = "LANGUAGE" any-param ":" Language-Tag language-prop = "LANGUAGE" any-param ":" Language-Tag
; Language-Tag is defined in RFC6350, Section 4. ; Language-Tag is defined in RFC 6350, Section 4.
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
LANGUAGE:de-AT LANGUAGE:de-AT
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="prop-pronouns"> <section anchor="prop-pronouns">
<name>PRONOUNS</name> <name>PRONOUNS</name>
<dl> <dl>
<dt>Property name:</dt> <dt>Property name:</dt>
<dd>PRONOUNS</dd> <dd>PRONOUNS</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd> <dd>
This property defines the pronouns that shall be used Defines the pronouns that shall be used
to refer to the entity represented by this vCard. to refer to the entity represented by this vCard.
</dd> </dd>
<dt>Value type:</dt> <dt>Value type:</dt>
<dd>A single text value.</dd> <dd>A single text value.</dd>
<dt>Cardinality:</dt> <dt>Cardinality:</dt>
<dd>*</dd> <dd>*</dd>
<dt>Property parameters:</dt> <dt>Property parameters:</dt>
<dd>LANG, PREF, TYPE</dd> <dd>LANG, PREF, TYPE, ALTID</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
This property contains the pronouns that the contact chooses to use for themselves. This property contains the pronouns that the contact chooses to use for themselves.
The value is free-form text. These pronouns shall be used The value is free-form text. These pronouns shall be used
when addressing or referring to the contact. Multiple occurrences o f when addressing or referring to the contact. Multiple occurrences o f
this property <bcp14>MAY</bcp14> define pronouns for multiple langua ges, this property <bcp14>MAY</bcp14> define pronouns for multiple langua ges,
preferences and contexts. Multiple pronouns in the same language preferences, and contexts. Multiple pronouns in the same language
<bcp14>SHOULD</bcp14> use the PREF parameter, otherwise, the order o <bcp14>SHOULD</bcp14> use the PREF parameter; otherwise, the order o
f f
preference is implementation-specific. preference is implementation-specific.
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<t>This property is defined by the following notation:</t> <t>This property is defined by the following notation:</t>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
pronouns = "PRONOUNS" pronouns-param ":" text pronouns = "PRONOUNS" pronouns-param ":" text
pronouns-param = pronouns-param =
*( *(
; ;
; The following are OPTIONAL, ; The following are OPTIONAL
; but MUST NOT occur more than once. ; but MUST NOT occur more than once.
; ;
(";" language-param) / (";" language-param) /
(";" pref-param) / (";" pref-param) /
(";" type-param) / (";" type-param) /
(";" altid-param) / (";" altid-param) /
; ;
; The following are OPTIONAL, ; The following are OPTIONAL
; and MAY occur more than once. ; and MAY occur more than once.
; ;
(";" any-param) (";" any-param)
; ;
) )
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
skipping to change at line 420 skipping to change at line 528
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="prop-socialprofile"> <section anchor="prop-socialprofile">
<name>SOCIALPROFILE</name> <name>SOCIALPROFILE</name>
<dl> <dl>
<dt>Property name:</dt> <dt>Property name:</dt>
<dd>SOCIALPROFILE</dd> <dd>SOCIALPROFILE</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>To specify the URI or username for social media profiles associate d with the object the vCard represents.</dd> <dd>Specifies the URI or username for social media profiles associated with the object the vCard represents.</dd>
<dt>Value type:</dt> <dt>Value type:</dt>
<dd>A single URI or TEXT value. The default value type is URI.</dd> <dd>A single URI or TEXT value. The default value type is URI.</dd>
<dt>Cardinality:</dt> <dt>Cardinality:</dt>
<dd>*</dd> <dd>*</dd>
<dt>Property parameters:</dt> <dt>Property parameters:</dt>
<dd>The SERVICE-TYPE parameter <bcp14>MUST</bcp14> be assigned to this property if the value type is TEXT, it <bcp14>MAY</bcp14> be assigned if the va lue type is URI. In either case, it <bcp14>MUST NOT</bcp14> be assigned more th an once.</dd> <dd>The SERVICE-TYPE parameter <bcp14>MUST</bcp14> be assigned to this property if the value type is TEXT, and it <bcp14>MAY</bcp14> be assigned if th e value type is URI. In either case, it <bcp14>MUST NOT</bcp14> be assigned mor e than once.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
Several vCard address book implementations currently use an experime ntal X-SOCIALPROFILE property to store social media profiles for contacts. This specification provides an IANA-registered property for the same purpose. In ad dition to the typical use of this property with URI values, it also allows setti ng usernames for social media services as free-text TEXT values, in which case t he service name <bcp14>MUST</bcp14> be provided as a parameter. Names <bcp14>MU ST</bcp14> be considered equal if they match case-insensitively. Several vCard address book implementations currently use an experime ntal X-SOCIALPROFILE property to store social media profiles for contacts. This specification provides an IANA-registered property for the same purpose. In ad dition to the typical use of this property with URI values, it also allows setti ng usernames for social media services as free-text TEXT values, in which case t he service name <bcp14>MUST</bcp14> be provided as a parameter. Names <bcp14>MU ST</bcp14> be considered equal if they match case-insensitively.
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<t>This property is defined by the following notation:</t> <t>This property is defined by the following notation:</t>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
socialpr = "SOCIALPROFILE" socialpr-param ":" socialpr = "SOCIALPROFILE" socialpr-param ":"
socialpr-value socialpr-value
skipping to change at line 463 skipping to change at line 571
</section> </section>
</section> </section>
<section anchor="new-parameters"> <section anchor="new-parameters">
<name>New Parameters</name> <name>New Parameters</name>
<section anchor="param-author"> <section anchor="param-author">
<name>AUTHOR</name> <name>AUTHOR</name>
<dl> <dl>
<dt>Parameter name:</dt> <dt>Parameter name:</dt>
<dd>AUTHOR</dd> <dd>AUTHOR</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This parameter identifies the author of the associated property va lue.</dd> <dd>Identifies the author of the associated property value.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>This parameter <bcp14>MAY</bcp14> be set on any property where co nveying authorship is desired. It identifies the author as a URI <xref target=" RFC3986"/>. Since every valid URI includes the COLON (U+003A) character, the pa rameter value <bcp14>MUST</bcp14> be quoted. Note that as an alternative or in addition to this parameter, the <tt>AUTHOR-NAME</tt> parameter allows naming an author as free-text value (see <xref target="param-author-name"/>).</t> <t>This parameter <bcp14>MAY</bcp14> be set on any property where co nveying authorship is desired. It identifies the author as a URI <xref target=" RFC3986"/>. Since every valid URI includes the COLON (U+003A) character, the pa rameter value <bcp14>MUST</bcp14> be quoted. Note that as an alternative or in addition to this parameter, the <tt>AUTHOR-NAME</tt> parameter allows naming an author as a free-text value (see <xref target="param-author-name"/>).</t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
author-param = "AUTHOR" "=" DQUOTE URI DQUOTE author-param = "AUTHOR" "=" DQUOTE URI DQUOTE
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
skipping to change at line 488 skipping to change at line 596
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="param-author-name"> <section anchor="param-author-name">
<name>AUTHOR-NAME</name> <name>AUTHOR-NAME</name>
<dl> <dl>
<dt>Parameter name:</dt> <dt>Parameter name:</dt>
<dd>AUTHOR-NAME</dd> <dd>AUTHOR-NAME</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This parameter names the author of the associated property value.< /dd> <dd>Names the author of the associated property value.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>This parameter <bcp14>MAY</bcp14> be set on any property where co <t>This parameter <bcp14>MAY</bcp14> be set on any property where co
nveying authorship is desired. It names the author as a free-text value. The p nveying authorship is desired. It names the author as a free-text value. The p
arameter value <bcp14>MUST NOT</bcp14> be empty. Implementations <bcp14>MUST</b arameter value <bcp14>MUST NOT</bcp14> be empty.
cp14> take care to quote the name part, if otherwise the part would not be a val
id <tt>param-value</tt> (see <xref target="RFC6350" section="3.3"/>). Note that <!--rfced] In the following, do implementations need to quote the name
as an alternative or in addition to this parameter, the <tt>AUTHOR</tt> paramet part in order for the param-value to be valid, as shown below?
er allows identifying an author by URI (see <xref target="param-author"/>).</t> Also, is "name part" referring to the parameter? Please let us
know how we may update this sentence for clarity.
Original:
Implementations MUST take care to quote the name part,
if otherwise the part would not be a valid param-value
(see Section 3.3 of [RFC6350]).
Perhaps:
Implementations MUST take care to quote the name part
of the parameter; otherwise, it will not be a valid
param-value (see Section 3.3 of [RFC6350]).
-->
Implementations <bcp14>MUST</bcp14> take care to quote the name part,
if otherwise the part would not be a valid <tt>param-value</tt> (see <xref targ
et="RFC6350" sectionFormat="of" section="3.3"/>). Note that as an alternative o
r in addition to this parameter, the <tt>AUTHOR</tt> parameter allows identifyin
g an author by URI (see <xref target="param-author"/>).</t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
author-name-param = "AUTHOR-NAME" "=" param-value ; not empty author-name-param = "AUTHOR-NAME" "=" param-value ; not empty
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
skipping to change at line 514 skipping to change at line 640
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="param-created"> <section anchor="param-created">
<name>CREATED</name> <name>CREATED</name>
<dl> <dl>
<dt>Parameter name:</dt> <dt>Parameter name:</dt>
<dd>CREATED</dd> <dd>CREATED</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This parameter defines the date and time when a property was creat ed in a vCard.</dd> <dd>Defines the date and time when a property was created in a vCard.< /dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>This parameter <bcp14>MAY</bcp14> be set on any property to defin e the point in time when the property was created. The value <bcp14>MUST</bcp14 > be a valid TIMESTAMP value as defined in <xref target="RFC6350" section="4.3.5 "/>. Generally, updating a property value <bcp14>SHOULD NOT</bcp14> change the creation timestamp.</t> <t>This parameter <bcp14>MAY</bcp14> be set on any property to defin e the point in time when the property was created. The value <bcp14>MUST</bcp14 > be a valid TIMESTAMP value as defined in <xref target="RFC6350" sectionFormat= "of" section="4.3.5"/>. Generally, updating a property value <bcp14>SHOULD NOT< /bcp14> change the creation timestamp.</t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
created-param = "CREATED" "=" param-value ; created-param = "CREATED" "=" param-value ;
; a valid TIMESTAMP of Section 4.3.5 of [RFC6350] ; a valid TIMESTAMP of Section 4.3.5 of RFC 6350
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
NOTE;CREATED=20221122T151823Z:This is some note. NOTE;CREATED=20221122T151823Z:This is some note.
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="param-derived"> <section anchor="param-derived">
<name>DERIVED</name> <name>DERIVED</name>
<dl> <dl>
<dt>Parameter name:</dt> <dt>Parameter name:</dt>
<dd>DERIVED</dd> <dd>DERIVED</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This parameter specifies that the value of the associated property is derived from some other property values in the same vCard.</dd> <dd>Specifies that the value of the associated property is derived fro m some other property values in the same vCard.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>This property parameter <bcp14>SHOULD</bcp14> be specified on an <t>This property parameter <bcp14>SHOULD</bcp14> be specified on a p
property if the property value is derived from some other properties in the same roperty if the property value is derived from some other properties in the same
vCard. When present with a value of <tt>true</tt>, clients <bcp14>MUST NOT</bc vCard. When present with a value of <tt>true</tt>, clients <bcp14>MUST NOT</bcp
p14> update the property.</t> 14> update the property.</t>
<t>For an example, an implementation may derive the value of the FN <t>As an example, an implementation may derive the value of the FN p
property from the name components of the N property. It indicates this fact by roperty from the name components of the N property. It indicates this fact by s
setting the DERIVED parameter on the FN property to <tt>true</tt>.</t> etting the DERIVED parameter on the FN property to <tt>true</tt>.</t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
derived-param = "DERIVED" "=" ("true" / "false") derived-param = "DERIVED" "=" ("true" / "false")
; Default is false ; Default is false
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
skipping to change at line 568 skipping to change at line 694
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="param-label"> <section anchor="param-label">
<name>LABEL</name> <name>LABEL</name>
<dl> <dl>
<dt>Parameter name:</dt> <dt>Parameter name:</dt>
<dd>LABEL</dd> <dd>LABEL</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This parameter is used with the ADR property. Its value contains a formatted text representation of that address, e.g. for delivery.</dd> <dd>Used with the ADR property. Its value contains a formatted text r epresentation of that address, e.g., for delivery.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t><xref target="RFC6350" section="6.3.1"/> defines the ADR property , noting that the property can also include a LABEL parameter to present a deliv ery address label for the address. But this parameter was not included in the I ANA Parameters Registry <xref target="RFC6350" section="10.3.2"/> and accordingl y is not a registered standard vCard element. This specification defines and re gisters the LABEL parameter for use with the ADR property as originally intended .</t> <t><xref target="RFC6350" sectionFormat="of" section="6.3.1"/> defin es the ADR property, noting that the property can also include a LABEL parameter to present a delivery address label for the address. But this parameter was no t included in the IANA "vCard Parameters" registry (<xref target="RFC6350" secti onFormat="of" section="10.3.2"/>) and, accordingly, is not a registered standard vCard element. This specification defines and registers the LABEL parameter fo r use with the ADR property as originally intended.</t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
label-param = "LABEL" "=" param-value label-param = "LABEL" "=" param-value
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<t>The LABEL parameter as illustrated the ADR property example in <x ref target="RFC6350" section="6.3.1"/>.</t> <t>The LABEL parameter as illustrated in the ADR property example in <xref target="RFC6350" sectionFormat="of" section="6.3.1"/>.</t>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
ADR;LABEL="Mr. John Q. Public, Esq.\nMail Drop: TNE QB\n123 ADR;LABEL="Mr. John Q. Public, Esq.\nMail Drop: TNE QB\n123
Main Street\nAny Town, CA 91921-1234\nU.S.A.": Main Street\nAny Town, CA 91921-1234\nU.S.A.":
;;123 Main Street;Any Town;CA;91921-1234;U.S.A. ;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="param-phonetic"> <section anchor="param-phonetic">
<name>PHONETIC</name> <name>PHONETIC</name>
<dl> <dl>
<dt>Parameter name:</dt> <dt>Parameter name:</dt>
<dd>PHONETIC</dd> <dd>PHONETIC</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This parameter defines how to pronounce the value of another prope rty in the same vCard.</dd> <dd>Defines how to pronounce the value of another property in the same vCard.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>This property parameter indicates that the value of its propert <t>This property parameter indicates that the value of its propert
y contains the phonetic representation of a same-named other property in the sam y contains the phonetic representation of another same-named property in the sam
e vCard. Exemplary uses are to define how pronounce a Japanese name, or for rom e vCard. Exemplary uses are defining how to pronounce Japanese names and romani
anization of Mandarin or Cantonese name and address components.</t> zing Mandarin or Cantonese names and address components.</t>
<t>The parameter value indicates the phonetic system and <bcp14>MU <t>The parameter value indicates the phonetic system and <bcp14>MU
ST</bcp14> be one of the values enumerated in the IANA <xref target="iana-vcard- ST</bcp14> be one of the values enumerated in the IANA <xref target="iana-vcard-
param-values">vCard Parameter Values</xref> registry. This specification define param-values">"vCard Parameter Values" registry</xref>. This specification defi
s the following values:</t> nes the following values:</t>
<ul>
<li><tt>ipa</tt>: denotes the <xref target="IPA">International P <!--[rfced] FYI: We listed the following terms in alphabetical order
honetic Alphabet</xref>.</li> to match how they are listed in Table 4 (Section 7.4) and the
<li><tt>piny</tt>: denotes the Standard Mandarin romanization sy "vCard Parameter Values" registry
stem "Hanyu Pinyin".</li> <https://www.iana.org/assignments/vcard-elements/>.
<li><tt>jyut</tt>: denotes the Cantonese romanization system "Jy
utping".</li> Original:
<li><tt>script</tt>: denotes the unknown phonetic system. The < ipa: denotes the International Phonetic Alphabet [IPA].
xref target="param-script">SCRIPT</xref> parameter <bcp14>MUST</bcp14> be set in piny: denotes the Standard Mandarin romanization system "Hanyu Pinyin".
addition to the PHONETIC parameter.</li> jyut: denotes the Cantonese romanization system "Jyutping".
</ul> script: denotes the unknown phonetic system. The SCRIPT (Section 4.8)
parameter MUST be set in addition to the PHONETIC parameter.
Current:
ipa: denotes the International Phonetic Alphabet [IPA].
jyut: denotes the Cantonese romanization system "Jyutping".
piny: denotes the Standard Mandarin romanization system "Hanyu Pinyin".
script: denotes the unknown phonetic system. The SCRIPT (Section 4.8)
parameter MUST be set in addition to the PHONETIC parameter.
-->
<dl>
<dt><tt>ipa</tt>:</dt><dd> denotes the <xref target="IPA">Intern
ational Phonetic Alphabet</xref>.</dd>
<dt><tt>jyut</tt>:</dt><dd> denotes the Cantonese romanization sy
stem "Jyutping".</dd>
<dt><tt>piny</tt>:</dt><dd> denotes the Standard Mandarin romani
zation system "Hanyu Pinyin".</dd>
<dt><tt>script</tt>:</dt><dd> denotes the unknown phonetic syste
m. The <xref target="param-script">SCRIPT</xref> parameter <bcp14>MUST</bcp14>
be set in addition to the PHONETIC parameter.</dd>
</dl>
<t>The value type of the property on which the PHONETIC parameter is set <bcp14>MUST</bcp14> be of the same type as its related property. If a co mponent value is set in the property on which the PHONETIC parameter is set, the n a component value also <bcp14>MUST</bcp14> be set at that same position in the related property. On the other hand, not every component value in the related property needs to have a phonetic representation.</t> <t>The value type of the property on which the PHONETIC parameter is set <bcp14>MUST</bcp14> be of the same type as its related property. If a co mponent value is set in the property on which the PHONETIC parameter is set, the n a component value also <bcp14>MUST</bcp14> be set at that same position in the related property. On the other hand, not every component value in the related property needs to have a phonetic representation.</t>
<t>The ALTID parameter (<xref target="RFC6350" section="5.4"/>) <b <t>The ALTID (<xref target="RFC6350" sectionFormat="of" section="5
cp14>MUST</bcp14> be set with equal values on both the related property and the .4"/>) parameter <bcp14>MUST</bcp14> be set with equal values on both the relate
property having the PHONETIC parameter set. If more than one same-named propert d property and the property having the PHONETIC parameter set.
y has both the PHONETIC parameter set and an equal ALTID parameter value, then a
t most one of these properties <bcp14>MAY</bcp14> not have the LANGUAGE paramete <!--[rfced] Should "MAY not" be updated as "MUST NOT" in the
r set and all others <bcp14>MUST</bcp14> have the LANGUAGE parameter set. The L following? Please review.
ANGUAGE parameters <bcp14>MUST NOT</bcp14> have equal values. The LANGUAGE para
meter value <bcp14>SHOULD NOT</bcp14> contain a script subtag in its Language-Ta Original:
g value and any such subtag <bcp14>MUST</bcp14> be ignored in favor of the <xref If more than one same-named property
target="param-script">SCRIPT</xref> parameter value.</t> has both the PHONETIC parameter set and an equal ALTID parameter
value, then at most one of these properties MAY not have the
LANGUAGE parameter set and all others MUST have the LANGUAGE
parameter set.
Perhaps:
If more than one same-named property
has both the PHONETIC parameter set and an equal ALTID parameter
value, then at most, one of these properties MUST NOT have the
LANGUAGE parameter set, and all others MUST have the LANGUAGE
parameter set.
-->
If more than one same-named property has both the PHONETIC parameter set and an
equal ALTID parameter value, then at most, one of these properties <bcp14>MAY</b
cp14> not have the LANGUAGE parameter set, and all others <bcp14>MUST</bcp14> ha
ve the LANGUAGE parameter set. The LANGUAGE parameters <bcp14>MUST NOT</bcp14>
have equal values. The LANGUAGE parameter value <bcp14>SHOULD NOT</bcp14> conta
in a script subtag in its Language-Tag value, and any such subtag <bcp14>MUST</b
cp14> be ignored in favor of the <xref target="param-script">SCRIPT</xref> param
eter value.</t>
<t>This specification defines the PHONETIC parameter for use with the ADR and N properties.</t> <t>This specification defines the PHONETIC parameter for use with the ADR and N properties.</t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
phonetic-param = "PHONETIC=" phonetic-value phonetic-param = "PHONETIC=" phonetic-value
phonetic-value = "ipa" / "piny" / "jyut" / "script" / iana-token / x-name phonetic-value = "ipa" / "piny" / "jyut" / "script" / iana-token / x-name
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
skipping to change at line 635 skipping to change at line 801
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="param-propid"> <section anchor="param-propid">
<name>PROP-ID</name> <name>PROP-ID</name>
<dl> <dl>
<dt>Parameter name:</dt> <dt>Parameter name:</dt>
<dd>PROP-ID</dd> <dd>PROP-ID</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This parameter identifies a property among all its siblings of the same property name.</dd> <dd>Identifies a property among all its siblings of the same property name.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t> <t>
This parameter uniquely identifies a property among all of its sib lings with the same name within a vCard. A valid PROP-ID value must be of 1 and a maximum of 255 octets in size, and it MUST only contain the ASCII alphanumeri c characters (<tt>A-Za-z0-9</tt>), hyphen (<tt>-</tt>), and underscore (<tt>_</t t>). The identifier only has the purpose to uniquely identify siblings, its val ue has no other meaning. If an application makes use of PROP-ID it <bcp14>SHOUL D</bcp14> assign a unique identifier to each sibling property of the same name w ithin their embedding component. The same identifier <bcp14>MAY</bcp14> be used for properties of a different name, and it <bcp14>MAY</bcp14> also be assigned to a same-named property that is not a sibling. This parameter uniquely identifies a property among all of its sib lings with the same name within a vCard. A valid PROP-ID value must be of 1 and a maximum of 255 octets in size, and it <bcp14>MUST</bcp14> only contain the AS CII alphanumeric characters (<tt>A-Za-z0-9</tt>), hyphen (<tt>-</tt>), and under score (<tt>_</tt>). The identifier's only purpose is to uniquely identify sibli ngs; its value has no other meaning. If an application makes use of PROP-ID, it <bcp14>SHOULD</bcp14> assign a unique identifier to each sibling property of th e same name within their embedding component. The same identifier <bcp14>MAY</b cp14> be used for properties of a different name, and it <bcp14>MAY</bcp14> also be assigned to a same-named property that is not a sibling.
</t> </t>
<t> <t>
Resolving duplicate identifier conflicts is specific to the applic ation. Similarly, handling properties where some but not all siblings have a PR OP-ID is assigned, is application-specific. Resolving duplicate identifier conflicts is specific to the applic ation. Similarly, handling properties where some but not all siblings have a PR OP-ID assigned is application-specific.
</t> </t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
prop-id-param = "PROP-ID" "=" 1*255(ALPHA / DIGIT / "-"/ "_") prop-id-param = "PROP-ID" "=" 1*255(ALPHA / DIGIT / "-"/ "_")
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
skipping to change at line 666 skipping to change at line 832
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="param-script"> <section anchor="param-script">
<name>SCRIPT</name> <name>SCRIPT</name>
<dl> <dl>
<dt>Parameter name:</dt> <dt>Parameter name:</dt>
<dd>SCRIPT</dd> <dd>SCRIPT</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This parameter defines the script in which a property value is wri tten in.</dd> <dd>Defines the script that a property value is written in.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>This parameter allows defining a script for a property value with out also defining a language as the LANGUAGE parameter would. The value <bcp14> MUST</bcp14> be a Script Subtag as defined in <xref target="RFC5646" section="2. 2.3"/>. This specification makes use of the SCRIPT parameter in combination wit h the <xref target="param-phonetic">PHONETIC</xref> parameter. </t> <t>This parameter allows defining a script for a property value with out also defining a language as the LANGUAGE parameter would. The value <bcp14> MUST</bcp14> be a script subtag as defined in <xref target="RFC5646" sectionForm at="of" section="2.2.3"/>. This specification makes use of the SCRIPT parameter in combination with the <xref target="param-phonetic">PHONETIC</xref> parameter . </t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
script-param = 4ALPHA script-param = 4ALPHA
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
skipping to change at line 691 skipping to change at line 857
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="param-service-type"> <section anchor="param-service-type">
<name>SERVICE-TYPE</name> <name>SERVICE-TYPE</name>
<dl> <dl>
<dt>Parameter name:</dt> <dt>Parameter name:</dt>
<dd>SERVICE-TYPE</dd> <dd>SERVICE-TYPE</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>To define the online service name associated with a messaging or s ocial media profile.</dd> <dd>Defines the online service name associated with a messaging or soc ial media profile.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>This parameter <bcp14>MAY</bcp14> be specified on a IMPP or SOCIA LPROFILE property to name the online service associated with that property value . Its value is case-sensitive, its letter cases <bcp14>MUST</bcp14> be preserve d.</t> <t>This parameter <bcp14>MAY</bcp14> be specified on an IMPP or a SO CIALPROFILE property to name the online service associated with that property va lue. Its value is case-sensitive; its letter cases <bcp14>MUST</bcp14> be prese rved.</t>
<t>Several vCard address book implementations currently use an exper imental X-SERVICE-TYPE parameter. This specification provides an IANA-registere d parameter for the same purpose.</t> <t>Several vCard address book implementations currently use an exper imental X-SERVICE-TYPE parameter. This specification provides an IANA-registere d parameter for the same purpose.</t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
service-type-param = "SERVICE-TYPE" "=" param-value service-type-param = "SERVICE-TYPE" "=" param-value
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
skipping to change at line 717 skipping to change at line 883
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="param-username"> <section anchor="param-username">
<name>USERNAME</name> <name>USERNAME</name>
<dl> <dl>
<dt>Parameter name:</dt> <dt>Parameter name:</dt>
<dd>USERNAME</dd> <dd>USERNAME</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>To define a username, such as the user of a messaging or social me dia service.</dd> <dd>Defines a username such as the user of a messaging or social media service.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>This parameter <bcp14>MAY</bcp14> be specified on a IMPP or SOCIA LPROFILE property to name the user with that property value. Its value is case- sensitive, its letter cases <bcp14>MUST</bcp14> be preserved. The IMPP or SOCIA LPROFILE value type <bcp14>MUST</bcp14> be URI.</t> <t>This parameter <bcp14>MAY</bcp14> be specified on an IMPP or a SO CIALPROFILE property to name the user with that property value. Its value is ca se-sensitive; its letter cases <bcp14>MUST</bcp14> be preserved. The IMPP or SO CIALPROFILE value type <bcp14>MUST</bcp14> be URI.</t>
</dd> </dd>
<dt>Format definition:</dt> <dt>Format definition:</dt>
<dd> <dd>
<sourcecode name="" type="abnf"><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
username-param = "USERNAME" "=" param-value username-param = "USERNAME" "=" param-value
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
skipping to change at line 745 skipping to change at line 911
</section> </section>
</section> </section>
<section anchor="new-values"> <section anchor="new-values">
<name>New Values</name> <name>New Values</name>
<section anchor="value-adr-type-billing"> <section anchor="value-adr-type-billing">
<name>Billing Address Type Value</name> <name>Billing Address Type Value</name>
<dl> <dl>
<dt>Value:</dt> <dt>Value:</dt>
<dd>billing</dd> <dd>billing</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This indicates to use this address for billing, e.g., to send invo ices to.</dd> <dd>Indicates using this address for billing, e.g., to send invoices t o.</dd>
<dt>Conformance:</dt> <dt>Conformance:</dt>
<dd> <dd>
<t>This value can be used with the "TYPE" parameter applied on the " ADR" property.</t> <t>This value can be used with the TYPE parameter applied on the ADR property.</t>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
ADR;TYPE=billing:;;123 Main Street;Any Town;CA;91921-1234;U.S.A. ADR;TYPE=billing:;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="value-adr-type-delivery"> <section anchor="value-adr-type-delivery">
<name>Delivery Address Type Value</name> <name>Delivery Address Type Value</name>
<dl> <dl>
<dt>Value:</dt> <dt>Value:</dt>
<dd>delivery</dd> <dd>delivery</dd>
<dt>Purpose:</dt> <dt>Purpose:</dt>
<dd>This indicates to use this address for delivery, e.g., to send pac kages to.</dd> <dd>Indicates using this address for delivery, e.g., to send packages to.</dd>
<dt>Conformance:</dt> <dt>Conformance:</dt>
<dd> <dd>
<t>This value can be used with the "TYPE" parameter applied on the " ADR" property.</t> <t>This value can be used with the TYPE parameter applied on the ADR property.</t>
</dd> </dd>
<dt>Example(s):</dt> <dt>Example(s):</dt>
<dd> <dd>
<sourcecode name=""><![CDATA[ <sourcecode name=""><![CDATA[
ADR;TYPE=delivery:;;123 Main Street;Any Town;CA;91921-1234;U.S.A. ADR;TYPE=delivery:;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
]]></sourcecode> ]]></sourcecode>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This specification extends the vCard Format Specification. The same se curity considerations as outlined in <xref target="RFC6350" section="9"/> apply. </t> <t>This specification extends "vCard Format Specification" <xref target="R FC6350"/>. The same security considerations as outlined in <xref target="RFC635 0" sectionFormat="of" section="9"/> apply.</t>
</section> </section>
<section anchor="IANA"> <section anchor="IANA">
<!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section> <section>
<name>Changes to the "vCard Properties" registry</name> <name>Changes to the vCard Properties Registry</name>
<section> <section>
<name>New property definitions</name> <name>New vCard Property Definitions</name>
<t>IANA is requested to add the following entries to the "vCard Proper <t>IANA has added the following entries to the "vCard Properties" regi
ties" registry, defined in Section 10.3.1. of <xref target="RFC6350"/>.</t> stry, as defined in <xref target="RFC6350" sectionFormat="of" section="10.3.1"/>
.</t>
<table anchor="new_properties"> <table anchor="new_properties">
<name>New vCard Properties</name> <name>New vCard Properties</name>
<thead> <thead>
<tr> <tr>
<th align="left">Namespace</th> <th align="left">Namespace</th>
<th align="left">Property</th> <th align="left">Property</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td/> <td/>
<td align="left">CREATED</td> <td align="left">CREATED</td>
<td align="left">This document, <xref target="prop-created"/></t d> <td align="left">RFC 9554, <xref target="prop-created"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">GRAMGENDER</td> <td align="left">GRAMGENDER</td>
<td align="left">This document, <xref target="prop-gramgender"/> </td> <td align="left">RFC 9554, <xref target="prop-gramgender"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">LANGUAGE</td> <td align="left">LANGUAGE</td>
<td align="left">This document, <xref target="prop-language"/></ td> <td align="left">RFC 9554, <xref target="prop-language"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">PRONOUNS</td> <td align="left">PRONOUNS</td>
<td align="left">This document, <xref target="prop-pronouns"/></ td> <td align="left">RFC 9554, <xref target="prop-pronouns"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">SOCIALPROFILE</td> <td align="left">SOCIALPROFILE</td>
<td align="left">This document, <xref target="prop-socialprofile "/></td> <td align="left">RFC 9554, <xref target="prop-socialprofile"/></ td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section> <section>
<name>Updated vCard properties</name> <name>Updated vCard Properties </name>
<t>IANA is requested to add <xref target="prop-adr"/> of this document <t>
as reference for the ADR property.</t> IANA has added <xref target="prop-adr"/> of this document as a reference for
<t>IANA is requested to add <xref target="prop-n"/> of this document a the ADR
s reference for the N property.</t> property and <xref target="prop-n"/> of this document as a reference for the
</section> N
property in the "vCard Properties" registry.
</t>
</section> </section>
</section>
<section> <section>
<name>Changes to the "vCard Parameters" registry</name> <name>Changes to the vCard Parameters Registry</name>
<t>IANA is requested to add the following entries to the "vCard Paramete <t>IANA has added the following entries to the "vCard Parameters" regist
rs" registry, defined in Section 10.3.2. of <xref target="RFC6350"/>.</t> ry, as defined in <xref target="RFC6350" sectionFormat="of" section="10.3.2"/>.<
/t>
<table anchor="new_parameters"> <table anchor="new_parameters">
<name>New vCard Parameters</name> <name>New vCard Parameters</name>
<thead> <thead>
<tr> <tr>
<th align="left">Namespace</th> <th align="left">Namespace</th>
<th align="left">Parameter</th> <th align="left">Parameter</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td/> <td/>
<td align="left">AUTHOR</td> <td align="left">AUTHOR</td>
<td align="left">This document, <xref target="param-author"/></td> <td align="left">RFC 9554, <xref target="param-author"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">AUTHOR-NAME</td> <td align="left">AUTHOR-NAME</td>
<td align="left">This document, <xref target="param-author-name"/> </td> <td align="left">RFC 9554, <xref target="param-author-name"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">CREATED</td> <td align="left">CREATED</td>
<td align="left">This document, <xref target="param-created"/></td > <td align="left">RFC 9554, <xref target="param-created"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">DERIVED</td> <td align="left">DERIVED</td>
<td align="left">This document, <xref target="param-derived"/></td > <td align="left">RFC 9554, <xref target="param-derived"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">LABEL</td> <td align="left">LABEL</td>
<td align="left"> <td align="left">
<xref target="RFC6350" section="6.3.1"/> and <xref target="RFC6350" sectionFormat="comma" section="6.3.1"/>
this document, <xref target="param-label"/> and
RFC 9554, <xref target="param-label"/>
</td> </td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">PHONETIC</td> <td align="left">PHONETIC</td>
<td align="left">This document, <xref target="param-phonetic"/></t d> <td align="left">RFC 9554, <xref target="param-phonetic"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">PROP-ID</td> <td align="left">PROP-ID</td>
<td align="left">This document, <xref target="param-propid"/></td> <td align="left">RFC 9554, <xref target="param-propid"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">SCRIPT</td> <td align="left">SCRIPT</td>
<td align="left">This document, <xref target="param-script"/></td> <td align="left">RFC 9554, <xref target="param-script"/></td>
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">SERVICE-TYPE</td> <td align="left">SERVICE-TYPE</td>
<td align="left">This document, <xref target="param-service-type"/ ></td> <td align="left">RFC 9554, <xref target="param-service-type"/></td >
</tr> </tr>
<tr> <tr>
<td/> <td/>
<td align="left">USERNAME</td> <td align="left">USERNAME</td>
<td align="left">This document, <xref target="param-username"/></t d> <td align="left">RFC 9554, <xref target="param-username"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section> <section>
<name>Changes to the "vCard Property Values" registry</name> <name>Changes to the vCard Property Values Registry</name>
<t>IANA is requested to add the following entries to the "vCard Property <t>IANA has added the following entries to the "vCard Property Values" r
Values" registry, defined in Section 10.3.4. of <xref target="RFC6350"/>.</t> egistry, as defined in <xref target="RFC6350" sectionFormat="of" section="10.3.4
"/>.</t>
<table anchor="new_values"> <table anchor="new_values">
<name>New vCard Property Values</name> <name>New vCard Property Values</name>
<thead> <thead>
<tr> <tr>
<th align="left">Property</th> <th align="left">Property</th>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">GRAMGENDER</td> <td align="left">GRAMGENDER</td>
<td align="left">animate</td> <td align="left">animate</td>
<td align="left">This document, <xref target="prop-gramgender"/></ td> <td align="left">RFC 9554, <xref target="prop-gramgender"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">GRAMGENDER</td> <td align="left">GRAMGENDER</td>
<td align="left">common</td> <td align="left">common</td>
<td align="left">This document, <xref target="prop-gramgender"/></ td> <td align="left">RFC 9554, <xref target="prop-gramgender"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">GRAMGENDER</td> <td align="left">GRAMGENDER</td>
<td align="left">feminine</td> <td align="left">feminine</td>
<td align="left">This document, <xref target="prop-gramgender"/></ td> <td align="left">RFC 9554, <xref target="prop-gramgender"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">GRAMGENDER</td> <td align="left">GRAMGENDER</td>
<td align="left">inanimate</td> <td align="left">inanimate</td>
<td align="left">This document, <xref target="prop-gramgender"/></ td> <td align="left">RFC 9554, <xref target="prop-gramgender"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">GRAMGENDER</td> <td align="left">GRAMGENDER</td>
<td align="left">masculine</td> <td align="left">masculine</td>
<td align="left">This document, <xref target="prop-gramgender"/></ td> <td align="left">RFC 9554, <xref target="prop-gramgender"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">GRAMGENDER</td> <td align="left">GRAMGENDER</td>
<td align="left">neuter</td> <td align="left">neuter</td>
<td align="left">This document, <xref target="prop-gramgender"/></ td> <td align="left">RFC 9554, <xref target="prop-gramgender"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="iana-vcard-param-values"> <section anchor="iana-vcard-param-values">
<name>Changes to the "vCard Parameter Values" registry</name> <name>Changes to the vCard Parameter Values Registry</name>
<t>IANA is requested to add the following entries to the "vCard Paramete <t>IANA has added the following entries to the "vCard Parameter Values"
r Values" registry, defined in Section 10.3.4. of <xref target="RFC6350"/>.</t> registry, as defined in <xref target="RFC6350" sectionFormat="of" section="10.3.
4"/>.</t>
<table anchor="new_param_values"> <table anchor="new_param_values">
<name>New vCard Property Values</name> <name>New vCard Property and Parameter Values</name>
<thead> <thead>
<tr> <tr>
<th align="left">Property</th> <th align="left">Property</th>
<th align="left">Parameter</th> <th align="left">Parameter</th>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">ADR</td> <td align="left">ADR</td>
<td align="left">TYPE</td> <td align="left">TYPE</td>
<td align="left">billing</td> <td align="left">billing</td>
<td align="left">This document, <xref target="value-adr-type-billi <td align="left">RFC 9554, <xref target="value-adr-type-billing"/>
ng"/></td> </td>
</tr>
<tr>
<td align="left">ADR</td>
<td align="left">TYPE</td>
<td align="left">delivery</td>
<td align="left">This document, <xref target="value-adr-type-deliv
ery"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">ADR</td> <td align="left">ADR</td>
<td align="left">TYPE</td> <td align="left">TYPE</td>
<td align="left">delivery</td> <td align="left">delivery</td>
<td align="left">This document, <xref target="value-adr-type-deliv ery"/></td> <td align="left">RFC 9554, <xref target="value-adr-type-delivery"/ ></td>
</tr> </tr>
<tr> <tr>
<td align="left">ADR, N</td> <td align="left">ADR, N</td>
<td align="left">PHONETIC</td> <td align="left">PHONETIC</td>
<td align="left">ipa</td> <td align="left">ipa</td>
<td align="left">This document, <xref target="param-phonetic"/></t d> <td align="left">RFC 9554, <xref target="param-phonetic"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">ADR, N</td> <td align="left">ADR, N</td>
<td align="left">PHONETIC</td> <td align="left">PHONETIC</td>
<td align="left">jyut</td> <td align="left">jyut</td>
<td align="left">This document, <xref target="param-phonetic"/></t d> <td align="left">RFC 9554, <xref target="param-phonetic"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">ADR, N</td> <td align="left">ADR, N</td>
<td align="left">PHONETIC</td> <td align="left">PHONETIC</td>
<td align="left">piny</td> <td align="left">piny</td>
<td align="left">This document, <xref target="param-phonetic"/></t d> <td align="left">RFC 9554, <xref target="param-phonetic"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">ADR, N</td> <td align="left">ADR, N</td>
<td align="left">PHONETIC</td> <td align="left">PHONETIC</td>
<td align="left">script</td> <td align="left">script</td>
<td align="left">This document, <xref target="param-phonetic"/></t d> <td align="left">RFC 9554, <xref target="param-phonetic"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section>
<name>Acknowledgements</name>
<t>The definition and examples of the <xref target="param-phonetic">PHONET
IC</xref> and <xref target="param-script">SCRIPT</xref> parameters are based on
the initial version of <xref target="I-D.calconnect-vobject-i18n"/>.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.calconnect-vobject" to="CALCONNECT-VOBJECT"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2 119.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2 119.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3 986.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3 986.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 234.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 234.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 646.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 646.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 350.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 350.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 174.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 174.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ca
lext-jscontact.xml"/> <!-- [I-D.ietf-calext-jscontact] in AUTH48 state; companion document RFC 9553 --
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ca >
lext-jscontact-vcard.xml"/> <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-jscontact-vcard] in AUTH48 state; companion document RFC 95
55 -->
<reference anchor="RFC9555" target="https://www.rfc-editor.org/info/rfc9555">
<front>
<title>JSContact: Converting from and to vCard</title>
<author initials="M." surname="Loffredo" fullname="Mario Loffredo">
<organization>IIT-CNR/Registro.it</organization>
</author>
<author initials="R." surname="Stepanek" fullname="Robert Stepanek">
<organization>Fastmail</organization>
</author>
<date month="March" year="2024"/>
</front>
<seriesInfo name="RFC" value="9555"/>
<seriesInfo name="DOI" value="10.17487/RFC9555"/>
</reference>
</references> </references>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-calconnec
t-vobject-i18n.xml"/> <!--[I-D.calconnect-vobject-i18n] IESG state Expired. Entered the long way to ge
t the correct initials-->
<reference anchor="I-D.calconnect-vobject" 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>
<reference anchor="CLDRPersonName" target="https://www.unicode.org/reports /tr35/tr35-personNames.html"> <reference anchor="CLDRPersonName" target="https://www.unicode.org/reports /tr35/tr35-personNames.html">
<front> <front>
<title>Technical Standard #35: Unicode Locale Data Markup Language (LD ML) Part 8: Person Names, Version 43.1</title> <title>Unicode Locale Data Markup Language (LDML) Part 8: Person Names </title>
<author fullname="M. Davis"> <author fullname="M. Davis">
<organization/> <organization/>
</author> </author>
<author fullname="P. Edberg"> <author fullname="P. Edberg">
<organization/> <organization/>
</author> </author>
<author fullname="R. Gillam"> <author fullname="R. Gillam">
<organization/> <organization/>
</author> </author>
<author fullname="A. Kolisnychenko"> <author fullname="A. Kolisnychenko">
<organization/> <organization/>
</author> </author>
<author fullname="M. McKenna"> <author fullname="M. McKenna">
<organization/> <organization/>
</author> </author>
<author fullname="others"> <author>
<organization/> <organization>other CLDR committee members</organization>
</author> </author>
<date year="2023" month="July"/> <date year="2023" month="July"/>
</front> </front>
<seriesInfo name="Unicode Technical Standard" value="#35"/>
<seriesInfo name="Version" value="44.1"/>
</reference> </reference>
<reference anchor="IPA" target="https://www.internationalphoneticalphabe t.org/"> <reference anchor="IPA" target="https://www.internationalphoneticalphabe t.org/">
<front> <front>
<title>International Phonetic Alphabet</title> <title>International Phonetic Alphabet</title>
<author/> <author><organization>IPA</organization></author>
</front> </front>
</reference> </reference>
</references> </references>
<section anchor="Acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The definition and examples of the <xref target="param-phonetic">PHONET
IC</xref> and <xref target="param-script">SCRIPT</xref> parameters are based on
the early draft version of <xref target="I-D.calconnect-vobject"/>.</t>
</section>
<!-- [rfced] FYI: We have added an expansion for the following
abbreviation per Section 3.6 of RFC 7322 ("RFC Style
Guide"). Please review this as well as each expansion in the
document to ensure correctness.
Common Locale Data Repository (CLDR) (per RFC 7529)
-->
<!-- [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.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 126 change blocks. 
323 lines changed or deleted 571 lines changed or added

This html diff was produced by rfcdiff 1.48.