calext
Internet Engineering Task Force (IETF) M. Loffredo
Internet-Draft
Request for Comments: 9555 IIT-CNR/Registro.it
Updates: 6350 (if approved) R. Stepanek
Intended status:
Category: Standards Track Fastmail
Expires: 21 March
ISSN: 2070-1721 April 2024 18 September 2023
JSContact: Converting from and to vCard
draft-ietf-calext-jscontact-vcard-13
Abstract
This document defines how to convert contact information between the
JSContact and vCard data formats. To achieve this, it updates RFC I-
D.ietf-calext-jscontact (JSContact) by registering new It defines conversion rules for
every JSContact
properties. Similarly, it updates RFC 6350 (vCard) by registering and vCard element registered at IANA at the time of
publication. It also defines new JSContact properties as well as
vCard properties and parameters. parameters, to support converting arbitrary or
unknown JSContact and vCard elements.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of six months RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 March 2024.
https://www.rfc-editor.org/info/rfc9555.
Copyright Notice
Copyright (c) 2023 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5
1.3. ABNF Notations . . . . . . . . . . . . . . . . . . . . . 5
2. Converting vCard to JSContact . . . . . . . . . . . . . . . . 5
2.1. General rules . . . . . . . . . . . . . . . . . . . . . . 5 Rules
2.1.1. The Card uid property . . . . . . . . . . . . . . . . . . 6 Property
2.1.2. Choosing identifiers . . . . . . . . . . . . . . . . 6 Identifiers
2.2. vCard Value Data Types . . . . . . . . . . . . . . . . . 6
2.2.1. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. INTEGER . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.4. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.5. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . 7
2.2.6. TEXT . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.7. URI . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.8. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . 7
2.3. vCard Parameters . . . . . . . . . . . . . . . . . . . . 7
2.3.1. ALTID . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. AUTHOR . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3. AUTHOR-NAME . . . . . . . . . . . . . . . . . . . . . 8
2.3.4. CALSCALE . . . . . . . . . . . . . . . . . . . . . . 8
2.3.5. CREATED . . . . . . . . . . . . . . . . . . . . . . . 8 CC
2.3.6. DERIVED . . . . . . . . . . . . . . . . . . . . . . . 8 CREATED
2.3.7. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 8 DERIVED
2.3.8. GROUP . . . . . . . . . . . . . . . . . . . . . . . . 8 GEO
2.3.9. INDEX . . . . . . . . . . . . . . . . . . . . . . . . 9 GROUP
2.3.10. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . 9 INDEX
2.3.11. LEVEL . . . . . . . . . . . . . . . . . . . . . . . . 12 LANGUAGE
2.3.12. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . 12 LABEL
2.3.13. PHONETIC . . . . . . . . . . . . . . . . . . . . . . 12 LEVEL
2.3.14. PID . . . . . . . . . . . . . . . . . . . . . . . . . 14 MEDIATYPE
2.3.15. PREF . . . . . . . . . . . . . . . . . . . . . . . . 14 PHONETIC
2.3.16. PROP-ID . . . . . . . . . . . . . . . . . . . . . . . 14 PID
2.3.17. SCRIPT . . . . . . . . . . . . . . . . . . . . . . . 14 PREF
2.3.18. SERVICE-TYPE . . . . . . . . . . . . . . . . . . . . 14 PROP-ID
2.3.19. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . 15 SCRIPT
2.3.20. TYPE . . . . . . . . . . . . . . . . . . . . . . . . 15 SERVICE-TYPE
2.3.21. TZ . . . . . . . . . . . . . . . . . . . . . . . . . 15 SORT-AS
2.3.22. USERNAME . . . . . . . . . . . . . . . . . . . . . . 15 TYPE
2.3.23. TZ
2.3.24. USERNAME
2.3.25. VALUE . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4. General Properties . . . . . . . . . . . . . . . . . . . 15
2.4.1. BEGIN and END . . . . . . . . . . . . . . . . . . . . 15
2.4.2. KIND . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.4. XML . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5. Identification Properties . . . . . . . . . . . . . . . . 16
2.5.1. ANNIVERSARY, BDAY, BIRTHPLACE, DEATHDATE, DEATHPLACE,
ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 16 and
DEATHPLACE
2.5.2. FN . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.3. GENDER . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.4. GRAMGENDER and PRONOUNS . . . . . . . . . . . . . . . 18
2.5.5. N . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.6. NICKNAME . . . . . . . . . . . . . . . . . . . . . . 21
2.5.7. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6. Delivery Addressing Properties . . . . . . . . . . . . . 22
2.6.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7. Communications Properties . . . . . . . . . . . . . . . . 25
2.7.1. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7.2. IMPP . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.3. LANG . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.4. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . 27
2.7.5. SOCIALPROFILE . . . . . . . . . . . . . . . . . . . . 27
2.7.6. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.8. Geographical Properties . . . . . . . . . . . . . . . . . 29
2.8.1. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8.2. TZ . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8.3. Combining geographical properties . . . . . . . . . . 30 Geographical Properties
2.9. Organizational Properties . . . . . . . . . . . . . . . . 30
2.9.1. CONTACT-URI . . . . . . . . . . . . . . . . . . . . . 30
2.9.2. LOGO . . . . . . . . . . . . . . . . . . . . . . . . 31
2.9.3. MEMBER . . . . . . . . . . . . . . . . . . . . . . . 31
2.9.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.9.5. RELATED . . . . . . . . . . . . . . . . . . . . . . . 32
2.9.6. TITLE and ROLE . . . . . . . . . . . . . . . . . . . 33
2.10. Personal Information Properties . . . . . . . . . . . . . 34
2.10.1. EXPERTISE . . . . . . . . . . . . . . . . . . . . . 34
2.10.2. HOBBY . . . . . . . . . . . . . . . . . . . . . . . 35
2.10.3. INTEREST . . . . . . . . . . . . . . . . . . . . . . 36
2.10.4. ORG-DIRECTORY . . . . . . . . . . . . . . . . . . . 36
2.11. Explanatory Properties . . . . . . . . . . . . . . . . . 37
2.11.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . 37
2.11.2. CLIENTPIDMAP and PID Parameter . . . . . . . . . . . 37
2.11.3. CREATED . . . . . . . . . . . . . . . . . . . . . . 38
2.11.4. NOTE . . . . . . . . . . . . . . . . . . . . . . . . 38
2.11.5. PRODID . . . . . . . . . . . . . . . . . . . . . . . 38
2.11.6. REV . . . . . . . . . . . . . . . . . . . . . . . . 39
2.11.7. SOUND . . . . . . . . . . . . . . . . . . . . . . . 39
2.11.8. UID . . . . . . . . . . . . . . . . . . . . . . . . 39
2.11.9. URL . . . . . . . . . . . . . . . . . . . . . . . . 39
2.11.10. VERSION . . . . . . . . . . . . . . . . . . . . . . 40
2.11.11. X-ABLabel . . . . . . . . . . . . . . . . . . . . . 40
2.12. Security Properties . . . . . . . . . . . . . . . . . . . 40
2.12.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . 41
2.13. Calendar Properties . . . . . . . . . . . . . . . . . . . 41
2.13.1. CALADRURI . . . . . . . . . . . . . . . . . . . . . 41
2.13.2. CALURI . . . . . . . . . . . . . . . . . . . . . . . 42
2.13.3. FBURL . . . . . . . . . . . . . . . . . . . . . . . 42
2.14. Extended Properties and Parameters . . . . . . . . . . . 43
2.15. New JSContact properties . . . . . . . . . . . . . . . . 43 Properties
2.15.1. Property vCardProps . . . . . . . . . . . . . . . . 43
2.15.2. Property vCardParams . . . . . . . . . . . . . . . . 44
2.15.3. Property vCardName . . . . . . . . . . . . . . . . . 44
3. Converting JSContact to vCard . . . . . . . . . . . . . . . . 45
3.1. Conversion Rules . . . . . . . . . . . . . . . . . . . . 45
3.1.1. Converting unknown properties . . . . . . . . . . . . 46 Unknown Properties
3.2. New vCard Properties . . . . . . . . . . . . . . . . . . 46
3.2.1. JSPROP . . . . . . . . . . . . . . . . . . . . . . . 46
3.3. New vCard Parameter . . . . . . . . . . . . . . . . . . . 48 Parameters
3.3.1. JSCOMPS . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.2. JSPTR . . . . . . . . . . . . . . . . . . . . . . . . 52
4. Security Considerations . . . . . . . . . . . . . . . . . . . 52
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
6.1.
5.1. New vCard Properties . . . . . . . . . . . . . . . . . . 52
6.2. Property
5.2. New vCard Parameters . . . . . . . . . . . . . . . . . . 53
6.3. Parameter
5.3. New JSContact Properties . . . . . . . . . . . . . . . . 53
6.4.
5.4. New JSContact Types . . . . . . . . . . . . . . . . . . . 53
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 54
7.1. CNR . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8. Type
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1.
6.1. Normative References . . . . . . . . . . . . . . . . . . 55
8.2.
6.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Reverse Rules of Converting a vCard to a JSContact
Card . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
1. Introduction
1.1. Motivation
The JSContact data model and format [I-D.ietf-calext-jscontact] [RFC9553] aims to be an
alternative to the widely used vCard [RFC6350] standard [RFC6350] and jCard
format [RFC7095].
While applications might prefer JSContact to exchange contact card
data with other systems, they are likely to interoperate with
services and clients that only support vCard or jCard. Similarly,
existing contact data providers and consumers already using vCard or
jCard might also want to represent their contact data also in JSContact.
To achieve this, this document defines standard rules to convert
contact data between JSContact and vCard (and consequently jCard).
1.2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.3. ABNF Notations
The ABNF definitions in this document use the notations of [RFC5234].
ABNF rules not defined in this document either are defined in either
[RFC5234] (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and
DIGIT) or [RFC6350].
2. Converting vCard to JSContact
This section contains the conversion rules from the vCard to the
JSContact Card. It follows the same structure as the vCard v4 [RFC6350].
Properties and parameters of vCard extension RFCs, including the
vCard JSContact those
described in "vCard Format Extension
[I-D.ietf-calext-vcard-jscontact-extensions] are for JSContact" [RFC9554], have
been added to the appropriate subsections.
2.1. General rules Rules
2.1.1. The Card uid property Property
The UID property (Section 6.7.6 of [RFC6350]) in vCard is optional,
but the Card object's uid property in
JSContact (Section 2.1.9 of [RFC9553]) is
mandatory. Implementations that convert a vCard without a UID
property MUST generate a unique identifier as a value for the uid
property. This value SHOULD be the same when converting the same
vCard multiple times, but how to achieve this is implementation-
specific.
2.1.2. Choosing identifiers Identifiers
Multivalued properties in JSContact typically are typically represented as a
JSON object where the object keys are of the Id type (Section 1.4.1
of [RFC9553]) and the object values are the converted vCard property.
In the absence of the PROP-ID parameter (see Section 2.3.16), 2.3.18),
implementations are free to choose any identifier as key for such
entries. Whatever identifier generation scheme implementations use,
they MUST generate values that are valid according to the definition
of the Id type in
[I-D.ietf-calext-jscontact]. [RFC9553]. For example, this could be an
incrementing number across all Ids identifier keys in the Card object or
only unique within one JSON object.
2.2. vCard Value Data Types
2.2.1. BOOLEAN
This
The BOOLEAN type (Section 4.4 of [RFC6350]) converts to the JSContact
Boolean type. type (Section 1.3.2 of [RFC9553]).
2.2.2. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP
The TIMESTAMP type generally (Section 4.3.5 of [RFC6350]) converts to the UTCDateTime. It
UTCDateTime type (Section 1.4.5 of [RFC9553]), except for
anniversaries. For anniversaries, it converts to the Timestamp type for anniversaries.
(Section 2.8.1 of [RFC9553]).
The DATE type (Section 4.3.1 of [RFC6350]) converts to the a PartialDate type, which only is
relevant
object (Section 2.8.1 of [RFC9553]) when used for anniversaries. This does not apply to an anniversary,
unless the DATE values that value only define contains a month or a day. day (but not both).
The TIME, DATE-TIME, DATE-AND-OR-TIME following temporal types and DATE type values that
only define a month or day do not convert to a JSContact datetime
type. Instead, vCard properties or parameters having such values value
types convert to the properties as defined in Section 2.15.
* TIME (Section 4.3.2 of [RFC6350])
* DATE-TIME (Section 4.3.3 of [RFC6350])
* DATE-AND-OR-TIME (Section 4.3.4 of [RFC6350])
* DATE type values that only define a month or day (but not both)
2.2.3. INTEGER
This
The INTEGER type (Section 4.5 of [RFC6350]) converts to the JSContact
Int and UnsignedInt types. types (Section 1.4.2 of [RFC9553]).
2.2.4. FLOAT
This
The FLOAT type (Section 4.6 of [RFC6350]) converts to the JSContact
Number type. type (Section 1.3.2 of [RFC9553]).
2.2.5. LANGUAGE-TAG
This
The LANGUAGE-TAG type (Section 4.8 of [RFC6350]) converts to the
JSContact String type. type (Section 1.3.2 of [RFC9553]). The value MUST
be a language tag as defined in [RFC5646].
2.2.6. TEXT
This
The TEXT type (Section 4.1 of [RFC6350]) converts to the JSContact
String type. type (Section 1.3.2 of [RFC9553]).
2.2.7. URI
This
The URI type (Section 4.2 of [RFC6350]) converts to the JSContact
String type. type (Section 1.3.2 of [RFC9553]). The value MUST be a URI as
defined in Section 3 of [RFC3986]
2.2.8. UTC-OFFSET
This
The UTC-OFFSET type (Section 4.7 of [RFC6350]) either converts to a
String value containing an IANA TimeZone Time Zone Database entry name (see
Section 2.8.2), 2.8.2) or it does not convert to any JSContact type. For the
latter, vCard properties or parameters having such values MAY convert to JSContact as
defined in Section 2.15.
2.3. vCard Parameters
This section contains the conversion rules for vCard parameters. A
rule typically only applies only for specific vCard properties. To
convert a vCard parameter on an arbitrary vCard property, see
Section 2.15.2.
2.3.1. ALTID
This
The ALTID parameter (Section 5.4 of [RFC6350]) does not convert to an
IANA-registered property in JSContact, but several conversion rules
make use of this parameter to combine multiple vCard properties into
a single JSContact object instance. For an example of this this, see
Section 2.6.1. To preserve the verbatim value of the ALTID
parameter, set the JSContact properties defined in Section 2.15.
2.3.2. AUTHOR
The AUTHOR parameter value (Section 4.1 of [RFC9554]) on a vCard NOTE property
converts to the Author object's uri property (Section 2.8.3 of the
[RFC9553]). That Author object for this note.
Note: This parameter is defined in
[I-D.ietf-calext-vcard-jscontact-extensions]. set as the value of the Note
object's author property (Section 2.8.3 of [RFC9553]).
2.3.3. AUTHOR-NAME
The AUTHOR-NAME parameter value (Section 4.2 of [RFC9554]) on a vCard NOTE
property converts to the Author object's name property (Section 2.8.3
of the [RFC9553]). That Author object for this note.
Note: This parameter is defined in
[I-D.ietf-calext-vcard-jscontact-extensions]. set as the value of the Note
object's author property.
2.3.4. CALSCALE
This
The CALSCALE parameter (Section 5.8 of [RFC6350]) set on a BDAY, DEATHDATE
DEATHDATE, or ANNIVERSARY property converts to the PartialDate
object's calendarScale property (Section 2.8.1 of the PartialDate object
type. [RFC9553]).
2.3.5. CC
The CC parameter (Section 3.1 of [RFC8605]) on an ADR property
converts to the Address object's countryCode property
(Section 2.5.1.1 of [RFC9553]).
2.3.6. CREATED
The CREATED parameter value (Section 4.3 of [RFC9554]) on a vCard NOTE property
converts to the Note object's created property (Section 2.8.3 of the Note object.
Note: This parameter is defined in
[I-D.ietf-calext-vcard-jscontact-extensions].
2.3.6.
[RFC9553]).
2.3.7. DERIVED
The DERIVED parameter (Section 4.4 of [RFC9554]) does not convert to
JSContact. If this the DERIVED parameter is set to true "true" on a vCard
property, then implementations MAY choose to not to convert that
property. Note: This
parameter is defined in [I-D.ietf-calext-vcard-jscontact-extensions].
2.3.7.
2.3.8. GEO
The GEO
This parameter (Section 5.10 of [RFC6350]) set on an ADR property
converts to the JSContact Address object's coordinates property
(Section 2.5.1.1 of the Address object that represents the vCard
ADR.
2.3.8. [RFC9553]).
2.3.9. GROUP
The GROUP
This parameter (Section 7.1 of [RFC7095]) does not convert to
JSContact. It exclusively is for use in jCard (see Section 7.1 of
[RFC7095]). It and MUST NOT be set in
a vCard.
Preserving the exact group name when converting from vCard to
JSContact and back to vCard is not necessary. Any group identifiers
will do, as long as the resulting vCard groups its properties equally
to the original vCard. Implementations that still wish to preserve
the exact property group name of a vCard property MAY set the group jCard
"group" parameter in the JSContact properties vCardProps or
vCardParams as defined in Section 2.15.
item1.TEL;VALUE=uri:tel:+1-555-555-5555
"phones": {
"p1": {
"number": "tel:+1-555-555-5555",
"vCardParams" : {
"group" : "item1"
}
}
}
Figure 1: An example how Example of How to preserve Preserve the group name Group Name in
vCardParams during conversion. Conversion
item2.X-FOO:bar
"vCardProps": [
["x-foo", {
"group": "item2"
}, "unknown", "bar"]
]
Figure 2: An example how Example of How to preserve Preserve the group name Group Name in vCardProps
during conversion.
2.3.9. Conversion
2.3.10. INDEX
The INDEX
This parameter (Section 3.1 of [RFC6715]) set on the EXPERTISE,
HOBBY, INTEREST INTEREST, and ORG-
DIRECTORY ORG-DIRECTORY properties defined in [RFC6715] converts to the JSContact
listAs property of the
PersonalInfo (Section 2.8.4 of [RFC9553]) and Directory objects.
2.3.10.
(Section 2.6.2 of [RFC9553]) objects' listAs property.
2.3.11. LANGUAGE
This
The LANGUAGE parameter (Section 5.1 of [RFC6350]) converts to an
entry in the Card object's localizations property (Section 2.7.1 of
[RFC9553]) for the that vCard property that on which this parameter is set on.
The value of the LANGUAGE parameter defines the language tag key in
the localizations property.
This specification does not define a single standard conversion rule
for how to convert the property values. Instead, building the
localizations value is implementation-specific.
Two options to populate the localizations property are:
* One Patch Per per Property: For each vCard property with a LANGUAGE
parameter, set the complete path in the PatchObject to the
JSContact property that the vCard property converts to. The value
of the patch is the converted property value. This is simple to
process and adequate if the vCard only contains a few properties
with the LANGUAGE parameter.
* Bundle Patches by Parent: If a PatchObject contains multiple paths
that have the same parent paths, then it might be possible to
combine these patches into one patch that patches the parent
property. This is possible if the property in the Card is patched
in its entirety.
Generally, localizations only localize properties that are present in
the non-localized version of this Card. Figure 3 illustrates this.
FN;LANGUAGE=EN:John Doe
TITLE;LANGUAGE=EN:Boss
TITLE;LANGUAGE=fr:Patron
TITLE;ALTID=1;LANGUAGE=EN:Boss
TITLE;ALTID=1;LANGUAGE=fr:Patron
"language": "en",
"name": {
"full": "John Doe"
},
"titles": {
"t1": {
"name": "Boss"
}
},
"localizations": {
"fr": {
"titles/t1/name": "Patron"
}
}
Figure 3: LANGUAGE conversion example: one dominant language Conversion Example: One Dominant Language
As a special case, if one or more vCard properties of the same type
do not have the LANGUAGE parameter set, then choose add them to the non-
localized non-localized
Card. Convert any with LANGUAGE parameters to the localizations
property. Figure 4 illustrates this.
FN:John Doe
TITLE:Boss
TITLE;LANGUAGE=fr:Patron
TITLE;ALTID=1:Boss
TITLE;ALTID=1;LANGUAGE=fr:Patron
"name": {
"full": "John Doe"
},
"titles": {
"t1": {
"name": "Boss"
}
},
"localizations": {
"fr": {
"titles/t1/name": "Patron"
}
}
Figure 4: LANGUAGE conversion example: property Conversion Example: Property without language
As the least preferred option, Figure 5 illustrates how all vCard
properties of the same type have the LANGUAGE parameter set, but none
of their language tags match the language of the main Card. In this
case, implementations MAY choose to add the localized vCard
properties only to the localizations object.
The following example uses non-ASCII characters to demonstrate
multilingual content. Language
2.3.12. LABEL
The ASCII-formatted version LABEL parameter (Section 6.3.1 of this
specification might not show the correct characters. Please refer [RFC6350]) on an ADR property
converts to the HTML or PDF versions instead.
LANGUAGE:es
FN:Gabriel García Márquez
TITLE;LANGUAGE=en:Boss
TITLE;LANGUAGE=fr:Patron
"language": "es",
"name" {
"full": "Gabriel García Márquez"
},
"localizations": {
"en": {
"titles": {
"t1": {
"name": "Novelist"
}
},
"fr": {
"titles": {
"t1": {
"name": "Écrivain"
}
}
}
Figure 5: LANGUAGE conversion example: conflicting LANGUAGE Address object's full property and parameter values
2.3.11. (Section 2.5.1.1 of
[RFC9553]).
2.3.13. LEVEL
The LEVEL parameter [RFC6715] (Section 3.2 of [RFC6715]) converts to the
PersonalInfo object's level property (Section 2.8.4 of the
PersonalInfo type. [RFC9553]).
If this parameter is set on the EXPERTISE property, then its values
convert as: as follows:
* "beginner" converts to "low";
* "average" converts to "medium"; and
* "expert" converts to "high".
In all other cases cases, the values convert verbatim, but lowercase MUST
be used for the JSContact value.
2.3.12.
2.3.14. MEDIATYPE
This
The MEDIATYPE parameter (Section 5.7 of [RFC6350]) converts to the
Resource object's mediaType property (Section 1.4.4 of the Resource object type.
2.3.13. [RFC9553]).
2.3.15. PHONETIC
The PHONETIC
This parameter as well as the SCRIPT (Section 2.3.17) parameter set
on a N or ADR property convert 4.6 of [RFC9554]) converts to JSContact as follows: the values
Name (Section 2.2.1 of the phonetic, phoneticScript [RFC9553]) and Address (Section 2.5.1 of
[RFC9553]) objects' phoneticSystem
properties property unless the parameter
value is "script", in which case the phoneticSystem property is not
set.
The value of the NameComponent and Name or AddressComponent and
Address object types, respectively. SCRIPT parameter converts to the phoneticScript
property (see Section 2.3.19).
The related N or ADR property is defined by the vCard ALTID
parameter. The conversion rules for the N (Section 2.5.5) and ADR
(Section 2.6.1) properties define how the vCard components convert to
JSContact.
The value component values of the PHONETIC parameter converts to the phoneticSystem property unless it is script, in on which case the phoneticSystem
property is not set. The value of the SCRIPT PHONETIC parameter converts to
the phoneticScript property.
The values of the components in the property value
is set convert to values
the phonetic properties for the respective NameComponent or
AddressComponent. AddressComponent
objects' phonetic properties.
If more than one property having has the PHONETIC parameter set and relates
to the same property, then they convert to the Card object's
localizations property according to their LANGUAGE parameter values
as outlined in Section 2.3.10. 2.3.11.
LANGUAGE=zh-Hant
N;ALTID=1;LANGUAGE=zh-Hant:孫;中山;文,逸仙;;
N;ALTID=1;PHONETIC=jyut;
SCRIPT=Latn;LANGUAGE=yue:syun1;zung1saan1;man4,jat6sin1;;
"language": "zh-Hant",
"name": {
"components": [
{ "kind": "surname", "value": "孫" },
{ "kind": "given", "value": "中山" },
{ "kind": "given2", "value": "文" },
{ "kind": "given2", "value": "逸仙" }
]
},
"localizations": {
"yue": {
"name/phoneticSystem": "jyut",
"name/phoneticScript": "Latn",
"name/components/0/phonetic": "syun1",
"name/components/1/phonetic": "zung1saan1",
"name/components/2/phonetic": "man4",
"name/components/3/phonetic": "jat6sin1"
}
}
Figure 6: 5: PHONETIC conversion example
2.3.14. Conversion Example
2.3.16. PID
This
The PID parameter (Section 5.5 of [RFC6350]) converts to an entry in the
vCardParams property, property; see Section 2.15.2.
2.3.15.
2.3.17. PREF
This
The PREF parameter (Section 5.3 of [RFC6350]) converts to the pref property.
2.3.16.
property of the derived JSContact object.
2.3.18. PROP-ID
The PROP-ID parameter value (Section 4.7 of a vCard property [RFC9554]) converts to the Id Id-
typed key of the derived JSContact property to which the vCard property converts. object.
TEL;PROP-ID=PHONE-A;VALUE=uri;PREF=1;TYPE="voice,home"
:tel:+1-555-555-5555;ext=5555
TEL;PROP-ID=PHONE-B;VALUE=uri;TYPE=home
:tel:+33-01-23-45-67
"phones": {
"PHONE-A": {
"contexts": { "private": true },
"features": { "voice": true },
"number": "tel:+1-555-555-5555;ext=5555",
"pref": 1
},
"PHONE-B": {
"contexts": { "private": true },
"number": "tel:+33-01-23-45-67"
}
}
Figure 7: 6: PROP-ID conversion example
Note: This parameter is defined in
[I-D.ietf-calext-vcard-jscontact-extensions].
2.3.17. Conversion Example
2.3.19. SCRIPT
See
The SCRIPT parameter (Section 4.8 of [RFC9554]) converts to the Name
(Section 2.2.1 of [RFC9553]) or Address (Section 2.5.1 of [RFC9553])
objects' phoneticScript property.
Also see Section 2.3.13.
2.3.18. 2.3.15.
2.3.20. SERVICE-TYPE
This
The SERVICE-TYPE parameter (Section 4.9 of [RFC9554]) converts to the
OnlineService object's service property (Section 2.3.2 of the OnlineService object
type. Note: This parameter is defined in
[I-D.ietf-calext-vcard-jscontact-extensions].
2.3.19. [RFC9553]).
2.3.21. SORT-AS
This
The SORT-AS parameter (Section 5.9 of [RFC6350]) converts to the sortAs properties defined for the
Name,
Organization Organization, and OrgUnit object types.
2.3.20. objects' sortAs properties.
2.3.22. TYPE
This
The TYPE parameter (Section 5.6 of [RFC6350]) converts to either the
contexts property as well as property-specific or the kind property values property, as defined in later sections.
If not specified otherwise for a specific JSContact property, specified, the vCard home "home" and work "work" parameter
values convert to the JSContact private "private" and work "work" contexts,
respectively.
2.3.21.
2.3.23. TZ
The TZ
This parameter set (Section 5.11 of [RFC6350]) on an ADR property
converts to the JSContact Address object's timeZone property (Section 2.5.1.1
of the Address object that represents the vCard
ADR. [RFC9553]). Also see the conversion of the TZ property in
Section 2.8.2.
2.3.22.
2.3.24. USERNAME
This
The USERNAME parameter (Section 4.10 of [RFC9554]) converts to the
OnlineService object's user property (Section 2.3.2 of the OnlineService object type.
Note: This parameter is defined in
[I-D.ietf-calext-vcard-jscontact-extensions].
2.3.23. [RFC9553]).
2.3.25. VALUE
This
The VALUE parameter (Section 5.2 of [RFC6350]) does not convert to an
IANA-registered property in JSContact. To preserve properties with
experimental values, see Section 2.15.2 Sections 2.15.1 and Section 2.15.1. 2.15.2.
2.4. General Properties
2.4.1. BEGIN and END
These
The BEGIN and END properties do not convert to IANA-registered
properties in JSContact.
2.4.2. KIND
The KIND property (Section 6.1.4 of [RFC6350]) converts to the kind
property (Figure 8). 7). Allowed values are those described in
Section 6.1.4 of [RFC6350] and extended with the values declared in
[RFC6473] and [RFC6869].
KIND:individual
"kind": "individual"
Figure 8: 7: KIND conversion example Conversion Example
2.4.3. SOURCE
The SOURCE property (Section 6.1.3 of [RFC6350]) converts to a
Directory object (Section 2.6.2 of [RFC9553]) in the Card object's
directories property (Figure 9). 8). The Directory object's kind
property is set to entry. "entry". The uri property is set to the SOURCE
property value.
The PREF and MEDIATYPE parameters convert according to the rules as
defined in Section 2.3.
SOURCE:https://dir.example.com/addrbook/jdoe/Jean%20Dupont.vcf
"directories": {
"ENTRY-1": {
"kind": "entry",
"uri": "https://dir.example.com/addrbook/jdoe/Jean%20Dupont.vcf"
}
}
Figure 9: 8: SOURCE conversion example Conversion Example
2.4.4. XML
This
The XML property (Section 6.1.5 of [RFC6350]) converts to an entry in the
vCardProps property, property; see Section 2.15.1.
2.5. Identification Properties
2.5.1. ANNIVERSARY, BDAY, BIRTHPLACE, DEATHDATE, DEATHPLACE, ANNIVERSARY
The BDAY and ANNIVERSARY properties and the extensions BIRTHPLACE,
DEATHDATE, DEATHPLACE described in [RFC6474] are represented as
The following properties all convert to Anniversary objects included in the
Card object's anniversaries property (Figure 10): 9):
* ANNIVERSARY (Section 6.2.6 of [RFC6350])
* BDAY (Section 6.2.5 of [RFC6350])
* BIRTHPLACE (Section 2.1 of [RFC6474])
* DEATHDATE (Section 2.3 of [RFC6474])
* DEATHPLACE (Section 2.2 of [RFC6474])
BDAY and BIRTHPLACE convert to an Anniversary object (Section 2.8.1
of [RFC9553]) having the date and place where properties set. The kind
poperty is set to
"birth";
* "birth".
DEATHDATE and DEATHPLACE convert to an Anniversary object having the
date and place where properties set. The Anniversary object's kind
property is set to "death";
* "death".
ANNIVERSARY converts to the Anniversary object's date where property. The
Anniversary object's kind property is set to "wedding".
Both birth and death places are represented as instances of
If the
Address object.
The BIRTHPLACE and or DEATHPLACE properties that are represented as geo
URIs convert property value is of type URI using
the "geo:" URI scheme, then it converts to Address instances including only the Address object's
coordinates property. If the URI value type is not a geo URI, TEXT, then it converts to
the place is ignored. Address object's full property. Otherwise, it converts to the
vCardProps property; see Section 2.15.1.
The ALTID and LANGUAGE parameters of both the BIRTHPLACE and
DEATHPLACE properties convert according to the rules as defined in
Section 2.3.
BDAY:19531015T231000Z
BIRTHPLACE:
123 Main Street\nAny Town, CA 91921-1234\nU.S.A.
DEATHDATE:19960415
DEATHPLACE:
5 Court Street\nNew England, ND 58647\nU.S.A.
ANNIVERSARY:19860201
"anniversaries": {
"ANNIVERSARY-1" : {
"kind": "birth",
"date": {
"@type": "Timestamp",
"utc": "1953-10-15T23:10:00Z"
},
"place": {
"full":
"123 Main Street\nAny Town, CA 91921-1234\nU.S.A."
}
},
"ANNIVERSARY-2" : {
"kind": "death",
"date": {
"year": 1996,
"month": 4,
"year": 15
},
"place": {
"full": "5 Court Street\nNew England, ND 58647\nU.S.A."
}
},
"ANNIVERSARY-3" : {
"kind": "wedding",
"date": {
"year": 1986,
"month": 2,
"day": 1
}
}
}
Figure 10: 9: ANNIVERSARY, BDAY, BIRTHPLACE, DEATHDATE, DEATHPLACE, ANNIVERSARY
conversion example and
DEATHPLACE Conversion Example
2.5.2. FN
The FN property (Section 6.2.1 of [RFC6350]) converts to the Name object in the name property.
Its value converts to the Name object
object's full property (Figure 11). 10). If the LANGUAGE parameter is
set, then the FN property converts as outlined in Section 2.3.10. 2.3.11. In
the unexpected case that where the vCard contains more than one FN
property without the LANGUAGE parameter, then convert the FN property that
has the least parameters set to the full
property. parameters. If multiple such FN properties are
present, choose any of them. All other FN properties convert to the
vCardProps (Section 2.15.1) property.
FN:John Q. Public, Esq.
"name": {
"full": "John Q. Public, Esq.", Esq."
}
Figure 11: 10: FN conversion example Conversion Example
2.5.3. GENDER
This
The GENDER property (Section 6.2.7 of [RFC6350]) does not map convert to
an IANA-registered property in JSContact. To convert this property,
see Section 2.15.1. Note Alternatively, the alternative
JSContact Card object's speakToAs
property which defines how to address and refer to an individual
represented by the card, Card, as do the newly defined vCard GRAMGENDER and
PRONOUNS properties of
[I-D.ietf-calext-vcard-jscontact-extensions]. [RFC9554].
2.5.4. GRAMGENDER and PRONOUNS
The GRAMGENDER property (Section 3.2 of [RFC9554]) converts to the
SpeakToAs object's grammaticalGender property of
the SpeakToAs object (Figure 12). 11).
The PRONOUNS property (Section 3.4 of [RFC9554]) converts to an entry in the
SpeakToAs object's pronouns property
of the SpeakToAs object (Figure 12). 11).
GRAMGENDER:NEUTER
PRONOUNS;PREF=2:they/them
PRONOUNS;PREF=1:xe/xir
"speakToAs": {
"grammaticalGender": "neuter",
"pronouns": {
"PRONOUNS-1": {
"pronouns": "they/them",
"pref": 2
},
"PRONOUNS-2": {
"pronouns": "xe/xir",
"pref": 1
}
}
}
Figure 12: 11: GRAMGENDER and PRONOUNS conversion example Conversion Example
2.5.5. N
The N property (Section 6.2.2 of [RFC6350]) converts to the a Name object
(Section 2.2.1 of [RFC9553]) in the Card object's name property.
Each component in the N property structured value converts to a
NameComponent in the Name object's components property. The
following table shows this relation:
+============+===============+==============================+
| N | NameComponent | Remarks |
| component | kind | |
+============+===============+==============================+
| Family | surname | To vCard: add any surname2 "surname2" |
| name | | NameComponent value in here, to the Family |
| | | name component, after all surname |
| | | "surname" values. |
| | | From vCard: ignore any value |
| | | that also occurs in the |
| | | Secondary surname component. |
+------------+---------------+------------------------------+
| Given name | given | |
+------------+---------------+------------------------------+
| Additional | given2 | |
| name | | |
+------------+---------------+------------------------------+
| Honorific | title | |
| prefix | | |
+------------+---------------+------------------------------+
| Honorific | credential | To vCard: add any generation |
| suffix | | "generation" NameComponent value also in |
| | | here. to the Honorific suffix |
| | | component. |
| | | From vCard: ignore any value |
| | | that also occurs in the |
| | | Generation component. |
+------------+---------------+------------------------------+
| Secondary | surname2 | |
| surname | | |
+------------+---------------+------------------------------+
| Generation | generation | |
+------------+---------------+------------------------------+
Table 1: N components conversion Components Conversion
If the JSCOMPS (Section 3.3.1) parameter is set, then the Name
object's isOrdered property value is "true", and the defaultSeparator
property and any
separator name components "separator" NameComponent objects are set according
to the parameter value. The order in the components list property MUST
adhere to the order of the JSCOMPS parameter value.
If the JSCOMPS parameter is not set, then the Name object's isOrdered
property value is "false" "false", and the defaultSeparator property MUST NOT
be set. The order in the components list property MUST follow the order
of values in the N structured value when read from left to right.
If the SORT-AS parameter is set, then its structured value converts
to the Name object's sortAs property according to Table 1. An empty
or non-
existent non-existent component value indicates that no sort is defined for
this kind.
N;SORT-AS="Stevenson,John Philip":Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr. Philip":
Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr.
"name": {
"components":[
{ "kind": "surname", "value": "Stevenson" },
{ "kind": "given", "value": "John" },
{ "kind": "given2", "value": "Philip" },
{ "kind": "given2", "value": "Paul" },
{ "kind": "title", "value": "Dr." },
{ "kind": "credential", "value": "M.D." },
{ "kind": "credential", "value": "A.C.P." },
{ "kind": "generation", "value": "Jr." }
],
"sortAs": {
"surname": "Stevenson",
"given": "John Philip"
}
}
Figure 13: 12: N conversion example Conversion Example
See Section 3.3.1 for examples of using the JSCOMPS parameter for
vCard structured
vCard-structured property values.
2.5.6. NICKNAME
A
The NICKNAME property (Section 6.2.3 of [RFC6350]) converts to a
Nickname object (Section 2.2.2 of [RFC9553]) in the Card object's
nicknames property (Figure 14). 13). The name property is set to the
NICKNAME property value.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
NICKNAME:Johnny
"nicknames": {
"NICK-1": {
"name": "Johnny"
}
}
Figure 14: 13: NICKNAME conversion example Conversion Example
2.5.7. PHOTO
A
The PHOTO property (Section 6.2.4 of [RFC6350]) converts to an entry a Media
object (Section 2.6.4 of [RFC9553]) in the Card object's media
property (Figure 15). 14). The entry value is a Media object whose object's kind property is set to photo
"photo" and the uri property is set to the PHOTO value.
The PREF and MEDIATYPE parameters convert according to the rules as
defined in Section 2.3.
PHOTO:https://www.example.com/pub/photos/jqpublic.gif
"media": {
"PHOTO-1": {
"kind": "photo",
"uri": "https://www.example.com/pub/photos/jqpublic.gif"
}
}
Figure 15: 14: PHOTO conversion example Conversion Example
2.6. Delivery Addressing Properties
2.6.1. ADR
The ADR property (Section 6.3.1 of [RFC6350]) converts to an Address
object (Section 2.5.1.1 of [RFC9553]) in the Card object's addresses
property. Each component in the ADR ADR-structured property structured value
converts to an AddressComponent in the Address object's components
property.
[I-D.ietf-calext-vcard-jscontact-extensions]
[RFC9554] defines new component components for the ADR property.
Implementations SHOULD set these new components, even if all their
values are the empty string.
The following table shows how the ADR component and AddressComponent
kind relate:
+===========+================+=============================================+
|ADR |AddressComponent|Remarks |
|component |kind
+=============+==================+===============================+
| ADR | AddressComponent | Remarks |
| component | kind | |
+=============+==================+===============================+
|
+===========+================+=============================================+
|post office|postOfficeBox |[RFC6350] post office | postOfficeBox | [RFC6350] recommends that |
| box | | this component not be set, |
| |
|box | |set, but this now is now disputable |
| | | given the new| new components. |
| | | |components. Instead, set this component and |
| | |use | and use the new ADR value |
| | | format defined in [RFC9554]. |
+-------------+------------------+-------------------------------+
| extended | apartment | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+
|extended |apartment (see |To To vCard: Set set the values of |
| address | | the following components:|
|address |Remarks) components: |
| | | |
| |* | | * room |
| | | |
| | |* | * floor |
| | | |
| | |* | * apartment |
| | | |
| | |* | * building |
| | | |
| | |From | From vCard: Ignore ignore if the ADR |
| | | structured value is of the |
| | | format defined in [I-D.ietf-calext-vcard-jscontact-extensions]. Otherwise [RFC9554]. |
| | | Otherwise, convert to apartment.|
+-----------+----------------+---------------------------------------------+
|street |name (see |To |
| | | "apartment". |
+-------------+------------------+-------------------------------+
| street | name | To vCard: Set set the values of |
| address | | the following components:|
|address |Remarks) components: |
| | | |
| |* | | * number |
| | | |
| | |* | * name |
| | | |
| | |* | * block |
| | | |
| | |* | * direction |
| | | |
| | |* | * landmark |
| | | |
| | |* | * subdistrict |
| | | |
| | |* | * district |
| | | |
| | |From | From vCard: Ignore ignore if the ADR |
| | | structured value is of the |
| | | format defined in [I-D.ietf-calext-vcard-jscontact-extensions]. Otherwise [RFC9554]. |
| | | Otherwise, convert to name.|
+-----------+----------------+---------------------------------------------+
|locality |locality "name". |
+-------------+------------------+-------------------------------+
| locality | locality | |
+-------------+------------------+-------------------------------+
|
+-----------+----------------+---------------------------------------------+
|region |region region | region |
+-----------+----------------+---------------------------------------------+
|postal code|postcode |
+-------------+------------------+-------------------------------+
|
+-----------+----------------+---------------------------------------------+
|apartment |apartment |Defined in postal code | postcode | | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+
|block |block |Defined
+-------------+------------------+-------------------------------+
| apartment | apartment | Defined in [RFC9554]. |
+-------------+------------------+-------------------------------+
| block | block | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+
|building |building |Defined Defined in [RFC9554]. |
+-------------+------------------+-------------------------------+
| building | building | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+
|direction |direction |Defined Defined in [RFC9554]. |
+-------------+------------------+-------------------------------+
| direction | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+
|district |district |Defined direction | Defined in [RFC9554]. |
+-------------+------------------+-------------------------------+
| district | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+
|floor |floor |Defined district | Defined in [RFC9554]. |
+-------------+------------------+-------------------------------+
| floor | floor | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+
|landmark |landmark |Defined Defined in [RFC9554]. |
+-------------+------------------+-------------------------------+
| landmark | landmark | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+
|room |room |Defined Defined in [RFC9554]. |
+-------------+------------------+-------------------------------+
| room | room | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+
|street |number |Defined Defined in [RFC9554]. |
+-------------+------------------+-------------------------------+
| street |
|number number | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+
|subdistrict|subdistrict |Defined Defined in [RFC9554]. |
| number | | |
+-------------+------------------+-------------------------------+
| subdistrict | |[I-D.ietf-calext-vcard-jscontact-extensions].|
+-----------+----------------+---------------------------------------------+ subdistrict | Defined in [RFC9554]. |
+-------------+------------------+-------------------------------+
Table 2: ADR components conversion Components Conversion
If the JSCOMPS (Section 3.3.1) parameter is set, then the Address
object's isOrdered property value is "true", and the defaultSeparator
property and any separator name components are set according to the
parameter value. The order in the components list property MUST adhere to
the order of the JSCOMPS parameter value.
If the JSCOMPS parameter is not set, then the Address object's
isOrdered property value is "false" "false", and the defaultSeparator
property MUST NOT be set. The order in the components list property MUST
follow the order of values in the ADR structured value when read from
left to right.
The LABEL parameter converts to the Address object's full
property.
The GEO parameter converts to the Address object's coordinates
property.
The TZ parameter converts to the Address object's timeZone
property.
The CC parameter as defined in [RFC8605] converts to the Address object's countryCode
property.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3. The ADR-specific values of the TYPE parameter
defined in Sections 5.1 and 5.2 of
[I-D.ietf-calext-vcard-jscontact-extensions] [RFC9554] convert to the
corresponding entries of the contexts property as defined in
Section 2.5.1 of [I-D.ietf-calext-jscontact]. [RFC9553].
The ALTID and LANGUAGE parameters convert according to the rules as
defined in Section 2.3. Each possible language-dependent alternative
is represented as
converts to an entry of the PatchObject map where the key references the
full property.
ADR;TYPE=work;CC=US:;;54321
ADR;TYPE=work;CC=US:
;;54321 Oak St;Reston;VA;20190;USA;;;;Oak St;54321;;;;; St;Reston;VA;20190;USA;;;;54321;Oak St;;;;;;
"addresses": {
"ADDR-1" : {
"contexts": { "work": true },
"components": [
{ "kind": "number", "value": "54321" },
{ "kind": "name", "value": "Oak St" },
{ "kind": "locality", "value": "Reston" },
{ "kind": "region", "value": "VA" },
{ "kind": "postcode", "value": "20190" },
{ "kind": "country", "value": "USA" }
],
"countryCode": "US", "US"
}
}
Figure 16: 15: ADR conversion example Conversion Example
See Section 3.3.1 for examples of using the JSCOMPS parameter for
vCard structured
vCard-structured property values.
2.7. Communications Properties
2.7.1. EMAIL
An
The EMAIL property (Section 6.4.2 of [RFC6350]) converts to an entry
EmailAddress object (Section 2.3.1 of [RFC9553]) in the Card object's
emails property (Figure 17). 16). The entry value is an EmailAddress object. The object's address
property is set to the EMAIL value.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
EMAIL;TYPE=work:jqpublic@xyz.example.com
EMAIL;PREF=1:jane_doe@example.com
"emails": {
"EMAIL-1": {
"contexts": { "work": true },
"address": "jqpublic@xyz.example.com"
},
"EMAIL-2": {
"address": "jane_doe@example.com",
"pref": 1
}
}
Figure 17: 16: EMAIL conversion example Conversion Example
2.7.2. IMPP
An
The IMPP property (Section 6.4.3 of [RFC6350]) converts to an entry
OnlineService object (Section 2.3.2 of [RFC9553]) in the Card
object's onlineServices property (Figure 18). The entry value is an OnlineService object. 17). The vCardName property
is set to "impp" "impp", and the uri property is set to the IMPP value.
The SERVICE-TYPE, USERNAME, PREF PREF, and TYPE parameters convert
according to the rules as defined in Section 2.3.
IMPP;PREF=1:xmpp:alice@example.com
"onlineServices": {
"OS-1": {
"uri": "xmpp:alice@example.com",
"pref": 1,
"vCardName": "impp"
}
}
Figure 18: 17: IMPP conversion example Conversion Example
2.7.3. LANG
A
The LANG property (Section 6.4.4 of [RFC6350]) converts to an entry a
LanguagePref object (Section 2.3.4 of [RFC9553]) in the Card object's
preferredLanguages property (Figure 19). The entry value is an LanguagePref object. 18). The LanguagePref language LANG property value is
converts to the LANG LanguagePref object's language property value.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
LANG;TYPE=work;PREF=1:en
LANG;TYPE=work;PREF=2:fr
LANG;TYPE=home:fr
"preferredLanguages": {
"LANG-1": {
"language": "en",
"contexts": { "work": true },
"pref": 1
},
"LANG-2": {
"language": "fr",
"contexts": { "work": true },
"pref": 2
},
"LANG-3": {
"language": "fr",
"contexts": { "private": true }
}
}
Figure 19: 18: LANG conversion example Conversion Example
2.7.4. LANGUAGE
The LANGUAGE property (Section 3.3 of [RFC9554]) converts to the Card
object's language property (Figure 20). 19).
LANGUAGE:de-AT
"language": "de-AT"
Figure 20: 19: LANGUAGE conversion example
Note: This property is defined in
[I-D.ietf-calext-vcard-jscontact-extensions]. Conversion Example
2.7.5. SOCIALPROFILE
A
The SOCIALPROFILE property (Section 3.5 of [RFC9554]) converts to an entry
OnlineService object (Section 2.3.2 of [RFC9553]) in the Card
object's onlineServices property (Figure 21). The entry value is an OnlineService object. 20). The vCardName property
is set to "socialprofile" "socialprofile", or it can be omitted. If the value type of the
SOCIALPROFILE property value is of type URI, then the OnlineService
object's uri property is
set to the SOCIALPROFILE value. Otherwise, set; otherwise, the user property is set
to the SOCIALPROFILE value. set.
The SERVICE-TYPE, USERNAME, PREF PREF, and TYPE parameters convert
according to the rules as defined in Section 2.3.
SOCIALPROFILE;SERVICE-TYPE=Mastodon:https://example.com/@foo
"onlineServices": {
...
"OS-1": {
"service": "Mastodon",
"uri": "https://example.com/@foo"
}
}
Figure 21: 20: SOCIALPROFILE conversion example
Note: This property is defined in
[I-D.ietf-calext-vcard-jscontact-extensions]. Conversion Example
2.7.6. TEL
A
The TEL property (Section 6.4.1 of [RFC6350]) converts to an entry a Phone
object (Section 2.3.3 of [RFC9553]) in the Card object's phones
property (Figure 22). The entry value is a Phone object. 21).
The TEL-specific values of the TYPE parameter convert to the features
property keys as outlined in table Table 3. Note that Section 6.4.1 of
[RFC6350] defines the default TYPE of TEL type to be voice, "voice", but the default
Phone features property is absent by default. Accordingly, an
implementation SHOULD only set the Phone object's features property
if the TEL property actually has a TEL-specific TYPE parameter set.
+=============+===============+
| TYPE value | Phone feature |
+=============+===============+
| cell | mobile |
+-------------+---------------+
| fax | fax |
+-------------+---------------+
| main-number | main-number |
+-------------+---------------+
| pager | pager |
+-------------+---------------+
| text | text |
+-------------+---------------+
| textphone | textphone |
+-------------+---------------+
| video | video |
+-------------+---------------+
| voice | voice |
+-------------+---------------+
Table 3: TEL TYPE conversion Conversion
The value of the TEL property converts to the Phone object's number
property.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555
TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67
"phones": {
"PHONE-1": {
"contexts": { "private": true },
"features": { "voice": true },
"number": "tel:+1-555-555-5555;ext=5555",
"pref": 1
},
"PHONE-2": {
"contexts": { "private": true },
"number": "tel:+33-01-23-45-67"
}
}
Figure 22: 21: TEL conversion example Conversion Example
2.8. Geographical Properties
2.8.1. GEO
This
The GEO property (Section 6.5.2 of [RFC6350]) converts to the Address
object's coordinates property (Section 2.5.1 of the Address object. [RFC9553]). Also see
Section 2.8.3 to determine which Address object instance to convert
to.
2.8.2. TZ
The TZ property (Section 6.5.1 of [RFC6350]) converts an Address
object (Section 2.5.1 of [RFC9553]) in the Card object's addresses
property.
A value of type TEXT converts to the timeZone property in the Address
object. object's timeZone
property.
A value of type UTC-OFFSET converts to the Address object's timeZone
property in the
Address object if the offset has zero minutes and the hour offset is
in the range
between -12 <= 14: and +14, both inclusively. Note that:
* If the hour offset is zero, use the time zone name Etc/UTC. "Etc/UTC".
* Otherwise Otherwise, construct the time zone name with Etc/GMT "Etc/GMT" suffixed
with the string representation of the reversed sign hour offset,
including the sign but excluding leading zeros and minutes. For
example, the UTC offset value -0500 "-0500" converts to Etc/GMT+5. "Etc/GMT+5".
For such property values, also see Section 2.8.3 to determine which
Address object instance to convert to.
Any other value of type UTC-OFFSET or URI does not convert to an
IANA-registered property in JSContact. To convert such property, see
Section 2.15.1.
2.8.3. Combining geographical properties Geographical Properties
In vCard vCard, the properties ADR, GEO GEO, and TZ occur independently of each
other. In JSContact, they all convert to properties of an Address
object. It is implementation-specific if these vCard properties
convert to _separate_ address instances in JSContact, JSContact or if some or
all of them convert to the _same_ address. That being said,
implementations MUST convert the properties to the _same_ address for
the following cases:
* The GROUP parameter values of the properties match.
* The GROUP parameters are not set, but they are set on any other
ADR,
GEO GEO, and TZ properties.
2.9. Organizational Properties
2.9.1. CONTACT-URI
A
The CONTACT-URI property as defined in [RFC8605] is represented as an
entry (Section 2.1 of [RFC8605]) converts to a
Link object (Section 2.6.3 of [RFC9553]) in the Card object's links
property (Figure 23). 22). The entry value is a Link
object whose object's kind property is set to contact
"contact" and the uri property is set to the CONTACT-URI property
value.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
CONTACT-URI;PREF=1:mailto:contact@example.com
"links": {
"CONTACT-1": {
"kind": "contact",
"uri": "mailto:contact@example.com",
"pref": 1
}
}
Figure 23: 22: CONTACT-URI conversion example Conversion Example
2.9.2. LOGO
A
The LOGO property (Section 6.6.3 of [RFC6350]) converts to an entry a Media
object (Section 2.6.4 of [RFC9553]) in the Card object's media
property (Figure 24). 23). The entry value is a Media object whose object's kind property is set to logo
"logo" and the uri property is set to the LOGO property value.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
LOGO:https://www.example.com/pub/logos/abccorp.jpg
"media": {
"LOGO-1": {
"kind": "logo",
"uri": "https://www.example.com/pub/logos/abccorp.jpg"
}
}
Figure 24: 23: LOGO conversion example Conversion Example
2.9.3. MEMBER
The uids MEMBER property (Section 6.6.5 of [RFC6350]) converts to the contact cards composing the group are included in the Card
object's members property (Figure 25).
In this case, 24). Each MEMBER property value is
a key in the members property. The PREF parameter (Section 5.3 of
[RFC6350]) does not have a JSContact
counterpart; however, the implementors MAY insert the map entries by
order of preference. convert to JSContact.
KIND:group
FN:The Doe family
MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
"kind": "group",
"name": {
"full": "The Doe family"
},
"uid": "urn:uuid:ab4310aa-fa43-11e9-8f0b-362b9e155667",
"members": {
"urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af": true,
"urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519": true
}
Figure 25: 24: Group example Example
2.9.4. ORG
An
The ORG property (Section 6.6.4 of [RFC6350]) converts to an entry
Organization object (Section 2.2.3 of [RFC9553]) in the Card object's
organizations property (Figure 26). 25). The entry value is an Organization object whose object's name
property contains is set to the ORG property organizational name, and the name component.
The Organization object's units property is an array of OrgUnit
objects that each containing the contain an organizational unit name in component value
of the name property. ORG property value.
Implementations MAY allow representation of organizational units
without the organizational name. In this case, the first component
of the ORG value MUST be an empty string (e.g., ORG:;DepartmentA).
The ALTID, ALTID and LANGUAGE parameters convert according to the rules as
defined in Section 2.3.
The first item of the comma-separated SORT-AS parameter value
converts to the sortAs property of the Organization object. The
subsequent items convert to the sortAs property of the corresponding
OrgUnit object.
The TYPE parameter converts according to the rules as defined in
Section 2.3.
ORG;SORT-AS="ABC":ABC\, Inc.;North American Division;Marketing
"organizations": {
"ORG-1": {
"name": "ABC, Inc.",
"units":[
{ "name": "North American Division" },
{ "name": "Marketing" }
],
"sortAs": "ABC"
}
}
Figure 26: 25: ORG conversion example Conversion Example
2.9.5. RELATED
This
The RELATED property (Section 6.6.6 of [RFC6350]) converts to an entry in the
Card object's relatedTo property (Figure 27). 26). The property value
converts to the key in the relatedTo property. The TYPE parameters
convert to the Relation object's relation property (Section 2.1.8 of the Relation object value.
[RFC9553]). Any other parameters convert as defined in
Section 2.15.2.
RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
RELATED;TYPE=contact:https://example.com/directory/john.vcf
RELATED;VALUE=text:Please contact my deputy John for any inquiries.
"relatedTo" : {
"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" : {
"relation" : {
"friend" : true
}
},
"https://example.com/directory/john.vcf" : {
"relation" : {
"contact" : true
}
},
"Please contact my deputy John for any inquiries." : {
"relation" : { }
}
}
Figure 27: 26: RELATED conversion example Conversion Example
2.9.6. TITLE and ROLE
Both
The TITLE (Section 6.6.1 of [RFC6350]) and ROLE (Section 6.6.2 of
[RFC6350]) properties are represented as entries convert to a Title object (Section 2.2.5 of
[RFC9553]) in the Card object's titles property (Figure 28). 27). The entry value is a
Title object whose object's kind property is set to title "title" or role "role" for the
TITLE and ROLE vCard properties, respectively. The name property is
set to the vCard property value.
The value of the organization organizationId property can be derived if the TITLE
or ROLE property is a member of a vCard property group and if exactly
one other ORG property also is also a part of that group.
The ALTID and LANGUAGE parameters convert according to the rules as
defined in Section 2.3.
TITLE:Research Scientist
group1.ROLE:Project Leader
group1.ORG:ABC, Inc.
"titles": {
"TITLE-1": {
"kind": "title",
"name": "Project Leader" "Research Scientist"
},
"TITLE-2": {
"kind": "role",
"name": "Research Scientist",
"organization": "Project Leader",
"organizationId": "ORG-1"
}
},
"organizations": {
"ORG-1": {
"name": "ABC, Inc."
}
}
Figure 28: 27: TITLE and ROLE conversion example Conversion Example
2.10. Personal Information Properties
2.10.1. EXPERTISE
An
The EXPERTISE property as defined in [RFC6715] is represented as (Section 2.1 of [RFC6715]) converts to a
PersonalInfo object (Section 2.8.4 of [RFC9553]) in the Card object's
personalInfo property (Figure 29). 28). The PersonalInfo object's kind
property is set to "expertise".
The INDEX parameter converts and LEVEL parameters convert according to the rules as defined
in Section 2.3.
EXPERTISE;LEVEL=beginner;INDEX=2:Chinese literature
EXPERTISE;INDEX=1;LEVEL=expert:chemistry
"personalInfo": {
"PERSINFO-1" : {
"kind": "expertise",
"value": "Chinese literature",
"level": "low",
"listAs": 2
},
"PERSINFO-2" : {
"kind": "expertise",
"value": "chemistry",
"level": "high",
"listAs": 1
}
}
Figure 29: 28: EXPERTISE conversion example Conversion Example
2.10.2. HOBBY
A
The HOBBY property as defined in [RFC6715] is represented as (Section 2.2 of [RFC6715]) converts to a
PersonalInfo object (Section 2.8.4 of [RFC9553]) in the Card object's
personalInfo property (Figure 30). 29). The PersonalInfo object's kind
property is set to "hobby".
The INDEX parameter converts and LEVEL parameters convert according to the rules as defined
in Section 2.3.
HOBBY;INDEX=1;LEVEL=high:reading
HOBBY;INDEX=2;LEVEL=high:sewing
"personalInfo": {
"PERSINFO-1" : {
"kind": "hobby",
"value": "reading",
"level": "high",
"listAs": 1
},
"PERSINFO-2" : {
"kind": "hobby",
"value": "sewing",
"level": "high",
"listAs": 2
}
}
Figure 30: 29: HOBBY conversion example Conversion Example
2.10.3. INTEREST
An
The INTEREST property as defined in [RFC6715] is represented as (Section 2.3 of [RFC6715]) converts to a
PersonalInfo object (Section 2.8.4 of [RFC9553]) in the Card object's
personalInfo property (Figure 31). 30). The PersonalInfo object's kind
property is set to "interest".
The INDEX parameter converts and LEVEL parameters convert according to the rules as defined
in Section 2.3.
INTEREST;INDEX=1;LEVEL=medium:r&b music
INTEREST;INDEX=2;LEVEL=high:rock&roll music
"personalInfo": {
"PERSINFO-1" : {
"kind": "interest",
"value": "r&b music",
"level": "medium",
"listAs": 1
},
"PERSINFO-2" : {
"kind": "interest",
"value": "rock&roll music",
"level": "high",
"listAs": 2
}
}
Figure 31: 30: INTEREST conversion example Conversion Example
2.10.4. ORG-DIRECTORY
The ORG-DIRECTORY property (Section 2.4 of [RFC6715]) [RFC6715]
converts to a Directory object (Section 2.6.2 of [RFC9553]) in the
Card object's directories property (Figure 32). 31). The Directory
object's kind property is set to
directory. "directory". The uri property is
set to the ORG-DIRECTORY property value.
The INDEX, PREF PREF, and TYPE parameters convert according to the rules as
defined in Section 2.3.
ORG-DIRECTORY;INDEX=1:https://directory.mycompany.example.com
ORG-DIRECTORY;PREF=1:ldap://ldap.tech.example/o=Tech,ou=Engineering
"directories": {
"DIRECTORY-1": {
"kind": "directory",
"uri": "https://directory.mycompany.example.com",
"listAs": 1
},
"DIRECTORY-2": {
"kind": "directory",
"uri": "ldap://ldap.tech.example/o=Tech,ou=Engineering",
"pref": 1
}
}
Figure 32: 31: ORG-DIRECTORY conversion example Conversion Example
2.11. Explanatory Properties
2.11.1. CATEGORIES
A
The CATEGORIES property (Section 6.7.1 of [RFC6350]) converts to a
set of entries of the Card object's keywords property (Figure 33). 32).
The keys are the comma-separated text values of the CATEGORIES
property.
In this case, the PREF parameter does not have a JSContact
counterpart; however, the implementors MAY insert the map entries by
order of preference.
CATEGORIES:internet,IETF,Industry,Information Technology
"keywords": {
"internet": true,
"IETF": true,
"Industry": true,
"Information Technology": true
}
Figure 33: 32: CATEGORIES conversion example Conversion Example
2.11.2. CLIENTPIDMAP and PID Parameter
These convert
The CLIENTPIDMAP property (Section 6.7.7 of [RFC6350]) converts to
the vCardProps (Section 2.15.1) and vCardParams
(Section 2.15.2) properties. property.
2.11.3. CREATED
The CREATED property (Section 3.1 of [RFC9554]) converts to the Card
object's created property (Figure 34). 33).
CREATED:19940930T143510Z
"created": "1994-09-30T14:35:10Z"
Figure 34: 33: CREATED conversion example
Note: This property is defined in
[I-D.ietf-calext-vcard-jscontact-extensions]. Conversion Example
2.11.4. NOTE
A
The NOTE property (Section 6.7.2 of [RFC6350]) converts to a Note
object (Section 2.8.3 of [RFC9553]) in the Card object's notes map
property (Figure 35). 34).
The ALTID and LANGUAGE parameters convert according to the rules as
defined in Section 2.3.
NOTE;CREATED=20221123T150132Z;AUTHOR-NAME="John":
Office hours are from 0800 to 1715 EST\, Mon-Fri.
"notes": {
"NOTE-1" : {
"note": "Office hours are from 0800 to 1715 EST, Mon-Fri.",
"created": "2022-11-23T15:01:32Z",
"author": {
"name": "John"
}
}
}
Figure 35: 34: NOTE conversion example Conversion Example
2.11.5. PRODID
The PRODID property (Section 6.7.3 of [RFC6350]) converts to the Card
object's prodId property (Figure 36). 35).
PRODID:ACME Contacts App version 1.23.5
"prodId": "ACME Contacts App version 1.23.5"
Figure 36: 35: PRODID conversion example Conversion Example
2.11.6. REV
The REV property (Section 6.7.4 of [RFC6350]) converts to the Card
object's updated property (Figure 37). 36).
REV:19951031T222710Z
"updated": "1995-10-31T22:27:10Z"
Figure 37: 36: REV conversion example Conversion Example
2.11.7. SOUND
A
The SOUND property (Section 6.7.5 of [RFC6350]) converts to an entry a Media
object (Section 2.6.4 of [RFC9553]) in the Card object's media
property (Figure 38). 37). The entry value is a Media object whose object's kind property is set to sound
"sound" and the uri property is set to the SOUND value.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
SOUND:CID:JOHNQPUBLIC.19960229T080000.xyzMail@example.com
"media": {
...
"SOUND-1": {
"kind": "sound",
"uri": "CID:JOHNQPUBLIC.19960229T080000.xyzMail@example.com"
}
}
Figure 38: 37: SOUND conversion example Conversion Example
2.11.8. UID
The UID property corresponds (Section 6.7.6 of [RFC6350]) converts to the Card
object's uid property (Figure 39). 38).
UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
"uid": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
Figure 39: 38: UID conversion example Conversion Example
2.11.9. URL
A
The URL property (Section 6.7.8 of [RFC6350]) converts to an entry a Link
object (Section 2.6.3 of [RFC9553]) in the Card object's links
property (Figure 40). 39). The entry value is a Link object whose object's uri property is set to the
URL value.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
URL:https://example.org/restaurant.french/~chezchic.html
"links": {
"LINK-1": {
"uri": "https://example.org/restaurant.french/~chezchic.html"
}
}
Figure 40: 39: URL conversion example Conversion Example
2.11.10. VERSION
This
The VERSION property (Section 6.7.9 of [RFC6350]) converts to an entry in the
vCardProps (Section 2.15.1) property.
2.11.11. X-ABLabel
This
The X-ABLabel property is experimental but widely in use in existing
vCard data. It converts to the label property of a JSContact object type. object.
The X-ABLabel property is preceded by a vCard property group name,
and the label converts to the JSContact object object, which got was converted
from a vCard property having of the same group.
The group name is not preserved, preserved; implementations are free to choose
any unique group name when converting back to vCard. For an example
on how to preserve the group name name, see Section 2.3.8. 2.3.9.
item1.TEL;VALUE=uri:tel:+1-555-555-5555
item1.X-ABLabel:foo
"phones": {
"p1": {
"number": "tel:+1-555-555-5555",
"label": "foo"
}
}
Figure 41: 40: X-ABLabel conversion example Conversion Example
2.12. Security Properties
2.12.1. KEY
A
The KEY property (Section 6.8.1 of [RFC6350]) converts to an entry a CryptoKey
object (Section 2.6.1 of [RFC9553]) in the Card object's cryptoKeys
property (Figure 42). 41). The entry value is a CryptoKey object whose object's uri property is set to
the KEY property value.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
KEY:https://www.example.com/keys/jdoe.cer
"cryptoKeys": {
"KEY-1": {
"uri": "https://www.example.com/keys/jdoe.cer"
}
}
Figure 42: 41: KEY conversion example Conversion Example
2.13. Calendar Properties
2.13.1. CALADRURI
A
The CALADRURI property (Section 6.9.2 of [RFC6350]) converts to an entry a
SchedulingAddress object (Section 2.4.2 of [RFC9553]) in the Card
object's schedulingAddresses property (Figure 43). 42). The entry value is a
SchedulingAddress object
whose object's uri property is set to the CALADRURI
value.
The PREF parameter (Section 5.3 of [RFC6350]) converts according to
the rules as defined in Section 2.3.
CALADRURI;PREF=1:mailto:janedoe@example.com
CALADRURI:https://example.com/calendar/jdoe
"schedulingAddresses": {
"SCHEDULING-1": {
"uri": "mailto:janedoe@example.com",
"pref": 1
},
"SCHEDULING-2": {
"uri": "https://example.com/calendar/jdoe"
}
}
Figure 43: 42: CALADRURI conversion example Conversion Example
2.13.2. CALURI
A
The CALURI property (Section 6.9.3 of [RFC6350]) converts to an entry a
Calendar object (Section 2.4.1 of [RFC9553]) in the Card object's
calendars property (Figure 44). 43). The entry value is a Calendar object whose object's kind property
is set to calendar "calendar" and the uri property is set to the CALURI value.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
CALURI;PREF=1:https://cal.example.com/calA
CALURI;MEDIATYPE=text/calendar:https://ftp.example.com/calA.ics
"calendars": {
"CAL-1": {
"kind": "calendar",
"uri": "https://cal.example.com/calA",
"pref": 1
},
"CAL-2": {
"kind": "calendar",
"uri": "https://ftp.example.com/calA.ics",
"mediaType": "text/calendar"
}
}
Figure 44: 43: CALURI conversion example Conversion Example
2.13.3. FBURL
An
The FBURL property (Section 6.9.1 of [RFC6350]) converts to an entry a
Calendar object (Section 2.4.1 of [RFC9553]) in the Card object's
calendars property (Figure 45). 44). The entry value is a Calendar object whose object's kind property
is set to freeBusy "freeBusy" and the uri property is set to the FBURL value.
The PREF and TYPE parameters convert according to the rules as defined
in Section 2.3.
FBURL;PREF=1:https://www.example.com/busy/janedoe
FBURL;MEDIATYPE=text/calendar:https://example.com/busy/project-a.ifb
"calendars": {
"FBURL-1": {
"kind": "freeBusy",
"uri": "https://www.example.com/busy/janedoe",
"pref": 1
},
"FBURL-2": {
"kind": "freeBusy",
"uri": "https://example.com/busy/project-a.ifb",
"mediaType": "text/calendar"
}
}
Figure 45: 44: FBURL conversion example Conversion Example
2.14. Extended Properties and Parameters
These
Extended properties and parameters convert as specified in
Section 2.15.
2.15. New JSContact properties Properties
vCards may contain properties or parameters for which no IANA-
registered JSContact property is defined. For example, a vCard may
contain properties and parameters of which the semantics or purposes
are unknown to the implementation; see Section 6.10 of [RFC6350].
This section defines JSContact properties by which such vCard
properties and parameters MAY be represented in JSContact.
Implementations MAY choose to convert differently if they deem that
more appropriate.
2.15.1. Property vCardProps
Name: vCardProps
Type: JCardProp[], where JCardProp denotes a jCard-encoded
vCardProps: JCardProp[] (optional). Contains vCard
property as defined in Section 3.3 of [RFC7095].
Definition: This property is set on a JSContact object that
represents a vCard. It contains properties that
are set in the vCard represented by this JSContact object. Each entry in this
list typically represents The
JCardProp type denotes a jCard-encoded vCard property for which no conversion
to an IANA-registered JSContact property is defined. as defined
in Section 3.3 of [RFC7095].
Example: This illustrates how to convert a vCard extension property:
item1.X-FOO;X-BAR=Hello:World!
"vCardProps": [
["x-foo", {
"x-bar": "Hello",
"group": "item1"
}, "unknown", "World!"]
]
Figure 46: 45: JSContact vCardProps example Example
2.15.2. Property vCardParams
Name: vCardParams
Type:
vCardParams: String[String|String[]]
Definition: This property is (optional). Contains vCard
parameters that are set on a JSContact object that
represents a the vCard property. Its property represented by this
JSContact object. The value MUST be a JSON object containing
vCard property parameters, defined parameters as array element 2 defined in Section 3.3 of [RFC7095].
Each entry represents a parameter of the vCard property that
converts to the JSContact object.
Example: This illustrates how to convert a vCard extension
parameter:
EMAIL;X-FOO=Bar:jane_doe@example.com
"emails": {
"email1": {
"address": "jane_doe@example.com",
"vCardParams": {
"x-foo": "Bar"
}
}
}
Figure 47: 46: JSContact vCardParams example Example
2.15.3. Property vCardName
Name: vCardName
Type:
vCardName: String
Definition: This property is set on a JSContact object that
represents a vCard property or parameter and its value contains (optional). Contains the name of that the vCard element. This element
that is represented by this JSContact object. For example, this
allows to preserve the name of a vCard element property when multiple elements
vCard properties convert the same JSContact object type. The case-insensitive case-
insensitive value MUST be valid according to the name "name" ABNF
defined in Section 3.3 of [RFC6350].
Example: Both vCard IMPP and SOCIALPROFILE convert to an
OnlineService object (Section 2.3.2 of [RFC9553]) in JSContact.
The vCardName property value indicates that the vCard source
element was IMPP: IMPP as follows:
IMPP:xmpp:alice@example.com
"onlineServices": {
"os1": {
"uri": "xmpp:alice@example.com",
"vCardName": "impp"
},
}
Figure 48: 47: JSContact vCardName example Example
3. Converting JSContact to vCard
3.1. Conversion Rules
A Card object converts to vCard by applying the reverse rules of
converting vCard to JSContact. In addition to those listed in
Appendix A, the following rules apply:
* Multivalued JSContact properties convert to separate instances of
their equivalent vCard property, and for each of the PROP-ID
parameter
parameters MUST be set to the Id Id-typed key of the converted value
(see Section 2.3.16). 2.3.18).
* The full property of the name property in JSContact is optional,
but the FN property is mandatory in vCard. The following rules
apply:
- If the Name object's full property is set, then implementations
MUST use its value for the vCard FN property.
- If the Name object's full property is not set, then
implementations SHOULD derive the full name from the Name
object's components property values. If the isOrdered property
is true, "true", then this can be done by concatenating the name
component values. Otherwise, or alternatively, an
implementation can choose any other heuristic to generate the
full name from its components, components such as [CLDRPersonName].
Implementations MUST set the DERIVED parameter on the FN
property.
- Otherwise, they MUST set the FN property MUST be set to the empty value.
* Vendor-specific and unknown properties convert to vCard as
outlined in Section 3.1.1.
3.1.1. Converting unknown properties Unknown Properties
JSContact object types objects may contain properties for which no IANA-
registered IANA-registered
vCard property is defined. For example, a JSContact object may
contain vendor-specific properties of which the semantics or purpose
are unknown.
This specification defines the new JSPROP (Section 3.2.1) vCard
property and JSPTR (Section 3.3.2) vCard parameter by which such
JSContact properties MAY be represented in vCard. Implementations
MAY choose to convert differently if they deem that more appropriate.
3.2. New vCard Properties
3.2.1. JSPROP
Property name: JSPROP
Purpose: This property represents Represents a JSContact property in vCard.
Value type: TEXT, TEXT; also see Format Definition "Format definition" below for value
restrictions.
Conformance: The property can Can be specified multiple times in a vCard.
Property parameters: The JSPTR parameter MUST be set for this
property. Other IANA-registered and experimental property
parameters can be specified on this property.
Description: This property converts an arbitrary JSContact property
from and to vCard. The vCard property value is the JSON-encoded
value of the JSContact property, represented as a TEXT value. The
format of the JSON value MUST be compact, e.g., without
insignificant whitespace. whitespace as defined in Section 2 of [RFC8259].
The value of the JSPTR parameter points to the JSContact property
within the Card.
The root of the JSON pointer is always the Card object that this
vCard converts to, irrespective if the JSON pointer starts with
the SOLIDUS (U+002F) character. The pointer MUST NOT reference
into an array.
All JSPROP properties in a vCard together form a PatchObject as
defined in [I-D.ietf-calext-jscontact]. [RFC9553]. The value of its JSPTR parameter
corresponds to a key in the PatchObject, PatchObject; the value of the JSPROP
property corresponds to the value for that key. When converting
from vCard to JSContact, the PatchObject MUST only be applied
after all other vCard properties have already been converted. The
PatchObject MUST be valid, including the restriction that an
invalid PatchObject MUST NOT be applied.
Format definition: This property is defined by the following
notation:
jsprop = "JSPROP" jsprop-param ":" TEXT
jsprop-param = *(
; The following are MANDATORY and MUST NOT
; occur more than once
( ";" jsptr-param ) / ; see next section
( ";" "VALUE" "=" "TEXT")
;
; The following is OPTIONAL, OPTIONAL
; and MAY occur more than once.
;
(";" other-param)
;
)
Example(s): This illustrates how to convert a property at the top- top
level in a Card object that is unknown to the implementation.
"someUnknownProperty": true
JSPROP;JSPTR="someUnknownProperty":true
Figure 49: 48: Unknown property example Property Example
This illustrates how to convert a vendor-specific property at the
top-level
top level of a Card object. Note the required use of quoted
string for the JSPTR value value, which allows the path to include the
COLON (U+003A) character.
"example.com:foo": {
"bar": 1234
}
JSPROP;JSPTR="example.com:foo":{"bar":1234}
Figure 50: Vendor-specific property conversion example 49: Vendor-Specific Property Conversion Example
This illustrates how to convert a vendor-specific property at a
nested level in a Card object using a path relative to the Card
object. Although not recommended, the property name includes the
SOLIDUS (U+002F) character character, which requires escaping in the JSON
pointer.
"phones": {
"phone1": {
"number": "tel:+33-01-23-45-67" "tel:+33-01-23-45-67",
"example.com:foo/bar": "tux hux"
}
}
TEL:tel:+33-01-23-45-67
JSPROP;JSPTR="phones/phone1/example.com:foo~1bar":
"tux hux"
Figure 51: 50: Nested vendor-specific property example Vendor-Specific Property Example with path
relative a Path
Relative to Card
3.3. New vCard Parameter Parameters
3.3.1. JSCOMPS
Parameter name: JSCOMPS
Purpose: This parameter defines Defines the order and separators for the elements of a
structured property value.
Description: The JSCOMPS parameter value facilitates converting name
and address components between JSContact and vCard. It preserves
the order of the components of the JSContact property and contains
the verbatim values of separator components.
If this parameter is set and its value is valid (see later), then
implementations MUST set the isOrdered property of the Name or
Address object to "true". Otherwise, they MUST set the isOrdered
property value to "false".
The JSCOMPS parameter value is a structured type value. Its value
MUST be quoted. The parameter value consists of a sequence of
entries, separated by the SEMICOLON character (U+003B). The first
entry defines the value of the defaultSeparator property. If it
is the empty string string, then no default separator is defined.
Otherwise, the first entry MUST be a separator entry. All
following entries processed in order result in an ordered list of
JSContact components, components and MUST be one of two the following two kinds:
1. A positional. This refers to a component value in the vCard
structured value value. A position consists of the numeric index of
a component in the structured value, optionally followed by a
COMMA (U+002C) character and the non-zero index of a value
within that component. The zero index selects the first
component or value, respectively. The second index by default is zero, zero by
default, in which case it MUST be omitted (as well as the
leading COMMA).
The resulting JSContact component is formed by determining its
kind by the position in the vCard structured value. The
component value is the verbatim value of the vCard component.
Figure 52
Figures 51 and Figure 53 52 illustrate this by example.
2. A separator. This contains the verbatim value of a separator
component. It starts with the LATIN SMALL LETTER S (U+0073)
character, followed by the COMMA (U+002C), (U+002C) character, followed
by zero or more "param-value" characters (see Section 3.3 of param-value [RFC6350] characters,
[RFC6350]), where the COMMA (U+002c) (U+002C) and SEMICOLON (U+003B) character
characters MUST be escaped according to the rules defined in
Section 3.4 of [RFC6350]. Figure 54 53 illustrates this by
example.
The resulting JSContact component is formed by setting its
kind to separator "separator" and its value to the verbatim value of the
entry.
A JSCOMPS parameter value is valid if and only if:
* All indexes in the positional entries refer to an existing
component value in the vCard property value.
* The count of positional entries equals the count of
deduplicated component values. Deduplication is required
because some values may occur in both their designated and
backwards-compatible components in the vCard property value:
- A value that occurs in both the N property secondary surname
component and the family name component only counts once.
- A value that occurs in both the N property generation
component and the honorific suffix component only counts
once.
- A value in the ADR property street address component does
not count if the ADR property value contains a value in one
of the new components defined in
[I-D.ietf-calext-vcard-jscontact-extensions]. [RFC9554].
- All other values count once each.
Format definition:
jscomps-param = "JSCOMPS" "=" DQUOTE (
(jscomps-entry-sep / "") [jscomps-entry-sep ] ";"
jscomps-entrylist
) DQUOTE
jscomps-entrylist = jscomps-entry *(";" jscomps-entry)
jscomps-entry = jscomps-entry-pos / jscomps-entry-sep
jscomps-entry-pos = 1*DIGIT [ "," 1*DIGIT ]
jscomps-entry-sep = "s" "," jscomps-entry-verb
jscomps-entry-verb = *QSAFE-CHAR ; encode according to RFC 6868
Example(s): The following example demonstrates the use of positional
entries for the name "Jane Doe". The given name is ordered before
the surname. No secondary index is required for either positional
because both are zero.
"name": {
"components": [
{ "kind": "given", "value": "Jane" },
{ "kind": "surname", "value": "Doe" }
],
"isOrdered": true
}
N;JSCOMPS=";1;0":Doe;Jane;;;;;;
FN;DERIVED=TRUE:Jane Doe
Figure 52: 51: Example for positional entries of a Secondary Positional Index
The following example demonstrates a secondary positional index.
The "Jr." generation marker only counts once because it occurs in
both the designated generation component and the backwards-
compatible honorific suffixes component.
"name": {
"components": [
{ "kind": "given", "value": "John" },
{ "kind": "given2", "value": "Philip" },
{ "kind": "given2", "value": "Paul" },
{ "kind": "surname", "value": "Stevenson" },
{ "kind": "generation", "value": "Jr." },
{ "kind": "credential", "value": "M.D." }
],
"isOrdered": true
}
N;JSCOMPS=";1;2;2,1;0;6;4,1":Stevenson;John;Philip,Paul;;Jr.,M.D.;;Jr.
N;JSCOMPS=";1;2;2,1;0;6;4,1":
Stevenson;John;Philip,Paul;;Jr.,M.D.;;Jr.
Figure 53: 52: Example for positional entries of Positional Entries
The following example demonstrates the use of separator entries
for the (shortened for brevity) address "54321 Oak St, Reston".
The first entry defines the default separator to be ", ". The
second and fourth positional entries are separated with the
separator value " ". For backwards-compatibility, backwards compatibility, the street
address component of the ADR property contains both the street
number and name, but it is not referred to in the JSCOMPS
parameter and does not contribute to the count of values.
"addresses": {
"a1": {
"components": [
{ "kind": "number", "value": "54321" },
{ "kind": "separator", "value": " " },
{ "kind": "name", "value": "Oak St" },
{ "kind": "locality", "value": "Reston" }
],
"defaultSeparator": ", ",
"isOrdered": true
}
}
ADR;JSCOMPS="s,\, ;11;s, ;10;3":;;54321 ;10;3":
;;54321 Oak St;Reston;;;;;;;Oak St;54321;;;;;;
Figure 54: 53: Example for separator entries of Separator Entries
3.3.2. JSPTR
Parameter name: JSPTR
Purpose: This parameter contains is set on a JSPROP (Section 3.2.1) property.
Its value is a JSON pointer [RFC6901] that
relates the vCard JSPROP (Section 3.2.1) property points to a the JSContact
property that has the value of the JSPROP property.
Description: This parameter has a single value that MUST be a valid
JSON pointer as defined in [RFC6901]. Note that the value MUST be
quoted according to the param-value "param-value" ABNF in [RFC6350].
Format definition:
jsptr-param = "JSPTR" "=" param-value
; also see param-value in RFC 6350, section Section 3.3
Example(s): This illustrates a simple example. For further examples
examples, see Section 3.2.1.
JSPROP;JSPTR="example.com:foo":"bar"
4. Security Considerations
This specification defines how to convert between the JSContact and
vCard formats. The security considerations for parsing and
formatting such data apply and are outlined in Section 5 4 of
[I-D.ietf-calext-jscontact] [RFC9553]
and Section 9 of [RFC6350].
5. Acknowledgements
The definition and examples of the PHONETIC (Section 2.3.13) and
SCRIPT (Section 2.3.17) parameters are based on the initial version
of [I-D.calconnect-vobject-i18n].
6. IANA Considerations
6.1.
5.1. New vCard Properties Property
IANA is requested to add has added the following entries entry to the "vCard Properties"
registry, as defined in Section 10.3.1. 10.3.1 of [RFC6350].
+===========+==========+==============================+
+===========+==========+=========================+
| Namespace | Property | Reference |
+===========+==========+==============================+
+===========+==========+=========================+
| | JSPROP | This document, RFC 9555, Section 3.2.1 |
+-----------+----------+------------------------------+
+-----------+----------+-------------------------+
Table 4: New vCard Properties
6.2. Property
5.2. New vCard Parameters Parameter
IANA is requested to add has added the following entries entry to the "vCard Parameters"
registry, as defined in Section 10.3.2. 10.3.2 of [RFC6350].
+===========+===========+==============================+
+===========+===========+=========================+
| Namespace | Parameter | Reference |
+===========+===========+==============================+
+===========+===========+=========================+
| | JSPTR | This document, RFC 9555, Section 3.3.2 |
+-----------+-----------+------------------------------+
+-----------+-----------+-------------------------+
Table 5: New vCard Parameters
6.3. Parameter
5.3. New JSContact Properties
IANA is requested to add has added the following entries to the "JSContact Properties"
registry. The Note that the Since Version for all properties is 1.0.
The 1.0, the Until Version for all properties is
not set. All RFC section
references are for this document. The change controller set, and the Change Controller is IETF for all of these properties is IETF.
+=============+================+===========+==============+========+
| Property | Property
properties.
+===========+=======================+=========+========+============+
|Property |Property Type |Property |Intended|Reference | Property
|Name | Reference or |Intended|
| Name | | Context | Description |Context |Usage |or |
+=============+================+===========+==============+========+
| vCardName | String | Any
| Section |common |
| | | JSContact | 2.15.3 | | | |Description |
+===========+=======================+=========+========+============+
|vCardName |String |Any |common |RFC 9555, | object
| | |JSContact| |Section |
+-------------+----------------+-----------+--------------+--------+
| vCardParams | String[String] |object | Any |2.15.3 | Section
+-----------+-----------------------+---------+--------+------------+
|vCardParams|String[String|String[]]|Any |common |RFC 9555, |
| | | JSContact | 2.15.2 |JSContact| |Section |
| | |object | |2.15.2 | object | |
+-----------+-----------------------+---------+--------+------------+
|vCardProps |JCardProp[] |Card |common |RFC 9555, |
+-------------+----------------+-----------+--------------+--------+
| vCardProps | JCardProp[] | Card | Section |common | |Section |
| | | 2.15.1 | |2.15.1 |
+-------------+----------------+-----------+--------------+--------+
+-----------+-----------------------+---------+--------+------------+
Table 6: Initial Contents of the "JSContact Properties" JSContact Properties Registry
6.4.
5.4. New JSContact Types Type
IANA is requested to add has added the following entries entry to the "JSContact Types" registry. The
Note that the Since Version for all properties is 1.0. The 1.0, the Until Version for all properties is not set. All RFC section
references are set, and
the Change Controller is IETF for this document. The change controller for all
these properties is IETF.
+===========+==========================+================+ type.
+===========+================+==========================+
| Type Name | Intended Usage | Reference or Description | Intended Usage |
+===========+==========================+================+
+===========+================+==========================+
| JCardProp | common | RFC 9555, Section 2.15.1 | common |
+-----------+--------------------------+----------------+
+-----------+----------------+--------------------------+
Table 7: Additional Contents of the "JSContact Types"
Registry
7. Implementation Status
NOTE: Please remove this section and the reference to RFC 7942 prior
to publication as an RFC.
This section records the status of known implementations of the
protocol as defined in this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in
[RFC7942]. The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations may exist.
According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
7.1. CNR
* Responsible Organization: National Research Council (CNR) of Italy
* Location: https://github.com/consiglionazionaledellericerche/
jscontact-tools
* Description: This implementation includes tools for JSContact
creation, validation, serialization/deserialization, and
conversion from vCard, xCard and jCard.
* Level of Maturity: This is an "alpha" test implementation.
* Coverage: This implementation includes all features described in
this specification.
* Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it
8. Types Registry
6. References
8.1.
6.1. Normative References
[I-D.ietf-calext-jscontact]
Stepanek, R. and M. Loffredo, "JSContact: A JSON
representation of contact data", Work in Progress,
Internet-Draft, draft-ietf-calext-jscontact-14, 31 August
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
calext-jscontact-14>.
[I-D.ietf-calext-vcard-jscontact-extensions]
Stepanek, R. and M. Loffredo, "vCard Format Extension for
JSContact", Work in Progress, Internet-Draft, draft-ietf-
calext-vcard-jscontact-extensions-10, 31 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-calext-
vcard-jscontact-extensions-10>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
[RFC6473] Saint-Andre, P., "vCard KIND:application", RFC 6473,
DOI 10.17487/RFC6473, December 2011,
<https://www.rfc-editor.org/info/rfc6473>.
[RFC6474] Li, K. and B. Leiba, "vCard Format Extensions: Place of
Birth, Place and Date of Death", RFC 6474,
DOI 10.17487/RFC6474, December 2011,
<https://www.rfc-editor.org/info/rfc6474>.
[RFC6715] Cauchie, D., Leiba, B., and K. Li, "vCard Format
Extensions: Representing vCard Extensions Defined by the
Open Mobile Alliance (OMA) Converged Address Book (CAB)
Group", RFC 6715, DOI 10.17487/RFC6715, August 2012,
<https://www.rfc-editor.org/info/rfc6715>.
[RFC6869] Salgueiro, G., Clarke, J., and P. Saint-Andre, "vCard
KIND:device", RFC 6869, DOI 10.17487/RFC6869, February
2013, <https://www.rfc-editor.org/info/rfc6869>.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer", RFC 6901,
DOI 10.17487/RFC6901, April 2013,
<https://www.rfc-editor.org/info/rfc6901>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC9553] Stepanek, R. and M. Loffredo, "JSContact: A JSON
Representation of Contact Data", RFC 9553,
DOI 10.17487/RFC9553, March 2024,
<https://www.rfc-editor.org/info/rfc9553>.
[RFC9554] Stepanek, R. and M. Loffredo, "vCard Format Extension for
JSContact", RFC 9554, DOI 10.17487/RFC9554, March 2024,
<https://www.rfc-editor.org/info/rfc9554>.
6.2. Informative References
[CLDRPersonName]
Davis, M., Edberg, P., Gillam, R., Kolisnychenko, A.,
McKenna, M., and others, "Technical Standard #35: Unicode other CLDR committee members, "Unicode
Locale Data Markup Language (LDML) Part 8: Person Names, Names",
Unicode Technical Standard #35, Version 43.1", 44.1, July 2023,
<https://www.unicode.org/reports/tr35/
tr35-personNames.html>.
[I-D.calconnect-vobject-i18n]
Tse, R. H., Tam, P., and M. Douglass, "vObject
Internationalization", Work in Progress, Internet-Draft,
draft-calconnect-vobject-i18n-00, 7 June 2018,
<https://datatracker.ietf.org/doc/html/draft-calconnect-
vobject-i18n-00>.
[RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions:
ICANN Extensions for the Registration Data Access Protocol
(RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019,
<https://www.rfc-editor.org/info/rfc8605>.
[vOBJECT] Tse, R., Tam, P., and M. Douglass, "vObject
Internationalization", Work in Progress, Internet-Draft,
draft-calconnect-vobject-i18n-00, 7 June 2018,
<https://datatracker.ietf.org/doc/html/draft-calconnect-
vobject-i18n-00>.
Appendix A. Reverse Rules of Converting a vCard to a JSContact Card
Table 8 lists the relevant document sections for each JSContact
object type
and property.
+===================+=====================+=================+
+===================+=====================+=====================+
| JSContact Type | Property Name | Relevant |
| | | Section(s) |
+===================+=====================+=================+
+===================+=====================+=====================+
| Address | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | components | Section 2.6.1, Sections 2.6.1 and |
| | | Section 3.3.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | coordinates | Section 2.3.7, Sections 2.3.8 and |
| | | Section 2.8.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | country | Section 2.6.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | countryCode | Section 2.6.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | defaultSeparator | Section 2.6.1, Sections 2.6.1 and |
| | | Section 3.3.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | full | Section 2.6.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | isOrdered | Section 2.6.1, Sections 2.6.1 and |
| | | Section 3.3.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | locality | Section 2.6.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | phoneticScript | Section 2.3.13, Sections 2.3.15 and |
| | | Section 2.3.17 2.3.19 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | phoneticSystem | Section 2.3.13 2.3.15 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | postcode | Section 2.6.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | region | Section 2.6.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Address | timeZone | Section 2.3.21, Sections 2.3.23 and |
| | | Section 2.8.2 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| AddressComponent | phonetic | Section 2.3.13 2.3.15 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Anniversary | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Anniversary | date | Section 2.5.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Anniversary | kind | Section 2.5.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Anniversary | place | Section 2.5.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Author | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Author | name | Section 2.3.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Author | uri | Section 2.3.2 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Calendar | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Calendar | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Calendar | kind | Section 2.13.1, Sections 2.13.2 and |
| | | Section 2.13.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Calendar | label | Section 2.11.11 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Calendar | mediaType | Section 2.3.12 2.3.14 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Calendar | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Calendar | uri | Section 2.13.1, Sections 2.13.2 and |
| | | Section 2.13.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | @version | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | addresses | Section 2.6.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | anniversaries | Section 2.5.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | calendars | Section 2.13.1, Sections 2.13.2 and |
| | | Section 2.13.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | created | Section 2.11.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | directories | Section 2.4.3, Sections 2.4.3 and |
| | | Section 2.10.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | emails | Section 2.7.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | keywords | Section 2.11.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | kind | Section 2.4.2 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | language | Section 2.7.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | links | Section 2.9.1, Sections 2.9.1 and |
| | | Section 2.11.9 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | localizations | Section 2.3.10 2.3.11 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | media | Section Sections 2.5.7, |
| | | Section 2.9.2, |
| | | Section and 2.11.7 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | members | Section 2.9.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | name | Section 2.5.5 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | nicknames | Section 2.5.5 2.5.6 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | notes | Section 2.11.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | onlineServices | Section 2.7.2 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | organizations | Section 2.9.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | personalInfo | Section Sections 2.10.1, |
| | | Section 2.10.2, |
| | | Section and 2.10.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | phones | Section 2.7.6 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | preferredLanguages | Section 2.7.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | prodId | Section 2.11.5 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | relatedTo | Section 2.9.5 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | schedulingAddresses | Section 2.13.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | speakToAs | Section 2.5.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | titles | Section 2.9.6 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | uid | Section 2.11.8 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Card | updated | Section 2.11.6 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| CryptoKey | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| CryptoKey | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| CryptoKey | kind | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| CryptoKey | label | Section 2.11.11 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| CryptoKey | mediaType | Section 2.3.12 2.3.14 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| CryptoKey | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| CryptoKey | uri | Section 2.12.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Directory | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Directory | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Directory | kind | Section 2.4.3, Sections 2.4.3 and |
| | | Section 2.10.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Directory | label | Section 2.11.11 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Directory | listAs | Section 2.3.9 2.3.10 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Directory | mediaType | Section 2.3.12 2.3.14 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Directory | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Directory | uri | Section 2.4.3, Sections 2.4.3 and |
| | | Section 2.10.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| EmailAddress | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| EmailAddress | address | Section 2.7.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| EmailAddress | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| EmailAddress | label | Section 2.11.11 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| EmailAddress | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| LanguagePref | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| LanguagePref | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| LanguagePref | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Link | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Link | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Link | kind | Section 2.9.1, | 2.9.1 | | | Section 2.11.9 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Link | label | Section 2.11.11 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Link | mediaType | Section 2.3.12 2.3.14 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Link | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Link | uri | Section 2.9.1, Sections 2.9.1 and |
| | | Section 2.11.9> 2.11.9 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Media | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Media | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Media | kind | Section Sections 2.5.7, |
| | | Section 2.9.2, |
| | | Section and 2.11.7 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Media | label | Section 2.11.11 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Media | mediaType | Section 2.3.12 2.3.14 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Media | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Media | uri | Section Sections 2.5.7, |
| | | Section 2.9.2, |
| | | Section and 2.11.7 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Name | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Name | components | Section 2.5.5, Sections 2.5.5 and |
| | | Section 3.3.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Name | defaultSeparator | Section 2.5.5, Sections 2.5.5 and |
| | | Section 3.3.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Name | full | Section 2.5.2 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Name | phoneticScript | Section 2.3.13, Sections 2.3.15 and |
| | | Section 2.3.17 2.3.19 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Name | phoneticSystem | Section 2.3.13 2.3.15 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Name | isOrdered | Section 2.5.5, Sections 2.5.5 and |
| | | Section 3.3.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Name | sortAs | Section 2.3.19 2.3.21 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| NameComponent | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| NameComponent | kind | Section 2.5.5 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| NameComponent | phonetic | Section 2.3.13 2.3.15 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| NameComponent | value | Section 2.5.5 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Nickname | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Nickname | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Nickname | name | Section 2.5.5 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Nickname | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Note | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Note | author | Section 2.3.2, Sections 2.3.2 and |
| | | Section 2.3.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Note | created | Section 2.3.5 2.3.6 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Note | note | Section 2.11.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| OnlineService | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| OnlineService | contexts | Section 2.3.20 |
+-------------------+---------------------+-----------------+
| OnlineService | kind | Section 2.7.2, |
| | | Section 2.7.5 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| OnlineService | label | Section 2.11.11 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| OnlineService | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| OnlineService | service | Section 2.3.18 2.3.20 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| OnlineService | uri | Section 2.7.2, Sections 2.7.2 and |
| | | Section 2.7.5 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| OnlineService | user | Section 2.3.22 2.3.24 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| OrgUnit | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| OrgUnit | name | Section 2.9.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| OrgUnit | sortAs | Section 2.3.19 2.3.21 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Organization | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Organization | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Organization | name | Section 2.9.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Organization | sortAs | Section 2.3.19 2.3.21 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Organization | units | Section 2.9.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PartialDate | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PartialDate | calendarScale | Section 2.3.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PartialDate | day | Section 2.2.2 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PartialDate | month | Section 2.2.2 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PartialDate | year | Section 2.2.2 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PatchObject | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PersonalInfo | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PersonalInfo | kind | Section Sections 2.10.1, |
| | | Section 2.10.2, |
| | | Section and 2.10.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PersonalInfo | listAs | Section 2.3.9 2.3.10 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PersonalInfo | level | Section 2.3.11 2.3.13 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| PersonalInfo | value | Section Sections 2.10.1, |
| | | Section 2.10.2, |
| | | Section and 2.10.3 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Phone | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Phone | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Phone | features | Section 2.7.6 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Phone | label | Section 2.11.11 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Phone | number | Section 2.7.6 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Phone | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Pronouns | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Pronouns | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Pronouns | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Pronouns | pronouns | Section 2.5.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Relation | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Relation | relation | Section 2.9.5 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Resource | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| SchedulingAddress | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| SchedulingAddress | contexts | Section 2.3.20 2.3.22 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| SchedulingAddress | label | Section 2.11.11 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| SchedulingAddress | pref | Section 2.3.15 2.3.17 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| SchedulingAddress | uri | Section 2.13.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| SpeakToAs | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| SpeakToAs | grammaticalGender | Section 2.5.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| SpeakToAs | pronouns | Section 2.5.4 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| AddressComponent | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| AddressComponent | kind | Section 2.6.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| AddressComponent | value | Section 2.6.1 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Timestamp | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Timestamp | utc | Section 2.2.2 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Title | @type | not applicable |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Title | kind | Section 2.9.6 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Title | name | Section 2.9.6 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
| Title | organization organizationId | Section 2.9.6 |
+-------------------+---------------------+-----------------+
+-------------------+---------------------+---------------------+
Table 8: Conversion rules by Rules for JSContact property Types and Properties
Acknowledgements
The definition and examples of the PHONETIC (Section 2.3.15) and
SCRIPT (Section 2.3.19) parameters are based on the initial draft
version of [vOBJECT].
Authors' Addresses
Mario Loffredo
IIT-CNR/Registro.it
Via Moruzzi,1 Moruzzi, 1
56124 Pisa
Italy
Email: mario.loffredo@iit.cnr.it
URI: https://www.iit.cnr.it
Robert Stepanek
Fastmail
PO Box 234, 234
Collins St St. West
Melbourne VIC 8007
Australia
Email: rsto@fastmailteam.com
URI: https://www.fastmail.com