[要約] RFC 3283は、インターネットカレンダリングのガイドラインであり、カレンダーの標準化と相互運用性を促進することを目的としています。このRFCは、カレンダーシステムの設計と実装に関する指針を提供します。
Network Working Group B. Mahoney
Request for Comments: 3283 MIT
Category: Informational G. Babics
Steltor
A. Taler
June 2002
Guide to Internet Calendaring
インターネットカレンダーのガイド
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work.
このドキュメントでは、さまざまなインターネットカレンダーとスケジューリング基準について説明し、進行中の機能、およびそれらの間の関係について説明します。その目的は、これらのドキュメントのコンテキストを提供し、理解を支援し、標準ベースのカレンダーおよびスケジューリングシステムの設計を支援することです。対処されている標準は、RFC 2445（ICALENDAR）、RFC 2446（ITIP）、およびRFC 2447（IMIP）です。進行中の作業は「カレンダーアクセスプロトコル」（CAP）です。また、このドキュメントは、これらのプロトコルによって解決されない問題と問題についても説明しており、将来の作業のターゲットになる可能性があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Concepts and Relationships . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Fundamental Needs . . . . . . . . . . . . . . . . . . . . . 4
2.2 Protocol Requirements . . . . . . . . . . . . . . . . . . . 5
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 Standalone Single-user System . . . . . . . . . . . . . . . 8
3.2.2 Single-user Systems Communicating . . . . . . . . . . . . . 8
3.2.3 Single-user with Multiple CUAs . . . . . . . . . . . . . . . 9
3.2.4 Single-user with Multiple Calendars . . . . . . . . . . . . 9
3.2.5 Users Communicating on a Multi-user System . . . . . . . . . 10
3.2.6 Users Communicating through Different Multi-user Systems . . 10
4. Important Aspects . . . . . . . . . . . . . . . . . . . . . 10
4.1 Timezones . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Choice of Transport . . . . . . . . . . . . . . . . . . . . 11
4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Amount of data . . . . . . . . . . . . . . . . . . . . . . . 11
4.5 Recurring Components . . . . . . . . . . . . . . . . . . . . 11
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Scheduling People, not Calendars . . . . . . . . . . . . . . 12
5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . 12
5.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . 12
6.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . 12
6.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 12
6.3 Using E-mail . . . . . . . . . . . . . . . . . . . . . . . . 13
6.4 Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
Calendaring and scheduling protocols are intended to aid individuals in obtaining calendaring information and scheduling meetings across the Internet, to aid organizations in providing calendaring information on the Internet, and to provide for organizations looking for a calendaring and scheduling solution to deploy internally.
カレンダーおよびスケジューリングプロトコルは、個人がインターネット全体でカレンダー情報とスケジューリング会議の取得を支援し、インターネット上のカレンダー情報を提供するのを支援し、内部で展開するためのカレンダー化とスケジューリングソリューションを探している組織に提供することを目的としています。
It is the intent of this document to provide a context for these documents, assist in their understanding, and potentially help in the design of standards-based calendaring and scheduling systems.
これらのドキュメントのコンテキストを提供し、彼らの理解を支援し、標準ベースのカレンダーとスケジューリングシステムの設計を支援することは、このドキュメントの意図です。
Problems not solved by these protocols, as well as security issues to be kept in mind, are discussed at the end of the document.
これらのプロトコルによって解決されていない問題と、留意すべきセキュリティの問題は、ドキュメントの最後で議論されています。
This memo uses much of the same terminology as iCalendar [RFC-2445], iTIP [RFC-2446], iMIP [RFC-2447], and [CAP]. The following definitions are provided as an introduction; the definitions in the protocol specifications themselves should be considered canonical.
このメモは、ICALENDAR [RFC-2445]、ITIP [RFC-2446]、IMIP [RFC-2447]、および[CAP]と同じ用語の多くを使用します。以下の定義は、紹介として提供されています。プロトコル仕様自体の定義は標準的であると見なされるべきです。
Calendar
カレンダー
A collection of events, to-dos, journal entries, etc. A calendar could be the content of a person or resource's agenda; it could also be a collection of data serving a more specialized need. Calendars are the basic storage containers for calendaring information.
イベント、To-Dos、Journalエントリなどのコレクション。カレンダーは、個人またはリソースのアジェンダの内容である可能性があります。また、より専門的なニーズを提供するデータのコレクションでもあります。カレンダーは、カレンダー情報の基本的なストレージコンテナです。
Calendar Access Rights
カレンダーアクセス権
A set of rules defining who may perform what operations, such as reading or writing information, on a given calendar.
特定のカレンダーで、情報の読み取りや執筆など、誰がどの操作を実行できるかを定義する一連のルール。
Calendar Service
カレンダーサービス
A running server application that provides access to a number of calendar stores.
多くのカレンダーストアへのアクセスを提供する実行中のサーバーアプリケーション。
Calendar Store (CS)
カレンダーストア（CS）
A data store of a calendar service. A calendar service may have several calendar stores, and each store may contain several calendars, as well as properties and components outside of those calendars.
カレンダーサービスのデータストア。カレンダーサービスにはいくつかのカレンダーストアがあり、各ストアにはいくつかのカレンダー、およびそれらのカレンダーの外側のプロパティとコンポーネントが含まれる場合があります。
Calendar User (CU)
カレンダーユーザー（CU）
An entity (often a human) that accesses calendar information.
カレンダー情報にアクセスするエンティティ（多くの場合人間）。
Calendar User Agent (CUA)
カレンダーユーザーエージェント（CUA）
Software with which the calendar user communicates with a calendar service or local calendar store to access calendar information.
カレンダーユーザーがカレンダーサービスまたはローカルカレンダーストアと通信してカレンダー情報にアクセスするソフトウェア。
Component
成分
A piece of calendar data such as an event, a to-do or an alarm. Information about components is stored as properties of those components.
イベント、To Do、アラームなどのカレンダーデータ。コンポーネントに関する情報は、これらのコンポーネントのプロパティとして保存されます。
Delegator
委任者
A calendar user who has assigned his or her participation in a scheduled calendar component (e.g. a VEVENT) to another calendar user (sometimes called the delegate or delegatee). An example of a delegator is a busy executive sending an employee to a meeting in his or her place.
スケジュールされたカレンダーコンポーネント（たとえば、Vevent）への参加を別のカレンダーユーザーに割り当てたカレンダーユーザー（代表者または代表者と呼ばれることもあります）。委任者の例は、従業員を自分の場所の会議に送る忙しい幹部です。
Delegate
委任
A calendar user (sometimes called the delegatee) who has been assigned to participate in a scheduled calendar component (e.g. a VEVENT) in place of one of the attendees in that component (sometimes called the delegator). An example of a delegate is a team member sent to a particular meeting.
そのコンポーネントの参加者の1人の代わりに、スケジュールされたカレンダーコンポーネント（例：Vevent）に参加するように割り当てられたカレンダーユーザー（代表者と呼ばれることもあります）。代表者の例は、特定の会議に送られたチームメンバーです。
Designate
指定
A calendar user authorized to act on behalf of another calendar user. An example of a designate is an assistant scheduling meetings for his or her superior.
別のカレンダーユーザーに代わって行動することを許可されたカレンダーユーザー。指定の例は、彼または彼女の上司のためのアシスタントスケジューリング会議です。
Local Store
地元の店
A CS that is on the same device as the CUA.
CUAと同じデバイスにあるCS。
Property
財産
A description of some element of a component, such as a start time, title or location.
開始時間、タイトル、場所など、コンポーネントの要素の説明。
Remote Store
リモートストア
A CS that is not on the same device as the CUA.
CUAと同じデバイスにないCS。
iCalendar is the language used to describe calendar objects. iTIP describes a way to use the iCalendar language to do scheduling. iMIP describes how to do iTIP scheduling via e-mail. CAP describes a way to use the iCalendar language to access a calendar store in real-time.
ICALENDARは、カレンダーオブジェクトを説明するために使用される言語です。ITIPは、アイカルエンダル言語を使用してスケジューリングを行う方法を説明しています。IMIPは、電子メールでitipスケジューリングを行う方法について説明します。CAPは、IcalEndar言語を使用してカレンダーストアにリアルタイムでアクセスする方法を説明しています。
The relationship between calendaring protocols is similar to that between e-mail protocols. In those terms, iCalendar is analogous to RFC 2822, iTIP and iMIP are analogous to the Simple Mail Transfer Protocol (SMTP), and CAP is analogous to the Post Office Protocol (POP) or Internet Message Access Protocol (IMAP).
カレンダープロトコル間の関係は、電子メールプロトコル間の関係に似ています。これらの用語では、ICALENDARはRFC 2822に類似しており、ITIPとIMIPは単純なメール転送プロトコル（SMTP）に類似しており、CAPは郵便局プロトコル（POP）またはインターネットメッセージアクセスプロトコル（IMAP）に類似しています。
The following scenarios illustrate people and organizations' basic calendaring and scheduling needs:
次のシナリオは、人々と組織の基本的なカレンダーとスケジューリングのニーズを示しています。
a] A doctor wishes to keep track of all her appointments.
A]医師は、すべての任命を追跡したいと考えています。
Need: To read and manipulate one's own calendar with only one CUA.
必要：自分のカレンダーを1つだけで読んで操作すること。
b] A busy musician wants to maintain her schedule with multiple devices, such as through an Internet-based agenda and with a PDA.
B]忙しいミュージシャンは、インターネットベースのアジェンダやPDAなど、複数のデバイスでスケジュールを維持したいと考えています。
Need: To read and manipulate one's own calendar, possibly with solutions from different vendors.
ニーズ：おそらく、さまざまなベンダーからの解決策を使用して、自分のカレンダーを読んで操作すること。
c] A software development team wishes to more effectively schedule their time through viewing each other's calendar information.
c]ソフトウェア開発チームは、お互いのカレンダー情報を表示して、より効果的に時間をスケジュールしたいと考えています。
Need: To share calendar information between users of the same calendar service.
ニーズ：同じカレンダーサービスのユーザー間でカレンダー情報を共有する。
d] A teacher wants his students to schedule appointments during his office hours.
d]教師は、生徒に営業時間中に予定をスケジュールすることを望んでいます。
Need: To schedule calendar events, to-dos and journals with other users of the same calendar service.
ニーズ：同じカレンダーサービスの他のユーザーとカレンダーイベント、To-Dos、およびジャーナルをスケジュールする。
e] A movie theater wants to publish its schedule for prospective customers.
e]映画館は、見込み客向けのスケジュールを公開したいと考えています。
Need: To share calendar information with users of other calendar services, possibly from a number of different vendors.
ニーズ：おそらく多くの異なるベンダーから、他のカレンダーサービスのユーザーとカレンダー情報を共有すること。
f] A social club wants to schedule calendar entries effectively with its members.
f]ソーシャルクラブは、メンバーとのカレンダーエントリを効果的にスケジュールしたいと考えています。
Need: To schedule calendar events and to-dos with users of other calendar services, possibly from a number of different vendors.
ニーズ：おそらく多数の異なるベンダーから、他のカレンダーサービスのユーザーとカレンダーイベントやTo-Dosをスケジュールすること。
Some of these needs can be met by proprietary solutions (a, c, d), but others can not (b, e, f). These latter scenarios show that standard protocols are required for accessing information in a calendar store and scheduling calendar entries. In addition, these protocols require a common data format for representing calendar information.
これらのニーズのいくつかは、独自のソリューション（a、c、d）で満たすことができますが、他のニーズはできません（b、e、f）。これらの後者のシナリオは、カレンダーストアで情報にアクセスしてカレンダーエントリをスケジュールするために標準プロトコルが必要であることを示しています。さらに、これらのプロトコルには、カレンダー情報を表すための共通のデータ形式が必要です。
These requirements are met by the following protocol specifications.
これらの要件は、次のプロトコル仕様によって満たされます。
- Data format: iCalendar [RFC-2445]
- データ形式：icalendar [RFC-2445]
iCalendar [RFC-2445] provides a data format for representing calendar information, to be used and exchanged by other protocols. iCalendar [RFC-2445] can also be used in other contexts, such as a drag-and-drop interface, or an export/import feature. All the other calendaring protocols depend on iCalendar [RFC-2445], so all elements of a standards-based calendaring and scheduling systems will have to be able to interpret iCalendar [RFC-2445].
ICALENDAR [RFC-2445]は、他のプロトコルによって使用および交換されるカレンダー情報を表すためのデータ形式を提供します。ICALENDAR [RFC-2445]は、ドラッグアンドドロップインターフェイスやエクスポート/インポート機能など、他のコンテキストでも使用できます。他のすべてのカレンダープロトコルはIcalEndar [RFC-2445]に依存するため、標準ベースのカレンダーおよびスケジューリングシステムのすべての要素は、IcalEndar [RFC-2445]を解釈できる必要があります。
- Scheduling protocol: iTIP [RFC-2446]
- スケジューリングプロトコル：ITIP [RFC-2446]
iTIP [RFC-2446] describes the messages used to schedule calendar events. Within iTIP messages, events are represented in iCalendar [RFC-2445] format, and have semantics that identify the message as being an invitation to a meeting, an acceptance of an invitation, or the assignment of a task.
ITIP [RFC-2446]は、カレンダーイベントのスケジュールに使用されるメッセージを説明しています。ITIPメッセージ内で、イベントはIcalEndar [RFC-2445]形式で表され、メッセージを会議への招待、招待状の受け入れ、またはタスクの割り当てであると特定するセマンティクスがあります。
iTIP [RFC-2446] messages are used in the scheduling workflow, where users exchange messages in order to organize things such as events and to-dos. CUAs generate and interpret iTIP [RFC-2446] messages at the direction of the calendar user. With iTIP [RFC-2446] users can create, modify, delete, reply to, counter, and decline counters to the various iCalendar [RFC-2445] components. Furthermore, users can also request the free/busy time of other people.
ITIP [RFC-2446]メッセージは、スケジューリングワークフローで使用されます。ここでは、ユーザーはメッセージを交換してイベントやTo-DOなどを整理します。CUASは、カレンダーユーザーの方向にITIP [RFC-2446]メッセージを生成および解釈します。ITIP [RFC-2446]を使用すると、ユーザーはさまざまなIcalEndar [RFC-2445]コンポーネントにカウンターを作成、変更、削除、返信、カウンター、および拒否できます。さらに、ユーザーは他の人の無料/忙しい時間を要求することもできます。
iTIP [RFC-2446] is transport-independent, and has one specified transport binding: iMIP [RFC-2447] binds iTIP to e-mail. In addition [CAP] will provide a real-time binding of iTIP [RFC-2446], allowing CUAs to perform calendar management and scheduling over a single connection.
ITIP [RFC-2446]は輸送に依存しておらず、1つの指定された輸送結合があります：IMIP [RFC-2447]はITIPを電子メールに結合します。さらに、[CAP]は、ITIP [RFC-2446]のリアルタイムバインディングを提供し、CUASが単一の接続でカレンダー管理とスケジューリングを実行できるようにします。
- Calendar management protocol: [CAP]
- カレンダー管理プロトコル：[CAP]
[CAP] describes the messages used to manage calendars on a calendar store. These messages use iCalendar [RFC-2445] to describe various components such as events and to-dos. These messages make it possible to perform iTIP [RFC-2446] operations, as well as other operations relating to a calendar store such as searching, creating calendars, specifying calendar properties, and specifying calendar access rights.
[CAP]は、カレンダーストアでカレンダーを管理するために使用されるメッセージを説明しています。これらのメッセージは、IcalEndar [RFC-2445]を使用して、イベントやTo-DOなどのさまざまなコンポーネントを記述します。これらのメッセージにより、ITIP [RFC-2446]操作、および検索、カレンダーの作成、カレンダープロパティの指定、カレンダーアクセス権の指定などのカレンダーストアに関連する他の操作を実行できます。
Returning to the scenarios presented in section 2.1, the calendaring protocols can be used in the following ways:
セクション2.1で提示されたシナリオに戻ると、カレンダープロトコルは次の方法で使用できます。
a] The doctor can use a proprietary CUA with a local store, and perhaps use iCalendar [RFC-2445] as a storage mechanism. This would allow her to easily import her data store into another application that supports iCalendar [RFC-2445].
a]医師は、地元の店で独自のCUAを使用し、おそらく貯蔵メカニズムとしてIcalEndar [RFC-2445]を使用することができます。これにより、彼女はデータストアを簡単にICALENDAR [RFC-2445]をサポートする別のアプリケーションにインポートすることができます。
b] The musician who wishes to access her agenda from anywhere can use a [CAP]-enabled calendar service accessible over the Internet. She can then use any available [CAP] clients to access the data.
B]どこからでもアジェンダにアクセスしたいミュージシャンは、インターネットでアクセスできる[CAP]対応のカレンダーサービスを使用できます。その後、利用可能な[CAP]クライアントを使用してデータにアクセスできます。
A proprietary system that provides access through a Web-based interface could also be employed, but the use of [CAP] would be superior in that it would allow the use of third party applications, such as PDA synchronization tools.
Webベースのインターフェイスを介してアクセスを提供する独自のシステムも使用できますが、[CAP]の使用は、PDA同期ツールなどのサードパーティアプリケーションの使用を可能にするという点で優れています。
c] The development team can use a calendar service which supports [CAP], and each member can use a [CAP]-enabled CUA of their choice.
c]開発チームは[CAP]をサポートするカレンダーサービスを使用でき、各メンバーは選択した[CAP]対応CUAを使用できます。
Alternatively, each member could use an iMIP [RFC-2447]-enabled CUA, and they could book meetings over e-mail. This solution has the drawback that it is difficult to examine other users' agendas, making the organization of meetings more difficult.
あるいは、各メンバーはIMIP [RFC-2447]対応CUAを使用でき、電子メールで会議を予約することができます。このソリューションには、他のユーザーのアジェンダを調べることが困難であり、会議の組織化をより困難にするという欠点があります。
Proprietary solutions are also available, but they require that all members use clients by the same vendor, and disallow the use of third party applications.
独自のソリューションも利用できますが、すべてのメンバーが同じベンダーでクライアントを使用し、サードパーティのアプリケーションの使用を禁止する必要があります。
d] The teacher can set up a calendar service, and have students book time through any of the iTIP [RFC-2446] bindings. [CAP] provides real-time access, but could require additional configuration. iMIP [RFC-2447] would be the easiest to configure, but may require more e-mail processing.
d]教師はカレンダーサービスをセットアップし、生徒にITIP [RFC-2446]バインディングのいずれかで時間を予約させることができます。[CAP]はリアルタイムアクセスを提供しますが、追加の構成が必要になる場合があります。IMIP [RFC-2447]は構成が最も簡単ですが、より多くの電子メール処理が必要になる場合があります。
If [CAP] access is provided then determining the state of the teacher's schedule is straightforward. If not, this can be determined through iTIP [RFC-2446] free/busy requests. Non-standard methods could also be employed, such as serving up iCalendar [RFC-2445], HTML, or XML over HTTP.
[cap]アクセスが提供されている場合、教師のスケジュールの状態を決定するのは簡単です。そうでない場合、これはITIP [RFC-2446]無料/ビジーリクエストを介して決定できます。HTTPを介したICALENDAR [RFC-2445]、HTML、またはXMLの提供など、非標準的な方法も採用できます。
A proprietary system could also be used, but would require that all students be able to use software from a specific vendor.
独自のシステムも使用できますが、すべての学生が特定のベンダーからソフトウェアを使用できることを要求します。
e] [CAP] would be preferred for publishing a movie theater's schedule, since it provides advanced access and search capabilities. It also allows easy integration with customers' calendar systems.
E] [CAP]は、映画館のスケジュールを公開するために推奨されます。これは、高度なアクセスおよび検索機能を提供するためです。また、顧客のカレンダーシステムとの簡単な統合も可能になります。
Non-standard methods such as serving data over HTTP could also be employed, but would be harder to integrate with customers' systems.
HTTPを介してデータを提供するなどの非標準的な方法も採用できますが、顧客のシステムと統合するのが難しいでしょう。
Using a completely proprietary solution would be very difficult, if not impossible, since it would require every user to install and use the proprietary software.
すべてのユーザーが独自のソフトウェアをインストールして使用する必要があるため、完全に独自のソリューションを使用することは非常に困難です。
f] The social club could distribute meeting information in the form of iTIP [RFC-2446] messages, sent via e-mail using iMIP [RFC-2447]. The club could distribute meeting invitations, as well as a full published agenda.
F]ソーシャルクラブは、IMIP [RFC-2447]を使用して電子メールで送信されるITIP [RFC-2446]メッセージの形で会議情報を配布できます。クラブは、会議の招待状と、完全に公開されたアジェンダを配布することができます。
Alternatively, the club could provide access to a [CAP]-enabled calendar service. However, this solution would be more expensive since it requires the maintenance of a server.
あるいは、クラブは[CAP]対応カレンダーサービスへのアクセスを提供できます。ただし、サーバーのメンテナンスが必要なため、このソリューションはより高価になります。
The following diagrams illustrate possible systems and their usage of the various protocols.
次の図は、可能なシステムとさまざまなプロトコルの使用を示しています。
A single user system that does not communicate with other systems need not employ any of the protocols. However, it may use iCalendar [RFC-2445] as a data format in some places.
他のシステムと通信しない単一のユーザーシステムは、プロトコルを使用する必要はありません。ただし、一部の場所では、IcalEndar [RFC-2445]をデータ形式として使用する場合があります。
----------- O
| CUA w/ | -+- user
|local store| A
----------- / \
Users with single-user systems may schedule meetings with each others using iTIP [RFC-2446]. The easiest binding of iTIP [RFC-2446] to use would be iMIP [RFC-2447], since messages can be held in the users' mail queues, which we assume to already exist. [CAP] could also be used.
シングルユーザーシステムを使用しているユーザーは、ITIP [RFC-2446]を使用してお互いの会議をスケジュールする場合があります。使用するITIP [RFC-2446]の最も簡単な結合は、IMIP [RFC-2447]です。これは、メッセージをユーザーのメールキューに保持できるため、すでに存在すると仮定しています。[CAP]も使用できます。
O ----------- ----------- O
-+- | CUA w/ | -----[iMIP]----- | CUA w/ | -+- user
A |local store| Internet |local store| A
/ \ ----------- ----------- / \
A single user may use more than one CUA to access his or her calendar. The user may use a PDA, a Web client, a PC, or some other device, depending on accessibility. Some of these clients may have local stores and others may not. Those with local stores need to synchronize the data on the CUA with the data on the CS.
1人のユーザーが複数のCUAを使用してカレンダーにアクセスすることができます。ユーザーは、アクセシビリティに応じて、PDA、Webクライアント、PC、またはその他のデバイスを使用できます。これらのクライアントの中には、地元の店舗がある場合もあれば、そうでない場合もあります。地元の店舗を持っている人は、CUAのデータをCSのデータと同期させる必要があります。
-----------
| CUA w | -----[CAP]----------+
|local store| |
O ----------- ----------
-+- | CS |
A | |
/ \ ----------
----------- |
| CUA w/o | -----[CAP]----------+
|local store|
-----------
A single user may have many independent calendars; for example, one may contain work-related information and another personal information. The CUA may or may not have a local store. If it does, then it needs to synchronize the data of the CUA with the data on both of the CS.
単一のユーザーには、多くの独立したカレンダーがある場合があります。たとえば、仕事関連の情報と別の個人情報が含まれている場合があります。CUAは地元の店を持っているかもしれません。もしそうなら、CUAのデータを両方のCSのデータと同期する必要があります。
----------
+------------[CAP]------ | CS |
| | |
O ----------- ----------
-+- | CUA |
A | |
/ \ -----------
| ----------
+------------[CAP]------ | CS |
| |
----------
Users on a multi-user system may schedule meetings with each other using [CAP]-enabled CUAs and services. The CUAs may or may not have local stores. Those with local stores need to synchronize the data on the CUAs with the data on the CS.
マルチユーザーシステムのユーザーは、[CAP]対応のCUAとサービスを使用して互いに会議をスケジュールすることができます。CUAは地元の店舗を持っている場合とない場合があります。地元の店舗を持っている人は、CUAのデータをCSのデータと同期させる必要があります。
O -----------
-+- | CUA w | -----[CAP]----------+
A |local store| |
/ \ ----------- ----------
| CS |
| |
----------
O ----------- |
-+- | CUA w/o | -----[CAP]----------+
A |local store|
/ \ -----------
Users on a multi-user system may need to schedule meetings with users on a different multi-user system. The services can communicate using [CAP] or iMIP [RFC-2447].
マルチユーザーシステムのユーザーは、異なるマルチユーザーシステムでユーザーとの会議をスケジュールする必要がある場合があります。サービスは、[CAP]またはIMIP [RFC-2447]を使用して通信できます。
O ----------- ----------
-+- | CUA w | -----[CAP]-------| CS |
A |local store| | |
/ \ ----------- ----------
|
[CAP] or [iMIP]
|
O ----------- ----------
-+- | CUA w/o | -----[CAP]-------| CS |
A |local store| | |
/ \ ----------- ----------
There are a number of important aspects of these calendaring standards of which people, especially implementers, should be aware.
これらのカレンダー標準には、人々、特に実装者が注意すべきであるという重要な側面がいくつかあります。
The dates and times in components can refer to a specific time zone. Time zones can be defined in a central store, or they may be defined by a user to fit his or her needs. All users and applications should be aware of time zones and time zone differences. New time zones may need to be added, and others removed. Two different vendors may describe the same time zone differently (such as by using a different name).
コンポーネント内の日付と時間は、特定のタイムゾーンを参照できます。タイムゾーンは、中央ストアで定義することも、ユーザーがニーズに合わせて定義することもできます。すべてのユーザーとアプリケーションは、タイムゾーンとタイムゾーンの違いを認識する必要があります。新しいタイムゾーンを追加する必要があり、他のゾーンを削除する必要があります。2つの異なるベンダーは、同じタイムゾーンを異なる方法で説明できます（別の名前を使用するなど）。
There are issues to be aware of in choosing between a network protocol such as [CAP], or a store and forward protocol, such as iMIP [RFC-2447].
[CAP]などのネットワークプロトコル、またはIMIP [RFC-2447]などのストアとフォワードプロトコルのいずれかを選択する際に注意すべき問題があります。
The use of a network ("on-the-wire") mechanism may require some organizations to make provisions to allow calendaring traffic to traverse a corporate firewall on the required ports. Depending on the organizational culture, this may be a challenging social exercise.
ネットワーク（「オンザワイヤ」）メカニズムの使用では、一部の組織が必要なポートで企業のファイアウォールをカレンダートラフィックに通過できるように規定を作成する必要があります。組織文化によっては、これは挑戦的な社会的演習かもしれません。
The use of an email-based mechanism exposes time-sensitive data to unbounded latency. Large or heavily utilized mail systems may experience an unacceptable delay in message receipt.
電子メールベースのメカニズムを使用すると、時間に敏感なデータが無制限のレイテンシにさらされます。大規模または頻繁に利用されているメールシステムは、メッセージ受信に受け入れられない遅延が発生する場合があります。
See the "Security Considerations" (Section 6) section below.
以下の「セキュリティ上の考慮事項」（セクション6）セクションを参照してください。
In some cases, a component may be very large, for instance, a component with a very large attachment. Some applications may be low-bandwidth or may be limited in the amount of data they can store. Maximum component size may be set in [CAP]. It can also be controlled in iMIP [RFC-2447] by restricting the maximum size of the e-mail that the application can download.
場合によっては、コンポーネントが非常に大きくなる場合があります。たとえば、非常に大きなアタッチメントを持つコンポーネントです。一部のアプリケーションは、帯域幅が低い場合がある場合や、保存できるデータの量が制限されている場合があります。[CAP]に最大コンポーネントサイズを設定できます。また、アプリケーションがダウンロードできる電子メールの最大サイズを制限することにより、IMIP [RFC-2447]で制御できます。
In iCAL [RFC-2445], one can specify complex recurrence rules for VEVENTs, VTODOs, and VJOURNALs. One must be careful to correctly interpret these recurrence rules and pay extra attention to being able to interoperate using them.
ICAL [RFC-2445]では、Vevents、Vtodos、およびVjournalsの複雑な再発ルールを指定できます。これらの再発ルールを正しく解釈し、それらを使用して相互運用できることに特に注意を払うように注意する必要があります。
Many issues are not currently resolved by these protocols, and many desirable features are not yet provided. Some of the more prominent ones are outlined below.
現在、多くの問題はこれらのプロトコルによって解決されておらず、多くの望ましい機能はまだ提供されていません。より顕著なもののいくつかは、以下に概説されています。
Meetings are scheduled with people; however, people may have many calendars, and may store these calendars in many places. There may also be many routes to contact them. The calendaring protocols do not attempt to provide unique access for contacting a given person. Instead, 'calendar addresses' are booked, which may be e-mail addresses or individual calendars. It is up to the users themselves to orchestrate mechanisms to ensure that the bookings go to the right place.
会議は人々とスケジュールされています。ただし、人々は多くのカレンダーを持っている可能性があり、これらのカレンダーを多くの場所に保存する場合があります。また、それらに連絡するための多くのルートがあるかもしれません。カレンダープロトコルは、特定の人に連絡するためのユニークなアクセスを提供しようとはしません。代わりに、「カレンダーアドレス」が予約されます。これは、電子メールアドレスまたは個々のカレンダーです。予約が正しい場所に行くことを保証するために、メカニズムを組織するのはユーザー自身次第です。
The calendaring protocols do not address the issues of administering users and calendars on a calendar service. This must be handled by proprietary mechanisms for each implementation.
カレンダープロトコルは、カレンダーサービスでユーザーとカレンダーを管理する問題に対処していません。これは、実装ごとに独自のメカニズムによって処理する必要があります。
People often wish to be notified of upcoming events, new events, or changes to existing events. The calendaring protocols do not attempt to address these needs in a real-time system. Instead, the ability to store alarm information on events is provided, which can be used to provide client-side notification of upcoming events. To organize notification of new or changed events, clients have to poll the data store.
多くの場合、今後のイベント、新しいイベント、または既存のイベントの変更について通知されることを望んでいます。カレンダープロトコルは、リアルタイムシステムでこれらのニーズに対処しようとはしません。代わりに、イベントにアラーム情報を保存する機能が提供されます。これは、今後のイベントのクライアント側の通知を提供するために使用できます。新しいイベントまたは変更されたイベントの通知を整理するには、クライアントはデータストアを投票する必要があります。
There has to be reasonable granularity in the configuration options for access to data through [CAP], so that what should be released to requesters is released, and what shouldn't is not. Details of handling this are described in [CAP].
[CAP]を介してデータにアクセスするための構成オプションには合理的な粒度が必要であるため、リクエスタにリリースされるべきものがリリースされ、そうでないことがありません。これの取り扱いの詳細は[CAP]で説明されています。
Access control must be coupled with a good authentication system, so that the right people get the right information. For [CAP], this means requiring authentication before any database access can be performed, and checking access rights and authentication credentials before releasing information. [CAP] uses the Simple Authentication Security Layer (SASL) for this authentication. In iMIP [RFC-2447], this may present some challenges, as authentication is often not a consideration in store-and-forward protocols.
適切な人が適切な情報を得るように、アクセス制御を適切な認証システムと結合する必要があります。[cap]の場合、これは、データベースアクセスを実行する前に認証を必要とし、情報をリリースする前にアクセス権と認証資格情報を確認できることを意味します。[CAP]この認証には、Simple認証セキュリティレイヤー（SASL）を使用します。IMIP [RFC-2447]では、認証はストアアンドフォワードプロトコルの考慮事項ではないことが多いため、これはいくつかの課題を提示する可能性があります。
Authentication is also important for scheduling, in that receivers of scheduling messages should be able to validate the apparent sender. Since scheduling messages are wrapped in MIME [RFC-2045], signing and encryption are freely available. For messages transmitted over mail, this is the only available alternative. It is suggested that developers take care in implementing the security features in iMIP [RFC-2447], bearing in mind that the concept and need may be foreign or non-obvious to users, yet essential for the system to function as they might expect.
スケジューリングには認証も重要です。そのため、スケジューリングメッセージの受信者は見かけの送信者を検証できるはずです。スケジューリングメッセージはMIME [RFC-2045]に包まれているため、署名と暗号化は自由に利用可能です。郵便で送信されたメッセージの場合、これが唯一の利用可能な代替手段です。開発者は、IMIP [RFC-2447]のセキュリティ機能を実装することに注意することが示唆されています。これは、概念とニーズはユーザーにとって外国人または非自明である可能性があるが、システムが予想されるように機能するために不可欠であることを念頭に置いています。
The real-time protocols provide for the authentication of users, and the preservation of that authentication information, allowing for validation by the receiving end-user or server.
リアルタイムプロトコルは、ユーザーの認証とその認証情報の保存を提供し、受信エンドユーザーまたはサーバーによる検証を可能にします。
Because scheduling information can be transmitted over mail without any authentication information, e-mail spoofing is extremely easy if the receiver is not checking for authentication. It is suggested that implementers consider requiring authentication as a default, using mechanisms such as are described in Section 3 of iMIP [RFC-2447]. The use of e-mail, and the potential for anonymous connections, means that 'calendar spam' is possible. Developers should consider this threat when designing systems, particularly those that allow for automated request processing.
スケジューリング情報は認証情報なしで郵便で送信できるため、受信者が認証をチェックしていない場合、電子メールスプーフィングは非常に簡単です。実装者は、IMIP [RFC-2447]のセクション3で説明されているようなメカニズムを使用して、デフォルトとして認証を要求することを検討することをお勧めします。電子メールの使用と匿名接続の可能性は、「カレンダースパム」が可能であることを意味します。開発者は、システム、特に自動化された要求処理を可能にするシステムを設計する際に、この脅威を考慮する必要があります。
The current security context should be obvious to users. Because the underlying mechanisms may not be clear to users, efforts to make clear the current state in the UI should be made. One example of this is the 'lock' icon used in some Web browsers during secure connections.
現在のセキュリティコンテキストは、ユーザーには明らかです。根本的なメカニズムはユーザーにとって明確ではない可能性があるため、UIの現在の状態を明確にするための努力をする努力が必要です。この一例は、安全な接続中に一部のWebブラウザーで使用される「ロック」アイコンです。
With both iMIP [RFC-2447] and [CAP], the possibilities of Denial of Service attacks must be considered. The ability to flood a calendar system with bogus requests is likely to be exploited once these systems become widely deployed, and detection and recovery methods will need to be considered.
IMIP [RFC-2447]と[CAP]の両方で、サービス拒否攻撃の可能性を考慮する必要があります。これらのシステムが広く展開されると、カレンダーシステムに偽のリクエストを殺す機能が悪用される可能性が高く、検出および回復方法を考慮する必要があります。
Acknowledgments
謝辞
Thanks to the following, who have participated in the development of this document:
以下のおかげで、このドキュメントの開発に参加した人は次のとおりです。
Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn, Alan Davies, Robb Surridge.
エリック・ブスブーム、パット・エイジェン、デビッド・メイド、ショーン・パックウッド、ブルース・カーン、アラン・デイビス、ロブ・サリッジ。
References
参考文献
[RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification - iCalendar", RFC 2445, November 1998.
[RFC -2445] Dawson、F。およびD. Stenerson、「インターネットカレンダーとスケジューリングコアオブジェクト仕様-ICALENDAR」、RFC 2445、1998年11月。
[RFC-2446] 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.
[RFC-2446] Silverberg、S.、Mansour、S.、Dawson、F。、およびR. Hopson、「Icalendar Transport Indoptent Interoperability Protocol（ITIP）：スケジューリングイベント、忙しい時間、To-Dos、Journalエントリ」、RFC2446、1998年11月。
[RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message-Based Interoperability Protocol - iMIP", RFC 2447, November 1998.
[RFC-2447] Dawson、F.、Mansour、S。、およびS. Silverberg、「Icalendarメッセージベースの相互運用性プロトコル - IMIP」、RFC 2447、1998年11月。
[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、「多目的インターネットメール拡張機能（MIME） - パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[CAP] Mansour, S., Royer, D., Babics, G., and Hill, P., "Calendar Access Protocol (CAP)", Work in Progress.
[Cap] Mansour、S.、Royer、D.、Babics、G。、およびHill、P。、「カレンダーアクセスプロトコル（CAP）」、Work in Progress。
Authors' Addresses
著者のアドレス
Bob Mahoney MIT E40-327 77 Massachusetts Avenue Cambridge, MA 02139 US
ボブ・マホニーMIT E40-327 77マサチューセッツアベニューケンブリッジ、マサチューセッツ州02139 US
Phone: (617) 253-0774 EMail: bobmah@mit.edu
電話：（617）253-0774メール：bobmah@mit.edu
George Babics Steltor 2000 Peel Street Montreal, Quebec H3A 2W5 CA
George Babics Steltor 2000 Peel Street Montreal、Quebec H3A 2W5 CA
Phone: (514) 733-8500 x4201 EMail: georgeb@steltor.com
電話：（514）733-8500 x4201メール：georgeb@steltor.com
Alexander Taler
アレクサンダー・テラー
EMail: alex@0--0.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。