Internet Engineering Task Force (IETF) A. Melnikov, Ed.
Request for Comments: 6047 Isode Ltd
Obsoletes: 2447 December 2010
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Melnikov, Ed.
Request for Comments: 6047 Isode Ltd
Obsoletes: 2447 December 2010
Category: Standards Track
ISSN: 2070-1721
iCalendar Message-Based Interoperability Protocol (iMIP)
iCalendar基于消息的互操作性协议（iMIP）
Abstract
摘要
This document, "iCalendar Message-Based Interoperability Protocol (iMIP)", specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP.
本文档“iCalendar基于消息的互操作性协议（iMIP）”规定了iCalendar传输独立互操作性协议（iTIP）与基于Internet电子邮件的传输之间的绑定。由iCalendar对象模型（iCalendar）定义的日历项使用来自RFC 5322和MIME（RFC 2045、RFC 2046、RFC 2047和RFC 2049）的构造进行包装，然后通过SMTP传输。
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/rfc6047.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6047.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Related Memos ..............................................3
1.2. Formatting Conventions .....................................3
1.3. Terminology ................................................4
2. MIME Message Format Binding .....................................4
2.1. MIME Media Type ............................................4
2.2. Security ...................................................5
2.2.1. Authorization .......................................5
2.2.2. Authentication ......................................5
2.2.3. Confidentiality .....................................5
2.3. Email Addresses ............................................6
2.4. Content-Type Header Field ..................................6
2.5. Content-Transfer-Encoding Header Field .....................7
2.6. Content-Disposition Header Field ...........................8
3. Security Considerations .........................................8
4. Examples .......................................................11
4.1. Single Component with an ATTACH Property ..................11
4.2. Using multipart/alternative for Low-Fidelity Clients ......11
4.3. Single Component with an ATTACH Property and
Inline Attachment .........................................12
4.4. Multiple Similar Components ...............................14
4.5. Multiple Mixed Components .................................15
4.6. Detailed Components with an ATTACH Property ...............16
5. Recommended Practices ..........................................18
5.1. Use of Content and Message IDs ............................18
6. IANA Considerations ............................................18
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................20
Appendix A. Changes since RFC 2447 ................................21
Appendix B. Acknowledgements ......................................22
1. Introduction ....................................................3
1.1. Related Memos ..............................................3
1.2. Formatting Conventions .....................................3
1.3. Terminology ................................................4
2. MIME Message Format Binding .....................................4
2.1. MIME Media Type ............................................4
2.2. Security ...................................................5
2.2.1. Authorization .......................................5
2.2.2. Authentication ......................................5
2.2.3. Confidentiality .....................................5
2.3. Email Addresses ............................................6
2.4. Content-Type Header Field ..................................6
2.5. Content-Transfer-Encoding Header Field .....................7
2.6. Content-Disposition Header Field ...........................8
3. Security Considerations .........................................8
4. Examples .......................................................11
4.1. Single Component with an ATTACH Property ..................11
4.2. Using multipart/alternative for Low-Fidelity Clients ......11
4.3. Single Component with an ATTACH Property and
Inline Attachment .........................................12
4.4. Multiple Similar Components ...............................14
4.5. Multiple Mixed Components .................................15
4.6. Detailed Components with an ATTACH Property ...............16
5. Recommended Practices ..........................................18
5.1. Use of Content and Message IDs ............................18
6. IANA Considerations ............................................18
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................20
Appendix A. Changes since RFC 2447 ................................21
Appendix B. Acknowledgements ......................................22
This document provides the transport-specific information ("binding") necessary to convey iCalendar Transport-independent Interoperability Protocol (iTIP) [iTIP] over Internet email (using MIME) as defined in [RFC5322] and [RFC2045]. Therefore, this document defines the iCalendar Message-Based Interoperability Protocol (iMIP).
本文档提供了在[RFC5322]和[RFC2045]中定义的通过互联网电子邮件（使用MIME）传输iCalendar传输独立互操作性协议（iTIP）[iTIP]所需的传输特定信息（“绑定”）。因此，本文件定义了iCalendar基于消息的互操作性协议（iMIP）。
Implementers will need to be familiar with several other memos that, along with this memo, form a framework for Internet calendaring and scheduling standards.
实施者需要熟悉其他几个备忘录，这些备忘录与本备忘录一起构成了互联网日历和日程安排标准的框架。
This document specifies an Internet email binding for iTIP.
本文档指定了iTIP的Internet电子邮件绑定。
[iCAL] specifies a core specification of objects, data types, properties, and property parameters.
[iCAL]指定对象、数据类型、属性和属性参数的核心规范。
[iTIP] specifies an interoperability protocol for scheduling between different implementations.
[iTIP]为不同实现之间的调度指定互操作性协议。
This memo does not attempt to repeat the specification of concepts or definitions from these other memos. Where possible, references are made to the memo that provides for the specification of these concepts or definitions.
本备忘录不试图重复其他备忘录中的概念或定义说明。在可能的情况下，参考备忘录，其中规定了这些概念或定义的规范。
The mechanisms defined in this memo are defined in prose. In order to refer to elements of the calendaring and scheduling model, core object, or interoperability protocol defined in [iCAL] and [iTIP], some formatting conventions have been used.
本备忘录中定义的机制以散文形式定义。为了引用[iCAL]和[iTIP]中定义的日历和调度模型、核心对象或互操作性协议的元素，使用了一些格式约定。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Calendaring and scheduling roles are referred to in quoted strings of text with the first character of each word in uppercase. For example, "Organizer" refers to a role of a "Calendar User" within the scheduling protocol defined by [iTIP].
日历和日程安排角色在带引号的文本字符串中引用，每个单词的第一个字符都是大写的。例如，“组织者”是指[iTIP]定义的调度协议中的“日历用户”角色。
Calendar components defined by [iCAL] are referred to with capitalized, quoted strings of text. All calendar components start with the letter "V". For example, "VEVENT" refers to the event calendar component, "VTODO" refers to the to-do calendar component, and "VJOURNAL" refers to the daily journal calendar component.
[iCAL]定义的日历组件是指带有大写引号的文本字符串。所有日历组件都以字母“V”开头。例如，“VEVENT”指的是事件日历组件，“VTODO”指的是待办日历组件，“VJOURNAL”指的是每日日志日历组件。
Scheduling methods defined by [iTIP] are referred to with capitalized, quoted strings of text. For example, "REQUEST" refers to the method for requesting a scheduling calendar component be created or modified; "REPLY" refers to the method a recipient of a request uses to update their status with the "Organizer" of the calendar component.
[iTIP]定义的调度方法使用大写、带引号的文本字符串引用。例如，“请求”是指用于请求创建或修改调度日历组件的方法；“回复”是指请求的收件人使用日历组件的“组织者”更新其状态的方法。
Properties defined by [iCAL] are referred to with capitalized, quoted strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a "Calendar User".
[iCAL]定义的属性是指带有大写引号的文本字符串，后跟“属性”一词。例如，“ATTENDEE”属性指用于传递“日历用户”日历地址的iCalendar属性。
Property parameters defined by [iCAL] are referred to with lowercase, quoted strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value.
由[iCAL]定义的属性参数使用小写、带引号的文本字符串表示，后跟单词“parameter”。例如，“值”参数是指用于替代特性值的默认数据类型的iCalendar特性参数。
The email terms used in this memo are defined in [RFC5322] and [RFC2045]. The calendaring and scheduling terms used in this memo are defined in [iCAL] and [iTIP].
本备忘录中使用的电子邮件术语在[RFC5322]和[RFC2045]中有定义。本备忘录中使用的日历和日程安排术语在[iCAL]和[iTIP]中定义。
This section defines the message binding to the MIME electronic mail transport.
本节定义了MIME电子邮件传输的消息绑定。
The sections below refer to the "originator" and the "recipient" of an iMIP message. In the case of a "request" method, the originator is the "Organizer" and the recipient is an "Attendee" of the event. In the case of a "response" method, the originator is an "Attendee" and the recipient is the "Organizer" of the event.
以下各节涉及iMIP报文的“发起者”和“接收者”。在“请求”方法的情况下，发起者是活动的“组织者”，接收者是活动的“参与者”。对于“响应”方法，发起者是“与会者”，接收者是活动的“组织者”。
The [RFC5322] "Reply-To" header field typically contains the email address of the originator of the scheduling message. However, this cannot be guaranteed because the sender of the iMIP message might not be the originator of the scheduling message and the sender's "Mail User Agent" (MUA) might not enforce iMIP semantics by translating the originator's address into the "Reply-To" email header field.
[RFC5322]“回复”标题字段通常包含计划消息的发起人的电子邮件地址。但是，这无法保证，因为iMIP消息的发送者可能不是计划消息的发起人，并且发送者的“邮件用户代理”（MUA）可能不会通过将发起人的地址转换为“回复”电子邮件头字段来强制实施iMIP语义。
A MIME entity containing content information formatted according to this document will be referenced as a "text/calendar" content type [iCAL]. It is assumed that this content type will be transported through a MIME electronic mail transport.
包含根据本文档格式化的内容信息的MIME实体将被引用为“文本/日历”内容类型[iCAL]。假定此内容类型将通过MIME电子邮件传输。
This section addresses several aspects of security including authentication, authorization, and confidentiality. Authentication and confidentiality can be achieved using Secure/MIME (S/MIME) [RFC5750] [RFC5751], which uses the Security Multiparts framework for MIME [RFC1847].
本节介绍了安全性的几个方面，包括身份验证、授权和机密性。可以使用Secure/MIME（S/MIME）[RFC5750][RFC5751]实现身份验证和机密性，它使用MIME[RFC1847]的安全多部分框架。
In iTIP messages [iTIP], only the "Organizer" is authorized to modify or cancel calendar entries she organizes. That is, spoof@xyz.example.net is not allowed to modify or cancel a meeting that was organized by a@example.com. Furthermore, only the respondent has the authorization to indicate their status to the "Organizer". That is, the "Organizer" MUST ignore an iTIP message from spoof@xyz.example.net that declines a meeting invitation for b@example.com.
在iTIP消息[iTIP]中，只有“组织者”有权修改或取消她组织的日历条目。就是，spoof@xyz.example.net不允许修改或取消由组织的会议a@example.com. 此外，只有答辩人有权向“组织者”表明其身份。也就是说，“组织者”必须忽略来自的iTIP消息spoof@xyz.example.net他拒绝了一个会议邀请b@example.com.
Implementations of iMIP SHOULD verify the authenticity of the creator of an iCalendar object before taking any action. Methods for doing this are presented later in this document.
iMIP的实现应该在采取任何操作之前验证iCalendar对象创建者的真实性。本文档后面将介绍执行此操作的方法。
[RFC1847] message flow in iTIP supports someone working on behalf of a "Calendar User" through use of the "sent-by" parameter that is associated with the "ATTENDEE" and "ORGANIZER" properties. However, there is no mechanism to verify whether or not a "Calendar User" has authorized someone to work on their behalf. It is left to implementations to provide mechanisms for the "Calendar Users" to make that decision.
[RFC1847]iTIP中的消息流支持通过使用与“与会者”和“组织者”属性关联的“发送人”参数代表“日历用户”工作。但是，没有任何机制来验证“日历用户”是否授权某人代表他们工作。由实现来为“日历用户”提供决策机制。
Authentication MUST be performed using S/MIME [RFC5750] [RFC5751]. Authentication is possible only on messages that have been signed. Unauthenticated messages (i.e., unsigned messages) may not be trusted.
必须使用S/MIME[RFC5750][RFC5751]执行身份验证。只能对已签名的邮件进行身份验证。未经验证的消息（即未签名的消息）可能不受信任。
To ensure confidentiality using iMIP, implementations SHOULD utilize encryption specified in S/MIME [RFC5750] [RFC5751]. iMIP does not restrict a "Calendar User Agent" (CUA) from forwarding iCalendar objects to other users or agents.
为确保使用iMIP的机密性，实现应使用S/MIME[RFC5750][RFC5751]中指定的加密。iMIP不限制“日历用户代理”（CUA）将iCalendar对象转发给其他用户或代理。
The calendar address specified within the "ORGANIZER" and "ATTENDEE" properties in an iCalendar object sent using iMIP MUST be a proper "mailto:" [MAILTO] URI specification for the corresponding "Organizer" or "Attendee" of the "VEVENT" or "VTODO".
在使用iMIP发送的iCalendar对象的“组织者”和“与会者”属性中指定的日历地址必须是“VEVENT”或“VTODO”的相应“组织者”或“与会者”的正确“mailto:[mailto]URI规范。
Because [iTIP] does not preclude "Attendees" from forwarding "VEVENT"s or "VTODO"s to others, the [RFC5322] "Sender" value may not equal that of the "Organizer". Additionally, the "Organizer" or "Attendee" cannot be reliably inferred by the [RFC5322] "Sender" or "Reply-To" header field values of an iMIP message. The relevant address MUST be ascertained by opening the "text/calendar" MIME body part and examining the "ATTENDEE" and "ORGANIZER" properties.
由于[iTIP]不排除“与会者”将“VEVENT”或“VTODO”转发给其他人，因此[RFC5322]“发件人”的值可能不等于“组织者”的值。此外，iMIP邮件的[RFC5322]“发件人”或“回复”标题字段值无法可靠地推断“组织者”或“与会者”。必须通过打开“文本/日历”MIME正文部分并检查“与会者”和“组织者”属性来确定相关地址。
A MIME body part containing content information that conforms to this document MUST have an [RFC2045] "Content-Type" value of "text/calendar". The [RFC2045] "Content-Type" header field MUST also include the MIME parameter "method". The value MUST be the same (ignoring case) as the value of the "METHOD" property within the iCalendar object.
包含符合此文档的内容信息的MIME正文部分必须具有[RFC2045]“内容类型”值“文本/日历”。[RFC2045]“内容类型”标题字段还必须包含MIME参数“方法”。该值必须与iCalendar对象中“METHOD”属性的值相同（忽略大小写）。
Note 1: A MIME message containing multiple iCalendar objects with different "method" values MUST be further encapsulated with a "multipart/mixed" MIME entity [RFC2046]. This will allow each of the iCalendar objects to be encapsulated within their own "text/calendar" MIME entity.
注1：包含多个具有不同“方法”值的iCalendar对象的MIME消息必须进一步封装为“多部分/混合”MIME实体[RFC2046]。这将允许每个iCalendar对象封装在它们自己的“文本/日历”MIME实体中。
Note 2: A MIME body part with a "Content-Type" value of "text/calendar" that lacks the "method" parameter is not considered to be an iMIP body part and thus is not subject to the requirements specified in this document.
注2：“内容类型”值为“text/calendar”且缺少“method”参数的MIME正文部分不被视为iMIP正文部分，因此不受本文件规定要求的约束。
Note that according to [iCAL] the default character set for iCalendar objects is UTF-8 [UTF-8]. However, the default character set for a "text/*" MIME entity according to [RFC2046] is US-ASCII. Thus, a "charset" MIME parameter MUST be present if the iCalendar object contains characters that can't be represented in the US-ASCII character set and, as specified in [iCAL], it MUST have the value "UTF-8".
请注意，根据[iCAL]，iCalendar对象的默认字符集为UTF-8[UTF-8]。但是，根据[RFC2046]的规定，“text/*”MIME实体的默认字符集是US-ASCII。因此，如果iCalendar对象包含无法在US-ASCII字符集中表示的字符，并且如[iCAL]中所述，它必须具有值“UTF-8”，则必须存在“charset”MIME参数。
The optional "component" MIME parameter defines the iCalendar component type contained within the iCalendar object.
可选的“component”MIME参数定义iCalendar对象中包含的iCalendar组件类型。
The following is an example of this header field with a value that indicates an event message.
以下是此标题字段的示例，其值指示事件消息。
Content-Type: text/calendar; method=REQUEST; charset=UTF-8;
component=vevent
Content-Type: text/calendar; method=REQUEST; charset=UTF-8;
component=vevent
The "text/calendar" content type allows for the scheduling message type to be included in a MIME message with other content information (i.e., "multipart/mixed") or included in a MIME message with a clear-text, human-readable form of the scheduling message (i.e., "multipart/alternative" [RFC2046]).
“文本/日历”内容类型允许调度消息类型与其他内容信息（即“多部分/混合”）一起包含在MIME消息中，或与调度消息的明文、人类可读形式（即“多部分/备选方案”[RFC2046]）一起包含在MIME消息中。
In order to permit the information in the scheduling message to be understood by MIME User Agents (UAs) that do not support the "text/calendar" content type, scheduling messages SHOULD be sent with an alternative, human-readable form of the information.
为了使不支持“文本/日历”内容类型的MIME用户代理（UAs）能够理解调度消息中的信息，调度消息应与可供选择的、人类可读的信息形式一起发送。
Note that "multipart/alternative" MUST NOT be used to represent two slightly different iCalendar objects, for example, two "VEVENT"s with alternative starting times.
请注意，“multipart/alternative”不能用于表示两个稍有不同的iCalendar对象，例如，两个具有可选启动时间的“VEVENT”。
CUAs can use other MIME parameters of the "Content-Type" header field, as well as a language specified in the Content-Language header field [RFC3282], to pick a "text/calendar" part for processing if a "multipart/alternative" MIME message contains more than one "text/calendar" part.
如果“多部分/备选”MIME消息包含多个“文本/日历”部分，CUAs可以使用“内容类型”标题字段的其他MIME参数以及内容语言标题字段[RFC3282]中指定的语言来选择“文本/日历”部分进行处理。
Any receiving UA compliant with this specification MUST be able to process "text/calendar" body parts enclosed within "multipart/*". Note that a "multipart/mixed" MIME message can include multiple "text/calendar" components. The receiving UA MUST be able to process all of them.
符合本规范的任何接收UA必须能够处理“multipart/*”中包含的“文本/日历”主体部件。请注意，“多部分/混合”MIME消息可以包含多个“文本/日历”组件。接收UA必须能够处理所有这些数据。
Unless an iMIP message is transported over 8-bit clean transport (such as SMTP [8BITMIME]), a transfer encoding such as quoted-printable or base64 [RFC2045] MUST be used for iCalendar objects containing any characters that can't be represented in the US-ASCII character set. For example:
除非通过8位干净传输（如SMTP[8BITMIME]）传输iMIP消息，否则必须对包含US-ASCII字符集中无法表示的任何字符的iCalendar对象使用传输编码，如引号可打印或base64[RFC2045]。例如：
From: user1@example.com
To: user2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Date: Wed, 07 May 2008 21:30:25 +0400
Message-ID: <4821E731.5040506@laptop1.example.com>
Content-Type: text/calendar; method=REQUEST; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
From: user1@example.com
To: user2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Date: Wed, 07 May 2008 21:30:25 +0400
Message-ID: <4821E731.5040506@laptop1.example.com>
Content-Type: text/calendar; method=REQUEST; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:user1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:user1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com
DTSTAMP:20080507T170000Z
DTSTART:20080701T160000Z
DTEND:20080701T163000Z
SUMMARY:Phone call to discuss your last visit
DESCRIPTION:=D1=82=D1=8B =D0=BA=D0=B0=D0=BA - =D0=B4=D0=BE=D0=
=B2=D0=BE=D0=BB=D0=B5=D0=BD =D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0
=BE=D0=B9?
UID:calsvr.example.com-8739701987387998
SEQUENCE:0
STATUS:TENTATIVE
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:user1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:user1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com
DTSTAMP:20080507T170000Z
DTSTART:20080701T160000Z
DTEND:20080701T163000Z
SUMMARY:Phone call to discuss your last visit
DESCRIPTION:=D1=82=D1=8B =D0=BA=D0=B0=D0=BA - =D0=B4=D0=BE=D0=
=B2=D0=BE=D0=BB=D0=B5=D0=BD =D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0
=BE=D0=B9?
UID:calsvr.example.com-8739701987387998
SEQUENCE:0
STATUS:TENTATIVE
END:VEVENT
END:VCALENDAR
Implementations MAY include a "Content-Disposition" header field to define a file name for an iCalendar object. However, the handling of a MIME part MUST be based on its [RFC2045] "Content-Type" and not on the extension specified in the "Content-Disposition", as different email malware is known to trick User Agents into misinterpreting content of messages by specifying a file extension in the Content-Disposition header field that doesn't correspond to the value of the "Content-Type" header field.
实现可能包括“内容处置”头字段，用于定义iCalendar对象的文件名。但是，MIME部件的处理必须基于其[RFC2045]“内容类型”，而不是“内容处置”中指定的扩展，众所周知，不同的电子邮件恶意软件通过在内容处置头字段中指定与“内容类型”头字段的值不对应的文件扩展名，诱使用户代理误解消息内容。
The security threats that applications must address when implementing iTIP are detailed in [iTIP]. In particular, two spoofing threats are identified in Section 6.1 of [iTIP]: spoofing the "Organizer", and spoofing an "Attendee". To address these threats, the originator of an iCalendar object must be authenticated by a recipient. Once
[iTIP]中详细介绍了应用程序在实施iTIP时必须解决的安全威胁。特别是，在[iTIP]第6.1节中确定了两种欺骗威胁：欺骗“组织者”和欺骗“与会者”。要解决这些威胁，iCalendar对象的发起人必须经过收件人的身份验证。一旦
authenticated, a determination can be made as to whether or not the originator is authorized to perform the requested operation. Compliant applications MUST support signing and encrypting "text/calendar" body parts using a mechanism based on S/MIME [RFC5750] [RFC5751] in order to facilitate the authentication of the originator of the iCalendar object (see Sections 2.2.2 and 2.2.3). The steps for processing a signed iMIP message are described below:
通过认证，可以确定发起人是否有权执行请求的操作。合规应用程序必须支持使用基于S/MIME[RFC5750][RFC5751]的机制对“文本/日历”主体部分进行签名和加密，以便于对iCalendar对象的发起人进行身份验证（请参见第2.2.2节和第2.2.3节）。处理已签名iMIP消息的步骤如下所述：
1. Using S/MIME, determine who signed the "text/calendar" body part containing the iCalendar object. This is the "signer". (Note that the email address of the signer MUST be specified in the rfc822Name field of the "subject alternative name" extension of the signer certificate, as specified in [RFC5280], Section 4.1.2.6.) Note that the signer is not necessarily the person sending an e-mail message, since an e-mail message can be forwarded.
1. 使用S/MIME，确定谁签署了包含iCalendar对象的“文本/日历”主体部分。这是“签名者”。（注意，签名人的电子邮件地址必须按照[RFC5280]第4.1.2.6节的规定，在签名人证书的“主体替代名称”扩展的RFC822名称字段中指定。）注意，签名人不一定是发送电子邮件的人，因为电子邮件可以转发。
2. Correlate the signer to either an "ATTENDEE" property or to the "ORGANIZER" property in the iCalendar object, based on the method and the calendar component specified in the iCalendar object, as defined in Section 1.4 of [iTIP]. If the signer cannot be correlated to an "ATTENDEE"/"ORGANIZER" property, then actively warn the user controlling the "Calendar User Agent" that the iCalendar object is untrusted, and encourage the user to ignore the message, but give advanced users the option to (a) view the certificate of the signer and the entire certificate chain (if any) in order to help decide if the signer should be trusted to send the message, and then (b) allow the CUA to accept and process the iCalendar object.
2. 根据[iTIP]第1.4节中定义的iCalendar对象中指定的方法和日历组件，将签名人与iCalendar对象中的“ATTENDEE”属性或“ORGANIZER”属性相关联。如果签名者无法关联到“ATTENDEE”/“ORGANIZER”属性，则主动警告控制“Calendar user Agent”的用户iCalendar对象不受信任，并鼓励用户忽略该消息，但允许高级用户选择（a）查看签名者的证书和整个证书链（如果有）为了帮助决定是否应该信任签名者发送消息，然后（b）允许CUA接受并处理iCalendar对象。
3. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized to perform the operation as defined by [iTIP]. If the conditions are not met, ignore the message.
3. 确定“与会者”/“组织者”是否有权执行[iTIP]定义的操作。如果不满足条件，则忽略该消息。
4. If all the above conditions are met, the message can be processed.
4. 如果满足上述所有条件，则可以处理该消息。
S/MIME signing also protects against malicious changes to messages in transit.
S/MIME签名还可以防止对传输中的消息进行恶意更改。
If calendar confidentiality is required by the sender, signed iMIP messages SHOULD be encrypted by a mechanism based on S/MIME [RFC5750] [RFC5751]. If iMIP is used within a single ADministrative Management Domain (ADMD) [RFC5598], SMTP STARTTLS [SMTP-TLS] (together with STARTTLS in IMAP/POP [IMAP-POP-TLS]) MAY alternatively be used to provide calendar confidentiality.
如果发送方要求日历保密，则签名的iMIP消息应通过基于S/MIME[RFC5750][RFC5751]的机制进行加密。如果在单个管理管理域（ADMD）[RFC5598]中使用iMIP，SMTP STARTTLS[SMTP-TLS]（与IMAP/POP[IMAP-POP-TLS]中的STARTTLS一起）也可用于提供日历机密性。
Once a signed and/or encrypted iMIP message is received and successfully verified (as detailed above) by a CUA, the CUA SHOULD remember whether the sender of the message is using signing and/or encrypting. If an unsigned iMIP message is received from the same sender later on, the receiving CUA SHOULD warn the receiving user about a possible man-in-the-middle attack and SHOULD ignore the message, unless explicitly overridden by the user.
一旦CUA接收到签名和/或加密的iMIP消息并成功验证（如上所述），CUA应记住消息的发送者是否正在使用签名和/或加密。如果稍后从同一发送方接收到未签名的iMIP消息，则接收CUA应警告接收用户可能存在中间人攻击，并应忽略该消息，除非用户明确覆盖该消息。
Implementations MAY provide means for users to disable signing and encrypting.
实现可以为用户提供禁用签名和加密的方法。
It is possible to receive iMIP messages sent by someone working on behalf of another "Calendar User". This is determined by examining the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" property. [iCAL] and [iTIP] provide no mechanism to verify that a "Calendar User" has authorized someone else to work on their behalf. To address this security issue, implementations MUST provide mechanisms for the "Calendar Users" to make that decision before applying changes from someone working on behalf of a "Calendar User". One way to achieve this is to reject iMIP messages sent by users other than the "ORGANIZER" or the "ATTENDEE"s. Alternatively, the receiver could have a list of trusted <sent-by, organizer> proxies in its local security policy. And yet another way is to prompt the user for confirmation.
可以接收由代表另一个“日历用户”工作的人发送的iMIP消息。这是通过检查相关“组织者”或“与会者”属性中的“发送人”参数确定的。[iCAL]和[iTIP]没有提供任何机制来验证“日历用户”是否已授权其他人代表他们工作。为了解决这个安全问题，实现必须为“日历用户”提供机制，以便在应用代表“日历用户”工作的人员所做的更改之前做出决定。实现这一点的一种方法是拒绝“组织者”或“与会者”以外的用户发送的iMIP消息。或者，接收者可以在其本地安全策略中具有受信任的<发送者，组织者>代理的列表。还有一种方法是提示用户确认。
iMIP-based calendaring is frequently deployed within a single ADMD, with boundary filtering employed to restrict email calendaring flows to be inside the ADMD. This can help in minimizing malicious changes to calendaring messages in transit, as well as in making authorization decisions less risky.
基于iMIP的日历通常部署在单个ADMD中，使用边界过滤将电子邮件日历流限制在ADMD中。这有助于最大限度地减少对传输中日历消息的恶意更改，并降低授权决策的风险。
A security consideration associated with the use of the Content-Disposition header field is described in Section 2.6.
第2.6节描述了与使用内容处置标头字段相关的安全考虑。
Use of S/MIME makes the security considerations discussed in [RFC5750] [RFC5751] relevant to this document. For additional security considerations regarding certificate and Certificate Revocation List (CRL) verification, please see [RFC5280].
使用S/MIME使[RFC5750][RFC5751]中讨论的安全注意事项与本文档相关。有关证书和证书吊销列表（CRL）验证的其他安全注意事项，请参阅[RFC5280]。
This minimal message shows how an iCalendar object references an attachment. The attachment is accessible via its URL.
此最小消息显示iCalendar对象如何引用附件。附件可以通过其URL访问。
From: sman@netscape.example.com
To: stevesil@microsoft.example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: sman@netscape.example.com
To: stevesil@microsoft.example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:man@netscape.example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:man@netscape.example.com
ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SUMMARY:Phone Conference
DESCRIPTION:Please review the attached document.
UID:calsvr.example.com-873970198738777
ATTACH:ftp://ftp.bar.example.com/pub/docs/foo.doc
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:man@netscape.example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:man@netscape.example.com
ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SUMMARY:Phone Conference
DESCRIPTION:Please review the attached document.
UID:calsvr.example.com-873970198738777
ATTACH:ftp://ftp.bar.example.com/pub/docs/foo.doc
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
This example shows how a client can emit a multipart message that includes both a plain text version and the full iCalendar object. Clients that do not support "text/calendar" will still be capable of rendering the plain text representation.
此示例显示了客户端如何发出包含纯文本版本和完整iCalendar对象的多部分消息。不支持“文本/日历”的客户端仍然能够呈现纯文本表示。
From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="01BD3665.3AF0D360"
From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="01BD3665.3AF0D360"
--01BD3665.3AF0D360
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--01BD3665.3AF0D360
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This is an alternative representation of a "text/calendar" MIME object.
这是“文本/日历”MIME对象的另一种表示形式。
When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT
Where:
Organizer: foo1@example.com
Summary: Phone Conference
When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT
Where:
Organizer: foo1@example.com
Summary: Phone Conference
--01BD3665.3AF0D360
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
--01BD3665.3AF0D360
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T170000Z
DTEND:19970701T173000Z
SUMMARY:Phone Conference
UID:calsvr.example.com-8739701987387771
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T170000Z
DTEND:19970701T173000Z
SUMMARY:Phone Conference
UID:calsvr.example.com-8739701987387771
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
--01BD3665.3AF0D360
--01BD3665.3AF0D360
This example shows how a message containing an iCalendar object references an attached document. The reference is made using a Content-ID (CID). Thus, the iCalendar object and the document are packaged in a "multipart/related" encapsulation.
此示例显示包含iCalendar对象的消息如何引用附加文档。使用内容ID（CID）进行引用。因此，iCalendar对象和文档被打包在“多部分/相关”封装中。
From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1"
From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1"
--boundary-example-1
--边界-示例-1
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T180000Z
DTEND:19970701T183000Z
SUMMARY:Phone Conference
UID:calsvr.example.com-8739701987387771
ATTACH:cid:123456789@example.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T180000Z
DTEND:19970701T183000Z
SUMMARY:Phone Conference
UID:calsvr.example.com-8739701987387771
ATTACH:cid:123456789@example.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
--boundary-example-1
Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="FieldReport.doc"
Content-ID: <123456789@example.com>
--boundary-example-1
Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="FieldReport.doc"
Content-ID: <123456789@example.com>
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD///////////////////////////////// ...
0M8R4KGXGUEAAAAAAAAAAAAAAPAP7/CQGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+////AAAAAAAAAAAAAAEAD EUAAAD////////。。。
--boundary-example-1--
--边界-示例-1--
Multiple iCalendar components of the same type can be included in the iCalendar object when the "METHOD" is the same for each component.
当每个组件的“方法”相同时，同一类型的多个iCalendar组件可以包含在iCalendar对象中。
From: foo1@example.com
To: foo2@example.com
Subject: Summer Company Holidays
Mime-Version: 1.0
Content-Type: text/calendar; method=PUBLISH; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"
From: foo1@example.com
To: foo2@example.com
Subject: Summer Company Holidays
Mime-Version: 1.0
Content-Type: text/calendar; method=PUBLISH; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:PUBLISH
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
DTSTAMP:19970611T150000Z
DTSTART:19970701T150000Z
DTEND:19970701T230000Z
SUMMARY:Company Picnic
DESCRIPTION:Food and drink will be provided
UID:calsvr.example.com-873970198738777-1
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970715T150000Z
DTEND:19970715T230000Z
SUMMARY:Company Bowling Tournament
DESCRIPTION:We have 10 lanes reserved
UID:calsvr.example.com-873970198738777-2
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:PUBLISH
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
DTSTAMP:19970611T150000Z
DTSTART:19970701T150000Z
DTEND:19970701T230000Z
SUMMARY:Company Picnic
DESCRIPTION:Food and drink will be provided
UID:calsvr.example.com-873970198738777-1
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970715T150000Z
DTEND:19970715T230000Z
SUMMARY:Company Bowling Tournament
DESCRIPTION:We have 10 lanes reserved
UID:calsvr.example.com-873970198738777-2
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
Different component types must be encapsulated in separate iCalendar objects.
不同的组件类型必须封装在单独的iCalendar对象中。
From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="--FEE3790DC7E35189CA67CE2C"
From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="--FEE3790DC7E35189CA67CE2C"
This is a multi-part message in MIME format.
这是MIME格式的多部分消息。
----FEE3790DC7E35189CA67CE2C
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event1.ics"
----FEE3790DC7E35189CA67CE2C
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event1.ics"
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SUMMARY:Phone Conference
DESCRIPTION:Discuss what happened at the last meeting
UID:calsvr.example.com-8739701987387772
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SUMMARY:Phone Conference
DESCRIPTION:Discuss what happened at the last meeting
UID:calsvr.example.com-8739701987387772
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
----FEE3790DC7E35189CA67CE2C
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="todo1.ics"
----FEE3790DC7E35189CA67CE2C
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="todo1.ics"
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VTODO
DUE:19970701T160000Z
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES:mailto:foo2@example.com
SUMMARY:Phone Conference
DESCRIPTION:Discuss a new location for the company picnic
UID:calsvr.example.com-td-8739701987387773
SEQUENCE:0
STATUS:NEEDS-ACTION
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VTODO
DUE:19970701T160000Z
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES:mailto:foo2@example.com
SUMMARY:Phone Conference
DESCRIPTION:Discuss a new location for the company picnic
UID:calsvr.example.com-td-8739701987387773
SEQUENCE:0
STATUS:NEEDS-ACTION
END:VEVENT
END:VCALENDAR
----FEE3790DC7E35189CA67CE2C
----FEE3790DC7E35189CA67CE2C
This example shows the format of a message containing a group meeting between three individuals. The "multipart/related" encapsulation is used because the iCalendar object contains an ATTACH property that uses a CID to reference the attachment.
此示例显示了包含三个人之间的小组会议的消息格式。之所以使用“多部分/相关”封装，是因为iCalendar对象包含使用CID引用附件的ATTACH属性。
From: foo1@example.com
MIME-Version: 1.0
To: foo2@example.com,foo3@example.com
Subject: REQUEST - Phone Conference
Content-Type: multipart/related;
boundary="--FEE3790DC7E35189CA67CE2C"
From: foo1@example.com
MIME-Version: 1.0
To: foo2@example.com,foo3@example.com
Subject: REQUEST - Phone Conference
Content-Type: multipart/related;
boundary="--FEE3790DC7E35189CA67CE2C"
----FEE3790DC7E35189CA67CE2C
Content-Type: multipart/alternative;
boundary="--00FEE3790DC7E35189CA67CE2C00"
----FEE3790DC7E35189CA67CE2C
Content-Type: multipart/alternative;
boundary="--00FEE3790DC7E35189CA67CE2C00"
----00FEE3790DC7E35189CA67CE2C00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
----00FEE3790DC7E35189CA67CE2C00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
When: 7/1/1997 10:00PM PDT - 7/1/97 10:30 PM PDT
Where:
Organizer: foo1@example.com
Summary: Let's discuss the attached document
When: 7/1/1997 10:00PM PDT - 7/1/97 10:30 PM PDT
Where:
Organizer: foo1@example.com
Summary: Let's discuss the attached document
----00FEE3790DC7E35189CA67CE2C00
----00FEE3790DC7E35189CA67CE2C00
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII;
Component=vevent
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII;
Component=vevent
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo3@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970621T170000Z
DTEND:199706211T173000Z
SUMMARY:Let's discuss the attached document
UID:calsvr.example.com-873970198738777-8aa
ATTACH:cid:calsvr.example.com-12345aaa
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo3@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970621T170000Z
DTEND:199706211T173000Z
SUMMARY:Let's discuss the attached document
UID:calsvr.example.com-873970198738777-8aa
ATTACH:cid:calsvr.example.com-12345aaa
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
----00FEE3790DC7E35189CA67CE2C00
----00FEE3790DC7E35189CA67CE2C00
----FEE3790DC7E35189CA67CE2C
Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="FieldReport.doc"
Content-ID: <calsvr.example.com-12345aaa>
----FEE3790DC7E35189CA67CE2C
Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="FieldReport.doc"
Content-ID: <calsvr.example.com-12345aaa>
R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94Xq AG4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvd riIH5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5i ZnJY6J ...
r0lgoddhtaqzajeaafvvd3e4aap///ywaaaataqzaaac/5yPOSLhD6OctNqLs94Xq AG4kiW5omm6sq27gvH8kzX9o1y+s73/g8cofeovgitcoxkmbycr16cnsq9yrnarfcrvc5ll5je6rxc3g+v2cguf0uv2Oz+v38L7/dxgookjurnjiii3ynjo+agzwywwwwwl5i znj6j。。。
----FEE3790DC7E35189CA67CE2C
----FEE3790DC7E35189CA67CE2C
This section outlines a series of recommended practices when using a messaging transport to exchange iCalendar objects.
本节概述了使用消息传输交换iCalendar对象时的一系列推荐做法。
The [iCAL] specification makes frequent use of the URI for data types in properties such as "DESCRIPTION", "ATTACH", "CONTACT", and others. Two forms of URIs are the Message ID (MID) and the Content-ID (CID). These are defined in [RFC2392]. Although [RFC2392] allows referencing messages or MIME body parts in other MIME entities or stores, it is strongly RECOMMENDED that iMIP implementations include all referenced messages and body parts in a single MIME entity. Simply put, if an iCalendar object contains CID or MID references to other messages or body parts, implementations should ensure that these messages and/or body parts are transmitted with the iCalendar object. If they are not, there is no guarantee that the receiving CUA will have the access or the authorization to view those objects.
[iCAL]规范经常使用URI来表示属性中的数据类型，如“DESCRIPTION”、“ATTACH”、“CONTACT”等。URI的两种形式是消息ID（MID）和内容ID（CID）。这些在[RFC2392]中定义。尽管[RFC2392]允许在其他MIME实体或存储中引用消息或MIME正文部分，但强烈建议iMIP实现在单个MIME实体中包含所有引用的消息和正文部分。简言之，如果iCalendar对象包含对其他消息或正文部分的CID或MID引用，则实现应确保这些消息和/或正文部分与iCalendar对象一起传输。如果没有，则无法保证接收CUA将有权访问或授权查看这些对象。
The "text/calendar" MIME media type was registered in [iCAL].
“文本/日历”MIME媒体类型已在[iCAL]中注册。
[iCAL] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.
[iCAL]Desruisseaux，B.，Ed.“互联网日历和调度核心对象规范（iCalendar）”，RFC 55452009年9月。
[iTIP] Daboo, C., Ed., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, December 2009.
[iTIP]Daboo，C.，编辑，“iCalendar传输独立互操作性协议（iTIP）”，RFC 55462009年12月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[MAILTO] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.
[MAILTO]Duerst，M.，Masinter，L.，和J.Zawinski，“MAILTO”URI方案”，RFC 6068，2010年10月。
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC1847]Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]Levinson，E.“内容ID和消息ID统一资源定位器”，RFC 2392，1998年8月。
[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月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，2002年2月。
[IMAP-POP-TLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[IMAP-POP-TLS]纽曼，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC 25951999年6月。
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010.
[RFC5750]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2证书处理”，RFC 57502010年1月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[8BITMIME]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“8bit MIMEtransport的SMTP服务扩展”，RFC 16521994年7月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC5598，2009年7月。
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[RFC3282]Alvestrand，H.，“内容语言标题”，RFC 3282，2002年5月。
Updated references. Split them into Normative and Informative.
更新参考资料。将其分为规范性和信息性。
Updated examples to use example.com/example.net domains.
已更新示例以使用example.com/example.net域。
Corrected usage of RFC 2119 language.
纠正了RFC 2119语言的用法。
Clarified that charset=UTF-8 is required, unless the calendar can be entirely represented in US-ASCII.
澄清需要charset=UTF-8，除非日历可以完全用US-ASCII表示。
Clarified that 7-bit content transfer encodings should be used unless the calendar object is known to be transferred over 8-bit clean transport.
澄清应使用7位内容传输编码，除非已知日历对象通过8位干净传输传输。
Clarified that file extension specified in the Content-Disposition header field is not to be used to override the "Content-Type" MIME type.
澄清了“内容处置头”字段中指定的文件扩展名不用于覆盖“内容类型”MIME类型。
Disallowed use of "multipart/alternative" for slightly different representations of the same calendar.
不允许对同一日历的略微不同的表示形式使用“多部分/备选方案”。
Clarified handling of the "method" MIME parameter of the "Content-Type" header field.
阐明了“内容类型”标题字段的“方法”MIME参数的处理。
Clarified that in an iMIP message an ORGANIZER/ATTENDEE property contains a mailto: URI.
澄清了在iMIP邮件中，组织者/与会者属性包含mailto:URI。
Fixed examples with ATTENDEE property to use "CUTYPE=" instead of "TYPE=".
修复了ATTENDEE属性使用“CUTYPE=”而不是“TYPE=”的示例。
Clarified that message integrity/confidentiality should be achieved using S/MIME.
阐明应使用S/MIME实现消息完整性/机密性。
Provided additional examples.
提供了其他示例。
Improved the Security Considerations section.
改进了安全注意事项部分。
Made multiple editorial changes to different sections of the document.
对文档的不同部分进行了多次编辑性更改。
The editor of this document wishes to thank Frank Dawson, Steve Mansour, and Steve Silverberg, the original authors of RFC 2447, as well as the following individuals who have participated in the drafting, review, and discussion of this memo:
本文件编辑感谢RFC 2447的原始作者Frank Dawson、Steve Mansour和Steve Silverberg，以及参与本备忘录起草、审查和讨论的以下个人：
Reinhold Kainhofer, Cyrus Daboo, Bernard Desruisseaux, Eliot Lear, and Peter Saint-Andre.
莱因霍尔德·凯恩霍夫、塞勒斯·达布、伯纳德·德鲁索、艾略特·李尔和彼得·圣安德烈。
Author's Address
作者地址
Alexey Melnikov (editor) Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
亚历克赛·梅尔尼科夫（编辑）英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Isode有限公司TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com