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)
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）からのバインディングを指定します。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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のバインディングインターネット電子メールを指定します。
[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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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」は-DOカレンダーコンポーネントを指し、そして「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]によって定義されるスケジューリング方法は、テキストの大文字、引用文字列と呼ばれます。例えば、「要求」は、スケジューリングカレンダーコンポーネント作成または変更することを要求するための方法をいいます。 「REPLY」はリクエストの受信者は、カレンダーコンポーネントの「主催者」とのステータスを更新するために使用する方法を指します。
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の]で定義されたプロパティは、単語「プロパティ」に続くテキストの大文字で、引用符で囲まれた文字列と呼ばれています。例えば、「出席者」プロパティが「カレンダ・ユーザー」のカレンダーのアドレスを伝えるために使用されるの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の]で定義されたプロパティのパラメータは小文字で呼ばれ、単語「パラメータ」に続くテキストの文字列を、引用しました。例えば、「値」パラメータは、プロパティ値のデフォルトのデータ・タイプをオーバーライドするために使用されるの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].
このセクションでは、認証、許可、および機密性など、セキュリティのいくつかの側面を扱います。認証および機密性は、セキュア/ MIME（S / MIME）MIMEマルチパートのセキュリティフレームワークを使用して、[RFC5750]、[RFC5751]、[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によって組織された会議を変更またはキャンセルすることはできませんされています。さらに、唯一の回答者は、「オーガナイザー」に自分の状態を示すための権限を持っています。つまり、「主催者は」b@example.comのための会議招集を辞退spoof@xyz.example.netからのiTIPメッセージを無視しなければなりません。
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.
iTIPで[RFC1847]メッセージ・フローは、「送られた - で、」「出席者」と「ORGANIZER」プロパティに関連付けられているパラメータを使用して「カレンダ・ユーザー」のために働く誰かをサポートしています。しかし、「カレンダ・ユーザーが」自分に代わって仕事をする人を承認しているかどうかを検証するメカニズムはありません。その決定を行うために、「カレンダーユーザー」のためのメカニズムを提供するために、実装に任されています。
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のは、他のユーザーまたはエージェントへのiCalendarオブジェクトを転送から「カレンダ・ユーザー・エージェント」（CUA）を制限するものではありません。
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オブジェクトに「主催」および「出席者」プロパティ内の指定されたカレンダーは、適切な「のmailto：」でなければなりません「VEVENT」の対応する「主催者」または「参加者」の[MAILTO] URI指定または"VTODO"。
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]、[RFC5322]、「送信者」値は、「オーガナイザー」の等しくないかもしれない他の人に「VEVENT」Sまたは「VTODO」Sを転送から「出席者」を排除するものではありません。また、「オーガナイザー」または「参加者」とは、確実に[RFC5322]、「送信者」または「返信先」iMIPのメッセージのヘッダフィールド値によって推測することができません。関連するアドレスは「テキスト/カレンダー」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]「Content-Type」ヘッダフィールドはまた、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：「メソッド」パラメータを欠いている「テキスト/カレンダー」の「コンテンツタイプ」値を持つ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".
The optional "component" MIME parameter defines the iCalendar component type contained within the iCalendar object.
オプションの「成分」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
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メッセージに含まれ、人間が読める形式とMIMEメッセージに含まれるスケジューリングメッセージのタイプを可能にしますスケジューリングメッセージの（すなわち、 "マルチパート/代替" [RFC2046]）。
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.
「マルチパート/代替が」代替の開始時間で、例えば、S 2つの「VEVENTを」わずかに異なる2つのiCalendarオブジェクトを表すために使用されてはならないことに注意してください。
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.
CUASは、「マルチパート/代替場合の処理のために、「テキスト/カレンダー」の部分を選択するために、「Content-Type」ヘッダフィールド、ならびにコンテンツ-Languageヘッダフィールドで指定された言語[RFC3282]の他のMIMEパラメータを使用することができテキスト/カレンダー 『一部" MIMEメッセージが複数含まれます』。
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.
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:
iMIPのメッセージは、引用された、印刷可能な又はBASE64のような転送エンコード（例えば、SMTP [8BITMIME]など）は、8ビットクリーン輸送を介して転送されていない限り、[RFC2045]はで表すことができない任意の文字を含むのiCalendarオブジェクトに使用されなければなりませんUS-ASCII文字セット。例えば：
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
投稿者：user1@example.comへ：user2@example.com件名：電話会議のMime-バージョン：1.0日付：水曜日、2008年5月7日21時30分25秒0400のMessage-ID：<4821E731.5040506@laptop1.example。 COM>のContent-Type：テキスト/カレンダー。方法= REQUEST。文字セット= UTF-8コンテンツ転送 - エンコード：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： - //例/ ExampleCalendarClient // EN METHOD：REQUESTバージョン：2.0 BEGIN：VEVENT主催：のmailto：user1@example.com ATTENDEE; ROLE = CHAIR; PARTSTAT = ACCEPTED：のmailto：user1@example.com ATTENDEE ; RSVP = YES; CUTYPE =個人：のmailto：user2@example.com DTSTAMP：20080507T170000Z DTSTART：20080701T160000Z DTENDは：20080701T163000Z概要：電話があなたの最後の訪問説明について議論する：= 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オブジェクトのファイル名を定義するには「Content-Disposition」ヘッダフィールドを含んでいてもよいです。別の電子メールマルウェアがメッセージの誤解コンテンツにユーザーエージェントをだますことが知られているようしかし、MIMEパートの取り扱いは、その[RFC2045]「のContent-Type」ではなく、「コンテンツディスポジション」で指定した拡張子に基づいていなければなりません「Content-Type」ヘッダフィールドの値に対応しないのContent-Dispositionヘッダーフィールドにファイル拡張子を指定すること。
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 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:
iTIPを実装する場合、アプリケーションが対処しなければならないセキュリティ上の脅威は、[のiTIP]に詳述されています。特に、2つのなりすましの脅威は、[のiTIP]の6.1節で識別されます：「オーガナイザー」をスプーフィングし、「参加者」をスプーフィング。これらの脅威に対処するために、iCalendarオブジェクトの発信者は、受信者が認証される必要があります。認証されると、判定が発信者が要求された操作を実行する権限があるか否かを判断することができます。準拠のアプリケーションが署名と暗号化「テキスト/カレンダー」をサポートしなければならないiCalendarオブジェクトの発信者の認証を容易にするために、S / MIME [RFC5750]、[RFC5751]に基づくメカニズムを使用して体の部分は（セクション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で指定されるように、署名者の電子メールアドレスは、署名者証明書の「サブジェクト代替名」拡張子のrfc822Nameでフィールドで指定しなければならないことに留意されたい。）署名者が必ずしもないことに注意してください電子メールメッセージを転送することができるため、電子メールメッセージを、送信者。
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オブジェクトに「主催」プロパティに署名を関連付けます。署名者は、「出席者」/「ORGANIZER」プロパティと相関させることができない場合には、積極的に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]によって定義されるような操作を実行する権限があるか否かを判定する。条件が満たされない場合は、メッセージを無視してください。
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]に基づくメカニズムによって暗号化されるべき署名しました。 iMIPのは、単一の管理管理ドメイン（ADMD）[RFC5598]、SMTP STARTTLS [SMTP-TLS]内で使用された場合には（一緒にIMAP / POP内のSTARTTLSと[IMAP、POP-TLS]）代わりにカレンダーの機密性を提供するために使用され得ます。
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.
署名されたおよび/または暗号化されたiMIPのメッセージがCUAによって受信され、（上記で詳述したように）正常に確認されると、CUAは、メッセージの送信者が署名を使用して、および/または暗号化されているかどうかを覚えておいてください。符号なしiMIPのメッセージが後で同じ送信者から受信した場合、受信CUAは、可能なman-in-the-middle攻撃についての受信をユーザーに警告する必要があり、ユーザーによって明示的に上書きされない限り、メッセージを無視すべきです。
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のメッセージを受信することが可能です。これは「送られた - で、」パラメータ関連「ORGANIZER」または「出席者」プロパティでを調べることによって決定されます。 [iCALの]と[のiTIP]「カレンダ・ユーザーが」自分に代わって動作するように他の誰かを承認したことを検証するメカニズムを提供しません。このセキュリティ問題に対処するために、実装は、「カレンダ・ユーザー」のために働く誰かからの変更を適用する前に、その決定を行うために、「カレンダーユーザー」のためのメカニズムを提供しなければなりません。これを達成する1つの方法は、「ORGANIZER」または「出席者」の以外のユーザーによって送信されたメッセージを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.
Content-Dispositionヘッダーフィールドの使用に関連したセキュリティ上の考慮事項は、セクション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
投稿者：sman@netscape.example.comへ：stevesil@microsoft.example.com件名：電話会議のMime-バージョン：1.0のContent-Type：テキスト/カレンダー。方法= REQUEST。文字セット= US-ASCIIコンテンツ転送 - エンコード：7ビット
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： - //例/ ExampleCalendarClient // EN METHOD：REQUESTバージョン：2.0 BEGIN：VEVENT主催：のmailto：man@netscape.example.com ATTENDEE; ROLE = CHAIR; PARTSTAT = ACCEPTED：MAILTO：男性の@ネットスケープを。 example.com ATTENDEE; RSVP = YES：のmailto：stevesil@microsoft.example.com DTSTAMP：19970611T190000Z DTSTART：19970701T210000Z DTEND：19970701T230000Z概要：電話会議の説明：添付文書を確認してください。 UID：calsvr.example.com-873970198738777は、ATTACHます。ftp：//ftp.bar.example.com/pub/docs/foo.docステータス：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"
投稿者：foo1@example.comへ：foo2@example.com件名：電話会議のMime-バージョン：1.0のContent-Type：マルチパート/代替;境界= "01BD3665.3AF0D360"
--01BD3665.3AF0D360 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
--01BD3665.3AF0D360のContent-Type：text / plainの。文字セット= US-ASCIIのコンテンツ転送 - エンコード：7ビット
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
：1997年7月1日10時00 AM PDT - 7/1/97 10:30 PDT：主催：foo1@example.com要約：電話会議
--01BD3665.3AF0D360 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII Content-Transfer-Encoding: 7bit
--01BD3665.3AF0D360のContent-Type：テキスト/カレンダー。方法= REQUEST。文字セット= US-ASCIIコンテンツ転送 - エンコード：7ビット
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： - //例/ ExampleCalendarClient // EN METHOD：REQUESTバージョン：2.0 BEGIN：VEVENT主催：の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概要：電話会議UID：calsvr.example.com-8739701987387771 SEQUENCE：0 STATUS：CONFIRMED END：VEVENTのEND：VCALENDAR
--01BD3665.3AF0D360
--01bdatttkh 3. F 0 0 Dattと
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"
投稿者：foo1@example.comへ：foo2@example.com件名：電話会議のMime-バージョン：1.0のContent-Type：マルチパート/関連;境界は= "境界例-1"
--boundary-example-1
--boundary-例1
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="event.ics"
コンテンツタイプ：テキスト/カレンダー。方法= REQUEST。文字セット= US-ASCIIコンテンツ転送 - エンコード：7ビットのContent-処分：添付ファイル;ファイル名= "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： - //例/ ExampleCalendarClient // EN METHOD：REQUESTバージョン：2.0 BEGIN：VEVENT主催：の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概要：電話会議UID：calsvr.example.com-8739701987387771アタッチ：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-例-1のContent-Type：アプリケーション/ mswordは、名前=「FieldReport.doc」コンテンツ転送エンコード：base64でコンテンツディスポジション：インライン;ファイル名= "FieldReport.docの" Content-ID：<123456789@example.com>
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD///////////////////////////////// ...
0n8hri4krgkrshguaaaaaaaaaaaaaaaaaaaaaoffgadaf7 / CQAGAAAAAAAAAAABAAAARAAAAAAA AAAAEAAAQAAAAAEAAAD + //// Aaaaaauaaad ///////////////////////////////// ...
--boundary-example-1--
--boundary-例-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"
投稿者：foo1@example.comへ：foo2@example.com件名：夏の会社休日のMime-バージョン：1.0のContent-Type：テキスト/カレンダー。方法= PUBLISH。文字セット= US-ASCIIコンテンツ転送 - エンコード：7ビットのContent-処分：添付ファイル;ファイル名= "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： - //例/ ExampleCalendarClient // EN METHOD：VERSIONを公開：2.0は、BEGIN：VEVENT主催：のmailto：foo1@example.com DTSTAMP：19970611T150000Z DTSTART：19970701T150000Z DTEND：19970701T230000Z概要：会社ピクニック説明：食品と飲み物UIDを提供する：calsvr.example.com-873970198738777から1 SEQUENCE：0 STATUS：CONFIRMED END：VEVENTがBEGIN：VEVENT主催：のmailto：foo1@example.com DTSTAMP：19970611T190000Z DTSTART：19970715T150000Z DTEND：19970715T230000Z概要：会社ボウリングトーナメントDESCRIPTION ：calsvr.example.com-873970198738777から2 SEQUENCE：0 STATUS：CONFIRMED END：VEVENT END：VCALENDAR私たちは、10のレーン予約UIDを持っています
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"
投稿者：foo1@example.comへ：foo2@example.com件名：電話会議のMime-バージョン：1.0のContent-Type：multipart / mixedの。境界= " - 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"
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： - //例/ ExampleCalendarClient // EN METHOD：REQUESTバージョン：2.0 BEGIN：VEVENT主催：のmailto：foo1@example.com ATTENDEE; ROLE = CHAIR; PARTSTAT = ACCEPTED：のmailto：foo1@example.com ATTENDEE ; RSVP = YES; CUTYPE =個人：のmailto：foo2@example.com DTSTAMP：19970611T190000Z DTSTART：19970701T210000Z DTEND：19970701T230000Z概要：電話会議の説明：前回の会議の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"
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： - //例/ ExampleCalendarClient // EN METHOD：REQUESTバージョン：2.0 BEGIN：VTODO DUE：19970701T160000Z主催：のmailto：foo1@example.com ATTENDEE; ROLE = CHAIR; PARTSTAT = ACCEPTED：のmailto：foo1の@例.COM ATTENDEE; RSVP = YES：のmailto：foo2@example.com概要：電話会議DESCRIPTION：会社のピクニックUIDの新しい場所を議論：calsvr.example.com-TD-8739701987387773 SEQUENCE：0 STATUS：NEEDS-ACTION END： VEVENT END：VCALENDAR
----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.
この例では、3つの個体間のグループ会議を含むメッセージのフォーマットを示します。 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"
投稿者：foo1@example.com MIME-バージョン：1.0：foo2は@ example.com、foo3 @ example.com件名：REQUEST - 電話会議のContent-Type：マルチパート/関連;境界= " - FEE3790DC7E35189CA67CE2C"
----FEE3790DC7E35189CA67CE2C
Content-Type: multipart/alternative;
boundary="--00FEE3790DC7E35189CA67CE2C00"
----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
とき：1997年7月1日10時PM PDT - 7/1/97午後10時30分PDT：主催：foo1@example.com概要：のは、添付文書を議論しましょう
----00FEE3790DC7E35189CA67CE2C00
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII; Component=vevent Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="event.ics"
コンテンツタイプ：テキスト/カレンダー。方法= REQUEST。文字セット= US-ASCII;コンポーネント= VEVENTコンテンツ転送 - エンコード：7ビットのコンテンツディスポジション：添付ファイル;ファイル名= "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： - //例/ ExampleCalendarClient // EN METHOD：REQUESTバージョン：2.0 BEGIN：VEVENT主催：foo1@example.com ATTENDEE; ROLE = CHAIR; PARTSTAT = ACCEPTED：foo1@example.com ATTENDEE; RSVP = YES ; CUTYPE =個人：のmailto：foo2@example.com ATTENDEE; RSVP = YES; CUTYPEは=個人：のmailto：foo3@example.com DTSTAMP：19970611T190000Z DTSTART：19970621T170000Z DTEND：199706211T173000Z概要：さんは、添付文書のUIDを議論してみましょう：calsvr.example .COM-873970198738777-8aa ATTACH：CID：calsvr.example.com-12345aaaのSEQUENCE：0 STATUS：CONFIRMED END：VEVENT END：VCALENDAR
----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>
R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94Xq AG4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvd riIH5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5i ZnJY6J ...
R0lGODdhTAQZAJEAAFVVVd3d3e4AAP /// ywAAAAATAQZAAAC / 5yPOSLhD6OctNqLs94Xq AG4kiW5omm6sq27gvH8kzX9o1y + S73 / g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvd riIH5LL5jE6rxc3G + v2cguf0uv2Oz + v38L7 / DxgoOKjURnjIIbe3yNjo + AgZWYVIWWl5i ZnJY6J ...
----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明細書は、「説明」などのプロパティのデータ型、「ATTACH」、「接触」、および他のURIを頻繁に利用します。 URIの2つの形態が、メッセージID（MID）およびContent-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.、エド。、 "インターネットカレンダーとスケジュールのコアオブジェクト仕様（iCalendar形式）"、RFC 5545、2009年9月。
[iTIP] Daboo, C., Ed., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, December 2009.
[ITIP] Daboo、A.編、 "てICalendarトランスポートに依存しない相互運用性プロトコル（のiTIP）"、RFC 5546、2009年12月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[MAILTO] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.
[mailtoの] Duerst、M、瑪斯ケア、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]ガルビン、J.、マーフィー、S.、クロッカー、S.、およびN.フリード、 "セキュリティマルチパート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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]レビンソン、E.、 "コンテンツIDとMessage-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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ホフマン、P.、RFC 3207、2002年2月 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"。
[IMAP-POP-TLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[IMAP-POP-TLS]ニューマン、C.、 "IMAP、POP3およびACAPとTLSを使用する"、RFC 2595、1999年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.ターナー、 "（S / MIME）バージョン3.2証明書の取り扱い/セキュア多目的インターネットメール拡張"、RFC 5750、2010年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.ターナー、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.2メッセージ仕様"、RFC 5751、2010年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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年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.、フリード、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、 "8ビット・MIMEtransportためのSMTPサービス拡張"、RFC 1652、1994年7月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]クロッカー、D.、 "インターネットメールのアーキテクチャ"、RFC 5598、2009年7月。
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[RFC3282] Alvestrand、H.、 "コンテンツ言語ヘッダ"、RFC 3282、2002年5月。
Appendix A. Changes since
付録A.からの変更点
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.
カレンダーは完全にUS-ASCIIで表現することができない限り、文字セット= UTF-8が、必要とされていることを明らかにしました。
Clarified that 7-bit content transfer encodings should be used unless the calendar object is known to be transferred over 8-bit clean transport.
カレンダオブジェクトが8ビットクリーン輸送を介して転送されることが知られていない限り、7ビットのコンテンツ転送エンコーディングが使用されるべきであることを明らかにしました。
Clarified that file extension specified in the Content-Disposition header field is not to be used to override the "Content-Type" MIME type.
Content-Dispositionヘッダーフィールドで指定されたファイルの拡張子が「Content-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.
「Content-Type」ヘッダフィールドの「方法」MIMEパラメータの明確化処理。
Clarified that in an iMIP message an ORGANIZER/ATTENDEE property contains a mailto: URI.
URI：iMIPのメッセージにORGANIZER / ATTENDEEプロパティはのmailtoが含まれていることを明らかにしました。
Fixed examples with ATTENDEE property to use "CUTYPE=" instead of "TYPE=".
代わりに「TYPE =」の「CUTYPE =」を使用するにはATTENDEEプロパティを修正例。
Clarified that message integrity/confidentiality should be achieved using S/MIME.
メッセージの整合性/機密性は、S / MIMEを使用して達成されるべきであることを明らかにしました。
Provided additional examples.
追加の例を提供します。
Improved the Security Considerations section.
Security Considerations部を改善しました。
Made multiple editorial changes to different sections of the document.
文書の異なるセクションに複数の編集上の変更を行いました。
Appendix B. Acknowledgements
付録B.謝辞
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:
このドキュメントの編集者はフランク・ドーソン、スティーブ・マンスール、とスティーブSilverberg、RFC 2447の原作者だけでなく、起草に参加した以下の個人、レビュー、およびこのメモの議論に感謝したいです。
Reinhold Kainhofer, Cyrus Daboo, Bernard Desruisseaux, Eliot Lear, and Peter Saint-Andre.
ラインホルト・Kainhofer、サイラスDaboo、バーナードDesruisseaux、エリオット・リア、そしてピーターサンタンドレ。
Author's Address
著者のアドレス
Alexey Melnikov (editor) Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフ（エディタ）ISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com