idnits 2.17.1 draft-calconnect-vobject-vformat-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 52 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC7953, but the abstract doesn't seem to directly say this. It does mention RFC7953 though, so this could be OK. -- The draft header indicates that this document updates RFC6321, but the abstract doesn't seem to directly say this. It does mention RFC6321 though, so this could be OK. -- The draft header indicates that this document updates RFC5545, but the abstract doesn't seem to directly say this. It does mention RFC5545 though, so this could be OK. -- The draft header indicates that this document updates RFC6350, but the abstract doesn't seem to directly say this. It does mention RFC6350 though, so this could be OK. -- The draft header indicates that this document updates RFC6351, but the abstract doesn't seem to directly say this. It does mention RFC6351 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC5545, updated by this document, for RFC5378 checks: 2005-10-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 8, 2018) is 2141 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3986' is defined on line 3394, but no explicit reference was found in the text == Unused Reference: 'I-D.daboo-valarm-extensions' is defined on line 3435, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-daboo-valarm-extensions-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Calendaring Extensions R. Tse 3 Internet-Draft P. Tam 4 Updates: 5545, 6321, 6350, 6351, 7953, Ribose 5 7265, 7095 (if approved) K. Murchison 6 Intended status: Standards Track FastMail Pty Ltd 7 Expires: December 10, 2018 M. Douglass 8 Spherical Cow Group 9 June 8, 2018 11 The vObject Model and vFormat Syntax 12 draft-calconnect-vobject-vformat-04 14 Abstract 16 This document specifies the vObject data model and its corresponding 17 syntax vFormat. 19 vObject represents the generalized data model, and vFormat the 20 generalized data format, of the following specifications and fully 21 covers them: 23 o RFC 6350, vCard version 4.0: the VCARD component; 25 o RFC 5545, Internet Calendaring and Scheduling Core Object 26 Specification (iCalendar): the VCALENDAR, VEVENT, VJOURNAL, 27 VFREEBUSY, VTIMEZONE, VALARM, VTODO, STANDARD and DAYLIGHT 28 components; 30 o RFC 7953, Calendar Availability Extensions: the VAVAILABILITY and 31 AVAILABLE components; 33 o I-Ddaboo-icalendar-vpatch, iCalendar Patching: the VPATCH 34 component; and 36 o alternative formats for iCalendar and vCard, including RFC 6321, 37 xCal; RFC 7265, jCal; RFC 6351, xCard; and RFC 7095, jCard. 39 This work is produced by the CalConnect TC-VCARD and TC-CALENDAR 40 committees. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on December 10, 2018. 59 Copyright Notice 61 Copyright (c) 2018 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 77 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8 78 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 79 3. vObject Data Model . . . . . . . . . . . . . . . . . . . . . 9 80 3.1. vObject-compliant Models . . . . . . . . . . . . . . . . 10 81 3.2. Elements . . . . . . . . . . . . . . . . . . . . . . . . 10 82 3.2.1. Equivalence . . . . . . . . . . . . . . . . . . . . . 11 83 3.3. Component . . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.3.1. Uniqueness Identifying Property . . . . . . . . . . . 12 85 3.3.2. Normalizing A Component . . . . . . . . . . . . . . . 13 86 3.3.2.1. Sorted Component Properties . . . . . . . . . . . 13 87 3.3.2.2. Sorted Inner Components . . . . . . . . . . . . . 13 88 3.3.2.3. Normalized Inner Components . . . . . . . . . . . 13 89 3.3.3. vObject Property . . . . . . . . . . . . . . . . . . 13 90 3.3.3.1. Normalized Values . . . . . . . . . . . . . . . . 14 91 3.3.3.2. Normalized Parameters . . . . . . . . . . . . . . 14 92 3.3.4. Property Value . . . . . . . . . . . . . . . . . . . 14 93 3.3.5. Normalization Of Property Values . . . . . . . . . . 14 94 3.3.6. Property Parameter . . . . . . . . . . . . . . . . . 14 95 3.3.6.1. Value Lists . . . . . . . . . . . . . . . . . . . 15 96 3.3.7. Default Property Parameter Values . . . . . . . . . . 15 97 3.3.8. Property Parameter Value . . . . . . . . . . . . . . 15 98 3.3.9. Normalizing Multiple Parameter Values . . . . . . . . 15 99 3.3.10. Property Group . . . . . . . . . . . . . . . . . . . 16 100 4. vFormat Syntax . . . . . . . . . . . . . . . . . . . . . . . 16 101 4.1. ABNF Format Definition . . . . . . . . . . . . . . . . . 16 102 4.2. Component . . . . . . . . . . . . . . . . . . . . . . . . 18 103 4.2.1. Component Name In Uppercase . . . . . . . . . . . . . 18 104 4.2.2. Order Of Inner Components And Properties . . . . . . 18 105 4.2.3. Maintain Validity . . . . . . . . . . . . . . . . . . 18 106 4.3. Property . . . . . . . . . . . . . . . . . . . . . . . . 19 107 4.3.1. Uppercased Property Name . . . . . . . . . . . . . . 19 108 4.3.2. Normalized Parameters . . . . . . . . . . . . . . . . 19 109 4.3.3. Wrapped Content Line . . . . . . . . . . . . . . . . 19 110 4.4. Property Value . . . . . . . . . . . . . . . . . . . . . 19 111 4.4.1. Normalizing Property Values . . . . . . . . . . . . . 20 112 4.5. Property Parameter . . . . . . . . . . . . . . . . . . . 20 113 4.5.1. Multiple Property Parameters . . . . . . . . . . . . 20 114 4.5.2. Expanded Form Of Property Parameter Value List . . . 20 115 4.5.3. Uppercased Property Parameter Names . . . . . . . . . 20 116 4.5.4. Join Identical Property Parameter Names . . . . . . . 21 117 4.5.5. Express Default Property Value Types . . . . . . . . 21 118 4.6. Property Parameter Value . . . . . . . . . . . . . . . . 21 119 4.6.1. Format Definition . . . . . . . . . . . . . . . . . . 22 120 4.6.2. Description . . . . . . . . . . . . . . . . . . . . . 22 121 4.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 23 122 4.6.4. Normalization of Line Breaks . . . . . . . . . . . . 23 123 4.6.5. Normalizing Parameter Values Via DQOUTE Wrapping . . 23 124 4.7. Property Group . . . . . . . . . . . . . . . . . . . . . 23 125 5. vObject Value Types And Notation Syntax . . . . . . . . . . . 23 126 5.1. Value Type Notation . . . . . . . . . . . . . . . . . . . 24 127 5.2. Meta Value Types . . . . . . . . . . . . . . . . . . . . 24 128 5.2.1. FIELDSET . . . . . . . . . . . . . . . . . . . . . . 24 129 5.2.1.1. Value Type Notation . . . . . . . . . . . . . . . 24 130 5.2.1.2. Example 1 . . . . . . . . . . . . . . . . . . . . 24 131 5.2.1.3. Example 2 . . . . . . . . . . . . . . . . . . . . 25 132 5.2.1.4. Normalizing a FIELDSET . . . . . . . . . . . . . 25 133 5.2.2. LIST . . . . . . . . . . . . . . . . . . . . . . . . 25 134 5.2.2.1. Value Type Notation . . . . . . . . . . . . . . . 25 135 5.2.2.2. Example 1 . . . . . . . . . . . . . . . . . . . . 25 136 5.2.2.3. Example 2 . . . . . . . . . . . . . . . . . . . . 26 137 5.2.2.4. Normalizing a LIST . . . . . . . . . . . . . . . 26 138 5.2.3. MAP . . . . . . . . . . . . . . . . . . . . . . . . . 26 139 5.2.3.1. Value Type Notation . . . . . . . . . . . . . . . 26 140 5.2.3.2. Example . . . . . . . . . . . . . . . . . . . . . 26 141 5.2.3.3. Normalizing a MAP . . . . . . . . . . . . . . . . 27 142 5.3. Basic Value Types . . . . . . . . . . . . . . . . . . . . 27 143 5.3.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . 27 144 5.3.1.1. Value Type Notation . . . . . . . . . . . . . . . 27 145 5.3.1.2. Purpose . . . . . . . . . . . . . . . . . . . . . 27 146 5.3.1.3. Format Definition . . . . . . . . . . . . . . . . 27 147 5.3.1.4. Associated parameters . . . . . . . . . . . . . . 27 148 5.3.1.5. Example . . . . . . . . . . . . . . . . . . . . . 28 149 5.3.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . 28 150 5.3.2.1. Value Type Notation . . . . . . . . . . . . . . . 28 151 5.3.2.2. Purpose . . . . . . . . . . . . . . . . . . . . . 28 152 5.3.2.3. Format Definition . . . . . . . . . . . . . . . . 28 153 5.3.2.4. Description . . . . . . . . . . . . . . . . . . . 28 154 5.3.2.5. Example . . . . . . . . . . . . . . . . . . . . . 28 155 5.3.2.6. Normalization . . . . . . . . . . . . . . . . . . 29 156 5.3.3. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . 29 157 5.3.3.1. Value Type Notation . . . . . . . . . . . . . . . 29 158 5.3.3.2. Purpose . . . . . . . . . . . . . . . . . . . . . 29 159 5.3.3.3. Format Definition . . . . . . . . . . . . . . . . 29 160 5.3.3.4. Description . . . . . . . . . . . . . . . . . . . 29 161 5.3.3.5. Examples . . . . . . . . . . . . . . . . . . . . 29 162 5.3.3.6. Normalization . . . . . . . . . . . . . . . . . . 29 163 5.3.4. INTEGER . . . . . . . . . . . . . . . . . . . . . . . 29 164 5.3.4.1. Value Type Notation . . . . . . . . . . . . . . . 30 165 5.3.4.2. Purpose . . . . . . . . . . . . . . . . . . . . . 30 166 5.3.4.3. Format Definition . . . . . . . . . . . . . . . . 30 167 5.3.4.4. Description . . . . . . . . . . . . . . . . . . . 30 168 5.3.4.5. Examples . . . . . . . . . . . . . . . . . . . . 30 169 5.3.4.6. Normalization . . . . . . . . . . . . . . . . . . 30 170 5.3.5. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . 31 171 5.3.5.1. Value Type Notation . . . . . . . . . . . . . . . 31 172 5.3.5.2. Purpose . . . . . . . . . . . . . . . . . . . . . 31 173 5.3.5.3. Format Definition . . . . . . . . . . . . . . . . 31 174 5.3.5.4. Description . . . . . . . . . . . . . . . . . . . 31 175 5.3.5.5. Examples . . . . . . . . . . . . . . . . . . . . 31 176 5.3.5.6. Normalization . . . . . . . . . . . . . . . . . . 31 177 5.3.6. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . 32 178 5.3.6.1. Value Type Notation . . . . . . . . . . . . . . . 32 179 5.3.6.2. Purpose . . . . . . . . . . . . . . . . . . . . . 32 180 5.3.6.3. Format Definition . . . . . . . . . . . . . . . . 32 181 5.3.6.4. Description . . . . . . . . . . . . . . . . . . . 32 182 5.3.6.5. Examples . . . . . . . . . . . . . . . . . . . . 32 183 5.3.6.6. Normalization . . . . . . . . . . . . . . . . . . 32 184 5.3.7. Binary . . . . . . . . . . . . . . . . . . . . . . . 33 185 5.3.7.1. Value Type Notation . . . . . . . . . . . . . . . 33 186 5.3.7.2. Purpose . . . . . . . . . . . . . . . . . . . . . 33 187 5.3.7.3. Format Definition . . . . . . . . . . . . . . . . 33 188 5.3.7.4. Description . . . . . . . . . . . . . . . . . . . 33 189 5.3.7.5. Example . . . . . . . . . . . . . . . . . . . . . 33 190 5.3.8. KEYVALUE . . . . . . . . . . . . . . . . . . . . . . 34 191 5.3.8.1. Value Type Notation . . . . . . . . . . . . . . . 34 192 5.3.8.2. Purpose . . . . . . . . . . . . . . . . . . . . . 34 193 5.3.8.3. Format Definition . . . . . . . . . . . . . . . . 34 194 5.3.8.4. Description . . . . . . . . . . . . . . . . . . . 34 195 5.3.8.5. Examples . . . . . . . . . . . . . . . . . . . . 34 196 5.3.8.6. Normalization . . . . . . . . . . . . . . . . . . 34 197 5.4. Date and Time Value Types . . . . . . . . . . . . . . . . 34 198 5.4.1. ISO-DATE-COMPLETE . . . . . . . . . . . . . . . . . . 35 199 5.4.1.1. Value Type Notation . . . . . . . . . . . . . . . 35 200 5.4.1.2. Purpose . . . . . . . . . . . . . . . . . . . . . 35 201 5.4.1.3. Format Definition . . . . . . . . . . . . . . . . 35 202 5.4.1.4. Description . . . . . . . . . . . . . . . . . . . 35 203 5.4.1.5. Example . . . . . . . . . . . . . . . . . . . . . 35 204 5.4.1.6. Normalization . . . . . . . . . . . . . . . . . . 35 205 5.4.2. ISO-DATE-FLEX . . . . . . . . . . . . . . . . . . . . 35 206 5.4.2.1. Value Type Notation . . . . . . . . . . . . . . . 36 207 5.4.2.2. Purpose . . . . . . . . . . . . . . . . . . . . . 36 208 5.4.2.3. Format Definition . . . . . . . . . . . . . . . . 36 209 5.4.2.4. Description . . . . . . . . . . . . . . . . . . . 36 210 5.4.2.5. Normalization . . . . . . . . . . . . . . . . . . 37 211 5.4.3. ISO-TIME-COMPLETE . . . . . . . . . . . . . . . . . . 37 212 5.4.3.1. Value Type Notation . . . . . . . . . . . . . . . 37 213 5.4.3.2. Purpose . . . . . . . . . . . . . . . . . . . . . 37 214 5.4.3.3. Format Definition . . . . . . . . . . . . . . . . 38 215 5.4.3.4. Description . . . . . . . . . . . . . . . . . . . 38 216 5.4.3.5. Normalization . . . . . . . . . . . . . . . . . . 39 217 5.4.4. ISO-TIME-BASIC . . . . . . . . . . . . . . . . . . . 39 218 5.4.4.1. Value Type Notation . . . . . . . . . . . . . . . 39 219 5.4.4.2. Purpose . . . . . . . . . . . . . . . . . . . . . 39 220 5.4.4.3. Format Definition . . . . . . . . . . . . . . . . 39 221 5.4.4.4. Description . . . . . . . . . . . . . . . . . . . 39 222 5.4.4.5. Normalization . . . . . . . . . . . . . . . . . . 40 223 5.4.5. ISO-TIME-FLEX . . . . . . . . . . . . . . . . . . . . 40 224 5.4.5.1. Value Type Notation . . . . . . . . . . . . . . . 40 225 5.4.5.2. Purpose . . . . . . . . . . . . . . . . . . . . . 40 226 5.4.5.3. Format Definition . . . . . . . . . . . . . . . . 40 227 5.4.5.4. Description . . . . . . . . . . . . . . . . . . . 41 228 5.4.5.5. Normalization . . . . . . . . . . . . . . . . . . 42 229 5.4.6. ISO-UTC-OFFSET . . . . . . . . . . . . . . . . . . . 42 230 5.4.6.1. Value Type Notation . . . . . . . . . . . . . . . 42 231 5.4.6.2. Purpose . . . . . . . . . . . . . . . . . . . . . 42 232 5.4.6.3. Format Definition . . . . . . . . . . . . . . . . 42 233 5.4.6.4. Example . . . . . . . . . . . . . . . . . . . . . 43 234 5.4.6.5. Normalization . . . . . . . . . . . . . . . . . . 43 235 5.4.7. CAL-UTC-OFFSET . . . . . . . . . . . . . . . . . . . 43 236 5.4.7.1. Value Type Notation . . . . . . . . . . . . . . . 43 237 5.4.7.2. Purpose . . . . . . . . . . . . . . . . . . . . . 43 238 5.4.7.3. Format Definition . . . . . . . . . . . . . . . . 43 239 5.4.7.4. Description: . . . . . . . . . . . . . . . . . . 43 240 5.4.7.5. Example . . . . . . . . . . . . . . . . . . . . . 44 241 5.4.7.6. Normalization . . . . . . . . . . . . . . . . . . 44 242 5.4.8. ISO-DATE-TIME-COMPLETE . . . . . . . . . . . . . . . 44 243 5.4.8.1. Value Type Notation . . . . . . . . . . . . . . . 44 244 5.4.8.2. Purpose . . . . . . . . . . . . . . . . . . . . . 44 245 5.4.8.3. Format Definition . . . . . . . . . . . . . . . . 44 246 5.4.8.4. Description . . . . . . . . . . . . . . . . . . . 45 247 5.4.8.5. Examples . . . . . . . . . . . . . . . . . . . . 45 248 5.4.8.6. Normalization . . . . . . . . . . . . . . . . . . 45 249 5.4.9. ISO-DATE-TIME-BASIC . . . . . . . . . . . . . . . . . 45 250 5.4.9.1. Value Type Notation . . . . . . . . . . . . . . . 45 251 5.4.9.2. Purpose . . . . . . . . . . . . . . . . . . . . . 45 252 5.4.9.3. Format Definition . . . . . . . . . . . . . . . . 46 253 5.4.9.4. Description . . . . . . . . . . . . . . . . . . . 46 254 5.4.9.5. Examples . . . . . . . . . . . . . . . . . . . . 46 255 5.4.9.6. Normalization . . . . . . . . . . . . . . . . . . 46 256 5.4.10. ISO-DATE-TIME-FLEX . . . . . . . . . . . . . . . . . 46 257 5.4.10.1. Value Type Notation . . . . . . . . . . . . . . 46 258 5.4.10.2. Purpose . . . . . . . . . . . . . . . . . . . . 46 259 5.4.10.3. Format Definition . . . . . . . . . . . . . . . 47 260 5.4.10.4. Description . . . . . . . . . . . . . . . . . . 47 261 5.4.10.5. Examples . . . . . . . . . . . . . . . . . . . . 47 262 5.4.10.6. Normalization . . . . . . . . . . . . . . . . . 47 263 5.4.11. ISO-DATE-AND-OR-TIME . . . . . . . . . . . . . . . . 47 264 5.4.11.1. Value Type Notation . . . . . . . . . . . . . . 47 265 5.4.11.2. Purpose . . . . . . . . . . . . . . . . . . . . 47 266 5.4.11.3. Format Definition . . . . . . . . . . . . . . . 48 267 5.4.11.4. Description . . . . . . . . . . . . . . . . . . 48 268 5.4.11.5. Example . . . . . . . . . . . . . . . . . . . . 48 269 5.4.11.6. Normalization . . . . . . . . . . . . . . . . . 49 270 5.4.12. ISO-DURATION-COMPLETE . . . . . . . . . . . . . . . . 49 271 5.4.12.1. Value Type Notation . . . . . . . . . . . . . . 49 272 5.4.12.2. Purpose . . . . . . . . . . . . . . . . . . . . 49 273 5.4.12.3. Format Definition . . . . . . . . . . . . . . . 49 274 5.4.12.4. Description . . . . . . . . . . . . . . . . . . 49 275 5.4.12.5. Examples . . . . . . . . . . . . . . . . . . . . 50 276 5.4.12.6. Normalization . . . . . . . . . . . . . . . . . 50 277 5.4.13. CAL-DURATION . . . . . . . . . . . . . . . . . . . . 51 278 5.4.13.1. Value Type Notation . . . . . . . . . . . . . . 51 279 5.4.13.2. Purpose . . . . . . . . . . . . . . . . . . . . 51 280 5.4.13.3. Format Definition . . . . . . . . . . . . . . . 51 281 5.4.13.4. Description . . . . . . . . . . . . . . . . . . 51 282 5.4.13.5. Example . . . . . . . . . . . . . . . . . . . . 52 283 5.4.13.6. Normalization . . . . . . . . . . . . . . . . . 53 284 5.4.14. ISO-INTERVAL . . . . . . . . . . . . . . . . . . . . 53 285 5.4.14.1. Value Type Notation . . . . . . . . . . . . . . 53 286 5.4.14.2. Purpose . . . . . . . . . . . . . . . . . . . . 53 287 5.4.14.3. Format Definition . . . . . . . . . . . . . . . 53 288 5.4.14.4. Description . . . . . . . . . . . . . . . . . . 53 289 5.4.14.5. Examples . . . . . . . . . . . . . . . . . . . . 55 290 5.4.14.6. Normalization . . . . . . . . . . . . . . . . . 55 291 5.4.15. CAL-INTERVAL . . . . . . . . . . . . . . . . . . . . 55 292 5.4.15.1. Value Type Notation . . . . . . . . . . . . . . 55 293 5.4.15.2. Purpose . . . . . . . . . . . . . . . . . . . . 55 294 5.4.15.3. Format Definition . . . . . . . . . . . . . . . 55 295 5.4.15.4. Description . . . . . . . . . . . . . . . . . . 55 296 5.4.15.5. Examples . . . . . . . . . . . . . . . . . . . . 56 297 5.4.15.6. Normalization . . . . . . . . . . . . . . . . . 57 298 6. Normalization . . . . . . . . . . . . . . . . . . . . . . . . 57 299 6.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 57 300 6.2. Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 58 301 6.3. Application on alternative serializations . . . . . . . . 59 302 7. Client Implementations Recommendations . . . . . . . . . . . 59 303 8. CardDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 304 8.1. Additional Server Semantics for PUT, COPY and MOVE . . . 59 305 8.1.1. Provide Normalized Output . . . . . . . . . . . . . . 59 306 9. CalDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 307 9.1. Additional Server Semantics for PUT, COPY and MOVE . . . 60 308 9.1.1. Provide Normalized Output . . . . . . . . . . . . . . 60 309 10. Security Considerations . . . . . . . . . . . . . . . . . . . 60 310 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 311 11.1. Common vObject Registries . . . . . . . . . . . . . . . 61 312 11.2. vObject Component Uniqueness Identifiers Registry . . . 61 313 11.2.1. Registration Procedure . . . . . . . . . . . . . . . 61 314 11.2.2. Registration Template . . . . . . . . . . . . . . . 61 315 11.2.3. Initial Registrations . . . . . . . . . . . . . . . 62 316 12. Mapping Of Data Value Types For Existing RFCs . . . . . . . . 63 317 12.1. RFC 6350 . . . . . . . . . . . . . . . . . . . . . . . . 63 318 12.2. RFC 5545 . . . . . . . . . . . . . . . . . . . . . . . . 64 319 12.2.1. RECURMAP . . . . . . . . . . . . . . . . . . . . . . 64 320 13. Mapping Of Component Property Value Types For Existing RFCs . 65 321 13.1. VCARD Component (RFC 6350) . . . . . . . . . . . . . . . 65 322 13.2. VCALENDAR Component (RFC 5545) . . . . . . . . . . . . . 67 323 13.3. VEVENT Component (RFC 5545) . . . . . . . . . . . . . . 67 324 13.4. VTODO Component (RFC 5545) . . . . . . . . . . . . . . . 69 325 13.5. VJOURNAL Component (RFC 5545) . . . . . . . . . . . . . 70 326 13.6. VFREEBUSY Component (RFC 5545) . . . . . . . . . . . . . 71 327 13.7. VTIMEZONE Component (RFC 5545) . . . . . . . . . . . . . 71 328 13.8. STANDARD / DAYLIGHT Components (RFC 5545) . . . . . . . 71 329 13.9. VALARM Component (RFC 5545) . . . . . . . . . . . . . . 72 330 14. Mapping Of Parameter Value Types For Existing RFCs . . . . . 72 331 14.1. RFC 6350 . . . . . . . . . . . . . . . . . . . . . . . . 72 332 14.2. RFC 5545 . . . . . . . . . . . . . . . . . . . . . . . . 73 333 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 334 15.1. Normative References . . . . . . . . . . . . . . . . . . 74 335 15.2. Informative References . . . . . . . . . . . . . . . . . 74 336 Appendix A. Normalization Examples for vFormat . . . . . . . . . 77 337 A.1. vCard . . . . . . . . . . . . . . . . . . . . . . . . . . 77 338 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 78 339 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 341 1. Introduction 343 The ubiquitous vCard [RFC6350] and iCalendar [RFC5545] standards are 344 known as the "vObject" or "VCOMPONENT" family of standards. Named by 345 the convention where the component type identifiers usually start 346 with the letter "v", all of them use very similar, if not identical, 347 syntax. 349 While the origin of these formats have a shared history, due to 350 diverged implementations of "vObject" standards, the serialization of 351 such formats often generate different output even when given 352 identical content, causing interoperability concerns and the general 353 inability to determine equivalence of vObjects for integrity concerns 354 (2.1.2 [RFC3552]). 356 This document: 358 o defines the "vObject" data model, a generalization of the implied 359 data models of vObject-compliant standards; 361 o defines the "vFormat" serialization syntax, a generalized syntax 362 of vObject-compliant serialization formats; 364 o provides the "vObject Value Type" notation syntax, a method to 365 define value schema of all properties in vObject-compliant 366 standards; and 368 o describes the normalized form of the vObject data model and the 369 normalization process for vFormat syntax. 371 The normalized forms and normalization methods described in this 372 document are fully compatible with the vObject-compliant standards, 373 including vCard 4.0 [RFC6350] and iCalendar [RFC5545]. 375 This is a work product of the CalConnect TC-VCARD [CALCONNECT-VCARD] 376 and TC-CALENDAR [CALCONNECT-CALENDAR] committees. 378 2. Terms and Definitions 380 The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", 381 "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT 382 RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be 383 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only 384 when, they appear in all capitals, as shown here. 386 The key words "*Private Use*", "*Experimental Use*", "*Hierarchical 387 Allocation*", "*First Come First Served*", "*Expert Review*", 388 "*Specification Required*", "*RFC Required*", "*IETF Review*", 389 "*Standards Action*" and "*IESG Approval*" in this document are to be 390 interpreted as described in 4 [RFC8126]. 392 Notation in this document is described in ABNF [RFC5234] as used by 393 [RFC6350]. 395 Definitions from [RFC6350] apply to this specification except when 396 explicitly overridden. 398 All names of properties, property parameters, enumerated property 399 values, and property parameter values are case-insensitive. However, 400 all property values are case-sensitive, unless otherwise stated. 402 2.1. Definitions 404 vObject 405 the generalized data model of the vCard component (VCARD) and 406 iCalendar (VCALENDAR) component defined in this document 408 vFormat 409 the native serialization format of vObject, which is the textual 410 format representation using the "BEGIN:" and "END:" component 411 keywords 413 inner vObject, sub-component 414 a vObject located within a vObject 416 outer vObject, super-component 417 a vObject that this vObject is located within 419 Client User Application (CUA) 420 the vObject client implementation that interfaces with the user 422 calendar date 423 as defined in 2.1.8 [ISO.8601.2004] 425 3. vObject Data Model 427 The vObject data model is the generalized data model from the implied 428 data models of vCard [RFC6350] and iCalendar [RFC5545]. 430 While both vCard [RFC6350] and iCalendar [RFC5545] specify data 431 formats for different purposes, the data model behind them follow an 432 identical logical structure (using components, properties and 433 parameters) with similar requirements. 435 By creating a generalized data model ("vObject") that is compatible 436 with both, we are able to ensure that newly developed data 437 modification techniques for vObject would be interoperable on all 438 other vObject-compliant models. 440 3.1. vObject-compliant Models 442 The implied data models behind these formats are compliant to the 443 vObject data model: 445 o vCard version 4.0 [RFC6350]: the VCARD component 447 o Internet Calendaring and Scheduling Core Object Specification 448 (iCalendar) [RFC5545], the VCALENDAR, VEVENT, VJOURNAL, VFREEBUSY, 449 VTIMEZONE, VALARM, VTODO, STANDARD, DAYLIGHT components 451 o Calendar Availability Extensions [RFC7953]: the VAVAILABILITY, 452 AVAILABLE components 454 o iCalendar Patching [VPATCH]: the VPATCH component 456 3.2. Elements 458 Data within a vObject is arranged through a logical hierarchy 459 composed of the following elements: 461 o component; 463 o property; 465 o property parameter; 467 o property value; 469 o property parameter value; and 471 o property group. 473 The property group is optional and *MAY* not be accepted by all 474 vObject-compliant models. 476 +-------------------+ 477 | vObject Component | 478 +-------------------+ 479 | 480 / - - - - - - - - - - - - - - \ 481 | | (Optional) | 482 | +----------------+ 483 | +---| Property Group | | 484 | +----------------+ 485 | | | 486 \ - - - - - - - - - - - - - - / 487 | +----------+ 488 +---| Property | 489 +----------+ 490 | 491 | +----------------+ 492 +---| Property Value | 493 | +----------------+ 494 | 495 | +--------------------+ 496 +---| Property Parameter | 497 +--------------------+ 498 | 499 | +--------------------------+ 500 +---| Property Parameter Value | 501 +--------------------------+ 503 Figure 1: vObject Data Model Hierarchy 505 3.2.1. Equivalence 507 Two vObjects are considered identical in content if their normalized 508 forms are textually equivalent. 510 3.3. Component 512 A vObject is based on the representation of the "component" element. 513 All vObjects are composed of at least one component element. 515 A component: 517 o *MAY* contain vObject components; 519 o *MAY* contain properties; and 521 o *MUST* contain a uniqueness identifier property whose value is 522 called the component's "unique identifier". 524 A component type is identified by the component name, and every 525 component instance is distinguished by the value of its uniqueness 526 identifier property. 528 A component is often used to model an object in the object-oriented 529 sense, such as a vCard or an iCalendar object. 531 The order of components *MAY* represent order of the objects, which 532 is important for example in a "VPATCH" component [VPATCH], 533 representing the patching order, which is not a commutative process. 535 3.3.1. Uniqueness Identifying Property 537 As a vObject component can contain inner components, it is important 538 that those inner components can be distinguished from each other. 540 A vObject component's uniqueness identifier property is a property 541 whose value can uniquely identify the immediate component that 542 contains it. 544 Every vObject component *MUST* contain a single, component uniqueness 545 identifier property. The uniqueness identifier property can be 546 different according to component types, and the uniqueness scope of 547 that property *MAY* be different. At a minimum, the uniqueness 548 identifier property value *MUST* be unique within the immediate 549 component that contains the uniqueness identifier property. 551 For example: 553 o a "VCARD" component can be distinguished among other "VCARD" 554 components by its "UID" property value that is globally unique; 556 o a "STANDARD" component of "VTIMEZONE" can be distinguished 557 according to its "DTSTART" property within the "VTIMEZONE" 558 component that contains it. 560 The list of uniqueness identifier properties for every vObject 561 component that complies with this document can be found in the IANA 562 registry described in Section 11.2. 564 New vObject components defined according to this document *MUST* 565 define a uniqueness identifier property for that component, and it 566 *MUST* be registered in the said IANA registry. 568 3.3.2. Normalizing A Component 570 3.3.2.1. Sorted Component Properties 572 Properties *MUST* be first normalized and before sorted, meaning that 573 the property's values, and its parameters and its values, have been 574 normalized. 576 The sorting of component properties *MUST* be performed according to 577 the following order: 579 o alphabetically by the property name. If a property spans multiple 580 content lines, the content lines *MUST NOT* be separated after 581 sorting. 583 o alphabetically by their normalized value. 585 o alphabetically by treating its parameters as long strings 587 3.3.2.2. Sorted Inner Components 589 Inner components within a vObject must be placed in a sorted order. 591 The sorting between components *MUST* be performed according to the 592 following order: 594 o alphabetically by component type, according to component name, 595 such as "VCALENDAR"; then 597 o if of the same component name, alphabetically according to its 598 unique identifier Section 3.3.1. 600 3.3.2.3. Normalized Inner Components 602 An inner component *MUST* itself be normalized, meaning that its 603 properties and inner components *MUST* be normalized. 605 3.3.3. vObject Property 607 Properties represent attributes of the vObject itself. 609 A property: 611 o *MUST* contain a value; 613 o *MAY* contain one or more property parameters. 615 vObject property value types are listed in Section 3.3.4. 617 3.3.3.1. Normalized Values 619 A normalized property *MUST* have normalized values. 621 3.3.3.2. Normalized Parameters 623 A normalized property *MUST* have normalized property parameters. 625 Property parameters within the same property *MUST* each be 626 normalized, and then sorted by parameter name alphabetically. 628 Property parameters of the same property *MUST* have unique names. 630 3.3.4. Property Value 632 A vObject property *MAY* have one or more values, depending on the 633 value type. 635 vObject property values are strongly typed, just like in [RFC5545] 636 and [RFC6350]. Basic value types accepted in vObject properties are 637 defined in Section 5. 639 vObject compliant formats *MAY* define additional value types that 640 are not provided in this document, and *MAY* require separate 641 validation rules, such as the "RECUR" property value type from 642 iCalendar [RFC5545]. 644 Each property *MUST* define a default value type, and *MAY* accept 645 alternative, defined, value types. 647 3.3.5. Normalization Of Property Values 649 The property value generally does not require any normalization. 650 Please consult individual normalization instructions in each value 651 type's definition. 653 3.3.6. Property Parameter 655 A property parameter is an attribute that applies on a property. 657 A property parameter contains: 659 o an identifier identifying its type; 661 o the value of the property parameter. 663 A property parameter *MAY* represent: 665 o information about the property; or 667 o information about the property value 669 A property *MAY* have multiple property parameters, for example, the 670 "TYPE" of the value or a category that applies to this value. 672 3.3.6.1. Value Lists 674 Certain property parameters allow multiple values. There is no 675 defined order among property parameters in a property parameter list. 677 In normalized form, values in a value list *MUST* be sorted 678 alphabetically. 680 3.3.7. Default Property Parameter Values 682 Property parameters are allowed to have a default value. 684 For example, in vObject formats including [RFC5545] and [RFC6350], 685 each property value has a specified data type specified as the 686 "VALUE" property parameter. 688 3.3.8. Property Parameter Value 690 vObject property parameter values are strongly typed, just like 691 vObject properties, [RFC5545] and [RFC6350]. Basic value types 692 accepted in vObject property parameter values are defined in 693 Section 5. 695 A property parameter value **MAY* contain none, one or several 696 property parameter values. No order is defined among a list of 697 property parameter values. 699 vObject compliant formats *MAY* define additional value types that 700 are not provided in this document, and *MAY* require separate 701 validation rules, such as the values accepted by the "FBTYPE" 702 property parameter in iCalendar [RFC5545]. 704 Each property parameter *MUST* define its accepted value type. While 705 a property *MAY* accept multiple alternative value types, a property 706 parameter value *MUST* only accept one value type. 708 3.3.9. Normalizing Multiple Parameter Values 710 Property parameter values within a property parameter is considered 711 sorted by value. 713 3.3.10. Property Group 715 A property group (or just "group") is used to group a set of 716 properties, useful to represent cases where a group of properties are 717 closely related to each other. 719 In the vCard [RFC6350], the group is used to tie multiple properties 720 into being displayed together. 722 Each property *MUST* only have a maximum of one group. 724 Groups are not ordered and group names are case-insensitive. 726 4. vFormat Syntax 728 The "vFormat" format is the generalized syntax from the vCard 729 [RFC6350] and iCalendar [RFC5545] formats, and is the native format 730 for vObject serialization ("vObject native format"). 732 vFormat is called the "native" format for vObjects to distinguish it 733 from alternative representations of vObject data, such as their XML 734 (xCal, xCard) or JSON (jCal, jCard) representations. 736 Its syntax originated from the textual representation of the 737 iCalendar and vCard formats, and is mostly traceable back to the 738 original vCard and iCalendar specifications [vCard21]. 740 Both of these formats are considered "instances" (or "downstream 741 formats") of vFormat, and fully adhere to vFormat requirements. 743 Parsing and modification operations that work on vFormat *SHOULD* 744 work on all its instances, including iCalendar [RFC5545] and vCard 745 [RFC6350]. 747 4.1. ABNF Format Definition 749 The following ABNF notation defines the vFormat syntax, in accordance 750 with [RFC5234], which also defines CRLF, WSP, DQUOTE, VCHAR, ALPHA, 751 and DIGIT. 753 A vObject is defined by the following notation in vFormat: 755 vobjects = 1*vobject 757 vobject = "BEGIN:" comp-name CRLF 758 *contentline 759 *vobject 760 "END:" comp-name CRLF 762 comp-name = name 764 prop-name = name 766 prop-values = prop-value / prop-list / prop-structured 768 prop-value = VALUE-CHAR 770 prop-list = prop-value *("," prop-value) 771 ; An unordered list containing multiple property values 773 prop-structured = prop-value *(";" prop-value) 774 ; A structured list that consist of multiple property fields 775 ; for multiple property values 777 contentline = [group "."] prop-name params ":" prop-values CRLF 778 ; Folding and unfolding procedures described in Section 3.2 of 779 ; [RFC6350] applies: 780 ; * When parsing a content line, folded lines *MUST* first be 781 ; unfolded accordingly. 782 ; * When generating a content line, lines longer than 75 783 ; characters *SHOULD* be folded accordingly. 784 ; * When normalizing a content line, the content line *MUST* 785 ; be folded when the line is longer than 75 characters. 787 group = name 789 params = *(";" param) 791 param = name "=" param-value *("," param-value) 792 ; Allowed parameters depend on property name. 794 name = 1*(ALPHA / DIGIT / "-") 796 NON-ASCII = UTF8-2 / UTF8-3 / UTF8-4 797 ; UTF8-{2,3,4} are defined in <> 798 ; TODO: generalize this to UTF-32 800 QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII 801 ; Any character except CTLs, DQUOTE 803 SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII 804 ; Any character except CTLs, DQUOTE, ";", ":" 806 VALUE-CHAR = WSP / VCHAR / NON-ASCII 807 ; Any textual character 809 4.2. Component 811 A component: 813 o begins with line of text that starts with "BEGIN:" following with 814 its component name, ending with a line break; 816 o ends with a line of text that starts with "END:" following with 817 its component name (matching with the "BEGIN:" line), ending with 818 a line break. 820 The vCard [RFC6350] and iCalendar [RFC5545] data formats both conform 821 to vFormat, and their syntaxes are considered to be restricted 822 instances of the vObject syntax. 824 4.2.1. Component Name In Uppercase 826 The component name of a vObject *MUST* be uppercased, for both the 827 "BEGIN:" and "END:" content lines. 829 Example: 831 "BEGIN:vCard" 833 Should be normalized to: 835 "BEGIN:VCARD" 837 4.2.2. Order Of Inner Components And Properties 839 Properties *MUST* be placed before inner components are listed. 841 4.2.3. Maintain Validity 843 Certain vObject formats places certain restrictions or requirements 844 on property line locations. Normalization procedures *MUST NOT* 845 affect the validity of the normalized vObject. 847 For example, in the VCARD component [RFC6350], the "VERSION" property 848 line is *REQUIRED* to be placed immediately below the "BEGIN" line. 850 In this case, when normalizing the VCARD component, the common 851 normalization procedure *MUST* be first applied, and the "VERSION" 852 property line *MUST* be restored to the valid location as required by 853 its specifications [RFC6350]. 855 4.3. Property 857 A property can be represented by one content line (a line that ends 858 with a line break), but can also be "folded" (3.1 [RFC5545]) to use 859 multiple lines. 861 A property begins with the property name (e.g., "TEL"), followed by a 862 COLON delimiter and the property's value. 864 4.3.1. Uppercased Property Name 866 The property name *MUST* be normalized to uppercase letters. 868 4.3.2. Normalized Parameters 870 The last property parameter of a property *MUST NOT* have a trailing 871 SEMICOLON. 873 4.3.3. Wrapped Content Line 875 When exporting a normalized property content line, it *MUST* be 876 folded at the character limit when it exceeds 75 characters. Each 877 folded line *MUST* be delimited by the character sequence of a line 878 break and a single white space (CRLF, SPACE (U+0020)). This rule 879 only applies to normalized output. 881 For example, the original form: 883 NOTE:This is a very long description on a long line that exceeds 75 characters. 885 When exported to normalized output *MUST* give out: 887 NOTE:This is a very long description on a long line that exceeds 75 charac 888 ters. 890 4.4. Property Value 892 The property's values are defined as the content after the property 893 name and COLON delimiter, until the end of the unfolded content line. 895 If a property accepts multiple values, the definition of delimitation 896 is defined in Section 5. 898 vObject compliant formats that defines additional value types *MAY* 899 require separate validation rules on top of vFormat syntax. 901 If the property value type of a property value is not the default 902 value type, the "VALUE" parameter *MUST* be present to specify the 903 type of the property value. 905 vFormat representation of different value types are provided in 906 Section 5. 908 4.4.1. Normalizing Property Values 910 The property value generally does not require any normalization. 912 4.5. Property Parameter 914 Property parameters exist between the property name and the COLON 915 delimiter in a property line. 917 Each property parameter in a list of property parameters *MUST* be 918 separated by a SEMICOLON character. 920 The property parameter name and the property parameter value is 921 separated with an equal sign ("="). 923 4.5.1. Multiple Property Parameters 925 If the property accepts multiple property parameters values, they 926 *MUST* be separated by a SEMICOLON character as a list. 928 4.5.2. Expanded Form Of Property Parameter Value List 930 When there are multiple instances of a property parameter on the same 931 property, such as in "TYPE=home;TYPE=work", it is considered 932 equivalent to "TYPE=home\,work". 934 4.5.3. Uppercased Property Parameter Names 936 The property parameter name *MUST* be normalized into uppercase 937 letters in form of a Unicode string (7 [RFC8259]). 939 Property parameter names (together with their values) *MUST* be 940 sorted alphabetically. 942 Example: 944 "TEL;VALUE=uri;type=home:tel:+1-888-888-8888" 946 The normalized form is: 948 "TEL;TYPE="home";VALUE="uri":tel:+1-888-888-8888" 950 4.5.4. Join Identical Property Parameter Names 952 If a property parameter occurs more than once within a property, the 953 property parameter is considered to contain a list of property 954 parameter values joined by the parameter separator. 956 Such instances of property parameters with identical names *MUST* be 957 joined into one instance with its value a sorted list of the property 958 parameter values. 960 For example, the vCard "TEL" property's "TYPE" parameter [RFC6350] 961 describes that "TYPE=home,work" and "TYPE=work;TYPE=home" are 962 considered equivalent. 964 Example: 966 "TEL;TYPE=home;Type=work;VALUE=uri:tel:+1-888-888-8888" 968 The normalized form is: 970 "TEL;TYPE="home","work";VALUE=uri:tel:+1-888-888-8888" 972 4.5.5. Express Default Property Value Types 974 In vObject formats including [RFC5545] and [RFC6350], each property 975 value has a specified data type either as specified by property 976 definition or optionally assigned. 978 When normalizing a property, the property data value type *MUST* 979 always be specified. If the value type is not explicitly specified, 980 it *MUST* be filled in according to the vObject format. 982 Example: 984 "TEL:+1-888-888-8888" 986 The normalized form is: 988 "TEL;VALUE="text":+1-888-888-8888" 990 4.6. Property Parameter Value 992 While a property parameter value may accept any vObject value type, 993 the serialization rules of a vFormat property value and a vFormat 994 property parameter value are different, due to further limitations of 995 allowed characters in property parameter values. 997 4.6.1. Format Definition 999 param-value = param-single-value *("," param-single-value) 1000 param-single-value = paramtext / quoted-string 1002 paramtext = *SAFE-CHAR 1003 quoted-string = DQUOTE *QSAFE-CHAR DQUOTE 1005 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII 1006 ; Any character except CONTROL and DQUOTE 1008 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E 1009 / NON-US-ASCII 1010 ; Any character except CONTROL, DQUOTE, ";", ":", "," 1012 NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4 1013 ; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC3629] 1015 CONTROL = %x00-08 / %x0A-1F / %x7F 1016 ; All the controls except HTAB 1018 4.6.2. Description 1020 In vFormat, if a property parameter accepts multiple values, these 1021 value elements *MUST* be separated by a COMMA (U+002C). 1023 The DQUOTE character is used as a delimiter for parameter values that 1024 contain restricted characters or URI text. 1026 Property parameter values that contain the COLON (U+003A), SEMICOLON 1027 (U+003B) (such as the "LIST" and "MAP" value types), or COMMA 1028 (U+002C) character separators *MUST* be specified as quoted-string 1029 text values. 1031 Property parameter values that contain the DQUOTE (U+0022) character 1032 *MUST* be escaped and specified as quoted-string text values. 1034 An intentional line break *MUST* be represented by the sequence of 1035 "\n" or "\N" (BACKSLASH followed by a LATIN SMALL LETTER N (U+006E) 1036 or a LATIN CAPITAL LETTER N (U+004E)). 1038 Property parameter values that are not in quoted-strings are case- 1039 insensitive. 1041 4.6.3. Example 1043 The value "cid:part1.0001@example.org" in the parameter "ALTREP" 1044 within a "DESCRIPTION" property in iCalendar can be specified like 1045 this: 1047 DESCRIPTION;ALTREP="cid:part1.0001@example.org":The Fall'98 Wild 1048 Wizards Conference - - Las Vegas\, NV\, USA 1050 4.6.4. Normalization of Line Breaks 1052 In vFormat, vObject property parameter values *MUST* convert all line 1053 breaks ("\n" or "\N") into the character sequence "\n" (BACKSLASH 1054 followed by a LATIN SMALL LETTER N (U+006E)). 1056 If a value is specified as "paramtext" (i.e., not inside a quoted- 1057 string), the value *SHOULD* be down-cased. 1059 4.6.5. Normalizing Parameter Values Via DQOUTE Wrapping 1061 vFormat property parameter values *SHOULD* be individually wrapped 1062 with the DQUOTE characters. 1064 This is an example application of the rule from [RFC6350]: 1066 "TEL;TYPE=home,work;VALUE=uri:tel:+1-888-888-8888" 1068 The normalized vFormat output is: 1070 "TEL;TYPE="home","work";VALUE="uri":tel:+1-888-888-8888" 1072 4.7. Property Group 1074 The syntax of a property group is defined in Section 4.1. 1076 Property groups *MUST NOT* be removed during normalization. This is 1077 contrary to [RFC6350] that allows stripping off groups. 1079 5. vObject Value Types And Notation Syntax 1081 vObject value types are identically defined for both: 1083 o vObject property values; and 1085 o vObject property parameter values. 1087 5.1. Value Type Notation 1089 The vObject value type notation is used for defining the accepted 1090 values within a vObject property or parameter values. It fully 1091 covers all complete and exhaustive amongst all vObject-compliant 1092 standards. 1094 This notation syntax allows a vObject specification to define complex 1095 value types by using one or more value primitives defined in the 1096 sections below. 1098 The purpose of this syntax is to provide a mechanism to all vObject 1099 value definitions, such that any new vObject mechanism (such as, a 1100 method that can be applied to any vObject) can ensure uniform 1101 applicability on vObject values. 1103 Value type mappings provided in Section 12, Section 14, and 1104 Section 13 are denoted using the vObject value type syntax. 1106 Implementation differences within Section 4 of the same value type 1107 are described in Section 4.4 and Section 4.6. 1109 5.2. Meta Value Types 1111 Meta value types are used in conjunction with basic value types 1112 (Section 5.3). 1114 5.2.1. FIELDSET 1116 Some properties and parameters require values defined in terms of 1117 multiple parts. 1119 This construct of multiple structured values is called a "FIELDSET". 1120 Each value in FIELDSET *MUST* have the same value type as defined. 1122 5.2.1.1. Value Type Notation 1124 When used to describe a value type, the "FIELDSET(field-1-value-type, 1125 ...)" notation is defined as a structure of fields separated by the 1126 SEMICOLON character, where each of its fields is of value type 1127 "field-i-value-type", where "i" represents the index of the specific 1128 field. 1130 5.2.1.2. Example 1 1132 The "CLIENTPIDMAP" property of [RFC6350] takes a tuple of "INTEGER" 1133 and "URI". 1135 The notation in vObject given for its value type would be this 1136 indicating that the first value is an INTEGER, while the latter value 1137 is a URI: 1139 FIELDSET(INTEGER, URI) 1141 5.2.1.3. Example 2 1143 The "N" property of [RFC6350] defines its value of having 5 values at 1144 once, and each of these values are a LIST of TEXT. 1146 The notation in vObject given for its value type would be this 1147 indicating that there are 5 fields in this FIELDSET, and each value 1148 element of it *MUST* be a LIST of TEXT elements: 1150 FIELDSET(5\*LIST(TEXT)) 1152 5.2.1.4. Normalizing a FIELDSET 1154 When normalizing a FIELDSET, each value *MUST* have been normalized, 1155 but the order of FIELDSET elements *MUST NOT* be rearranged. 1157 5.2.2. LIST 1159 Properties and parameters *MAY* specify its value to be an unordered 1160 list of values. There is no significance to the order of values in a 1161 list. 1163 This construct is called the "LIST". Each value in the LIST *MUST* 1164 have the same value type. 1166 5.2.2.1. Value Type Notation 1168 The "LIST(value-type)" notation is used to describe this value type, 1169 of a list of elements, where each of its elements is of value type 1170 "value-type". 1172 5.2.2.2. Example 1 1174 The "NICKNAME" property of [RFC6350] defines its value to be an 1175 unordered list of TEXT. 1177 In vObject notation its value type is defined to be: 1179 LIST(TEXT) 1181 5.2.2.3. Example 2 1183 The "RECUR" property of [RFC5545] defines its value to be an 1184 unordered list of ASSIGN. 1186 In vObject notation its value type is defined to be: 1188 LIST(KEYVALUE, ";") 1190 5.2.2.4. Normalizing a LIST 1192 When normalizing a LIST, each value of it *MUST* be normalized, and 1193 the values *MUST* be sorted alphabetically. 1195 For example, values of [RFC5545] RESOURCES, FREEBUSY, EXDATE, RDATE, 1196 CATEGORIES, *MUST* be sorted alphabetically when normalized. 1198 5.2.3. MAP 1200 A "MAP" serves the function of a key-value table. It is realized 1201 using the "LIST" value type with values of the value type "KEYVALUE". 1203 Each value in the MAP *MUST* use the "KEYVALUE" value type. 1205 There is no inherent order of the values within a MAP. Values within 1206 its key value pairs *MAY* be of different value types as defined. 1208 5.2.3.1. Value Type Notation 1210 This value type is described using the "MAP(kv_1, kv_2, ...)" 1211 notation, where each "kv_i" represents a property of the value type 1212 KEYVALUE. 1214 5.2.3.2. Example 1216 The Recurrence Rule property ("RECUR") of [RFC5545] defines its value 1217 to be a MAP. 1219 In vObject notation its value type is defined to be: 1221 MAP( 1222 KEYVALUE(FREQ, TEXT), 1223 KEYVALUE(UNTIL, ISO-DATE-COMPLETE / ISO-DATE-TIME-BASIC), 1224 KEYVALUE(COUNT, INTEGER), 1225 KEYVALUE(INTERVAL, INTEGER), 1226 KEYVALUE(BYSECOND, LIST(INTEGER)), 1227 KEYVALUE(BYMINUTE, LIST(INTEGER)), 1228 KEYVALUE(BYHOUR, LIST(INTEGER)), 1229 KEYVALUE(BYDAY, LIST(INTEGER)), 1230 KEYVALUE(BYMONTHDAY, LIST(INTEGER)), 1231 KEYVALUE(BYYEARDAY, LIST(INTEGER)), 1232 KEYVALUE(BYWEEKNO, LIST(INTEGER)), 1233 KEYVALUE(BYMONTH, LIST(INTEGER)), 1234 KEYVALUE(BYSETPOS, INTEGER), 1235 KEYVALUE(WKST, TEXT) 1236 ) 1238 5.2.3.3. Normalizing a MAP 1240 When normalizing a MAP, each value of it *MUST* be normalized, and 1241 the values *MUST* be sorted alphabetically according to its "key". 1243 5.3. Basic Value Types 1245 5.3.1. TEXT 1247 This corresponds to the TEXT value type in 4.1 [RFC6350] and 3.3.11 1248 [RFC5545]. 1250 5.3.1.1. Value Type Notation 1252 TEXT 1254 5.3.1.2. Purpose 1256 This value type defines values that contain free-form, human-readable 1257 text. 1259 5.3.1.3. Format Definition 1261 text = VALUE-CHAR 1263 5.3.1.4. Associated parameters 1265 o Language in which the text is represented can be controlled by the 1266 "LANGUAGE" property parameter. 1268 5.3.1.5. Example 1270 This multiple line value is a valid value for the NOTE property of 1271 vCard: 1273 TC VCARD 1274 The Calendaring And Scheduling Consortium 1275 July 20, 2017 1277 5.3.2. URI 1279 This corresponds to the URI value type in 4.2 [RFC6350] and 3.3.13 1280 [RFC5545]. 1282 5.3.2.1. Value Type Notation 1284 URI 1286 5.3.2.2. Purpose 1288 This value type defines values that are represented by data 1289 referenced by a uniform resource identifier (URI), the value is what 1290 the URI points to, not the URI itself. 1292 5.3.2.3. Format Definition 1294 uri = 1296 5.3.2.4. Description 1298 When a property parameter value is a URI value type, the URI *MUST* 1299 be specified as a quoted-string value. 1301 5.3.2.5. Example 1303 This following values for the PHOTO property of vCard are valid. 1305 Example 1: 1307 http://www.example.com/pub/photos/jqpublic.gif 1309 Example 2: 1311 data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv 1312 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1313 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1314 <...remainder of base64-encoded data...> 1316 5.3.2.6. Normalization 1318 No normalization procedures are needed. 1320 5.3.3. BOOLEAN 1322 This corresponds to the BOOLEAN value types in 4.4 [RFC6350] and 1323 3.3.2 [RFC5545]. 1325 5.3.3.1. Value Type Notation 1327 BOOLEAN 1329 5.3.3.2. Purpose 1331 This value type is used to identify properties that contain either a 1332 "TRUE" or "FALSE" Boolean value. 1334 5.3.3.3. Format Definition 1336 boolean = "TRUE" / "FALSE" 1338 5.3.3.4. Description 1340 Parsing of "TRUE" and "FALSE" values *SHOULD* be case-insensitive, 1341 but a writer of such value *MUST* only output of this value type in 1342 uppercase. 1344 5.3.3.5. Examples 1346 o TRUE 1348 o false 1350 o True 1352 o FaLSe 1354 5.3.3.6. Normalization 1356 Values of the BOOLEAN data type *MUST* be normalized to uppercase, 1357 i.e., the values "TRUE" and "FALSE". 1359 5.3.4. INTEGER 1361 The INTEGER-64 and INTEGER-32 value types corresponds to the INTEGER 1362 value types in 4.5 [RFC6350] and in 3.3.8 [RFC5545] respectively. 1364 5.3.4.1. Value Type Notation 1366 INTEGER 1368 (INTEGER-32 for storing 32-bit integer, INTEGER-64 for storing 64-bit 1369 integer) 1371 5.3.4.2. Purpose 1373 Representation of a signed integer value. 1375 5.3.4.3. Format Definition 1377 integer = (["+"] / "-") 1*DIGIT 1379 5.3.4.4. Description 1381 If a preceding sign is not specified, the value is assumed positive 1382 "". While the format accepts the optional "" PLUS sign, a writer 1383 that conforms to this document *SHOULD* not write the "+" sign for 1384 clarity reasons. 1386 The valid ranges for INTEGER-32 and INTEGER-64 are: 1388 o INTEGER-32: -2147483648 (-2^31) to 2147483647 (2^31 - 1) 1390 o INTEGER-64: -9223372036854775807 (-2^63) to 9223372036854775808 1391 (2^63 - 1) 1393 5.3.4.5. Examples 1395 o 1234567890 1397 o -1234567890 1399 o +1234567890 1401 o 432109876 1403 5.3.4.6. Normalization 1405 A positive integer when normalized *MUST* not have the optional "+" 1406 sign. 1408 5.3.5. FLOAT 1410 This corresponds to the FLOAT value types in 3.3.7 [RFC5545] and 4.6 1411 [RFC6350]. 1413 5.3.5.1. Value Type Notation 1415 FLOAT 1417 5.3.5.2. Purpose 1419 Representation of a real-number value. 1421 5.3.5.3. Format Definition 1423 float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] 1425 5.3.5.4. Description 1427 If a preceding sign is not specified, the value is assumed positive 1428 "+". 1430 Implementations *MUST* support a precision equal or better than that 1431 of the IEEE "binary64" format [IEEE.754.2008]. 1433 Scientific notation is disallowed. 1435 5.3.5.5. Examples 1437 o 20.30 1439 o 1000000.0000001 1441 o 1.333 1443 o -3.14 1445 5.3.5.6. Normalization 1447 No normalization procedures are needed. 1449 Trailing zeros, such as "100.10000" *MUST* be kept as it indicates 1450 accuracy of the number. 1452 5.3.6. LANGUAGE-TAG 1454 This corresponds to the LANGUAGE-TAG value type in 4.8 [RFC6350]. 1456 5.3.6.1. Value Type Notation 1458 LANGUAGE-TAG 1460 5.3.6.2. Purpose 1462 Representing a language tag, as defined in [RFC5646]. 1464 5.3.6.3. Format Definition 1466 Defined in [RFC5646]. 1468 5.3.6.4. Description 1470 A single language tag 1472 5.3.6.5. Examples 1474 o de 1476 o en-US 1478 o sr-Cyrl 1480 o zh-yue-HK 1482 5.3.6.6. Normalization 1484 The normalization procedure of the LANGUAGE-TAG data type follows the 1485 procedure described in 2.1.1 [RFC5646]. 1487 o language codes *MUST* be written in lowercase ('mn' Mongolian) 1489 o script codes *MUST* be in lowercase when the initial letter 1490 capitalized ('Cyrl' Cyrillic) 1492 o country codes *MUST* be capitalized ('MN' Mongolia) 1494 As the language tag is comprised of a mixture of these components, 1495 [RFC5646] provides a rule that applies this procedure across all 1496 language tags: 1498 o All subtags, including extension and private use subtags, *MUST* 1499 use lowercase letters. 1501 o Except: two-letter subtags that neither appear at the start of the 1502 tag nor occur after singletons *MUST* be in uppercase ("en-CA- 1503 x-ca" or "sgn-BE-FR"). 1505 o Except: four-letter subtags that neither appear at the start of 1506 the tag nor occur after singletons *MUST* be in titlecase ("az- 1507 Latn-x-latn"). 1509 5.3.7. Binary 1511 This corresponds to the BINARY value type in 3.3.1 [RFC5545]. 1513 5.3.7.1. Value Type Notation 1515 BINARY 1517 5.3.7.2. Purpose 1519 This value type defines values that contain inline binary data 1520 encoded in characters. For example, an inline "ATTACH" property of 1521 an iCalendar object or an inline "PHOTO" property image inside a 1522 vCard object. 1524 5.3.7.3. Format Definition 1526 binary = *(4b-char) [b-end] 1527 ; A "BASE64" encoded character string, as defined by [RFC4648]. 1529 b-end = (2b-char "==") / (3b-char "=") 1531 b-char = ALPHA / DIGIT / "+" / "/" 1533 5.3.7.4. Description 1535 Property values with this value type *MUST* specify the parameter 1536 "ENCODING" with parameter value "BASE64", and the inline binary data 1537 *MUST* be character encoded using the "BASE64" encoding method 1538 defined in [RFC2045]. 1540 5.3.7.5. Example 1542 This value for the NOTE value of vCard: 1544 The following is an example of a "BASE64" encoded binary value data 1545 folded to 72 characters long: 1547 AAABAAEAEBAQAAEABAAoAQAAFgAAACgAAAAQAAAAIAAAAAEABAAAAAAAAAAAAAAAAAAAAAAA 1548 AAAAAAAAAACAAAAAgIAAAICAgADAwMAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 1549 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAAAAAABNEMQAAAAAAAk 1550 QgAAAAAAJEREQgAAACECQ0QgEgAAQxQzM0E0AABERCRCREQAADRDJEJEQwAAAhA0QwEQAAAA 1551 AEREAAAAAAAAREQAAAAAAAAkQgAAAAAAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 1552 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 1554 5.3.8. KEYVALUE 1556 5.3.8.1. Value Type Notation 1558 "KEYVALUE(key, value-type)" 1560 5.3.8.2. Purpose 1562 Representation of a key-value pair: a key "key" linked to a value of 1563 value type "value-type". 1565 5.3.8.3. Format Definition 1567 assign-key = *(TSAFE-CHAR) 1568 assign-value = prop-values 1570 5.3.8.4. Description 1572 This value type is a core component of the "MAP" value type. 1574 If the "KEYVALUE" value is accepted within a list, the "key" value 1575 must be unique amongst the list. 1577 5.3.8.5. Examples 1579 o key: "FREQ"; value: "WEEKLY" 1581 o key: "BYHOUR"; value: "3,6,9" 1583 o key: "BYWEEKNO"; value: "MO,TU,WE,TH,FR,SA" 1585 5.3.8.6. Normalization 1587 Its value *MUST* be normalized according to the "value-type" of that 1588 value. 1590 5.4. Date and Time Value Types 1592 These date and time related value types are based on [ISO.8601.2004] 1593 and [ISO.8601.2000]. 1595 5.4.1. ISO-DATE-COMPLETE 1597 This corresponds to the DATE value type in 3.3.4 [RFC5545]. 1599 5.4.1.1. Value Type Notation 1601 ISO-DATE-COMPLETE 1603 5.4.1.2. Purpose 1605 Representation of a complete calendar date defined in 1606 [ISO.8601.2004]. 1608 5.4.1.3. Format Definition 1610 iso-date = iso-date-value 1611 iso-date-value = iso-date-fullyear iso-date-month iso-date-mday 1612 iso-date-fullyear = 4DIGIT 1613 iso-date-month = 2DIGIT ;01-12 1614 iso-date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 1615 ;based on month/year 1617 5.4.1.4. Description 1619 This value format is based on the "basic format" calendar date 1620 (specified in 4.1.2.2 [ISO.8601.2004] "Complete representations"). 1622 The value *MUST* be represented textually as "YYYYMMDD", with its 1623 components "YYYY" a four-digit year, "MM" a two-digit month, and "DD" 1624 a two-digit day of the month as described in the definition. 1626 5.4.1.5. Example 1628 The following represents July 1, 1997: 1630 o 19970701 1632 5.4.1.6. Normalization 1634 No normalization procedures are needed. 1636 5.4.2. ISO-DATE-FLEX 1638 Representation of a calendar date [ISO.8601.2004] that does not 1639 require complete representation. 1641 This corresponds to the DATE value type in 4.3.1 [RFC6350]. 1643 5.4.2.1. Value Type Notation 1645 ISO-DATE-FLEX 1647 5.4.2.2. Purpose 1649 This value type defines a calendar date format that allows entry of a 1650 complete calendar date [ISO.8601.2004], a reduced accuracy date 1651 [ISO.8601.2004] and a truncated date [ISO.8601.2004]. 1653 5.4.2.3. Format Definition 1655 iso-date-flex = iso-date / 1656 iso-date-reduced / 1657 iso-date-truncated 1659 iso-date-reduced = iso-date-fullyear / iso-date-year-month 1660 iso-date-year-month = iso-date-fullyear "-" iso-date-month 1662 iso-date-truncated = iso-date-truncated-month-day / 1663 iso-date-truncated-month-only / 1664 iso-date-truncated-day-only 1666 iso-date-truncated-month-day = "--" iso-date-month iso-date-mday 1667 iso-date-truncated-month-only = "--" iso-date-month 1668 iso-date-truncated-day-only = "---" iso-date-mday 1670 5.4.2.4. Description 1672 This value format accepts: 1674 o a complete calendar date, specified in 4.1.2.2 [ISO.8601.2004] 1675 "Complete representations", 1677 o a reduced accuracy calendar date, specified in 4.1.2.3 1678 [ISO.8601.2004] "Representations with reduced accuracy", and 1680 o a truncated representation calendar date, specified in 5.2.1.3 1681 [ISO.8601.2000] "Truncated representations". 1683 The value can be represented in these ways: 1685 o "YYYYMMDD" Complete representation basic format, specified in 1686 4.1.2.2 [ISO.8601.2004]. 1688 o "YYYY-MM" Reduced accuracy representation, specified in 4.1.2.3 a) 1689 [ISO.8601.2004]. 1691 o "YYYY" Reduced accuracy representation, specified in 4.1.2.3 b) 1692 [ISO.8601.2004]. 1694 o "--MMDD" Truncated representation for a specific day of a month in 1695 the implied year, basic format, specified in 5.2.1.3 d) 1696 [ISO.8601.2000]. 1698 o "--MM" Truncated representation for a specific month in the 1699 implied year, basic format, specified in 5.2.1.3 e) 1700 [ISO.8601.2000]. 1702 o "---DD" Truncated representation for a specific day in the implied 1703 month, basic format, specified in 5.2.1.3 f) [ISO.8601.2000]. 1705 Example: 1707 o 20170712 1709 o 2017-07 1711 o 2017 1713 o --0712 1715 o --07 1717 o ---12 1719 5.4.2.5. Normalization 1721 No normalization procedures are needed. 1723 5.4.3. ISO-TIME-COMPLETE 1725 This corresponds to the "time" portion of the TIMESTAMP value type in 1726 4.3.5 [RFC6350]. 1728 5.4.3.1. Value Type Notation 1730 ISO-TIME-COMPLETE 1732 5.4.3.2. Purpose 1734 Representation of a complete time of day with a UTC offset 1735 [ISO.8601.2004]. 1737 5.4.3.3. Format Definition 1739 iso-time = time-hour time-minute time-second 1740 [iso-time-utc / iso-utc-offset] 1742 iso-time-hour = 2DIGIT ;00-23 1743 iso-time-minute = 2DIGIT ;00-59 1744 iso-time-second = 2DIGIT ;00-60 1745 ;The "60" value is used to account for positive "leap" seconds. 1747 iso-time-utc = "Z" 1749 5.4.3.4. Description 1751 This value format accepts a time of day value specified as: 1753 o "hhmmss", the basic format of 4.2.2.2 [ISO.8601.2004] "Complete 1754 representations". 1756 o "hhmmssZ", the first basic format of 4.2.4 [ISO.8601.2004] "UTC of 1757 day". 1759 o "hhmmss+/-hhmm", "hhmmss+/-hh", the basic formats of 4.2.5.2 1760 [ISO.8601.2004] "Local time and the difference from UTC" 1762 The components mean: "hh" a two-digit, 24-hour of the day (00-23), 1763 "mm" a two-digit minute in the hour (00-59), and "ss" a two-digit 1764 second in the minute (00-60). 1766 The seconds value of 60 *MUST* only be used to account for positive 1767 "leap" seconds. Fractions of a second are not supported by this 1768 format. 1770 This value indicates "local time" as specified in 2.1.16 1771 [ISO.8601.2004]. To indicate UTC time, a "Z" character *MUST* be 1772 appended to the basic format as described in 4.2.4 [ISO.8601.2004] 1773 "UTC of day". To indicate a UTC offset, the "utc-offset" section 1774 *MUST* be specified in accordance with 4.2.5.2. [ISO.8601.2004] 1776 The value of "hhmmssZ" *MUST* be used instead of the equivalent 1777 "hhmmss+0000" or "hhmmss-0000". 1779 Example: 1781 o 140000 1783 o 140000Z 1784 o 140000-05 1786 o 140000-0500 1788 5.4.3.5. Normalization 1790 No normalization procedures are needed. 1792 5.4.4. ISO-TIME-BASIC 1794 This corresponds to the TIME value type in 3.3.12 [RFC5545]. 1796 5.4.4.1. Value Type Notation 1798 ISO-TIME-BASIC 1800 5.4.4.2. Purpose 1802 Representation of a complete time of day disallowing a UTC offset 1803 [ISO.8601.2004]. 1805 5.4.4.3. Format Definition 1807 iso-time-basic = iso-time-hour iso-time-minute iso-time-second 1808 [iso-time-utc] 1810 5.4.4.4. Description 1812 This value format is similar to "TIME" except it disallows the 1813 additional UTC offset, (the basic formats of 4.2.5.2 [ISO.8601.2004] 1814 "Local time and the difference from UTC"). 1816 This value format accepts a time of day value specified as: 1818 o "hhmmss", the basic format of 4.2.2.2 [ISO.8601.2004] "Complete 1819 representations". 1821 o "hhmmssZ", the first basic format of 4.2.4 [ISO.8601.2004] "UTC of 1822 day". 1824 The seconds value of 60 *MUST* only be used to account for positive 1825 "leap" seconds. Fractions of a second are not supported by this 1826 format. 1828 This value indicates "local time" as specified in 2.1.16 1829 [ISO.8601.2004]. To indicate UTC time, a "Z" character *MUST* be 1830 appended to the basic format as described in 4.2.4 [ISO.8601.2004] 1831 "UTC of day". 1833 Example: 1835 o 232050 1837 o 232050Z 1839 5.4.4.5. Normalization 1841 No normalization procedures are needed. 1843 5.4.5. ISO-TIME-FLEX 1845 This corresponds to the TIME value type in 4.3.2 [RFC6350]. 1847 5.4.5.1. Value Type Notation 1849 ISO-TIME-FLEX 1851 5.4.5.2. Purpose 1853 This value type defines a time of day format that allows a entry of a 1854 complete time of day [ISO.8601.2004], a reduced accuracy date 1855 [ISO.8601.2004] and a truncated date representation [ISO.8601.2000]. 1857 5.4.5.3. Format Definition 1859 iso-time-flex = iso-time / 1860 iso-time-reduced / 1861 iso-time-truncated 1863 iso-time-zone = iso-time-utc / iso-time-utc-offset 1865 iso-time-reduced = iso-time-reduced-hour-minute / 1866 iso-time-hour 1868 iso-time-reduced-hour-minute = iso-time-hour iso-time-minute 1870 iso-time-truncated = iso-time-truncated-minute-second / 1871 iso-time-truncated-minute-only / 1872 iso-time-truncated-second-only 1873 iso-time-truncated-minute-second = "-" iso-time-minute iso-time-second 1874 iso-time-truncated-minute-only = "-" iso-time-minute 1875 iso-time-truncated-second-only = "--" iso-time-second 1877 5.4.5.4. Description 1879 This value format accepts: 1881 o a complete time of day, specified in 4.2.2.2 [ISO.8601.2004] 1882 "Complete representations", 1884 o a reduced accuracy time of day, specified in 4.2.2.3 1885 [ISO.8601.2004] "Representations with reduced accuracy", 1887 o and a truncated representation time of day, specified in 5.3.1.4 1888 [ISO.8601.2000] "Truncated representations". 1890 The value can be represented in these ways: 1892 o "hhmmss" Complete representation basic format, specified in 1893 4.2.2.2 [ISO.8601.2004]. 1895 o "hhmm" Reduced accuracy representation basic format for a specific 1896 hour and minute, specified in 4.2.2.3 a) [ISO.8601.2004]. 1898 o "hh" Reduced accuracy representation basic format for a specific 1899 hour, specified in 4.2.2.3 b) [ISO.8601.2004]. 1901 o "-mmss" Truncated representation for a specific minute and second 1902 of the implied hour, specified in 5.3.1.4 a) [ISO.8601.2000]. 1904 o "-mm" Truncated representation for a specific minute of the 1905 implied hour, specified in 5.3.1.4 b) [ISO.8601.2000]. 1907 o "--ss" Truncated representation for a specific second of the 1908 implied minute, specified in 5.3.1.4 c) [ISO.8601.2000]. 1910 The seconds value of 60 *MUST* only be used to account for positive 1911 "leap" seconds. Fractions of a second are not supported by this 1912 format. 1914 This value indicates "local time" as specified in 2.1.16 1915 [ISO.8601.2004]. To indicate UTC time, a "Z" character *MUST* be 1916 appended to the basic format as described in 4.2.4 [ISO.8601.2004] 1917 "UTC of day". 1919 This format requires the midnight hour to be represented by "00" 1920 (4.2.3 a) [ISO.8601.2004]), not "24" (4.2.3 b) [ISO.8601.2004]). 1922 This format supports the specification of UTC offsets for the 1923 complete representation basic format (defined in 4.2.5.2 1924 [ISO.8601.2004] basic format), in the form of "hhmmss+/-HHMM". 1926 "HHMM" is the hour and minute of UTC offset, defined in 4.2.5.1 1927 [ISO.8601.2004] basic format. 1929 Example: 1931 o 102200 1933 o 1022 1935 o 10 1937 o -2200 1939 o --00 1941 o 102200Z 1943 o 102200+0800 1945 5.4.5.5. Normalization 1947 No normalization procedures are needed. 1949 5.4.6. ISO-UTC-OFFSET 1951 This corresponds to the UTC-OFFSET value type in 4.7 [RFC6350]. 1953 5.4.6.1. Value Type Notation 1955 ISO-UTC-OFFSET 1957 5.4.6.2. Purpose 1959 Representation of a UTC offset as described in [ISO.8601.2004]. 1961 5.4.6.3. Format Definition 1963 sign = "+" / "-" 1964 iso-utc-offset = sign iso-time-hour [iso-time-minute] 1966 Description: 1968 The value can be represented in two ways: 1970 o "+/-hhmm" specified in 4.2.5.1 [ISO.8601.2004] "Difference between 1971 local time and UTC of day", the first basic format. 1973 o "+/-hh" specified in 4.2.5.1 [ISO.8601.2004] "Difference between 1974 local time and UTC of day", the second basic format. 1976 The PLUS SIGN character MUST be specified for positive UTC offsets 1977 (i.e., ahead of UTC). The HYPHEN-MINUS character MUST be specified 1978 for negative UTC offsets (i.e., behind of UTC). 1980 The value of "-00" and "-0000" are not allowed. The time-minute, if 1981 present, MUST NOT be 60; if absent, it defaults to zero. 1983 5.4.6.4. Example 1985 The following UTC offsets are given for standard time for New York 1986 (five hours behind UTC) and Geneva (one hour ahead of UTC): 1988 o -05 1990 o -0500 1992 o +01 1994 o +0100 1996 5.4.6.5. Normalization 1998 No normalization procedures are needed. 2000 5.4.7. CAL-UTC-OFFSET 2002 This corresponds to the UTC-OFFSET value type in 3.3.14 [RFC5545]. 2004 5.4.7.1. Value Type Notation 2006 CAL-UTC-OFFSET 2008 5.4.7.2. Purpose 2010 Representation of a UTC offset as described in [RFC5545]. 2012 5.4.7.3. Format Definition 2014 cal-utc-offset = sign iso-time-hour iso-time-minute [iso-time-second] 2016 5.4.7.4. Description: 2018 The value can be represented in two ways: 2020 o "+/-hhmm" specified in 4.2.5.1 [ISO.8601.2004] "Difference between 2021 local time and UTC of day", the first basic format. 2023 o "+/-hhmmss" which is unique to this value type. 2025 The PLUS SIGN character MUST be specified for positive UTC offsets 2026 (i.e., ahead of UTC). The HYPHEN-MINUS character MUST be specified 2027 for negative UTC offsets (i.e., behind of UTC). 2029 The value of "-0000" and "-000000" are not allowed. The time-second, 2030 if present, MUST NOT be 60; if absent, it defaults to zero. 2032 5.4.7.5. Example 2034 The following UTC offsets are given for standard time for New York 2035 (five hours behind UTC) and Geneva (one hour ahead of UTC): 2037 o -0500 2039 o -050000 2041 o +0100 2043 o +010000 2045 5.4.7.6. Normalization 2047 No normalization procedures are needed. 2049 5.4.8. ISO-DATE-TIME-COMPLETE 2051 This corresponds to the TIMESTAMP value type in 4.3.5 [RFC6350]. 2053 5.4.8.1. Value Type Notation 2055 ISO-DATE-TIME-COMPLETE 2057 5.4.8.2. Purpose 2059 A complete date and time of day combination as specified in 4.3.2 2060 [ISO.8601.2004] 2062 5.4.8.3. Format Definition 2064 iso-date-time = iso-date "T" iso-time 2066 5.4.8.4. Description 2068 This value format accepts a complete date and time of day 2069 representation, specified in 4.3.2 [ISO.8601.2004] "Complete 2070 representations". 2072 The value can be represented in these ways: 2074 o "YYYYMMDDThhmmss" 4.3.2 Complete representation basic format, 2075 first entry. 2077 o "YYYYMMDDThhmmssZ" 4.3.2 Complete representation basic format, 2078 second entry. 2080 o "YYYYMMDDThhmmss+/-hhmm" 4.3.2 Complete representation basic 2081 format, third entry. 2083 o "YYYYMMDDThhmmss+/-hh" 4.3.2 Complete representation basic format, 2084 fourth entry. 2086 5.4.8.5. Examples 2088 o 19850412T101530 2090 o 19850412T101530Z 2092 o 19850412T101530+0400 2094 o 19850412T101530+04 2096 5.4.8.6. Normalization 2098 No normalization procedures are needed. 2100 5.4.9. ISO-DATE-TIME-BASIC 2102 This corresponds to the DATE-TIME value type in 3.3.5 [RFC5545]. 2104 5.4.9.1. Value Type Notation 2106 ISO-DATE-TIME-BASIC 2108 5.4.9.2. Purpose 2110 A date and time of day combination without non-UTC timezone as 2111 specified in 4.3.2 [ISO.8601.2004] 2113 5.4.9.3. Format Definition 2115 iso-date-time-no-zone = iso-date "T" iso-time-basic 2117 5.4.9.4. Description 2119 This value format accepts a complete date and time of day 2120 representation, specified in 4.3.2 [ISO.8601.2004] "Complete 2121 representations", identical with ISO-DATE-TIME-COMPLETE, except that 2122 the "utc-offset" portion is disallowed. 2124 The value can be represented in these ways: 2126 o "YYYYMMDDThhmmss" 4.3.2 Complete representation basic format, 2127 first entry. 2129 o "YYYYMMDDThhmmssZ" 4.3.2 Complete representation basic format, 2130 second entry. 2132 Due to the lack of "utc-offset", properties that use this value type 2133 *SHOULD* handle time zone information with other methods such as in 2134 property parameters, such as using the "TZID" property parameter 2135 defined in [RFC5545]. 2137 5.4.9.5. Examples 2139 o 19980118T230000 2141 o 19980118T230000Z 2143 5.4.9.6. Normalization 2145 No normalization procedures are needed. 2147 5.4.10. ISO-DATE-TIME-FLEX 2149 This corresponds to the DATE-TIME value type in 4.3.3 [RFC6350]. 2151 5.4.10.1. Value Type Notation 2153 DATE-TIME-FLEX 2155 5.4.10.2. Purpose 2157 This value type defines a date and time of day combination as 2158 specified in 4.3 [ISO.8601.2004] and 5.4.2 c [ISO.8601.2000]). 2160 5.4.10.3. Format Definition 2162 iso-date-time-flex = iso-date-time-flex-date "T" iso-date-time-flex-time 2164 iso-date-time-flex-date = iso-date / iso-date-truncated 2165 iso-date-time-flex-time = iso-time / iso-time-reduced 2167 5.4.10.4. Description 2169 This value format allows for the: 2171 o truncation of the date portion and 2173 o the reduced accuracy of the time portion 2175 o according to the requirements of 5.4.2 [ISO.8601.2000] 2176 "Representations other than complete" part c). 2178 5.4.10.5. Examples 2180 o 19961022T150236 2182 o --1022T1502 2184 o ---22T15 2186 5.4.10.6. Normalization 2188 No normalization procedures are needed. 2190 5.4.11. ISO-DATE-AND-OR-TIME 2192 This corresponds to the DATE-AND-OR-TIME value type in 4.3.4 2193 [RFC6350]. 2195 5.4.11.1. Value Type Notation 2197 ISO-DATE-AND-OR-TIME 2199 5.4.11.2. Purpose 2201 Representation of a ISO-DATE-FLEX, ISO-TIME-FLEX or an ISO-DATE-TIME- 2202 FLEX value. 2204 5.4.11.3. Format Definition 2206 iso-date-and-or-time = iso-date-flex / 2207 "T" iso-time-flex / 2208 iso-date-time-flex 2210 5.4.11.4. Description 2212 This value format accepts values of ISO-DATE-FLEX, ISO-TIME-FLEX and 2213 ISO-DATE-TIME-FLEX. 2215 A stand-alone ISO-TIME value *MUST* be preceded by a "T" for 2216 unambiguous interpretation. 2218 5.4.11.5. Example 2220 o 19961022T140000 2222 o --1022T1400 2224 o ---22T14 2226 o 19850412 2228 o 1985-04 2230 o 1985 2232 o --0412 2234 o ---12 2236 o T102200 2238 o T1022 2240 o T10 2242 o T-2200 2244 o T--00 2246 o T102200Z 2248 o T102200-0800 2250 5.4.11.6. Normalization 2252 No normalization procedures are needed. 2254 5.4.12. ISO-DURATION-COMPLETE 2256 This corresponds to the values accepted by "duration" as specified in 2257 [ISO.8601.2004]. 2259 5.4.12.1. Value Type Notation 2261 ISO-DURATION-COMPLETE 2263 5.4.12.2. Purpose 2265 Representing a duration of time specified by 4.4.3.2 [ISO.8601.2004] 2266 complete representation basic format. 2268 5.4.12.3. Format Definition 2270 iso-duration-sign = ["+"] / "-" 2271 iso-duration = ( iso-duration-sign ) "P" iso-duration-value 2273 iso-duration-value = iso-duration-date / iso-duration-week 2275 iso-duration-date = iso-duration-day "T" iso-duration-time 2277 iso-duration-week = 1*DIGIT "W" 2279 iso-duration-year = 1*DIGIT "Y" 2280 iso-duration-month = 1*DIGIT "M" 2281 iso-duration-day = 1*DIGIT "D" 2283 iso-duration-time = iso-duration-hour iso-duration-minute 2284 iso-duration-second 2286 iso-duration-hour = 1*DIGIT "H" 2287 iso-duration-minute = 1*DIGIT "M" 2288 iso-duration-second = 1*DIGIT "S" 2290 5.4.12.4. Description 2292 The value format is based on the complete representation basic format 2293 specified in 4.4.3.2. [ISO.8601.2004] 2295 It accepts the following formats ("nn" represents): 2297 o "PnnW" 4.4.3.2 [ISO.8601.2004], complete representation, first 2298 basic format, for duration in weeks. 2300 o "PnnYnnMnnDTnnHnnMnnS" 4.4.3.2 [ISO.8601.2004], complete 2301 representation, second basic format, for duration in years, 2302 months, days, hours, minutes and seconds. 2304 This format differs from the specification of 4.4.3.2 [ISO.8601.2004] 2305 in the following areas: 2307 o An optional, preceding "sign", element is used to indicate 2308 positive or negative duration. Negative durations are useful in 2309 representing reverse scheduling, such as the time to trigger an 2310 alarm before an associated time (see [RFC5545]). 2312 o Reduced accuracy as defined in 4.4.3.2 [ISO.8601.2004] is not 2313 allowed. Omission of the number and corresponding designator of 2314 days, hours, minutes or seconds is not allowed even if any of the 2315 expressions are zero (4.4.3.2 [ISO.8601.2004] c)). 2317 o The duration of a week or a day depends on its position in the 2318 calendar. 2320 In the case of discontinuities in the time scale, such as the change 2321 from standard time to daylight time and back, the computation of the 2322 exact duration requires the subtraction or addition of the change of 2323 duration of the discontinuity. Leap seconds *MUST NOT* be considered 2324 when computing an exact duration. 2326 5.4.12.5. Examples 2328 A duration of 15 days, 5 hours, and 20 seconds *MAY* be represented 2329 as 2331 o P0Y0M15DT5H0M20S 2333 A duration of 7 weeks *MAY* be represented as: 2335 o P7W 2337 5.4.12.6. Normalization 2339 No normalization procedures are needed. 2341 5.4.13. CAL-DURATION 2343 This corresponds to the DURATION value type in 3.3.6 [RFC5545]. 2345 5.4.13.1. Value Type Notation 2347 CAL-DURATION 2349 5.4.13.2. Purpose 2351 Representing a duration of time specified by 4.4.3.2 [ISO.8601.2004] 2352 complete representation basic format, similar to ISO-DURATION, but 2353 with syntax tailored to calendaring. 2355 5.4.13.3. Format Definition 2357 cal-duration = cal-duration-sign cal-duration-no-sign 2358 cal-duration-sign = (["+"] / "-") 2359 cal-duration-no-sign = "P" cal-duration-value 2361 cal-duration-value = ( cal-duration-date / 2362 cal-duration-time / 2363 cal-duration-week ) 2365 cal-duration-date = cal-duration-day [cal-duration-time] 2367 cal-duration-time = "T" ( cal-duration-hour / 2368 cal-duration-minute / 2369 cal-duration-second ) 2371 cal-duration-week = 1*DIGIT "W" 2372 cal-duration-hour = 1*DIGIT "H" [cal-duration-minute] 2373 cal-duration-minute = 1*DIGIT "M" [cal-duration-second] 2374 cal-duration-second = 1*DIGIT "S" 2375 cal-duration-day = 1*DIGIT "D" 2377 5.4.13.4. Description 2379 The value format is similar to ISO-DURATION and based on the complete 2380 representation basic format specified in 4.4.3.2 [ISO.8601.2004], but 2381 given extra flexibility to calendaring usage. 2383 It accepts the following formats ("nn" represents): 2385 o "PnnW" 4.4.3.2 [ISO.8601.2004], complete representation, first 2386 basic format, for duration in weeks. 2388 o "PnnDTnnHnnMnnS" 4.4.3.2 [ISO.8601.2004], complete representation, 2389 second basic format, with the omission of years and months, for 2390 duration in days, hours, minutes and seconds. 2392 o "PnnDTnnHnnM" Reduced accuracy with omission of seconds. 2394 o "PnnDTnnH" Reduced accuracy with omission of minutes. 2396 o "PnnD" Reduced accuracy with omission of hours. 2398 This format differs from the specification of 4.4.3.2 [ISO.8601.2004] 2399 in the following areas: 2401 o Years and months are not accepted in this syntax. 2403 o An optional, preceding "sign", element is used to indicate 2404 positive or negative duration. Negative durations are useful in 2405 representing reverse scheduling, such as the time to trigger an 2406 alarm before an associated time (see [RFC5545]). 2408 o Reduced accuracy is allowed for in particular, the omission of the 2409 number and designators of hours, minutes or seconds is allowed 2410 with the omission starting from the extreme right-hand side. In 2411 the case of the omission of the time value, the "T" separator 2412 *MUST* also be omitted. The day ("D") portion *MUST* always be 2413 present. 2415 o The duration of a week or a day depends on its position in the 2416 calendar. 2418 In the case of discontinuities in the time scale, such as the change 2419 from standard time to daylight time and back, the computation of the 2420 exact duration requires the subtraction or addition of the change of 2421 duration of the discontinuity. Leap seconds *MUST NOT* be considered 2422 when computing an exact duration. 2424 When computing an exact duration, the greatest order time components 2425 *MUST* be added first, that is, the number of days *MUST* be added 2426 first, followed by the number of hours, number of minutes, and number 2427 of seconds. 2429 5.4.13.5. Example 2431 A duration of 0 days, 0 hours, and 20 seconds *SHOULD* be represented 2432 as 2434 P0DT0H0M20S 2435 A duration of 15 days, 5 hours, and 3 hours *SHOULD* be represented 2436 as 2438 P15DT5H3M 2440 A duration of 15 days, 5 hours *SHOULD* be represented as 2442 P15DT5H 2444 A duration of 15 days *SHOULD* be represented as 2446 P15D 2448 A duration of 7 weeks *SHOULD* be represented as: 2450 P7W 2452 5.4.13.6. Normalization 2454 No normalization procedures are needed. 2456 5.4.14. ISO-INTERVAL 2458 This corresponds to the values accepted by "time interval" as 2459 specified in [ISO.8601.2004]. 2461 5.4.14.1. Value Type Notation 2463 ISO-INTERVAL-COMPLETE 2465 5.4.14.2. Purpose 2467 Representation of a time interval. 2469 5.4.14.3. Format Definition 2471 iso-interval = iso-interval-explicit / iso-interval-start 2473 iso-interval-explicit = iso-date-time "/" iso-date-time 2474 iso-interval-start = iso-date-time "/" iso-duration-no-sign 2476 5.4.14.4. Description 2478 This value format accepts a time interval representation, specified 2479 in 4.4 [ISO.8601.2004] "Time Interval". 2481 The value can be represented by: 2483 a) a start and an end; 2485 o "YYYYMMDDThhmmss/YYYYMMDDThhmmss" 4.4.4.1 [ISO.8601.2004] Complete 2486 representation, "Representations of time intervals identified by 2487 start and end", basic format, first entry. The start *MUST* be 2488 before the end. 2490 c) a start and a duration; 2492 o "YYYYMMDDThhmmss/PnnYnnMnnDTnnHnnMnnS" 4.4.4.3 [ISO.8601.2004] 2493 Complete representation, "Representations of time interval 2494 identified by start and duration", first basic format. The 2495 duration component *MUST* be positive. 2497 o "YYYYMMDDThhmmss/PnnW" 4.4.4.5 [ISO.8601.2004] Other complete 2498 representations, third item, allowing the expression 2499 "PnnYnnMnnDTnnHnnMnnS" to be substituted with "PnnW" 4.4.3.2 2500 [ISO.8601.2004]. 2502 d) a duration and an end. 2504 o "PnnYnnMnnDTnnHnnMnnS/YYYYMMDDThhmmss" 4.4.4.4 [ISO.8601.2004] 2505 Complete representation, "Representations of time interval 2506 identified by duration and end", first basic format. The start of 2507 the interval can be determined by subtracting the duration 2508 component from the end of the interval. 2510 o "PnnW/YYYYMMDDThhmmss" 4.4.4.5 [ISO.8601.2004] Other complete 2511 representations, third item, allowing the expression 2512 "PnnYnnMnnDTnnHnnMnnS" to be substituted with "PnnW" 4.4.3.2 2513 [ISO.8601.2004]. 2515 In accordance with 4.4.4.5 [ISO.8601.2004]: 2517 o where representations using local time in a time point component 2518 are shown, a complete representation of UTC (4.2.4 2519 [ISO.8601.2004]) or local time and the difference from UTC 2520 (4.2.5.2 [ISO.8601.2004]) *MAY* be substituted for local time, 2521 i.e. representations using the expression "YYYYMMDDThhmmss" could 2522 be substituted with any of these: 2524 o "YYYYMMDDThhmmssZ" 4.3.2 Complete representation basic format, 2525 second entry. 2527 o "YYYYMMDDThhmmss+/-hhmm" 4.3.2 Complete representation basic 2528 format, third entry. 2530 o "YYYYMMDDThhmmss+/-hh" 4.3.2 [ISO.8601.2004] Complete 2531 representation basic format, fourth entry. 2533 In accordance with 4.4.5 [ISO.8601.2004]: 2535 o representations for UTC included with the component preceding the 2536 solidus shall be assumed to apply to the component following the 2537 solidus, unless a corresponding alternative is included. 2539 5.4.14.5. Examples 2541 o 19850412T232050/P1Y2M15DT12H30M0S 2543 o 19850412T232050Z/P1Y2M15DT12H30M0S 2545 o 19850412T232050Z/19850612T232050 2547 o P1Y2M15DT12H30M0S/19850412T232050 2549 5.4.14.6. Normalization 2551 No normalization procedures are needed. 2553 5.4.15. CAL-INTERVAL 2555 This corresponds to the PERIOD value type in 3.3.9 [RFC5545]. 2557 5.4.15.1. Value Type Notation 2559 CAL-INTERVAL 2561 5.4.15.2. Purpose 2563 Representation of a time interval for calendaring. 2565 5.4.15.3. Format Definition 2567 cal-interval = cal-interval-explicit / cal-interval-start 2569 cal-interval-explicit = iso-date-time-no-zone "/" iso-date-time-no-zone 2570 cal-interval-start = iso-date-time-no-zone "/" cal-duration-no-sign 2572 5.4.15.4. Description 2574 This value format accepts a time interval representation, specified 2575 in 4.4. [ISO.8601.2004] "Time Interval" tailored for calendaring 2576 purposes. 2578 The value can be represented in two ways. 2580 As an interval with start and end: 2582 o "YYYYMMDDThhmmss/YYYYMMDDThhmmss" 4.4.4.1 [ISO.8601.2004] Complete 2583 representation, "Representations of time intervals identified by 2584 start and end", basic format, first entry. The start *MUST* be 2585 before the end. 2587 As an interval with start and duration (positive duration only): 2589 o "YYYYMMDDThhmmss/PnnDTnnHnnMnnS" 4.4.4.3 [ISO.8601.2004] Complete 2590 representation, "Representations of time interval identified by 2591 start and duration", first basic format, modified to omit the 2592 "nnYnnM", which is the "cal-duration" period format. 2594 o "YYYYMMDDThhmmss/PnnW" 4.4.4.5 [ISO.8601.2004] Other complete 2595 representations, third item, allowing the expression 2596 "PnnYnnMnnDTnnHnnMnnS" to be substituted with "PnnW" 4.4.3.2 2597 [ISO.8601.2004]. 2599 o "YYYYMMDDThhmmss/PnnDTnnHnnM" with the duration specified in 2600 reduced accuracy with omission of seconds as in Section 5.4.13. 2602 o "YYYYMMDDThhmmss/PnnDTnnH" with the duration specified in reduced 2603 accuracy with omission of minutes as in Section 5.4.13. 2605 o "YYYYMMDDThhmmss/PnnD" with the duration specified in reduced 2606 accuracy with omission of hours as in Section 5.4.13. 2608 In accordance with 4.4.5 [ISO.8601.2004], representations for UTC 2609 included with the component preceding the solidus shall be assumed to 2610 apply to the component following the solidus, unless a corresponding 2611 alternative is included. 2613 5.4.15.5. Examples 2615 o 19970101T180000Z/19970102T070000Z 2617 o 19850412T232050/19850625T103000 2619 o 19970101T180000Z/PT5H30M 2621 o 19850412T232050/P15DT12H30M0S 2623 o 19850412T232050/P00010215T123000 2625 o Both components are in UTC: 19850412T232050Z/19850625T103000 2626 o Former component in local time, latter in UTC: 2627 19850412T232050/19850625T103000 2629 5.4.15.6. Normalization 2631 No normalization procedures are needed. 2633 6. Normalization 2635 A normalization procedure can be applied to vObjects (in its various 2636 representations) to make them compatible prior to comparison, 2637 allowing for consistent results. The result of normalization 2638 processing of a vObject, is an equivalent vObject described according 2639 to vFormat representation. 2641 The normalization method has the following properties: 2643 o stable across different implementations generating the same output 2644 from the same input 2646 o compatible with alternative representation formats such as xCard 2647 [RFC6351] / jCard [RFC7095] and xCal [RFC6321] / jCal [RFC7265] 2649 o generates output adhering to the original vObject format allowing 2650 interoperability with existing implementations 2652 o generates output compatible with protocols that utilize these 2653 vObject, such as CardDAV [RFC6352] and CalDAV [RFC4791] systems. 2655 There are two levels of normalization. 2657 o vObject normalization, of values and property parameter values, 2658 are performed within the vObject data model; 2660 o vFormat normalization, of the format syntax itself, is performed 2661 during serialization of a vObject into vFormat. 2663 6.1. Approach 2665 The goals of the normalization procedure are: 2667 o A normalized vObject will be a valid vObject in vFormat syntax. 2668 Therefore the normalization procedure requires knowledge of the 2669 source specific vObject format. 2671 o A normalized vObject is stable across alternative representation 2672 formats, such as xCal and jCal of iCalendar, and xCard and jCard 2673 of vCard. This allows comparison of vObject content regardless of 2674 the representation format. 2676 o Allows comparison of equivalence of content rather than 2677 formatting. E.g., addition of new-lines within a vCard and order 2678 of listed properties do not affect the resulting normalized form. 2680 o A normalized vObject *MUST* maintain validity under the original 2681 format rules, such as in the case of VCARD [RFC6350] components, 2682 the "VERSION" property line *MUST* be located immediately after 2683 the "BEGIN" property line. 2685 6.2. Steps 2687 In order to serialize a vObject into normalized vFormat syntax, one 2688 would directly serialize the vObject data model into vFormat syntax. 2690 The steps are generally described below. 2692 1. Normalize the vObject 2694 A. Normalize properties 2696 i. Normalize property parameters 2698 A. Normalize property parameter types 2700 B. Normalize property parameter values 2702 I. Sort property parameter values 2703 alphabetically. 2705 II. Concatenate property parameter values. 2707 C. Normalize property parameter key: cast to 2708 uppercase. 2710 D. Concatenate string form of property parameter key, 2711 value type and values. 2713 ii. Normalize property values 2715 B. Normalize inner vObjects (sub-components) 2717 i. Perform the same function as (1) 2719 6.3. Application on alternative serializations 2721 The normalization procedure applies to alternative vObject 2722 representations as well, including: 2724 o xCard [RFC6351] 2726 o jCard [RFC7095] 2728 o xCal [RFC6321] 2730 o jCal [RFC7265] 2732 To normalize a vObject provided in these representations, the vObject 2733 data should be first normalized in data model form according to 2734 Section 3, and then serialized into these representations. 2736 7. Client Implementations Recommendations 2738 A CUA *SHOULD* normalize the vObject upon modification of it. 2740 8. CardDAV 2742 8.1. Additional Server Semantics for PUT, COPY and MOVE 2744 This specification creates an additional precondition and 2745 postcondition for the PUT, COPY, and MOVE methods when: 2747 o A PUT operation requests an address object resource to be placed 2748 into an address book collection; and 2750 o A COPY or MOVE operation requests an address object resource to be 2751 placed into (or out of) an address book collection. 2753 8.1.1. Provide Normalized Output 2755 Certain servers perform silent changes or cleanups of client provided 2756 vCard data when stored as address object resources, such as the order 2757 of property parameters or scrubbed values. 2759 The resulting vCard data stored on the server (and when returned back 2760 to the client) *MAY* end up different than that of the client without 2761 its knowledge. It is therefore necessary for the client to be 2762 reported on such modifications. 2764 Additional Postcondition: 2766 (CARDDAV:resource-normalized): Convert to normalized format. 2768 9. CalDAV 2770 9.1. Additional Server Semantics for PUT, COPY and MOVE 2772 This specification creates an additional precondition and 2773 postcondition for the PUT, COPY, and MOVE methods when: 2775 o A PUT operation of a calendar object resource into a calendar 2776 collection occurs [RFC4791]; 2778 o A COPY or MOVE operation of a calendar object resource into a 2779 calendar collection occurs [RFC4791]; and 2781 o A COPY or MOVE operation occurs on a calendar collection 2782 [RFC4791]. 2784 9.1.1. Provide Normalized Output 2786 Certain servers perform silent changes or cleanups of client provided 2787 iCalendar data when stored as calendar object resources, such as the 2788 order of property parameters or scrubbed values. 2790 The resulting iCalendar data stored on the server (and when returned 2791 back to the client) *MAY* end up different than that of the client 2792 without its knowledge. It is therefore necessary for the client to 2793 be reported on such modifications. 2795 Additional Postcondition: 2797 (CALDAV:resource-normalized): Convert to normalized format. 2799 10. Security Considerations 2801 Security considerations around vObject formats in the following 2802 documents *MUST* be adhered to: 2804 o vCard: [RFC6350] 2806 o iCalendar: [RFC5545], [RFC5789], [RFC4791] 2808 11. IANA Considerations 2810 New vObject and vFormat specifications produced *MUST* adhere to the 2811 requirements, including the normalization process, described in this 2812 document, and any exceptions or further instructions for 2813 normalization *MUST* be described. 2815 11.1. Common vObject Registries 2817 The IANA has created and will maintain the following registries for 2818 vObject elements with pointers to appropriate reference documents. 2819 The registries are grouped together under the heading "vObject Common 2820 Elements". 2822 11.2. vObject Component Uniqueness Identifiers Registry 2824 11.2.1. Registration Procedure 2826 This section defines the process to register new or modified 2827 uniqueness properties for vObject components with IANA. 2829 The IETF will create a mailing list, vobject@ietf.org, which can be 2830 used for public discussion of vObject elements prior to registration. 2832 The registry policy is *Specification Required*; any newly proposed 2833 specification *MUST* be reviewed by the designated expert. 2835 The registry *SHOULD* contain the following note: 2837 Note: Experts are to verify that the proposed registration 2838 *SHOULD* provide benefits for the wider vObject community, 2839 and provides a publicly-available standard that can be implemented in 2840 an interoperable way. References to IETF-published documents are 2841 preferred. The "Reference" value should point to a document that 2842 details the implementation of this property. 2844 The registration procedure begins when a completed registration 2845 template, defined in the sections below, is sent to vobject@ietf.org 2846 and iana@iana.org. 2848 The designated expert is expected to tell IANA and the submitter of 2849 the registration within two weeks whether the registration is 2850 approved, approved with minor changes, or rejected with cause. When 2851 a registration is rejected with cause, it can be re-submitted if the 2852 concerns listed in the cause are addressed. Decisions made by the 2853 designated expert can be appealed to the IESG Applications Area 2854 Director, then to the IESG. They follow the normal appeals procedure 2855 for IESG decisions. 2857 11.2.2. Registration Template 2859 A registration for a vObject Component Uniqueness Property is defined 2860 by completing the following template. 2862 Component 2863 The name of the component. 2865 Property 2866 The property of the component that is used to uniquely identify 2867 the component it belongs to. 2869 Scope 2870 The uniqueness scope of the aforementioned property. 2872 Reference 2873 The document that defines the component syntax and the uniqueness 2874 identifying property. Generally, this is where the component was 2875 originally defined, but if the uniqueness property is defined in 2876 an extension document, a reference to the extension document 2877 *SHOULD* be given instead. 2879 Description 2880 Any special notes about the usage of the uniqueness identifying 2881 property, how it is to be used, etc. 2883 Example(s) 2884 One or more examples of instances of the component need to be 2885 specified. 2887 11.2.3. Initial Registrations 2889 The IANA created and maintains this registry for vObject Component 2890 Uniqueness Identifiers with pointers to appropriate reference 2891 documents. 2893 The following table has been used to initialize the registry. 2895 +--------------+-------------+--------+-----------------------------+ 2896 | Component | Property | Scope | Reference | 2897 +--------------+-------------+--------+-----------------------------+ 2898 | VCALENDAR | UID | Global | 5.3 [RFC7986] | 2899 | VCARD | UID | Global | 6.7.6 [RFC6350] | 2900 | VEVENT | UID | Global | 3.6.1 [RFC5545] | 2901 | VTODO | UID | Global | 3.6.2 [RFC5545] | 2902 | VJOURNAL | UID | Global | 3.6.3 [RFC5545] | 2903 | VFREEBUSY | UID | Global | 3.6.4 [RFC5545] | 2904 | VTIMEZONE | TZID | Global | 3.6.5 [RFC5545] | 2905 | STANDARD | DTSTART | Parent | 3.6.5 [RFC5545] | 2906 | DAYLIGHT | DTSTART | Parent | 3.6.5 [RFC5545] | 2907 | VALARM | UID | Global | 4 [I-D.daboo-valarm-extensi | 2908 | | | | ons] | 2909 | VAVAILABILIT | UID | Global | 3.1 [RFC7953] | 2910 | Y | | | | 2911 | AVAILABLE | UID | Global | 3.1 [RFC7953] | 2912 | VPOLL | UID | Parent | 4.5.1 [I-D.york-vpoll] | 2913 | VVOTER | VOTER | Parent | 4.5.2 [I-D.york-vpoll] | 2914 | VOTE | POLL-ITEM- | Parent | 4.5.3 [I-D.york-vpoll] | 2915 | | ID | | | 2916 +--------------+-------------+--------+-----------------------------+ 2918 12. Mapping Of Data Value Types For Existing RFCs 2920 The vObject value types in this section are described using vObject 2921 value type notation (see Section 5.1). 2923 12.1. RFC 6350 2925 +----------------------+---------------------+ 2926 | vObject Value Type | Original Value Type | 2927 +----------------------+---------------------+ 2928 | BOOLEAN | BOOLEAN | 2929 | ISO-DATE-FLEX | DATE | 2930 | ISO-DATE-AND-OR-TIME | DATE-AND-OR-TIME | 2931 | ISO-DATE-TIME-FLEX | DATE-TIME | 2932 | FLOAT | FLOAT | 2933 | INTEGER-64 | INTEGER | 2934 | LANGUAGE-TAG | LANGUAGE-TAG | 2935 | TEXT | TEXT | 2936 | ISO-TIME-FLEX | TIME | 2937 | ISO-TIME-COMPLETE | TIMESTAMP | 2938 | URI | URI | 2939 | ISO-UTC-OFFSET | UTC-OFFSET | 2940 +----------------------+---------------------+ 2942 12.2. RFC 5545 2944 +---------------------------+---------------------+ 2945 | vObject Value Type | Original Value Type | 2946 +---------------------------+---------------------+ 2947 | BINARY | BINARY | 2948 | BOOLEAN | BOOLEAN | 2949 | URI | CAL-ADDRESS | 2950 | ISO-DATE-COMPLETE | DATE | 2951 | ISO-DATE-TIME-BASIC | DATE-TIME | 2952 | CAL-DURATION | DURATION | 2953 | FLOAT | FLOAT | 2954 | INTEGER-32 | INTEGER | 2955 | CAL-DURATION | PERIOD | 2956 | TEXT | TEXT | 2957 | ISO-TIME-BASIC | TIME | 2958 | URI | URI | 2959 | CAL-UTC-OFFSET | UTC-OFFSET | 2960 | RECURMAP (Section 12.2.1) | RECUR | 2961 +---------------------------+---------------------+ 2963 12.2.1. RECURMAP 2965 RECURMAP is shown here instead of within the tables due to space 2966 constraints. 2968 It is defined to be the value type of the following vObject value 2969 type: 2971 RECURMAP = MAP( 2972 KEYVALUE(FREQ, TEXT), 2973 KEYVALUE(UNTIL, ISO-DATE-COMPLETE / ISO-DATE-TIME-BASIC), 2974 KEYVALUE(COUNT, INTEGER), 2975 KEYVALUE(INTERVAL, INTEGER), 2976 KEYVALUE(BYSECOND, LIST(INTEGER)), 2977 KEYVALUE(BYMINUTE, LIST(INTEGER)), 2978 KEYVALUE(BYHOUR, LIST(INTEGER)), 2979 KEYVALUE(BYDAY, LIST(INTEGER)), 2980 KEYVALUE(BYMONTHDAY, LIST(INTEGER)), 2981 KEYVALUE(BYYEARDAY, LIST(INTEGER)), 2982 KEYVALUE(BYWEEKNO, LIST(INTEGER)), 2983 KEYVALUE(BYMONTH, LIST(INTEGER)), 2984 KEYVALUE(BYSETPOS, INTEGER), 2985 KEYVALUE(WKST, TEXT) 2986 ) 2988 13. Mapping Of Component Property Value Types For Existing RFCs 2990 The default and alternative value types in this section are described 2991 using vObject value type notation (see Section 5.1). 2993 13.1. VCARD Component (RFC 6350) 2995 Properties with the default data type as TEXT. 2997 +-----------+-------------------+--------------+--------------------+ 2998 | Property | Default Value | Alt. Value | Original Value | 2999 | | Type | Types | Type | 3000 +-----------+-------------------+--------------+--------------------+ 3001 | BEGIN | TEXT | | 1\*TEXT | 3002 | END | TEXT | | 1\*TEXT | 3003 | KIND | TEXT | | 1\*TEXT | 3004 | XML | TEXT | | 1\*TEXT | 3005 | FN | TEXT | | 1\*TEXT | 3006 | BDAY | ISO-DATE-AND-OR- | TEXT | 1\*date-and-or- | 3007 | | TIME | | time, 1\*text | 3008 | ANNIVERSA | ISO-DATE-AND-OR- | TEXT | 1\*date-and-or- | 3009 | RY | TIME | | time, 1\*text | 3010 | EMAIL | TEXT | | 1\*TEXT, | 3011 | TZ | TEXT | URI, ISO- | 1\*TEXT, URI, UTC- | 3012 | | | UTC-OFFSET | OFFSET | 3013 | TITLE | TEXT | | 1\*TEXT | 3014 | ROLE | TEXT | | 1\*TEXT | 3015 | NOTE | TEXT | | 1\*TEXT | 3016 | PRODID | TEXT | | 1\*TEXT | 3017 | VERSION | TEXT | | 1\*TEXT | 3018 +-----------+-------------------+--------------+--------------------+ 3020 Properties with the default data type as URI. 3022 +-----------+-----------------+-----------------+-------------------+ 3023 | Property | Default Value | Alt. Value | Original Value | 3024 | | Type | Types | Type | 3025 +-----------+-----------------+-----------------+-------------------+ 3026 | TEL | URI | TEXT | 1\*text, URI | 3027 | SOURCE | URI | | URI | 3028 | PHOTO | URI | | URI | 3029 | IMPP | URI | | URI | 3030 | GEO | URI | | URI | 3031 | LOGO | URI | | URI | 3032 | MEMBER | URI | | URI | 3033 | RELATED | URI | TEXT | URI, 1\*text | 3034 | UID | URI | | URI, 1\*text | 3035 | KEY | URI | | URI, 1\*text | 3036 | SOUND | URI | | URI | 3037 | URL | URI | | URI | 3038 | FBURL | URI | | URI | 3039 | CALADRURI | URI | | URI | 3040 | CALURI | URI | | URI | 3041 +-----------+-----------------+-----------------+-------------------+ 3043 Properties with FIELDSET. 3045 +--------------+-------------------------+-----------+--------------+ 3046 | Property | Default Value Type | Alt. | Original | 3047 | | | Value | Value Type | 3048 | | | Types | | 3049 +--------------+-------------------------+-----------+--------------+ 3050 | N | FIELDSET(5\*LIST(TEXT)) | | TEXT | 3051 | GENDER | FIELDSET(2\*TEXT) | | TEXT | 3052 | ADR | FIELDSET(7\*LIST(TEXT)) | | TEXT | 3053 | ORG | FIELDSET(1\*TEXT) | | TEXT | 3054 | CLIENTPIDMAP | FIELDSET(INTEGER-64, | | TEXT | 3055 | | URI) | | | 3056 +--------------+-------------------------+-----------+--------------+ 3058 Properties with LIST. 3060 +------------+------------------+----------------+------------------+ 3061 | Property | Default Value | Alt. Value | Original Value | 3062 | | Type | Types | Type | 3063 +------------+------------------+----------------+------------------+ 3064 | NICKNAME | LIST(TEXT) | | TEXT | 3065 | CATEGORIES | LIST(TEXT) | | TEXT | 3066 +------------+------------------+----------------+------------------+ 3068 Properties with ISO-DATE-AND-OR-TIME. 3070 +-------------+----------------------+----------+-------------------+ 3071 | Property | Default Value Type | Alt. | Original Value | 3072 | | | Value | Type | 3073 | | | Types | | 3074 +-------------+----------------------+----------+-------------------+ 3075 | BDAY | ISO-DATE-AND-OR-TIME | TEXT | date-and-or-time, | 3076 | | | | text | 3077 | ANNIVERSARY | ISO-DATE-AND-OR-TIME | TEXT | date-and-or-time, | 3078 | | | | text | 3079 +-------------+----------------------+----------+-------------------+ 3081 Properties with ISO-DATE-TIME-COMPLETE. 3083 +----------+------------------------+-------------+-----------------+ 3084 | Property | Default Value Type | Alt. Value | Original Value | 3085 | | | Types | Type | 3086 +----------+------------------------+-------------+-----------------+ 3087 | REV | ISO-DATE-TIME-COMPLETE | | timestamp | 3088 +----------+------------------------+-------------+-----------------+ 3090 Properties with LANGUAGE-TAG. 3092 +----------+-------------------+---------------+--------------------+ 3093 | Property | Default Value | Alt. Value | Original Value | 3094 | | Type | Types | Type | 3095 +----------+-------------------+---------------+--------------------+ 3096 | LANG | LANGUAGE-TAG | | language-tag | 3097 +----------+-------------------+---------------+--------------------+ 3099 13.2. VCALENDAR Component (RFC 5545) 3101 +---------------+-----------------+---------------+-----------------+ 3102 | Property | Default Value | Alt. Value | Original Value | 3103 | | Type | Types | Type | 3104 +---------------+-----------------+---------------+-----------------+ 3105 | PRODID | TEXT | | 1\*TEXT | 3106 | VERSION | TEXT | | 1\*TEXT | 3107 | CALSCALE | TEXT | | 1\*TEXT | 3108 | METHOD | TEXT | | 1\*TEXT | 3109 | IANA-REGed/X- | TEXT | | 1\*TEXT | 3110 +---------------+-----------------+---------------+-----------------+ 3112 13.3. VEVENT Component (RFC 5545) 3114 +--------------+-------------------+------------------+-------------+ 3115 | Property | Default Value | Alt. Value Types | Original | 3116 | | Type | | Value Type | 3117 +--------------+-------------------+------------------+-------------+ 3118 | DTSTAMP | ISO-DATE-TIME- | | DATE-TIME | 3119 | | BASIC | | | 3120 | UID | TEXT | | 1\*TEXT | 3121 | DTSTART | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, | 3122 | | BASIC | COMPLETE | DATE | 3123 | CLASS | TEXT | | 1\*TEXT | 3124 | CREATED | ISO-DATE-TIME- | | DATE-TIME | 3125 | | BASIC | | | 3126 | DESCRIPTION | TEXT | | 1\*TEXT | 3127 | GEO | FIELDSET(2\*FLOAT | | FLOAT ";" | 3128 | | ) | | FLOAT | 3129 | LAST- | ISO-DATE-TIME- | | DATE-TIME | 3130 | MODIFIED | BASIC | | | 3131 | LOCATION | TEXT | | 1\*TEXT | 3132 | ORGANIZER | URI | | cal-address | 3133 | PRIORITY | INTEGER-32 | | INTEGER | 3134 | SEQUENCE | INTEGER-32 | | INTEGER | 3135 | STATUS | TEXT | | 1\*TEXT | 3136 | SUMMARY | TEXT | | 1\*TEXT | 3137 | TRANSP | TEXT | | 1\*TEXT | 3138 | URL | URI | | URI | 3139 | RECURRENCE- | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, | 3140 | ID | BASIC | COMPLETE | DATE | 3141 | RRULE | RECURMAP (Section | | RECUR | 3142 | | 12.2.1) | | | 3143 | DTEND | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, | 3144 | | BASIC | COMPLETE | DATE | 3145 | DURATION | DURATION | | DURATION | 3146 | ATTACH | URI | BINARY | URI, BINARY | 3147 | ATTENDEE | URI | | cal-address | 3148 | CATEGORIES | LIST(TEXT) | | TEXT | 3149 | COMMENT | TEXT | | 1\*TEXT | 3150 | CONTACT | TEXT | | 1\*TEXT | 3151 | EXDATE | LIST( ISO-DATE- | | DATE-TIME, | 3152 | | TIME-BASIC / ISO- | | DATE | 3153 | | DATE-COMPLETE ) | | | 3154 | RELATED-TO | TEXT | | 1\*TEXT | 3155 | RESOURCES | LIST(TEXT) | | TEXT | 3156 | RDATE | LIST( ISO-DATE- | | DATE-TIME, | 3157 | | TIME-BASIC / ISO- | | DATE, | 3158 | | DATE-COMPLETE / | | PERIOD | 3159 | | CAL-INTERVAL) | | | 3160 | IANA- | TEXT | | 1\*TEXT | 3161 | REGed/X- | | | | 3162 +--------------+-------------------+------------------+-------------+ 3164 13.4. VTODO Component (RFC 5545) 3166 +--------------+-------------------+------------------+-------------+ 3167 | Property | Default Value | Alt. Value Types | Original | 3168 | | Type | | Value Type | 3169 +--------------+-------------------+------------------+-------------+ 3170 | DTSTAMP | ISO-DATE-TIME- | | DATE-TIME | 3171 | | BASIC | | | 3172 | UID | TEXT | | 1\*TEXT | 3173 | CLASS | TEXT | | 1\*TEXT | 3174 | CREATED | ISO-DATE-TIME- | | DATE-TIME | 3175 | | BASIC | | | 3176 | COMPLETED | ISO-DATE-TIME- | | DATE-TIME | 3177 | | BASIC | | | 3178 | DESCRIPTION | TEXT | | 1\*TEXT | 3179 | DTSTART | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, | 3180 | | BASIC | COMPLETE | DATE | 3181 | GEO | FIELDSET(2\*FLOAT | | FLOAT ";" | 3182 | | ) | | FLOAT | 3183 | LAST- | ISO-DATE-TIME- | | DATE-TIME | 3184 | MODIFIED | BASIC | | | 3185 | LOCATION | TEXT | | 1\*TEXT | 3186 | ORGANIZER | URI | | cal-address | 3187 | PRIORITY | INTEGER-32 | | INTEGER | 3188 | SEQUENCE | INTEGER-32 | | INTEGER | 3189 | STATUS | TEXT | | 1\*TEXT | 3190 | SUMMARY | TEXT | | 1\*TEXT | 3191 | URL | URI | | URI | 3192 | RRULE | RECURMAP (Section | | RECUR | 3193 | | 12.2.1) | | | 3194 | DUE | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, | 3195 | | BASIC | COMPLETE | DATE | 3196 | DURATION | DURATION | | DURATION | 3197 | ATTACH | URI | BINARY | URI, BINARY | 3198 | ATTENDEE | URI | | cal-address | 3199 | CATEGORIES | LIST(TEXT) | | TEXT | 3200 | COMMENT | TEXT | | 1\*TEXT | 3201 | CONTACT | TEXT | | 1\*TEXT | 3202 | EXDATE | LIST( ISO-DATE- | | DATE-TIME, | 3203 | | TIME-BASIC / ISO- | | DATE | 3204 | | DATE-COMPLETE ) | | | 3205 | REQUEST- | TEXT | | 1\*TEXT | 3206 | STATUS | | | | 3207 | RELATED-TO | TEXT | | 1\*TEXT | 3208 | RESOURCES | LIST(TEXT) | | TEXT | 3209 | RDATE | LIST( ISO-DATE- | | DATE-TIME, | 3210 | | TIME-BASIC / ISO- | | DATE, | 3211 | | DATE-COMPLETE / | | PERIOD | 3212 | | CAL-INTERVAL) | | | 3213 | IANA- | TEXT | | 1\*TEXT | 3214 | REGed/X- | | | | 3215 +--------------+-------------------+------------------+-------------+ 3217 13.5. VJOURNAL Component (RFC 5545) 3219 +--------------+-------------------+------------------+-------------+ 3220 | Property | Default Value | Alt. Value Types | Original | 3221 | | Type | | Value Type | 3222 +--------------+-------------------+------------------+-------------+ 3223 | DTSTAMP | ISO-DATE-TIME- | | DATE-TIME | 3224 | | BASIC | | | 3225 | UID | TEXT | | 1\*TEXT | 3226 | CLASS | TEXT | | 1\*TEXT | 3227 | CREATED | ISO-DATE-TIME- | | DATE-TIME | 3228 | | BASIC | | | 3229 | DTSTART | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, | 3230 | | BASIC | COMPLETE | DATE | 3231 | LAST- | ISO-DATE-TIME- | | DATE-TIME | 3232 | MODIFIED | BASIC | | | 3233 | ORGANIZER | URI | | cal-address | 3234 | SEQUENCE | INTEGER-32 | | INTEGER | 3235 | STATUS | TEXT | | 1\*TEXT | 3236 | SUMMARY | TEXT | | 1\*TEXT | 3237 | URL | URI | | URI | 3238 | RRULE | RECURMAP (Section | | RECUR | 3239 | | 12.2.1) | | | 3240 | ATTACH | URI | BINARY | URI, BINARY | 3241 | ATTENDEE | URI | | cal-address | 3242 | CATEGORIES | LIST(TEXT) | | TEXT | 3243 | COMMENT | TEXT | | 1\*TEXT | 3244 | CONTACT | TEXT | | 1\*TEXT | 3245 | DESCRIPTION | TEXT | | 1\*TEXT | 3246 | EXDATE | LIST( ISO-DATE- | | DATE-TIME, | 3247 | | TIME-BASIC / ISO- | | DATE | 3248 | | DATE-COMPLETE ) | | | 3249 | RELATED-TO | TEXT | | 1\*TEXT | 3250 | RDATE | LIST( ISO-DATE- | | DATE-TIME, | 3251 | | TIME-BASIC / ISO- | | DATE, | 3252 | | DATE-COMPLETE / | | PERIOD | 3253 | | CAL-INTERVAL) | | | 3254 | REQUEST- | TEXT | | 1\*TEXT | 3255 | STATUS | | | | 3256 | IANA- | TEXT | | 1\*TEXT | 3257 | REGed/X- | | | | 3258 +--------------+-------------------+------------------+-------------+ 3260 13.6. VFREEBUSY Component (RFC 5545) 3262 +--------------+-------------------+------------------+-------------+ 3263 | Property | Default Value | Alt. Value Types | Original | 3264 | | Type | | Value Type | 3265 +--------------+-------------------+------------------+-------------+ 3266 | DTSTAMP | ISO-DATE-TIME- | | DATE-TIME | 3267 | | BASIC | | | 3268 | UID | TEXT | | 1\*TEXT | 3269 | CONTACT | TEXT | | 1\*TEXT | 3270 | DTSTART | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, | 3271 | | BASIC | COMPLETE | DATE | 3272 | DTEND | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, | 3273 | | BASIC | COMPLETE | DATE | 3274 | ORGANIZER | URI | | cal-address | 3275 | URL | URI | | URI | 3276 | ATTENDEE | URI | | cal-address | 3277 | COMMENT | TEXT | | 1\*TEXT | 3278 | FREEBUSY | LIST(CAL- | | LIST(PERIOD | 3279 | | INTERVAL) | | ) | 3280 | REQUEST- | TEXT | | 1\*TEXT | 3281 | STATUS | | | | 3282 | IANA- | TEXT | | 1\*TEXT | 3283 | REGed/X- | | | | 3284 +--------------+-------------------+------------------+-------------+ 3286 13.7. VTIMEZONE Component (RFC 5545) 3288 +---------------+---------------------+------------+----------------+ 3289 | Property | Default Value Type | Alt. Value | Original Value | 3290 | | | Types | Type | 3291 +---------------+---------------------+------------+----------------+ 3292 | TZID | TEXT | | 1\*TEXT | 3293 | LAST-MODIFIED | ISO-DATE-TIME-BASIC | | DATE-TIME | 3294 | TZURL | URI | | URI | 3295 | IANA-REGed/X- | TEXT | | 1\*TEXT | 3296 +---------------+---------------------+------------+----------------+ 3298 13.8. STANDARD / DAYLIGHT Components (RFC 5545) 3299 +--------------+--------------------+------------------+------------+ 3300 | Property | Default Value Type | Alt. Value Types | Original | 3301 | | | | Value Type | 3302 +--------------+--------------------+------------------+------------+ 3303 | DTSTART | ISO-DATE-TIME- | ISO-DATE- | DATE-TIME, | 3304 | | BASIC | COMPLETE | DATE | 3305 | TZOFFSETFROM | CAL-UTC-OFFSET | | UTC-OFFSET | 3306 | TZOFFSETTO | CAL-UTC-OFFSET | | UTC-OFFSET | 3307 | RRULE | RECURMAP (Section | | RECUR | 3308 | | 12.2.1) | | | 3309 | COMMENT | TEXT | | 1\*TEXT | 3310 | RDATE | LIST( ISO-DATE- | | DATE-TIME, | 3311 | | TIME-BASIC / ISO- | | DATE, | 3312 | | DATE-COMPLETE / | | PERIOD | 3313 | | CAL-INTERVAL) | | | 3314 | TZNAME | TEXT | | 1\*TEXT | 3315 | IANA- | TEXT | | 1\*TEXT | 3316 | REGed/X- | | | | 3317 +--------------+--------------------+------------------+------------+ 3319 13.9. VALARM Component (RFC 5545) 3321 +---------------+-------------+---------------------+---------------+ 3322 | Property | Default | Alt. Value Types | Original | 3323 | | Value Type | | Value Type | 3324 +---------------+-------------+---------------------+---------------+ 3325 | ACTION | TEXT | | 1\*TEXT | 3326 | DESCRIPTION | TEXT | | 1\*TEXT | 3327 | SUMMARY | TEXT | | 1\*TEXT | 3328 | TRIGGER | DURATION | ISO-DATE-TIME-BASIC | DURATION, | 3329 | | | | DATE-TIME | 3330 | DURATION | DURATION | | DURATION | 3331 | REPEAT | INTEGER-32 | | INTEGER | 3332 | ATTACH | URI | BINARY | URI, BINARY | 3333 | ATTENDEE | URI | | cal-address | 3334 | IANA-REGed/X- | TEXT | | 1\*TEXT | 3335 +---------------+-------------+---------------------+---------------+ 3337 14. Mapping Of Parameter Value Types For Existing RFCs 3339 The value types in this section are described using vObject value 3340 type notation (see Section 5.1). 3342 14.1. RFC 6350 3343 +-----------+--------------+ 3344 | Parameter | Value Type | 3345 +-----------+--------------+ 3346 | LANGUAGE | LANGUAGE-TAG | 3347 | VALUE | TEXT | 3348 | PREF | INTEGER-64 | 3349 | ALTID | TEXT | 3350 | PID | TEXT | 3351 | TYPE | LIST(TEXT) | 3352 | MEDIATYPE | TEXT | 3353 | CALSCALE | TEXT | 3354 | SORT-AS | LIST(TEXT) | 3355 | GEO | URI | 3356 | TZ | TEXT | 3357 +-----------+--------------+ 3359 14.2. RFC 5545 3361 +----------------+--------------+ 3362 | Parameter | Value Type | 3363 +----------------+--------------+ 3364 | ALTREP | URI | 3365 | CN | TEXT | 3366 | CUTYPE | TEXT | 3367 | DELEGATED-FROM | URI | 3368 | DELEGATED-TO | URI | 3369 | DIR | URI | 3370 | ENCODING | TEXT | 3371 | FMTTYPE | TEXT | 3372 | FBTYPE | TEXT | 3373 | LANGUAGE | LANGUAGE-TAG | 3374 | MEMBER | LIST(URI) | 3375 | PARTSTAT | TEXT | 3376 | RANGE | TEXT | 3377 | RELATED | TEXT | 3378 | RELTYPE | TEXT | 3379 | ROLE | TEXT | 3380 | RSVP | BOOLEAN | 3381 | SENT-BY | URI | 3382 | TZID | TEXT | 3383 | VALUE | TEXT | 3384 +----------------+--------------+ 3386 15. References 3387 15.1. Normative References 3389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3390 Requirement Levels", BCP 14, RFC 2119, 3391 DOI 10.17487/RFC2119, March 1997, 3392 . 3394 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3395 Resource Identifier (URI): Generic Syntax", STD 66, 3396 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3397 . 3399 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 3400 Scheduling Core Object Specification (iCalendar)", 3401 RFC 5545, DOI 10.17487/RFC5545, September 2009, 3402 . 3404 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3405 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3406 September 2009, . 3408 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 3409 DOI 10.17487/RFC6350, August 2011, 3410 . 3412 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3413 Writing an IANA Considerations Section in RFCs", BCP 26, 3414 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3415 . 3417 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3418 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3419 May 2017, . 3421 15.2. Informative References 3423 [CALCONNECT-CALENDAR] 3424 The Calendaring and Scheduling Consortium, "CalConnect 3425 CALENDAR Technical Committee", April 2018, 3426 . 3429 [CALCONNECT-VCARD] 3430 The Calendaring and Scheduling Consortium, "CalConnect 3431 VCARD Technical Committee", April 2018, 3432 . 3435 [I-D.daboo-valarm-extensions] 3436 Daboo, C., "VALARM Extensions for iCalendar", draft-daboo- 3437 valarm-extensions-04 (work in progress), June 2012. 3439 [I-D.york-vpoll] 3440 York, E., Daboo, C., and M. Douglass, "VPOLL: Consensus 3441 Scheduling Component for iCalendar", draft-york-vpoll-04 3442 (work in progress), February 2017. 3444 [IEEE.754.2008] 3445 Institute of Electrical and Electronics Engineers, "IEEE 3446 Standard 754, Standard for Binary Floating-Point 3447 Arithmetic", August 2008, 3448 . 3450 [ISO.8601.2000] 3451 ISO/IEC, "ISO 8601:2000, Data elements and interchange 3452 formats -- Information interchange -- Representation of 3453 dates and times", December 2000, 3454 . 3456 [ISO.8601.2004] 3457 ISO/IEC, "ISO 8601:2004, Data elements and interchange 3458 formats -- Information interchange -- Representation of 3459 dates and times", December 2004, 3460 . 3462 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 3463 Extensions (MIME) Part One: Format of Internet Message 3464 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 3465 . 3467 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3468 Text on Security Considerations", BCP 72, RFC 3552, 3469 DOI 10.17487/RFC3552, July 2003, 3470 . 3472 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3473 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 3474 2003, . 3476 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 3477 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 3478 . 3480 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 3481 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 3482 DOI 10.17487/RFC4791, March 2007, 3483 . 3485 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3486 Specifications: ABNF", STD 68, RFC 5234, 3487 DOI 10.17487/RFC5234, January 2008, 3488 . 3490 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 3491 RFC 5789, DOI 10.17487/RFC5789, March 2010, 3492 . 3494 [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML 3495 Format for iCalendar", RFC 6321, DOI 10.17487/RFC6321, 3496 August 2011, . 3498 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 3499 RFC 6351, DOI 10.17487/RFC6351, August 2011, 3500 . 3502 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 3503 Authoring and Versioning (WebDAV)", RFC 6352, 3504 DOI 10.17487/RFC6352, August 2011, 3505 . 3507 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 3508 DOI 10.17487/RFC7095, January 2014, 3509 . 3511 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 3512 Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 3513 2014, . 3515 [RFC7953] Daboo, C. and M. Douglass, "Calendar Availability", 3516 RFC 7953, DOI 10.17487/RFC7953, August 2016, 3517 . 3519 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 3520 DOI 10.17487/RFC7986, October 2016, 3521 . 3523 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 3524 Interchange Format", STD 90, RFC 8259, 3525 DOI 10.17487/RFC8259, December 2017, 3526 . 3528 [vCard21] Internet Mail Consortium, "vCard - The Electronic Business 3529 Card Version 2.1", 09 1996. 3531 [VPATCH] Daboo, C. and K. Murchison, "The iCalendar VPATCH 3532 Component (draft)", 10 2016. 3534 Appendix A. Normalization Examples for vFormat 3536 Original: 3538 BEGIN:VOBJECT 3539 PROPERTY1:10 3540 PROPERTY2:20 3541 END:VOBJECT 3543 Normalized: 3545 BEGIN:VOBJECT 3546 PROPERTY1:10 3547 PROPERTY2:20 3548 END:VOBJECT 3550 A.1. vCard 3552 Original: 3554 BEGIN:VCARD 3555 VERSION:4.0 3556 KIND:individual 3557 FN:Martin Van Buren 3558 N:Van Buren;Martin;;;Hon. 3559 TEL;VALUE=uri;PREF=1;TYPE="voice";TYPE="home":tel:+1-888-888-8888;ext=8888 3560 END:VCARD 3562 Normalized: 3564 BEGIN:VCARD 3565 VERSION:4.0 3566 KIND:individual 3567 FN:Martin Van Buren 3568 N:Van Buren;Martin;;;Hon. 3569 TEL;VALUE=uri;PREF=1;TYPE="voice","home":tel:+1-888-888-8888;ext=8888 3570 END:VCARD 3572 Appendix B. Acknowledgements 3574 The authors wish to thank their families and the following parties 3575 who helped this materialize and for their support of a better and 3576 vObject-enabled world: 3578 o The CalConnect TC-VCARD and TC-CALENDAR committees 3580 o Cyrus Daboo 3582 o Marten Gajda 3584 o The CalConnect Technical Coordination Committee ("TCC") 3586 o Members and the Board of Directors of CalConnect 3588 Authors' Addresses 3590 Ronald Henry Tse 3591 Ribose 3592 Suite 1111, 1 Pedder Street 3593 Central 3594 Hong Kong 3596 Email: ronald.tse@ribose.com 3597 URI: https://www.ribose.com 3599 Peter Kwan Yu Tam 3600 Ribose 3601 Suite 1111, 1 Pedder Street 3602 Central 3603 Hong Kong 3605 Email: peter.tam@ribose.com 3606 URI: https://www.ribose.com 3608 Kenneth Murchison 3609 FastMail Pty Ltd 3610 Level 2, 114 William Street 3611 Melbourne, VIC 3000 3612 Australia 3614 Email: murch@fastmailteam.com 3615 Mike Douglass 3616 Spherical Cow Group 3617 226 3rd Street 3618 Troy, NY 12180 3619 United States of America 3621 Email: mdouglass@sphericalcowgroup.com 3622 URI: http://sphericalcowgroup.com