idnits 2.17.1 draft-ietf-calsch-inetcal-guide-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 570 has weird spacing: '...tion is often...' == Line 578 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.) -- The document date (July 18, 2001) is 8316 days in the past. Is this intentional? 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? 'RFC-2445' on line 645 looks like a reference -- Missing reference section? 'RFC-2446' on line 649 looks like a reference -- Missing reference section? 'RFC-2447' on line 654 looks like a reference -- Missing reference section? 'CAP' on line 662 looks like a reference -- Missing reference section? 'RFC-2045' on line 658 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Mahoney 3 Internet-Draft MIT 4 Expires: January 16, 2002 G. Babics 5 Steltor 6 A. Taler 7 July 18, 2001 9 Guide to Internet Calendaring 10 draft-ietf-calsch-inetcal-guide-01 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 16, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 This document describes the various Internet calendaring and 42 scheduling standards and works in progress and the relationships 43 between them. It's intention is to provide a context for these 44 documents, assist in their understanding, and potentially help 45 implementers in the design of their standards based calendaring and 46 scheduling systems. The standards addressed are RFC 2445 47 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in 48 progress addressed is "Calendar Access Protocol" (CAP). This 49 document also describes issues and problems that are not solved by 50 these protocols, and could be targets for future work. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2 Concepts and Relationships . . . . . . . . . . . . . . . . . 5 57 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.1 Fundamental Needs . . . . . . . . . . . . . . . . . . . . . 6 59 2.2 Protocol Requirements . . . . . . . . . . . . . . . . . . . 6 60 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.2 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.2.1 Standalone single-user system . . . . . . . . . . . . . . . 9 64 3.2.2 Single-user systems communicating . . . . . . . . . . . . . 9 65 3.2.3 Single-user with multiple CUA . . . . . . . . . . . . . . . 10 66 3.2.4 Single-user with multiple calendars . . . . . . . . . . . . 10 67 3.2.5 Users communicating on a multi-user system . . . . . . . . . 11 68 3.2.6 Users communicating through different multi-user systems . . 11 69 4. Important Aspects . . . . . . . . . . . . . . . . . . . . . 12 70 4.1 Timezones . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2 Choice of Transport . . . . . . . . . . . . . . . . . . . . 12 72 4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.4 Amount of data . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.5 Recurring Components . . . . . . . . . . . . . . . . . . . . 12 75 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14 76 5.1 Scheduling people, not calendars . . . . . . . . . . . . . . 14 77 5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . 14 78 5.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . 14 79 6. Security considerations . . . . . . . . . . . . . . . . . . 15 80 6.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . 15 81 6.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 15 82 6.3 Using email . . . . . . . . . . . . . . . . . . . . . . . . 15 83 6.4 Other issues . . . . . . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 85 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 86 B. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 18 87 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 The calendaring and scheduling protocols are intended to provide for 92 the needs of individuals attempting to obtain calendaring information 93 and schedule meetings across the Internet, organizations attempting 94 to provide calendaring information on the Internet, as well as 95 organizations looking for a calendaring and scheduling solution to 96 deploy internally. 98 It is the intent of this document to provide a context for the 99 calendar standards and works in progress, assist in their 100 understanding, and potentially help implementers in the design of 101 their Internet calendaring and scheduling systems. 103 Problems not solved by these protocols, as well as security issues to 104 be kept in mind, are discussed at the end of the document. 106 1.1 Terminology 108 This memo uses much of the same terminology as iCalendar [RFC-2445], 109 iTIP [RFC-2446], iMIP [RFC-2447], and [CAP]. The following 110 definitions are provided as introductory, the definitions in the 111 protocol specifications are the canonical ones. 113 Calendar 115 A collection of events, to-dos, journal entries, etc. A calendar 116 could be the content of a person or a resource's agenda; it could 117 also be a collection of data serving a more specialized need. 118 Calendars are the basic storage containers for calendaring 119 information. 121 Calendar Access Rights 123 A set of rules for a calendar describing who may perform which 124 operations on that calendar, such as reading and writing 125 information. 127 Calendar Service 129 A running server application which provides access to a collection 130 of calendars. 132 Calendar Store (CS) 134 A data store of a calendar service. A calendar service may have 135 several calendar stores, and each store may contain several 136 calendars, as well as properties and components outside of the 137 calendars. 139 Calendar User (CU) 141 An entity (often a human) that accesses calendar information. 143 Calendar User Agent (CUA) 145 Software used by the calendar user that communicates with calendar 146 services to provide the user access to calendar information. 148 Component 150 A piece of calendar data such as an event, a to-do or an alarm. 151 Information about components is stored as properties of those 152 components. 154 Delegator 156 Is a calendar user (sometimes called the delegatee) who has 157 assigned his or her participation in a scheduled calendar 158 component (e.g., VEVENT) to another calendar user (sometimes 159 called the delegate or delegatee). 161 Delegate 163 Is a calendar user (sometimes called the delegatee) who has been 164 assigned participation in a scheduled calendar component (e.g., 165 VEVENT) by one of the attendees in the scheduled calendar 166 component (sometimes called the delegator). An example of a 167 delegate is a team member told to go to a particular meeting. 169 Designate 171 Is a calendar user who is authorized to act on behalf of another 172 calendar user. An example of a designate is an assistant. 174 Local Store 176 A CS which is on the same platform as the CUA. 178 Property 180 A property of a component, such as a description or a start time. 182 Remote Store 184 A CS which is not on the same platform as the CUA. 186 1.2 Concepts and Relationships 188 iCalendar is the language used to describe calendar objects. iTIP is 189 a way to use the language to do scheduling. iMIP is how to do iTIP 190 with email. CAP is a way to use the language, to access a calendar 191 store in real-time. 193 The relationship between the calendaring protocols is similar to that 194 between the email protocols. In those terms iCalendar is like RFC 195 822, iTIP and iMIP are like SMTP, and CAP is like POP or IMAP. 197 2. Requirements 199 2.1 Fundamental Needs 201 The following examples illustrate people's and organizations' basic 202 calendaring and scheduling needs: 204 a] A doctor wishes to keep track of all his appointments. 206 Need: Read and manipulate one's own calendar with only one CUA. 208 b] A busy musician wants to maintain her schedule with different 209 devices, such as with an Internet-based agenda or with a PDA. 211 Need: Read and manipulate one's own calendar, possibly with 212 solutions from different vendors. 214 c] A software development team wishes to share agenda information 215 by using a group scheduling product in order to more effectively 216 schedule their time. 218 Need: Share calendar information with users using the same 219 calendar service. 221 d] A teacher wants his students to be able to schedule calendar 222 entries during his office hours. 224 Need: Schedule calendar events, to-dos and journals with users 225 using the same calendar service. 227 e] A movie theater wants to publish its schedule so that 228 prospective customers can easily access it. 230 Need: Share calendar information with users using other calendar 231 services, possibly from different vendors. 233 f] A social club wants to be able to schedule calendar entries 234 effectively with its members. 236 Need: Schedule calendar events and to-dos with users using other 237 calendar services, possibly from different vendors. 239 2.2 Protocol Requirements 241 Some of the needs can be met with proprietary solutions (a, c, d), 242 but others can not (b, e, f). From these needs we can establish that 243 protocols are required for accessing information in a calendar store, 244 and for scheduling calendar entries. In addition these protocols 245 require a data format for representing calendar information. 247 These roles are filled by the following protocol specifications. 249 - iCalendar [RFC-2445] is the data format 251 iCalendar [RFC-2445] provides data format for representing 252 calendar information which the other protocols can use. iCalendar 253 [RFC-2445] can also be used in other contexts such as a drag and 254 drop format or an export/import format. All the other protocols 255 depend on iCalendar [RFC-2445], so all elements of a standards- 256 based calendaring and scheduling systems will have to interpret 257 iCalendar [RFC-2445]. 259 - iTIP [RFC-2446] is the scheduling protocol 261 iTIP [RFC-2446] describes the messages used to schedule calendar 262 events. These messages are represented in iCalendar [RFC-2445], 263 and have semantics that include such things as being an invitation 264 to a meeting, an acceptance of an invitation or the assignment of 265 a task. 267 iTIP [RFC-2446] messages are used in the scheduling workflow, 268 where users exchange messages in order to organize things such as 269 events and to-dos. CUAs generate and interpret iTIP [RFC-2446] 270 messages at the direction of the calendar user. With iTIP [RFC- 271 2446] one can create, modify, delete, reply to, counter, and 272 decline counters to the various iCalendar [RFC-2445] components. 273 Furthermore, one can also request the free/busy time of other 274 people. 276 iTIP [RFC-2446] is transport-independent, and has one specified 277 transport bindings: iMIP [RFC-2447] is a binding to email. In 278 addition [CAP] will provide a real-time binding of iTIP [RFC- 279 2446], allowing CUAs to perform calendar management as well as 280 scheduling over a single connection. 282 - [CAP] is the calendar management protocol 284 [CAP] describes the messages used to manage calendars on a 285 calendar store. These messages use iCalendar [RFC-2445] to 286 describe various components such as events and to-dos. With these 287 messages one can do the operations in iTIP [RFC-2446] and other 288 operations relating to a calendar store, such as search, creating 289 calendars, specifying calendar properties, and being able to 290 specify access rights to one's calendars. 292 3. Solutions 294 3.1 Examples 296 Returning to the examples of section 2.1, they can be solved using 297 the protocols in the following ways: 299 a] The doctor can use a proprietary CUA with a local store, and 300 perhaps use iCalendar [RFC-2445] as a storage mechanism. This 301 would allow the doctor to easily import his store into another 302 application that supports iCalendar [RFC-2445]. 304 b] The musician who wishes to access her agenda from anywhere can 305 use a [CAP] enabled calendar service accessible through the 306 Internet. She can then use whichever [CAP] clients are available 307 to access the data. 309 A proprietary system could also be employed which provides access 310 through a web-based interface, but the use of [CAP] would be 311 superior in that it would allow the use of third party tools, such 312 as PDA synchronization tools. 314 c] The development team can use a calendar service which supports 315 [CAP] and then each member can use a [CAP]-enabled CUA of their 316 choice. 318 Alternatively, each member could use an iMIP [RFC-2447]-enabled 319 CUA, and they could book meetings over email. This solution has 320 the drawback that it is difficult to examine the other agendas, 321 making organizing meetings more difficult. 323 Proprietary solutions are also available, but they require that 324 all people use clients by the same vendor, and disallow the use of 325 third party applications. 327 d] The teacher can set up a calendar service, and have students 328 book time through any of the iTIP [RFC-2446] bindings. [CAP] 329 provides real-time access, but could require additional 330 configuration. iMIP [RFC-2447] would be the easiest to configure, 331 but may require more email processing. 333 If [CAP] access is provided then determining the state of the 334 teacher's schedule is straightforward. If not, this can be 335 determined through iTIP [RFC-2446] free/busy requests. Non- 336 standard methods could also be employed, such as serving up ICAL, 337 HTML, XML over HTTP. 339 A proprietary system could also be used, but would require that 340 all students be able to use software from a specific vendor. 342 e] For publishing a movie theater's schedule [CAP] provides the 343 most advanced access and search capabilities. It also allows easy 344 integration with its customer's calendar systems. 346 Non-standard methods such as serving data over HTTP could also be 347 employed, but would be harder to integrate with customer's 348 systems. 350 Using a completely proprietary solutions would be very difficult 351 since it would require every user to install and use proprietary 352 software. 354 f] The social club could distribute meeting information in the 355 form of iTIP [RFC-2446] messages. This could be done over email 356 using iMIP [RFC-2447]. Meeting invitations, as well as a full 357 published agenda could be distributed. 359 Alternatively, the social club could provide access to a [CAP] 360 enabled calendar service, however this solution would be more 361 expensive since it requires the maintenance of a server. 363 3.2 Systems 365 The following diagrams illustrate possible example systems and usage 366 of the protocols. 368 3.2.1 Standalone single-user system 370 A single user system that does not communicate with other systems 371 need not employ any of the protocols. However, it may use iCalendar 372 [RFC-2445] as a data format in some places. 374 ----------- O 375 | CUA w/ | -+- user 376 |local store| A 377 ----------- / \ 379 3.2.2 Single-user systems communicating 381 Users with single-user systems may schedule meetings with each other 382 using iTIP [RFC-2446]. The easiest binding of iTIP [RFC-2446] to use 383 is iMIP [RFC-2447], since since the messages can be held in their 384 mail queue, which we assume to already exist. [CAP] could also be 385 used. 387 O ----------- ----------- O 388 -+- | CUA w/ | -----[IMIP]----- | CUA w/ | -+- user 389 A |local store| Internet |local store| A 390 / \ ----------- ----------- / \ 392 3.2.3 Single-user with multiple CUA 394 A single user may use more than one CUA to access his or her 395 calendar. The user may use a PDA, a web client, a PC, or some other 396 device, depending an accessibility. Some of these clients may have 397 local stores and others may not. If they do, then they need to 398 ensure that the data on the CUA is synchronized with the data on the 399 CS. 401 ----------- 402 | CUA w | -----[CAP]----------+ 403 |local store| | 404 O ----------- ---------- 405 -+- | CS | 406 A | | 407 / \ ---------- 408 ----------- | 409 | CUA w/o | -----[CAP]----------+ 410 |local store| 411 ----------- 413 3.2.4 Single-user with multiple calendars 415 A single user may have many independent calendars. One may be work 416 related, another for personal use. The CUA may or may not have a 417 local store. If it does, then it needs to ensure that the data on 418 the CUA is synchronized with the data on both of the CS. 420 ---------- 421 +------------[CAP]------ | CS | 422 | | | 423 O ----------- ---------- 424 -+- | CUA | 425 A | | 426 / \ ----------- 427 | ---------- 428 +------------[CAP]------ | CS | 429 | | 430 ---------- 432 3.2.5 Users communicating on a multi-user system 434 Users on a multi-user system may schedule meetings with each other 435 using [CAP]-enabled CUA and service. The CUA may or may not have a 436 local store. If they do, then they need to ensure that the data on 437 the CUA is synchronized with the data on the CS. 439 O ----------- 440 -+- | CUA w | -----[CAP]----------+ 441 A |local store| | 442 / \ ----------- ---------- 443 | CS | 444 | | 445 ---------- 446 O ----------- | 447 -+- | CUA w/o | -----[CAP]----------+ 448 A |local store| 449 / \ ----------- 451 3.2.6 Users communicating through different multi-user systems 453 Users on a multi-user system may need to schedule meetings with user 454 on a different multi user system. The services can communicate using 455 [CAP] or iMIP [RFC-2447]. 457 O ----------- ---------- 458 -+- | CUA w | -----[CAP]-------| CS | 459 A |local store| | | 460 / \ ----------- ---------- 461 | 462 [CAP] or [iMIP] 463 | 464 O ----------- ---------- 465 -+- | CUA w/o | -----[CAP]-------| CS | 466 A |local store| | | 467 / \ ----------- ---------- 469 4. Important Aspects 471 There are a number of important aspects of these calendaring 472 documents of which people, especially implementers, should be aware. 474 4.1 Timezones 476 The dates and times in components can refer to time zones. These 477 time zones can be defined in some central store, or they may be 478 defined by a user to fit his or her needs. Any user and application 479 should be aware of time zones and time zone differences. New time 480 zones may be added, and others removed. Two different vendors may 481 describe the same time zone differently (such as by using a different 482 name). 484 4.2 Choice of Transport 486 There are issues to be aware of in choosing a transport mechanism. 487 The choices are a network protocol, such as CAP, or a store and 488 forward (email) solution. 490 The use of a network ("on-the-wire") mechanism may require some 491 organizations to make provisions to allow calendaring traffic to 492 traverse a corporate firewall on the required ports. Depending on 493 the organizational culture, this may be a challenging social 494 exercise. 496 The use of an email-based mechanism exposes innately time sensitive 497 data to unbounded latency. Large or heavily utilized mail systems 498 may experience an unacceptable delay in message receipt. 500 4.3 Security 502 See the "Security Considerations" (Section 6) section below. 504 4.4 Amount of data 506 In some cases a component may be very large. For instance, some 507 attachments may be very large. Some applications may be low- 508 bandwidth or be limited in the amount of data they can store. The 509 size of the data may be controlled in [CAP], by specifying maximums. 510 In iMIP [RFC-2447] it can be controlled, by restricting the maximum 511 size of the email that the application can download. 513 4.5 Recurring Components 515 In iCAL [RFC-2445] one can specify complex recurrence rules for 516 VEVENTs, VTODOs, and VJOURNALs. There is the danger that 517 applications interpret these rules differently. Thus, one must make 518 sure that one is careful with recurrence rules. 520 5. Open Issues 522 Many issues are not currently resolved by these protocols, and many 523 desirable features are not yet provided. Some of the more prominent 524 ones follow. 526 5.1 Scheduling people, not calendars 528 Meetings are scheduled with people, however people may have many 529 calendars, and may store these calendars in many places. There may 530 also be many routes to contact them. These protocols do not attempt 531 to provide unique access for contacting a single person. Instead, 532 'calendar addresses' are booked, which may be email addresses or 533 individual calendars. It is up to the users themselves to 534 orchestrate mechanisms to ensure that the bookings go to the right 535 place. 537 5.2 Administration 539 These protocols do not address the issues of administering users and 540 calendars on a calendar service. This must be handled by proprietary 541 mechanisms for each implementation. 543 5.3 Notification 545 People often wish to be notified of upcoming events, new events, or 546 changes to events. These protocols do not attempt to address these 547 needs in a real-time fashion. Instead, the ability to store alarm 548 information on events is provided, which can be used to provide 549 client-side notification of upcoming events. To organize 550 notification of new or changed events clients will have to poll the 551 data store. 553 6. Security considerations 555 6.1 Access Control 557 There has to be reasonable granularity in the configuration options 558 for access to data through [CAP], so that what should be released to 559 requesters is released, and what shouldn't isn't. Details of 560 handling this are described in [CAP]. 562 6.2 Authentication 564 Access control must be coupled with a good authentication system, so 565 that the right people get the right information. For [CAP] this 566 means requiring authentication before any database access can be 567 performed, and checking access rights and authentication credentials 568 before releasing information. [CAP] uses SASL for this 569 authentication. In iMIP [RFC-2447], this may present some 570 challenges, as authentication is often not a consideration in store- 571 and-forward protocols. 573 Authentication is also important for scheduling, in that receivers of 574 scheduling messages should be able to validate the apparent sender. 575 Since scheduling messages are wrapped in MIME [RFC-2045], signing and 576 encryption is available for free. For messages transmitted over mail 577 this is the only available alternative. It is suggested that 578 developers take care in implementing the security features in iMIP 579 [RFC-2447], bearing in mind that the concept and need may be foreign 580 or non-obvious to users, yet essential for the system to function as 581 they might expect. 583 The real-time protocols provide for the authentication of users, and 584 the preservation of that authentication information, allowing for 585 validation by the receiving end-user or server. 587 6.3 Using email 589 Because scheduling information can be transmitted over mail without 590 any authentication information, email spoofing is extremely easy if 591 the receiver is not checking for authentication. It is suggested 592 that implementers consider requiring authentication as a default, 593 using mechanisms such as are described in Section 3 of iMIP [RFC- 594 2447]. The use of email, and the potential for anonymous 595 connections, means that 'calendar spam' is possible. Developers 596 should consider this threat when designing systems, particularly 597 those that allow for automated request processing. 599 6.4 Other issues 601 The current security context should be obvious to users. Because the 602 underlying mechanisms may not be clear to users, efforts to make 603 clear the current state in the UI should be made. One example is the 604 'lock' icon used in some web browsers during secure connections. 605 With both iMIP [RFC-2447] and [CAP], the possibilities of Denial of 606 Service attacks must be considered. The ability to flood a calendar 607 system with bogus requests is likely to be exploited once these 608 systems become widely deployed, and detection and recovery methods 609 will need to be considered. 611 Authors' Addresses 613 Bob Mahoney 614 MIT 615 E40-327 616 77 Massachusetts Avenue 617 Cambridge, MA 02139 618 US 620 Phone: (617) 253-0774 621 EMail: bobmah@mit.edu 623 George Babics 624 Steltor 625 2000 Peel Street 626 Montreal, Quebec H3A 2W5 627 CA 629 Phone: (514) 733-8500 x4201 630 EMail: georgeb@steltor.com 632 Alex Taler 634 EMail: dissent@elea.dhs.org 636 Appendix A. Acknowledgments 638 Thanks to the following who have participated in the development of 639 this document: 641 Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn. 643 Appendix B. Bibliography 645 [RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring 646 and Scheduling Core Object Specification - iCalendar", RFC 2445, 647 November 1998. 649 [RFC-2446] Silverberg, S., Mansour, S., Dawson, F. and R. 650 Hopson, "iCalendar Transport-Independent Interoperability Protocol 651 (iTIP): Scheduling Events, Busy Time, To-dos and Journal Entries", 652 RFC 2446, November 1998. 654 [RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar 655 Message-Based Interoperability Protocol - iMIP", RFC 2447, 656 November 1998. 658 [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet 659 Mail Extensions (MIME) - Part One: Format of Internet Message 660 Bodies", RFC 2045, November 1996. 662 [CAP] Mansour, S., Royer, D., Babics, G., and Hill, P. "Calendar 663 Access Protocol (CAP)" draft-ietf-calsch-cap-04.txt 665 Full Copyright Statement 667 Copyright (C) The Internet Society (2001). All Rights Reserved. 669 This document and translations of it may be copied and furnished to 670 others, and derivative works that comment on or otherwise explain it 671 or assist in its implementation may be prepared, copied, published 672 and distributed, in whole or in part, without restriction of any 673 kind, provided that the above copyright notice and this paragraph are 674 included on all such copies and derivative works. However, this 675 document itself may not be modified in any way, such as by removing 676 the copyright notice or references to the Internet Society or other 677 Internet organizations, except as needed for the purpose of 678 developing Internet standards in which case the procedures for 679 copyrights defined in the Internet Standards process must be 680 followed, or as required to translate it into languages other than 681 English. 683 The limited permissions granted above are perpetual and will not be 684 revoked by the Internet Society or its successors or assigns. 686 This document and the information contained herein is provided on an 687 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 688 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 689 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 690 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 691 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 Acknowledgement 695 Funding for the RFC Editor function is currently provided by the 696 Internet Society.