idnits 2.17.1 draft-daboo-ical-vcard-parameter-encoding-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6321, but the abstract doesn't seem to mention this, which it should. -- 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 mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (January 10, 2013) is 4116 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple 4 Updates: 5545,6321,6350,6351 January 10, 2013 5 (if approved) 6 Intended status: Standards Track 7 Expires: July 14, 2013 9 Parameter Value Encoding in iCalendar and vCard 10 draft-daboo-ical-vcard-parameter-encoding-04 12 Abstract 14 This specification updates the data formats for iCalendar (RFC 5545) 15 and vCard (RFC 6350) to allow parameter values to include certain 16 characters forbidden by the existing specifications. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 14, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 54 3. Parameter Value Encoding Scheme . . . . . . . . . . . . . . . . 3 55 3.1. iCalendar Example . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. vCard Examples . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 61 Appendix A. Choice of Quoting Mechanism . . . . . . . . . . . . . 6 62 Appendix B. Change History (To be removed by RFC Editor 63 before publication) . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 The iCalendar [RFC5545] specification defines a standard way to 69 describe calendar data. The vCard [RFC6350] specification defines a 70 standard way to describe contact data. Both of these use a similar 71 text-based data format. Each iCalendar and vCard data object can 72 include "properties" which have "parameters" and a "value". The 73 value of a "parameter" is typically a token or URI value, but a 74 "generic" text value is also allowed. However, the syntax rules for 75 both iCalendar and vCard prevent the use of a double-quote character 76 or control characters in such values, though double-quote and some 77 subset of control characters are allowed in the actual property 78 values. 80 As more and more extensions are being developed for these data 81 formats, there is a need to allow at least double-quotes and line 82 feeds to be included in parameter values. The \-escaping mechanism 83 used for property text values is not defined for use with parameter 84 values and cannot be easily used in a backwards compatible manner. 85 This specification defines a new character escaping mechanism, 86 compatible with existing parsers and chosen to minimise any impact on 87 existing data. 89 2. Conventions Used in This Document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 [RFC2119]. 96 3. Parameter Value Encoding Scheme 98 This specification defines the ^ character (U+005E - Circumflex 99 Accent) as an escape character in parameter values whose value type 100 is defined using the "param-value" syntax element (Section 3.1 of 101 iCalendar [RFC5545] and Section 3.3 of vCard [RFC6350]). The 102 ^-escaping mechanism can be used when the value is either unquoted or 103 quoted (i.e., whether or not the value is surrounded by double- 104 quotes). 106 When generating iCalendar or vCard parameter values the following 107 applies: 109 o formatted text line breaks are encoded into ^n (U+005E, U+006E) 110 o the ^ character (U+005E) is encoded into ^^ (U+005E, U+005E) 112 o the " character (U+0022) is encoded into ^' (U+005E, U+0027) 114 When parsing iCalendar or vCard parameter values the following 115 applies: 117 o the character sequence ^n (U+005E, U+006E) is decoded into an 118 appropriate formatted line break for the system being run on 120 o the character sequence ^^ (U+005E, U+005E) is decoded into the ^ 121 character (U+005E) 123 o the character sequence ^' (U+005E, U+0027) is decoded into the " 124 character (U+0022) 126 o if a ^ (U+005E) character is followed by any other character than 127 the ones above, parsers MUST leave both the ^ and the following 128 character in place 130 When converting between iCalendar and vCard text-based data formats 131 and alternative data-format representations such as XML (as described 132 in [RFC6321] and [RFC6351] respectively), implementations MUST ensure 133 that parameter value escape sequences are generated correctly in the 134 text-based format and are decoded when the parameter values appear in 135 the alternate data formats. 137 3.1. iCalendar Example 139 An "ATTENDEE" property with a "CN" parameter whose value includes two 140 double-quote characters. The parameter value is not quoted as there 141 are no characters in the value that would trigger quoting as required 142 by iCalendar. 144 ATTENDEE;CN=George Herman ^'Babe^' Ruth:mailto:babe@example.com 146 The unescaped parameter value is 148 George Herman "Babe" Ruth 150 3.2. vCard Examples 152 A "GEO" property with a "X-ADDRESS" parameter whose value includes 153 several line feed characters. The parameter value is also quoted 154 since it contains a comma which triggers quoting as required by 155 vCard. 157 GEO;X-ADDRESS="Pittsburgh Pirates^n115 Federal St^nPitt 158 sburgh, PA 15212":geo:40.446816,-80.00566 160 The unescaped parameter value is (where each line is terminated by a 161 line break character sequence) 163 Pittsburgh Pirates 164 115 Federal St 165 Pittsburgh, PA 15212 167 4. Security Considerations 169 There are no additional security issues beyond those of iCalendar 170 [RFC5545] and vCard [RFC6350]. 172 5. IANA Considerations 174 There are none. 176 6. Acknowledgments 178 Thanks to Michael Angstadt, Tim Bray, Mike Douglass, Barry Leiba, 179 Simon Perreault, and Pete Resnick, for feedback on this 180 specification. 182 7. Normative References 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, March 1997. 187 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 188 Core Object Specification (iCalendar)", RFC 5545, 189 September 2009. 191 [RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML 192 Format for iCalendar", RFC 6321, August 2011. 194 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 195 August 2011. 197 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 198 RFC 6351, August 2011. 200 Appendix A. Choice of Quoting Mechanism 202 Having recognized the need for escaping parameters values, the 203 question is what mechanism to use? One obvious choice would be to 204 adopt the \-escaping used for property values. However, that could 205 not be used as-is, because it escapes a double-quote as the sequence 206 of \ followed by double-quote. Consider what the example in 207 Section 3.1 might look like using \-escaping: 209 ATTENDEE;CN="George Herman \"Babe\" Ruth":mailto:babe@example.com 211 Existing iCalendar/vCard parsers know nothing about escape sequences 212 in parameters. So they would parse the parameter value as: 214 George Herman \ 216 i.e. the text between the first and second occurrence of a double- 217 quote. However, the text after the second double-quote ought to be 218 either a : or a ; (to delimit the parameter value from the following 219 parameter or property) but is not - so the parser could legitimately 220 throw an error at that point because the data is syntactically 221 invalid. Thus for backwards compatibility reasons, a double-quote 222 cannot be escaped using a sequence that itself includes a double- 223 quote. Hence the choice of using a single-quote in this 224 specification. 226 Another option would be to use a form of \-escaping modified for use 227 in parameter values only. However, some incorrect, non-interoperable 228 use of \ in parameter values has been observed, and thus it is best 229 to steer clear of that to achieve guaranteed, reliable 230 interoperability. Also, given that double-quote gets changed to 231 single-quote in the escape sequence for a parameter, but not for a 232 value, it is better to not give the impression that the same escape 233 mechanism (and thus code) can be used for both (which could lead to 234 other issues such as an implementations incorrectly escaping a ; as 235 \; as opposed to quoting the parameter value). 237 The choice of ^ as the escape character was made based on the 238 requirement that an ASCII symbol (non-alphanumeric) character be 239 used, and it ought to be one least likely to be found in existing 240 data. 242 Appendix B. Change History (To be removed by RFC Editor before 243 publication) 245 Changes in -03: 247 1. Tweak wording and change SHOULD to MUST for leaving ^+any other 248 character sequences unchanged. 250 2. Added paragraph on interaction with other data-format 251 representations such as XML. 253 Changes in -02: 255 1. Removed unnecessary HTAB escaping. 257 2. Added appendix to describe why ^ was chosen as the escape 258 mechanism. 260 Changes in -01: 262 1. Tweaked vCard example line-folding. 264 Author's Address 266 Cyrus Daboo 267 Apple Inc. 268 1 Infinite Loop 269 Cupertino, CA 95014 270 USA 272 Email: cyrus@daboo.name 273 URI: http://www.apple.com/