[要約] RFC 2447は、iCalendarメッセージベースの相互運用性プロトコル（iMIP）に関する規格です。このRFCの目的は、異なるシステム間でiCalendarデータを交換するための標準化と手順の提供です。
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.
Copyright（C）The Internet Society（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）からインターネット電子メールベースのトランスポートへのバインディングを指定しています。 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 Webサイト（http://www.imc.org）、IETF Webサイト（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
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のインターネット電子メールバインディングを指定しています。
[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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、 [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]で定義されたプロパティパラメータは、小文字のテキストの引用符付き文字列で参照され、その後に「パラメータ」という単語が続きます。たとえば、「値」パラメータは、プロパティ値のデフォルトのデータ型を上書きするために使用される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]の「Reply-To」ヘッダーには、通常、イベントの発信者または応答者の電子メールアドレスが含まれています。ただし、メールユーザーエージェント（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.
このセクションでは、認証、承認、機密性など、セキュリティのいくつかの側面について説明します。認証と機密性は、MIMEのセキュリティマルチパートを指定する[RFC-1847]を使用して実現できます。このフレームワークは、マルチパートの新しいコンテンツタイプとサブタイプを定義します：署名および暗号化。それぞれに2つの本体部分が含まれています。1つは保護されたデータ用で、もう1つは保護を解除するために必要な制御情報用です。
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]メッセージでは、「オーガナイザ」のみが、それらが整理するカレンダーエントリを変更またはキャンセルすることができます。つまり、a @ example.comが主催した会議をspoof@xyz.comで変更またはキャンセルすることはできません。さらに、回答者だけが「主催者」に自分のステータスを示す権限を持っています。つまり、「主催者」は、b @ example.comへの会議招集を拒否するspoof@xyz.comからの[iTIP]メッセージを無視する必要があります。
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オブジェクトの作成者の信頼性を検証する必要があります（SHOULD）。これを行う方法については、このドキュメントの後半で説明します。
[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のメッセージフローは、「ATTENDEE」および「ORGANIZER」プロパティに関連付けられた「sent-by」パラメータを使用して、「カレンダーユーザー」に代わって作業するユーザーをサポートします。ただし、「カレンダーユーザー」が誰かに代わって作業することを承認したかどうかを確認するメカニズムはありません。 "Calendar Users"がその決定を行うためのメカニズムを提供するのは実装に任されています。
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] "multipart / signed"の実装を使用して実行できます。認証は、署名されたメッセージに対してのみ可能です。署名されていないメッセージの認証は信頼できない場合があります。
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]準拠の暗号化を利用する必要があります。このプロトコルは、「Calendar User Agent」（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」の対応する「Organizer」または「Attendee」の完全修飾[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]は[参加者]が[VEVENTS]または[VTODOS]を他の人に転送することを妨げないため、[RFC-822] [送信者]の値は[主催者]の値と異なる場合があります。さらに、「Organizer」または「Attendee」は、iMIPメッセージの[RFC-822]「Sender」または「Reply-to」の値から確実に推測することはできません。 「text / calendar」MIMEボディパーツを開き、「ATTENDEE」プロパティと「ORGANIZER」プロパティを調べて、関連するアドレスを確認する必要があります。
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 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.
このドキュメントに準拠するコンテンツ情報を含むMIME本文部分は、[RFC-2045]の「Content-Type」値が「text / calendar」である必要があります。 [RFC-2045] "Content-Type"ヘッダーフィールドには、typeパラメーター "method"も含める必要があります。この値は、iCalendarオブジェクト内の「METHOD」カレンダープロパティの値と同じである必要があります。つまり、メソッド値が異なる複数のiCalendarオブジェクトを含むMIMEメッセージは、「multipart / mixed」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.
US-ASCII文字セットの一部ではない文字がiCalendarオブジェクトに含まれている場合は、「charset」パラメーターが存在する必要があります。 [RFC-2046]は、適切な「charset」値の選択について説明しています。
The optional "component" parameter defines the iCalendar component type contained within the iCalendar object.
オプションの「コンポーネント」パラメーターは、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").
「text / calendar」コンテンツタイプを使用すると、スケジューリングメッセージタイプを他のコンテンツ情報（つまり、「multipart / mixed」）とともに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.
「text / calendar」コンテンツタイプをサポートしないMIMEユーザーエージェント（UA）がスケジュールメッセージの情報を理解できるようにするには、スケジュールメッセージを人間が読める形式の情報とともに送信する必要があります（SHOULD）。
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オブジェクトに使用する必要があります（SHOULD）。
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]の「Content-Type」に基づいている必要があります。ただし、これがすべての環境で機能することは保証されていません。一部の環境では、ファイルタイプまたは拡張子に基づいてMIME添付ファイルを処理します。これらの環境で正しく動作するように、実装では、ファイル名を定義するための「Content-Disposition」プロパティを含めることができます。
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]で詳しく説明しています。 2つのなりすましの脅威が確認されています。「オーガナイザー」のなりすましと「参加者」のなりすましです。これらの脅威に対処するには、iCalendarオブジェクトの発信者を受信者が認証する必要があります。認証されると、要求された操作の実行を発信者に許可するかどうかを決定できます。準拠アプリケーションは、iCalendarオブジェクトの発信者の認証を容易にするために、MIMEのセキュリティマルチパート[RFC-1847]に基づくメカニズムを使用したテキスト/カレンダーの添付ファイルの署名と暗号化をサポートする必要があります。実装は、ユーザーが署名と暗号化を無効にする手段を提供する場合があります。手順は次のとおりです。
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. [ATTENDEE]が[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].
機密性のセキュリティ脅威に対処するために、MIMEのセキュリティマルチパート[RFC-1847]に基づくメカニズムによって、署名されたiMIPメッセージを暗号化する必要があります（SHOULD）。
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メッセージを受信する可能性があります。これは、関連する「ORGANIZER」または「ATTENDEE」プロパティの「sent-by」パラメータを調べることによって決定されます。 [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
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"
--01BD3665.3AF0D360
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 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
--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
--01BD3665.3AF0D360
--01 Bdatat 3 F-0 Let 0
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
--boundary-example-1
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
--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/////////////////////////////////
--boundary-example-1--
--boundary-example-1--
Multiple iCalendar components of the same type can be included in the iCalendar object when the METHOD is the same for each component.
各コンポーネントのMETHODが同じ場合、同じタイプの複数の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"
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"
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"
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"
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
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"
----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
----00FEE3790DC7E35189CA67CE2C00
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
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/5yPOSLhD6OctNqLs94XqAG 4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvdriIH 5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5iZnJY6J.
R0lGODdhTAQZAJEAAFVVVd3d3e4AAP /// ywAAAAATAQZAAAC / 5yPOSLhD6OctNqLs94XqAG 4kiW5omm6sq27gvH8kzX9o1y + S73 / g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvdriIH 5LL5jE6rxc3G + v2cguf0uv2Oz + v38L7 / DxgoOKjURnjIIbe3yNjo + AgZWYVIWWl5iZnJY6J。
----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の2つの形式は、メッセージID（MID）とコンテンツID（CID）です。これらは[RFC-2111]で定義されています。 [RFC-2111]では、他のMIMEエンティティまたはストアでメッセージまたはMIMEボディパーツを参照できますが、iMIP実装には、参照されるすべてのメッセージとボディパーツを1つのMIMEエンティティに含めることを強くお勧めします。簡単に言えば、iCalendarオブジェクトに他のメッセージまたはボディパーツへのCIDまたはMID参照が含まれている場合、実装はこれらのメッセージまたはボディパーツ、あるいはその両方がiCalendarオブジェクトとともに送信されることを確認する必要があります。そうでない場合、受信側の「CU」がこれらのオブジェクトを表示するためのアクセス権または許可を持つことは保証されません。
6 Bibliography
6参考文献
[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 2445、1998年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. and R. Hopson、 "iCalendar Transport-Independent Interoperability Protocol（iTIP）：Scheduling Events、Busy Time、To-dos and Journal Entries"、RFC 2446、 1998年11月。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822] Crocker、D。、「Standard for the Format for ARPA Internet Text Messages」、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のセキュリティマルチパート：Multipart / SignedおよびMultipart / Encrypted」、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、「Multipurpose Internet Mail Extensions（MIME）-Part One：Format of Internet Message Bodies」、RFC 2045、1996年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、「Multipurpose Internet Mail Extensions（MIME）-Part Two：Media Types」、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。、「Multipurpose Internet Mail Extensions（MIME）-Part Three：Message Header Extensions for Non-ASCII Text」、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、「Multipurpose Internet Mail Extensions（MIME）-Part Four：Registration Procedures」、RFC 2048、1997年1月。
[RFC-2111] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2111, March 1997.
[RFC-2111] Levinson、E。、「Content-ID and Message-ID Uniform Resource Locators」、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: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 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:
BEGIN：VCARD VERSION：3.0 N：Silverberg; Steve FN：Steve Silverberg ORG：Microsoft Corporation ADR; TYPE = WORK、POSTAL、PARCEL：;; 1つの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 iCalendarオブジェクトは、インターネット技術特別調査委員会の予定表作成およびスケジューリング作業グループの作業の結果です。そのワーキンググループの議長は次のとおりです。
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
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。