rfc3283.txt

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.

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.

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



Mahoney, et. al.             Informational                      [Page 1]

RFC 3283             Guide to Internet Calendaring             June 2002


   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

   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

   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.








Mahoney, et. al.             Informational                      [Page 2]

RFC 3283             Guide to Internet Calendaring             June 2002


   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)

      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)

      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.

   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.




Mahoney, et. al.             Informational                      [Page 3]

RFC 3283             Guide to Internet Calendaring             June 2002


   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.

   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.

   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.

1.2 Concepts and Relationships

   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.

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

2. Requirements

2.1 Fundamental Needs

   The following scenarios illustrate people and organizations' basic
   calendaring and scheduling needs:




Mahoney, et. al.             Informational                      [Page 4]

RFC 3283             Guide to Internet Calendaring             June 2002


      a] A doctor wishes to keep track of all her appointments.

      Need: To read and manipulate one's own calendar with only one CUA.

      b] A busy musician wants to maintain her schedule with multiple
      devices, such as through an Internet-based agenda and with a 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.

      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.

      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.

      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.

      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

   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.

   These requirements are met by the following protocol specifications.







Mahoney, et. al.             Informational                      [Page 5]

RFC 3283             Guide to Internet Calendaring             June 2002


      - Data format: 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].

      - Scheduling protocol: iTIP [RFC-2446]

      iTIP [RFC-2446] describes the messages used to schedule calendar
      events.  Within iTIP messages, events are represented in iCalendar