idnits 2.17.1 draft-ietf-calsch-imp-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 474 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 are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 440 looks like a reference -- Missing reference section? 'ITIP' on line 441 looks like a reference -- Missing reference section? 'IMIP' on line 443 looks like a reference -- Missing reference section? 'IRIP' on line 444 looks like a reference -- Missing reference section? 'CAP' on line 446 looks like a reference -- Missing reference section? 'RFC-2445' on line 440 looks like a reference -- Missing reference section? 'RFC-2446' on line 441 looks like a reference -- Missing reference section? 'RFC-2447' on line 443 looks like a reference -- Missing reference section? 'RFC-1847' on line 448 looks like a reference -- Missing reference section? 'RFC-2045' on line 449 looks like a reference -- Missing reference section? 'RFC-2046' on line 450 looks like a reference -- Missing reference section? 'RFC 2047' on line 451 looks like a reference -- Missing reference section? 'RFC-2048' on line 452 looks like a reference -- Missing reference section? 'RFC-2049' on line 453 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Guide to Implementors 2 Network Working Group Bob Mahoney/MIT 3 Internet-Draft Alexander Taler/CS&T 4 5 4-Oct-99 6 Expires: 8 Implementors' Guide to Internet Calendaring 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes the relationship between the various internet 35 calendaring and scheduling protocols defined by RFC 2445 (iCalendar), 36 RFC 2446 (iTIP), and RFC 2447 (iMIP), as well as the works in 37 progress,"iCalendar Real-time Interoperability Protocol" (iRIP), 38 and "Calendar Access Protocol" (CAP). It's intention is to provide 39 a context for these protocols, assist in their understanding, and 40 ultimately help implementors in the design of their internet 41 calendaring and scheduling systems. 43 This document also describes issues and problems which are not solved 44 by these protocols, and could be targets for future work. 46 Status of this Memo 47 1. Introduction 48 Terminology 49 2. Requirements 50 Fundamental Need 51 Protocol Requirements 52 3. Standards Solution 53 Examples 54 Systems 55 Standalone single-user system 56 Single-user systems communicating 57 4. Open Issues 58 Scheduling People, not calendars 59 Administration 60 Notification 61 5. Security Considerations 62 Access Control 63 Authentication 64 Using Email 65 Other issues 66 6. Acknowldegements 67 7. Bibliography 68 8. Author's Addresses 69 9. Full Copyright Statement 71 1. Introduction 73 The calendaring and scheduling protocols are intended to provide for 74 the needs of individuals attempting to obtain information and 75 schedule meetings across the internet, organizations attempting to 76 provide information on the internet, as well as organizations looking 77 for a calendaring and scheduling solution to deploy internally. 79 It is the intent of this document to provide guidance for 80 implementors of calendaring and scheduling products in determining 81 which of the various existing protocol documents are applicable to 82 their work, as well as providing some background information and 83 pointers to the less obvious implications of the available choices. 85 Problems not solved by these protocols, as well as security issues 86 to be kept in mind, are discussed at the end of the document. 88 1.1 Terminology 90 This memo uses much of the same terminology as [ICAL], [ITIP], 91 [IMIP], [IRIP] and [CAP]. The following definitions are provided as 92 introductory, the definitions in the protocol specifications are the 93 canonical ones. 95 Calendar 96 A collection of events, todos, journal entries, etc. A calendar 97 could be the content of a person's or a resource's agenda; it 98 could also be a collection of data serving a more specialized 99 need. Calendars are the basic storage containers for calendaring 100 information. 102 Calendar Access Rights 103 A set of rules for a calendar describing who may perform which 104 operations on that calendar, such as reading and writing 105 information. 107 Calendar Service 108 A running server application which provides access to a 109 collection of calendars. 111 Calendar Store 112 A data store of a calendar service. A calendar service may have 113 several calendar stores, and each store may contain several 114 calendars, as well as properties and components outside of the 115 calendars. 117 Calendar User 118 An entity (often a human) which accesses calendar information. 120 Calendar User Agent (CUA) 121 Software used by the calendar user which communicates with 122 calendar services to provide the user access to calendar 123 information. 125 Component 126 A piece of calendar data such as an event, a todo or an alarm. 127 Information about components is stored as properties of those 128 components. 130 Property 131 A property of a component, such as a description or a start time. 133 2. Requirements 135 2.1 Fundamental Needs 137 The following examples illustrate people's basic calendaring and 138 scheduling needs: 140 a] A busy musician wants to maintain her schedule on an 141 internet-based agenda which she can access from anywhere. 143 Need: Read and manipulate one's own calendar. 145 b] A software development team wishes to share agenda information 146 by using a group scheduling product in order to more effectively 147 schedule their time. 149 Need: Share calendar information with users using the same 150 calendar service. 152 c] A teacher wants his students to be able to book time slots 153 during his office hours. 155 Need: Schedule calendar events and todos with users using the 156 same calendar service. 158 d] A movie theatre wants to publish its schedule so that 159 prospective customers can easily access it. 161 Need: Share calendar information with users using other calendar 162 services, possibly from different vendors. 164 e] A social club wants to be able to organise events more 165 effectively by booking time with its members. 167 Need: Schedule calendar events and todos with users using other 168 calendar services, possibly from different vendors. 170 2.2 Protocol requirements 172 The first three needs can be satisfied through proprietary solutions, 173 but the last two cannot. From these needs we can establish that 174 protocols are required for accessing information in a calendar store, 175 and for scheduling events and todos. In addition these protocols 176 require a data format for representing calendar information. 178 These roles are filled by the following protocol requirements. 180 - [ICAL] is the data format 182 [ICAL] provides data format for representing calendar information 183 which the other protocols can use. [ICAL] can also be used in 184 other contexts such as a drag and drop format or an export/import 185 format. 187 All the other protocols depend on [ICAL], so all elements of a 188 standards-based calendaring and scheduling systems will have to 189 interpret [ICAL]. 191 - [ITIP] is the scheduling protocol 193 [ITIP] describes the messages used to schedule calendar events. 194 These messages are represented in [ICAL], and have semantics that 195 include such things as being an invitation to a meeting, an 196 acceptance of an invitation or the assignation of a task. 198 [ITIP] messages are used in the scheduling work flow, where users 199 exchange messages in order to organize things such as events and 200 todos. CUAs generate and interpret [ITIP] messages at the 201 direction of the calendar user. 203 [ITIP] is transport-independent, but has two specified transport 204 bindings, [IMIP] is a binding to email and [IRIP] is a real-time 205 binding. In addition [CAP] will provide a second real-time 206 binding of [ITIP], allowing CUAs to perform calendar management 207 as well as scheduling over a single connection. 209 Both CUAs and calendar services may have [ITIP] interpreters. 211 - [CAP] is the calendar management protocol 213 [CAP] describes the messages used to manage calendars. These 214 messages are represented in [ICAL], and have semantics such as 215 being a search for data, being data in response to a search or 216 the being the creation of a meeting. 218 [CAP] also provides a real-time binding for the calendar 219 management messages. Although other bindings, such as an email 220 binding, could be defined, this is not done because it is 221 inappropriate for this protocol. 223 The following diagram describes the implementation dependencies 224 between the protocols. A calendar system using these standards 225 will implement at least one of the leaves of the tree. The 226 calendar management message and transport protocol parts of CAP are 227 separated in the diagram to highlight its relationship to ITIP. 229 ------------------ 230 | iCalendar | 231 ------------------ 232 | 233 | 234 | 235 ------------------------------------- 236 | | 237 ------------------ | 238 | iTIP | | 239 ------------------ | 240 | | 241 | ----------|------- 242 | | CAP | | 243 | | message | 244 ---------------------------------------- format | 245 | | | | | | 246 ---------- ----------- | | | | 247 | Session | | E-mail | | transport | 248 | iRIP | | iMIP | | protocol | 249 ---------- ----------- ------------------ 251 3. Solutions 253 3.1 Examples 255 Returning to the examples of section 2.1, they can be solved using 256 the protocols in the following ways: 258 a] The musician who wishes to access her agenda from anywhere can 259 use a [CAP] enabled calendar service accessible through the 260 internet. She can then use whichever [CAP] clients are 261 available to access the data. 263 A proprietary system could also be employed which provides 264 access through a web-based interface, but the use of [CAP] would 265 be superior in that it would allow the use of third party tools, 266 such as PDA synchronization tools. 268 b] The development team can use a calendar service which supports 269 [CAP] and then each member can use a [CAP]-enabled CUA of their 270 choice. 272 Alternatively, each member could use an [IMIP]-enabled CUA, and 273 they could book meetings over email. This solution has the 274 drawback that it is difficult to examine the other agendas, 275 making organizing meetings more difficult. 277 Proprietary solutions are also available, but they require that 278 all people use clients by the same vendor, and disallow the use 279 of third party applications. 281 c] The teacher can set up a calendar service, and have students 282 book time through any of the [ITIP] bindings. [CAP] or [IRIP] 283 provide real-time access, but could require additional 284 configuration. [IMIP] would be the easiest to configure, but 285 may require more email processing. 287 If [CAP] access is provided then determining the state of the 288 teacher's schedule is straightforward. If not, this can be 289 determined through [ITIP] free-busy requests. Non-standard 290 methods could also be employed, such as serving up ICAL, HTML, 291 XML through HTTP. 293 A proprietary system could also be used, but would require that 294 all students be able to use software from a specific vendor. 296 d] For publishing a movie theatre's schedule [CAP] provides the 297 most advanced access and search capabilities. It also allows 298 easy integration with its customer's calendar systems. 300 Non-standard methods such as serving data over HTTP could also 301 be employed, but would be harder to integrate with customer's 302 systems. 304 Using a completely proprietary solutions would be very difficult 305 since it would require every user to install and use proprietary 306 software. 308 e] The social club could distribute meeting information in the form 309 of [ITIP] messages. This could be done over email using [IMIP], 310 or [IRIP] depending on the recipient. Meeting invitations, as 311 well as a full published agenda could be distributed. 313 Alternatively, the social club could provide access to a [CAP] 314 enabled calendar service, however this solution would be more 315 expensive since it requires the maintenance of a server. 317 3.2 Systems 319 The following diagrams illustrate possible example systems and usage 320 of the protocols. [ed. More coming] 322 3.2.1 Standalone single-user system 324 A single user system which does not communicate with other systems 325 need not employ any of the protocols. However, it may use [ICAL] as 326 a data format in some places. 328 ----------- O 329 | CUA w/ | -+- user 330 |local store| A 331 ----------- / \ 333 3.2.2 Single-user systems communicating 335 Users with single-user systems may schedule meetings with each other 336 using [ITIP]. The easiest binding of [ITIP] to use is [IMIP], since 337 it messages can be held in their mail queue, which we assume to 338 already exist. [IRIP] or [CAP] would require at least one user to run 339 a listening server. 341 O ----------- ----------- O 342 -+- | CUA w/ | -----[IMIP]----- | CUA w/ | -+- user 343 A |local store| Internet |local store| A 344 / \ ----------- ----------- / \ 346 4. Open Issues 348 Many issues are not currently resolved by these protocols, and many 349 desirable features are not yet provided. Some of the more prominent 350 ones follow. 352 4.1 Scheduling people, not calendars 354 Meetings are scheduled with people, however people may have many 355 calendars, and may store these calendars in many places. There may 356 also be many routes to contact them. These protocols do not attempt 357 to provide unique access for contacting a single person. Instead, 358 'calendar addresses' are booked, which may be email addresses or 359 individual calendars. It is up to the users themselves to 360 orchestrate mechanisms to ensure that the bookings go to the right 361 place. 363 4.2 Administration 365 These protocols do not address the issues of administering users and 366 calendars on a calendar service. This must be handled by proprietary 367 mechanisms for each implementation. 369 4.3 Notification 371 People often wish to be notified of upcoming events, new events, or 372 changes to events. These protocols do not attempt to address these 373 needs in a real-time fashion. Instead, the ability to store alarm 374 information on events is provided, which can be used to provide 375 client-side notification of upcoming events. To organize 376 notification of new or changed events clients will have to poll the 377 data store. 379 5. Security considerations 381 5.1 Access Control 383 There has to be reasonable granularity in the configuration options 384 for access to data through [CAP], so that what should be released to 385 requestors is, and what shouldn't isn't. Details of handling this 386 are described in [CAP]. 388 5.2 Authentication 390 Access control must be coupled with a good authentication system, so 391 that the right people get the right information. For [CAP] this 392 means requiring authentication before any data base access can be 393 performed, and checking access rights and authentication credentials 394 before releasing information. In [IMIP], this may present some 395 challenges, as authentication is often not a consideration in 396 store-and-forward protocols. 398 Authentication is also important for scheduling, in that receivers of 399 scheduling messages should be able to validate the apparent sender. 400 Since scheduling messages are wrapped in MIME, signing and encryption 401 is available for free. For messages transmitted over mail this is 402 the only available alternative. It is suggested that developers take 403 care in implementing the security features in [IMIP], bearing in 404 mind that the concept and need may be foreign or non-obvious to users, 405 yet essential for the system to function as they might expect. 407 The real-time protocols provide for the authentication of users, and 408 the preservation of that authentication information, allowing for 409 validation by the receiving end-user or server. 411 5.3 Using email 413 Because scheduling information can be transmitted over mail without 414 any authentication information, email spoofing is extremely easy if 415 the receiver is not checking for authentication. It is suggested 416 that implementors consider requiring authentication as a default, 417 using mechanisms such as are described in Section 2 of [IMIP]. 419 The use of email, and the potential for anonymous connections, means 420 that 'calendar spam' is possible. Developers should consider this 421 threat when designing systems, particularly those that allow for 422 automated request processing. 424 5.4 Other issues 426 The current security context should be obvious to users. Because the 427 underlying mechanisms may not be clear to users, efforts to make 428 clear the current state in the UI should be made. One example is the 429 'lock' icon used in some web browsers during secure connections. 431 6. Acknowledgements 433 Thanks to the following who have participated in the development of 434 this document: 436 Eric Busboom, Pat Egen, David Madeo, Shawn Packwood. 438 7. Bibliography 440 [ICAL] [RFC-2445] Calendaring and Scheduling Core Object Specification 441 [ITIP] [RFC-2446] iCalendar Transport-Independent Interoperability 442 Protocol 443 [IMIP] [RFC-2447] iCalendar Message-Based Interoperability Protocol 444 [IRIP] draft-ietf-calsch-irip iCalendar Real-time Interoperability 445 Protocol 446 [CAP] draft-ietf-calsch-cap Calendar Access Protocol 448 [RFC-1847] Security Multiparts for MIME 449 [RFC-2045] MIME Part 1: Format of Internet Message Bodies 450 [RFC-2046] MIME Part 2: Media Types 451 [RFC 2047] MIME Part 3: Message Header Extensions for Non-ASCII Text 452 [RFC-2048] MIME Part 4: Registration Procedures 453 [RFC-2049] MIME Part 5: Conformance Criteria and Examples 455 8. Author's Addresses 457 Alexander Taler 458 CS&T 459 3333 Graham Boulevard, 5th Floor 460 Montreal, QC H3R 3L5 461 Tel: (514) 733-8500 462 Email: alext@cst.ca 464 Bob Mahoney 465 MIT 466 E40-327 467 77 Massachusetts Avenue 468 Cambridge, MA 02139 469 Tel: (617) 253-0774 470 Email: bobmah@mit.edu 472 9. Full Copyright Statement