Network Working Group F. Dawson
Request for Comments: 2447 Lotus
Category: Standards Track S. Mansour
Netscape
S. Silverberg
Microsoft
November 1998
Network Working Group F. Dawson
Request for Comments: 2447 Lotus
Category: Standards Track S. Mansour
Netscape
S. Silverberg
Microsoft
November 1998
iCalendar Message-Based Interoperability Protocol (iMIP)
iCalendar基于消息的互操作性协议（iMIP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document, [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 [iCAL] are composed using constructs from [RFC-822], [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].
本文档[iMIP]指定了从iCalendar传输独立互操作性协议（iTIP）到基于Internet电子邮件的传输的绑定。iCalendar对象模型[iCAL]定义的日历条目是使用[RFC-822]、[RFC-2045]、[RFC-2046]、[RFC-2047]、[RFC-2048]和[RFC-2049]中的结构组成的。
This document is based on discussions within the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents.
本文件基于互联网工程任务组（IETF）日历和日程安排（CALSCH）工作组内的讨论。有关IETF CALSCH工作组活动的更多信息，请访问IMC网站http://www.imc.org，IETF网站http://www.ietf.org/html.charters/calsch-charter.html. 有关如何访问这些不同文档的更多信息，请参阅本文档中的参考资料。
Table of Contents
目录
1 INTRODUCTION........................................................2
1.1 RELATED MEMOS ...................................................2
1.2 FORMATTING CONVENTIONS ..........................................3
1.3 TERMINOLOGY .....................................................4
2 MIME MESSAGE FORMAT BINDING.........................................4
2.1 MIME MEDIA TYPE .................................................4
2.2 SECURITY ........................................................4
2.2.1 Authorization ...............................................4
2.2.2 Authentication ..............................................5
2.2.3 Confidentiality .............................................5
2.3 [RFC-822] ADDRESSES .............................................5
2.4 CONTENT TYPE ....................................................5
2.5 CONTENT-TRANSFER-ENCODING .......................................6
2.6 CONTENT-DISPOSITION .............................................6
3 SECURITY CONSIDERATIONS.............................................7
4 EXAMPLES............................................................8
4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY ........................8
4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS ............8
4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ..9
4.4 MULTIPLE SIMILAR COMPONENTS ....................................10
4.5 MULTIPLE MIXED COMPONENTS ......................................11
4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY ....................13
5 RECOMMENDED PRACTICES..............................................14
5.1 USE OF CONTENT AND MESSAGE IDS .................................14
6 BIBLIOGRAPHY.......................................................15
7 AUTHORS' ADDRESSES.................................................16
8 FULL COPYRIGHT STATEMENT...........................................18
1 INTRODUCTION........................................................2
1.1 RELATED MEMOS ...................................................2
1.2 FORMATTING CONVENTIONS ..........................................3
1.3 TERMINOLOGY .....................................................4
2 MIME MESSAGE FORMAT BINDING.........................................4
2.1 MIME MEDIA TYPE .................................................4
2.2 SECURITY ........................................................4
2.2.1 Authorization ...............................................4
2.2.2 Authentication ..............................................5
2.2.3 Confidentiality .............................................5
2.3 [RFC-822] ADDRESSES .............................................5
2.4 CONTENT TYPE ....................................................5
2.5 CONTENT-TRANSFER-ENCODING .......................................6
2.6 CONTENT-DISPOSITION .............................................6
3 SECURITY CONSIDERATIONS.............................................7
4 EXAMPLES............................................................8
4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY ........................8
4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS ............8
4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ..9
4.4 MULTIPLE SIMILAR COMPONENTS ....................................10
4.5 MULTIPLE MIXED COMPONENTS ......................................11
4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY ....................13
5 RECOMMENDED PRACTICES..............................................14
5.1 USE OF CONTENT AND MESSAGE IDS .................................14
6 BIBLIOGRAPHY.......................................................15
7 AUTHORS' ADDRESSES.................................................16
8 FULL COPYRIGHT STATEMENT...........................................18
1 Introduction
1导言
This binding document provides the transport specific information necessary convey iCalendar Transport-independent Interoperability Protocol (iTIP) over MIME as defined in [RFC-822] and [RFC-2045].
本绑定文档提供了通过[RFC-822]和[RFC-2045]中定义的MIME传输iCalendar传输独立互操作性协议（iTIP）所需的传输特定信息。
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, [iMIP], specifies an Internet email binding for iTIP.
此文档[iMIP]指定iTIP的Internet电子邮件绑定。
[iCAL] - specifies a core specification of objects, data types, properties and property parameters;
[IC]-指定对象、数据类型、属性和属性参数的核心规范；
[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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
Calendaring and scheduling roles are referred to in quoted-strings of text with the first character of each word in upper case. 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 lower case, 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 [RFC-822] and [RFC-2045]. The calendaring and scheduling terms used in this memo are defined in [iCAL] and [iTIP].
本备忘录中使用的电子邮件术语在[RFC-822]和[RFC-2045]中有定义。本备忘录中使用的日历和日程安排术语在[iCAL]和[iTIP]中定义。
2 MIME Message Format Binding
2 MIME消息格式绑定
This section defines the message binding to the MIME electronic mail transport.
本节定义了MIME电子邮件传输的消息绑定。
The sections below refer to the "originator" and the "respondent" of an iMIP message. Typically, the originator is the "Organizer" of an event. The respondent is an "Attendee" of the event.
以下各节涉及iMIP报文的“发起人”和“响应人”。通常，发起者是事件的“组织者”。受访者是活动的“参与者”。
The [RFC-822] "Reply-To" header typically contains the email address of the originator or respondent of an event. However, this cannot be guaranteed as Mail User Agents (MUA) are not required to enforce iMIP semantics.
[RFC-822]“回复”标题通常包含事件发起人或响应人的电子邮件地址。但是，这无法保证，因为不需要邮件用户代理（MUA）来强制实施iMIP语义。
A MIME entity containing content information formatted according to this document will be referenced as a "text/calendar" content type. It is assumed that this content type will be transported through a MIME electronic mail transport.
包含根据本文档格式化的内容信息的MIME实体将被引用为“文本/日历”内容类型。假定此内容类型将通过MIME电子邮件传输。
This section addresses several aspects of security including Authentication, Authorization and Confidentiality. Authentication and confidentiality can be achieved using [RFC-1847] that specifies the Security Multiparts for MIME. This framework defines new content types and subtypes of multipart: signed and encrypted. Each contains two body parts: one for the protected data and another for the control information necessary to remove the protection.
本节讨论了安全性的几个方面，包括身份验证、授权和保密性。可以使用[RFC-1847]来实现身份验证和机密性，该[RFC-1847]指定MIME的安全多部分。该框架定义了多部分的新内容类型和子类型：签名和加密。每个包含两个主体部分：一个用于受保护的数据，另一个用于删除保护所需的控制信息。
In [iTIP] messages, only the "Organizer" is authorized to modify or cancel calendar entries they organize. That is, spoof@xyz.com 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.com that declines a meeting invitation for b@example.com.
在[iTIP]消息中，只有“组织者”有权修改或取消其组织的日历条目。就是，spoof@xyz.com不允许修改或取消由组织的会议a@example.com. 此外，只有答辩人有权向“组织者”表明其身份。也就是说，“组织者”必须忽略来自的[iTIP]消息spoof@xyz.com他拒绝了一个会议邀请b@example.com.
Implementations of iMIP SHOULD verify the authenticity of the creator of an iCalendar object before taking any action. The methods for doing this are presented later in this document.
iMIP的实现应该在采取任何操作之前验证iCalendar对象创建者的真实性。本文后面将介绍执行此操作的方法。
[RFC-1847] 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.
[RFC-1847]iTIP中的消息流支持通过使用与“与会者”和“组织者”属性关联的“发送人”参数代表“日历用户”工作。但是，没有任何机制来验证“日历用户”是否授权某人代表他们工作。由实现来为“日历用户”提供决策机制。
Authentication can be performed using an implementation of [RFC-1847] "multipart/signed" that supports public/private key certificates. Authentication is possible only on messages that have been signed. Authenticating an unsigned message may not be reliable.
可以使用支持公钥/私钥证书的[RFC-1847]“多部分/签名”的实现来执行身份验证。只能对已签名的邮件进行身份验证。验证未签名消息可能不可靠。
To ensure confidentiality using iMIP implementations should utilize [RFC-1847]-compliant encryption. The protocol does not restrict a "Calendar User Agent" (CUA) from forwarding iCalendar objects to other users or agents.
为确保使用iMIP实现的机密性，应使用[RFC-1847]兼容的加密。该协议不限制“日历用户代理”（CUA）将iCalendar对象转发给其他用户或代理。
The calendar address specified within the "ATTENDEE" property in an iCalendar object MUST be a fully qualified, [RFC-822] address specification for the corresponding "Organizer" or "Attendee" of the "VEVENT" or "VTODO".
iCalendar对象中“ATTENDEE”属性中指定的日历地址必须是“VEVENT”或“VTODO”对应的“组织者”或“与会者”的完全限定[RFC-822]地址规范。
Because [iTIP] does not preclude "Attendees" from forwarding "VEVENTS" or "VTODOS" to others, the [RFC-822] "Sender" value may not equal that of the "Organizer". Additionally, the "Organizer" or "Attendee" cannot be reliably inferred by the [RFC-822] "Sender" or "Reply-to" 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]不排除“与会者”将“事件”或“VTODO”转发给其他人，因此[RFC-822]“发件人”的值可能不等于“组织者”的值。此外，iMIP消息的[RFC-822]“发件人”或“回复”值无法可靠地推断“组织者”或“与会者”。必须通过打开“文本/日历”MIME正文部分并检查“与会者”和“组织者”属性来确定相关地址。
A MIME body part containing content information that conforms to this document MUST have an [RFC-2045] "Content-Type" value of "text/calendar". The [RFC-2045] "Content-Type" header field must also include the type parameter "method". The value MUST be the same as the value of the "METHOD" calendar property within the iCalendar
包含符合此文档的内容信息的MIME正文部分必须具有[RFC-2045]“内容类型”值“文本/日历”。[RFC-2045]“内容类型”标题字段还必须包含类型参数“方法”。该值必须与iCalendar中“METHOD”日历属性的值相同
object. This means that a MIME message containing multiple iCalendar objects with different method values must be further encapsulated with a "multipart/mixed" MIME entity. This will allow each of the iCalendar objects to be encapsulated within their own "text/calendar" MIME entity.
对象这意味着包含多个具有不同方法值的iCalendar对象的MIME消息必须进一步用“多部分/混合”MIME实体进行封装。这将允许每个iCalendar对象封装在它们自己的“文本/日历”MIME实体中。
A "charset" parameter MUST be present if the iCalendar object contains characters that are not part of the US-ASCII character set. [RFC-2046] discusses the selection of an appropriate "charset" value.
如果iCalendar对象包含不属于US-ASCII字符集的字符，则必须存在“charset”参数。[RFC-2046]讨论了适当“字符集”值的选择。
The optional "component" parameter defines the iCalendar component type contained within the iCalendar object.
可选的“component”参数定义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").
“文本/日历”内容类型允许调度消息类型与其他内容信息（即“多部分/混合”）一起包含在MIME消息中，或与调度消息的明文、人类可读形式（即“多部分/替代”）一起包含在MIME消息中。
In order to permit the information in the scheduling message to be understood by MIME user agents (UA) that do not support the "text/calendar" content type, scheduling messages SHOULD be sent with an alternative, human-readable form of the information.
为了允许不支持“文本/日历”内容类型的MIME用户代理（UA）理解调度消息中的信息，调度消息应以可供选择的、人类可读的信息形式发送。
Note that the default character set for iCalendar objects is UTF-8. A transfer encoding SHOULD be used for iCalendar objects containing any characters that are not part of the US-ASCII character set.
请注意，iCalendar对象的默认字符集是UTF-8。对于包含不属于US-ASCII字符集的任何字符的iCalendar对象，应使用传输编码。
The handling of a MIME part should be based on its [RFC-2045] "Content-Type". However, this is not guaranteed to work in all environments. Some environments handle MIME attachments based on their file type or extension. To operate correctly in these environments, implementations may wish to include a "Content-Disposition" property to define a file name.
MIME部件的处理应基于其[RFC-2045]“内容类型”。但是，这并不能保证在所有环境中都能工作。某些环境根据文件类型或扩展名处理MIME附件。为了在这些环境中正确运行，实现可能希望包括“内容处置”属性来定义文件名。
3 Security Considerations
3安全考虑
The security threats that applications must address when implementing iTIP are detailed in [iTIP]. Two spoofing threats are identified: Spoofing the "Organizer", and Spoofing an "Attendee". To address these threats, the originator of an iCalendar object must be authenticated by a recipient. Once 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 attachments using a mechanism based on Security Multiparts for MIME [RFC-1847] to facilitate the authentication the originator of the iCalendar object. Implementations MAY provide a means for users to disable signing and encrypting. The steps are described below:
[iTIP]中详细介绍了应用程序在实施iTIP时必须解决的安全威胁。确定了两种欺骗威胁：欺骗“组织者”和欺骗“与会者”。要解决这些威胁，iCalendar对象的发起人必须经过收件人的身份验证。一旦认证，就可以确定发起人是否有权执行请求的操作。兼容应用程序必须支持使用基于MIME安全多部分的机制[RFC-1847]对文本/日历附件进行签名和加密，以便于对iCalendar对象的发起人进行身份验证。实现可以为用户提供一种禁用签名和加密的方法。步骤如下所述：
1. The iCalendar object MUST be signed by the "Organizer" sending an update or the "Attendee" sending a reply.
1. iCalendar对象必须由发送更新的“组织者”或发送回复的“与会者”签名。
2. Using the [RFC-1847]-compliant security mechanism, determine who signed the iCalendar object. This is the "signer". Note that the signer is not necessarily the person sending an e-mail message since an e-mail message can be forwarded.
2. 使用[RFC-1847]兼容的安全机制，确定谁签署了iCalendar对象。这是“签名者”。请注意，签名者不一定是发送电子邮件的人，因为电子邮件可以转发。
3. Correlate the signer to an "ATTENDEE" property in the iCalendar object. If the signer cannot be correlated to an "ATTENDEE" property, ignore the message.
3. 将签名者与iCalendar对象中的“ATTENDEE”属性关联。如果签名者无法与“ATTENDEE”属性关联，请忽略该消息。
4. Determine whether or not the "ATTENDEE" is authorized to perform the operation as defined by [iTIP]. If the conditions are not met, ignore the message.
4. 确定“与会者”是否有权执行[iTIP]定义的操作。如果不满足条件，则忽略该消息。
5. If all the above conditions are met, the message can be processed.
5. 如果满足上述所有条件，则可以处理该消息。
To address the confidentiality security threats, signed iMIP messages SHOULD be encrypted by a mechanism based on Security Multiparts for MIME [RFC-1847].
为了解决保密性安全威胁，签名的iMIP消息应该通过基于MIME安全多部分的机制进行加密[RFC-1847]。
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".
可以接收由代表另一个“日历用户”工作的人发送的iMIP消息。这是通过检查相关“组织者”或“与会者”属性中的“发送人”参数确定的。[iCAL]和[iTIP]没有提供任何机制来验证“日历用户”是否已授权其他人代表他们工作。为了解决这个安全问题，实现必须为“日历用户”提供机制，以便在应用代表“日历用户”工作的人员所做的更改之前做出决定。
4 Examples
4个例子
This minimal message shows how an iCalendar object references an attachment. The attachment is accessible via its URL.
此最小消息显示iCalendar对象如何引用附件。附件可以通过其URL访问。
From: sman@netscape.com
To: stevesil@microsoft.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: sman@netscape.com
To: stevesil@microsoft.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:sman@netscape.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.com
ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.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.com/pub/docs/foo.doc
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:sman@netscape.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.com
ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.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.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 as well as 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
--01BD3665.3AF0D360
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 7bit
内容传输编码：7bit
This is an alternative representation of a TEXT/CALENDAR MIME Object
When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT
Where:
Organizer: foo1@example.com
Summary: Phone Conference
This is an alternative representation of a TEXT/CALENDAR MIME Object
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:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=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:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=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";
type=text/calendar
From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1";
type=text/calendar
--boundary-example-1
--边界-示例-1
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.vcs"
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.vcs"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=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:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=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/////////////////////////////////
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
--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.vcs"
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.vcs"
BEGIN:VCALENDAR
PRODID:-//ACME/DESKTOPCALENDAR//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:-//ACME/DESKTOPCALENDAR//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.vcs"
----FEE3790DC7E35189CA67CE2C
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event1.vcs"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=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:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=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.vcs"
----FEE3790DC7E35189CA67CE2C
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding:7bit
Content-Disposition: attachment; filename="todo1.vcs"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VTODO
DUE:19970701T090000-0700
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=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:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VTODO
DUE:19970701T090000-0700
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=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.vcs"
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII;
Component=vevent
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.vcs"
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:REQUEST
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo3@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970621T170000Z
DTEND:199706211T173000Z
SUMMARY:Let's discuss the attached document
UID:calsvr.example.com-873970198738777-8aa
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
PROFILE:REQUEST
PROFILE-VERSION:1.0
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:foo1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:foo1@example.com
ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
ATTENDEE;RSVP=YES;TYPE=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
附件：cid:calsvr.example.com-12345aaa序列：0状态：已确认结束：VEVENT结束：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/5yPOSLhD6OctNqLs94XqAG 4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvdriIH 5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5iZnJY6J.
r0lgoddhtaqzajeaafvvd3e4aap///ywaaaataqzaaac/5yPOSLhD6OctNqLs94XqAG 4kiW5omm6sq27gvH8kzX9o1y+s73/g8cofeovgitcoxkmbycr16cnsq9yrnarfcrvdriih 5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/dxgookjurnjiiii3ynjo+agzwyvwwl5izy6j。
----FEE3790DC7E35189CA67CE2C
----FEE3790DC7E35189CA67CE2C
5 Recommended Practices
5建议的做法
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 Message ID (MID) and Content ID (CID). These are defined in [RFC-2111]. Although [RFC-2111] 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 "CU" will have the access or the authorization to view those objects.
[iCAL]规范经常在属性（如“DESCRIPTION”、“ATTACH”、“CONTACT”等）中的数据类型中使用URI。URI的两种形式是消息ID（MID）和内容ID（CID）。这些定义见[RFC-2111]。尽管[RFC-2111]允许在其他MIME实体或存储中引用消息或MIME正文部分，但强烈建议iMIP实现在单个MIME实体中包含所有引用的消息和正文部分。简言之，如果iCalendar对象包含对其他消息或正文部分的CID或MID引用，则实现应确保这些消息和/或正文部分与iCalendar对象一起传输。如果没有，则无法保证接收“CU”将有权访问或授权查看这些对象。
6 Bibliography
6参考书目
[CHST] Character Sets, ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets
[CHST] Character Sets, ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets
[iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification - iCalendar", RFC 2445, November 1998.
[iCAL]Dawson，F.和D.Stenerson，“互联网日历和调度核心对象规范-iCalendar”，RFC 24451998年11月。
[iTIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP): Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, November 1998.
[iTIP]Silverberg，S.，Mansour，S.，Dawson，F.和R.Hopson，“iCalendar传输独立互操作性协议（iTIP）：调度事件，繁忙时间，待办事项和日志条目”，RFC 24461998年11月。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC-1847]Galvin，J.，Murphy，S.，Crocker，S.和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC-2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）-第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996.
[RFC-2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）-第二部分：媒体类型”，RFC 2046，1996年11月。
[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC-2047]Moore，K.，“多用途互联网邮件扩展（MIME）-第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 2048, January 1997.
[RFC-2048]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）-第四部分：注册程序”，RFC 2048，1997年1月。
[RFC-2111] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2111, March 1997.
[RFC-2111]Levinson，E.“内容ID和消息ID统一资源定位器”，RFC 2111，1997年3月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
7 Authors' Addresses
7作者地址
The following address information is provided in a vCard v3.0, Electronic Business Card, format.
以下地址信息以vCard v3.0电子名片格式提供。
BEGIN:VCARD
VERSION:3.0
N:Dawson;Frank
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford
Drive;Raleigh;NC;27613-3502;USA
TEL;TYPE=WORK,MSG:+1-919-676-9515
TEL;TYPE=WORK,FAX:+1-919-676-9564
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Dawson;Frank
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford
Drive;Raleigh;NC;27613-3502;USA
TEL;TYPE=WORK,MSG:+1-919-676-9515
TEL;TYPE=WORK,FAX:+1-919-676-9564
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Mansour;Steve
FN:Steve Mansour
ORG:Netscape Communications Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain
View;CA;94043;USA
TEL;TYPE=WORK,MSG:+1-650-937-2378
TEL;TYPE=WORK,FAX:+1-650-937-2103
EMAIL;TYPE=INTERNET:sman@netscape.com
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Mansour;Steve
FN:Steve Mansour
ORG:Netscape Communications Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain
View;CA;94043;USA
TEL;TYPE=WORK,MSG:+1-650-937-2378
TEL;TYPE=WORK,FAX:+1-650-937-2103
EMAIL;TYPE=INTERNET:sman@netscape.com
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Silverberg;Steve
FN:Steve Silverberg
ORG:Microsoft Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
Redmond;WA;98052-6399;USA
TEL;TYPE=WORK,MSG:+1-425-936-9277
TEL;TYPE=WORK,FAX:+1-425-936-8019
EMAIL;TYPE=INTERNET:stevesil@Microsoft.com
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Silverberg;Steve
FN:Steve Silverberg
ORG:Microsoft Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
Redmond;WA;98052-6399;USA
TEL;TYPE=WORK,MSG:+1-425-936-9277
TEL;TYPE=WORK,FAX:+1-425-936-8019
EMAIL;TYPE=INTERNET:stevesil@Microsoft.com
END:VCARD
The iCalendar Object is a result of the work of the Internet Engineering Task Force Calendaring and scheduling Working Group. The chairmen of that working group are:
iCalendar对象是Internet工程任务组日历和日程安排工作组工作的结果。该工作组的主席是：
BEGIN:VCARD
VERSION:3.0
N:Ganguly;Anik
FN:Anik Ganguly
ORG:Open Text Inc.
ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
Livonia;MI;48152;USA
TEL;TYPE=WORK,MSG:+1-734-542-5955
EMAIL;TYPE=INTERNET:ganguly@acm.org
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Ganguly;Anik
FN:Anik Ganguly
ORG:Open Text Inc.
ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
Livonia;MI;48152;USA
TEL;TYPE=WORK,MSG:+1-734-542-5955
EMAIL;TYPE=INTERNET:ganguly@acm.org
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Moskowitz;Robert
FN:Robert Moskowitz
EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:Moskowitz;Robert
FN:Robert Moskowitz
EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com
END:VCARD
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。