RFC3283 日本語訳
3283 Guide to Internet Calendaring. B. Mahoney, G. Babics, A. Taler. June 2002. (Format: TXT=31768 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Mahoney
Request for Comments: 3283 MIT
Category: Informational G. Babics
Steltor
A. Taler
June 2002
コメントを求めるワーキンググループB.マホニー要求をネットワークでつないでください: 3283年のMITカテゴリ: 情報のG.Babics Steltor A.Taler2002年6月
Guide to Internet Calendaring
インターネットにCalendaringを動かしてください。
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントは様々なインターネットcalendaringとスケジューリング規格、執筆中の作品、およびそれらの間の関係について説明します。 意図は、これらのドキュメントのための文脈を提供して、彼らの理解を助けて、規格ベースのcalendaringとスケジューリングシステムの設計で潜在的に支援することです。記述された規格は、RFC2445(iCalendar)と、RFC2446(iTIP)と、RFC2447です(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1用語. . . . . . . . . . . . . . . . . . . . . . . . 2 1.2概念と関係. . . . . . . . . . . . . . . . . 4 2。 要件. . . . . . . . . . . . . . . . . . . . . . . . 4 2.1原理は.42.2のプロトコル要件. . . . . . . . . . . . . . . . . . . 5 3を必要とします。 ソリューション. . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1例. . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2のシステム. . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1スタンドアロンシングルユーザーシステム. . . . . . . . . . . . . . . 8 3.2.2台のシングルユーザーシステムが交信する、.83.2、.3シングルユーザー、複数のCUAs、.93.2、.4シングルユーザー、複数のカレンダー. . . . . . . . . . . . 9
Mahoney, et. al. Informational [Page 1] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[1ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
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
3.2.5 マルチユーザーシステム. . . . . . . . . 10 3.2の上で異なったマルチユーザーシステム. . 10 4を通って交信する.6人のユーザを伝えるユーザ。 データ. . . . . . . . . . . . . . . . . . . . . . . 11 4.5Recurring Components.115のTransport. . . . . . . . . . . . . . . . . . . . 11 4.3Security. . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4Amountの重要なAspects. . . . . . . . . . . . . . . . . . . . . 10 4.1Timezones. . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2Choice。 カレンダー. . . . . . . . . . . . . . 12 5.2政権. . . . . . . . . . . . . . . . . . . . . . . 12 5.3通知. . . . . . . . . . . . . . . . . . . . . . . . 12 6ではなく、人々の計画をする問題. . . . . . . . . . . . . . . . . . . . . . . . 11 5.1を開いてください。 メール. . . . . . . . . . . . . . . . . . . . . . . . 13 6.4他の問題を使用して、セキュリティ問題. . . . . . . . . . . . . . . . . . 12 6.1はコントロール. . . . . . . . . . . . . . . . . . . . . . . 12 6.2認証. . . . . . . . . . . . . . . . . . . . . . . 12 6.3にアクセスします…; .13の承認. . . . . . . . . . . . . . . . . . . . . . 13の参照. . . . . . . . . . . . . . . . . . . . . . . . . 14作者のものは.15の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 16を記述します。
1. Introduction
1. 序論
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.
プロトコルのCalendaringして、計画をするのは、calendaringを探す組織とスケジューリング解答が内部的に展開するように情報をcalendaringして、スケジューリングミーティングをインターネットの向こう側に得る際に個人を支援して、インターネットの情報をcalendaringしながら提供する際に組織を支援して、提供することを意図します。
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.
これらのドキュメントのための文脈を提供して、彼らの理解を助けて、規格ベースのcalendaringとスケジューリングシステムの設計で潜在的に助けるのは、このドキュメントの意図です。
Problems not solved by these protocols, as well as security issues to be kept in mind, are discussed at the end of the document.
ドキュメントの端でこれらのプロトコル、および安全保障問題で解決された、覚えておかれることがない問題について議論します。
1.1 Terminology
1.1 用語
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]と同じ用語の多くを使用します。 序論として以下の定義を提供します。 プロトコル仕様自体との定義は正準であると考えられるべきです。
Mahoney, et. al. Informational [Page 2] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[2ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
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.
出来事、大騒ぎ、仕訳記入などの収集 カレンダーは人かリソースの議題の内容であるかもしれません。 また、それは、より専門化している必要性に役立つデータの収集であるかもしれません。 カレンダーは、情報をcalendaringするための基本的な貯蔵容器です。
Calendar Access Rights
カレンダーアクセス権
A set of rules defining who may perform what operations, such as
reading or writing information, on a given calendar.
だれが読書などのどんな操作か与えられたカレンダーに情報を書くのを実行するかもしれないかを定義する1セットの規則。
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)
カレンダーユーザエージェント(クーア)
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.
出来事、大騒ぎまたはアラームなどの1つのカレンダーデータ。 コンポーネントに関する情報はそれらのコンポーネントの特性として格納されます。
Delegator
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)へのその人の参加を別のカレンダーユーザ(時々代表か「反-遺産受取人」と呼ばれる)に割り当てたカレンダーユーザ。 「反-遺贈者」の例はその人のところでのミーティングに従業員を送る忙しい幹部社員です。
Mahoney, et. al. Informational [Page 3] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[3ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
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.
そのコンポーネント(時々「反-遺贈者」と呼ばれる)の出席者のひとりに代わって予定されているカレンダーコンポーネント(例えば、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.
別のカレンダーユーザを代表して行動するのに権限を与えられたカレンダーユーザ。 aに関する例が指定する、その人の上司のためにミーティングの計画をするアシスタントはそうです。
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。
1.2 Concepts and Relationships
1.2 概念と関係
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はスケジューリングするのにiCalendar言語を使用する方法を述べます。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).
プロトコルをcalendaringすることの間の関係はメールプロトコルの間でそれと同様です。 それらの用語で、iCalendarはRFC2822に類似しています、そして、iTIPとiMIPはシンプルメールトランスファプロトコル(SMTP)に類似しています、そして、CAPはポストオフィスプロトコル(POP)かインターネットMessage Accessプロトコル(IMAP)に類似しています。
2. Requirements
2. 要件
2.1 Fundamental Needs
2.1 基本的な必要性
The following scenarios illustrate people and organizations' basic calendaring and scheduling needs:
以下のシナリオは人々と組織の基本的なcalendaringとスケジューリングの必要性を例証します:
Mahoney, et. al. Informational [Page 4] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[4ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
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.
必要性: 1CUAだけと共に自分自身のカレンダーを読んで、操るために。
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.
必要性: 同じカレンダーサービスの他のユーザと共にカレンダーイベント、大騒ぎ、およびジャーナルの計画をするように。
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.
必要性: 他のカレンダーサービスのユーザと共にことによると多くの異なった業者からカレンダーイベントと大騒ぎの計画をするように。
2.2 Protocol Requirements
2.2 プロトコル要件
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.
これらの必要条件は以下のプロトコル仕様で満たされます。
Mahoney, et. al. Informational [Page 5] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[5ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
- 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]を使用できます、ドラッグ・アンド・ドロップインタフェース、または輸出/輸入機能などのように。 他のすべてのcalendaringプロトコルがiCalendar[RFC-2445]によるので、規格ベースのcalendaringとスケジューリングシステムのすべての原理が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]メッセージはスケジューリング作業フローに使用されます、ユーザが出来事や大騒ぎなどのものを組織化するためにメッセージを交換するところで。 CUAsはカレンダーユーザの指示に基づきiTIP[RFC-2446]メッセージを発生して、解釈します。 ユーザは、iTIP[RFC2446]と共に、様々な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[RFC2446]のリアルタイムの結合を提供するでしょう、CUAsが単独結合の上でカレンダー管理とスケジューリングを実行するのを許容して。
- Calendar management protocol: [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]を使用します。 これらのメッセージでiTIP[RFC-2446]操作を実行するのは可能になります、探すことなどのカレンダー店に関連する他の操作と同様に、カレンダーを作成して、カレンダーの特性を指定して、カレンダーアクセス権を指定して。
Mahoney, et. al. Informational [Page 6] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[6ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
3. Solutions
3. ソリューション
3.1 Examples
3.1 例
Returning to the scenarios presented in section 2.1, the calendaring protocols can be used in the following ways:
セクション2.1に提示されたシナリオに戻って、以下の方法でcalendaringプロトコルを使用できます:
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.
第三者アプリケーションの使用を許すでしょう、また、ウェブベースのインタフェースを通してアクセスを提供するプロプライエタリシステムは使うことができましたが、したがって、[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]の自由であるか忙しい要求で決定できます。 また、iCalendar[RFC-2445]、HTML、またはXMLをHTTPの上に供給するのなどように非標準方法を使うことができました。
A proprietary system could also be used, but would require that
all students be able to use software from a specific vendor.
プロプライエタリシステムは、また、使用できましたが、すべての学生が特定の業者からのソフトウェアを使用できるのを必要とするでしょう。
Mahoney, et. al. Informational [Page 7] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[7ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
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を使用することでメールで送られたiTIP[RFC-2446]メッセージ[RFC-2447]の形でミーティング情報を分配できました。 クラブはミーティング招待状、および完全な発行された議題を広げることができました。
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]可能にされたカレンダーサービスへのアクセスを提供できました。 しかしながら、サーバの維持を必要とするので、この解決策は、より高価でしょう。
3.2 Systems
3.2 システム
The following diagrams illustrate possible systems and their usage of the various protocols.
以下のダイヤグラムは可能なシステムとそれらの様々なプロトコルの用法を例証します。
3.2.1 Standalone Single-user System
3.2.1 スタンドアロンシングルユーザーシステム
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
----------- / \
----------- O| CUA| -+ユーザ|地元の小売店| A----------- / \
3.2.2 Single-user Systems Communicating
3.2.2 シングルユーザーシステム交信
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]を使用できました。
Mahoney, et. al. Informational [Page 8] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[8ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
O ----------- ----------- O
-+- | CUA w/ | -----[iMIP]----- | CUA w/ | -+- user
A |local store| Internet |local store| A
/ \ ----------- ----------- / \
O----------- ----------- o+、-| CUA| -----[iMIP]----- | CUA| -+ユーザA|地元の小売店| インターネット|地元の小売店| A/\----------- ----------- / \
3.2.3 Single-user with Multiple CUAs
3.2.3 複数のCUAsをもっているシングルユーザー
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.
シングルユーザーは、その人のカレンダーにアクセスするのに1CUAを使用するかもしれません。 アクセシビリティによって、ユーザはPDA、ウェブクライアント、PC、またはある他の装置を使用するかもしれません。 何人かのこれらのクライアントが地元の小売店を持っているかもしれません、そして、他のものは持っていないかもしれません。 地元の小売店があるものは、CUAに関するデータをCSに関するデータと同期させる必要があります。
-----------
| CUA w | -----[CAP]----------+
|local store| |
O ----------- ----------
-+- | CS |
A | |
/ \ ----------
----------- |
| CUA w/o | -----[CAP]----------+
|local store|
-----------
----------- | CUA w| -----[キャップ]----------+ |地元の小売店| | O----------- ---------- -+- | Cs| A| | / \ ---------- ----------- | | CUA| -----[キャップ]----------+ |地元の小売店| -----------
3.2.4 Single-user with Multiple Calendars
3.2.4 複数のカレンダーをもっているシングルユーザー
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には、地元の小売店があるかもしれません。 そうするなら、それは、CSの両方に関するデータとCUAに関するデータを同期させる必要があります。
----------
+------------[CAP]------ | CS |
| | |
O ----------- ----------
-+- | CUA |
A | |
/ \ -----------
| ----------
+------------[CAP]------ | CS |
| |
----------
---------- +------------[キャップ]------ | Cs| | | | O----------- ---------- -+- | クーア| A| | / \ ----------- | ---------- +------------[キャップ]------ | Cs| | | ----------
Mahoney, et. al. Informational [Page 9] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[9ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
3.2.5 Users Communicating on a Multi-user System
3.2.5 マルチユーザーシステムについて話し合うユーザ
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.
マルチユーザーシステムの上のユーザは可能にされたCUAsを使用する[CAP]互いとのミーティングとサービスの計画をするかもしれません。 CUAsには、地元の小売店があるかもしれません。 地元の小売店があるものは、CUAsに関するデータをCSに関するデータと同期させる必要があります。
O -----------
-+- | CUA w | -----[CAP]----------+
A |local store| |
/ \ ----------- ----------
| CS |
| |
----------
O ----------- |
-+- | CUA w/o | -----[CAP]----------+
A |local store|
/ \ -----------
O----------- -+- | CUA w| -----[キャップ]----------+ A|地元の小売店| | / \ ----------- ---------- | Cs| | | ---------- O----------- | -+- | CUA| -----[キャップ]----------+ A|地元の小売店| / \ -----------
3.2.6 Users Communicating through Different Multi-user Systems
3.2.6 異なったマルチユーザーシステムを通って交信するユーザ
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| | |
/ \ ----------- ----------
O----------- ---------- -+- | CUA w| -----[キャップ]-------| Cs| A|地元の小売店| | | / \ ----------- ---------- | [キャップ]か[iMIP]| O----------- ---------- -+- | CUA| -----[キャップ]-------| Cs| A|地元の小売店| | | / \ ----------- ----------
4. Important Aspects
4. 重要な一面
There are a number of important aspects of these calendaring standards of which people, especially implementers, should be aware.
人々(特にimplementers)が意識しているべきである規格をcalendaringするこれらの多くの重要な一面があります。
4.1 Timezones
4.1 タイムゾーン
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
コンポーネントの日付と回は特定の時間帯について言及できます。 中央の店で時間帯を定義できますか、またはそれらは、その人の必要性に合うようにユーザによって定義されるかもしれません。 すべてのユーザとアプリケーションは時間帯と時間帯の差を知っているべきです。 新期間ゾーンはそうするかもしれません。
Mahoney, et. al. Informational [Page 10] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[10ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
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つの異なった業者が同じ時間帯について異なっ(そのようなもの同じくらい変名を使っている)て説明するかもしれません。
4.2 Choice of Transport
4.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.
ネットワーク(「ワイヤ」の)メカニズムの使用は、いくつかの組織が必要なポートの上の法人のファイアウォールを横断するために交通をcalendaringするのを許容するために条項を作るのを必要とするかもしれません。 組織文化によって、これはやりがいがある社会的な運動であるかもしれません。
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.
メールベースのメカニズムの使用は時間極秘データを限りない潜在に露出します。 大きいか大いに利用されたメールシステムはメッセージ領収書の容認できない遅れになるかもしれません。
4.3 Security
4.3 セキュリティ
See the "Security Considerations" (Section 6) section below.
下の「セキュリティ問題」(セクション6)セクションを見てください。
4.4 Amount of data
4.4 データ量
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]でアプリケーションがダウンロードできるメールの最大サイズを制限することによって、それを制御できます。
4.5 Recurring Components
4.5 再発コンポーネント
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]では、1つはVEVENTs、VTODOs、およびVJOURNALsに複雑な再発規則を指定できます。 正しくこれらの再発規則を解釈して、それらを使用することで共同利用できる存在に余分に注意を向けるのにおいて慎重であるに違いありません。
5. Open Issues
5. 未解決の問題
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.
多くの問題は現在これらのプロトコルによって解決されていません、そして、多くの望ましい特徴はまだ提供されていません。 際立ったもののいくつかが以下に概説されています。
Mahoney, et. al. Informational [Page 11] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[11ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
5.1 Scheduling People, not Calendars
5.1 カレンダーではなく、スケジューリングの人々
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.
ミーティングは人々と共に予定されています。 しかしながら、人々は、多くのカレンダーを持って、多くの場所にこれらのカレンダーを格納するかもしれません。 また、それらに連絡する多くのルートがあるかもしれません。 calendaringプロトコルは、与えられた人に連絡するためのユニークなアクセスを提供するのを試みません。 代わりに、'カレンダーアドレス'(Eメールアドレスか個々のカレンダーであるかもしれない)は、予約しています。 予約が適当な場所に行くのを保証するためにメカニズムを調整するのは、ユーザ自身次第です。
5.2 Administration
5.2 政権
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.
calendaringプロトコルはカレンダーサービスのときにユーザとカレンダーを管理する問題を記述しません。 各実現のために独占メカニズムでこれを扱わなければなりません。
5.3 Notification
5.3 通知
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.
人々はしばしば近く行われるイベント、新しいイベント、または既存のイベントへの変化について通知されたいです。 calendaringプロトコルは、リアルタイムのシステムでこれらの必要性を扱うのを試みません。 代わりに、イベントのアラーム情報を保存する能力(近く行われるイベントのクライアントサイド通知を提供するのに使用できる)を提供します。 新しいか変えられたイベントの通知を組織化するために、クライアントはデータ・ストアに投票しなければなりません。
6. Security Considerations
6. セキュリティ問題
6.1 Access Control
6.1 アクセスコントロール
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]で説明されます。
6.2 Authentication
6.2 認証
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 Authentication Security Layer(SASL)を使用します。 iMIP[RFC-2447]では、これは、認証がしばしば用意して、そして、前方に考慮であるというわけではないので、いくつかの挑戦を提示するかもしれません。プロトコル。
Mahoney, et. al. Informational [Page 12] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[12ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
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.
リアルタイムのプロトコルはユーザの認証、およびその認証情報の保存に備えます、受信エンドユーザかサーバで合法化を考慮して。
6.3 Using E-mail
6.3 メールを使用すること。
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.
少しも認証情報なしでスケジューリング情報をメールの上に伝えることができるので、受信機が認証がないかどうかチェックしていないなら、メールスプーフィングは非常に簡単です。 implementersが、認証を必要とするのが、デフォルトであるとみなすことが提案されます、iMIP[RFC2447]のセクション3で説明されるようなメカニズムを使用して。 メールの使用、および匿名の接続の可能性は、'カレンダースパム'が可能であることを意味します。 システム、特に自動化された要求処理を考慮するものを設計するとき、開発者はこの脅威を考えるべきです。
6.4 Other Issues
6.4 他の問題
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で現状を明らかにする取り組みは作られているべきです。 この1つの例が安全な接続の間に何人かのウェブブラウザで使用される'錠'アイコンです。
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.
エリックBusboom、Egen、デヴィッドMadeo、ショーン・パックウッド、ブルース・カーン、アラン・デイヴィース、ロブSurridgeを軽くたたいてください。
Mahoney, et. al. Informational [Page 13] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[13ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
References
参照
[RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification - iCalendar", RFC
2445, November 1998.
[RFC-2445] ドーソン、F.、およびD.Stenerson、「インターネットCalendaringとスケジューリングはオブジェクト仕様の芯を取ります--iCalendar」、RFC2445、11月1998日
[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] シルバーバーグ、S.、マンスール、S.、ドーソン、F.、およびR.ホプソン、「iCalendarの輸送から独立している相互運用性は(iTIP)について議定書の中で述べます」。 「イベント、繁忙期、大騒ぎ、および仕訳記入の計画をします」、RFC2446、1998年11月。
[RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
Message-Based Interoperability Protocol - iMIP", RFC 2447,
November 1998.
[RFC-2447] ドーソン、F.、マンスール、S.、およびS.シルバーバーグ、「iCalendarのメッセージベースの相互運用性は議定書を作ります--iMIP」、RFC2447、11月1998日
[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月。
[CAP] Mansour, S., Royer, D., Babics, G., and Hill, P.,
"Calendar Access Protocol (CAP)", Work in Progress.
[ふたをしています] マンスール、S.、ロワイエー、D.、Babics、G.、およびヒル、P.、「カレンダーアクセス・プロトコル(上限)」が進行中で働いています。
Mahoney, et. al. Informational [Page 14] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[14ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
Authors' Addresses
作者のアドレス
Bob Mahoney MIT E40-327 77 Massachusetts Avenue Cambridge, MA 02139 US
ケンブリッジ、ボブマホニーMIT E40-327 77MA02139米国マサチューセッツ通り
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
ジョージBabics Steltor2000皮の通りケベックH3A 2W5モントリオール(カリフォルニア)
Phone: (514) 733-8500 x4201 EMail: georgeb@steltor.com
以下に電話をしてください。 (514) 733-8500x4201 EMail: georgeb@steltor.com
Alexander Taler
アレクサンダーTaler
EMail: alex@0--0.org
メール: alex@0--0.org
Mahoney, et. al. Informational [Page 15] RFC 3283 Guide to Internet Calendaring June 2002
etマホニー、アル。 情報[15ページ]のRFC3283は2002年6月にインターネットにCalendaringを動かします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Mahoney, et. al. Informational [Page 16]
etマホニー、アル。 情報[16ページ]
一覧
スポンサーリンク
