Internet DRAFT - draft-calconnect-vobject-vformat
draft-calconnect-vobject-vformat
Calendaring Extensions R. Tse
Internet-Draft P. Tam
Updates: 5545, 6321, 6350, 6351, 7953, Ribose
7265, 7095 (if approved) K. Murchison
Intended status: Standards Track FastMail Pty Ltd
Expires: December 10, 2018 M. Douglass
Spherical Cow Group
June 8, 2018
The vObject Model and vFormat Syntax
draft-calconnect-vobject-vformat-04
Abstract
This document specifies the vObject data model and its corresponding
syntax vFormat.
vObject represents the generalized data model, and vFormat the
generalized data format, of the following specifications and fully
covers them:
o RFC 6350, vCard version 4.0: the VCARD component;
o RFC 5545, Internet Calendaring and Scheduling Core Object
Specification (iCalendar): the VCALENDAR, VEVENT, VJOURNAL,
VFREEBUSY, VTIMEZONE, VALARM, VTODO, STANDARD and DAYLIGHT
components;
o RFC 7953, Calendar Availability Extensions: the VAVAILABILITY and
AVAILABLE components;
o I-Ddaboo-icalendar-vpatch, iCalendar Patching: the VPATCH
component; and
o alternative formats for iCalendar and vCard, including RFC 6321,
xCal; RFC 7265, jCal; RFC 6351, xCard; and RFC 7095, jCard.
This work is produced by the CalConnect TC-VCARD and TC-CALENDAR
committees.
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 of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
Tse, et al. Expires December 10, 2018 [Page 1]
Internet-Draft vObject and vFormat June 2018
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents 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 December 10, 2018.
Copyright Notice
Copyright (c) 2018 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) 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
3. vObject Data Model . . . . . . . . . . . . . . . . . . . . . 9
3.1. vObject-compliant Models . . . . . . . . . . . . . . . . 10
3.2. Elements . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Equivalence . . . . . . . . . . . . . . . . . . . . . 11
3.3. Component . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Uniqueness Identifying Property . . . . . . . . . . . 12
3.3.2. Normalizing A Component . . . . . . . . . . . . . . . 13
3.3.2.1. Sorted Component Properties . . . . . . . . . . . 13
3.3.2.2. Sorted Inner Components . . . . . . . . . . . . . 13
3.3.2.3. Normalized Inner Components . . . . . . . . . . . 13
3.3.3. vObject Property . . . . . . . . . . . . . . . . . . 13
3.3.3.1. Normalized Values . . . . . . . . . . . . . . . . 14
3.3.3.2. Normalized Parameters . . . . . . . . . . . . . . 14
3.3.4. Property Value . . . . . . . . . . . . . . . . . . . 14
3.3.5. Normalization Of Property Values . . . . . . . . . . 14
3.3.6. Property Parameter . . . . . . . . . . . . . . . . . 14
3.3.6.1. Value Lists . . . . . . . . . . . . . . . . . . . 15
3.3.7. Default Property Parameter Values . . . . . . . . . . 15
Tse, et al. Expires December 10, 2018 [Page 2]
Internet-Draft vObject and vFormat June 2018
3.3.8. Property Parameter Value . . . . . . . . . . . . . . 15
3.3.9. Normalizing Multiple Parameter Values . . . . . . . . 15
3.3.10. Property Group . . . . . . . . . . . . . . . . . . . 16
4. vFormat Syntax . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. ABNF Format Definition . . . . . . . . . . . . . . . . . 16
4.2. Component . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. Component Name In Uppercase . . . . . . . . . . . . . 18
4.2.2. Order Of Inner Components And Properties . . . . . . 18
4.2.3. Maintain Validity . . . . . . . . . . . . . . . . . . 18
4.3. Property . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1. Uppercased Property Name . . . . . . . . . . . . . . 19
4.3.2. Normalized Parameters . . . . . . . . . . . . . . . . 19
4.3.3. Wrapped Content Line . . . . . . . . . . . . . . . . 19
4.4. Property Value . . . . . . . . . . . . . . . . . . . . . 19
4.4.1. Normalizing Property Values . . . . . . . . . . . . . 20
4.5. Property Parameter . . . . . . . . . . . . . . . . . . . 20
4.5.1. Multiple Property Parameters . . . . . . . . . . . . 20
4.5.2. Expanded Form Of Property Parameter Value List . . . 20
4.5.3. Uppercased Property Parameter Names . . . . . . . . . 20
4.5.4. Join Identical Property Parameter Names . . . . . . . 21
4.5.5. Express Default Property Value Types . . . . . . . . 21
4.6. Property Parameter Value . . . . . . . . . . . . . . . . 21
4.6.1. Format Definition . . . . . . . . . . . . . . . . . . 22
4.6.2. Description . . . . . . . . . . . . . . . . . . . . . 22
4.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 23
4.6.4. Normalization of Line Breaks . . . . . . . . . . . . 23
4.6.5. Normalizing Parameter Values Via DQOUTE Wrapping . . 23
4.7. Property Group . . . . . . . . . . . . . . . . . . . . . 23
5. vObject Value Types And Notation Syntax . . . . . . . . . . . 23
5.1. Value Type Notation . . . . . . . . . . . . . . . . . . . 24
5.2. Meta Value Types . . . . . . . . . . . . . . . . . . . . 24
5.2.1. FIELDSET . . . . . . . . . . . . . . . . . . . . . . 24
5.2.1.1. Value Type Notation . . . . . . . . . . . . . . . 24
5.2.1.2. Example 1 . . . . . . . . . . . . . . . . . . . . 24
5.2.1.3. Example 2 . . . . . . . . . . . . . . . . . . . . 25
5.2.1.4. Normalizing a FIELDSET . . . . . . . . . . . . . 25
5.2.2. LIST . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.2.1. Value Type Notation . . . . . . . . . . . . . . . 25
5.2.2.2. Example 1 . . . . . . . . . . . . . . . . . . . . 25
5.2.2.3. Example 2 . . . . . . . . . . . . . . . . . . . . 26
5.2.2.4. Normalizing a LIST . . . . . . . . . . . . . . . 26
5.2.3. MAP . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.3.1. Value Type Notation . . . . . . . . . . . . . . . 26
5.2.3.2. Example . . . . . . . . . . . . . . . . . . . . . 26
5.2.3.3. Normalizing a MAP . . . . . . . . . . . . . . . . 27
5.3. Basic Value Types . . . . . . . . . . . . . . . . . . . . 27
5.3.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.1.1. Value Type Notation . . . . . . . . . . . . . . . 27
Tse, et al. Expires December 10, 2018 [Page 3]
Internet-Draft vObject and vFormat June 2018
5.3.1.2. Purpose . . . . . . . . . . . . . . . . . . . . . 27
5.3.1.3. Format Definition . . . . . . . . . . . . . . . . 27
5.3.1.4. Associated parameters . . . . . . . . . . . . . . 27
5.3.1.5. Example . . . . . . . . . . . . . . . . . . . . . 28
5.3.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.2.1. Value Type Notation . . . . . . . . . . . . . . . 28
5.3.2.2. Purpose . . . . . . . . . . . . . . . . . . . . . 28
5.3.2.3. Format Definition . . . . . . . . . . . . . . . . 28
5.3.2.4. Description . . . . . . . . . . . . . . . . . . . 28
5.3.2.5. Example . . . . . . . . . . . . . . . . . . . . . 28
5.3.2.6. Normalization . . . . . . . . . . . . . . . . . . 29
5.3.3. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . 29
5.3.3.1. Value Type Notation . . . . . . . . . . . . . . . 29
5.3.3.2. Purpose . . . . . . . . . . . . . . . . . . . . . 29
5.3.3.3. Format Definition . . . . . . . . . . . . . . . . 29
5.3.3.4. Description . . . . . . . . . . . . . . . . . . . 29
5.3.3.5. Examples . . . . . . . . . . . . . . . . . . . . 29
5.3.3.6. Normalization . . . . . . . . . . . . . . . . . . 29
5.3.4. INTEGER . . . . . . . . . . . . . . . . . . . . . . . 29
5.3.4.1. Value Type Notation . . . . . . . . . . . . . . . 30
5.3.4.2. Purpose . . . . . . . . . . . . . . . . . . . . . 30
5.3.4.3. Format Definition . . . . . . . . . . . . . . . . 30
5.3.4.4. Description . . . . . . . . . . . . . . . . . . . 30
5.3.4.5. Examples . . . . . . . . . . . . . . . . . . . . 30
5.3.4.6. Normalization . . . . . . . . . . . . . . . . . . 30
5.3.5. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.5.1. Value Type Notation . . . . . . . . . . . . . . . 31
5.3.5.2. Purpose . . . . . . . . . . . . . . . . . . . . . 31
5.3.5.3. Format Definition . . . . . . . . . . . . . . . . 31
5.3.5.4. Description . . . . . . . . . . . . . . . . . . . 31
5.3.5.5. Examples . . . . . . . . . . . . . . . . . . . . 31
5.3.5.6. Normalization . . . . . . . . . . . . . . . . . . 31
5.3.6. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . 32
5.3.6.1. Value Type Notation . . . . . . . . . . . . . . . 32
5.3.6.2. Purpose . . . . . . . . . . . . . . . . . . . . . 32
5.3.6.3. Format Definition . . . . . . . . . . . . . . . . 32
5.3.6.4. Description . . . . . . . . . . . . . . . . . . . 32
5.3.6.5. Examples . . . . . . . . . . . . . . . . . . . . 32
5.3.6.6. Normalization . . . . . . . . . . . . . . . . . . 32
5.3.7. Binary . . . . . . . . . . . . . . . . . . . . . . . 33
5.3.7.1. Value Type Notation . . . . . . . . . . . . . . . 33
5.3.7.2. Purpose . . . . . . . . . . . . . . . . . . . . . 33
5.3.7.3. Format Definition . . . . . . . . . . . . . . . . 33
5.3.7.4. Description . . . . . . . . . . . . . . . . . . . 33
5.3.7.5. Example . . . . . . . . . . . . . . . . . . . . . 33
5.3.8. KEYVALUE . . . . . . . . . . . . . . . . . . . . . . 34
5.3.8.1. Value Type Notation . . . . . . . . . . . . . . . 34
5.3.8.2. Purpose . . . . . . . . . . . . . . . . . . . . . 34
Tse, et al. Expires December 10, 2018 [Page 4]
Internet-Draft vObject and vFormat June 2018
5.3.8.3. Format Definition . . . . . . . . . . . . . . . . 34
5.3.8.4. Description . . . . . . . . . . . . . . . . . . . 34
5.3.8.5. Examples . . . . . . . . . . . . . . . . . . . . 34
5.3.8.6. Normalization . . . . . . . . . . . . . . . . . . 34
5.4. Date and Time Value Types . . . . . . . . . . . . . . . . 34
5.4.1. ISO-DATE-COMPLETE . . . . . . . . . . . . . . . . . . 35
5.4.1.1. Value Type Notation . . . . . . . . . . . . . . . 35
5.4.1.2. Purpose . . . . . . . . . . . . . . . . . . . . . 35
5.4.1.3. Format Definition . . . . . . . . . . . . . . . . 35
5.4.1.4. Description . . . . . . . . . . . . . . . . . . . 35
5.4.1.5. Example . . . . . . . . . . . . . . . . . . . . . 35
5.4.1.6. Normalization . . . . . . . . . . . . . . . . . . 35
5.4.2. ISO-DATE-FLEX . . . . . . . . . . . . . . . . . . . . 35
5.4.2.1. Value Type Notation . . . . . . . . . . . . . . . 36
5.4.2.2. Purpose . . . . . . . . . . . . . . . . . . . . . 36
5.4.2.3. Format Definition . . . . . . . . . . . . . . . . 36
5.4.2.4. Description . . . . . . . . . . . . . . . . . . . 36
5.4.2.5. Normalization . . . . . . . . . . . . . . . . . . 37
5.4.3. ISO-TIME-COMPLETE . . . . . . . . . . . . . . . . . . 37
5.4.3.1. Value Type Notation . . . . . . . . . . . . . . . 37
5.4.3.2. Purpose . . . . . . . . . . . . . . . . . . . . . 37
5.4.3.3. Format Definition . . . . . . . . . . . . . . . . 38
5.4.3.4. Description . . . . . . . . . . . . . . . . . . . 38
5.4.3.5. Normalization . . . . . . . . . . . . . . . . . . 39
5.4.4. ISO-TIME-BASIC . . . . . . . . . . . . . . . . . . . 39
5.4.4.1. Value Type Notation . . . . . . . . . . . . . . . 39
5.4.4.2. Purpose . . . . . . . . . . . . . . . . . . . . . 39
5.4.4.3. Format Definition . . . . . . . . . . . . . . . . 39
5.4.4.4. Description . . . . . . . . . . . . . . . . . . . 39
5.4.4.5. Normalization . . . . . . . . . . . . . . . . . . 40
5.4.5. ISO-TIME-FLEX . . . . . . . . . . . . . . . . . . . . 40
5.4.5.1. Value Type Notation . . . . . . . . . . . . . . . 40
5.4.5.2. Purpose . . . . . . . . . . . . . . . . . . . . . 40
5.4.5.3. Format Definition . . . . . . . . . . . . . . . . 40
5.4.5.4. Description . . . . . . . . . . . . . . . . . . . 41
5.4.5.5. Normalization . . . . . . . . . . . . . . . . . . 42
5.4.6. ISO-UTC-OFFSET . . . . . . . . . . . . . . . . . . . 42
5.4.6.1. Value Type Notation . . . . . . . . . . . . . . . 42
5.4.6.2. Purpose . . . . . . . . . . . . . . . . . . . . . 42
5.4.6.3. Format Definition . . . . . . . . . . . . . . . . 42
5.4.6.4. Example . . . . . . . . . . . . . . . . . . . . . 43
5.4.6.5. Normalization . . . . . . . . . . . . . . . . . . 43
5.4.7. CAL-UTC-OFFSET . . . . . . . . . . . . . . . . . . . 43
5.4.7.1. Value Type Notation . . . . . . . . . . . . . . . 43
5.4.7.2. Purpose . . . . . . . . . . . . . . . . . . . . . 43
5.4.7.3. Format Definition . . . . . . . . . . . . . . . . 43
5.4.7.4. Description: . . . . . . . . . . . . . . . . . . 43
5.4.7.5. Example . . . . . . . . . . . . . . . . . . . . . 44
Tse, et al. Expires December 10, 2018 [Page 5]
Internet-Draft vObject and vFormat June 2018
5.4.7.6. Normalization . . . . . . . . . . . . . . . . . . 44
5.4.8. ISO-DATE-TIME-COMPLETE . . . . . . . . . . . . . . . 44
5.4.8.1. Value Type Notation . . . . . . . . . . . . . . . 44
5.4.8.2. Purpose . . . . . . . . . . . . . . . . . . . . . 44
5.4.8.3. Format Definition . . . . . . . . . . . . . . . . 44
5.4.8.4. Description . . . . . . . . . . . . . . . . . . . 45
5.4.8.5. Examples . . . . . . . . . . . . . . . . . . . . 45
5.4.8.6. Normalization . . . . . . . . . . . . . . . . . . 45
5.4.9. ISO-DATE-TIME-BASIC . . . . . . . . . . . . . . . . . 45
5.4.9.1. Value Type Notation . . . . . . . . . . . . . . . 45
5.4.9.2. Purpose . . . . . . . . . . . . . . . . . . . . . 45
5.4.9.3. Format Definition . . . . . . . . . . . . . . . . 46
5.4.9.4. Description . . . . . . . . . . . . . . . . . . . 46
5.4.9.5. Examples . . . . . . . . . . . . . . . . . . . . 46
5.4.9.6. Normalization . . . . . . . . . . . . . . . . . . 46
5.4.10. ISO-DATE-TIME-FLEX . . . . . . . . . . . . . . . . . 46
5.4.10.1. Value Type Notation . . . . . . . . . . . . . . 46
5.4.10.2. Purpose . . . . . . . . . . . . . . . . . . . . 46
5.4.10.3. Format Definition . . . . . . . . . . . . . . . 47
5.4.10.4. Description . . . . . . . . . . . . . . . . . . 47
5.4.10.5. Examples . . . . . . . . . . . . . . . . . . . . 47
5.4.10.6. Normalization . . . . . . . . . . . . . . . . . 47
5.4.11. ISO-DATE-AND-OR-TIME . . . . . . . . . . . . . . . . 47
5.4.11.1. Value Type Notation . . . . . . . . . . . . . . 47
5.4.11.2. Purpose . . . . . . . . . . . . . . . . . . . . 47
5.4.11.3. Format Definition . . . . . . . . . . . . . . . 48
5.4.11.4. Description . . . . . . . . . . . . . . . . . . 48
5.4.11.5. Example . . . . . . . . . . . . . . . . . . . . 48
5.4.11.6. Normalization . . . . . . . . . . . . . . . . . 49
5.4.12. ISO-DURATION-COMPLETE . . . . . . . . . . . . . . . . 49
5.4.12.1. Value Type Notation . . . . . . . . . . . . . . 49
5.4.12.2. Purpose . . . . . . . . . . . . . . . . . . . . 49
5.4.12.3. Format Definition . . . . . . . . . . . . . . . 49
5.4.12.4. Description . . . . . . . . . . . . . . . . . . 49
5.4.12.5. Examples . . . . . . . . . . . . . . . . . . . . 50
5.4.12.6. Normalization . . . . . . . . . . . . . . . . . 50
5.4.13. CAL-DURATION . . . . . . . . . . . . . . . . . . . . 51
5.4.13.1. Value Type Notation . . . . . . . . . . . . . . 51
5.4.13.2. Purpose . . . . . . . . . . . . . . . . . . . . 51
5.4.13.3. Format Definition . . . . . . . . . . . . . . . 51
5.4.13.4. Description . . . . . . . . . . . . . . . . . . 51
5.4.13.5. Example . . . . . . . . . . . . . . . . . . . . 52
5.4.13.6. Normalization . . . . . . . . . . . . . . . . . 53
5.4.14. ISO-INTERVAL . . . . . . . . . . . . . . . . . . . . 53
5.4.14.1. Value Type Notation . . . . . . . . . . . . . . 53
5.4.14.2. Purpose . . . . . . . . . . . . . . . . . . . . 53
5.4.14.3. Format Definition . . . . . . . . . . . . . . . 53
5.4.14.4. Description . . . . . . . . . . . . . . . . . . 53
Tse, et al. Expires December 10, 2018 [Page 6]
Internet-Draft vObject and vFormat June 2018
5.4.14.5. Examples . . . . . . . . . . . . . . . . . . . . 55
5.4.14.6. Normalization . . . . . . . . . . . . . . . . . 55
5.4.15. CAL-INTERVAL . . . . . . . . . . . . . . . . . . . . 55
5.4.15.1. Value Type Notation . . . . . . . . . . . . . . 55
5.4.15.2. Purpose . . . . . . . . . . . . . . . . . . . . 55
5.4.15.3. Format Definition . . . . . . . . . . . . . . . 55
5.4.15.4. Description . . . . . . . . . . . . . . . . . . 55
5.4.15.5. Examples . . . . . . . . . . . . . . . . . . . . 56
5.4.15.6. Normalization . . . . . . . . . . . . . . . . . 57
6. Normalization . . . . . . . . . . . . . . . . . . . . . . . . 57
6.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2. Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3. Application on alternative serializations . . . . . . . . 59
7. Client Implementations Recommendations . . . . . . . . . . . 59
8. CardDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.1. Additional Server Semantics for PUT, COPY and MOVE . . . 59
8.1.1. Provide Normalized Output . . . . . . . . . . . . . . 59
9. CalDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.1. Additional Server Semantics for PUT, COPY and MOVE . . . 60
9.1.1. Provide Normalized Output . . . . . . . . . . . . . . 60
10. Security Considerations . . . . . . . . . . . . . . . . . . . 60
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
11.1. Common vObject Registries . . . . . . . . . . . . . . . 61
11.2. vObject Component Uniqueness Identifiers Registry . . . 61
11.2.1. Registration Procedure . . . . . . . . . . . . . . . 61
11.2.2. Registration Template . . . . . . . . . . . . . . . 61
11.2.3. Initial Registrations . . . . . . . . . . . . . . . 62
12. Mapping Of Data Value Types For Existing RFCs . . . . . . . . 63
12.1. RFC 6350 . . . . . . . . . . . . . . . . . . . . . . . . 63
12.2. RFC 5545 . . . . . . . . . . . . . . . . . . . . . . . . 64
12.2.1. RECURMAP . . . . . . . . . . . . . . . . . . . . . . 64
13. Mapping Of Component Property Value Types For Existing RFCs . 65
13.1. VCARD Component (RFC 6350) . . . . . . . . . . . . . . . 65
13.2. VCALENDAR Component (RFC 5545) . . . . . . . . . . . . . 67
13.3. VEVENT Component (RFC 5545) . . . . . . . . . . . . . . 67
13.4. VTODO Component (RFC 5545) . . . . . . . . . . . . . . . 69
13.5. VJOURNAL Component (RFC 5545) . . . . . . . . . . . . . 70
13.6. VFREEBUSY Component (RFC 5545) . . . . . . . . . . . . . 71
13.7. VTIMEZONE Component (RFC 5545) . . . . . . . . . . . . . 71
13.8. STANDARD / DAYLIGHT Components (RFC 5545) . . . . . . . 71
13.9. VALARM Component (RFC 5545) . . . . . . . . . . . . . . 72
14. Mapping Of Parameter Value Types For Existing RFCs . . . . . 72
14.1. RFC 6350 . . . . . . . . . . . . . . . . . . . . . . . . 72
14.2. RFC 5545 . . . . . . . . . . . . . . . . . . . . . . . . 73
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 73
15.1. Normative References . . . . . . . . . . . . . . . . . . 74
15.2. Informative References . . . . . . . . . . . . . . . . . 74
Appendix A. Normalization Examples for vFormat . . . . . . . . . 77
Tse, et al. Expires December 10, 2018 [Page 7]
Internet-Draft vObject and vFormat June 2018
A.1. vCard . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
1. Introduction
The ubiquitous vCard [RFC6350] and iCalendar [RFC5545] standards are
known as the "vObject" or "VCOMPONENT" family of standards. Named by
the convention where the component type identifiers usually start
with the letter "v", all of them use very similar, if not identical,
syntax.
While the origin of these formats have a shared history, due to
diverged implementations of "vObject" standards, the serialization of
such formats often generate different output even when given
identical content, causing interoperability concerns and the general
inability to determine equivalence of vObjects for integrity concerns
(2.1.2 [RFC3552]).
This document:
o defines the "vObject" data model, a generalization of the implied
data models of vObject-compliant standards;
o defines the "vFormat" serialization syntax, a generalized syntax
of vObject-compliant serialization formats;
o provides the "vObject Value Type" notation syntax, a method to
define value schema of all properties in vObject-compliant
standards; and
o describes the normalized form of the vObject data model and the
normalization process for vFormat syntax.
The normalized forms and normalization methods described in this
document are fully compatible with the vObject-compliant standards,
including vCard 4.0 [RFC6350] and iCalendar [RFC5545].
This is a work product of the CalConnect TC-VCARD [CALCONNECT-VCARD]
and TC-CALENDAR [CALCONNECT-CALENDAR] committees.
2. Terms and Definitions
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.
Tse, et al. Expires December 10, 2018 [Page 8]
Internet-Draft vObject and vFormat June 2018
The key words "*Private Use*", "*Experimental Use*", "*Hierarchical
Allocation*", "*First Come First Served*", "*Expert Review*",
"*Specification Required*", "*RFC Required*", "*IETF Review*",
"*Standards Action*" and "*IESG Approval*" in this document are to be
interpreted as described in 4 [RFC8126].
Notation in this document is described in ABNF [RFC5234] as used by
[RFC6350].
Definitions from [RFC6350] apply to this specification except when
explicitly overridden.
All names of properties, property parameters, enumerated property
values, and property parameter values are case-insensitive. However,
all property values are case-sensitive, unless otherwise stated.
2.1. Definitions
vObject
the generalized data model of the vCard component (VCARD) and
iCalendar (VCALENDAR) component defined in this document
vFormat
the native serialization format of vObject, which is the textual
format representation using the "BEGIN:" and "END:" component
keywords
inner vObject, sub-component
a vObject located within a vObject
outer vObject, super-component
a vObject that this vObject is located within
Client User Application (CUA)
the vObject client implementation that interfaces with the user
calendar date
as defined in 2.1.8 [ISO.8601.2004]
3. vObject Data Model
The vObject data model is the generalized data model from the implied
data models of vCard [RFC6350] and iCalendar [RFC5545].
While both vCard [RFC6350] and iCalendar [RFC5545] specify data
formats for different purposes, the data model behind them follow an
identical logical structure (using components, properties and
parameters) with similar requirements.
Tse, et al. Expires December 10, 2018 [Page 9]
Internet-Draft vObject and vFormat June 2018
By creating a generalized data model ("vObject") that is compatible
with both, we are able to ensure that newly developed data
modification techniques for vObject would be interoperable on all
other vObject-compliant models.
3.1. vObject-compliant Models
The implied data models behind these formats are compliant to the
vObject data model:
o vCard version 4.0 [RFC6350]: the VCARD component
o Internet Calendaring and Scheduling Core Object Specification
(iCalendar) [RFC5545], the VCALENDAR, VEVENT, VJOURNAL, VFREEBUSY,
VTIMEZONE, VALARM, VTODO, STANDARD, DAYLIGHT components
o Calendar Availability Extensions [RFC7953]: the VAVAILABILITY,
AVAILABLE components
o iCalendar Patching [VPATCH]: the VPATCH component
3.2. Elements
Data within a vObject is arranged through a logical hierarchy
composed of the following elements:
o component;
o property;
o property parameter;
o property value;
o property parameter value; and
o property group.
The property group is optional and *MAY* not be accepted by all
vObject-compliant models.
Tse, et al. Expires December 10, 2018 [Page 10]
Internet-Draft vObject and vFormat June 2018
+-------------------+
| vObject Component |
+-------------------+
|
/ - - - - - - - - - - - - - - \
| | (Optional) |
| +----------------+
| +---| Property Group | |
| +----------------+
| | |
\ - - - - - - - - - - - - - - /
| +----------+
+---| Property |
+----------+
|
| +----------------+
+---| Property Value |
| +----------------+
|
| +--------------------+
+---| Property Parameter |
+--------------------+
|
| +--------------------------+
+---| Property Parameter Value |
+--------------------------+
Figure 1: vObject Data Model Hierarchy
3.2.1. Equivalence
Two vObjects are considered identical in content if their normalized
forms are textually equivalent.
3.3. Component
A vObject is based on the representation of the "component" element.
All vObjects are composed of at least one component element.
A component:
o *MAY* contain vObject components;
o *MAY* contain properties; and
o *MUST* contain a uniqueness identifier property whose value is
called the component's "unique identifier".
Tse, et al. Expires December 10, 2018 [Page 11]
Internet-Draft vObject and vFormat June 2018
A component type is identified by the component name, and every
component instance is distinguished by the value of its uniqueness
identifier property.
A component is often used to model an object in the object-oriented
sense, such as a vCard or an iCalendar object.
The order of components *MAY* represent order of the objects, which
is important for example in a "VPATCH" component [VPATCH],
representing the patching order, which is not a commutative process.
3.3.1. Uniqueness Identifying Property
As a vObject component can contain inner components, it is important
that those inner components can be distinguished from each other.
A vObject component's uniqueness identifier property is a property
whose value can uniquely identify the immediate component that
contains it.
Every vObject component *MUST* contain a single, component uniqueness
identifier property. The uniqueness identifier property can be
different according to component types, and the uniqueness scope of
that property *MAY* be different. At a minimum, the uniqueness
identifier property value *MUST* be unique within the immediate
component that contains the uniqueness identifier property.
For example:
o a "VCARD" component can be distinguished among other "VCARD"
components by its "UID" property value that is globally unique;
o a "STANDARD" component of "VTIMEZONE" can be distinguished
according to its "DTSTART" property within the "VTIMEZONE"
component that contains it.
The list of uniqueness identifier properties for every vObject
component that complies with this document can be found in the IANA
registry described in Section 11.2.
New vObject components defined according to this document *MUST*
define a uniqueness identifier property for that component, and it
*MUST* be registered in the said IANA registry.
Tse, et al. Expires December 10, 2018 [Page 12]
Internet-Draft vObject and vFormat June 2018
3.3.2. Normalizing A Component
3.3.2.1. Sorted Component Properties
Properties *MUST* be first normalized and before sorted, meaning that
the property's values, and its parameters and its values, have been
normalized.
The sorting of component properties *MUST* be performed according to
the following order:
o alphabetically by the property name. If a property spans multiple
content lines, the content lines *MUST NOT* be separated after
sorting.
o alphabetically by their normalized value.
o alphabetically by treating its parameters as long strings
3.3.2.2. Sorted Inner Components
Inner components within a vObject must be placed in a sorted order.
The sorting between components *MUST* be performed according to the
following order:
o alphabetically by component type, according to component name,
such as "VCALENDAR"; then
o if of the same component name, alphabetically according to its
unique identifier Section 3.3.1.
3.3.2.3. Normalized Inner Components
An inner component *MUST* itself be normalized, meaning that its
properties and inner components *MUST* be normalized.
3.3.3. vObject Property
Properties represent attributes of the vObject itself.
A property:
o *MUST* contain a value;
o *MAY* contain one or more property parameters.
vObject property value types are listed in Section 3.3.4.
Tse, et al. Expires December 10, 2018 [Page 13]
Internet-Draft vObject and vFormat June 2018
3.3.3.1. Normalized Values
A normalized property *MUST* have normalized values.
3.3.3.2. Normalized Parameters
A normalized property *MUST* have normalized property parameters.
Property parameters within the same property *MUST* each be
normalized, and then sorted by parameter name alphabetically.
Property parameters of the same property *MUST* have unique names.
3.3.4. Property Value
A vObject property *MAY* have one or more values, depending on the
value type.
vObject property values are strongly typed, just like in [RFC5545]
and [RFC6350]. Basic value types accepted in vObject properties are
defined in Section 5.
vObject compliant formats *MAY* define additional value types that
are not provided in this document, and *MAY* require separate
validation rules, such as the "RECUR" property value type from
iCalendar [RFC5545].
Each property *MUST* define a default value type, and *MAY* accept
alternative, defined, value types.
3.3.5. Normalization Of Property Values
The property value generally does not require any normalization.
Please consult individual normalization instructions in each value
type's definition.
3.3.6. Property Parameter
A property parameter is an attribute that applies on a property.
A property parameter contains:
o an identifier identifying its type;
o the value of the property parameter.
A property parameter *MAY* represent:
Tse, et al. Expires December 10, 2018 [Page 14]
Internet-Draft vObject and vFormat June 2018
o information about the property; or
o information about the property value
A property *MAY* have multiple property parameters, for example, the
"TYPE" of the value or a category that applies to this value.
3.3.6.1. Value Lists
Certain property parameters allow multiple values. There is no
defined order among property parameters in a property parameter list.
In normalized form, values in a value list *MUST* be sorted
alphabetically.
3.3.7. Default Property Parameter Values
Property parameters are allowed to have a default value.
For example, in vObject formats including [RFC5545] and [RFC6350],
each property value has a specified data type specified as the
"VALUE" property parameter.
3.3.8. Property Parameter Value
vObject property parameter values are strongly typed, just like
vObject properties, [RFC5545] and [RFC6350]. Basic value types
accepted in vObject property parameter values are defined in
Section 5.
A property parameter value **MAY* contain none, one or several
property parameter values. No order is defined among a list of
property parameter values.
vObject compliant formats *MAY* define additional value types that
are not provided in this document, and *MAY* require separate
validation rules, such as the values accepted by the "FBTYPE"
property parameter in iCalendar [RFC5545].
Each property parameter *MUST* define its accepted value type. While
a property *MAY* accept multiple alternative value types, a property
parameter value *MUST* only accept one value type.
3.3.9. Normalizing Multiple Parameter Values
Property parameter values within a property parameter is considered
sorted by value.
Tse, et al. Expires December 10, 2018 [Page 15]
Internet-Draft vObject and vFormat June 2018
3.3.10. Property Group
A property group (or just "group") is used to group a set of
properties, useful to represent cases where a group of properties are
closely related to each other.
In the vCard [RFC6350], the group is used to tie multiple properties
into being displayed together.
Each property *MUST* only have a maximum of one group.
Groups are not ordered and group names are case-insensitive.
4. vFormat Syntax
The "vFormat" format is the generalized syntax from the vCard
[RFC6350] and iCalendar [RFC5545] formats, and is the native format
for vObject serialization ("vObject native format").
vFormat is called the "native" format for vObjects to distinguish it
from alternative representations of vObject data, such as their XML
(xCal, xCard) or JSON (jCal, jCard) representations.
Its syntax originated from the textual representation of the
iCalendar and vCard formats, and is mostly traceable back to the
original vCard and iCalendar specifications [vCard21].
Both of these formats are considered "instances" (or "downstream
formats") of vFormat, and fully adhere to vFormat requirements.
Parsing and modification operations that work on vFormat *SHOULD*
work on all its instances, including iCalendar [RFC5545] and vCard
[RFC6350].
4.1. ABNF Format Definition
The following ABNF notation defines the vFormat syntax, in accordance
with [RFC5234], which also defines CRLF, WSP, DQUOTE, VCHAR, ALPHA,
and DIGIT.
A vObject is defined by the following notation in vFormat:
vobjects = 1*vobject
vobject = "BEGIN:" comp-name CRLF
*contentline
*vobject
"END:" comp-name CRLF
Tse, et al. Expires December 10, 2018 [Page 16]
Internet-Draft vObject and vFormat June 2018
comp-name = name
prop-name = name
prop-values = prop-value / prop-list / prop-structured
prop-value = VALUE-CHAR
prop-list = prop-value *("," prop-value)
; An unordered list containing multiple property values
prop-structured = prop-value *(";" prop-value)
; A structured list that consist of multiple property fields
; for multiple property values
contentline = [group "."] prop-name params ":" prop-values CRLF
; Folding and unfolding procedures described in Section 3.2 of
; [RFC6350] applies:
; * When parsing a content line, folded lines *MUST* first be
; unfolded accordingly.
; * When generating a content line, lines longer than 75
; characters *SHOULD* be folded accordingly.
; * When normalizing a content line, the content line *MUST*
; be folded when the line is longer than 75 characters.
group = name
params = *(";" param)
param = name "=" param-value *("," param-value)
; Allowed parameters depend on property name.
name = 1*(ALPHA / DIGIT / "-")
NON-ASCII = UTF8-2 / UTF8-3 / UTF8-4
; UTF8-{2,3,4} are defined in <<RFC3629>>
; TODO: generalize this to UTF-32
QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII
; Any character except CTLs, DQUOTE
SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
; Any character except CTLs, DQUOTE, ";", ":"
VALUE-CHAR = WSP / VCHAR / NON-ASCII
; Any textual character
Tse, et al. Expires December 10, 2018 [Page 17]
Internet-Draft vObject and vFormat June 2018
4.2. Component
A component:
o begins with line of text that starts with "BEGIN:" following with
its component name, ending with a line break;
o ends with a line of text that starts with "END:" following with
its component name (matching with the "BEGIN:" line), ending with
a line break.
The vCard [RFC6350] and iCalendar [RFC5545] data formats both conform
to vFormat, and their syntaxes are considered to be restricted
instances of the vObject syntax.
4.2.1. Component Name In Uppercase
The component name of a vObject *MUST* be uppercased, for both the
"BEGIN:" and "END:" content lines.
Example:
"BEGIN:vCard"
Should be normalized to:
"BEGIN:VCARD"
4.2.2. Order Of Inner Components And Properties
Properties *MUST* be placed before inner components are listed.
4.2.3. Maintain Validity
Certain vObject formats places certain restrictions or requirements
on property line locations. Normalization procedures *MUST NOT*
affect the validity of the normalized vObject.
For example, in the VCARD component [RFC6350], the "VERSION" property
line is *REQUIRED* to be placed immediately below the "BEGIN" line.
In this case, when normalizing the VCARD component, the common
normalization procedure *MUST* be first applied, and the "VERSION"
property line *MUST* be restored to the valid location as required by
its specifications [RFC6350].
Tse, et al. Expires December 10, 2018 [Page 18]
Internet-Draft vObject and vFormat June 2018
4.3. Property
A property can be represented by one content line (a line that ends
with a line break), but can also be "folded" (3.1 [RFC5545]) to use
multiple lines.
A property begins with the property name (e.g., "TEL"), followed by a
COLON delimiter and the property's value.
4.3.1. Uppercased Property Name
The property name *MUST* be normalized to uppercase letters.
4.3.2. Normalized Parameters
The last property parameter of a property *MUST NOT* have a trailing
SEMICOLON.
4.3.3. Wrapped Content Line
When exporting a normalized property content line, it *MUST* be
folded at the character limit when it exceeds 75 characters. Each
folded line *MUST* be delimited by the character sequence of a line
break and a single white space (CRLF, SPACE (U+0020)). This rule
only applies to normalized output.
For example, the original form:
NOTE:This is a very long description on a long line that exceeds 75 characters.
When exported to normalized output *MUST* give out:
NOTE:This is a very long description on a long line that exceeds 75 charac
ters.
4.4. Property Value
The property's values are defined as the content after the property
name and COLON delimiter, until the end of the unfolded content line.
If a property accepts multiple values, the definition of delimitation
is defined in Section 5.
vObject compliant formats that defines additional value types *MAY*
require separate validation rules on top of vFormat syntax.
Tse, et al. Expires December 10, 2018 [Page 19]
Internet-Draft vObject and vFormat June 2018
If the property value type of a property value is not the default
value type, the "VALUE" parameter *MUST* be present to specify the
type of the property value.
vFormat representation of different value types are provided in
Section 5.
4.4.1. Normalizing Property Values
The property value generally does not require any normalization.
4.5. Property Parameter
Property parameters exist between the property name and the COLON
delimiter in a property line.
Each property parameter in a list of property parameters *MUST* be
separated by a SEMICOLON character.
The property parameter name and the property parameter value is
separated with an equal sign ("=").
4.5.1. Multiple Property Parameters
If the property accepts multiple property parameters values, they
*MUST* be separated by a SEMICOLON character as a list.
4.5.2. Expanded Form Of Property Parameter Value List
When there are multiple instances of a property parameter on the same
property, such as in "TYPE=home;TYPE=work", it is considered
equivalent to "TYPE=home\,work".
4.5.3. Uppercased Property Parameter Names
The property parameter name *MUST* be normalized into uppercase
letters in form of a Unicode string (7 [RFC8259]).
Property parameter names (together with their values) *MUST* be
sorted alphabetically.
Example:
"TEL;VALUE=uri;type=home:tel:+1-888-888-8888"
The normalized form is:
"TEL;TYPE="home";VALUE="uri":tel:+1-888-888-8888"
Tse, et al. Expires December 10, 2018 [Page 20]
Internet-Draft vObject and vFormat June 2018
4.5.4. Join Identical Property Parameter Names
If a property parameter occurs more than once within a property, the
property parameter is considered to contain a list of property
parameter values joined by the parameter separator.
Such instances of property parameters with identical names *MUST* be
joined into one instance with its value a sorted list of the property
parameter values.
For example, the vCard "TEL" property's "TYPE" parameter [RFC6350]
describes that "TYPE=home,work" and "TYPE=work;TYPE=home" are
considered equivalent.
Example:
"TEL;TYPE=home;Type=work;VALUE=uri:tel:+1-888-888-8888"
The normalized form is:
"TEL;TYPE="home","work";VALUE=uri:tel:+1-888-888-8888"
4.5.5. Express Default Property Value Types
In vObject formats including [RFC5545] and [RFC6350], each property
value has a specified data type either as specified by property
definition or optionally assigned.
When normalizing a property, the property data value type *MUST*
always be specified. If the value type is not explicitly specified,
it *MUST* be filled in according to the vObject format.
Example:
"TEL:+1-888-888-8888"
The normalized form is:
"TEL;VALUE="text":+1-888-888-8888"
4.6. Property Parameter Value
While a property parameter value may accept any vObject value type,
the serialization rules of a vFormat property value and a vFormat
property parameter value are different, due to further limitations of
allowed characters in property parameter values.
Tse, et al. Expires December 10, 2018 [Page 21]
Internet-Draft vObject and vFormat June 2018
4.6.1. Format Definition
param-value = param-single-value *("," param-single-value)
param-single-value = paramtext / quoted-string
paramtext = *SAFE-CHAR
quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
; Any character except CONTROL and DQUOTE
SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
/ NON-US-ASCII
; Any character except CONTROL, DQUOTE, ";", ":", ","
NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC3629]
CONTROL = %x00-08 / %x0A-1F / %x7F
; All the controls except HTAB
4.6.2. Description
In vFormat, if a property parameter accepts multiple values, these
value elements *MUST* be separated by a COMMA (U+002C).
The DQUOTE character is used as a delimiter for parameter values that
contain restricted characters or URI text.
Property parameter values that contain the COLON (U+003A), SEMICOLON
(U+003B) (such as the "LIST" and "MAP" value types), or COMMA
(U+002C) character separators *MUST* be specified as quoted-string
text values.
Property parameter values that contain the DQUOTE (U+0022) character
*MUST* be escaped and specified as quoted-string text values.
An intentional line break *MUST* be represented by the sequence of
"\n" or "\N" (BACKSLASH followed by a LATIN SMALL LETTER N (U+006E)
or a LATIN CAPITAL LETTER N (U+004E)).
Property parameter values that are not in quoted-strings are case-
insensitive.
Tse, et al. Expires December 10, 2018 [Page 22]
Internet-Draft vObject and vFormat June 2018
4.6.3. Example
The value "cid:part1.0001@example.org" in the parameter "ALTREP"
within a "DESCRIPTION" property in iCalendar can be specified like
this:
DESCRIPTION;ALTREP="cid:part1.0001@example.org":The Fall'98 Wild
Wizards Conference - - Las Vegas\, NV\, USA
4.6.4. Normalization of Line Breaks
In vFormat, vObject property parameter values *MUST* convert all line
breaks ("\n" or "\N") into the character sequence "\n" (BACKSLASH
followed by a LATIN SMALL LETTER N (U+006E)).
If a value is specified as "paramtext" (i.e., not inside a quoted-
string), the value *SHOULD* be down-cased.
4.6.5. Normalizing Parameter Values Via DQOUTE Wrapping
vFormat property parameter values *SHOULD* be individually wrapped
with the DQUOTE characters.
This is an example application of the rule from [RFC6350]:
"TEL;TYPE=home,work;VALUE=uri:tel:+1-888-888-8888"
The normalized vFormat output is:
"TEL;TYPE="home","work";VALUE="uri":tel:+1-888-888-8888"
4.7. Property Group
The syntax of a property group is defined in Section 4.1.
Property groups *MUST NOT* be removed during normalization. This is
contrary to [RFC6350] that allows stripping off groups.
5. vObject Value Types And Notation Syntax
vObject value types are identically defined for both:
o vObject property values; and
o vObject property parameter values.
Tse, et al. Expires December 10, 2018 [Page 23]
Internet-Draft vObject and vFormat June 2018
5.1. Value Type Notation
The vObject value type notation is used for defining the accepted
values within a vObject property or parameter values. It fully
covers all complete and exhaustive amongst all vObject-compliant
standards.
This notation syntax allows a vObject specification to define complex
value types by using one or more value primitives defined in the
sections below.
The purpose of this syntax is to provide a mechanism to all vObject
value definitions, such that any new vObject mechanism (such as, a
method that can be applied to any vObject) can ensure uniform
applicability on vObject values.
Value type mappings provided in Section 12, Section 14, and
Section 13 are denoted using the vObject value type syntax.
Implementation differences within Section 4 of the same value type
are described in Section 4.4 and Section 4.6.
5.2. Meta Value Types
Meta value types are used in conjunction with basic value types
(Section 5.3).
5.2.1. FIELDSET
Some properties and parameters require values defined in terms of
multiple parts.
This construct of multiple structured values is called a "FIELDSET".
Each value in FIELDSET *MUST* have the same value type as defined.
5.2.1.1. Value Type Notation
When used to describe a value type, the "FIELDSET(field-1-value-type,
...)" notation is defined as a structure of fields separated by the
SEMICOLON character, where each of its fields is of value type
"field-i-value-type", where "i" represents the index of the specific
field.
5.2.1.2. Example 1
The "CLIENTPIDMAP" property of [RFC6350] takes a tuple of "INTEGER"
and "URI".
Tse, et al. Expires December 10, 2018 [Page 24]
Internet-Draft vObject and vFormat June 2018
The notation in vObject given for its value type would be this
indicating that the first value is an INTEGER, while the latter value
is a URI:
FIELDSET(INTEGER, URI)
5.2.1.3. Example 2
The "N" property of [RFC6350] defines its value of having 5 values at
once, and each of these values are a LIST of TEXT.
The notation in vObject given for its value type would be this
indicating that there are 5 fields in this FIELDSET, and each value
element of it *MUST* be a LIST of TEXT elements:
FIELDSET(5\*LIST(TEXT))
5.2.1.4. Normalizing a FIELDSET
When normalizing a FIELDSET, each value *MUST* have been normalized,
but the order of FIELDSET elements *MUST NOT* be rearranged.
5.2.2. LIST
Properties and parameters *MAY* specify its value to be an unordered
list of values. There is no significance to the order of values in a
list.
This construct is called the "LIST". Each value in the LIST *MUST*
have the same value type.
5.2.2.1. Value Type Notation
The "LIST(value-type)" notation is used to describe this value type,
of a list of elements, where each of its elements is of value type
"value-type".
5.2.2.2. Example 1
The "NICKNAME" property of [RFC6350] defines its value to be an
unordered list of TEXT.
In vObject notation its value type is defined to be:
LIST(TEXT)
Tse, et al. Expires December 10, 2018 [Page 25]
Internet-Draft vObject and vFormat June 2018
5.2.2.3. Example 2
The "RECUR" property of [RFC5545] defines its value to be an
unordered list of ASSIGN.
In vObject notation its value type is defined to be:
LIST(KEYVALUE, ";")
5.2.2.4. Normalizing a LIST
When normalizing a LIST, each value of it *MUST* be normalized, and
the values *MUST* be sorted alphabetically.
For example, values of [RFC5545] RESOURCES, FREEBUSY, EXDATE, RDATE,
CATEGORIES, *MUST* be sorted alphabetically when normalized.
5.2.3. MAP
A "MAP" serves the function of a key-value table. It is realized
using the "LIST" value type with values of the value type "KEYVALUE".
Each value in the MAP *MUST* use the "KEYVALUE" value type.
There is no inherent order of the values within a MAP. Values within
its key value pairs *MAY* be of different value types as defined.
5.2.3.1. Value Type Notation
This value type is described using the "MAP(kv_1, kv_2, ...)"
notation, where each "kv_i" represents a property of the value type
KEYVALUE.
5.2.3.2. Example
The Recurrence Rule property ("RECUR") of [RFC5545] defines its value
to be a MAP.
In vObject notation its value type is defined to be:
Tse, et al. Expires December 10, 2018 [Page 26]
Internet-Draft vObject and vFormat June 2018
MAP(
KEYVALUE(FREQ, TEXT),
KEYVALUE(UNTIL, ISO-DATE-COMPLETE / ISO-DATE-TIME-BASIC),
KEYVALUE(COUNT, INTEGER),
KEYVALUE(INTERVAL, INTEGER),
KEYVALUE(BYSECOND, LIST(INTEGER)),
KEYVALUE(BYMINUTE, LIST(INTEGER)),
KEYVALUE(BYHOUR, LIST(INTEGER)),
KEYVALUE(BYDAY, LIST(INTEGER)),
KEYVALUE(BYMONTHDAY, LIST(INTEGER)),
KEYVALUE(BYYEARDAY, LIST(INTEGER)),
KEYVALUE(BYWEEKNO, LIST(INTEGER)),
KEYVALUE(BYMONTH, LIST(INTEGER)),
KEYVALUE(BYSETPOS, INTEGER),
KEYVALUE(WKST, TEXT)
)
5.2.3.3. Normalizing a MAP
When normalizing a MAP, each value of it *MUST* be normalized, and
the values *MUST* be sorted alphabetically according to its "key".
5.3. Basic Value Types
5.3.1. TEXT
This corresponds to the TEXT value type in 4.1 [RFC6350] and 3.3.11
[RFC5545].
5.3.1.1. Value Type Notation
TEXT
5.3.1.2. Purpose
This value type defines values that contain free-form, human-readable
text.
5.3.1.3. Format Definition
text = VALUE-CHAR
5.3.1.4. Associated parameters
o Language in which the text is represented can be controlled by the
"LANGUAGE" property parameter.
Tse, et al. Expires December 10, 2018 [Page 27]
Internet-Draft vObject and vFormat June 2018
5.3.1.5. Example
This multiple line value is a valid value for the NOTE property of
vCard:
TC VCARD
The Calendaring And Scheduling Consortium
July 20, 2017
5.3.2. URI
This corresponds to the URI value type in 4.2 [RFC6350] and 3.3.13
[RFC5545].
5.3.2.1. Value Type Notation
URI
5.3.2.2. Purpose
This value type defines values that are represented by data
referenced by a uniform resource identifier (URI), the value is what
the URI points to, not the URI itself.
5.3.2.3. Format Definition
uri = <As defined in Section 3 of [RFC3986]>
5.3.2.4. Description
When a property parameter value is a URI value type, the URI *MUST*
be specified as a quoted-string value.
5.3.2.5. Example
This following values for the PHOTO property of vCard are valid.
Example 1:
http://www.example.com/pub/photos/jqpublic.gif
Example 2:
data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...remainder of base64-encoded data...>
Tse, et al. Expires December 10, 2018 [Page 28]
Internet-Draft vObject and vFormat June 2018
5.3.2.6. Normalization
No normalization procedures are needed.
5.3.3. BOOLEAN
This corresponds to the BOOLEAN value types in 4.4 [RFC6350] and
3.3.2 [RFC5545].
5.3.3.1. Value Type Notation
BOOLEAN
5.3.3.2. Purpose
This value type is used to identify properties that contain either a
"TRUE" or "FALSE" Boolean value.
5.3.3.3. Format Definition
boolean = "TRUE" / "FALSE"
5.3.3.4. Description
Parsing of "TRUE" and "FALSE" values *SHOULD* be case-insensitive,
but a writer of such value *MUST* only output of this value type in
uppercase.
5.3.3.5. Examples
o TRUE
o false
o True
o FaLSe
5.3.3.6. Normalization
Values of the BOOLEAN data type *MUST* be normalized to uppercase,
i.e., the values "TRUE" and "FALSE".
5.3.4. INTEGER
The INTEGER-64 and INTEGER-32 value types corresponds to the INTEGER
value types in 4.5 [RFC6350] and in 3.3.8 [RFC5545] respectively.
Tse, et al. Expires December 10, 2018 [Page 29]
Internet-Draft vObject and vFormat June 2018
5.3.4.1. Value Type Notation
INTEGER
(INTEGER-32 for storing 32-bit integer, INTEGER-64 for storing 64-bit
integer)
5.3.4.2. Purpose
Representation of a signed integer value.
5.3.4.3. Format Definition
integer = (["+"] / "-") 1*DIGIT
5.3.4.4. Description
If a preceding sign is not specified, the value is assumed positive
"". While the format accepts the optional "" PLUS sign, a writer
that conforms to this document *SHOULD* not write the "+" sign for
clarity reasons.
The valid ranges for INTEGER-32 and INTEGER-64 are:
o INTEGER-32: -2147483648 (-2^31) to 2147483647 (2^31 - 1)
o INTEGER-64: -9223372036854775807 (-2^63) to 9223372036854775808
(2^63 - 1)
5.3.4.5. Examples
o 1234567890
o -1234567890
o +1234567890
o 432109876
5.3.4.6. Normalization
A positive integer when normalized *MUST* not have the optional "+"
sign.
Tse, et al. Expires December 10, 2018 [Page 30]
Internet-Draft vObject and vFormat June 2018
5.3.5. FLOAT
This corresponds to the FLOAT value types in 3.3.7 [RFC5545] and 4.6
[RFC6350].
5.3.5.1. Value Type Notation
FLOAT
5.3.5.2. Purpose
Representation of a real-number value.
5.3.5.3. Format Definition
float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT]
5.3.5.4. Description
If a preceding sign is not specified, the value is assumed positive
"+".
Implementations *MUST* support a precision equal or better than that
of the IEEE "binary64" format [IEEE.754.2008].
Scientific notation is disallowed.
5.3.5.5. Examples
o 20.30
o 1000000.0000001
o 1.333
o -3.14
5.3.5.6. Normalization
No normalization procedures are needed.
Trailing zeros, such as "100.10000" *MUST* be kept as it indicates
accuracy of the number.
Tse, et al. Expires December 10, 2018 [Page 31]
Internet-Draft vObject and vFormat June 2018
5.3.6. LANGUAGE-TAG
This corresponds to the LANGUAGE-TAG value type in 4.8 [RFC6350].
5.3.6.1. Value Type Notation
LANGUAGE-TAG
5.3.6.2. Purpose
Representing a language tag, as defined in [RFC5646].
5.3.6.3. Format Definition
Defined in [RFC5646].
5.3.6.4. Description
A single language tag
5.3.6.5. Examples
o de
o en-US
o sr-Cyrl
o zh-yue-HK
5.3.6.6. Normalization
The normalization procedure of the LANGUAGE-TAG data type follows the
procedure described in 2.1.1 [RFC5646].
o language codes *MUST* be written in lowercase ('mn' Mongolian)
o script codes *MUST* be in lowercase when the initial letter
capitalized ('Cyrl' Cyrillic)
o country codes *MUST* be capitalized ('MN' Mongolia)
As the language tag is comprised of a mixture of these components,
[RFC5646] provides a rule that applies this procedure across all
language tags:
o All subtags, including extension and private use subtags, *MUST*
use lowercase letters.
Tse, et al. Expires December 10, 2018 [Page 32]
Internet-Draft vObject and vFormat June 2018
o Except: two-letter subtags that neither appear at the start of the
tag nor occur after singletons *MUST* be in uppercase ("en-CA-
x-ca" or "sgn-BE-FR").
o Except: four-letter subtags that neither appear at the start of
the tag nor occur after singletons *MUST* be in titlecase ("az-
Latn-x-latn").
5.3.7. Binary
This corresponds to the BINARY value type in 3.3.1 [RFC5545].
5.3.7.1. Value Type Notation
BINARY
5.3.7.2. Purpose
This value type defines values that contain inline binary data
encoded in characters. For example, an inline "ATTACH" property of
an iCalendar object or an inline "PHOTO" property image inside a
vCard object.
5.3.7.3. Format Definition
binary = *(4b-char) [b-end]
; A "BASE64" encoded character string, as defined by [RFC4648].
b-end = (2b-char "==") / (3b-char "=")
b-char = ALPHA / DIGIT / "+" / "/"
5.3.7.4. Description
Property values with this value type *MUST* specify the parameter
"ENCODING" with parameter value "BASE64", and the inline binary data
*MUST* be character encoded using the "BASE64" encoding method
defined in [RFC2045].
5.3.7.5. Example
This value for the NOTE value of vCard:
The following is an example of a "BASE64" encoded binary value data
folded to 72 characters long:
Tse, et al. Expires December 10, 2018 [Page 33]
Internet-Draft vObject and vFormat June 2018
AAABAAEAEBAQAAEABAAoAQAAFgAAACgAAAAQAAAAIAAAAAEABAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAACAAAAAgIAAAICAgADAwMAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAAAAAABNEMQAAAAAAAk
QgAAAAAAJEREQgAAACECQ0QgEgAAQxQzM0E0AABERCRCREQAADRDJEJEQwAAAhA0QwEQAAAA
AEREAAAAAAAAREQAAAAAAAAkQgAAAAAAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
5.3.8. KEYVALUE
5.3.8.1. Value Type Notation
"KEYVALUE(key, value-type)"
5.3.8.2. Purpose
Representation of a key-value pair: a key "key" linked to a value of
value type "value-type".
5.3.8.3. Format Definition
assign-key = *(TSAFE-CHAR)
assign-value = prop-values
5.3.8.4. Description
This value type is a core component of the "MAP" value type.
If the "KEYVALUE" value is accepted within a list, the "key" value
must be unique amongst the list.
5.3.8.5. Examples
o key: "FREQ"; value: "WEEKLY"
o key: "BYHOUR"; value: "3,6,9"
o key: "BYWEEKNO"; value: "MO,TU,WE,TH,FR,SA"
5.3.8.6. Normalization
Its value *MUST* be normalized according to the "value-type" of that
value.
5.4. Date and Time Value Types
These date and time related value types are based on [ISO.8601.2004]
and [ISO.8601.2000].
Tse, et al. Expires December 10, 2018 [Page 34]
Internet-Draft vObject and vFormat June 2018
5.4.1. ISO-DATE-COMPLETE
This corresponds to the DATE value type in 3.3.4 [RFC5545].
5.4.1.1. Value Type Notation
ISO-DATE-COMPLETE
5.4.1.2. Purpose
Representation of a complete calendar date defined in
[ISO.8601.2004].
5.4.1.3. Format Definition
iso-date = iso-date-value
iso-date-value = iso-date-fullyear iso-date-month iso-date-mday
iso-date-fullyear = 4DIGIT
iso-date-month = 2DIGIT ;01-12
iso-date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31
;based on month/year
5.4.1.4. Description
This value format is based on the "basic format" calendar date
(specified in 4.1.2.2 [ISO.8601.2004] "Complete representations").
The value *MUST* be represented textually as "YYYYMMDD", with its
components "YYYY" a four-digit year, "MM" a two-digit month, and "DD"
a two-digit day of the month as described in the definition.
5.4.1.5. Example
The following represents July 1, 1997:
o 19970701
5.4.1.6. Normalization
No normalization procedures are needed.
5.4.2. ISO-DATE-FLEX
Representation of a calendar date [ISO.8601.2004] that does not
require complete representation.
This corresponds to the DATE value type in 4.3.1 [RFC6350].
Tse, et al. Expires December 10, 2018 [Page 35]
Internet-Draft vObject and vFormat June 2018
5.4.2.1. Value Type Notation
ISO-DATE-FLEX
5.4.2.2. Purpose
This value type defines a calendar date format that allows entry of a
complete calendar date [ISO.8601.2004], a reduced accuracy date
[ISO.8601.2004] and a truncated date [ISO.8601.2004].
5.4.2.3. Format Definition
iso-date-flex = iso-date /
iso-date-reduced /
iso-date-truncated
iso-date-reduced = iso-date-fullyear / iso-date-year-month
iso-date-year-month = iso-date-fullyear "-" iso-date-month
iso-date-truncated = iso-date-truncated-month-day /
iso-date-truncated-month-only /
iso-date-truncated-day-only
iso-date-truncated-month-day = "--" iso-date-month iso-date-mday
iso-date-truncated-month-only = "--" iso-date-month
iso-date-truncated-day-only = "---" iso-date-mday
5.4.2.4. Description
This value format accepts:
o a complete calendar date, specified in 4.1.2.2 [ISO.8601.2004]
"Complete representations",
o a reduced accuracy calendar date, specified in 4.1.2.3
[ISO.8601.2004] "Representations with reduced accuracy", and
o a truncated representation calendar date, specified in 5.2.1.3
[ISO.8601.2000] "Truncated representations".
The value can be represented in these ways:
o "YYYYMMDD" Complete representation basic format, specified in
4.1.2.2 [ISO.8601.2004].
o "YYYY-MM" Reduced accuracy representation, specified in 4.1.2.3 a)
[ISO.8601.2004].
Tse, et al. Expires December 10, 2018 [Page 36]
Internet-Draft vObject and vFormat June 2018
o "YYYY" Reduced accuracy representation, specified in 4.1.2.3 b)
[ISO.8601.2004].
o "--MMDD" Truncated representation for a specific day of a month in
the implied year, basic format, specified in 5.2.1.3 d)
[ISO.8601.2000].
o "--MM" Truncated representation for a specific month in the
implied year, basic format, specified in 5.2.1.3 e)
[ISO.8601.2000].
o "---DD" Truncated representation for a specific day in the implied
month, basic format, specified in 5.2.1.3 f) [ISO.8601.2000].
Example:
o 20170712
o 2017-07
o 2017
o --0712
o --07
o ---12
5.4.2.5. Normalization
No normalization procedures are needed.
5.4.3. ISO-TIME-COMPLETE
This corresponds to the "time" portion of the TIMESTAMP value type in
4.3.5 [RFC6350].
5.4.3.1. Value Type Notation
ISO-TIME-COMPLETE
5.4.3.2. Purpose
Representation of a complete time of day with a UTC offset
[ISO.8601.2004].
Tse, et al. Expires December 10, 2018 [Page 37]
Internet-Draft vObject and vFormat June 2018
5.4.3.3. Format Definition
iso-time = time-hour time-minute time-second
[iso-time-utc / iso-utc-offset]
iso-time-hour = 2DIGIT ;00-23
iso-time-minute = 2DIGIT ;00-59
iso-time-second = 2DIGIT ;00-60
;The "60" value is used to account for positive "leap" seconds.
iso-time-utc = "Z"
5.4.3.4. Description
This value format accepts a time of day value specified as:
o "hhmmss", the basic format of 4.2.2.2 [ISO.8601.2004] "Complete
representations".
o "hhmmssZ", the first basic format of 4.2.4 [ISO.8601.2004] "UTC of
day".
o "hhmmss+/-hhmm", "hhmmss+/-hh", the basic formats of 4.2.5.2
[ISO.8601.2004] "Local time and the difference from UTC"
The components mean: "hh" a two-digit, 24-hour of the day (00-23),
"mm" a two-digit minute in the hour (00-59), and "ss" a two-digit
second in the minute (00-60).
The seconds value of 60 *MUST* only be used to account for positive
"leap" seconds. Fractions of a second are not supported by this
format.
This value indicates "local time" as specified in 2.1.16
[ISO.8601.2004]. To indicate UTC time, a "Z" character *MUST* be
appended to the basic format as described in 4.2.4 [ISO.8601.2004]
"UTC of day". To indicate a UTC offset, the "utc-offset" section
*MUST* be specified in accordance with 4.2.5.2. [ISO.8601.2004]
The value of "hhmmssZ" *MUST* be used instead of the equivalent
"hhmmss+0000" or "hhmmss-0000".
Example:
o 140000
o 140000Z
Tse, et al. Expires December 10, 2018 [Page 38]
Internet-Draft vObject and vFormat June 2018
o 140000-05
o 140000-0500
5.4.3.5. Normalization
No normalization procedures are needed.
5.4.4. ISO-TIME-BASIC
This corresponds to the TIME value type in 3.3.12 [RFC5545].
5.4.4.1. Value Type Notation
ISO-TIME-BASIC
5.4.4.2. Purpose
Representation of a complete time of day disallowing a UTC offset
[ISO.8601.2004].
5.4.4.3. Format Definition
iso-time-basic = iso-time-hour iso-time-minute iso-time-second
[iso-time-utc]
5.4.4.4. Description
This value format is similar to "TIME" except it disallows the
additional UTC offset, (the basic formats of 4.2.5.2 [ISO.8601.2004]
"Local time and the difference from UTC").
This value format accepts a time of day value specified as:
o "hhmmss", the basic format of 4.2.2.2 [ISO.8601.2004] "Complete
representations".
o "hhmmssZ", the first basic format of 4.2.4 [ISO.8601.2004] "UTC of
day".
The seconds value of 60 *MUST* only be used to account for positive
"leap" seconds. Fractions of a second are not supported by this
format.
This value indicates "local time" as specified in 2.1.16
[ISO.8601.2004]. To indicate UTC time, a "Z" character *MUST* be
appended to the basic format as described in 4.2.4 [ISO.8601.2004]
"UTC of day".
Tse, et al. Expires December 10, 2018 [Page 39]
Internet-Draft vObject and vFormat June 2018
Example:
o 232050
o 232050Z
5.4.4.5. Normalization
No normalization procedures are needed.
5.4.5. ISO-TIME-FLEX
This corresponds to the TIME value type in 4.3.2 [RFC6350].
5.4.5.1. Value Type Notation
ISO-TIME-FLEX
5.4.5.2. Purpose
This value type defines a time of day format that allows a entry of a
complete time of day [ISO.8601.2004], a reduced accuracy date
[ISO.8601.2004] and a truncated date representation [ISO.8601.2000].
5.4.5.3. Format Definition
iso-time-flex = iso-time /
iso-time-reduced /
iso-time-truncated
iso-time-zone = iso-time-utc / iso-time-utc-offset
iso-time-reduced = iso-time-reduced-hour-minute /
iso-time-hour
iso-time-reduced-hour-minute = iso-time-hour iso-time-minute
iso-time-truncated = iso-time-truncated-minute-second /
iso-time-truncated-minute-only /
iso-time-truncated-second-only
iso-time-truncated-minute-second = "-" iso-time-minute iso-time-second
iso-time-truncated-minute-only = "-" iso-time-minute
iso-time-truncated-second-only = "--" iso-time-second
Tse, et al. Expires December 10, 2018 [Page 40]
Internet-Draft vObject and vFormat June 2018
5.4.5.4. Description
This value format accepts:
o a complete time of day, specified in 4.2.2.2 [ISO.8601.2004]
"Complete representations",
o a reduced accuracy time of day, specified in 4.2.2.3
[ISO.8601.2004] "Representations with reduced accuracy",
o and a truncated representation time of day, specified in 5.3.1.4
[ISO.8601.2000] "Truncated representations".
The value can be represented in these ways:
o "hhmmss" Complete representation basic format, specified in
4.2.2.2 [ISO.8601.2004].
o "hhmm" Reduced accuracy representation basic format for a specific
hour and minute, specified in 4.2.2.3 a) [ISO.8601.2004].
o "hh" Reduced accuracy representation basic format for a specific
hour, specified in 4.2.2.3 b) [ISO.8601.2004].
o "-mmss" Truncated representation for a specific minute and second
of the implied hour, specified in 5.3.1.4 a) [ISO.8601.2000].
o "-mm" Truncated representation for a specific minute of the
implied hour, specified in 5.3.1.4 b) [ISO.8601.2000].
o "--ss" Truncated representation for a specific second of the
implied minute, specified in 5.3.1.4 c) [ISO.8601.2000].
The seconds value of 60 *MUST* only be used to account for positive
"leap" seconds. Fractions of a second are not supported by this
format.
This value indicates "local time" as specified in 2.1.16
[ISO.8601.2004]. To indicate UTC time, a "Z" character *MUST* be
appended to the basic format as described in 4.2.4 [ISO.8601.2004]
"UTC of day".
This format requires the midnight hour to be represented by "00"
(4.2.3 a) [ISO.8601.2004]), not "24" (4.2.3 b) [ISO.8601.2004]).
This format supports the specification of UTC offsets for the
complete representation basic format (defined in 4.2.5.2
[ISO.8601.2004] basic format), in the form of "hhmmss+/-HHMM".
Tse, et al. Expires December 10, 2018 [Page 41]
Internet-Draft vObject and vFormat June 2018
"HHMM" is the hour and minute of UTC offset, defined in 4.2.5.1
[ISO.8601.2004] basic format.
Example:
o 102200
o 1022
o 10
o -2200
o --00
o 102200Z
o 102200+0800
5.4.5.5. Normalization
No normalization procedures are needed.
5.4.6. ISO-UTC-OFFSET
This corresponds to the UTC-OFFSET value type in 4.7 [RFC6350].
5.4.6.1. Value Type Notation
ISO-UTC-OFFSET
5.4.6.2. Purpose
Representation of a UTC offset as described in [ISO.8601.2004].
5.4.6.3. Format Definition
sign = "+" / "-"
iso-utc-offset = sign iso-time-hour [iso-time-minute]
Description:
The value can be represented in two ways:
o "+/-hhmm" specified in 4.2.5.1 [ISO.8601.2004] "Difference between
local time and UTC of day", the first basic format.
Tse, et al. Expires December 10, 2018 [Page 42]
Internet-Draft vObject and vFormat June 2018
o "+/-hh" specified in 4.2.5.1 [ISO.8601.2004] "Difference between
local time and UTC of day", the second basic format.
The PLUS SIGN character MUST be specified for positive UTC offsets
(i.e., ahead of UTC). The HYPHEN-MINUS character MUST be specified
for negative UTC offsets (i.e., behind of UTC).
The value of "-00" and "-0000" are not allowed. The time-minute, if
present, MUST NOT be 60; if absent, it defaults to zero.
5.4.6.4. Example
The following UTC offsets are given for standard time for New York
(five hours behind UTC) and Geneva (one hour ahead of UTC):
o -05
o -0500
o +01
o +0100
5.4.6.5. Normalization
No normalization procedures are needed.
5.4.7. CAL-UTC-OFFSET
This corresponds to the UTC-OFFSET value type in 3.3.14 [RFC5545].
5.4.7.1. Value Type Notation
CAL-UTC-OFFSET
5.4.7.2. Purpose
Representation of a UTC offset as described in [RFC5545].
5.4.7.3. Format Definition
cal-utc-offset = sign iso-time-hour iso-time-minute [iso-time-second]
5.4.7.4. Description:
The value can be represented in two ways:
Tse, et al. Expires December 10, 2018 [Page 43]
Internet-Draft vObject and vFormat June 2018
o "+/-hhmm" specified in 4.2.5.1 [ISO.8601.2004] "Difference between
local time and UTC of day", the first basic format.
o "+/-hhmmss" which is unique to this value type.
The PLUS SIGN character MUST be specified for positive UTC offsets
(i.e., ahead of UTC). The HYPHEN-MINUS character MUST be specified
for negative UTC offsets (i.e., behind of UTC).
The value of "-0000" and "-000000" are not allowed. The time-second,
if present, MUST NOT be 60; if absent, it defaults to zero.
5.4.7.5. Example
The following UTC offsets are given for standard time for New York
(five hours behind UTC) and Geneva (one hour ahead of UTC):
o -0500
o -050000
o +0100
o +010000
5.4.7.6. Normalization
No normalization procedures are needed.
5.4.8. ISO-DATE-TIME-COMPLETE
This corresponds to the TIMESTAMP value type in 4.3.5 [RFC6350].
5.4.8.1. Value Type Notation
ISO-DATE-TIME-COMPLETE
5.4.8.2. Purpose
A complete date and time of day combination as specified in 4.3.2
[ISO.8601.2004]
5.4.8.3. Format Definition
iso-date-time = iso-date "T" iso-time
Tse, et al. Expires December 10, 2018 [Page 44]
Internet-Draft vObject and vFormat June 2018
5.4.8.4. Description
This value format accepts a complete date and time of day
representation, specified in 4.3.2 [ISO.8601.2004] "Complete
representations".
The value can be represented in these ways:
o "YYYYMMDDThhmmss" 4.3.2 Complete representation basic format,
first entry.
o "YYYYMMDDThhmmssZ" 4.3.2 Complete representation basic format,
second entry.
o "YYYYMMDDThhmmss+/-hhmm" 4.3.2 Complete representation basic
format, third entry.
o "YYYYMMDDThhmmss+/-hh" 4.3.2 Complete representation basic format,
fourth entry.
5.4.8.5. Examples
o 19850412T101530
o 19850412T101530Z
o 19850412T101530+0400
o 19850412T101530+04
5.4.8.6. Normalization
No normalization procedures are needed.
5.4.9. ISO-DATE-TIME-BASIC
This corresponds to the DATE-TIME value type in 3.3.5 [RFC5545].
5.4.9.1. Value Type Notation
ISO-DATE-TIME-BASIC
5.4.9.2. Purpose
A date and time of day combination without non-UTC timezone as
specified in 4.3.2 [ISO.8601.2004]
Tse, et al. Expires December 10, 2018 [Page 45]
Internet-Draft vObject and vFormat June 2018
5.4.9.3. Format Definition
iso-date-time-no-zone = iso-date "T" iso-time-basic
5.4.9.4. Description
This value format accepts a complete date and time of day
representation, specified in 4.3.2 [ISO.8601.2004] "Complete
representations", identical with ISO-DATE-TIME-COMPLETE, except that
the "utc-offset" portion is disallowed.
The value can be represented in these ways:
o "YYYYMMDDThhmmss" 4.3.2 Complete representation basic format,
first entry.
o "YYYYMMDDThhmmssZ" 4.3.2 Complete representation basic format,
second entry.
Due to the lack of "utc-offset", properties that use this value type
*SHOULD* handle time zone information with other methods such as in
property parameters, such as using the "TZID" property parameter
defined in [RFC5545].
5.4.9.5. Examples
o 19980118T230000
o 19980118T230000Z
5.4.9.6. Normalization
No normalization procedures are needed.
5.4.10. ISO-DATE-TIME-FLEX
This corresponds to the DATE-TIME value type in 4.3.3 [RFC6350].
5.4.10.1. Value Type Notation
DATE-TIME-FLEX
5.4.10.2. Purpose
This value type defines a date and time of day combination as
specified in 4.3 [ISO.8601.2004] and 5.4.2 c [ISO.8601.2000]).
Tse, et al. Expires December 10, 2018 [Page 46]
Internet-Draft vObject and vFormat June 2018
5.4.10.3. Format Definition
iso-date-time-flex = iso-date-time-flex-date "T" iso-date-time-flex-time
iso-date-time-flex-date = iso-date / iso-date-truncated
iso-date-time-flex-time = iso-time / iso-time-reduced
5.4.10.4. Description
This value format allows for the:
o truncation of the date portion and
o the reduced accuracy of the time portion
o according to the requirements of 5.4.2 [ISO.8601.2000]
"Representations other than complete" part c).
5.4.10.5. Examples
o 19961022T150236
o --1022T1502
o ---22T15
5.4.10.6. Normalization
No normalization procedures are needed.
5.4.11. ISO-DATE-AND-OR-TIME
This corresponds to the DATE-AND-OR-TIME value type in 4.3.4
[RFC6350].
5.4.11.1. Value Type Notation
ISO-DATE-AND-OR-TIME
5.4.11.2. Purpose
Representation of a ISO-DATE-FLEX, ISO-TIME-FLEX or an ISO-DATE-TIME-
FLEX value.
Tse, et al. Expires December 10, 2018 [Page 47]
Internet-Draft vObject and vFormat June 2018
5.4.11.3. Format Definition
iso-date-and-or-time = iso-date-flex /
"T" iso-time-flex /
iso-date-time-flex
5.4.11.4. Description
This value format accepts values of ISO-DATE-FLEX, ISO-TIME-FLEX and
ISO-DATE-TIME-FLEX.
A stand-alone ISO-TIME value *MUST* be preceded by a "T" for
unambiguous interpretation.
5.4.11.5. Example
o 19961022T140000
o --1022T1400
o ---22T14
o 19850412
o 1985-04
o 1985
o --0412
o ---12
o T102200
o T1022
o T10
o T-2200
o T--00
o T102200Z
o T102200-0800
Tse, et al. Expires December 10, 2018 [Page 48]
Internet-Draft vObject and vFormat June 2018
5.4.11.6. Normalization
No normalization procedures are needed.
5.4.12. ISO-DURATION-COMPLETE
This corresponds to the values accepted by "duration" as specified in
[ISO.8601.2004].
5.4.12.1. Value Type Notation
ISO-DURATION-COMPLETE
5.4.12.2. Purpose
Representing a duration of time specified by 4.4.3.2 [ISO.8601.2004]
complete representation basic format.
5.4.12.3. Format Definition
iso-duration-sign = ["+"] / "-"
iso-duration = ( iso-duration-sign ) "P" iso-duration-value
iso-duration-value = iso-duration-date / iso-duration-week
iso-duration-date = iso-duration-day "T" iso-duration-time
iso-duration-week = 1*DIGIT "W"
iso-duration-year = 1*DIGIT "Y"
iso-duration-month = 1*DIGIT "M"
iso-duration-day = 1*DIGIT "D"
iso-duration-time = iso-duration-hour iso-duration-minute
iso-duration-second
iso-duration-hour = 1*DIGIT "H"
iso-duration-minute = 1*DIGIT "M"
iso-duration-second = 1*DIGIT "S"
5.4.12.4. Description
The value format is based on the complete representation basic format
specified in 4.4.3.2. [ISO.8601.2004]
It accepts the following formats ("nn" represents):
Tse, et al. Expires December 10, 2018 [Page 49]
Internet-Draft vObject and vFormat June 2018
o "PnnW" 4.4.3.2 [ISO.8601.2004], complete representation, first
basic format, for duration in weeks.
o "PnnYnnMnnDTnnHnnMnnS" 4.4.3.2 [ISO.8601.2004], complete
representation, second basic format, for duration in years,
months, days, hours, minutes and seconds.
This format differs from the specification of 4.4.3.2 [ISO.8601.2004]
in the following areas:
o An optional, preceding "sign", element is used to indicate
positive or negative duration. Negative durations are useful in
representing reverse scheduling, such as the time to trigger an
alarm before an associated time (see [RFC5545]).
o Reduced accuracy as defined in 4.4.3.2 [ISO.8601.2004] is not
allowed. Omission of the number and corresponding designator of
days, hours, minutes or seconds is not allowed even if any of the
expressions are zero (4.4.3.2 [ISO.8601.2004] c)).
o The duration of a week or a day depends on its position in the
calendar.
In the case of discontinuities in the time scale, such as the change
from standard time to daylight time and back, the computation of the
exact duration requires the subtraction or addition of the change of
duration of the discontinuity. Leap seconds *MUST NOT* be considered
when computing an exact duration.
5.4.12.5. Examples
A duration of 15 days, 5 hours, and 20 seconds *MAY* be represented
as
o P0Y0M15DT5H0M20S
A duration of 7 weeks *MAY* be represented as:
o P7W
5.4.12.6. Normalization
No normalization procedures are needed.
Tse, et al. Expires December 10, 2018 [Page 50]
Internet-Draft vObject and vFormat June 2018
5.4.13. CAL-DURATION
This corresponds to the DURATION value type in 3.3.6 [RFC5545].
5.4.13.1. Value Type Notation
CAL-DURATION
5.4.13.2. Purpose
Representing a duration of time specified by 4.4.3.2 [ISO.8601.2004]
complete representation basic format, similar to ISO-DURATION, but
with syntax tailored to calendaring.
5.4.13.3. Format Definition
cal-duration = cal-duration-sign cal-duration-no-sign
cal-duration-sign = (["+"] / "-")
cal-duration-no-sign = "P" cal-duration-value
cal-duration-value = ( cal-duration-date /
cal-duration-time /
cal-duration-week )
cal-duration-date = cal-duration-day [cal-duration-time]
cal-duration-time = "T" ( cal-duration-hour /
cal-duration-minute /
cal-duration-second )
cal-duration-week = 1*DIGIT "W"
cal-duration-hour = 1*DIGIT "H" [cal-duration-minute]
cal-duration-minute = 1*DIGIT "M" [cal-duration-second]
cal-duration-second = 1*DIGIT "S"
cal-duration-day = 1*DIGIT "D"
5.4.13.4. Description
The value format is similar to ISO-DURATION and based on the complete
representation basic format specified in 4.4.3.2 [ISO.8601.2004], but
given extra flexibility to calendaring usage.
It accepts the following formats ("nn" represents):
o "PnnW" 4.4.3.2 [ISO.8601.2004], complete representation, first
basic format, for duration in weeks.
Tse, et al. Expires December 10, 2018 [Page 51]
Internet-Draft vObject and vFormat June 2018
o "PnnDTnnHnnMnnS" 4.4.3.2 [ISO.8601.2004], complete representation,
second basic format, with the omission of years and months, for
duration in days, hours, minutes and seconds.
o "PnnDTnnHnnM" Reduced accuracy with omission of seconds.
o "PnnDTnnH" Reduced accuracy with omission of minutes.
o "PnnD" Reduced accuracy with omission of hours.
This format differs from the specification of 4.4.3.2 [ISO.8601.2004]
in the following areas:
o Years and months are not accepted in this syntax.
o An optional, preceding "sign", element is used to indicate
positive or negative duration. Negative durations are useful in
representing reverse scheduling, such as the time to trigger an
alarm before an associated time (see [RFC5545]).
o Reduced accuracy is allowed for in particular, the omission of the
number and designators of hours, minutes or seconds is allowed
with the omission starting from the extreme right-hand side. In
the case of the omission of the time value, the "T" separator
*MUST* also be omitted. The day ("D") portion *MUST* always be
present.
o The duration of a week or a day depends on its position in the
calendar.
In the case of discontinuities in the time scale, such as the change
from standard time to daylight time and back, the computation of the
exact duration requires the subtraction or addition of the change of
duration of the discontinuity. Leap seconds *MUST NOT* be considered
when computing an exact duration.
When computing an exact duration, the greatest order time components
*MUST* be added first, that is, the number of days *MUST* be added
first, followed by the number of hours, number of minutes, and number
of seconds.
5.4.13.5. Example
A duration of 0 days, 0 hours, and 20 seconds *SHOULD* be represented
as
P0DT0H0M20S
Tse, et al. Expires December 10, 2018 [Page 52]
Internet-Draft vObject and vFormat June 2018
A duration of 15 days, 5 hours, and 3 hours *SHOULD* be represented
as
P15DT5H3M
A duration of 15 days, 5 hours *SHOULD* be represented as
P15DT5H
A duration of 15 days *SHOULD* be represented as
P15D
A duration of 7 weeks *SHOULD* be represented as:
P7W
5.4.13.6. Normalization
No normalization procedures are needed.
5.4.14. ISO-INTERVAL
This corresponds to the values accepted by "time interval" as
specified in [ISO.8601.2004].
5.4.14.1. Value Type Notation
ISO-INTERVAL-COMPLETE
5.4.14.2. Purpose
Representation of a time interval.
5.4.14.3. Format Definition
iso-interval = iso-interval-explicit / iso-interval-start
iso-interval-explicit = iso-date-time "/" iso-date-time
iso-interval-start = iso-date-time "/" iso-duration-no-sign
5.4.14.4. Description
This value format accepts a time interval representation, specified
in 4.4 [ISO.8601.2004] "Time Interval".
The value can be represented by:
Tse, et al. Expires December 10, 2018 [Page 53]
Internet-Draft vObject and vFormat June 2018
a) a start and an end;
o "YYYYMMDDThhmmss/YYYYMMDDThhmmss" 4.4.4.1 [ISO.8601.2004] Complete
representation, "Representations of time intervals identified by
start and end", basic format, first entry. The start *MUST* be
before the end.
c) a start and a duration;
o "YYYYMMDDThhmmss/PnnYnnMnnDTnnHnnMnnS" 4.4.4.3 [ISO.8601.2004]
Complete representation, "Representations of time interval
identified by start and duration", first basic format. The
duration component *MUST* be positive.
o "YYYYMMDDThhmmss/PnnW" 4.4.4.5 [ISO.8601.2004] Other complete
representations, third item, allowing the expression
"PnnYnnMnnDTnnHnnMnnS" to be substituted with "PnnW" 4.4.3.2
[ISO.8601.2004].
d) a duration and an end.
o "PnnYnnMnnDTnnHnnMnnS/YYYYMMDDThhmmss" 4.4.4.4 [ISO.8601.2004]
Complete representation, "Representations of time interval
identified by duration and end", first basic format. The start of
the interval can be determined by subtracting the duration
component from the end of the interval.
o "PnnW/YYYYMMDDThhmmss" 4.4.4.5 [ISO.8601.2004] Other complete
representations, third item, allowing the expression
"PnnYnnMnnDTnnHnnMnnS" to be substituted with "PnnW" 4.4.3.2
[ISO.8601.2004].
In accordance with 4.4.4.5 [ISO.8601.2004]:
o where representations using local time in a time point component
are shown, a complete representation of UTC (4.2.4
[ISO.8601.2004]) or local time and the difference from UTC
(4.2.5.2 [ISO.8601.2004]) *MAY* be substituted for local time,
i.e. representations using the expression "YYYYMMDDThhmmss" could
be substituted with any of these:
o "YYYYMMDDThhmmssZ" 4.3.2 Complete representation basic format,
second entry.
o "YYYYMMDDThhmmss+/-hhmm" 4.3.2 Complete representation basic
format, third entry.
Tse, et al. Expires December 10, 2018 [Page 54]
Internet-Draft vObject and vFormat June 2018
o "YYYYMMDDThhmmss+/-hh" 4.3.2 [ISO.8601.2004] Complete
representation basic format, fourth entry.
In accordance with 4.4.5 [ISO.8601.2004]:
o representations for UTC included with the component preceding the
solidus shall be assumed to apply to the component following the
solidus, unless a corresponding alternative is included.
5.4.14.5. Examples
o 19850412T232050/P1Y2M15DT12H30M0S
o 19850412T232050Z/P1Y2M15DT12H30M0S
o 19850412T232050Z/19850612T232050
o P1Y2M15DT12H30M0S/19850412T232050
5.4.14.6. Normalization
No normalization procedures are needed.
5.4.15. CAL-INTERVAL
This corresponds to the PERIOD value type in 3.3.9 [RFC5545].
5.4.15.1. Value Type Notation
CAL-INTERVAL
5.4.15.2. Purpose
Representation of a time interval for calendaring.
5.4.15.3. Format Definition
cal-interval = cal-interval-explicit / cal-interval-start
cal-interval-explicit = iso-date-time-no-zone "/" iso-date-time-no-zone
cal-interval-start = iso-date-time-no-zone "/" cal-duration-no-sign
5.4.15.4. Description
This value format accepts a time interval representation, specified
in 4.4. [ISO.8601.2004] "Time Interval" tailored for calendaring
purposes.
Tse, et al. Expires December 10, 2018 [Page 55]
Internet-Draft vObject and vFormat June 2018
The value can be represented in two ways.
As an interval with start and end:
o "YYYYMMDDThhmmss/YYYYMMDDThhmmss" 4.4.4.1 [ISO.8601.2004] Complete
representation, "Representations of time intervals identified by
start and end", basic format, first entry. The start *MUST* be
before the end.
As an interval with start and duration (positive duration only):
o "YYYYMMDDThhmmss/PnnDTnnHnnMnnS" 4.4.4.3 [ISO.8601.2004] Complete
representation, "Representations of time interval identified by
start and duration", first basic format, modified to omit the
"nnYnnM", which is the "cal-duration" period format.
o "YYYYMMDDThhmmss/PnnW" 4.4.4.5 [ISO.8601.2004] Other complete
representations, third item, allowing the expression
"PnnYnnMnnDTnnHnnMnnS" to be substituted with "PnnW" 4.4.3.2
[ISO.8601.2004].
o "YYYYMMDDThhmmss/PnnDTnnHnnM" with the duration specified in
reduced accuracy with omission of seconds as in Section 5.4.13.
o "YYYYMMDDThhmmss/PnnDTnnH" with the duration specified in reduced
accuracy with omission of minutes as in Section 5.4.13.
o "YYYYMMDDThhmmss/PnnD" with the duration specified in reduced
accuracy with omission of hours as in Section 5.4.13.
In accordance with 4.4.5 [ISO.8601.2004], representations for UTC
included with the component preceding the solidus shall be assumed to
apply to the component following the solidus, unless a corresponding
alternative is included.
5.4.15.5. Examples
o 19970101T180000Z/19970102T070000Z
o 19850412T232050/19850625T103000
o 19970101T180000Z/PT5H30M
o 19850412T232050/P15DT12H30M0S
o 19850412T232050/P00010215T123000
o Both components are in UTC: 19850412T232050Z/19850625T103000
Tse, et al. Expires December 10, 2018 [Page 56]
Internet-Draft vObject and vFormat June 2018
o Former component in local time, latter in UTC:
19850412T232050/19850625T103000
5.4.15.6. Normalization
No normalization procedures are needed.
6. Normalization
A normalization procedure can be applied to vObjects (in its various
representations) to make them compatible prior to comparison,
allowing for consistent results. The result of normalization
processing of a vObject, is an equivalent vObject described according
to vFormat representation.
The normalization method has the following properties:
o stable across different implementations generating the same output
from the same input
o compatible with alternative representation formats such as xCard
[RFC6351] / jCard [RFC7095] and xCal [RFC6321] / jCal [RFC7265]
o generates output adhering to the original vObject format allowing
interoperability with existing implementations
o generates output compatible with protocols that utilize these
vObject, such as CardDAV [RFC6352] and CalDAV [RFC4791] systems.
There are two levels of normalization.
o vObject normalization, of values and property parameter values,
are performed within the vObject data model;
o vFormat normalization, of the format syntax itself, is performed
during serialization of a vObject into vFormat.
6.1. Approach
The goals of the normalization procedure are:
o A normalized vObject will be a valid vObject in vFormat syntax.
Therefore the normalization procedure requires knowledge of the
source specific vObject format.
o A normalized vObject is stable across alternative representation
formats, such as xCal and jCal of iCalendar, and xCard and jCard
Tse, et al. Expires December 10, 2018 [Page 57]
Internet-Draft vObject and vFormat June 2018
of vCard. This allows comparison of vObject content regardless of
the representation format.
o Allows comparison of equivalence of content rather than
formatting. E.g., addition of new-lines within a vCard and order
of listed properties do not affect the resulting normalized form.
o A normalized vObject *MUST* maintain validity under the original
format rules, such as in the case of VCARD [RFC6350] components,
the "VERSION" property line *MUST* be located immediately after
the "BEGIN" property line.
6.2. Steps
In order to serialize a vObject into normalized vFormat syntax, one
would directly serialize the vObject data model into vFormat syntax.
The steps are generally described below.
1. Normalize the vObject
A. Normalize properties
i. Normalize property parameters
A. Normalize property parameter types
B. Normalize property parameter values
I. Sort property parameter values
alphabetically.
II. Concatenate property parameter values.
C. Normalize property parameter key: cast to
uppercase.
D. Concatenate string form of property parameter key,
value type and values.
ii. Normalize property values
B. Normalize inner vObjects (sub-components)
i. Perform the same function as (1)
Tse, et al. Expires December 10, 2018 [Page 58]
Internet-Draft vObject and vFormat June 2018
6.3. Application on alternative serializations
The normalization procedure applies to alternative vObject
representations as well, including:
o xCard [RFC6351]
o jCard [RFC7095]
o xCal [RFC6321]
o jCal [RFC7265]
To normalize a vObject provided in these representations, the vObject
data should be first normalized in data model form according to
Section 3, and then serialized into these representations.
7. Client Implementations Recommendations
A CUA *SHOULD* normalize the vObject upon modification of it.
8. CardDAV
8.1. Additional Server Semantics for PUT, COPY and MOVE
This specification creates an additional precondition and
postcondition for the PUT, COPY, and MOVE methods when:
o A PUT operation requests an address object resource to be placed
into an address book collection; and
o A COPY or MOVE operation requests an address object resource to be
placed into (or out of) an address book collection.
8.1.1. Provide Normalized Output
Certain servers perform silent changes or cleanups of client provided
vCard data when stored as address object resources, such as the order
of property parameters or scrubbed values.
The resulting vCard data stored on the server (and when returned back
to the client) *MAY* end up different than that of the client without
its knowledge. It is therefore necessary for the client to be
reported on such modifications.
Additional Postcondition:
(CARDDAV:resource-normalized): Convert to normalized format.
Tse, et al. Expires December 10, 2018 [Page 59]
Internet-Draft vObject and vFormat June 2018
9. CalDAV
9.1. Additional Server Semantics for PUT, COPY and MOVE
This specification creates an additional precondition and
postcondition for the PUT, COPY, and MOVE methods when:
o A PUT operation of a calendar object resource into a calendar
collection occurs [RFC4791];
o A COPY or MOVE operation of a calendar object resource into a
calendar collection occurs [RFC4791]; and
o A COPY or MOVE operation occurs on a calendar collection
[RFC4791].
9.1.1. Provide Normalized Output
Certain servers perform silent changes or cleanups of client provided
iCalendar data when stored as calendar object resources, such as the
order of property parameters or scrubbed values.
The resulting iCalendar data stored on the server (and when returned
back to the client) *MAY* end up different than that of the client
without its knowledge. It is therefore necessary for the client to
be reported on such modifications.
Additional Postcondition:
(CALDAV:resource-normalized): Convert to normalized format.
10. Security Considerations
Security considerations around vObject formats in the following
documents *MUST* be adhered to:
o vCard: [RFC6350]
o iCalendar: [RFC5545], [RFC5789], [RFC4791]
11. IANA Considerations
New vObject and vFormat specifications produced *MUST* adhere to the
requirements, including the normalization process, described in this
document, and any exceptions or further instructions for
normalization *MUST* be described.
Tse, et al. Expires December 10, 2018 [Page 60]
Internet-Draft vObject and vFormat June 2018
11.1. Common vObject Registries
The IANA has created and will maintain the following registries for
vObject elements with pointers to appropriate reference documents.
The registries are grouped together under the heading "vObject Common
Elements".
11.2. vObject Component Uniqueness Identifiers Registry
11.2.1. Registration Procedure
This section defines the process to register new or modified
uniqueness properties for vObject components with IANA.
The IETF will create a mailing list, vobject@ietf.org, which can be
used for public discussion of vObject elements prior to registration.
The registry policy is *Specification Required*; any newly proposed
specification *MUST* be reviewed by the designated expert.
The registry *SHOULD* contain the following note:
Note: Experts are to verify that the proposed registration
*SHOULD* provide benefits for the wider vObject community,
and provides a publicly-available standard that can be implemented in
an interoperable way. References to IETF-published documents are
preferred. The "Reference" value should point to a document that
details the implementation of this property.
The registration procedure begins when a completed registration
template, defined in the sections below, is sent to vobject@ietf.org
and iana@iana.org.
The designated expert is expected to tell IANA and the submitter of
the registration within two weeks whether the registration is
approved, approved with minor changes, or rejected with cause. When
a registration is rejected with cause, it can be re-submitted if the
concerns listed in the cause are addressed. Decisions made by the
designated expert can be appealed to the IESG Applications Area
Director, then to the IESG. They follow the normal appeals procedure
for IESG decisions.
11.2.2. Registration Template
A registration for a vObject Component Uniqueness Property is defined
by completing the following template.
Component
Tse, et al. Expires December 10, 2018 [Page 61]
Internet-Draft vObject and vFormat June 2018
The name of the component.
Property
The property of the component that is used to uniquely identify
the component it belongs to.
Scope
The uniqueness scope of the aforementioned property.
Reference
The document that defines the component syntax and the uniqueness
identifying property. Generally, this is where the component was
originally defined, but if the uniqueness property is defined in
an extension document, a reference to the extension document
*SHOULD* be given instead.
Description
Any special notes about the usage of the uniqueness identifying
property, how it is to be used, etc.
Example(s)
One or more examples of instances of the component need to be
specified.
11.2.3. Initial Registrations
The IANA created and maintains this registry for vObject Component
Uniqueness Identifiers with pointers to appropriate reference
documents.
The following table has been used to initialize the registry.
Tse, et al. Expires December 10, 2018 [Page 62]
Internet-Draft vObject and vFormat June 2018
+--------------+-------------+--------+-----------------------------+
| Component | Property | Scope | Reference |
+--------------+-------------+--------+-----------------------------+
| VCALENDAR | UID | Global | 5.3 [RFC7986] |
| VCARD | UID | Global | 6.7.6 [RFC6350] |
| VEVENT | UID | Global | 3.6.1 [RFC5545] |
| VTODO | UID | Global | 3.6.2 [RFC5545] |
| VJOURNAL | UID | Global | 3.6.3 [RFC5545] |
| VFREEBUSY | UID | Global | 3.6.4 [RFC5545] |
| VTIMEZONE | TZID | Global | 3.6.5 [RFC5545] |
| STANDARD | DTSTART | Parent | 3.6.5 [RFC5545] |
| DAYLIGHT | DTSTART | Parent | 3.6.5 [RFC5545] |
| VALARM | UID | Global | 4 [I-D.daboo-valarm-extensi |
| | | | ons] |
| VAVAILABILIT | UID | Global | 3.1 [RFC7953] |
| Y | | | |
| AVAILABLE | UID | Global | 3.1 [RFC7953] |
| VPOLL | UID | Parent | 4.5.1 [I-D.york-vpoll] |
| VVOTER | VOTER | Parent | 4.5.2 [I-D.york-vpoll] |
| VOTE | POLL-ITEM- | Parent | 4.5.3 [I-D.york-vpoll] |
| | ID | | |
+--------------+-------------+--------+-----------------------------+
12. Mapping Of Data Value Types For Existing RFCs
The vObject value types in this section are described using vObject
value type notation (see Section 5.1).
12.1. RFC 6350
+----------------------+---------------------+
| vObject Value Type | Original Value Type |
+----------------------+---------------------+
| BOOLEAN | BOOLEAN |
| ISO-DATE-FLEX | DATE |
| ISO-DATE-AND-OR-TIME | DATE-AND-OR-TIME |
| ISO-DATE-TIME-FLEX | DATE-TIME |
| FLOAT | FLOAT |
| INTEGER-64 | INTEGER |
| LANGUAGE-TAG | LANGUAGE-TAG |
| TEXT | TEXT |
| ISO-TIME-FLEX | TIME |
| ISO-TIME-COMPLETE | TIMESTAMP |
| URI | URI |
| ISO-UTC-OFFSET | UTC-OFFSET |
+----------------------+---------------------+
Tse, et al. Expires December 10, 2018 [Page 63]
Internet-Draft vObject and vFormat June 2018
12.2. RFC 5545
+---------------------------+---------------------+
| vObject Value Type | Original Value Type |
+---------------------------+---------------------+
| BINARY | BINARY |
| BOOLEAN | BOOLEAN |
| URI | CAL-ADDRESS |
| ISO-DATE-COMPLETE | DATE |
| ISO-DATE-TIME-BASIC | DATE-TIME |
| CAL-DURATION | DURATION |
| FLOAT | FLOAT |
| INTEGER-32 | INTEGER |
| CAL-DURATION | PERIOD |
| TEXT | TEXT |
| ISO-TIME-BASIC | TIME |
| URI | URI |
| CAL-UTC-OFFSET | UTC-OFFSET |
| RECURMAP (Section 12.2.1) | RECUR |
+---------------------------+---------------------+
12.2.1. RECURMAP
RECURMAP is shown here instead of within the tables due to space
constraints.
It is defined to be the value type of the following vObject value
type:
RECURMAP = MAP(
KEYVALUE(FREQ, TEXT),
KEYVALUE(UNTIL, ISO-DATE-COMPLETE / ISO-DATE-TIME-BASIC),
KEYVALUE(COUNT, INTEGER),
KEYVALUE(INTERVAL, INTEGER),
KEYVALUE(BYSECOND, LIST(INTEGER)),
KEYVALUE(BYMINUTE, LIST(INTEGER)),
KEYVALUE(BYHOUR, LIST(INTEGER)),
KEYVALUE(BYDAY, LIST(INTEGER)),
KEYVALUE(BYMONTHDAY, LIST(INTEGER)),
KEYVALUE(BYYEARDAY, LIST(INTEGER)),
KEYVALUE(BYWEEKNO, LIST(INTEGER)),
KEYVALUE(BYMONTH, LIST(INTEGER)),
KEYVALUE(BYSETPOS, INTEGER),
KEYVALUE(WKST, TEXT)
)
Tse, et al. Expires December 10, 2018 [Page 64]
Internet-Draft vObject and vFormat June 2018
13. Mapping Of Component Property Value Types For Existing RFCs
The default and alternative value types in this section are described
using vObject value type notation (see Section 5.1).
13.1. VCARD Component (RFC 6350)
Properties with the default data type as TEXT.
+-----------+-------------------+--------------+--------------------+
| Property | Default Value | Alt. Value | Original Value |
| | Type | Types | Type |
+-----------+-------------------+--------------+--------------------+
| BEGIN | TEXT | | 1\*TEXT |
| END | TEXT | | 1\*TEXT |
| KIND | TEXT | | 1\*TEXT |
| XML | TEXT | | 1\*TEXT |
| FN | TEXT | | 1\*TEXT |
| BDAY | ISO-DATE-AND-OR- | TEXT | 1\*date-and-or- |
| | TIME | | time, 1\*text |
| ANNIVERSA | ISO-DATE-AND-OR- | TEXT | 1\*date-and-or- |
| RY | TIME | | time, 1\*text |
| EMAIL | TEXT | | 1\*TEXT, |
| TZ | TEXT | URI, ISO- | 1\*TEXT, URI, UTC- |
| | | UTC-OFFSET | OFFSET |
| TITLE | TEXT | | 1\*TEXT |
| ROLE | TEXT | | 1\*TEXT |
| NOTE | TEXT | | 1\*TEXT |
| PRODID | TEXT | | 1\*TEXT |
| VERSION | TEXT | | 1\*TEXT |
+-----------+-------------------+--------------+--------------------+
Properties with the default data type as URI.
Tse, et al. Expires December 10, 2018 [Page 65]
Internet-Draft vObject and vFormat June 2018
+-----------+-----------------+-----------------+-------------------+
| Property | Default Value | Alt. Value | Original Value |
| | Type | Types | Type |
+-----------+-----------------+-----------------+-------------------+
| TEL | URI | TEXT | 1\*text, URI |
| SOURCE | URI | | URI |
| PHOTO | URI | | URI |
| IMPP | URI | | URI |
| GEO | URI | | URI |
| LOGO | URI | | URI |
| MEMBER | URI | | URI |
| RELATED | URI | TEXT | URI, 1\*text |
| UID | URI | | URI, 1\*text |
| KEY | URI | | URI, 1\*text |
| SOUND | URI | | URI |
| URL | URI | | URI |
| FBURL | URI | | URI |
| CALADRURI | URI | | URI |
| CALURI | URI | | URI |
+-----------+-----------------+-----------------+-------------------+
Properties with FIELDSET.
+--------------+-------------------------+-----------+--------------+
| Property | Default Value Type | Alt. | Original |
| | | Value | Value Type |
| | | Types | |
+--------------+-------------------------+-----------+--------------+
| N | FIELDSET(5\*LIST(TEXT)) | | TEXT |
| GENDER | FIELDSET(2\*TEXT) | | TEXT |
| ADR | FIELDSET(7\*LIST(TEXT)) | | TEXT |
| ORG | FIELDSET(1\*TEXT) | | TEXT |
| CLIENTPIDMAP | FIELDSET(INTEGER-64, | | TEXT |
| | URI) | | |
+--------------+-------------------------+-----------+--------------+
Properties with LIST.
+------------+------------------+----------------+------------------+
| Property | Default Value | Alt. Value | Original Value |
| | Type | Types | Type |
+------------+------------------+----------------+------------------+
| NICKNAME | LIST(TEXT) | | TEXT |
| CATEGORIES | LIST(TEXT) | | TEXT |
+------------+------------------+----------------+------------------+
Properties with ISO-DATE-AND-OR-TIME.
Tse, et al. Expires December 10, 2018 [Page 66]
Internet-Draft vObject and vFormat June 2018
+-------------+----------------------+----------+-------------------+
| Property | Default Value Type | Alt. | Original Value |
| | | Value | Type |
| | | Types | |
+-------------+----------------------+----------+-------------------+
| BDAY | ISO-DATE-AND-OR-TIME | TEXT | date-and-or-time, |
| | | | text |
| ANNIVERSARY | ISO-DATE-AND-OR-TIME | TEXT | date-and-or-time, |
| | | | text |
+-------------+----------------------+----------+-------------------+
Properties with ISO-DATE-TIME-COMPLETE.
+----------+------------------------+-------------+-----------------+
| Property | Default Value Type | Alt. Value | Original Value |
| | | Types | Type |
+----------+------------------------+-------------+-----------------+
| REV | ISO-DATE-TIME-COMPLETE | | timestamp |
+----------+------------------------+-------------+-----------------+
Properties with LANGUAGE-TAG.
+----------+-------------------+---------------+--------------------+
| Property | Default Value | Alt. Value | Original Value |
| | Type | Types | Type |
+----------+-------------------+---------------+--------------------+
| LANG | LANGUAGE-TAG | | language-tag |
+----------+-------------------+---------------+--------------------+
13.2. VCALENDAR Component (RFC 5545)
+---------------+-----------------+---------------+-----------------+
| Property | Default Value | Alt. Value | Original Value |
| | Type | Types | Type |
+---------------+-----------------+---------------+-----------------+
| PRODID | TEXT | | 1\*TEXT |
| VERSION | TEXT | | 1\*TEXT |
| CALSCALE | TEXT | | 1\*TEXT |
| METHOD | TEXT | | 1\*TEXT |
| IANA-REGed/X- | TEXT | | 1\*TEXT |
+---------------+-----------------+---------------+-----------------+
13.3. VEVENT Component (RFC 5545)
+--------------+-------------------+------------------+-------------+
| Property | Default Value | Alt. Value Types | Original |
| | Type | | Value Type |
+--------------+-------------------+------------------+-------------+
Tse, et al. Expires December 10, 2018 [Page 67]
Internet-Draft vObject and vFormat June 2018
| DTSTAMP | ISO-DATE-TIME- | | DATE-TIME |
| | BASIC | | |
| UID | TEXT | | 1\*TEXT |
| DTSTART | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, |
| | BASIC | COMPLETE | DATE |
| CLASS | TEXT | | 1\*TEXT |
| CREATED | ISO-DATE-TIME- | | DATE-TIME |
| | BASIC | | |
| DESCRIPTION | TEXT | | 1\*TEXT |
| GEO | FIELDSET(2\*FLOAT | | FLOAT ";" |
| | ) | | FLOAT |
| LAST- | ISO-DATE-TIME- | | DATE-TIME |
| MODIFIED | BASIC | | |
| LOCATION | TEXT | | 1\*TEXT |
| ORGANIZER | URI | | cal-address |
| PRIORITY | INTEGER-32 | | INTEGER |
| SEQUENCE | INTEGER-32 | | INTEGER |
| STATUS | TEXT | | 1\*TEXT |
| SUMMARY | TEXT | | 1\*TEXT |
| TRANSP | TEXT | | 1\*TEXT |
| URL | URI | | URI |
| RECURRENCE- | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, |
| ID | BASIC | COMPLETE | DATE |
| RRULE | RECURMAP (Section | | RECUR |
| | 12.2.1) | | |
| DTEND | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, |
| | BASIC | COMPLETE | DATE |
| DURATION | DURATION | | DURATION |
| ATTACH | URI | BINARY | URI, BINARY |
| ATTENDEE | URI | | cal-address |
| CATEGORIES | LIST(TEXT) | | TEXT |
| COMMENT | TEXT | | 1\*TEXT |
| CONTACT | TEXT | | 1\*TEXT |
| EXDATE | LIST( ISO-DATE- | | DATE-TIME, |
| | TIME-BASIC / ISO- | | DATE |
| | DATE-COMPLETE ) | | |
| RELATED-TO | TEXT | | 1\*TEXT |
| RESOURCES | LIST(TEXT) | | TEXT |
| RDATE | LIST( ISO-DATE- | | DATE-TIME, |
| | TIME-BASIC / ISO- | | DATE, |
| | DATE-COMPLETE / | | PERIOD |
| | CAL-INTERVAL) | | |
| IANA- | TEXT | | 1\*TEXT |
| REGed/X- | | | |
+--------------+-------------------+------------------+-------------+
Tse, et al. Expires December 10, 2018 [Page 68]
Internet-Draft vObject and vFormat June 2018
13.4. VTODO Component (RFC 5545)
+--------------+-------------------+------------------+-------------+
| Property | Default Value | Alt. Value Types | Original |
| | Type | | Value Type |
+--------------+-------------------+------------------+-------------+
| DTSTAMP | ISO-DATE-TIME- | | DATE-TIME |
| | BASIC | | |
| UID | TEXT | | 1\*TEXT |
| CLASS | TEXT | | 1\*TEXT |
| CREATED | ISO-DATE-TIME- | | DATE-TIME |
| | BASIC | | |
| COMPLETED | ISO-DATE-TIME- | | DATE-TIME |
| | BASIC | | |
| DESCRIPTION | TEXT | | 1\*TEXT |
| DTSTART | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, |
| | BASIC | COMPLETE | DATE |
| GEO | FIELDSET(2\*FLOAT | | FLOAT ";" |
| | ) | | FLOAT |
| LAST- | ISO-DATE-TIME- | | DATE-TIME |
| MODIFIED | BASIC | | |
| LOCATION | TEXT | | 1\*TEXT |
| ORGANIZER | URI | | cal-address |
| PRIORITY | INTEGER-32 | | INTEGER |
| SEQUENCE | INTEGER-32 | | INTEGER |
| STATUS | TEXT | | 1\*TEXT |
| SUMMARY | TEXT | | 1\*TEXT |
| URL | URI | | URI |
| RRULE | RECURMAP (Section | | RECUR |
| | 12.2.1) | | |
| DUE | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, |
| | BASIC | COMPLETE | DATE |
| DURATION | DURATION | | DURATION |
| ATTACH | URI | BINARY | URI, BINARY |
| ATTENDEE | URI | | cal-address |
| CATEGORIES | LIST(TEXT) | | TEXT |
| COMMENT | TEXT | | 1\*TEXT |
| CONTACT | TEXT | | 1\*TEXT |
| EXDATE | LIST( ISO-DATE- | | DATE-TIME, |
| | TIME-BASIC / ISO- | | DATE |
| | DATE-COMPLETE ) | | |
| REQUEST- | TEXT | | 1\*TEXT |
| STATUS | | | |
| RELATED-TO | TEXT | | 1\*TEXT |
| RESOURCES | LIST(TEXT) | | TEXT |
| RDATE | LIST( ISO-DATE- | | DATE-TIME, |
| | TIME-BASIC / ISO- | | DATE, |
| | DATE-COMPLETE / | | PERIOD |
Tse, et al. Expires December 10, 2018 [Page 69]
Internet-Draft vObject and vFormat June 2018
| | CAL-INTERVAL) | | |
| IANA- | TEXT | | 1\*TEXT |
| REGed/X- | | | |
+--------------+-------------------+------------------+-------------+
13.5. VJOURNAL Component (RFC 5545)
+--------------+-------------------+------------------+-------------+
| Property | Default Value | Alt. Value Types | Original |
| | Type | | Value Type |
+--------------+-------------------+------------------+-------------+
| DTSTAMP | ISO-DATE-TIME- | | DATE-TIME |
| | BASIC | | |
| UID | TEXT | | 1\*TEXT |
| CLASS | TEXT | | 1\*TEXT |
| CREATED | ISO-DATE-TIME- | | DATE-TIME |
| | BASIC | | |
| DTSTART | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, |
| | BASIC | COMPLETE | DATE |
| LAST- | ISO-DATE-TIME- | | DATE-TIME |
| MODIFIED | BASIC | | |
| ORGANIZER | URI | | cal-address |
| SEQUENCE | INTEGER-32 | | INTEGER |
| STATUS | TEXT | | 1\*TEXT |
| SUMMARY | TEXT | | 1\*TEXT |
| URL | URI | | URI |
| RRULE | RECURMAP (Section | | RECUR |
| | 12.2.1) | | |
| ATTACH | URI | BINARY | URI, BINARY |
| ATTENDEE | URI | | cal-address |
| CATEGORIES | LIST(TEXT) | | TEXT |
| COMMENT | TEXT | | 1\*TEXT |
| CONTACT | TEXT | | 1\*TEXT |
| DESCRIPTION | TEXT | | 1\*TEXT |
| EXDATE | LIST( ISO-DATE- | | DATE-TIME, |
| | TIME-BASIC / ISO- | | DATE |
| | DATE-COMPLETE ) | | |
| RELATED-TO | TEXT | | 1\*TEXT |
| RDATE | LIST( ISO-DATE- | | DATE-TIME, |
| | TIME-BASIC / ISO- | | DATE, |
| | DATE-COMPLETE / | | PERIOD |
| | CAL-INTERVAL) | | |
| REQUEST- | TEXT | | 1\*TEXT |
| STATUS | | | |
| IANA- | TEXT | | 1\*TEXT |
| REGed/X- | | | |
+--------------+-------------------+------------------+-------------+
Tse, et al. Expires December 10, 2018 [Page 70]
Internet-Draft vObject and vFormat June 2018
13.6. VFREEBUSY Component (RFC 5545)
+--------------+-------------------+------------------+-------------+
| Property | Default Value | Alt. Value Types | Original |
| | Type | | Value Type |
+--------------+-------------------+------------------+-------------+
| DTSTAMP | ISO-DATE-TIME- | | DATE-TIME |
| | BASIC | | |
| UID | TEXT | | 1\*TEXT |
| CONTACT | TEXT | | 1\*TEXT |
| DTSTART | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, |
| | BASIC | COMPLETE | DATE |
| DTEND | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, |
| | BASIC | COMPLETE | DATE |
| ORGANIZER | URI | | cal-address |
| URL | URI | | URI |
| ATTENDEE | URI | | cal-address |
| COMMENT | TEXT | | 1\*TEXT |
| FREEBUSY | LIST(CAL- | | LIST(PERIOD |
| | INTERVAL) | | ) |
| REQUEST- | TEXT | | 1\*TEXT |
| STATUS | | | |
| IANA- | TEXT | | 1\*TEXT |
| REGed/X- | | | |
+--------------+-------------------+------------------+-------------+
13.7. VTIMEZONE Component (RFC 5545)
+---------------+---------------------+------------+----------------+
| Property | Default Value Type | Alt. Value | Original Value |
| | | Types | Type |
+---------------+---------------------+------------+----------------+
| TZID | TEXT | | 1\*TEXT |
| LAST-MODIFIED | ISO-DATE-TIME-BASIC | | DATE-TIME |
| TZURL | URI | | URI |
| IANA-REGed/X- | TEXT | | 1\*TEXT |
+---------------+---------------------+------------+----------------+
13.8. STANDARD / DAYLIGHT Components (RFC 5545)
Tse, et al. Expires December 10, 2018 [Page 71]
Internet-Draft vObject and vFormat June 2018
+--------------+--------------------+------------------+------------+
| Property | Default Value Type | Alt. Value Types | Original |
| | | | Value Type |
+--------------+--------------------+------------------+------------+
| DTSTART | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, |
| | BASIC | COMPLETE | DATE |
| TZOFFSETFROM | CAL-UTC-OFFSET | | UTC-OFFSET |
| TZOFFSETTO | CAL-UTC-OFFSET | | UTC-OFFSET |
| RRULE | RECURMAP (Section | | RECUR |
| | 12.2.1) | | |
| COMMENT | TEXT | | 1\*TEXT |
| RDATE | LIST( ISO-DATE- | | DATE-TIME, |
| | TIME-BASIC / ISO- | | DATE, |
| | DATE-COMPLETE / | | PERIOD |
| | CAL-INTERVAL) | | |
| TZNAME | TEXT | | 1\*TEXT |
| IANA- | TEXT | | 1\*TEXT |
| REGed/X- | | | |
+--------------+--------------------+------------------+------------+
13.9. VALARM Component (RFC 5545)
+---------------+-------------+---------------------+---------------+
| Property | Default | Alt. Value Types | Original |
| | Value Type | | Value Type |
+---------------+-------------+---------------------+---------------+
| ACTION | TEXT | | 1\*TEXT |
| DESCRIPTION | TEXT | | 1\*TEXT |
| SUMMARY | TEXT | | 1\*TEXT |
| TRIGGER | DURATION | ISO-DATE-TIME-BASIC | DURATION, |
| | | | DATE-TIME |
| DURATION | DURATION | | DURATION |
| REPEAT | INTEGER-32 | | INTEGER |
| ATTACH | URI | BINARY | URI, BINARY |
| ATTENDEE | URI | | cal-address |
| IANA-REGed/X- | TEXT | | 1\*TEXT |
+---------------+-------------+---------------------+---------------+
14. Mapping Of Parameter Value Types For Existing RFCs
The value types in this section are described using vObject value
type notation (see Section 5.1).
14.1. RFC 6350
Tse, et al. Expires December 10, 2018 [Page 72]
Internet-Draft vObject and vFormat June 2018
+-----------+--------------+
| Parameter | Value Type |
+-----------+--------------+
| LANGUAGE | LANGUAGE-TAG |
| VALUE | TEXT |
| PREF | INTEGER-64 |
| ALTID | TEXT |
| PID | TEXT |
| TYPE | LIST(TEXT) |
| MEDIATYPE | TEXT |
| CALSCALE | TEXT |
| SORT-AS | LIST(TEXT) |
| GEO | URI |
| TZ | TEXT |
+-----------+--------------+
14.2. RFC 5545
+----------------+--------------+
| Parameter | Value Type |
+----------------+--------------+
| ALTREP | URI |
| CN | TEXT |
| CUTYPE | TEXT |
| DELEGATED-FROM | URI |
| DELEGATED-TO | URI |
| DIR | URI |
| ENCODING | TEXT |
| FMTTYPE | TEXT |
| FBTYPE | TEXT |
| LANGUAGE | LANGUAGE-TAG |
| MEMBER | LIST(URI) |
| PARTSTAT | TEXT |
| RANGE | TEXT |
| RELATED | TEXT |
| RELTYPE | TEXT |
| ROLE | TEXT |
| RSVP | BOOLEAN |
| SENT-BY | URI |
| TZID | TEXT |
| VALUE | TEXT |
+----------------+--------------+
15. References
Tse, et al. Expires December 10, 2018 [Page 73]
Internet-Draft vObject and vFormat June 2018
15.1. Normative References
[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>.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)",
RFC 5545, DOI 10.17487/RFC5545, September 2009,
<https://www.rfc-editor.org/info/rfc5545>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
15.2. Informative References
[CALCONNECT-CALENDAR]
The Calendaring and Scheduling Consortium, "CalConnect
CALENDAR Technical Committee", April 2018,
<https://www.calconnect.org/about/technical-committees/
calendar-technical-committee>.
[CALCONNECT-VCARD]
The Calendaring and Scheduling Consortium, "CalConnect
VCARD Technical Committee", April 2018,
<http://www.calconnect.org/about/technical-committees/
vcard-technical-committee>.
Tse, et al. Expires December 10, 2018 [Page 74]
Internet-Draft vObject and vFormat June 2018
[I-D.daboo-valarm-extensions]
Daboo, C., "VALARM Extensions for iCalendar", draft-daboo-
valarm-extensions-04 (work in progress), June 2012.
[I-D.york-vpoll]
York, E., Daboo, C., and M. Douglass, "VPOLL: Consensus
Scheduling Component for iCalendar", draft-york-vpoll-04
(work in progress), February 2017.
[IEEE.754.2008]
Institute of Electrical and Electronics Engineers, "IEEE
Standard 754, Standard for Binary Floating-Point
Arithmetic", August 2008,
<https://doi.org/10.1109/IEEESTD.2008.4610935>.
[ISO.8601.2000]
ISO/IEC, "ISO 8601:2000, Data elements and interchange
formats -- Information interchange -- Representation of
dates and times", December 2000,
<https://www.iso.org/standard/26780.html>.
[ISO.8601.2004]
ISO/IEC, "ISO 8601:2004, Data elements and interchange
formats -- Information interchange -- Representation of
dates and times", December 2004,
<https://www.iso.org/standard/40874.html>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
Tse, et al. Expires December 10, 2018 [Page 75]
Internet-Draft vObject and vFormat June 2018
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
DOI 10.17487/RFC4791, March 2007,
<https://www.rfc-editor.org/info/rfc4791>.
[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>.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, DOI 10.17487/RFC5789, March 2010,
<https://www.rfc-editor.org/info/rfc5789>.
[RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML
Format for iCalendar", RFC 6321, DOI 10.17487/RFC6321,
August 2011, <https://www.rfc-editor.org/info/rfc6321>.
[RFC6351] Perreault, S., "xCard: vCard XML Representation",
RFC 6351, DOI 10.17487/RFC6351, August 2011,
<https://www.rfc-editor.org/info/rfc6351>.
[RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed
Authoring and Versioning (WebDAV)", RFC 6352,
DOI 10.17487/RFC6352, August 2011,
<https://www.rfc-editor.org/info/rfc6352>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>.
[RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON
Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May
2014, <https://www.rfc-editor.org/info/rfc7265>.
[RFC7953] Daboo, C. and M. Douglass, "Calendar Availability",
RFC 7953, DOI 10.17487/RFC7953, August 2016,
<https://www.rfc-editor.org/info/rfc7953>.
[RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986,
DOI 10.17487/RFC7986, October 2016,
<https://www.rfc-editor.org/info/rfc7986>.
[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>.
Tse, et al. Expires December 10, 2018 [Page 76]
Internet-Draft vObject and vFormat June 2018
[vCard21] Internet Mail Consortium, "vCard - The Electronic Business
Card Version 2.1", 09 1996.
[VPATCH] Daboo, C. and K. Murchison, "The iCalendar VPATCH
Component (draft)", 10 2016.
Appendix A. Normalization Examples for vFormat
Original:
BEGIN:VOBJECT
PROPERTY1:10
PROPERTY2:20
END:VOBJECT
Normalized:
BEGIN:VOBJECT
PROPERTY1:10
PROPERTY2:20
END:VOBJECT
A.1. vCard
Original:
BEGIN:VCARD
VERSION:4.0
KIND:individual
FN:Martin Van Buren
N:Van Buren;Martin;;;Hon.
TEL;VALUE=uri;PREF=1;TYPE="voice";TYPE="home":tel:+1-888-888-8888;ext=8888
END:VCARD
Normalized:
BEGIN:VCARD
VERSION:4.0
KIND:individual
FN:Martin Van Buren
N:Van Buren;Martin;;;Hon.
TEL;VALUE=uri;PREF=1;TYPE="voice","home":tel:+1-888-888-8888;ext=8888
END:VCARD
Tse, et al. Expires December 10, 2018 [Page 77]
Internet-Draft vObject and vFormat June 2018
Appendix B. Acknowledgements
The authors wish to thank their families and the following parties
who helped this materialize and for their support of a better and
vObject-enabled world:
o The CalConnect TC-VCARD and TC-CALENDAR committees
o Cyrus Daboo
o Marten Gajda
o The CalConnect Technical Coordination Committee ("TCC")
o Members and the Board of Directors of CalConnect
Authors' Addresses
Ronald Henry Tse
Ribose
Suite 1111, 1 Pedder Street
Central
Hong Kong
Email: ronald.tse@ribose.com
URI: https://www.ribose.com
Peter Kwan Yu Tam
Ribose
Suite 1111, 1 Pedder Street
Central
Hong Kong
Email: peter.tam@ribose.com
URI: https://www.ribose.com
Kenneth Murchison
FastMail Pty Ltd
Level 2, 114 William Street
Melbourne, VIC 3000
Australia
Email: murch@fastmailteam.com
Tse, et al. Expires December 10, 2018 [Page 78]
Internet-Draft vObject and vFormat June 2018
Mike Douglass
Spherical Cow Group
226 3rd Street
Troy, NY 12180
United States of America
Email: mdouglass@sphericalcowgroup.com
URI: http://sphericalcowgroup.com
Tse, et al. Expires December 10, 2018 [Page 79]