idnits 2.17.1 draft-ietf-calsch-mod-03.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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-calsch-mod-03', but the file name used is 'draft-ietf-calsch-mod-03' == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 59 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 367 has weird spacing: '...journal fre...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Category: INTERNET DRAFT', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- 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: 'RFC- 2045' is mentioned on line 143, but not defined Unexpected reference format, failed extracting the RFC number: RFC- 2045 == Missing Reference: 'RFC821' is mentioned on line 245, but not defined ** Obsolete undefined reference: RFC 821 (Obsoleted by RFC 2821) == Missing Reference: 'RFC822' is mentioned on line 245, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Unused Reference: 'RFC-1983' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC-2026' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC-2045' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 640, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1983 ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) -- Possible downref: Non-RFC (?) normative reference: ref. 'CAP' Summary: 15 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Noerenberg 2 ietf-draft-calsch-mod-03.txt Qualcomm, Inc 3 Category: INTERNET DRAFT Expires: May 1998 5 Internet Calendar Model Specification 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, and 11 its working groups. Note that other groups may also distribute working 12 documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months. 15 Internet-Drafts may be updated, replaced, or made obsolete by other 16 documents at any time. It is not appropriate to use Internet-Drafts as 17 reference material or to cite them other than as a "working draft" or 18 "work in progress". 20 To learn the current status of any Internet-Draft, please check the 21 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 23 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 Distribution of this document is unlimited. 27 Abstract 29 Internet Calendaring and Scheduling protocols require the definition of 30 objects to encapsulate an event to be scheduled, a calendar on which 31 the event will be stored, and means for exchanging these objects across 32 the Internet between calendars on behalf of people for whom the 33 calendars are meaningful. This document gives an abstract model of the 34 objects and the protocols necessary to accomplish this kind of 35 information exchange. It will establish the context in which other 36 Calendaring and Scheduling RFCs can be interpreted. Included are brief 37 introductions to the other components of Internet calendar protocols 38 and definitions of nomenclature common to all documents defining these 39 protocols. Reading this document will enable implementors and users of 40 Internet Calendaring and Scheduling protocols to understand the goals 41 and constraints chosen for related protocols. 43 Table of Contents 45 1. Document framework 3 46 1.1 Model Specification 3 47 1.2 iCalendar: Core Object Specification 3 48 1.3 iTIP: Transport Independent Interoperability Protocol 4 49 1.4 iRIP: Binding of iTIP to a session protocol 4 50 1.5 iMIP: Binding of iTIP to E-mail 4 51 1.6 CAP: Calendar Access Protocol Specification 4 52 2. Abstract Model 5 53 3. Principal Model Components 6 54 3.1 Calendar User 7 55 3.2 Calendar 7 56 3.3 Calendar User Agent (CUA) 9 57 3.4 Calendar Service 9 58 3.5 Calendar Domain 9 59 3.6 Calendar Access Protocol (CAP) 9 60 3.7 Transport Independent Interoperability Protocol (iTIP) 10 61 4. Calendar Object Transport 10 62 4.1 Direct Access 12 63 4.2 Calendar Service Mediation 12 64 4.3 Interdomain Exchange 13 65 4.4 Node-Foreign Domain Exchange 13 66 5. Security considerations 13 67 6. Copyright 14 68 7. References 14 69 8. Acknowledgments 15 70 9. Author's address 15 71 10. Appendix -- Calendar protocol nomenclature 16 72 Introduction 74 The Internet Calendar Model specification provides a framework for the 75 set of protocols that define Calendaring and Scheduling for the 76 Internet. The protocols specify the contents of calendars, and how the 77 objects stored on calendars are represented during transmission across 78 the Internet. These protocols also define the interaction between a 79 calendar user agent and a calendar store, as well as the actions 80 performed by calendar transfer agents that facilitate communication 81 between calendar stores. These terms will be defined more precisely in 82 the section on nomenclature below. The protocols are the: 84 "Core Object Specification" [iCalendar] 85 "iCalendar Interoperability Protocol" [iTIP] 86 "Calendar Access Protocol" [CAP] 88 1. Document framework 90 Calendar and Scheduling Protocols are contained in a series of related 91 documents. This section describes the relationship between the 92 documents. Section 2 presents the abstract model for Internet 93 Calendaring and Scheduling. 95 Following sections amplify the principal concepts defined in the 96 abstract model, provide a schematic representation of information flow 97 in Internet Calendaring and Scheduling, and supply other, useful 98 background information. 100 1.1 Model Specification 102 This document - see abstract and introduction above. 104 1.2 iCalendar: Core Object Specification 106 The Core Object Specification is the dictionary for Internet 107 Calendaring and Scheduling protocols. It provides the authoritative 108 definition of all properties that may be used in the Internet Calendar 109 and Scheduling protocols as well as the rules for encoding and 110 representing the objects that are constructed from those properties. 111 iCalendar also specifies the method to be used to define new 112 properties. 114 Because it is a reference, some readers will find it easier to read the 115 transport protocols first, and use iCalendar to learn details of the 116 objects transmitted by the transport protocols. If any discrepencies 117 exist between the use of properties in iCalendar and other Calendaring 118 and Scheduling protocols, iCalendar's definition always takes 119 precedence. 121 The properties of a calendar object can be thought of as attributes. 122 The objects that are defined in iCalendar are referred to as Calendar 123 components. In this document, and others regarding Calendaring and 124 Scheduling, properties and attributes may be regarded as synonomous, 125 and components are equivalent to objects. 127 1.3 iTIP: Transport Independent Interoperability Protocol 129 This document specifies how calendaring systems use iCalendar objects 130 to interoperate with other calendar systems. It does so in a general 131 way so as to allow multiple methods of communication between systems. 133 1.4 iRIP: Binding of iTIP to a Session Protocol 135 This document specifies a session-layer iTIP protocol. Multiple 136 bindings are possible. This WG will specify and foster implementation 137 of at least one binding. 139 1.5 iMIP: Binding of iTIP to E-mail 141 This document specifies an iTIP protocol over Internet e-mail. 142 Internet e-mail protocols are given by RFCs 821, 822, 2045-2049 143 [RFC-821] [RFC-822] [RFC- 2045] [RFC-2046] [RFC-2047]. [RFC-2048] 144 [RFC-2049]. See the references for details for constructing Internet 145 e-mail messages. 147 1.6 CAP: Calendar Access Protocol Specification 149 This document specifies how a Calendar User Agent (CUA) will interact 150 with a Calendar Service using iCalendar objects. 152 A graphical representation of the relationship between the documents is 153 shown below: 154 ------------------ 155 | Model Document | 156 ------------------ 157 | 158 | 159 | 160 ------------------ 161 | iCalendar | 162 ------------------ 163 | 164 | 165 | 166 ----------------------------------- 167 | | 168 ------------------ ------------------ 169 | iTIP | | CAP | 170 ------------------ ------------------ 171 | 172 ----------------- 173 | | 174 ---------- ----------- 175 | Session | | E-mail | 176 | iRIP | | iMIP | 177 ---------- ----------- 179 2. Abstract Model 181 A CALENDAR is a collection of logically related OBJECTs. 183 OBJECTs include EVENTs, TODOs, JOURNALs, ALARMs, TIMEZONEs and 184 FREEBUSYs. OBJECTS are also termed Calendar Components. 186 Each OBJECT is described using a set of OBJECT PROPERTIES such as 187 date&time, attendees, resources and statuses. 189 The complete set of OBJECT PROPERTIES and their representation is 190 defined in [iCalendar]. 192 A specific CALENDAR has a unique CALENDAR IDENTIFIER (CI). 194 A CALENDAR USER (CU) views and modifies a CALENDAR using a CALENDAR 195 USER AGENT (CUA). Via a CUA a CU can modify a CALENDAR by adding or 196 modifying OBJECTs stored in the CALENDAR. When a CU creates an OBJECT, 197 the CU becomes the OWNER and ORGANIZER for that OBJECT. The CU may 198 delegate OWNER and ORGANIZER properties to other CUs by changing the 199 OBJECT PROPERTIES and distributing the OBJECT to other CUs. 201 A CUA uses the services of a CALENDAR SERVICE (CS) via the CALENDAR 202 ACCESS PROTOCOL (CAP) to distribute OBJECTS from and reconcile changes 203 to a CALENDAR owned by a CU. A CS delivers messages to a CUA 204 containing OBJECTs from other CALENDAR USERs via CAP. A CUA uses the 205 iCalendar Transport-Independent Interoperability Protocol (iTIP) to 206 deliver OBJECTS to a CS to be distributed to other CUAs. 208 A CS stores a set of CALENDARs which are accessible according to ACCESS 209 RULES maintained by the CS. CAP enables the CUA and CS to request 210 access to CALENDARs according to the ACCESS RULES. A CUA using CAP 211 MUST NOT use a plaintext password to gain access to a CALENDAR stored 212 by a CS. CAP also enables a CUA and CS to modify the current ACCESS 213 RULES for particular CALENDAR USERs and particular CALENDARs. 215 iTIP supports the exchange of OBJECTs without the use of ACCESS RULES. 216 It enables the exchange of objects between CSs, as well as between CUAs 217 and CSs. OBJECTs exchanged via iTIP SHOULD be encrypted for the 218 recipients and signed by the sender. A set of CSs may cooperate in a 219 CALENDAR DOMAIN. A CALENDAR DOMAIN appears to be a single CS through 220 iTIP, from the point of view of another CS. 222 An INTERNET CALENDAR SYSTEM comprises a CUA, a CS and the services of 223 CAP and iTIP, all of which which may, or may not, be integrated 224 together in a given implementation. 226 NOTE: It is not required that interacting CUA, CS, CAP and iTIP 227 entities be matched implementations, though it is required that all 228 implementations must comply with the specified CAP and iTIP. 230 A CS is responsible for locating the appropriate CALENDAR DOMAIN for 231 CIs specified in OBJECTs to be transmitted between CALENDAR DOMAINS. A 232 CUA is also required to locate the appropriate CALENDAR DOMAIN in order 233 to use iTIP. When OBJECTs are transmitted, they are encapsulated in a 234 CALENDAR PROTOCOL DATA UNIT (CPDU). 236 CPDUs are MIME encoded objects that specify a requested action and/or 237 response and carry associated data. Thus, the format of all 238 information exchanged among CALENDAR SYSTEM ENTITIES is defined in 239 terms of MIME CONTENT-TYPES with associated PARAMETER VALUES and MIME 240 BODY PART CONTENT. CONTENT is defined in terms of iCalendar. 242 The complete set of CPDUs and the corresponding finite state machine 243 for unauthenticated exchange make up iTIP. iTIP is defined in [iTIP]. 244 iTIP is capable of using a variety of transport mechanisms such as 245 Internet Mail ([RFC821], [RFC822]),and session-layer protocols, such as 246 those derived from iTIP ([iMIP], [iRIP]). 248 ACCESS RULES and the corresponding finite state machine for 249 authenticated exchange make up CAP. CAP is defined in [CAP]. 251 3. Principal Model Components 253 There are several principal components in a Calendaring and Scheduling 254 system. Their relationship can be seen in Figure 2 below. This 255 section identifies some of the salient features of the components. The 256 syntax and semantics for creating and transmitting these objects are 257 completely specified in [iCalendar], [CAP], and [iTIP]. 259 3.1 Calendar User 261 A calendar user interprets objects on a calendar, creates them, and 262 exchanges them with other calendar users. A calendar user may be a 263 person (Ken Caminiti), a group of people (the San Diego Padres baseball 264 club), or a resource (Qualcomm Stadium). From the point of view of 265 other calendar users, groups and resources appear as a single Calendar 266 user, regardless of their composition in the physical world. Calendar 267 users that are resources generally contain properties that identify 268 them as inanimate objects -- anything from a fruit bowl to rubber bats 269 to settle disputes during a meeting. 271 A calendar user owns his own calendar, and can manipulate objects 272 stored there via a CUA. Access control properties condition access to 273 calendars and their components and properties. 275 A calendar user can also manipulate the contents of other calendar 276 users' calendars by sending messages containing calendar objects to 277 them. For example, The San Diego Padres sends calendar events for the 278 1997 season to Ken Caminiti, so he knows when to show up at the 279 ballpark. The Padres sends calendar events for games to be played at 280 home to the Qualcomm Stadium calendar so the concessionaires can order 281 hot dogs. 283 A calendar user can also organize and own events. When a calendar user 284 creates an event object, that user becomes the organizer and the owner. 285 The organizer can delegate ownership and the role of organizer to 286 others. Only organizers and owners may alter any property of an event 287 object. Calendar users assigned other Attendees roles may not change 288 event properties. 290 3.2 Calendar 292 3.2.1 Collection of objects 294 Calendar users own calendars. This is a one to many relationship. A 295 single calendar user may have multiple calendars. However, each 296 calendar must have a unique identifier. A calendar is an information 297 store containing information about events,to-dos, alarms, journals and 298 free time, the objects stored in it. Within the context of a Calendar, 299 these objects are called components. Also stored in a calendar are 300 properties that are global to all of the objects in the calendar. An 301 example of a global property is the CALSCALE property that identifies 302 the type of calendar year used by objects in a calendar. Global 303 properties such as this establish the context used to interpret the 304 objects stored in the calendar. The principal structural features of a 305 calendar are described below in section 3.2.3. When objects or 306 properties of a calendar are exchanged between actors in a calendaring 307 and scheduling network (Calendar User Agents and Calendar Services), 308 they are expressed in the form defined in [iCalendar]. Figure 1 below 309 is a schematic representation of a calendar. 311 3.2.2 Properties 313 Properties are attributes of an object or a calendar. They consist of 314 a name and a value. Properties are strongly typed. Some properties 315 are multivalued. A property may have parameters that distinguish 316 between related properties. Some properties may occur multiple times 317 in the same object instance, and may be gathered into a logical group. 318 Some properties may be unique to a particular calendar or object. 320 3.2.3 Objects 321 Objects are collections of property values. A particular set of values 322 for the properties of an object define a particular object. Some 323 objects may contain certain other objects. The set of objects in a 324 calendar are identified below. 326 3.2.3.1 Events 327 Event objects are defined for specific starting date-time, have a 328 duration on a calendar, and a description. Other properties of an 329 event may specify a location or other attributes that define the event, 330 such as resources that are part of the event. Events may also contain 331 an Alarm object. 333 3.2.3.2 To-do 334 While like an event, a To-do doesn't reserve a specific block of time 335 on a calendar. A To- do component must have a starting date-time that 336 identifies its first appearance on the calendar. It must also have a 337 date-time that specifies when the To-do expires. A To-do must have a 338 description. It may also contain an alarm object. 340 3.2.3.3 Alarms 341 An alarm object may occur in an Event or To-do. It contains a 342 date-time. When present, and the date-time is passed, it will cause a 343 CUA or CS to notify the user the date-time has passed. 345 3.2.3.4 Journal 346 A journal object is a textual item that is associated with a particular 347 date. As its name suggests, its purpose is to record information 348 meaningful about the date, but not necessarily tied to other calendar 349 objects on a calendar. 351 3.2.3.5 Timezone 352 Timezone objects encapsulate rules for calculating local time from UTC. 353 Including this object in an event object enables a receiver to 354 calculate the universal time value for time values expressed in the 355 sender's local time. This object is especially useful for expressing 356 recurring events whose instances span a change in the time reference 357 such as the transition between Standard time and Daylight Savings time. 358 Time values expressed in local time are always interpreted in the 359 receiver's local time. The sender must provide another context using 360 UTC values and Timezone objects if this is not the interpretation 361 intended by the sender. 363 calendar 364 | 365 ----------------------------------------------------------- 366 | | | | | | 367 to-do event journal freebusy timezone property... 368 | 369 -------------- 370 | | 371 property... alarm 372 | 373 property... 375 Figure 1: Calendar Object Model 377 3.3 Calendar User Agent (CUA) 378 A CUA mediates the interactions between a calendar user and his 379 calendar. It represents the information stored in the calendar to the 380 user, and enables the user to manipulate it. This is a particular 381 instance of the interactive process used by a calendar user. 383 3.4 Calendar Service 384 A Calendar Service (CS) stores a collection of calendars and interacts 385 with the Calendar User Agent (CUA) via the Calendar Access Protocol 386 (CAP). 388 3.5 Calendar Domain 389 A collection of calendars that can be grouped together constitutes a 390 Calendar Domain. The relation used to bound the group is arbitrary. 391 Frequently membership in an organization will be used to define the 392 domain, but it could be a shared Internet address domain, as well. A 393 Calendar Domain provides a contiguous address space for all the 394 calendars, CSs and CUAs contained in the domain. It must be possible 395 for any Calendar User (via the facilities of a CUA and/or CS) to 396 determine whether they are members of a particular domain, or if other 397 Calendar Users are members. CSs and CUAs can take advantage of domain 398 information when routing event messages. 400 3.6 Calendar Access Protocol (CAP) 401 When calendar users need to manipulate calendars that are not stored on 402 the same computer where the CUA executes, the CUA will use the Calendar 403 Access Protocol to exchange objects with the Calendar Service (CS). 404 CAP specifies the beginning and ending of the session between the CUA 405 and the CS. Using CAP, the CUA will mediate authentication of the user 406 to the service. CAP requires calendar objects and calendar properties 407 to be expressed in the on-the-wire data format defined in [iCalendar]. 408 A CUA must not be required to maintain a connection to a CS via CAP in 409 order to display a Calendar for a Calendar User or accept commands from 410 a user to change a Calendar's content. By using CAP a CUA need not 411 have specific information on how a particular CS stores a Calendar and 412 vice versa. This enables specification and exchange of objects and 413 properties independently of Calendar storage models adopted by 414 particular CUAs or CSs. 416 3.7 Transport Independent Interoperability Protocol (iTIP) 417 CSs in a domain or across domains exchange objects and properties using 418 iTIP. Like CAP, the objects exchanged with iTIP are iCalendar objects. 419 iTIP defines the beginning and ending of the exchange session, as well 420 the users for whom the messages are intended. iTIP permits 421 unauthenticated delivery of objects to a CS. An CS may accept or 422 reject delivery without interaction with a user. But a CS may require 423 further confirmation of receipt of a object before it is acted upon by 424 the CS. 426 4. Calendar Object Transport 427 There are several transport modes in this architecture. The figures 428 below illustrate the different modes that are allowed. Four modes are 429 required to handled the different kinds of calendar exchanges across 430 the Internet, person to person, group interactions local to a 431 particular network, and exchanges between networks, and exchanges 432 between an individual node in one network and the foreign network. 434 ------------ ------------ 435 | CUA | rcvr| ----- ----|rcvr| CUA | 436 | -----| \ / |---- | 437 | | \ / | | 438 | | X | | 439 | | / \ | | 440 | -----| / \ |---- | 441 | | sndr| ----- ----|sndr| | 442 ------------ \ / ------------ 443 iTIP 445 Figure 2: Direct Access 446 ------------ ------------ 447 | CUA | | CUA | 448 | | | | 449 | | | | 450 ------------ ------------ 451 \ / 452 \ ------- CAP ------- / 453 \ / 454 \ -------------- / 455 \ | CS | / 456 | | 457 | | 458 -------------- 460 Figure 3: Calendar Service Mediation 462 ----------------- ------------------ 463 | | | | 464 | Calendar Domain | | Calendar Domain | 465 | | | | 466 | | | | 467 | ------- | | | 468 | | CUA | | | | 469 | ------- | | | 470 | | | | | 471 | | -- CAP | | | 472 | | | | | 473 | ------------ | |--------- | 474 | | CS | rcvr|---------- -------|rcvr| | | 475 | | -----| | \ / |---- | | 476 | | | | \ / | Gateway | | 477 | | | | X | | | 478 | | | | / \ | | | 479 | | -----| | / \ |---- | | 480 | | | sndr| --------- ------|sndr| | | 481 | ------------ | \ / |--------- | 482 | | iTIP | | 483 | | | | 484 ----------------- ------------------ 486 Figure 4: Interdomain Exchange 487 ------------------ 488 | | 489 | Calendar Domain | 490 | | 491 | | 492 | | 493 | | 494 | | 495 | | 496 | | 497 | | 498 ------------ |--------- | 499 | CUA | rcvr|---------- -------|rcvr| | | 500 | -----| \ / |---- | | 501 | | \ / | Gateway | | 502 | | X | | | 503 | | / \ | | | 504 | -----| / \ |---- | | 505 | | sndr| --------- ------|sndr| | | 506 ------------ \ / |--------- | 507 iTIP | | 508 | | 509 ------------------ 511 Figure 5: Node-Foreign Network Exchange 513 4.1 Direct Access 514 For direct access, two calendar user agents (CUA) exchange calendar 515 components by using iTIP. Each CUA provides an iTIP sender and 516 receiver. As is generally the case, the methods used by the CUA to 517 store calendar data locally are not relevant to the transport model. 518 For this mode, calendar users must be uniquely identifiable across the 519 Internet, and access to CUAs must conform with privacy and security 520 considerations. To insure privacy and/or authenticity, CUAs should use 521 the cryptographic wrappers provided by iTIP. 523 4.2 Calendar Service Mediation 524 Using Calendar Service Mediation a CUA interoperates with a Calendar 525 Service (CS) using CAP to exchange calendar components. The CS takes 526 responsibility for mediating receipt and delivery of components with 527 other collaborating CUAs. The principal difference between this mode 528 and Interdomain Exchange is that CSs do not need to use iTIP to 529 facilitate exchange of components. A consequence of this mode is that 530 CUAs and CSs need not use addresses that are unique across the 531 Internet. However, consistency with other modes makes a consistent 532 address model an obvious simplification for implementors. Moreover, 533 because CAP access provides authentication, objects exchanged through a 534 CAP channel need not carry authenication information. 536 4.3 Interdomain Exchange 537 With Interdomain Exchange a Calendar Service (CS) supporting a group of 538 users in one domain can exchange calendar components with a different 539 calendar domain. Domains may or may not be within the same Internet 540 network domain. Like Direct Access, iTIP is the vehicle which permits 541 component exchange. In the figure, one domain is illustrated with a 542 Calendar Service providing iTIP service. The 2nd domain in this figure 543 has a distinct iTIP sender and receiver. In order to provide 544 end-to-end privacy components must be wrapped in a cryptographically 545 secure wrapper to insure only the intended correspondents can interpret 546 the components. This wrapper is not required unless privacy must be 547 assured. In order to provide backward compatibility with existing 548 calendar and scheduling systems, a privacy wrapper cannot be a required 549 aspect of the component exchange. 551 4.4 Node-Foreign Domain Exchange 552 Figure 5 describes the interaction between some particular Calendar 553 Domain, and a node which is not part of that domain. Like Interdomain 554 Exchange and Direct Access, iTIP is used to mediate the exchange of 555 objects between the CUA and the Calendar Domain. Similar to those two 556 modes, objects exchanged in this mode should be enclosed in a crypto- 557 graphic wrapper to assure the privacy and authenticity of the exchange. 559 5. Security considerations 560 There are four classes of threats with which Calendaring and Scheduling 561 protocols must be concerned. These threats can be characterized as 562 Spoofs, Eavesdropping, Floods, and Malicious Changes. A Spoof occurs 563 when a node masquerades as another node enabling it to receive objects 564 to which it would not otherwise be entitled or send unauthorized 565 objects. Eavesdropping occurs when an intermediary node is able to 566 retain and interpret an object exchanged between a sender and receiver 567 without their knowledge or permission. A Flood occurs when a node acts 568 to send more messages to a receiver than the receiver can process, 569 prohibiting the receiver from receiving other messages. Malicious 570 Changes occur if a CU gains access to some Calendar not owned by the CU 571 or some CPDU in transit and makes unauthorized changes to the Calendar 572 or to the CPDU. Simply gaining unauthorized access via the protocols 573 outlined by this model may be considered malicious,as well. 575 iCalendar must provides the means to classify the intended sensitivity 576 level of an event, to-do or journal calendar component (i.e., PUBLIC, 577 PRIVATE, or CONFIDENTIAL). 579 CAP must provide a description of the elements of the calendaring 580 system access model and the protocol elements for creating and 581 manipulating the access control to a calendar. This protocol must also 582 describe the authentication procedure between a CUA and CS. This will 583 mitigate Malicious Changes. 585 iTIP must provide a means to wrap all components in an exchange in a 586 cryptographically secure envelope so that only the intended 587 correspondents can decode the message. This will mitigate the threats 588 of Spoofs and Eavesdropping. It must also provide a means for a 589 receiver to throttle the messages of a sender to prevent Flooding. 591 6. Copyright 592 Copyright (C) The Internet Society (Oct 1997). All Rights Reserved. 594 This document and translations of it may be copied and furnished to 595 others, and derivative works that comment on or otherwise explain it or 596 assist in its implmentation may be prepared, copied, published and 597 distributed, in whole or in part, without restriction of any kind, 598 provided that the above copyright notice and this paragraph are 599 included on all such copies and derivative works. However, this 600 document itself may not be modified in any way, such as by removing the 601 copyright notice or references to the Internet Society or other 602 Internet organizations, except as needed for the purpose of developing 603 Internet standards in which case the procedures for copyrights defined 604 in the Internet Standards process must be followed, or as required to 605 translate it into languages other than English. 607 The limited permissions granted above are perpetual and will not be 608 revoked by the Internet Society or its successors or assigns. 610 7. References 611 [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 612 USC/Information Sciences Institute, August 1982. 614 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 615 Messages", STD 11, RFC 822, UDEL, August 1982. 617 [RFC-1983] Malkin, G., "Internet Users' Glossary", RFC 1983, Aug 1996 619 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", 620 RFC 2026, Oct 1996 622 [RFC-2045] Borenstein, N. & Freed, N., "Multipurpose Internet Mail 623 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 624 2045, Nov 1996 626 [RFC-2046] Borenstein, N. & Freed, N., "Multipurpose Internet Mail 627 Extensions MIME) Part Two: Media Types", RFC 2046, Nov 1996 629 [RFC-2047] Borenstein, N. & Freed, N., "MIME (Multipurpose Internet 630 Mail Extensions) Part Three: Message Header Extensions for Non-ASCII 631 Text", RFC 2047, Nov 1996 633 [RFC-2048] Borenstein, N. & Freed, N., "Multipurpose Internet Mail 634 Extensions (MIME) Part Four: Registration Procedures", RFC 2048, Nov 635 1996 637 [RFC-2049] Borenstein, N. & Freed, N., "Multipurpose Internet Mail 638 Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 639 2049, Nov 1996 640 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, Mar 1997 643 [iCalendar] Dawson, F. & Stenerson, D., "Internet Calendaring and 644 Scheduling Core Object Specification" ietf-calsch-ical-01.txt, March, 645 1997 647 [iTIP] Silverberg, S., Mansour, S., Dawson, F., & Hopson, R., 648 "iCalendar Transport-Independent Interoperability Protocol (iTIP)", 649 [CAP] Author U., "Calendar Access Protocol", unwritten, Oct 1997 651 8. Acknowledgments 652 The author is extremely grateful for the assistance, patience and 653 tolerance of the members of the CalSch working group. Their ideas and 654 suggestions are crucial to making this a useful document. In 655 particular, the author would like to thank 656 Anik Ganguly 657 Derik Stenerson 658 Frank Dawson 659 Gilles Fortin 660 Einar Stefferud 661 Steve Mansour 662 Steve Silverberg 664 Their comments and ideas were particularly important in the formulation 665 of this draft. I would also like to thank Qualcomm, Incorporated for 666 allowing the time necessary to bring this effort to fruition. 668 9. Author's address 670 For more information, please contact the author via Internet Mail. 672 John W. Noerenberg, II 673 Qualcomm, Incorporated 674 6455 Lusk Blvd 675 San Diego, CA 92131 676 USA 678 email: jwn2@qualcomm.com 679 ph: +1 619 658 3510 680 The "Internet Calendar Model Specification" is the work of the Internet 681 Engineering Task Force Working Group on Calendaring and Scheduling. The 682 chairman of that group, Anik Ganguly, may be reached at: 684 Anik Ganguly 685 Campbell Services, Inc. 686 21700 Northwestern Highway 687 10th Floor 688 Southfield, MI 48075 689 email: anik@ontime.com 691 10. Appendix -- Calendar protocol nomenclature 692 Calendaring and Scheduling uses a rich lexicon of terms that are 693 specific to the problems of scheduling events and reconciling 694 conflicting requests for time and resources. This document will 695 identify the major components of these systems, and show component 696 relationships. However, for the sake of completeness and to serve as 697 an introduction to the protocols in general, a more extensive list of 698 terms, and brief definitions are included here. Essential parts of the 699 system model have expanded definitions in this document where the 700 components of the model are introduced. 702 10.1 Calendaring lexicon 704 Alarm, Reminder 705 An asynchronous mechanism providing feedback for a pending or past 706 event or to-do. 708 Busy Time 709 A period of time that is not available for scheduling. 711 Calendar 712 A particular collection of calendar objects. 714 Calendar Component 715 A Calendar Object. 717 Calendar Object 718 The objects that can be found in a calendar. The objects are events, 719 to-dos, journals, free/busies, time zones and alarms. Objects also 720 include properties and may include other objects. A calendar object is 721 identified by unique delimiters. 723 Calendar Date 724 A day identified by its position within the calendar year. 726 Calendar Scale 727 A particular type of calendar year, for example, Gregorian, Buddhist 728 Era, Japanese Emperor Era, Chinese Lunar, Islamic, and Jewish 729 Calendars. 731 Calendar Service 732 A Calendar Service (CS) stores a collection of calendars and interacts 733 with the Calendar User Agent (CUA) via the Calendar Access Protocol 734 (CAP). 736 Calendar User Agent (CUA) 737 A CUA mediates the interactions between a calendar user and his 738 calendar. It represents the information stored in the calendar to the 739 user, and enables the user to manipulate it. This is a particular 740 instance of the interactive process used by a calendar user. 742 Coordinate Universal Time (UTC) 743 The time scale maintained by the Bureau International de l'Heure 744 (International Time Bureau). UTC is often incorrectly referred to as 745 GMT. 747 Daylight Saving Time (DST) 748 An adjustment to local time to accommodate annual changes in the number 749 of daylight hours. DST is also known as Advanced Time, Summer Time, or 750 Legal Time. Daylight Saving Time adjustments in the Southern 751 Hemisphere are opposite to those in the Northern Hemisphere. 753 Event 754 A calendar object that defines a scheduled activity, minimally 755 specified by a start and end calendar date and time of day and a 756 description. 758 Free Time 759 A period of time available for scheduling on a calendar. 761 FreeBusy 762 FreeBusy objects describe blocks of allocated and unallocated time on a 763 calendar. They do not contain a description why the time is allocated. 765 Gregorian Calendar 766 A calendar scale in general use beginning in 1582. The Gregorian 767 Calendar scale is based on a solar calendar consisting of common years 768 made up of 365 days and leap years made up of 366 days; both divided 769 into 12 sequential months. 771 Journal 772 A calendar object that defines a collection of information intended for 773 human presentation and is minimally specified by a calendar date and 774 one or more descriptions. 776 Local Time 777 The clock time in public use in a locale. Local time is often 778 referenced by the customary name for the time zone in which it is 779 located. The relationship between local time and UTC is based on the 780 offset(s) that are in use for a particular time zone. In general, the 781 formula is as follows: 783 local time = UTC + (offset) 784 Period 785 A duration of time, specified as either a defined length of time or by 786 its beginning and end points. 788 Properties 789 Attributes that apply to calendar objects or calendars. A calendar 790 object is a named set of properties. Properties can also be used to 791 produce variants to suit a particular purpose. 793 Recurrence Rule 794 A notation used to represent repeating occurrences, or the exceptions 795 to such a repetition of an event or a to-do. The recurrence rule can 796 also be used in the specification of a time zone description. 798 Repeating Event or To-do 799 An event or to-do that repeats for one or more additional occurrences. 800 The recurrence may be defined with discrete dates and times and/or with 801 a recurrence rule. 803 Standard Time 804 Introduced by Sir Sanford Fleming and others around 1870, standard time 805 is a scheme for dividing the world into zones where the same time would 806 be kept. The original proposal was to divide the world into 24 zones, 807 each zone having a width of 15 degrees of longitude. The center zone 808 was originally the meridian passing through Greenwich, England, called 809 Greenwich Mean Time (GMT). The time in the zones was decremented by 810 one hour per zone going westwards and was incremented by one hour per 811 zone going eastwards from GMT. Changes have been made to the original 812 proposal to accommodate political boundaries. In addition, some 813 countries and regions specify 30 or 45 minute offsets, rather than the 814 full 60 minute offset. Standard time is also known as Winter Time in 815 some regions. 817 GMT and UTC are generally equivalent. However, by international 818 agreement, the GMT term is discouraged in favor of the term UTC for all 819 general time keeping. 821 Time Zone 822 A geographic region to which a specified offset from UTC applies. While 823 offsets can frequently be calculated by knowing the longitudinal 824 distance from Greenwich, England, local conventions frequently alter 825 the calculation, complicating the determination of local time. Local 826 convention may also assign a label to identify the time zone. There is 827 no world-wide standard for labels. 829 To-do 830 A calendar object that defines an action item and is minimally 831 specified by an effective calendar date and time of day, a due 832 calendar date and time of day, a priority and a description.