Network Working Group                                         B. Mahoney
Request for Comments: 3283                                           MIT
Category: Informational                                        G. Babics
                                                                 Steltor
                                                                A. Taler
                                                               June 2002
        
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.

版权所有(C)互联网协会(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.

本文档描述了各种Internet日历和日程安排标准和正在进行的工作,以及它们之间的关系。其目的是为这些文档提供上下文,帮助理解它们,并可能帮助设计基于标准的日历和日程安排系统。所述标准为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
        
   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
        
   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
        
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.

日历和日程安排协议旨在帮助个人通过互联网获取日历信息和安排会议,帮助组织在互联网上提供日历信息,并为寻求在内部部署日历和日程安排解决方案的组织提供帮助。

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.

这些协议未解决的问题以及需要记住的安全问题将在本文档末尾讨论。

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]相同的术语。以下定义作为引言提供;协议规范中的定义本身应被视为规范。

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.

事件、待办事项、日记条目等的集合。日历可以是个人或资源议程的内容;它也可以是一个为更专门的需要服务的数据集合。日历是日历信息的基本存储容器。

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.

一段日历数据,如事件、待办事项或警报。有关组件的信息存储为这些组件的属性。

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.

一个日历用户(有时称为被授权人),被指定参与计划日历组件(例如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。

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).

日历协议之间的关系类似于电子邮件协议之间的关系。在这些术语中,iCalendar类似于RFC 2822,iTIP和iMIP类似于简单邮件传输协议(SMTP),CAP类似于邮局协议(POP)或互联网邮件访问协议(IMAP)。

2. Requirements
2. 要求
2.1 Fundamental Needs
2.1 基本需要

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.

需要:只用一个CUA阅读和操作自己的日历。

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.

以下协议规范满足这些要求。

- 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]消息用于调度工作流,在该工作流中,用户交换消息以组织事件和待办事项等事项。CUA在日历用户的指导下生成和解释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]是独立于传输的,并且有一个指定的传输绑定:iMIP[RFC-2447]将iTIP绑定到电子邮件。此外,[CAP]将提供iTIP[RFC-2446]的实时绑定,允许CUA在单个连接上执行日历管理和调度。

- 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]来描述各种组件,如事件和待办事项。这些消息可以执行iTIP[RFC-2446]操作,以及与日历存储相关的其他操作,如搜索、创建日历、指定日历属性和指定日历访问权限。

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节中介绍的场景,日历协议可通过以下方式使用:

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] 社交俱乐部可以以iTIP[RFC-2446]消息的形式分发会议信息,并使用iMIP[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 w/    |     -+- user
         |local store|      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]也可以使用。

          O   -----------                    -----------   O
         -+- | CUA w/    | -----[iMIP]----- | CUA w/    | -+- user
          A  |local store|     Internet     |local store|  A
         / \  -----------                    -----------  / \
        
          O   -----------                    -----------   O
         -+- | CUA w/    | -----[iMIP]----- | CUA w/    | -+- user
          A  |local store|     Internet     |local store|  A
         / \  -----------                    -----------  / \
        
3.2.3 Single-user with Multiple CUAs
3.2.3 具有多个CUA的单用户

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.

单个用户可以使用多个CUA访问其日历。根据可访问性,用户可以使用PDA、Web客户端、PC或一些其他设备。其中一些客户可能有本地商店,而其他客户可能没有。具有本地存储的用户需要将CUA上的数据与CS上的数据同步。

                -----------
               |   CUA w   | -----[CAP]----------+
               |local store|                     |
          O     -----------                    ----------
         -+-                                  |   CS     |
          A                                   |          |
         / \                                   ----------
                -----------                      |
               |  CUA w/o  | -----[CAP]----------+
               |local store|
                -----------
        
                -----------
               |   CUA w   | -----[CAP]----------+
               |local store|                     |
          O     -----------                    ----------
         -+-                                  |   CS     |
          A                                   |          |
         / \                                   ----------
                -----------                      |
               |  CUA w/o  | -----[CAP]----------+
               |local store|
                -----------
        
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可能有也可能没有本地商店。如果是,则需要将CUA的数据与两个CS上的数据同步。

                                               ----------
                     +------------[CAP]------ |   CS     |
                     |                        |          |
          O     -----------                    ----------
         -+-   |  CUA      |
          A    |           |
         / \    -----------
                     |                         ----------
                     +------------[CAP]------ |   CS     |
                                              |          |
                                               ----------
        
                                               ----------
                     +------------[CAP]------ |   CS     |
                     |                        |          |
          O     -----------                    ----------
         -+-   |  CUA      |
          A    |           |
         / \    -----------
                     |                         ----------
                     +------------[CAP]------ |   CS     |
                                              |          |
                                               ----------
        
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.

多用户系统上的用户可以使用启用[CAP]的CUA和服务彼此安排会议。CUAs可能有也可能没有本地商店。具有本地存储的用户需要将CUAs上的数据与CS上的数据同步。

          O     -----------
         -+-   |   CUA w   | -----[CAP]----------+
          A    |local store|                     |
         / \    -----------                    ----------
                                              |   CS     |
                                              |          |
                                               ----------
          O     -----------                      |
         -+-   |  CUA w/o  | -----[CAP]----------+
          A    |local store|
         / \    -----------
        
          O     -----------
         -+-   |   CUA w   | -----[CAP]----------+
          A    |local store|                     |
         / \    -----------                    ----------
                                              |   CS     |
                                              |          |
                                               ----------
          O     -----------                      |
         -+-   |  CUA w/o  | -----[CAP]----------+
          A    |local store|
         / \    -----------
        
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   | -----[CAP]-------|   CS     |
          A    |local store|                  |          |
         / \    -----------                    ----------
                                                   |
                                             [CAP] or [iMIP]
                                                   |
          O     -----------                    ----------
         -+-   |  CUA w/o  | -----[CAP]-------|   CS     |
          A    |local store|                  |          |
         / \    -----------                    ----------
        
4. Important Aspects
4. 重要方面

There are a number of important aspects of these calendaring standards of which people, especially implementers, should be aware.

人们,尤其是实施者,应该了解这些日历标准的许多重要方面。

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

组件中的日期和时间可以指特定的时区。时区可以在中央存储中定义,也可以由用户定义以满足其需求。所有用户和应用程序都应该知道时区和时区差异。可能会出现新时区

need to be added, and others removed. Two different vendors may describe the same time zone differently (such as by using a different name).

需要添加,其他需要删除。两个不同的供应商可能会对同一时区进行不同的描述(例如使用不同的名称)。

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.

使用网络(“在线”)机制可能需要一些组织做出规定,允许日历流量通过所需端口上的公司防火墙。根据组织文化的不同,这可能是一项具有挑战性的社会活动。

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]中,可以为VEVENT、VTODOs和VG日志指定复杂的重复规则。必须小心正确解释这些重复规则,并特别注意能够使用它们进行互操作。

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.

许多问题目前还没有通过这些协议解决,许多理想的特性还没有提供。下面概述了一些比较突出的问题。

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.

安排与人会面;然而,人们可能有许多日历,并且可能在许多地方存储这些日历。与他们联系的途径也可能很多。日历协议不会尝试为联系给定人员提供唯一访问权限。相反,“日历地址”被预订,可能是电子邮件地址或个人日历。由用户自己来协调机制,以确保预订到达正确的位置。

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.

日历协议不解决在日历服务上管理用户和日历的问题。这必须由每个实现的专有机制来处理。

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.

人们通常希望收到即将发生的事件、新事件或现有事件的更改的通知。日历协议并不试图在实时系统中满足这些需求。相反,提供了存储事件警报信息的功能,可用于提供即将发生的事件的客户端通知。要组织新事件或更改事件的通知,客户端必须轮询数据存储。

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]使用简单身份验证安全层(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.

实时协议提供用户身份验证,并保存该身份验证信息,允许接收最终用户或服务器进行验证。

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.

由于调度信息可以在没有任何身份验证信息的情况下通过邮件传输,因此如果接收者没有检查身份验证,则电子邮件欺骗非常容易。建议实施者认为需要认证作为默认,使用机制,如在IMIP的第3部分[RCF-2447 ]中所描述的。电子邮件的使用,以及匿名连接的可能性,意味着“日历垃圾邮件”是可能的。开发人员应该在设计系统时考虑这种威胁,特别是那些允许自动请求处理的系统。

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中的当前状态。这方面的一个例子是在安全连接期间某些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.

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 24451998年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传输独立互操作性协议(iTIP):调度事件,繁忙时间,待办事项和日志条目”,RFC 2446,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,“多用途Internet邮件扩展(MIME)-第一部分:Internet邮件正文格式”,RFC 20451996年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)”,正在进行中。

Authors' Addresses

作者地址

Bob Mahoney MIT E40-327 77 Massachusetts Avenue Cambridge, MA 02139 US

美国马萨诸塞州剑桥马萨诸塞大道77号麻省理工学院鲍勃·马奥尼E40-327 02139

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皮尔街蒙特利尔魁北克H3A 2W5加利福尼亚州

Phone: (514) 733-8500 x4201 EMail: georgeb@steltor.com

电话:(514)733-8500 x4201电子邮件:georgeb@steltor.com

Alexander Taler

亚历山大·塔勒

   EMail: alex@0--0.org
        
   EMail: alex@0--0.org
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

版权所有(C)互联网协会(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编辑功能的资金目前由互联网协会提供。