Internet Engineering Task Force (IETF) C. Daboo
Request for Comments: 6868 Apple
Updates: 5545, 6321, 6350, 6351 February 2013
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Daboo
Request for Comments: 6868 Apple
Updates: 5545, 6321, 6350, 6351 February 2013
Category: Standards Track
ISSN: 2070-1721
Parameter Value Encoding in iCalendar and vCard
iCalendar和vCard中的参数值编码
Abstract
摘要
This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications.
本规范更新了iCalendar（RFC 5545）和vCard（RFC 6350）的数据格式，以允许参数值包含现有规范禁止的某些字符。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6868.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6868.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Parameter Value Encoding Scheme .................................3
3.1. iCalendar Example ..........................................4
3.2. vCard Example ..............................................4
4. Security Considerations .........................................4
5. Acknowledgments .................................................4
6. Normative References ............................................5
Appendix A. Choice of Quoting Mechanism ............................6
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Parameter Value Encoding Scheme .................................3
3.1. iCalendar Example ..........................................4
3.2. vCard Example ..............................................4
4. Security Considerations .........................................4
5. Acknowledgments .................................................4
6. Normative References ............................................5
Appendix A. Choice of Quoting Mechanism ............................6
The iCalendar [RFC5545] specification defines a standard way to describe calendar data. The vCard [RFC6350] specification defines a standard way to describe contact data. Both of these use a similar text-based data format. Each iCalendar and vCard data object can include "properties" that have "parameters" and a "value". The value of a "parameter" is typically a token or URI value, but a "generic" text value is also allowed. However, the syntax rules for both iCalendar and vCard prevent the use of a double-quote character or control characters in such values, though double-quote characters and some subset of control characters are allowed in the actual property values.
iCalendar[RFC5545]规范定义了描述日历数据的标准方法。vCard[RFC6350]规范定义了描述联系人数据的标准方法。两者都使用类似的基于文本的数据格式。每个iCalendar和vCard数据对象可以包括具有“参数”和“值”的“属性”。“参数”的值通常是令牌或URI值，但也允许使用“通用”文本值。但是，iCalendar和vCard的语法规则都禁止在此类值中使用双引号字符或控制字符，尽管实际属性值中允许使用双引号字符和一些控制字符子集。
As more and more extensions are being developed for these data formats, there is a need to allow at least double-quotes and line feeds to be included in parameter values. The \-escaping mechanism used for property text values is not defined for use with parameter values and cannot be easily used in a backwards-compatible manner. This specification defines a new character escaping mechanism, compatible with existing parsers and chosen to minimize any impact on existing data.
随着越来越多的扩展被开发用于这些数据格式，需要在参数值中至少包含双引号和换行符。\-用于属性文本值的转义机制未定义为与参数值一起使用，因此无法以向后兼容的方式轻松使用。该规范定义了一种新的字符转义机制，该机制与现有解析器兼容，并选择用于最小化对现有数据的任何影响。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This specification defines the ^ character (U+005E -- Circumflex Accent) as an escape character in parameter values whose value type is defined using the "param-value" syntax element (Section 3.1 of iCalendar [RFC5545] and Section 3.3 of vCard [RFC6350]). The ^-escaping mechanism can be used when the value is either unquoted or quoted (i.e., whether or not the value is surrounded by double-quotes).
本规范将^character（U+005E——扬抑重音）定义为参数值中的转义字符，其值类型使用“param value”语法元素定义（iCalendar[RFC5545]第3.1节和vCard[RFC6350]第3.3节）。^-转义机制可在值未加引号或带引号时使用（即，无论值是否用双引号括起来）。
When generating iCalendar or vCard parameter values, the following apply:
在生成iCalendar或vCard参数值时，以下各项适用：
o formatted text line breaks are encoded into ^n (U+005E, U+006E)
o 格式化的文本换行符编码为^n（U+005E，U+006E）
o the ^ character (U+005E) is encoded into ^^ (U+005E, U+005E)
o ^字符（U+005E）编码为^（U+005E，U+005E）
o the " character (U+0022) is encoded into ^' (U+005E, U+0027)
o “字符（U+0022）被编码成^”（U+005E，U+0027）
When parsing iCalendar or vCard parameter values, the following apply:
在分析iCalendar或vCard参数值时，以下内容适用：
o the character sequence ^n (U+005E, U+006E) is decoded into an appropriate formatted line break according to the type of system being used
o 字符序列^n（U+005E，U+006E）将根据所用系统的类型解码为适当的格式化换行符
o the character sequence ^^ (U+005E, U+005E) is decoded into the ^ character (U+005E)
o 字符序列^^（U+005E，U+005E）被解码成^字符（U+005E）
o the character sequence ^' (U+005E, U+0027) is decoded into the " character (U+0022)
o 字符序列^'（U+005E，U+0027）被解码为“字符（U+0022）”
o if a ^ (U+005E) character is followed by any character other than the ones above, parsers MUST leave both the ^ and the following character in place
o 如果^（U+005E）字符后面跟有除上述字符以外的任何字符，解析器必须将^和后面的字符保留在适当的位置
When converting between iCalendar and vCard text-based data formats and alternative data-format representations such as XML (as described in [RFC6321] and [RFC6351], respectively), implementations MUST ensure that parameter value escape sequences are generated correctly in the text-based format and are decoded when the parameter values appear in the alternate data formats.
在iCalendar和vCard基于文本的数据格式与替代数据格式表示（如[RFC6321]和[RFC6351]中所述）之间转换时，实现必须确保以基于文本的格式正确生成参数值转义序列，并在参数值以备用数据格式出现时进行解码。
The following example is an "ATTENDEE" property with a "CN" parameter whose value includes two double-quote characters. The parameter value is not quoted, as there are no characters in the value that would trigger quoting as required by iCalendar.
以下示例是一个带有“CN”参数的“ATTENDEE”属性，其值包括两个双引号字符。参数值不带引号，因为值中没有按iCalendar要求触发引号的字符。
ATTENDEE;CN=George Herman ^'Babe^' Ruth:mailto:babe@example.com
ATTENDEE;CN=George Herman ^'Babe^' Ruth:mailto:babe@example.com
The unescaped parameter value is
未切换的参数值为
George Herman "Babe" Ruth
乔治·赫尔曼“宝贝”露丝
The following example is a "GEO" property with an "X-ADDRESS" parameter whose value includes several line feed characters. The parameter value is also quoted, since it contains a comma, which triggers quoting as required by vCard.
以下示例是带有“X-ADDRESS”参数的“GEO”属性，其值包括多个换行字符。参数值也会被引用，因为它包含一个逗号，可以根据vCard的要求触发引用。
GEO;X-ADDRESS="Pittsburgh Pirates^n115 Federal St^nPitt
sburgh, PA 15212":geo:40.446816,-80.00566
GEO;X-ADDRESS="Pittsburgh Pirates^n115 Federal St^nPitt
sburgh, PA 15212":geo:40.446816,-80.00566
The unescaped parameter value (where each line is terminated by a line break character sequence) is
未转换的参数值（其中每行由换行符序列终止）为
Pittsburgh Pirates 115 Federal St Pittsburgh, PA 15212
匹兹堡海盗美国宾夕法尼亚州匹兹堡联邦街115号，邮编15212
There are no additional security issues beyond those of iCalendar [RFC5545] and vCard [RFC6350].
除了iCalendar[RFC5545]和vCard[RFC6350]之外，没有其他安全问题。
Thanks to Michael Angstadt, Tim Bray, Mike Douglass, Barry Leiba, Simon Perreault, and Pete Resnick for feedback on this specification.
感谢Michael Angstadt、Tim Bray、Mike Douglass、Barry Leiba、Simon Perreault和Pete Resnick对本规范的反馈。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.
[RFC5545]Desruisseaux，B.“互联网日历和调度核心对象规范（iCalendar）”，RFC 55452009年9月。
[RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML Format for iCalendar", RFC 6321, August 2011.
[RFC6321]Daboo，C.，Douglass，M.，和S.Lees，“xCal:iCalendar的XML格式”，RFC 63212011年8月。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.
[RFC6350]Perreault，S.，“vCard格式规范”，RFC 63502011年8月。
[RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, August 2011.
[RFC6351]Perreault，S.，“xCard:vCard XML表示”，RFC6351，2011年8月。
Having recognized the need for escaping parameter values, the question is what mechanism to use? One obvious choice would be to adopt the \-escaping used for property values. However, that could not be used as-is, because it escapes a double-quote as the sequence of \ followed by double-quote. Consider what the example in Section 3.1 might look like using \-escaping:
认识到需要转义参数值后，问题是使用什么机制？一个明显的选择是采用用于属性值的转义。但是，它不能按原样使用，因为它将双引号转义为\后跟双引号的序列。考虑第3.1节中使用\-逃逸的例子：
ATTENDEE;CN="George Herman \"Babe\" Ruth":mailto:babe@example.com
ATTENDEE;CN="George Herman \"Babe\" Ruth":mailto:babe@example.com
Existing iCalendar/vCard parsers know nothing about escape sequences in parameters. So they would parse the parameter value as:
现有的iCalendar/vCard解析器对参数中的转义序列一无所知。因此，他们将参数值解析为：
George Herman \
乔治·赫尔曼\
i.e., the text between the first and second occurrence of a double-quote. However, the text after the second double-quote ought to be either a : or a ; (to delimit the parameter value from the following parameter or property) but is not, so the parser could legitimately throw an error at that point because the data is syntactically invalid. Thus, for backwards-compatibility reasons, a double-quote cannot be escaped using a sequence that itself includes a double-quote, and hence the choice of using a single-quote in this specification.
i、 例如，双引号第一次和第二次出现之间的文本。但是，第二个双引号后的文本应为：或a；（从以下参数或属性中分隔参数值）但不是，因此解析器可以合法地在该点抛出错误，因为数据在语法上无效。因此，出于向后兼容性的原因，不能使用本身包含双引号的序列对双引号进行转义，因此在本规范中可以选择使用单引号。
Another option would be to use a form of \-escaping modified for use in parameter values only. However, some incorrect, non-interoperable use of \ in parameter values has been observed, and thus it is best to steer clear of that to achieve guaranteed, reliable interoperability. Also, given that double-quote gets changed to single-quote in the escape sequence for a parameter, but not for a value, it is better to not give the impression that the same escape mechanism (and thus code) can be used for both (which could lead to other issues, such as an implementation incorrectly escaping a ; as \; as opposed to quoting the parameter value).
另一种选择是使用一种形式的\-转义，仅用于参数值。然而，已经观察到\in参数值的一些不正确的、不可互操作的使用，因此最好避免这种情况，以实现有保证的、可靠的互操作性。此外，如果参数的转义序列中的双引号更改为单引号，而不是值的转义序列，那么最好不要给人这样的印象，即两个参数可以使用相同的转义机制（以及代码）（这可能会导致其他问题，例如实现错误地转义；as\，而不是引用参数值）。
The choice of ^ as the escape character was made based on the requirement that an ASCII symbol (non-alphanumeric character) be used, and it ought to be one least likely to be found in existing data.
选择^作为转义字符是基于使用ASCII符号（非字母数字字符）的要求，并且它应该是现有数据中最不可能找到的字符之一。
Author's Address
作者地址
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Cyrus Daboo苹果公司，美国加利福尼亚州库珀蒂诺市无限环路1号，邮编95014
EMail: cyrus@daboo.name
URI: http://www.apple.com/
EMail: cyrus@daboo.name
URI: http://www.apple.com/