rfc3283.txt

RFC 的详细文档！

   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.

5. Open Issues

   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


5.1 Scheduling People, not Calendars

   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

   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

   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.1 Access Control

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

6.2 Authentication

   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.





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


   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.

   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

   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.

6.4 Other Issues

   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.

   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.

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.




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


References

   [RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring and
              Scheduling Core Object Specification - iCalendar", RFC
              2445, November 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-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
              Message-Based Interoperability Protocol - iMIP", RFC 2447,
              November 1998.

   [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) - Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [CAP]      Mansour, S., Royer, D., Babics, G., and Hill, P.,
              "Calendar Access Protocol (CAP)", Work in Progress.






























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


Authors' Addresses

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

   Phone: [phone]
   EMail: [e-mail]


   George Babics
   Steltor
   2000 Peel Street
   Montreal, Quebec  H3A 2W5
   CA

   Phone: [phone] x4201
   EMail: [e-mail]


   Alexander Taler

   EMail: [e-mail]

























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


Full Copyright Statement

   Copyright (C) The Internet Society (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.

   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.



















Mahoney, et. al.             Informational                     [Page 16]