idnits 2.17.1 draft-ietf-calsch-inetcal-guide-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 28 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 869: '...the Internet Standards process MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 44 has weird spacing: '...onality has b...' == Line 758 has weird spacing: '...tion is often...' == Line 771 has weird spacing: '...rs take care ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'ICAL' on line 816 looks like a reference -- Missing reference section? 'ITIP' on line 818 looks like a reference -- Missing reference section? 'IMIP' on line 820 looks like a reference -- Missing reference section? 'IRIP' on line 821 looks like a reference -- Missing reference section? 'CAP' on line 823 looks like a reference -- Missing reference section? 'RFC-2445' on line 816 looks like a reference -- Missing reference section? 'RFC-2446' on line 818 looks like a reference -- Missing reference section? 'RFC-2447' on line 820 looks like a reference -- Missing reference section? 'RFC-1847' on line 825 looks like a reference -- Missing reference section? 'RFC-2045' on line 826 looks like a reference -- Missing reference section? 'RFC-2046' on line 827 looks like a reference -- Missing reference section? 'RFC 2047' on line 828 looks like a reference -- Missing reference section? 'RFC-2048' on line 834 looks like a reference -- Missing reference section? 'RFC-2049' on line 835 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bob Mahoney/MIT 2 Internet Draft George Babics/Steltor 3 4 February 20 2001 Expires: August 20 2001 6 Guide to Internet Calendaring 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright (C) The Internet Society 2000. All Rights Reserved. 31 Abstract 33 This document describes the various internet calendaring and 34 scheduling standards and drafts and the relationships between them. 35 It's intention is to provide a context for these documents, assist 36 in their understanding, and potentially help implementors in the 37 design of their internet calendaring and scheduling systems. The 38 standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and 39 RFC 2447 (iMIP). The draft addressed is "Calendar Access Protocol" 40 (CAP). 42 [Note: in the past there has been some discussion as to whether iRIP 43 was a live effort, given that interest has waned and some 44 functionality has been moved to CAP. Its status will be discussed 45 further.] 47 This document also describes issues and problems that are not solved 48 by these protocols, and could be targets for future work. 50 Status of this Memo 52 1. Introduction 53 Terminology 54 2. Requirements 55 Fundamental Need 56 Protocol Requirements 57 3. Standards Solution 58 Examples 59 Systems 60 Standalone single-user system 61 Single-user systems communicating 62 4. Important Aspects 64 Mahoney/Babics 1 Expires August 2001 65 Draft Guide To Internet Calendaring February, 2001 67 Timezones 68 Choice of Transport 69 Security 70 Amount of data 71 Recurring Components 72 5. Open Issues 73 Choice of Transport 74 Scheduling People, not calendars 75 Administration 76 Notification 77 6. Security Considerations 78 Access Control 79 Authentication 80 Using Email 81 Other issues 82 7. Acknowledgements 83 8. Bibliography 84 9. Author's Addresses 85 10. Full Copyright Statement 87 1. Introduction 89 The calendaring and scheduling protocols are intended to provide for 90 the needs of individuals attempting to obtain calendaring 91 information and schedule meetings across the internet, organizations 92 attempting to provide calendaring information on the internet, as 93 well as organizations looking for a calendaring and scheduling 94 solution to deploy internally. 96 It is the intent of this document is to provide a context for the 97 calendar standard and draft documents, assist in their 98 understanding, and potentially help implementors in the design of 99 their internet calendaring and scheduling systems. 101 Problems not solved by these protocols, as well as security issues 102 to be kept in mind, are discussed at the end of the document. 104 1.1 Terminology 106 This memo uses much of the same terminology as [ICAL], [ITIP], 107 [IMIP], [IRIP] and [CAP]. The following definitions are provided as 108 introductory, the definitions in the protocol specifications are the 109 canonical ones. 111 Calendar 112 A collection of events, todos, journal entries, etc. A 113 calendar could be the content of a person or a resource's 114 agenda; it could also be a collection of data serving a more 115 specialized need. Calendars are the basic storage containers 116 for calendaring information. 118 Calendar Access Rights 119 A set of rules for a calendar describing who may perform 120 which operations on that calendar, such as reading and 121 writing information. 123 Calendar Service 124 A running server application which provides access to a 125 collection of calendars. 127 Calendar Store 128 A data store of a calendar service. A calendar service may 130 Mahoney/Babics 2 Expires August 2001 131 Draft Guide To Internet Calendaring February, 2001 133 have several calendar stores, and each store may contain 134 several calendars, as well as properties and components 135 outside of the calendars. 137 Calendar User 138 An entity (often a human) that accesses calendar 139 information. 141 Calendar User Agent (CUA) 142 Software used by the calendar user that communicates with 143 calendar services to provide the user access to calendar 144 information. 146 Component 147 A piece of calendar data such as an event, a todo or an 148 alarm. Information about components is stored as properties 149 of those components. 151 Delegate 152 Is a calendar user (sometimes called the delegatee) who has 153 been assigned participation in a scheduled calendar 154 component (e.g., VEVENT) by one of the attendees in the 155 scheduled calendar component (sometimes called the 156 delegator). An example of a delegate is a team member told 157 to go to a particular meeting. 159 Designate 160 Is a calendar user who is authorized to act on behalf of 161 another calendar user. An example of a designate is an 162 assistant. 164 Local Store 165 A CS which is on the same platform as the CUA. 167 Property 168 A property of a component, such as a description or a start 169 time. 171 Remote Store 172 A CS which is not on the same platform as the CUA. 174 1.2 Concepts and Relationships 176 iCalendar is the Language to be used in calendar events. 177 iTIP is how you use the language. 178 iMIP is further definition for use over email. 179 iRIP is the language used over a real-time transport 180 CAP is how to use the language, in real-time, to access a 181 calendar server 183 Another way to put it is as follows: 184 iCalendar are the words 185 iTIP is the grammar book or the "Rosetta Stone". 186 iMIP is "expressing it in email terminology" an 187 EMAIL dictionary 188 CAP/iRIP is "expressing it for use in a Real Time transport" 190 A comparison with email: 191 RFC822 in email: iRIP in Calendaring (scheduling not 192 booking) 193 POP/IMAP in email: CAP in calendaring 194 iMIP uses RFC822 196 Mahoney/Babics 3 Expires August 2001 197 Draft Guide To Internet Calendaring February, 2001 199 RFC822 is a wrapper for email: iTIP is a wrapper for 200 calendaring objects 202 2. Requirements 204 2.1 Fundamental Needs 206 The following examples illustrate people's and 207 organizations' basic calendaring and scheduling needs: 209 a] A doctor wishes to keep track of all his appointments. 211 Need: Read and manipulate one's own calendar with only one 212 CUA. 214 b] A busy musician wants to maintain her schedule on an 215 internet-based agenda which she can access from anywhere. 217 Need: Read and manipulate one's own calendar. 219 c] A software development team wishes to share agenda 220 information by using a group scheduling product in order 221 to more effectively schedule their time. 223 Need: Share calendar information with users using the same 224 calendar service. 226 d] A teacher wants his students to be able to book time 227 slot during his office hours. 229 Need: Schedule calendar events and todos with users using 230 the same calendar service. 232 e] A movie theatre wants to publish its schedule so that 233 prospective customers can easily access it. 235 Need: Share calendar information with users using other 236 calendar services, possibly from different vendors. 238 f] A social club wants to be able to organize events more 239 effectively by booking time with its members. 241 Need: Schedule calendar events and todos with users using 242 other calendar services, possibly from different vendors. 244 2.2 Protocol requirements 246 The first four needs can be satisfied through proprietary solutions, 247 but the last two cannot. From these needs we can establish that 248 protocols are required for accessing information in a calendar 249 store, and for scheduling events and todos. In addition these 250 protocols require a data format for representing calendar 251 information. 253 These roles are filled by the following protocol requirements. 255 - [ICAL] is the data format 257 [ICAL] provides data format for representing calendar 258 information which the other protocols can use. [ICAL] can 260 Mahoney/Babics 4 Expires August 2001 261 Draft Guide To Internet Calendaring February, 2001 263 also be used in other contexts such as a drag and drop 264 format or an export/import format. 266 All the other protocols depend on [ICAL], so all elements 267 of a standards-based calendaring and scheduling systems 268 will have to interpret [ICAL]. 270 For example the following describes an event: 272 BEGIN:VCALENDAR 273 VERSION:2.0 274 PRODID:-//ABC Corporation//NONSGML My Product//EN 275 BEGIN:VEVENT 276 ORGANIZER;CN=Jane Doe:MAILTO:jane@bar.com 277 DTSTART:20000905T120000Z 278 SUMMARY:Lunch 279 DTEND:20000905T130000Z 280 ATTENDEE;CN=John Smith:MAILTO:john@foo.com 281 ATTENDEE;CN=Jane Doe:MAILTO:doe@bar.com 282 END:VEVENT 283 END:VCALENDAR 285 - [ITIP] is the scheduling protocol 287 [ITIP] describes the messages used to schedule calendar 288 events. These messages are represented in [ICAL], and 289 have semantics that include such things as being an 290 invitation to a meeting, an acceptance of an invitation 291 or the assignation of a task. 293 [ITIP] messages are used in the scheduling work flow, 294 where users exchange messages in order to organize things 295 such as events and todos. CUAs generate and interpret 296 [ITIP] messages at the direction of the calendar user. 298 With [ITIP] one can create, modify, delete, reply to, 299 counter, and decline counters to, the various [ICAL] 300 components. Furthermore, one can also request the 301 freebusy time of other people. 303 For example, to invite a user to the above event, one can 304 send a message like this one: 306 BEGIN:VCALENDAR 307 METHOD:REQUEST 308 VERSION:2.0 309 PRODID:-//ABC Corporation//NONSGML My Product//EN 310 BEGIN:VEVENT 311 ORGANIZER;CN=Jane Doe:MAILTO:jane@bar.com 312 DTSTART:20000905T120000Z 313 SUMMARY:Lunch 314 DTEND:20000905T130000Z 315 ATTENDEE;CN=John Smith:MAILTO:john@foo.com 316 ATTENDEE;CN=Jane Doe:MAILTO:doe@bar.com 317 END:VEVENT 318 END:VCALENDAR 320 The user, John Smith, can send a reply using the 321 REPLY method. 323 Mahoney/Babics 5 Expires August 2001 324 Draft Guide To Internet Calendaring February, 2001 326 [ITIP] is transport-independent, but has two specified 327 transport bindings, [IMIP] is a binding to email and 328 [IRIP] is a real-time binding. In addition [CAP] will 329 provide a second real-time binding of [ITIP], allowing 330 CUAs to perform calendar management as well as scheduling 331 over a single connection. 333 For example, sending the above request using iMIP would 334 look like: 336 From: jane@bar.com 337 To: john@foo.com 338 Subject: Lunch 339 Mime-Version: 1.0 340 Content-Type:text/calendar; method=REQUEST;charset=US-ASCII 341 Content-Transfer-Encoding: 7bit 343 BEGIN:VCALENDAR 344 VERSION:2.0 345 PRODID:-//ABC Corporation//NONSGML My Product//EN 346 BEGIN:VEVENT 347 ORGANIZER;CN=Jane Doe:MAILTO:jane@bar.com 348 DTSTART:20000905T120000Z 349 SUMMARY:Lunch 350 DTEND:20000905T130000Z 351 ATTENDEE;CN=John Smith:MAILTO:john@foo.com 352 ATTENDEE;CN=Jane Doe:MAILTO:doe@bar.com 353 END:VEVENT 354 END:VCALENDAR 356 Both CUAs and calendar services may have [ITIP] 357 interpreters. 359 - [CAP] is the calendar management protocol 361 [CAP] describes the messages used to manage calendars. These 362 messages are represented in [ICAL], and have semantics such as 363 being a search for data, being data in response to a search or 364 the being the creation of a meeting. 366 [CAP] describes the messages used to manage calendars on a 367 calendar store. 369 These messages are represented in [ICAL]. With these messages 370 one can do the operations in [ITIP] and other operations 371 relating to a calendar store. These operations include, 372 search, creating calendars, specifying calendar properties, 373 and being able to specify access rights to one's calendars. 375 [CAP] also provides a real-time binding for the calendar 376 management messages. Although other bindings, such as an email 377 binding, could be defined, this is not done because it is 378 inappropriate for this protocol. 380 For example, one can schedule the above meeting using CAP: 382 C:SENDATA 383 C:CONTENT-TYPE:text/calendar;method=CREATE;charset=US-ASCII 384 C:content-transfer-encoding: 7bit 385 C:BEGIN:VCALENDAR 386 C:VERSION:2.0 388 Mahoney/Babics 6 Expires August 2001 389 Draft Guide To Internet Calendaring February, 2001 391 C:PRODID:-//ABC Corporation//NONSGML My Product//EN 392 C:TARGET:cap://cal.example.com/johns 393 C:TARGET:janed 394 C:METHOD:CREATE 395 C:BEGIN:VEVENT 396 C:ORGANIZER;CN=Jane Doe:MAILTO:jane@bar.com 397 C:DTSTART:20000905T073000Z 398 C:SUMMARY:Lunch 399 C:DTEND:20000905T120000Z 400 C:END:VEVENT 401 C:END:VCALENDAR 402 C: . 403 S: 2.0 404 S: Content-Type:text/calendar; method=RESPONSE; 405 S: 406 S: BEGIN:VCALENDAR 407 S: VERSION:2.1 408 S: METHOD:RESPONSE 409 S: BEGIN:VEVENT 410 S: TARGET::cap://cal.example.com/johnd 411 S: REQUEST-STATUS:2.0 412 S: END:VEVENT 413 S: END:VCALENDAR 414 S: Content-Type:text/calendar; method=RESPONSE; 415 S: 416 S: BEGIN:VCALENDAR 417 S: VERSION:2.1 418 S: METHOD:RESPONSE 419 S: BEGIN:VEVENT 420 S: TARGET::cap://cal.example.com/janed 421 S: REQUEST-STATUS:2.0 422 S: END:VEVENT 423 S: END:VCALENDAR 424 S: . 426 Note that "C" indicates the data sent by the client, 427 and "S" the data sent by the server. Furthermore, CAP 428 is still a draft, thus the details of one can create 429 such an event may change. 431 The dependencies between the different protocols are as follows: 433 iCalendar is the language set used to describe/specify 434 calendaring events or operations. 436 When specified using correct iCalendar grammar, we refer to these 437 event representations or operation requests as " calendar object 438 representations 440 There are two main methodologies for communicating iCalendar 441 objects: 443 1) Via a store-and-forward mechanism (usually email), using the 444 iMIP specification. 446 2) Via an on-the-wire mechanism (a directly connected state, 447 however briefly), using the CAP specification. 449 A system may implement the first methodology only. The second one 450 is dependent on iTIP. It requires understanding of iTIP and the 451 ability to communicate with other CAP servers using iTIP. Since, 452 currently, iMIP is the only binding of iTIP, the second method 454 Mahoney/Babics 7 Expires August 2001 455 Draft Guide To Internet Calendaring February, 2001 457 is also dependent on iMIP. 459 Additionally, the iTIP specification describes a 460 transport-independent grammar for communicating between systems. 461 The iMIP specification utilizes iTIP to express iCalendar 462 objects. 464 3. Solutions 466 3.1 Examples 468 Returning to the examples of section 2.1, they can be solved 469 using the protocols in the following ways: 471 a] The doctor can use a proprietary CUA with a local store, 472 and perhaps use [ICAL] as a storage mechanism. This would 473 allow the doctor to easily import his store into another 474 application that supports [ICAL]. 476 b] The musician who wishes to access her agenda from anywhere 477 can use a [CAP] enabled calendar service accessible through 478 the internet. She can then use whichever [CAP] clients are 479 available to access the data. 481 A proprietary system could also be employed which provides 482 access through a web-based interface, but the use of [CAP] 483 would be superior in that it would allow the use of third 484 party tools, such as PDA synchronization tools. 486 c] The development team can use a calendar service which 487 supports [CAP] and then each member can use a [CAP]-enabled 488 CUA of their choice. 490 Alternatively, each member could use an [IMIP]-enabled CUA, 491 and they could book meetings over email. This solution has 492 the drawback that it is difficult to examine the other 493 agendas, making organizing meetings more difficult. 495 Proprietary solutions are also available, but they require 496 that all people use clients by the same vendor, and 497 disallow the use of third party applications. 499 d] The teacher can set up a calendar service, and have 500 students book time through any of the [ITIP] bindings. 501 [CAP] or [IRIP] provide real-time access, but could require 502 additional configuration. [IMIP] would be the easiest to 503 configure, but may require more email processing. 505 If [CAP] access is provided then determining the state of 506 the teacher's schedule is straightforward. If not, this can 507 be determined through [ITIP] free-busy requests. Non- 508 standard methods could also be employed, such as serving up 509 ICAL, HTML, XML through HTTP. 511 A proprietary system could also be used, but would require 512 that all students be able to use software from a specific 513 vendor. 515 e] For publishing a movie theatre's schedule [CAP] provides 516 the most advanced access and search capabilities. It also 517 allows easy integration with its customer's calendar 519 Mahoney/Babics 8 Expires August 2001 520 Draft Guide To Internet Calendaring February, 2001 522 systems. 524 Non-standard methods such as serving data over HTTP could 525 also be employed, but would be harder to integrate with 526 customer's systems. 528 Using a completely proprietary solutions would be very 529 difficult since it would require every user to install and 530 use proprietary software. 532 f] The social club could distribute meeting information in the 533 form of [ITIP] messages. This could be done over email 534 using [IMIP], or [IRIP] depending on the recipient. Meeting 535 invitations, as well as a full published agenda could be 536 distributed. 538 Alternatively, the social club could provide access to a 539 [CAP] enabled calendar service, however this solution would 540 be more expensive since it requires the maintenance of a 541 server. 543 3.2 Systems 545 The following diagrams illustrate possible example systems and 546 usage of the protocols. 548 3.2.1 Standalone single-user system 550 A single user system that does not communicate with other systems 551 need not employ any of the protocols. However, it may use [ICAL] as 552 a data format in some places. 554 ----------- O 555 | CUA w/ | -+- user 556 |local store| A 557 ----------- / \ 559 3.2.2 Single-user systems communicating 561 Users with single-user systems may schedule meetings with each other 562 using [ITIP]. The easiest binding of [ITIP] to use is [IMIP], since 563 it messages can be held in their mail queue, which we assume to 564 already exist. [IRIP] or [CAP] would require at least one user to 565 run a listening server. 567 O ----------- ----------- O 568 -+- | CUA w/ | -----[IMIP]----- | CUA w/ | -+- user 569 A |local store| Internet |local store| A 570 / \ ----------- ----------- / \ 572 3.2.3 Single-user with multiple CUA 574 A single user may use more than one CUA to access his or her 575 calendar. The user may use a PDA, a web client, a PC, or some other 576 device, depending an accessibility. Some of these clients may have 577 local stores and others may not. If they do, then they need to 578 ensure that the data on the CUA is synchronized with the data on the 579 CS. 581 Mahoney/Babics 9 Expires August 2001 582 Draft Guide To Internet Calendaring February, 2001 584 ----------- 585 | CUA w | -----[CAP]----------+ 586 |local store| | 587 O ----------- ---------- 588 -+- | CS | 589 A | | 590 / \ ---------- 591 ----------- | 592 | CUA w/o | -----[CAP]----------+ 593 |local store| 594 ----------- 596 3.2.4 Single-user with multiple calendars 598 A single user may have many independent calendars. One may be work 599 related, another for personal use. The CUA may or may not have a 600 local store. If it does, then it needs to ensure that the data on 601 the CUA is synchronized with the data on both of the CS. 603 ---------- 604 +------------[CAP]------ | CS | 605 | | | 606 O ----------- ---------- 607 -+- | CUA | 608 A | | 609 / \ ----------- 610 | ---------- 611 +------------[CAP]------ | CS | 612 | | 613 ---------- 615 3.2.5 Users communicating on a multi-user system 617 Users on a multi-user system may schedule meetings with each other 618 using [CAP]-enabled CUA and service. The CUA may or may not have a 619 local store. If they do, then they need to ensure that the data on 620 the CUA is synchronized with the data on the CS. 622 O ----------- 623 -+- | CUA w | -----[CAP]----------+ 624 A |local store| | 625 / \ ----------- ---------- 626 | CS | 627 | | 628 ---------- 629 O ----------- | 630 -+- | CUA w/o | -----[CAP]----------+ 631 A |local store| 632 / \ ----------- 634 3.2.6 Users communicating through different multi-user systems 636 Users on a multi-user system may need to schedule meetings with user 637 on a different multi user system. The services can communicate 638 using [CAP] or [ITIP]. 640 Mahoney/Babics 10 Expires August 641 2001 642 Draft Guide To Internet Calendaring February, 2001 644 O ----------- ---------- 645 -+- | CUA w | -----[CAP]-------| CS | 646 A |local store| | | 647 / \ ----------- ---------- 648 | 649 [CAP] 650 | 651 O ----------- ---------- 652 -+- | CUA w/o | -----[CAP]-------| CS | 653 A |local store| | | 654 / \ ----------- ---------- 656 4. Important Aspects 658 There are a number of important aspects of these calendaring 659 documents that people, especially implementors, should be aware of. 661 4.1 Timezones 663 The dates and times in components can refer to timezones. These 664 timezones can be defined in some central store, or they may be 665 defined by a user to fit his or her needs. Any user and application 666 should be aware of timezones and timezone differences. 668 4.2 Choice of Transport 670 There are issues to be aware of in choosing a transport mechanism. 671 The choices are a network protocol, such as CAP, or a store and 672 forward (email) solution. 674 The use of a network ("on-the-wire") mechanism may require some 675 organizations to make provisions to allow calendaring traffic to 676 traverse a corporate firewall on the required ports. Depending on 677 the organizational culture, this may be a challenging social 678 exercise. 680 The use of an email-based mechanism exposes innately time-sensitive 681 data to unbounded latency. Large or heavily utilized mail systems 682 may experience an unacceptable delay in message receipt. 684 4.3 Security 686 See the "Security Considerations" section below. 688 4.4 Amount of data 690 In some cases a component may be very large. For instance, some 691 attachments may be very large. Some applications may be low- 692 bandwidth or be limited in the amount of data they can store. The 693 size of the data may be controlled in [CAP], by specifying maximums. 694 In [iMIP] it can be controlled, by restricting the maximum size of 695 the email that the application can download. 697 4.5 Recurring Components 699 Mahoney/Babics 11 Expires August 700 2001 701 Draft Guide To Internet Calendaring February, 2001 703 In [iCAL] one can specify complex recurrence rules for VEVENTs, 704 VTODOs, and VJOURNALs. There is the danger that applications 705 interpret these rules differently. Thus, one must make sure that one 706 is careful with recurrence rules. 708 5. Open Issues 710 Many issues are not currently resolved by these protocols, and many 711 desirable features are not yet provided. Some of the more prominent 712 ones follow. 714 5.1 Scheduling people, not calendars 716 Meetings are scheduled with people, however people may have many 717 calendars, and may store these calendars in many places. There may 718 also be many routes to contact them. These protocols do not attempt 719 to provide unique access for contacting a single person. Instead, 720 'calendar addresses' are booked, which may be email addresses or 721 individual calendars. It is up to the users themselves to 722 orchestrate mechanisms to ensure that the bookings go to the right 723 place. 725 5.2 Administration 727 These protocols do not address the issues of administering users and 728 calendars on a calendar service. This must be handled by proprietary 729 mechanisms for each implementation. 731 5.3 Notification 733 People often wish to be notified of upcoming events, new events, or 734 changes to events. These protocols do not attempt to address these 735 needs in a real-time fashion. Instead, the ability to store alarm 736 information on events is provided, which can be used to provide 737 client-side notification of upcoming events. To organize 738 notification of new or changed events clients will have to poll the 739 data store. 741 6. Security considerations 743 6.1 Access Control 745 There has to be reasonable granularity in the configuration options 746 for access to data through [CAP], so that what should be released to 747 requestors is, and what shouldn't isn't. Details of handling this 748 are described in [CAP]. 750 6.2 Authentication 752 Access control must be coupled with a good authentication system, so 753 that the right people get the right information. For [CAP] this 754 means requiring authentication before any data base access can be 755 performed, and checking access rights and authentication credentials 756 before releasing information. [CAP] uses SASL for this 757 authentication. In [IMIP], this may present some challenges, as 758 authentication is often not a consideration in store-and-forward 759 protocols. 761 Authentication is also important for scheduling, in that receivers 762 of scheduling messages should be able to validate the apparent 764 Mahoney/Babics 12 Expires August 765 2001 766 Draft Guide To Internet Calendaring February, 2001 768 sender. Since scheduling messages are wrapped in MIME, signing and 769 encryption is available for free. For messages transmitted over mail 770 this is the only available alternative. It is suggested that 771 developers take care in implementing the security features in 772 [IMIP], bearing in mind that the concept and need may be foreign or 773 non-obvious to users, yet essential for the system to function as 774 they might expect. 776 The real-time protocols provide for the authentication of users, and 777 the preservation of that authentication information, allowing for 778 validation by the receiving end-user or server. 780 6.3 Using email 782 Because scheduling information can be transmitted over mail without 783 any authentication information, email spoofing is extremely easy if 784 the receiver is not checking for authentication. It is suggested 785 that implementors consider requiring authentication as a default, 786 using mechanisms such as are described in Section 2 of [IMIP]. 788 The use of email, and the potential for anonymous connections, means 789 that 'calendar spam' is possible. Developers should consider this 790 threat when designing systems, particularly those that allow for 791 automated request processing. 793 6.4 Other issues 795 The current security context should be obvious to users. Because the 796 underlying mechanisms may not be clear to users, efforts to make 797 clear the current state in the UI should be made. One example is the 798 'lock' icon used in some web browsers during secure connections. 800 With both [IMIP] and [CAP], the possibilities of Denial of Service 801 attacks must be considered. The ability to flood a calendar system 802 with bogus requests is likely to be exploited once these systems 803 become widely deployed, and detection and recovery methods will need 804 to be considered. 806 7. Acknowledgements 808 Thanks to the following who have participated in the development of 809 this document: 811 Eric Busboom, Alex Taler, Pat Egen, David Madeo, Shawn Packwood, 812 Bruce Kahn. 814 8. Bibliography 816 [ICAL] [RFC-2445] Calendaring and Scheduling Core Object 817 Specification 818 [ITIP] [RFC-2446] iCalendar Transport-Independent Interoperability 819 Protocol 820 [IMIP] [RFC-2447] iCalendar Message-Based Interoperability Protocol 821 [IRIP] draft-ietf-calsch-irip iCalendar Real-time Interoperability 822 Protocol 823 [CAP] draft-ietf-calsch-cap Calendar Access Protocol 825 [RFC-1847] Security Multiparts for MIME 826 [RFC-2045] MIME Part 1: Format of Internet Message Bodies 827 [RFC-2046] MIME Part 2: Media Types 828 [RFC 2047] MIME Part 3: Message Header Extensions for Non-ASCII Text 830 Mahoney/Babics 13 Expires August 831 2001 832 Draft Guide To Internet Calendaring February, 2001 834 [RFC-2048] MIME Part 4: Registration Procedures 835 [RFC-2049] MIME Part 5: Conformance Criteria and Examples 837 9. Author's Addresses 839 Bob Mahoney 840 MIT 841 E40-327 842 77 Massachusetts Avenue 843 Cambridge, MA 02139 844 Tel: (617) 253-0774 845 Email: bobmah@mit.edu 847 George Babics 848 Steltor (formerly CS&T/Lexacom) 849 2000 Peel Street 850 Montreal, Quebec, Canada 851 H3A 2W5 852 Tel: (514) 733-8500 x4201 853 Fax: (514) 733-8878 854 mailto: georgeb@steltor.co m 856 10. Full Copyright Statement 858 "Copyright (C) The Internet Society (2000). All Rights Reserved. 859 This document and translations of it may be copied and furnished to 860 others, and derivative works that comment on or otherwise explain it 861 or assist in its implementation may be prepared, copied, published 862 and distributed, in whole or in part, without restriction of any 863 kind, provided that the above copyright notice and this paragraph 864 are included on all such copies and derivative works. However, this 865 document itself may not be modified in any way, such as by removing 866 the copyright notice or references to the Internet Society or other 867 Internet organizations, except as needed for the purpose of 868 developing Internet standards in which case the procedures for 869 copyrights defined in the Internet Standards process MUST be 870 followed, or as required to translate it into languages other than 871 English. 873 The limited permissions granted above are perpetual and will not be 874 revoked by the Internet Society or its successors or assigns. This 875 document and the information contained herein is provided on an "AS 876 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 877 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 878 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 879 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 880 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 882 Mahoney/Babics 14 Expires August 883 2001