rfc9554.original   rfc9554.txt 
Calendaring Extensions R. Stepanek Internet Engineering Task Force (IETF) R. Stepanek
Internet-Draft Fastmail Request for Comments: 9554 Fastmail
Updates: 6350 (if approved) M. Loffredo Updates: 6350 M. Loffredo
Intended status: Standards Track IIT-CNR Category: Standards Track IIT-CNR
Expires: 3 March 2024 31 August 2023 ISSN: 2070-1721 March 2024
vCard Format Extension for JSContact vCard Format Extension for JSContact
draft-ietf-calext-vcard-jscontact-extensions-10
Abstract Abstract
This document defines a set of new properties for vCard and extends This document defines a set of new properties for vCard and extends
the use of existing ones. Their primary purpose is to align the same the use of existing ones. Their primary purpose is to align the same
set of features between the JSContact and vCard formats, but the new set of features between the JSContact and vCard formats, but the new
definitions also aim to be useful within just the vCard format. This definitions also aim to be useful within just the vCard format. This
document updates RFC 6350 (vCard). document updates RFC 6350 ("vCard Format Specification").
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 3 March 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9554.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions
1.2. ABNF Notations . . . . . . . . . . . . . . . . . . . . . 3 1.2. ABNF Notations
2. Updated Properties . . . . . . . . . . . . . . . . . . . . . 3 2. Updated Properties
2.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. ADR
2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. N
3. New Properties . . . . . . . . . . . . . . . . . . . . . . . 6 3. New Properties
3.1. CREATED . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. CREATED
3.2. GRAMGENDER . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. GRAMGENDER
3.3. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. LANGUAGE
3.4. PRONOUNS . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. PRONOUNS
3.5. SOCIALPROFILE . . . . . . . . . . . . . . . . . . . . . . 10 3.5. SOCIALPROFILE
4. New Parameters . . . . . . . . . . . . . . . . . . . . . . . 11 4. New Parameters
4.1. AUTHOR . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. AUTHOR
4.2. AUTHOR-NAME . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. AUTHOR-NAME
4.3. CREATED . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. CREATED
4.4. DERIVED . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. DERIVED
4.5. LABEL . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. LABEL
4.6. PHONETIC . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. PHONETIC
4.7. PROP-ID . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.7. PROP-ID
4.8. SCRIPT . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.8. SCRIPT
4.9. SERVICE-TYPE . . . . . . . . . . . . . . . . . . . . . . 16 4.9. SERVICE-TYPE
4.10. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 16 4.10. USERNAME
5. New Values . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. New Values
5.1. Billing Address Type Value . . . . . . . . . . . . . . . 17 5.1. Billing Address Type Value
5.2. Delivery Address Type Value . . . . . . . . . . . . . . . 17 5.2. Delivery Address Type Value
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations
7.1. Changes to the "vCard Properties" registry . . . . . . . 17 7.1. Changes to the vCard Properties Registry
7.1.1. New property definitions . . . . . . . . . . . . . . 17 7.1.1. New vCard Property Definitions
7.1.2. Updated vCard properties . . . . . . . . . . . . . . 18 7.1.2. Updated vCard Properties
7.2. Changes to the "vCard Parameters" registry . . . . . . . 18 7.2. Changes to the vCard Parameters Registry
7.3. Changes to the "vCard Property Values" registry . . . . . 19 7.3. Changes to the vCard Property Values Registry
7.4. Changes to the "vCard Parameter Values" registry . . . . 20 7.4. Changes to the vCard Parameter Values Registry
8. References
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Informative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 Acknowledgements
10. Informative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The JSContact [I-D.ietf-calext-jscontact] format aims to be an The JSContact [RFC9553] format aims to be an alternative to the vCard
alternative to the vCard [RFC6350] format for representation of [RFC6350] format for representation of contact and address book data.
contact and address book data. As such, it introduces new semantics As such, it introduces new semantics that are not covered in the
that are not covered in the current definition of vCard and its current definition of vCard and its various extensions. Converting
various extensions. Converting contact data between the two formats contact data between the two formats is defined in [RFC9555] with the
is defined in [I-D.ietf-calext-jscontact-vcard] with the goal of not goal of not losing any semantics during conversion. To achieve this,
losing any semantics during conversion. To do so, this document this document defines a new set of properties for vCard and extends
defines a new set of properties for vCard and extends existing existing definitions.
definitions.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. ABNF Notations 1.2. ABNF Notations
The ABNF definitions in this document use the notations of [RFC5234]. The ABNF definitions in this document use the notations of [RFC5234].
ABNF rules not defined in this document either are defined in ABNF rules not defined in this document are defined in either
[RFC5234] (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and [RFC5234] (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and
DIGIT) or [RFC6350]. DIGIT) or [RFC6350].
2. Updated Properties 2. Updated Properties
2.1. ADR 2.1. ADR
This specification modifies the definition of the "ADR" property. It This specification modifies the definition of the ADR property. It
extends its structured value with additional address components to extends its structured value with additional address components to
better support the variety of international addresses. It separates better support the variety of international addresses. It separates
the address parts that currently typically are combined in street the address parts, which currently are typically combined in street
address component values into distinct components. address component values, into distinct components.
Implementations SHOULD write a combined value of these components in Implementations SHOULD write a combined value of these components in
the street address component for backwards compatibility, but SHOULD the street address component for backwards compatibility, but they
ignore the street component during read if the ADR property value SHOULD ignore the street component during reads if the ADR property
contains any of the new components. value contains any of the new components.
The following change is made to the first paragraph in the "Special The following change is made to the first paragraph under "Special
Notes" section, originally specified in Section 6.3.1 of [RFC6350]. notes", as originally specified in Section 6.3.1 of [RFC6350]. The
All remaining paragraphs of that section in the original remaining paragraphs of that section in the original specification
specification still apply. still apply.
Special notes: The structured type value consists of a sequence of Special notes: The structured type value consists of a sequence of
address components. The component values MUST be specified in address components. The component values MUST be specified in their
their corresponding position. The structured type value corresponding position. The structured type value corresponds, in
corresponds, in sequence, to sequence, to the
the post office box;
the extended address (e.g., apartment or suite number);
the street address;
the locality (e.g., city);
the region (e.g., state or province);
the postal code;
the country name (full name in the language specified in
Section 5.1 of [RFC6350]);
the room or suite number or identifier
the apartment number, extension designation or box number.
the building floor or level;
the street number;
the street name;
the building, tower, condominium;
the block name or number;
the subdistrict;
the district;
the landmark or another publicly known prominent feature that can
substitute the street name and number, e.g., "White House"", "Taj
Mahal"";
the cardinal direction or quadrant, e.g., "North"
The following change is made to the definition of "ADR-value" in the post office box;
"ABNF" section, originally specified in Section 6.3.1 of [RFC6350]. extended address (e.g., apartment or suite number);
street address;
locality (e.g., city);
region (e.g., state or province);
postal code;
country name (full name in the language specified in Section 5.1
of [RFC6350]);
room, suite number, or identifier;
apartment number, extension designation, or box number;
building floor or level;
street number;
street name;
building, tower, or condominium;
block name or number;
subdistrict;
district;
landmark or another publicly known prominent feature that can
substitute the street name and number (e.g., "White House" and
"Taj Mahal"); and
the cardinal direction or quadrant (e.g., "north").
The following change is made to the definition of "ADR-value" under
"ABNF", as originally specified in Section 6.3.1 of [RFC6350].
ABNF ABNF
ADR-value = ADR-component-pobox ";" ADR-component-ext ";"
ADR-component-street ";" ADR-component-locality ";"
ADR-component-region ";" ADR-component-code ";"
ADR-component-country ";"
; above components are defined in RFC 6350, section 6.3.1
ADR-component-room ";" ADR-component-apartment ";"
ADR-component-floor ";"
ADR-component-streetnumber ";" ADR-component-streetname ";"
ADR-component-building ";" ADR-component-block ";"
ADR-component-subdistrict ";" ADR-component-district ";"
ADR-component-landmark ";" ADR-component-direction
ADR-component-pobox = list-component
ADR-component-ext = list-component
ADR-component-street = list-component
ADR-component-locality = list-component
ADR-component-region = list-component
ADR-component-code = list-component
ADR-component-country = list-component
ADR-component-room = list-component
ADR-component-apartment = list-component
ADR-component-floor = list-component
ADR-component-streetnumber = list-component
ADR-component-streetname = list-component
ADR-component-building = list-component
ADR-component-block = list-component
ADR-component-subdistrict = list-component
ADR-component-district = list-component
ADR-component-landmark = list-component
ADR-component-direction = list-component
The following change is made to the "Example" section, originally ADR-value = ADR-component-pobox ";" ADR-component-ext ";"
specified in Section 6.2.2 of [RFC6350]. ADR-component-street ";" ADR-component-locality ";"
ADR-component-region ";" ADR-component-code ";"
ADR-component-country ";"
; above components are defined in RFC 6350, Section 6.3.1
ADR-component-room ";" ADR-component-apartment ";"
ADR-component-floor ";"
ADR-component-streetnumber ";" ADR-component-streetname ";"
ADR-component-building ";" ADR-component-block ";"
ADR-component-subdistrict ";" ADR-component-district ";"
ADR-component-landmark ";" ADR-component-direction
ADR-component-pobox = list-component
ADR-component-ext = list-component
ADR-component-street = list-component
ADR-component-locality = list-component
ADR-component-region = list-component
ADR-component-code = list-component
ADR-component-country = list-component
ADR-component-room = list-component
ADR-component-apartment = list-component
ADR-component-floor = list-component
ADR-component-streetnumber = list-component
ADR-component-streetname = list-component
ADR-component-building = list-component
ADR-component-block = list-component
ADR-component-subdistrict = list-component
ADR-component-district = list-component
ADR-component-landmark = list-component
ADR-component-direction = list-component
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 Example: In this example, the post office box and the extended
address components are absent. The street number and name are address components are absent. The street number and name are both
added both as separate components, as well as combined in the added as separate components and are combined in the street component
street component for backwards-compatibility. for backwards compatibility.
ADR;GEO="geo:12.3457,78.910":
;;123 Main Street;Any Town;CA;91921-1234;U.S.A.;;123;Main Street;;;;;;; ADR;GEO="geo:12.3457,78.910":
;;123 Main Street;Any Town;CA;91921-1234;U.S.A.;;123;Main Street;;;;;;;
2.2. N 2.2. N
This specification modifies the definition of the "N" property. It This specification modifies the definition of the N property. It
extends its structured value with additional name components to extends its structured value with additional name components to
better support international names and generation markers. Doing so, better support international names and generation markers. In doing
this also facilitates formatting N property values using the Unicode so, this also facilitates formatting N property values using the
CLDR Person Name [CLDRPersonName] formatting standard. Unicode Common Locale Data Repository (CLDR) Person Name
[CLDRPersonName] formatting standard.
One new component is for secondary surnames, as in some cultures, One new component is for secondary surnames, because in some
such secondary surname kinds are used to indicate the paternal and cultures, such secondary surname kinds are used to indicate the
maternal family names or generational names indicating father, paternal and maternal family names or generational names indicating
grandfather. Another new component indicates a generation ("II", father or grandfather. Another new component indicates a generation
"XVI") or parental relation ("Jr.", "Sr."). ("II", "XVI") or parental relation ("Jr.", "Sr.").
Currently, implementations typically place secondary surnames in the Currently, implementations typically place secondary surnames in the
family name components, and generational markers in the honorific family name component and generational markers in the honorific
suffixes component. For backwards compatibility, implementations suffixes component. For backwards compatibility, implementations
SHOULD add such values to both the newly defined components and their SHOULD add such values to both the newly defined components and their
backwards-compatible counterpart. Reading N property values, backwards-compatible counterpart. Reading N property values,
implementations SHOULD ignore any value in the backward-compatible implementations SHOULD ignore any value in the backwards-compatible
component if an equal value is set in the according new component. component if an equal value is set in the new component accordingly.
For example, a "Jr." that occurs in both honorific suffixes and For example, a "Jr." that occurs in both honorific suffixes and
generation should only be handled as a generational marker. generation should only be handled as a generational marker.
The following change is made to the first paragraph in the "Special The following change is made to the first paragraph under "Special
Notes" section, originally specified in Section 6.2.2 of [RFC6350]. note", as originally specified in Section 6.2.2 of [RFC6350]. The
All remaining text of this and the following paragraphs of that remaining paragraphs of that section in the original specification
section in the original specification still apply. still apply.
Special notes: The structured property value corresponds, in Special notes: The structured property value corresponds, in
sequence, to the sequence, to the
family names (also known as surnames),
given names,
additional names,
honorific prefixes,
honorific suffixes,
secondary surname,
and generation.
The following change is made to the "ABNF" section, originally family names (also known as surnames);
specified in Section 6.2.2 of [RFC6350]. given names;
additional names;
honorific prefixes;
honorific suffixes;
secondary surname; and
generation.
The following change is made under "ABNF", as originally specified in
Section 6.2.2 of [RFC6350].
ABNF ABNF
N-param = "VALUE=text" / sort-as-param / language-param
/ altid-param / any-param
N-value = list-component 6(";" list-component)
The following change is made to the "Example" section, originally N-param = "VALUE=text" / sort-as-param / language-param
/ altid-param / any-param
N-value = list-component 6(";" list-component)
The following change is made under "Examples", as originally
specified in Section 6.2.2 of [RFC6350]. specified in Section 6.2.2 of [RFC6350].
Example Examples
N:Public;John;Quinlan;Mr.;Esq.
N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr. N:Public;John;Quinlan;Mr.;Esq.
N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr.
No change is required for the definition of the SORT-AS parameter, No change is required for the definition of the SORT-AS parameter,
but the new components also apply for use with this parameter. but the new components also apply for use with this parameter.
3. New Properties 3. New Properties
3.1. CREATED 3.1. CREATED
Property name: CREATED Property name: CREATED
Purpose: This property defines the date and time when the vCard was Purpose: Defines the date and time when the vCard was created.
created
Value type: A single timestamp value. Value type: A single timestamp value.
Cardinality: *1 Cardinality: *1
Property parameters: VALUE Property parameters: VALUE
Description: This is the time stamp when the vCard was created. Description: This is the timestamp when the vCard was created.
Copying the vCard across systems does not count as a new creation, Copying the vCard across systems does not count as a new creation
nor does a new revision. Instead, the time stamp value typically nor a new revision. Instead, the timestamp value typically stays
stays unchanged for the existence of the vCard. unchanged for the existence of the vCard.
Format definition: This property is defined by the following Format definition: This property is defined by the following
notation: notation:
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)
; ;
) )
Example(s): Example(s):
CREATED:20220705T093412Z CREATED:20220705T093412Z
CREATED;VALUE=TIMESTAMP:20211022T140000-05 CREATED;VALUE=TIMESTAMP:20211022T140000-05
3.2. GRAMGENDER 3.2. GRAMGENDER
Property name: GRAMGENDER Property name: GRAMGENDER
Purpose: This property defines which grammatical gender to use in Purpose: Defines which grammatical gender to use in salutations and
salutations and other grammatical constructs. other grammatical constructs.
Value type: A single text value, restricted to an enumerated list of Value type: A single text value that is restricted to an enumerated
allowed values. list of allowed values.
Cardinality: * Cardinality: *
Property parameters: LANG Property parameters: LANG, ALTID
Description: This property defines the grammatical gender that the Description: This property defines the grammatical gender that the
contact prefers to be addressed by or referred at in written or contact prefers to be addressed by or referred to as in written or
spoken form. For example, the German language distinguishes by spoken form. For example, the German language distinguishes by
grammatical gender in salutations such as "Sehr geehrte" grammatical gender in salutations such as "Sehr geehrte"
(feminine) and "Sehr geehrter" (masculine). Multiple occurrences (feminine) and "Sehr geehrter" (masculine). Multiple occurrences
of this property MUST be distinguished by the LANG parameter. of this property MUST be distinguished by the LANG parameter.
Format definition: This property is defined by the following Format definition: This property is defined by the following
notation: notation:
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" /
skipping to change at page 9, line 9 skipping to change at line 383
iana-token / iana-token /
x-name x-name
Example(s): Example(s):
GRAMGENDER:neuter GRAMGENDER:neuter
3.3. LANGUAGE 3.3. LANGUAGE
Property name: LANGUAGE Property name: LANGUAGE
Purpose: This property defines the default language that human- Purpose: Defines the default language that human-readable text
readable text values in this vCard should be assumed written in. values in this vCard are assumed to be written in.
Value type: A single Language-Tag value as defined in Section 4 of Value type: A single Language-Tag value as defined in Section 4 of
[RFC6350]. [RFC6350].
Cardinality: *1 Cardinality: *1
Property parameters: The LANGUAGE parameter MUST NOT be assigned to Property parameters: The LANGUAGE parameter MUST NOT be assigned to
this property. this property.
Description: This property defines the language in which property Description: This property defines the language that property values
values of type TEXT shall be assumed to be written for this vCard. of type TEXT are assumed to be written in for this vCard. If a
If a vCard property includes the LANGUAGE parameter, then the vCard property includes the LANGUAGE parameter, then the parameter
parameter value has higher precedence than the LANGUAGE property value has higher precedence than the LANGUAGE property value.
value.
Format definition: This property is defined by the following Format definition: This property is defined by the following
notation: notation:
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.
Example(s): Example(s):
LANGUAGE:de-AT LANGUAGE:de-AT
3.4. PRONOUNS 3.4. PRONOUNS
Property name: PRONOUNS Property name: PRONOUNS
Purpose: This property defines the pronouns that shall be used to Purpose: Defines the pronouns that shall be used to refer to the
refer to the entity represented by this vCard. entity represented by this vCard.
Value type: A single text value. Value type: A single text value.
Cardinality: * Cardinality: *
Property parameters: LANG, PREF, TYPE Property parameters: LANG, PREF, TYPE, ALTID
Description: This property contains the pronouns that the contact Description: This property contains the pronouns that the contact
chooses to use for themselves. The value is free-form text. chooses to use for themselves. The value is free-form text.
These pronouns shall be used when addressing or referring to the These pronouns shall be used when addressing or referring to the
contact. Multiple occurrences of this property MAY define contact. Multiple occurrences of this property MAY define
pronouns for multiple languages, preferences and contexts. pronouns for multiple languages, preferences, and contexts.
Multiple pronouns in the same language SHOULD use the PREF Multiple pronouns in the same language SHOULD use the PREF
parameter, otherwise, the order of preference is implementation- parameter; otherwise, the order of preference is implementation-
specific. specific.
Format definition: This property is defined by the following Format definition: This property is defined by the following
notation: notation:
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)
; ;
) )
Example(s): Example(s):
PRONOUNS;LANG=en;PREF=1:xe/xir PRONOUNS;LANG=en;PREF=1:xe/xir
PRONOUNS;LANG=en;PREF=2:they/them PRONOUNS;LANG=en;PREF=2:they/them
3.5. SOCIALPROFILE 3.5. SOCIALPROFILE
Property name: SOCIALPROFILE Property name: SOCIALPROFILE
Purpose: To specify the URI or username for social media profiles Purpose: Specifies the URI or username for social media profiles
associated with the object the vCard represents. associated with the object the vCard represents.
Value type: A single URI or TEXT value. The default value type is Value type: A single URI or TEXT value. The default value type is
URI. URI.
Cardinality: * Cardinality: *
Property parameters: The SERVICE-TYPE parameter MUST be assigned to Property parameters: The SERVICE-TYPE parameter MUST be assigned to
this property if the value type is TEXT, it MAY be assigned if the this property if the value type is TEXT, and it MAY be assigned if
value type is URI. In either case, it MUST NOT be assigned more the value type is URI. In either case, it MUST NOT be assigned
than once. more than once.
Description: Several vCard address book implementations currently Description: Several vCard address book implementations currently
use an experimental X-SOCIALPROFILE property to store social media use an experimental X-SOCIALPROFILE property to store social media
profiles for contacts. This specification provides an IANA- profiles for contacts. This specification provides an IANA-
registered property for the same purpose. In addition to the registered property for the same purpose. In addition to the
typical use of this property with URI values, it also allows typical use of this property with URI values, it also allows
setting usernames for social media services as free-text TEXT setting usernames for social media services as free-text TEXT
values, in which case the service name MUST be provided as a values, in which case the service name MUST be provided as a
parameter. Names MUST be considered equal if they match case- parameter. Names MUST be considered equal if they match case-
insensitively. insensitively.
skipping to change at page 11, line 37 skipping to change at line 506
SOCIALPROFILE;SERVICE-TYPE=Mastodon:https://example.com/@foo SOCIALPROFILE;SERVICE-TYPE=Mastodon:https://example.com/@foo
SOCIALPROFILE:https://example.com/ietf SOCIALPROFILE:https://example.com/ietf
SOCIALPROFILE;SERVICE-TYPE=SomeSite;VALUE=text:peter94 SOCIALPROFILE;SERVICE-TYPE=SomeSite;VALUE=text:peter94
4. New Parameters 4. New Parameters
4.1. AUTHOR 4.1. AUTHOR
Parameter name: AUTHOR Parameter name: AUTHOR
Purpose: This parameter identifies the author of the associated Purpose: Identifies the author of the associated property value.
property value.
Description: This parameter MAY be set on any property where Description: This parameter MAY be set on any property where
conveying authorship is desired. It identifies the author as a conveying authorship is desired. It identifies the author as a
URI [RFC3986]. Since every valid URI includes the COLON (U+003A) URI [RFC3986]. Since every valid URI includes the COLON (U+003A)
character, the parameter value MUST be quoted. Note that as an character, the parameter value MUST be quoted. Note that as an
alternative or in addition to this parameter, the AUTHOR-NAME alternative or in addition to this parameter, the AUTHOR-NAME
parameter allows naming an author as free-text value (see parameter allows naming an author as a free-text value (see
Section 4.2). Section 4.2).
Format definition: Format definition:
author-param = "AUTHOR" "=" DQUOTE URI DQUOTE author-param = "AUTHOR" "=" DQUOTE URI DQUOTE
Example(s): Example(s):
NOTE;AUTHOR="mailto:john@example.com":This is some note. NOTE;AUTHOR="mailto:john@example.com":This is some note.
4.2. AUTHOR-NAME 4.2. AUTHOR-NAME
Parameter name: AUTHOR-NAME Parameter name: AUTHOR-NAME
Purpose: This parameter names the author of the associated property Purpose: Names the author of the associated property value.
value.
Description: This parameter MAY be set on any property where Description: This parameter MAY be set on any property where
conveying authorship is desired. It names the author as a free- conveying authorship is desired. It names the author as a free-
text value. The parameter value MUST NOT be empty. text value. The parameter value MUST NOT be empty.
Implementations MUST take care to quote the name part, if Implementations MUST take care to quote the name part, if
otherwise the part would not be a valid param-value (see otherwise the part would not be a valid param-value (see
Section 3.3 of [RFC6350]). Note that as an alternative or in Section 3.3 of [RFC6350]). Note that as an alternative or in
addition to this parameter, the AUTHOR parameter allows addition to this parameter, the AUTHOR parameter allows
identifying an author by URI (see Section 4.1). identifying an author by URI (see Section 4.1).
skipping to change at page 12, line 32 skipping to change at line 548
author-name-param = "AUTHOR-NAME" "=" param-value ; not empty author-name-param = "AUTHOR-NAME" "=" param-value ; not empty
Example(s): Example(s):
NOTE;AUTHOR-NAME=John Doe:This is some note. NOTE;AUTHOR-NAME=John Doe:This is some note.
NOTE;AUTHOR-NAME="_:l33tHckr:_":A note by an unusual author name. NOTE;AUTHOR-NAME="_:l33tHckr:_":A note by an unusual author name.
4.3. CREATED 4.3. CREATED
Parameter name: CREATED Parameter name: CREATED
Purpose: This parameter defines the date and time when a property Purpose: Defines the date and time when a property was created in a
was created in a vCard. vCard.
Description: This parameter MAY be set on any property to define the Description: This parameter MAY be set on any property to define the
point in time when the property was created. The value MUST be a point in time when the property was created. The value MUST be a
valid TIMESTAMP value as defined in Section 4.3.5 of [RFC6350]. valid TIMESTAMP value as defined in Section 4.3.5 of [RFC6350].
Generally, updating a property value SHOULD NOT change the Generally, updating a property value SHOULD NOT change the
creation timestamp. creation timestamp.
Format definition: Format definition:
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
Example(s): Example(s):
NOTE;CREATED=20221122T151823Z:This is some note. NOTE;CREATED=20221122T151823Z:This is some note.
4.4. DERIVED 4.4. DERIVED
Parameter name: DERIVED Parameter name: DERIVED
Purpose: This parameter specifies that the value of the associated Purpose: Specifies that the value of the associated property is
property is derived from some other property values in the same derived from some other property values in the same vCard.
vCard.
Description: This property parameter SHOULD be specified on an Description: This property parameter SHOULD be specified on a
property if the property value is derived from some other property if the property value is derived from some other
properties in the same vCard. When present with a value of true, properties in the same vCard. When present with a value of true,
clients MUST NOT update the property. clients MUST NOT update the property.
For an example, an implementation may derive the value of the FN As an example, an implementation may derive the value of the FN
property from the name components of the N property. It indicates property from the name components of the N property. It indicates
this fact by setting the DERIVED parameter on the FN property to this fact by setting the DERIVED parameter on the FN property to
true. true.
Format definition: Format definition:
derived-param = "DERIVED" "=" ("true" / "false") derived-param = "DERIVED" "=" ("true" / "false")
; Default is false ; Default is false
Example(s): Example(s):
N:;John;Quinlan;Mr.; N:;John;Quinlan;Mr.;
FN;DERIVED=TRUE:Mr. John Quinlan FN;DERIVED=TRUE:Mr. John Quinlan
4.5. LABEL 4.5. LABEL
Parameter name: LABEL Parameter name: LABEL
Purpose: This parameter is used with the ADR property. Its value Purpose: Used with the ADR property. Its value contains a formatted
contains a formatted text representation of that address, e.g. for text representation of that address, e.g., for delivery.
delivery.
Description: Section 6.3.1 of [RFC6350] defines the ADR property, Description: Section 6.3.1 of [RFC6350] defines the ADR property,
noting that the property can also include a LABEL parameter to noting that the property can also include a LABEL parameter to
present a delivery address label for the address. But this present a delivery address label for the address. But this
parameter was not included in the IANA Parameters Registry parameter was not included in the IANA "vCard Parameters" registry
Section 10.3.2 of [RFC6350] and accordingly is not a registered (Section 10.3.2 of [RFC6350]) and, accordingly, is not a
standard vCard element. This specification defines and registers registered standard vCard element. This specification defines and
the LABEL parameter for use with the ADR property as originally registers the LABEL parameter for use with the ADR property as
intended. originally intended.
Format definition: Format definition:
label-param = "LABEL" "=" param-value label-param = "LABEL" "=" param-value
Example(s): The LABEL parameter as illustrated the ADR property Example(s): The LABEL parameter as illustrated in the ADR property
example in Section 6.3.1 of [RFC6350]. example in Section 6.3.1 of [RFC6350].
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.
4.6. PHONETIC 4.6. PHONETIC
Parameter name: PHONETIC Parameter name: PHONETIC
Purpose: This parameter defines how to pronounce the value of Purpose: Defines how to pronounce the value of another property in
another property in the same vCard. the same vCard.
Description: This property parameter indicates that the value of its Description: This property parameter indicates that the value of its
property contains the phonetic representation of a same-named property contains the phonetic representation of another same-
other property in the same vCard. Exemplary uses are to define named property in the same vCard. Exemplary uses are defining how
how pronounce a Japanese name, or for romanization of Mandarin or to pronounce Japanese names and romanizing Mandarin or Cantonese
Cantonese name and address components. names and address components.
The parameter value indicates the phonetic system and MUST be one The parameter value indicates the phonetic system and MUST be one
of the values enumerated in the IANA vCard Parameter Values of the values enumerated in the IANA "vCard Parameter Values"
(Section 7.4) registry. This specification defines the following registry (Section 7.4). This specification defines the following
values: values:
* ipa: denotes the International Phonetic Alphabet [IPA]. ipa: denotes the International Phonetic Alphabet [IPA].
* piny: denotes the Standard Mandarin romanization system "Hanyu jyut: denotes the Cantonese romanization system "Jyutping".
Pinyin".
* jyut: denotes the Cantonese romanization system "Jyutping". piny: denotes the Standard Mandarin romanization system "Hanyu
Pinyin".
* script: denotes the unknown phonetic system. The SCRIPT script: denotes the unknown phonetic system. The SCRIPT
(Section 4.8) parameter MUST be set in addition to the PHONETIC (Section 4.8) parameter MUST be set in addition to the PHONETIC
parameter. parameter.
The value type of the property on which the PHONETIC parameter is The value type of the property on which the PHONETIC parameter is
set MUST be of the same type as its related property. If a set MUST be of the same type as its related property. If a
component value is set in the property on which the PHONETIC component value is set in the property on which the PHONETIC
parameter is set, then a component value also MUST be set at that parameter is set, then a component value also MUST be set at that
same position in the related property. On the other hand, not same position in the related property. On the other hand, not
every component value in the related property needs to have a every component value in the related property needs to have a
phonetic representation. phonetic representation.
The ALTID parameter (Section 5.4 of [RFC6350]) MUST be set with The ALTID (Section 5.4 of [RFC6350]) parameter MUST be set with
equal values on both the related property and the property having equal values on both the related property and the property having
the PHONETIC parameter set. If more than one same-named property the PHONETIC parameter set. If more than one same-named property
has both the PHONETIC parameter set and an equal ALTID parameter has both the PHONETIC parameter set and an equal ALTID parameter
value, then at most one of these properties MAY not have the value, then at most, one of these properties MAY not have the
LANGUAGE parameter set and all others MUST have the LANGUAGE LANGUAGE parameter set, and all others MUST have the LANGUAGE
parameter set. The LANGUAGE parameters MUST NOT have equal parameter set. The LANGUAGE parameters MUST NOT have equal
values. The LANGUAGE parameter value SHOULD NOT contain a script values. The LANGUAGE parameter value SHOULD NOT contain a script
subtag in its Language-Tag value and any such subtag MUST be subtag in its Language-Tag value, and any such subtag MUST be
ignored in favor of the SCRIPT (Section 4.8) parameter value. ignored in favor of the SCRIPT (Section 4.8) parameter value.
This specification defines the PHONETIC parameter for use with the This specification defines the PHONETIC parameter for use with the
ADR and N properties. ADR and N properties.
Format definition: Format definition:
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
Example(s): Example(s):
N;ALTID=1;LANGUAGE=zh-Hant:孫;中山;文,逸仙;;;; N;ALTID=1;LANGUAGE=zh-Hant:孫;中山;文,逸仙;;;;
N;ALTID=1;PHONETIC=jyut; N;ALTID=1;PHONETIC=jyut;
SCRIPT=Latn;LANGUAGE=yue:syun1;zung1saan1;man4,jat6sin1;;;; SCRIPT=Latn;LANGUAGE=yue:syun1;zung1saan1;man4,jat6sin1;;;;
4.7. PROP-ID 4.7. PROP-ID
Parameter name: PROP-ID Parameter name: PROP-ID
Purpose: This parameter identifies a property among all its siblings Purpose: Identifies a property among all its siblings of the same
of the same property name. property name.
Description: This parameter uniquely identifies a property among all Description: This parameter uniquely identifies a property among all
of its siblings with the same name within a vCard. A valid PROP- of its siblings 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 ID value must be of 1 and a maximum of 255 octets in size, and it
MUST only contain the ASCII alphanumeric characters (A-Za-z0-9), MUST only contain the ASCII alphanumeric characters (A-Za-z0-9),
hyphen (-), and underscore (_). The identifier only has the hyphen (-), and underscore (_). The identifier's only purpose is
purpose to uniquely identify siblings, its value has no other to uniquely identify siblings; its value has no other meaning. If
meaning. If an application makes use of PROP-ID it SHOULD assign an application makes use of PROP-ID, it SHOULD assign a unique
a unique identifier to each sibling property of the same name identifier to each sibling property of the same name within their
within their embedding component. The same identifier MAY be used embedding component. The same identifier MAY be used for
for properties of a different name, and it MAY also be assigned to properties of a different name, and it MAY also be assigned to a
a same-named property that is not a sibling. same-named property that is not a sibling.
Resolving duplicate identifier conflicts is specific to the Resolving duplicate identifier conflicts is specific to the
application. Similarly, handling properties where some but not application. Similarly, handling properties where some but not
all siblings have a PROP-ID is assigned, is application-specific. all siblings have a PROP-ID assigned is application-specific.
Format definition: Format definition:
prop-id-param = "PROP-ID" "=" 1*255(ALPHA / DIGIT / "-"/ "_") prop-id-param = "PROP-ID" "=" 1*255(ALPHA / DIGIT / "-"/ "_")
Example(s): Example(s):
PHOTO;PROP-ID=p827:data:image/jpeg;base64,MIICajCCAdOgAwIBAg PHOTO;PROP-ID=p827:data:image/jpeg;base64,MIICajCCAdOgAwIBAg
<...remainder of base64-encoded data...> <...remainder of base64-encoded data...>
4.8. SCRIPT 4.8. SCRIPT
Parameter name: SCRIPT Parameter name: SCRIPT
Purpose: This parameter defines the script in which a property value Purpose: Defines the script that a property value is written in.
is written in.
Description: This parameter allows defining a script for a property Description: This parameter allows defining a script for a property
value without also defining a language as the LANGUAGE parameter value without also defining a language as the LANGUAGE parameter
would. The value MUST be a Script Subtag as defined in would. The value MUST be a script subtag as defined in
Section 2.2.3 of [RFC5646]. This specification makes use of the Section 2.2.3 of [RFC5646]. This specification makes use of the
SCRIPT parameter in combination with the PHONETIC (Section 4.6) SCRIPT parameter in combination with the PHONETIC (Section 4.6)
parameter. parameter.
Format definition: Format definition:
script-param = 4ALPHA script-param = 4ALPHA
Example(s): Example(s):
SCRIPT=Latn SCRIPT=Latn
4.9. SERVICE-TYPE 4.9. SERVICE-TYPE
Parameter name: SERVICE-TYPE Parameter name: SERVICE-TYPE
Purpose: To define the online service name associated with a Purpose: Defines the online service name associated with a messaging
messaging or social media profile. or social media profile.
Description: This parameter MAY be specified on a IMPP or Description: This parameter MAY be specified on an IMPP or a
SOCIALPROFILE property to name the online service associated with SOCIALPROFILE property to name the online service associated with
that property value. Its value is case-sensitive, its letter that property value. Its value is case-sensitive; its letter
cases MUST be preserved. cases MUST be preserved.
Several vCard address book implementations currently use an Several vCard address book implementations currently use an
experimental X-SERVICE-TYPE parameter. This specification experimental X-SERVICE-TYPE parameter. This specification
provides an IANA-registered parameter for the same purpose. provides an IANA-registered parameter for the same purpose.
Format definition: Format definition:
service-type-param = "SERVICE-TYPE" "=" param-value service-type-param = "SERVICE-TYPE" "=" param-value
Example(s): Example(s):
SOCIALPROFILE;SERVICE-TYPE=Mastodon:https://example.com/@foo SOCIALPROFILE;SERVICE-TYPE=Mastodon:https://example.com/@foo
4.10. USERNAME 4.10. USERNAME
Parameter name: USERNAME Parameter name: USERNAME
Purpose: To define a username, such as the user of a messaging or Purpose: Defines a username such as the user of a messaging or
social media service. social media service.
Description: This parameter MAY be specified on a IMPP or Description: This parameter MAY be specified on an IMPP or a
SOCIALPROFILE property to name the user with that property value. SOCIALPROFILE property to name the user with that property value.
Its value is case-sensitive, its letter cases MUST be preserved. Its value is case-sensitive; its letter cases MUST be preserved.
The IMPP or SOCIALPROFILE value type MUST be URI. The IMPP or SOCIALPROFILE value type MUST be URI.
Format definition: Format definition:
username-param = "USERNAME" "=" param-value username-param = "USERNAME" "=" param-value
Example(s): Example(s):
SOCIALPROFILE;USERNAME="The Foo":https://example.com/@foo SOCIALPROFILE;USERNAME="The Foo":https://example.com/@foo
5. New Values 5. New Values
5.1. Billing Address Type Value 5.1. Billing Address Type Value
Value: billing Value: billing
Purpose: This indicates to use this address for billing, e.g., to Purpose: Indicates using this address for billing, e.g., to send
send invoices to. invoices to.
Conformance: This value can be used with the "TYPE" parameter Conformance: This value can be used with the TYPE parameter applied
applied on the "ADR" property. on the ADR property.
Example(s): Example(s):
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.
5.2. Delivery Address Type Value 5.2. Delivery Address Type Value
Value: delivery Value: delivery
Purpose: This indicates to use this address for delivery, e.g., to Purpose: Indicates using this address for delivery, e.g., to send
send packages to. packages to.
Conformance: This value can be used with the "TYPE" parameter Conformance: This value can be used with the TYPE parameter applied
applied on the "ADR" property. on the ADR property.
Example(s): Example(s):
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.
6. Security Considerations 6. Security Considerations
This specification extends the vCard Format Specification. The same This specification extends "vCard Format Specification" [RFC6350].
security considerations as outlined in Section 9 of [RFC6350] apply. The same security considerations as outlined in Section 9 of
[RFC6350] apply.
7. IANA Considerations 7. IANA Considerations
7.1. Changes to the "vCard Properties" registry 7.1. Changes to the vCard Properties Registry
7.1.1. New property definitions
IANA is requested to add the following entries to the "vCard
Properties" registry, defined in Section 10.3.1. of [RFC6350].
+===========+===============+============================+
| Namespace | Property | Reference |
+===========+===============+============================+
| | CREATED | This document, Section 3.1 |
+-----------+---------------+----------------------------+
| | GRAMGENDER | This document, Section 3.2 |
+-----------+---------------+----------------------------+
| | LANGUAGE | This document, Section 3.3 |
+-----------+---------------+----------------------------+
| | PRONOUNS | This document, Section 3.4 |
+-----------+---------------+----------------------------+
| | SOCIALPROFILE | This document, Section 3.5 |
+-----------+---------------+----------------------------+
Table 1: New vCard Properties
7.1.2. Updated vCard properties
IANA is requested to add Section 2.1 of this document as reference 7.1.1. New vCard Property Definitions
for the ADR property.
IANA is requested to add Section 2.2 of this document as reference IANA has added the following entries to the "vCard Properties"
for the N property. registry, as defined in Section 10.3.1 of [RFC6350].
7.2. Changes to the "vCard Parameters" registry +===========+===============+=======================+
| Namespace | Property | Reference |
+===========+===============+=======================+
| | CREATED | RFC 9554, Section 3.1 |
+-----------+---------------+-----------------------+
| | GRAMGENDER | RFC 9554, Section 3.2 |
+-----------+---------------+-----------------------+
| | LANGUAGE | RFC 9554, Section 3.3 |
+-----------+---------------+-----------------------+
| | PRONOUNS | RFC 9554, Section 3.4 |
+-----------+---------------+-----------------------+
| | SOCIALPROFILE | RFC 9554, Section 3.5 |
+-----------+---------------+-----------------------+
IANA is requested to add the following entries to the "vCard Table 1: New vCard Properties
Parameters" registry, defined in Section 10.3.2. of [RFC6350].
+===========+==============+================================+ 7.1.2. Updated vCard Properties
| Namespace | Parameter | Reference |
+===========+==============+================================+
| | AUTHOR | This document, Section 4.1 |
+-----------+--------------+--------------------------------+
| | AUTHOR-NAME | This document, Section 4.2 |
+-----------+--------------+--------------------------------+
| | CREATED | This document, Section 4.3 |
+-----------+--------------+--------------------------------+
| | DERIVED | This document, Section 4.4 |
+-----------+--------------+--------------------------------+
| | LABEL | Section 6.3.1 of [RFC6350] and |
| | | this document, Section 4.5 |
+-----------+--------------+--------------------------------+
| | PHONETIC | This document, Section 4.6 |
+-----------+--------------+--------------------------------+
| | PROP-ID | This document, Section 4.7 |
+-----------+--------------+--------------------------------+
| | SCRIPT | This document, Section 4.8 |
+-----------+--------------+--------------------------------+
| | SERVICE-TYPE | This document, Section 4.9 |
+-----------+--------------+--------------------------------+
| | USERNAME | This document, Section 4.10 |
+-----------+--------------+--------------------------------+
Table 2: New vCard Parameters IANA has added Section 2.1 of this document as a reference for the
ADR property and Section 2.2 of this document as a reference for the
N property in the "vCard Properties" registry.
7.3. Changes to the "vCard Property Values" registry 7.2. Changes to the vCard Parameters Registry
IANA is requested to add the following entries to the "vCard Property IANA has added the following entries to the "vCard Parameters"
Values" registry, defined in Section 10.3.4. of [RFC6350]. registry, as defined in Section 10.3.2 of [RFC6350].
+============+===========+============================+ +===========+==============+===========================+
| Property | Value | Reference | | Namespace | Parameter | Reference |
+============+===========+============================+ +===========+==============+===========================+
| GRAMGENDER | animate | This document, Section 3.2 | | | AUTHOR | RFC 9554, Section 4.1 |
+------------+-----------+----------------------------+ +-----------+--------------+---------------------------+
| GRAMGENDER | common | This document, Section 3.2 | | | AUTHOR-NAME | RFC 9554, Section 4.2 |
+------------+-----------+----------------------------+ +-----------+--------------+---------------------------+
| GRAMGENDER | feminine | This document, Section 3.2 | | | CREATED | RFC 9554, Section 4.3 |
+------------+-----------+----------------------------+ +-----------+--------------+---------------------------+
| GRAMGENDER | inanimate | This document, Section 3.2 | | | DERIVED | RFC 9554, Section 4.4 |
+------------+-----------+----------------------------+ +-----------+--------------+---------------------------+
| GRAMGENDER | masculine | This document, Section 3.2 | | | LABEL | [RFC6350], Section 6.3.1 |
+------------+-----------+----------------------------+ | | | and RFC 9554, Section 4.5 |
| GRAMGENDER | neuter | This document, Section 3.2 | +-----------+--------------+---------------------------+
+------------+-----------+----------------------------+ | | PHONETIC | RFC 9554, Section 4.6 |
+-----------+--------------+---------------------------+
| | PROP-ID | RFC 9554, Section 4.7 |
+-----------+--------------+---------------------------+
| | SCRIPT | RFC 9554, Section 4.8 |
+-----------+--------------+---------------------------+
| | SERVICE-TYPE | RFC 9554, Section 4.9 |
+-----------+--------------+---------------------------+
| | USERNAME | RFC 9554, Section 4.10 |
+-----------+--------------+---------------------------+
Table 3: New vCard Property Values Table 2: New vCard Parameters
7.4. Changes to the "vCard Parameter Values" registry 7.3. Changes to the vCard Property Values Registry
IANA is requested to add the following entries to the "vCard IANA has added the following entries to the "vCard Property Values"
Parameter Values" registry, defined in Section 10.3.4. of [RFC6350]. registry, as defined in Section 10.3.4 of [RFC6350].
+==========+===========+==========+============================+ +============+===========+=======================+
| Property | Parameter | Value | Reference | | Property | Value | Reference |
+==========+===========+==========+============================+ +============+===========+=======================+
| ADR | TYPE | billing | This document, Section 5.1 | | GRAMGENDER | animate | RFC 9554, Section 3.2 |
+----------+-----------+----------+----------------------------+ +------------+-----------+-----------------------+
| ADR | TYPE | delivery | This document, Section 5.2 | | GRAMGENDER | common | RFC 9554, Section 3.2 |
+----------+-----------+----------+----------------------------+ +------------+-----------+-----------------------+
| ADR | TYPE | delivery | This document, Section 5.2 | | GRAMGENDER | feminine | RFC 9554, Section 3.2 |
+----------+-----------+----------+----------------------------+ +------------+-----------+-----------------------+
| ADR, N | PHONETIC | ipa | This document, Section 4.6 | | GRAMGENDER | inanimate | RFC 9554, Section 3.2 |
+----------+-----------+----------+----------------------------+ +------------+-----------+-----------------------+
| ADR, N | PHONETIC | jyut | This document, Section 4.6 | | GRAMGENDER | masculine | RFC 9554, Section 3.2 |
+----------+-----------+----------+----------------------------+ +------------+-----------+-----------------------+
| ADR, N | PHONETIC | piny | This document, Section 4.6 | | GRAMGENDER | neuter | RFC 9554, Section 3.2 |
+----------+-----------+----------+----------------------------+ +------------+-----------+-----------------------+
| ADR, N | PHONETIC | script | This document, Section 4.6 |
+----------+-----------+----------+----------------------------+
Table 4: New vCard Property Values Table 3: New vCard Property Values
8. Acknowledgements 7.4. Changes to the vCard Parameter Values Registry
The definition and examples of the PHONETIC (Section 4.6) and SCRIPT IANA has added the following entries to the "vCard Parameter Values"
(Section 4.8) parameters are based on the initial version of registry, as defined in Section 10.3.4 of [RFC6350].
[I-D.calconnect-vobject-i18n].
9. References +==========+===========+==========+=======================+
| Property | Parameter | Value | Reference |
+==========+===========+==========+=======================+
| ADR | TYPE | billing | RFC 9554, Section 5.1 |
+----------+-----------+----------+-----------------------+
| ADR | TYPE | delivery | RFC 9554, Section 5.2 |
+----------+-----------+----------+-----------------------+
| ADR, N | PHONETIC | ipa | RFC 9554, Section 4.6 |
+----------+-----------+----------+-----------------------+
| ADR, N | PHONETIC | jyut | RFC 9554, Section 4.6 |
+----------+-----------+----------+-----------------------+
| ADR, N | PHONETIC | piny | RFC 9554, Section 4.6 |
+----------+-----------+----------+-----------------------+
| ADR, N | PHONETIC | script | RFC 9554, Section 4.6 |
+----------+-----------+----------+-----------------------+
9.1. Normative References Table 4: New vCard Property and Parameter Values
[I-D.ietf-calext-jscontact] 8. References
Stepanek, R. and M. Loffredo, "JSContact: A JSON
representation of contact data", Work in Progress,
Internet-Draft, draft-ietf-calext-jscontact-13, 24 July
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
calext-jscontact-13>.
[I-D.ietf-calext-jscontact-vcard] 8.1. Normative References
Loffredo, M. and R. Stepanek, "JSContact: Converting from
and to vCard", Work in Progress, Internet-Draft, draft-
ietf-calext-jscontact-vcard-11, 24 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-calext-
jscontact-vcard-11>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 21, line 50 skipping to change at line 939
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011, DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>. <https://www.rfc-editor.org/info/rfc6350>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10. Informative References [RFC9553] Stepanek, R. and M. Loffredo, "JSContact: A JSON
Representation of Contact Data", RFC 9553,
DOI 10.17487/RFC9553, March 2024,
<https://www.rfc-editor.org/info/rfc9553>.
[CLDRPersonName] [RFC9555] Loffredo, M. and R. Stepanek, "JSContact: Converting from
Davis, M., Edberg, P., Gillam, R., Kolisnychenko, A., and to vCard", RFC 9555, DOI 10.17487/RFC9555, March 2024,
McKenna, M., and others, "Technical Standard #35: Unicode <https://www.rfc-editor.org/info/rfc9555>.
Locale Data Markup Language (LDML) Part 8: Person Names,
Version 43.1", July 2023,
<https://www.unicode.org/reports/tr35/
tr35-personNames.html>.
[I-D.calconnect-vobject-i18n] 9. Informative References
Tse, R. H., Tam, P., and M. Douglass, "vObject
[CALCONNECT-VOBJECT]
Tse, R., Tam, P., and M. Douglass, "vObject
Internationalization", Work in Progress, Internet-Draft, Internationalization", Work in Progress, Internet-Draft,
draft-calconnect-vobject-i18n-00, 7 June 2018, draft-calconnect-vobject-i18n-00, 7 June 2018,
<https://datatracker.ietf.org/doc/html/draft-calconnect- <https://datatracker.ietf.org/doc/html/draft-calconnect-
vobject-i18n-00>. vobject-i18n-00>.
[IPA] "International Phonetic Alphabet", [CLDRPersonName]
Davis, M., Edberg, P., Gillam, R., Kolisnychenko, A.,
McKenna, M., and other CLDR committee members, "Unicode
Locale Data Markup Language (LDML) Part 8: Person Names",
Unicode Technical Standard #35, Version 44.1, July 2023,
<https://www.unicode.org/reports/tr35/
tr35-personNames.html>.
[IPA] IPA, "International Phonetic Alphabet",
<https://www.internationalphoneticalphabet.org/>. <https://www.internationalphoneticalphabet.org/>.
Acknowledgements
The definition and examples of the PHONETIC (Section 4.6) and SCRIPT
(Section 4.8) parameters are based on the early draft version of
[CALCONNECT-VOBJECT].
Authors' Addresses Authors' Addresses
Robert Stepanek Robert Stepanek
Fastmail Fastmail
PO Box 234, Collins St West PO Box 234
Melbourne VIC 8007 Collins St. West
Melbourne VIC 8007
Australia Australia
Email: rsto@fastmailteam.com Email: rsto@fastmailteam.com
Mario Loffredo Mario Loffredo
IIT-CNR IIT-CNR
Via Moruzzi,1 Via Moruzzi, 1
56124 Pisa 56124 Pisa
Italy Italy
Email: mario.loffredo@iit.cnr.it Email: mario.loffredo@iit.cnr.it
 End of changes. 121 change blocks. 
419 lines changed or deleted 408 lines changed or added

This html diff was produced by rfcdiff 1.48.