RFC2447 日本語訳
2447 iCalendar Message-Based Interoperability Protocol (iMIP). F.Dawson, S. Mansour, S. Silverberg. November 1998. (Format: TXT=33480 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Dawson
Request for Comments: 2447 Lotus
Category: Standards Track S. Mansour
Netscape
S. Silverberg
Microsoft
November 1998
コメントを求めるワーキンググループF.ドーソン要求をネットワークでつないでください: 2447年のロータスカテゴリ: 標準化過程S.マンスールNetscape S.シルバーバーグマイクロソフト1998年11月
iCalendar Message-Based Interoperability Protocol
(iMIP)
iCalendarのメッセージベースの相互運用性プロトコル(iMIP)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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 Transportから独立しているInteroperabilityプロトコル(iTIP)からメールベースのインターネット輸送までの結合を指定します。 iCalendar Object Modelによって定義されたエントリーをCalendaringして、[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)CalendaringとScheduling(CALSCH)ワーキンググループの中で議論に基づいています。 http://www.imc.org ( http://www.ietf.org/html.charters/calsch-charter.html のIETFウェブサイト)のIMCウェブサイトでIETF CALSCHワーキンググループ活動に関する詳しい情報を見つけることができます。 このドキュメントの中のどうこれらの様々なドキュメントにアクセスするかに関する詳細の参照を参照してください。
Dawson, et. al. Standards Track [Page 1] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[1ページ]。
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つの序論…2 1.1 メモについて話します…2 1.2 形式コンベンション…3 1.3用語…4 2はメッセージ・フォーマット結合をまねます…4 2.1 MIMEメディアはタイプされます…4 2.2セキュリティ…4 2.2 .1承認…4 2.2 .2認証…5 2.2 .3秘密性…5 2.3 [RFC-822]アドレス…5 2.4content type…5 2.5 満足している転送コード化…6 2.6 満足している気質…6 3のセキュリティ問題…7 4の例…8 4.1 ただ一つのコンポーネント、特性を取り付けてください…8 4.2 低い信義クライアントに複合代替手段を使用します…8 4.3 ただ一つのコンポーネント、特性とインライン付属を取り付けてください。9 4.4の倍数同様のコンポーネント…10 4.5 複数のMixedコンポーネント…4.6がコンポーネントを詳しく述べた11、特性を取り付けてください…13 5 お勧めの習慣…14 5.1 内容とメッセージイドの使用…14 6図書目録…15 7人の作者のアドレス…16 8 完全な著作権宣言文…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 Transportから独立しているInteroperabilityプロトコル(iTIP)を特定の必要情報が伝える輸送に提供します。
1.1 Related Memos
1.1 関連メモ
Implementers will need to be familiar with several other memos that, along with this memo, form a framework for Internet calendaring and scheduling standards.
Implementersは、このメモと共に規格のcalendaringして、計画をするインターネットにフレームワークを形成する他のいくつかのメモによく知られる必要があるでしょう。
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]--オブジェクト、データ型、特性、および特性のパラメタのコア仕様を指定します。
Dawson, et. al. Standards Track [Page 2] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[2ページ]。
[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.
このメモは、これらの他のメモから概念か定義の仕様を繰り返すのを試みません。 可能であるところでは、これらの概念か定義の仕様に備えるメモを参照します。
1.2 Formatting Conventions
1.2 形式コンベンション
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]で定義されたcalendaringとスケジューリング・モデルか、コアオブジェクトか相互運用性プロトコルの原理を示すために、いくつかの形式コンベンションが使用されました。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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].
役割のCalendaringして、計画をするのは大文字における、それぞれの単語の最初のキャラクタと共にテキストに関する引用文字列で言及されます。 例えば、「オーガナイザー」は[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]によって定義された特性が大文字で書かれることで示される、「特性」という言葉があとに続いたテキストに関する引用文字列。 例えば、「出席者」の特性はカレンダーユーザのカレンダーアドレスを伝えるのに使用される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特性のパラメタを示します。
Dawson, et. al. Standards Track [Page 3] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[3ページ]。
1.3 Terminology
1.3 用語
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]と[RFC2045]で定義されます。 このメモで使用されるcalendaringとスケジューリング用語は[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]はヘッダーに「答えます」。イベントの創始者か応答者のEメールアドレスを通常含んでいます。 しかしながら、メール・ユーザー・エージェント(MUA)がiMIP意味論を実施する必要はないとき、これを保証できません。
2.1 MIME Media Type
2.1 MIMEメディアタイプ
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実体は「テキスト/カレンダー」content typeとして参照をつけられるでしょう。 このcontent typeがMIME電子メール輸送で輸送されると思われます。
2.2 Security
2.2 セキュリティ
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.
このセクションはAuthentication、Authorization、およびConfidentialityを含むセキュリティのいくつかの局面を扱います。 MIMEにSecurity Multipartsを指定する[RFC-1847]を使用することで認証と秘密性を達成できます。 このフレームワークは複合の新しいcontent typeと血液型亜型を定義します: 署名されて、暗号化されます。 それぞれが2つの身体の部分を含んでいます: 保護されたデータのためのものと保護を取り除くのに必要な制御情報のための別。
2.2.1 Authorization
2.2.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]メッセージを無視しなければなりません。
Dawson, et. al. Standards Track [Page 4] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[4ページ]。
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 SHOULDの実装は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.
iTIPでの[RFC-1847]メッセージ流動は、「送って」「出席者」と「オーガナイザー」の特性に関連しているパラメタの使用による「カレンダーユーザ」を代表して働きながら、だれかをサポートします。 しかしながら、「カレンダーユーザ」が、だれかがそれらの利益に取り組むのを認可したかどうか確かめるために、メカニズムは全くありません。 「カレンダーユーザ」がその決定をするようにそれがメカニズムを提供するのが実装に残されます。
2.2.2 Authentication
2.2.2 認証
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]「複合/は署名した」実装を使用することで認証を実行できます。 認証は署名されたメッセージだけで可能です。 未署名のメッセージを認証するのは信頼できないかもしれません。
2.2.3 Confidentiality
2.2.3 秘密性
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オブジェクトから他のユーザかエージェントに制限しません。
2.3 [RFC-822] Addresses
2.3 [RFC-822]アドレス
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オブジェクトの「出席者」所有地の中で指定されたカレンダーアドレスは"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]が推進「VEVENTS」か「VTODOS」から他のものまで「出席者」を排除しないので、[RFC-822]「送付者」値は「オーガナイザー」のものと等しくないかもしれません。 さらに、「オーガナイザー」か「出席者」が、[RFC-822]「送付者」が確かに推論できませんし、iMIPメッセージの値に「答えることができません」。 「テキスト/カレンダー」MIME身体の部分を開いて、「出席者」と「オーガナイザー」の特性を調べることによって、関連アドレスを確かめなければなりません。
2.4 Content Type
2.4 content type
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の中で「メソッド」カレンダー属性の価値と同じであるに違いありません。
Dawson, et. al. Standards Track [Page 5] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[5ページ]。
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実体でさらに異なったメソッド値がある複数のiCalendarオブジェクトを含む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オブジェクトが米国-ASCII文字の組の一部でないキャラクタを含んでいるなら、"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
コンテントタイプ: テキスト/カレンダー。 メソッドは要求と等しいです。 charset=UTF-8。 コンポーネント=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").
「テキスト/カレンダー」content typeは、スケジューリングメッセージタイプが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.
メッセージSHOULDの計画をして、「テキスト/カレンダー」content typeをサポートしないMIMEユーザエージェント(UA)に解釈されるべきスケジューリングメッセージの情報を可能にするには、情報の代替の、そして、人間読み込み可能なフォームと共に送ってください。
2.5 Content-Transfer-Encoding
2.5 満足している転送コード化
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であることに注意してください。 SHOULDをコード化しながら、Aを移します。iCalendarオブジェクトには、米国-ASCII文字の組の一部でないどんなキャラクタも含んで、使用されてください。
2.6 Content-Disposition
2.6 満足している気質
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付属を扱います。 これらの環境で正しく作動するために、実装はファイル名を定義するために「内容気質」の特性を含みたがっているかもしれません。
Dawson, et. al. Standards Track [Page 6] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[6ページ]。
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オブジェクトの創始者を認証しなければなりません。 一度認証されています、創始者が要求された操作を実行するのに権限を与えられるかどうかに関して決断をすることができます。 対応するアプリケーションは署名をサポートしなければなりません、そして、MIME[RFC-1847]が認証を容易にするようにSecurity Multipartsに基づくメカニズムを使用することでテキスト/カレンダー付属を暗号化して、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オブジェクトの「出席者」の特性に署名者を関連させてください。 署名者が「出席者」の特性に関連できないなら、メッセージを無視してください。
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メッセージSHOULDであると署名される秘密性軍事的脅威を扱うには、Security Multipartsに基づくメカニズムで、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]は、「カレンダーユーザ」が、他の誰かがそれらの利益に取り組むのを認可したことを確かめるためにメカニズムを全く提供しません。 この安全保障問題を扱うなら、「カレンダーユーザ」が「カレンダーユーザ」を代表して働きながらだれかからの変化を適用する前にその決定をするように、実装はメカニズムを提供しなければなりません。
Dawson, et. al. Standards Track [Page 7] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[7ページ]。
4 Examples
4つの例
4.1 Single Component With An ATTACH Property
4.1のただ一つのコンポーネント、特性を取り付けてください。
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: コンファレンスパントマイムバージョンに電話をしてください: 1.0 コンテントタイプ: テキスト/カレンダー。 メソッドは要求と等しいです。 charsetは米国のASCIIの満足している転送コード化と等しいです: 7ビット
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.0BEGIN: VEVENT ORGANIZER:mailto: sman@netscape.com ATTENDEE; ROLE=議長; ATTSTAT=ACCEPTED:mailto: sman@netscape.com ATTENDEE; はい:mailto: stevesil@microsoft.com RSVP=DTSTAMP: 19970611T190000Z DTSTART:19970701T210000Z DTEND:19970701T230000Z SUMMARY: コンファレンス記述に電話をしてください: 添付書類を再検討してください。 UID: calsvr.example.com-873970198738777は: ftp://ftp.bar.com/pub/docs/foo.doc 状態を付けます: 終わり: VEVENTエンド: VCALENDARを確認します。
4.2 Using Multipart Alternative for Low Fidelity Clients
4.2 低い信義クライアントに複合代替手段を使用すること。
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: コンファレンスパントマイムバージョンに電話をしてください: 1.0コンテントタイプ: 複合/代替手段; 境界="01BD3665.3AF0D360"
--01BD3665.3AF0D360 Content-Type: text/plain;charset=us-ascii
--01BD3665.3AF0D360コンテントタイプ: テキスト/平野; charsetするのが私たちと等しい、-、ASCII
Dawson, et. al. Standards Track [Page 8] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[8ページ]。
Content-Transfer-Encoding: 7bit
満足している転送コード化: 7ビット
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
これはTEXT/CALENDAR MIME Object Whenの代替の表現です: 太平洋夏時間午前10時0分から7/1/97の太平洋夏時間午前10時30分までの7/1/1997、どこ: オーガナイザー: foo1@example.com 概要: コンファレンスに電話をしてください。
--01BD3665.3AF0D360 Content-Type:text/calendar; method=REQUEST; charset=US-ASCII Content-Transfer-Encoding: 7bit
--01BD3665.3AF0D360コンテントタイプ: テキスト/カレンダー。 メソッドは要求と等しいです。 charsetは米国のASCIIの満足している転送コード化と等しいです: 7ビット
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
始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//ENメソッド: バージョンを要求してください: 2.0は始まります: VEVENTオーガナイザー:mailto: foo1@example.com 出席者; ROLE=議長; ATTSTAT=は受け入れました: mailto: foo1@example.com 出席者; RSVP=はい;は=個人:mailto: foo2@example.com DTSTAMPをタイプします: 19970611T190000Z DTSTART:19970701T170000Z DTEND:19970701T173000Z概要: コンファレンスUID: calsvr.example.com-8739701987387771系列: 0状態: 確認された終わり: VEVENTエンド: VCALENDARに電話をしてください。
--01BD3665.3AF0D360
--01BD3665.3AF0D360
4.3 Single Component With An ATTACH Property and Inline Attachment
4.3のただ一つのコンポーネント、特性とインライン付属を取り付けてください。
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オブジェクトを含むメッセージがどう添付書類に参照をつけるかを示しています。 Content-イド(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: コンファレンスパントマイムバージョンに電話をしてください: 1.0コンテントタイプ: 複合か関連する。 境界の=「境界例の1インチ」。 =テキスト/カレンダーをタイプしてください。
--boundary-example-1
--境界例1
Dawson, et. al. Standards Track [Page 9] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[9ページ]。
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="event.vcs"
コンテントタイプ: テキスト/カレンダー。 メソッドは要求と等しいです。 charsetは米国のASCIIの満足している転送コード化と等しいです: 7は満足している気質に噛み付きました: 付属。 ファイル名="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
始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//ENメソッド: バージョンを要求してください: 2.0は始まります: VEVENTオーガナイザー:mailto: foo1@example.com 出席者; ROLE=議長; ATTSTAT=は受け入れました: mailto: foo1@example.com 出席者; RSVP=はい;は=個人:mailto: foo2@example.com DTSTAMP: UID: : 電話コンファレンスcalsvr.example.com-8739701987387771が添付する19970611T190000Z DTSTART:19970701T180000Z DTEND:19970701T183000Z概要: Cid: 123456789@example.com 系列: 0状態: 確認された終わり: VEVENTエンド: 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>
--境界例1のコンテントタイプ: アプリケーション/msword。 ="FieldReport.doc"満足している転送コード化を命名してください: base64 Content-気質: インライン。 ファイル名は"FieldReport.doc"コンテントIDと等しいです: <123456789@example.com>。
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
--boundary-example-1--
--境界例1--
4.4 Multiple Similar Components
4.4 複数の同様のコンポーネント
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"
From: foo1@example.com To: foo2@example.com Subject: 夏の会社愛の休日パントマイムバージョン: 1.0 コンテントタイプ: テキスト/カレンダー。 メソッド=は発行します。 charsetは米国のASCIIの満足している転送コード化と等しいです: 7は満足している気質に噛み付きました: 付属。 ファイル名="event.vcs"
Dawson, et. al. Standards Track [Page 10] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[10ページ]。
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:会社Picnic記述: UIDを飲食物に提供するでしょう: CALSVR.EXAMPLE; COM-873970198738777-1 SEQUENCE: 0STATUS: CONFIRMED END:VEVENT BEGIN:VEVENT ORGANIZER:MAILTO: FOO1@EXAMPLE.COM DTSTAMP:19970611T190000Z DTSTART:19970715T150000Z DTEND:19970715T230000Z SUMMARY:会社Bowling Tournament記述: 私たちは10の車線予約されたUID:CALSVR.EXAMPLE.COM-873970198738777-2 SEQUENCE:0STATUS: CONFIRMED END:VEVENT END:VCALENDARを持っています。
4.5 Multiple Mixed Components
4.5 複数のMixedコンポーネント
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: コンファレンスパントマイムバージョンに電話をしてください: 「1.0に、コンテントタイプ: 複合/は混入しました; 境界=」--、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コンテントタイプ: テキスト/カレンダー。 メソッドは要求と等しいです。 charsetは米国のASCIIの満足している転送コード化と等しいです: 7は満足している気質に噛み付きました: 付属。 ファイル名="event1.vcs"
Dawson, et. al. Standards Track [Page 11] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[11ページ]。
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.0BEGIN: VEVENT ORGANIZER:mailto: foo1@example.com ATTENDEE; ROLE=議長; ATTSTAT=ACCEPTED:mailto: foo1@example.com ATTENDEE; RSVP=はい; TYPE=INDIVIDUAL:mailto: foo2@example.com DTSTAMP:19970611T190000Z DTSTART:19970701T210000Z DTEND:19970701T230000Z SUMMARY:電話コンファレンス記述: 何がUID:calsvr.example.com-8739701987387772 SEQUENCE:0STATUS: 前回のミーティング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コンテントタイプ: テキスト/カレンダー。 メソッドは要求と等しいです。 charsetは米国のASCIIの満足している転送コード化と等しいです: 7は満足している気質に噛み付きました: 付属。 ファイル名="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.0BEGIN:VTODO DUE:19970701T090000-0700 ORGANIZER:mailto: foo1@example.com ATTENDEE; ROLE=議長; ATTSTAT=ACCEPTED:mailto: foo1@example.com ATTENDEE; RSVPははい:mailto: foo2@example.com SUMMARYと等しいです: コンファレンス記述に電話をしてください: UID:calsvr.example.com-td-8739701987387773 SEQUENCE:0STATUS: 会社のピクニックNEEDS ACTION END:VEVENT END:VCALENDARのために新しい位置について議論してください。
----FEE3790DC7E35189CA67CE2C
----FEE3790DC7E35189CA67CE2C
Dawson, et. al. Standards Track [Page 12] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[12ページ]。
4.6 Detailed Components With An ATTACH Property
4.6がコンポーネントについて詳述した、特性を取り付けてください。
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"
From: foo1@example.com MIMEバージョン: 1.0 To: foo2@example.com 、foo3@example.com Subject: 「要求--複合の、または、関連する電話コンファレンスコンテントタイプ; 境界=」--、FEE3790DC7E35189CA67CE2C、」
----FEE3790DC7E35189CA67CE2C
Content-Type: multipart/alternative;
boundary="--00FEE3790DC7E35189CA67CE2C00"
----FEE3790DC7E35189CA67CE2Cコンテントタイプ: 複合/代替手段。 「境界=」--00FEE3790DC7E35189CA67CE2C00"
----00FEE3790DC7E35189CA67CE2C00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
----00FEE3790DC7E35189CA67CE2C00コンテントタイプ: テキスト/平野。 charsetが私たちと等しい、-、ASCII Content転送コード化: 7ビット
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
いつ: 7/1/1997の7/1/97の太平洋夏時間午後10時0分の太平洋夏時間午後10時30分、どこ: オーガナイザー: foo1@example.com 概要: 添付書類について議論しましょう。
----00FEE3790DC7E35189CA67CE2C00
----00FEE3790DC7E35189CA67CE2C00
Content-Type:text/calendar; method=REQUEST; charset=US-ASCII;
Component=vevent
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.vcs"
コンテントタイプ: テキスト/カレンダー。 方法は要求と等しいです。 charsetは米国-ASCIIと等しいです。 コンポーネントはveventの満足している転送コード化と等しいです: 7は満足している気質に噛み付きました: 付属。 ファイル名="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-バージョン: 1.0バージョン: 2.0BEGIN:VEVENT ORGANIZER: foo1@example.com ATTENDEE; 議長; ATTSTAT=ACCEPTED: foo1@example.com ATTENDEE; ROLE=RSVPははい; TYPE=INDIVIDUAL:mailto: foo2@example.com ATTENDEE; RSVP=はい; TYPE=INDIVIDUAL:mailto: foo3@example.com DTSTAMP: 19970611T190000Z DTSTART:19970621T170000Z DTEND:199706211T173000Z SUMMARYと等しいです: UID: 添付書類calsvr.example.com-873970198738777-8aaについて議論しましょう。
Dawson, et. al. Standards Track [Page 13] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[13ページ]。
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コンテントタイプ: アプリケーション/msword。 ="FieldReport.doc"満足している転送コード化を命名してください: base64 Content-気質: インライン。 ファイル名は"FieldReport.doc"コンテント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
----FEE3790DC7E35189CA67CE2C
5 Recommended Practices
5 お勧めの習慣
This section outlines a series of recommended practices when using a messaging transport to exchange iCalendar objects.
iCalendar物を交換するのにメッセージング輸送を使用するとき、このセクションは一連の推奨案について概説します。
5.1 Use of Content and Message IDs
5.1 内容とメッセージIDの使用
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]仕様はURIの「記述」や、「付いてください」や、「接触」や他のものなどの所有地のデータ型の頻繁な使用をします。 2つのフォームのURIは、Message ID(MID)とContent ID(CID)です。 これらは[RFC-2111]で定義されます。 [RFC-2111]は、他のMIME実体か店でメッセージかMIME身体の部分に参照をつけるのを許容しますが、iMIP実現がただ一つのMIME実体にすべての参照をつけられたメッセージと身体の部分を含むことが強く勧められます。 単に、iCalendar物が他のメッセージか身体の部分のCIDかMID参照を含んでいるなら、置かれます、実現はこれらのメッセージ、そして/または、身体の部分がiCalendar物で伝えられるのを確実にするべきです。 それらがそれらの物を見るために受信「Cu」にはアクセスか認可があるという保証が全くないということであるなら。
Dawson, et. al. Standards Track [Page 14] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[14ページ]。
6 Bibliography
6 図書目録
[CHST] Character Sets, ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets
[CHST]文字コード、 ftp://ftp.isi.edu/in- 注意/iana/課題/文字の組
[iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification - iCalendar", RFC
2445, November 1998.
[iCAL] ドーソン、F.、およびD.Stenerson、「インターネットCalendaringとスケジューリングは物の仕様の芯を取ります--iCalendar」、RFC2445、11月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, November 1998.
[iTIP] シルバーバーグ、S.、マンスール、S.、ドーソン、F.、およびR.ホプソン、「iCalendarの輸送から独立している相互運用性は(iTIP)について議定書の中で述べます」。 「出来事、繁忙期、大騒ぎ、および仕訳記入の計画をします」、RFC2446、1998年11月。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, August 1982.
[RFC-822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、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] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「サインされて複合の/がコード化した複合/」、RFC1847、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]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)--1つを分けてください」 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) - Part Two: Media Types", RFC 2046,
November 1996.
解放された[RFC-2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)--2を分けてください」 「メディアタイプ」、RFC2046、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]ムーア、K.、「マルチパーパスインターネットメールエクステンション(MIME)--3を分けてください」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、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]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)--4を分けてください」 「登録手順」、RFC2048、1997年1月。
[RFC-2111] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2111, March 1997.
[RFC-2111] レヴィンソン、E.、「コンテントIDとMessage ID Uniform Resource Locator」、RFC2111、1997年3月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Dawson, et. al. Standards Track [Page 15] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[15ページ]。
7 Authors' Addresses
7人の作者のアドレス
The following address information is provided in a vCard v3.0, Electronic Business Card, format.
vCard v3.0、Electronic Business Card、形式に以下のアドレス情報を提供します。
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
始まってください: VCARDバージョン: N: ドーソン; フランクFN: フランクドーソンORG: Lotus Development Corporation ADR; タイプ=が扱う郵便であることの3.0は以下を包みにします。6544年のバトルフォードのドライブ; ローリー; NC; 27613-3502; 米国TEL;は=仕事、エムエスジーをタイプします: +1-919-676-9515 TEL; タイプ=仕事、Fax:+1-919-676-9564メール;は=インターネット: fdawson@earthlink.net URL: http://home.earthlink.net/~fdawsonエンド: 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
始まってください: VCARDバージョン: N: マンスール; スティーブFN: スティーブマンスールORG: ネットスケープ社ADR; タイプ=が扱う郵便であることの3.0は以下を包みにします。501の東Middlefield道路; マウンテンビュー; カリフォルニア; 94043; 米国TEL;は=仕事、エムエスジーをタイプします: +1-650-937-2378 TEL; タイプ=仕事、Fax:+1-650-937-2103メール;は=インターネット: sman@netscape.com エンド: 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
始まってください: VCARDバージョン: N: シルバーバーグ; スティーブFN: スティーブシルバーバーグORG: マイクロソフト社ADR; タイプ=が扱う郵便であることの3.0は以下を包みにします。1つのマイクロソフト方法。 レッドモンド; ワシントン; 98052-6399; 米国TEL;は=仕事、エムエスジーをタイプします: +1-425-936-9277 TEL; タイプ=仕事、Fax:+1-425-936-8019メール;は=インターネット: stevesil@Microsoft.com エンド: VCARDをタイプします。
Dawson, et. al. Standards Track [Page 16] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[16ページ]。
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 Objectはインターネット・エンジニアリング・タスク・フォースCalendaringとスケジューリング作業部会の仕事の結果です。 そのワーキンググループの議長は以下の通りです。
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
始まってください: VCARDバージョン: N: ガングリー; アーニク衛星FN: アーニク衛星ガングリーORG: オープンテキスト株式会社ADR; タイプ=が扱う郵便であることの3.0は以下を包みにします; スイートの101;38777の6マイルの西道路 リボニア; MI; 48152; 米国TEL;は=仕事、エムエスジーをタイプします: +1-734-542-5955 メールしてください; =インターネット: ganguly@acm.org エンド: VCARDをタイプしてください。
BEGIN:VCARD VERSION:3.0 N:Moskowitz;Robert FN:Robert Moskowitz EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com END:VCARD
始まってください: VCARDバージョン: 3.0に、N: マスコウィッツ; ロバートFN: ロバートマスコウィッツEMAIL;は=インターネット: rgm-ietf@htt-consult.com エンド: VCARDをタイプします。
Dawson, et. al. Standards Track [Page 17] RFC 2447 iMIP November 1998
etドーソン、アル。 規格はiMIP1998年11月にRFC2447を追跡します[17ページ]。
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Dawson, et. al. Standards Track [Page 18]
etドーソン、アル。 標準化過程[18ページ]
一覧
スポンサーリンク
