idnits 2.17.1 draft-ietf-calsch-mod-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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-01', but the file name used is 'draft-ietf-calsch-mod-01' == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 11) being 106 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 566 has weird spacing: '...journal fre...' == 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 199, but not defined Unexpected reference format, failed extracting the RFC number: RFC- 2045 == Missing Reference: 'RFC821' is mentioned on line 359, but not defined ** Obsolete undefined reference: RFC 821 (Obsoleted by RFC 2821) == Missing Reference: 'RFC822' is mentioned on line 359, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RFC2091' is mentioned on line 361, but not defined == Missing Reference: 'CalObjSpec' is mentioned on line 640, but not defined == Unused Reference: 'RFC-2045' is defined on line 901, but no explicit reference was found in the text == Unused Reference: 'RFC-2068' is defined on line 929, 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) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. 'CAP' Summary: 16 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Noerenberg 4 ietf-draft-calsch-mod-01.txt Qualcomm, Inc 6 Category: INTERNET DRAFT Expires: Jan 1998 8 Internet Calendar Model Specification 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months. 22 Internet-Drafts may be updated, replaced, or made obsolete by other 24 documents at any time. It is not appropriate to use Internet-Drafts as 26 reference material or to cite them other than as a "working draft" or 28 "work in progress". 30 To learn the current status of any Internet-Draft, please check the 32 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 34 Directories on ds.internic.net (US East Coast), nic.nordu.net 36 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 38 Distribution of this document is unlimited. 40 Abstract 42 Internet Calendaring and Scheduling protocols require the definition 44 of objects to encapsulate an event to be scheduled, a calendar on 46 which the event will be stored, and means for exchanging these objects 48 across the Internet between calendars on behalf of people for whom the 50 calendars are meaningful. This document gives an abstract model of the 52 objects and the protocols necessary to accomplish this kind of 54 information exchange. It will establish the context in which other 56 Calendaring and Scheduling RFCs can be interpreted. Included are 58 brief introductions to the other components of Internet calendar 60 protocols and definitions of nomenclature common to all documents 62 defining these protocols. Reading this document will enable 64 implementors and users of Internet Calendaring and Scheduling 66 protocols to understand the goals and constraints chosen for related 68 protocols. 70 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 72 Table of Contents 74 1. Document framework 3 76 1.1 Model Specification 3 78 1.2 iCalendar: Core Object Specification 3 80 1.3 iTIP: Transport Independent Interoperability Protocol 3 82 1.4 CAP: Calendar Access Protocol Specification 4 84 2. Abstract Model 5 86 3. Principal Model Components 6 88 3.1 Calendar User 6 90 3.2 Calendar 7 92 3.3 Calendar User Agent (CUA) 8 94 3.4 Calendar Service 8 96 3.5 Calendar Domain 9 98 3.6 Calendar Access Protocol (CAP) 9 100 3.7 Transport Independent Interoperability Protocol (iTIP) 9 102 4. Calendar Object Transport 10 104 4.1 Direct Access 11 106 4.2 Calendar Service Mediation 11 108 4.3 Interdomain Exchange 12 110 5. Security considerations 12 112 6. References 13 114 7. Acknowledgments 14 116 8. Author's address 14 118 9. Appendix -- Calendar protocol nomenclature 15 119 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 121 Introduction 123 The Internet Calendar Model specification provides a framework for the 125 set of protocols that define Calendaring and scheduling for the 127 Internet. The protocols specify the contents of calendars, and how 129 the objects stored on calendars are represented during transmission 131 across the Internet. These protocols also define the interaction 133 between a calendar user agent and a calendar store, as well as the 135 actions performed by calendar transfer agents that facilitate 137 communication between calendar stores. These terms will be defined 139 more precisely in the section on nomenclature below. The protocols 141 are the: 143 "Core Object Specification" [iCalendar] 145 "iCalendar Interoperability Protocol" [iTIP] 147 "Calendar Access Protocol" [CAP] 149 1. Document framework Calendar and Scheduling Protocols are contained 151 in a series of related documents. This section describes the 153 relationship between the documents. Section 2 presents the abstract 155 model for Internet Calendaring and Scheduling. 157 Following sections amplify the principal concepts defined in the 159 abstract model, provide a schematic representation of information flow 161 in Internet Calendaring and Scheduling, and supply other, useful 163 background information. 165 1.1 Model Specification This document - see abstract and introduction 167 above. 169 1.2 iCalendar: Core Object Specification The Core Object Specification 171 is the authoritative definition of all properties that may be used in 173 the Internet Calendar and Scheduling Protocols as well as the rules 175 for encoding and representing the objects that are constructed from 177 those properties. iCalendar also specifies the method to be used to 179 define new attributes. 181 1.3 iTIP: Transport Independent Interoperability Protocol This 183 document specifies how calendaring systems use iCalendar objects to 185 interoperate with other calendar systems. It does so in a general way 187 so as to allow multiple methods of communication between systems. 189 Binding of iTIP to a real-time protocol This document specifies a 191 session-layer iTIP protocol. Multiple bindings are possible. This WG 193 will specify and foster implementation of at least one binding. 195 Binding of iTIP to E-mail This document specifies an iTIP protocol 197 over Internet e-mail using MIME. Internet e-mail protocols are given 199 by RFCs 821, 822, 2045-2049 [RFC-821] [RFC-822] [RFC- 2045] [RFC-2046] 201 [RFC-2047]. [RFC-2048] [RFC-2049]. See the references for details for 203 constructing Internet e-mail messages. 205 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 207 1.4 CAP: Calendar Access Protocol Specification This document 209 specifies how a Calendar User Agent (CUA) will interact with a 211 Calendar Service using iCalendar objects. 213 A graphical representation of the relationship between the documents 215 is shown below: 217 ------------------ 219 | Model Document | 221 ------------------ 223 | 225 | 227 | 229 ------------------ 231 | iCalendar | 233 ------------------ 235 | 237 | 239 | 241 ----------------------------------- 243 | | 245 ------------------ ------------------ 247 | iTIP | | CAP | 249 ------------------ ------------------ 251 | 253 ----------------- 255 | | 257 ---------- ----------- 259 | session | | email | 261 | iTIP | | iTIP | 263 ---------- ----------- 265 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 267 2. Abstract Model 269 A CALENDAR is a collection of logically related OBJECTs. 271 OBJECTs include EVENTs, TODOs, JOURNALs, ALARMs, TIMEZONEs and 273 FREEBUSYs. 275 Each OBJECT is described using a set of OBJECT ATTRIBUTES such as 277 date&time, attendees, resources and statuses. 279 The complete set of OBJECT ATTRIBUTES and their representation is 281 defined in [iCalendar]. 283 A specific CALENDAR has a unique CALENDAR IDENTIFIER (CI). 285 A CALENDAR USER (CU) views and modifies a CALENDAR using a CALENDAR 287 USER AGENT (CUA). Via a CUA a CU can modify a CALENDAR by adding or 289 modifying OBJECTs stored in the CALENDAR. A CUA uses the services of 291 a CALENDAR SERVICE (CS) via the CALENDAR ACCESS PROTOCOL (CAP) to 293 publish changes to a CALENDAR. A CS also delivers messages containing 295 OBJECTs from other CALENDAR USERs via CAP, or via the iCalendar 297 Transport-Independent Interoperability Protocol, iTIP. 299 A CS stores a set of CALENDARs which are accessible according to 301 ACCESS RULES maintained by the CS. CAP enables the CUA and CS to 303 request access to CALENDARs according to the ACCESS RULES. CAP also 305 enables a CUA and CS to modify the current ACCESS RULES for particular 307 CALENDAR USERs and particular CALENDARs. 309 iTIP supports the exchange of OBJECTs without the use of ACCESS RULES. 311 It enables the exchange of objects between CSs, as well as between 313 CUAs and CSs. A set of CSs may cooperate in a CALENDAR DOMAIN. A 315 CALENDAR DOMAIN appears to be a single CS through iTIP, from the point 317 of view of another CS. 319 A minimal INTERNET CALENDAR SYSTEM comprises a CUA, a CS and the 321 services of CAP and iTIP, all of which which may, or may not, be 323 integrated together in a given implementation. 325 NOTE: It is not required that interacting CUA, CS, CAP and iTIP 327 entities be matched implementations, though it is required that all 329 implementations must comply with the specified CAP and iTIP. 331 A CS is responsible for locating the appropriate CALENDAR DOMAIN for 333 CIs specified in OBJECTs to be transmitted between CALENDAR DOMAINS. A 335 CUA is also required to locate the appropriate CALENDAR DOMAIN in 337 order to use iTIP. When OBJECTs are transmitted, they are 339 encapsulated in a CALENDAR PROTOCOL DATA UNIT (CPDU). 341 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 343 CPDUs are MIME encoded objects that specify a requested action and/or 345 response and carry associated data. Thus, the format of all 347 information exchanged among CALENDAR SYSTEM ENTITIES is defined in 349 terms of MIME CONTENT-TYPES with associated PARAMETER VALUES and MIME 351 BODY PART CONTENT. CONTENT is defined in terms of iCalendar. 353 The complete set of CPDUs and the corresponding finite state machine 355 for unauthenticated exchange make up iTIP. iTIP is defined in 357 [iTIP1], [iTIP2], and [iTIP3]. iTIP is capable of using a variety of 359 transport mechanisms including INTERNET MAIL ([RFC821], [RFC822]), 361 HTTP, [RFC2091], as well as session-layer protocols derived directly 363 from iTIP. 365 ACCESS RULES and the cooresponding finite state machine for 367 authenticated exchange make up CAP. CAP is defined in [CAP]. 369 3. Principal Model Components 371 There are several principal components in a Calendaring and Scheduling 373 system. Their relationship can be seen in Figure 2 below. This 375 section identifies some of the salient features of the components. The 377 syntax and semantics for creating and transmitting these objects are 379 completely specified in [iCalendar], [CAP], and [iTIP]. 381 3.1 Calendar User 383 A calendar user interprets objects on a calendar, creates them, and 385 exchanges them with other calendar users. A calendar user may be a 387 person (Ken Caminiti), a group of people (the the San Diego Padres 389 baseball club), or a resource (Qualcomm Stadium). From the point of 391 view of other calendar users, groups and resources appear as a single 393 Calendar user, regardless of their composition in the physical world. 395 Calendar users that are resources generally contain properties that 397 identify them as inanimate objects -- anything from a fruit bowl to 399 rubber bats to settle disputes during a meeting. 401 A calendar user owns his own calendar, and can manipulate objects 403 stored there via a CUA. Access control attributes condition access to 405 calendars and their components and properties. 407 A calendar user can also manipulate the contents of other calendar 409 users' calendars by sending messages containing calendar objects to 411 them. For example, The San Diego Padres sends calendar events for the 413 1997 season to Ken Caminiti, so he knows when to show up at the 415 ballpark. The Padres sends calendar events for games to be played at 417 home to the Qualcomm Stadium calendar so the concessionaires can order 419 hot dogs. 421 A calendar user can also organize and own events. When a calendar 423 user creates an event object, that user becomes the organizer and the 425 owner. The organizer can delegate ownership and the role of organizer 426 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 428 to others. Only organizers and owners may alter any attribute of an 430 event object. Calendar users assigned other Attendees roles may not 432 change event attributes. 434 3.2 Calendar 436 3.2.1 Collection of objects 438 Calendar users own calendars. This is a one to many relationship. A 440 single calendar user may have multiple calendars. However, each 442 calendar must have a unique identifier. A calendar is an information 444 store containing information about events,to-dos, alarms, journals and 446 free time, the objects stored in it. Also stored in a calendar are 448 properties that are global to all of the objects in the calendar. An 450 example of a global property is the GEO property that identifies the 452 physical location where the calendar user can be found. Global 454 properties such as this establish the context used to interpret the 456 objects stored in the calendar. The principal structural features of 458 a calendar are described below in section 3.2.3. When objects or 460 properties of a calendar are exchanged between actors in a calendaring 462 and scheduling network (Calendar User Agents and Calendar Services), 464 they are expressed in the form defined in [iCalendar]. Figure 1 below 466 is a schematic representation of a calendar. 468 3.2.2 Properties 470 Properties are attributes of an object or a calendar. They consist of 472 a name and a value. Properties are strongly typed. Some properties 474 are multivalued. A property may have parameters that distinguish 476 between related properties. Some properties may occur multiple times 478 in the same object instance, and may be gathered into a logical group. 480 Some properties may be unique to a particular calendar or object. 482 3.2.3 Objects 484 Objects are collections of property values. A particular set of 486 values for the properties of a object define a particular object. 488 Some objects may contain certain other objects. The set of objects in 490 a calendar are identified below. 492 3.2.3.1 Events 494 Event objects are defined for specific starting date-time, have a 496 duration on a calendar, and a description. Other properties of an 498 event may specify a location or other attributes that define the 500 event, such as resources that are part of the event. Events may also 502 contain an Alarm object. 504 3.2.3.2 To-do 506 While like an event, a To-do doesn't reserve a specific block of time 508 on a calendar. A To- do component must have a starting date-time that 510 identifies its first appearance on the calendar. It must also have a 512 date-time that specifies when the To-do expires. A To-do must have a 514 description. It may also contain an alarm object. 516 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 518 3.2.3.3 Alarms 520 An alarm object may occur in an Event or To-do. It contains a 522 date-time. When present, and the date-time is passed, it will cause a 524 CUA or CS to notify the user the date-time has passed. 526 3.2.3.4 Journal 528 A journal object is a textual item that is associated with a 530 particular date. As its name suggests, its purpose is to record 532 information meaningful about the date, but not necessarily tied to 534 other calendar objects on a calendar. 536 3.2.3.5 Timezone 538 Timezone objects encapsulate rules for calculating local time from 540 UTC. Including this object in an event object enables a receiver to 542 calculate the universal time value for time values expressed in the 544 sender's local time. This object is especially useful for expressing 546 recurring events whose instances span a change in the time reference 548 such as the transition between Standard time and Daylight Savings 550 time. Time values expressed in local time are always interpreted in 552 the receiver's local time. The sender must provide another context 554 using UTC values and Timezone objects if this is not the 556 interpretation intended by the sender. 558 calendar 560 | 562 ----------------------------------------------------------- 564 | | | | | | 566 to-do event journal freebusy timezone property... 568 | 570 -------------- 572 | | 574 property... alarm 576 | 578 property... 580 Figure 1: Calendar Object Model 582 3.3 Calendar User Agent (CUA) 584 A CUA mediates the interactions between a calendar user and his 586 calendar. It represents the information stored in the calendar to the 588 user, and enables the user to manipulate it. This is a particular 590 instance of the interactive process used by a calendar user. 592 3.4 Calendar Service 594 A Calendar Service (CS) stores a collection of calendars and interacts 596 with the Calendar User Agent (CUA) via the Calendar Access Protocol 598 (CAP). 600 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 602 3.5 Calendar Domain 604 A collection of calendars that can be grouped together constitutes a 606 Calendar Domain. The relation used to bound the group is arbitrary. 608 Frequently membership in an organization will be used to define the 610 domain, but it could be a shared Internet address domain, as well. A 612 Calendar Domain provides a contiguous address space for all the 614 calendars, CTAs and CUAs contained in the domain. It must be possible 616 for any Calendar User (via the facilities of a CUA and/or CTA) to 618 determine whether they are members of a particular domain, or if other 620 Calendar Users are members. CTAs and CUAs can take advantage of 622 domain information when routing event messages. 624 3.6 Calendar Access Protocol (CAP) 626 When calendar users need to manipulate calendars that are not stored 628 on the same computer where the CUA executes, the CUA will use the 630 Calendar Access Protocol to exchange objects with the Calendar Service 632 (CS). CAP specifies the beginning and ending of the session between 634 the CUA and the CS. Using CAP, the CUA will mediate authentication of 636 the user to the service. CAP requires calendar objects and calendar 638 properties to be expressed in the on-the-wire data format defined in 640 [CalObjSpec]. A CUA must not be required to maintain a connection to a 642 CS via CAP in order to display a Calendar for a Calendar User or 644 accept commands from a user to change a Calendar's content. By using 646 CAP a CUA need not have specific information on how a particular CS 648 stores a Calendar and vice versa. This enables specification and 650 exchange of objects and properties independently of Calendar storage 652 models adopted by particular CUAs or CSs. 654 3.7 Transport Independent Interoperability Protocol (iTIP) 656 CSs in a domain or across domains exchange objects and properties 658 using iTIP. Like CAP, iTIP uses iCalendar formats to represent objects 660 and properties. iTIP defines the beginning and ending of the exchange 662 session, as well the users for whom the messages are intended. iTIP 664 permits unauthenticated delivery of objects and properties to a CS. A 666 CS may accept or reject delivery without interaction with a user. But 668 a CS may require further confirmation of receipt of a object or 670 property before it is acted upon by the CS. 672 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 674 4. Calendar Object Transport 676 There are several transport modes in this architecture. The figures 678 below illustrate the different modes that are allowed. Three modes 680 are required to handled the different kinds of calendar exchanges 682 across the Internet, person to person, group interactions local to a 684 particular network, and exchanges across networks. 686 ------------ ------------ 688 | CUA | rcvr| ----- ----|rcvr| CUA | 690 | -----| \ / |---- | 692 | | \ / | | 694 | | X | | 696 | | / \ | | 698 | -----| / \ |---- | 700 | | sndr| ----- ----|sndr| | 702 ------------ \ / ------------ 704 iTIP 706 Figure 2: Direct Access 708 ------------ ------------ 710 | CUA | | CUA | 712 | | | | 714 | | | | 716 ------------ ------------ 718 \ / 720 \ ------- CAP ------- / 722 \ / 724 \ -------------- / 726 \ | CS | / 728 | | 730 | | 732 -------------- 734 Figure 3: Calendar Service Mediation 735 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 737 ----------------- ------------------ 739 | | | | 741 | Calendar Domain | | Calendar Domain | 743 | | | | 745 | | | | 747 | ------- | | | 749 | | CUA | | | | 751 | ------- | | | 753 | | | | | 755 | | -- CAP | | | 757 | | | | | 759 | ------------ | |--------- | 761 | | CS | rcvr|---------- -------|rcvr| | | 763 | | -----| | \ / |---- | | 765 | | | | \ / | Gateway | | 767 | | | | X | | | 769 | | | | / \ | | | 771 | | -----| | / \ |---- | | 773 | | | sndr| --------- ------|sndr| | | 775 | ------------ | \ / |--------- | 777 | | iTIP | | 779 | | | | 781 ----------------- ------------------ 783 Figure 4: Interdomain Exchange 785 4.1 Direct Access 787 For direct access, two calendar user agents (CUA) exchange calendar 789 components by using iTIP. Each CUA provides an iTIP sender and 791 receiver. As is generally the case, the methods used by the CUA to 793 store calendar data locally are not relevant to the transport model. 795 For this mode, calendar users must be uniquely identifiable across the 797 Internet, and access to CUAs must conform with privacy and security 799 considerations. Because the transport itself is not authenticated, it 801 is crucial the objects themselves be capable of carrying 803 authentication information. 805 4.2 Calendar Service Mediation 807 Using Calendar Service Mediation a CUA interoperates with a Calendar 809 Service (CS) using CAP to exchange calendar components. The CS takes 811 responsibility for mediating receipt and delivery of components with 813 other collaborating CUAs. The principal difference between this mode 815 and Interdomain Exchange is that CSs do not need to use iTIP to 817 facilitate exchange of components. A consequence of this mode is that 819 CUAs and CSs need not use addresses that are unique across the 821 Internet. However, consistency with other modes makes a consistent 823 address model an obvious simplification for implementors. Moreover, 825 because CAP access provides authentication, objects exchanged through 827 a CAP channel need not carry authenication information. 829 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 831 4.3 Interdomain Exchange 833 With Interdomain Exchange a Calendar Service (CS) supporting a group 835 of users in one domain can exchange calendar components with a 837 different calendar domain. Domains may or may not be within the same 839 Internet network domain. Like Direct Access, iTIP is the vehicle 841 which permits component exchange. In the figure, one domain is 843 illustrated with a Calendar Service providing iTIP service. The 2nd 845 domain in this figure has a distinct iTIP sender and receiver. In 847 order to provide end-to-end privacy components must be wrapped in a 849 cryptographically secure wrapper to insure only the intended 851 corespondents can interpret the components. This wrapper is not 853 required unless privacy must be assured. In order to provide backward 855 compatibility with existing calendar and scheduling systems, a privacy 857 wrapper cannot be a required aspect of the component exchange. 859 5. Security considerations 861 The Core Object Specification must provides the means to classify the 863 intended sensitivity level of an event, to-do or journal calendar 865 component (i.e., PUBLIC, PRIVATE, or CONFIDENTIAL). It must also 867 provide a means to wrap all components in an exchange in a 869 cryptographically secure envelope so that only the intended 871 correspondents can decode the message. 873 The Calendar Access Protocol must provide a description of the 875 elements of the calendaring system security model and the protocol 877 elements for creating and manipulating the access control to a 879 calendar. This protocol must also describe the authentication 881 procedure between a CUA and CS. 883 So that iCalendar objects may be securely transmitted across the 885 Internet and may be verified by recipients, iCalendar must describe 887 how objects will be covered and authenticated. 889 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 891 6. References 893 [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 895 821, USC/Information Sciences Institute, August 1982. 897 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 899 Messages", STD 11, RFC 822, UDEL, August 1982. 901 [RFC-2045] Borenstein, N. & Freed, N., "Multipurpose Internet Mail 903 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 905 2045, Nov 1996 907 [RFC-2046] Borenstein, N. & Freed, N., "Multipurpose Internet Mail 909 Extensions MIME) Part Two: Media Types", RFC 2046, Nov 1996 911 [RFC-2047] Borenstein, N. & Freed, N., "MIME (Multipurpose Internet 913 Mail Extensions) Part Three: Message Header Extensions for Non-ASCII 915 Text", RFC 2047, Nov 1996 917 [RFC-2048] Borenstein, N. & Freed, N., "Multipurpose Internet Mail 919 Extensions (MIME) Part Four: Registration Procedures", RFC 2048, Nov 921 1996 923 [RFC-2049] Borenstein, N. & Freed, N., "Multipurpose Internet Mail 925 Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 927 2049, Nov 1996 929 [RFC-2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 931 Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, 933 Jan 1997 935 [iCalendar] Dawson, F. & Stenerson, D., "Internet Calendaring and 937 Scheduling Core Object Specification" ietf-calsch-ical-01.txt, March, 939 1997 941 [iTIP1] Silverberg, S., Mansour, S., Dawson, F., & Hopson, R., 943 "iCalendar Transport-Independent Interoperability Protocol (iTIP) Part 945 One: Scheduling Events and BusyTime", 946 [iTIP2] Silverberg, S., Mansour, S., Dawson, F., & Hopson, R., 948 "iCalendar Transport-Independent Interoperability Protocol (iTIP) Part 950 Two: Scheduling To-Dos", draft-ietf-calsch-itip-part2-00.txt, Jul 1997 952 [iTIP3] Silverberg, S., Mansour, S., Dawson, F., & Hopson, R., 954 "iCalendar Transport-Independent Interoperability Protocol (iTIP) Part 956 Three: Scheduling Journal Entries", 957 [CAP] "Calendar Access Protocol" 958 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 960 7. Acknowledgments 962 The author is extremely grateful for the assistance, patience and 964 tolerance of the members of the CalSch working group. Their ideas and 966 suggestions are crucial to making this a useful document. In 968 particular, the author would like to thank 970 Anik Ganguly 972 Derik Stenerson 974 Frank Dawson 976 Gilles Fortin 978 Einar Stefferud 980 Their comments and ideas were particularly important in the 982 formulation of this draft. I would also like to thank Qualcomm, 984 Incorporated for allowing the time necessary to bring this effort to 986 fruition. 988 8. Author's address 990 For more information, please contact the author via Internet Mail. 992 John W. Noerenberg, II 994 Qualcomm, Incorporated 996 6455 Lusk Blvd 998 San Diego, CA 92131 1000 USA 1002 email: jwn2@qualcomm.com 1004 ph: +1 619 658 3510 1006 The "Internet Calendar Model Specification" is the work of the 1007 Internet 1009 Engineering Task Force Working Group on Calendaring and Scheduling. 1011 The chairman of that group, Anik Ganguly, may be reached at: 1013 Anik Ganguly 1015 Campbell Services, Inc. 1017 21700 Northwestern Highway 1019 10th Floor 1021 Southfield, MI 48075 1023 email: anik@ontime.com 1024 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 1026 9. Appendix -- Calendar protocol nomenclature 1028 Calendaring and Scheduling uses a rich lexicon of terms that are 1030 specific to the problems of scheduling events and reconciling 1032 conflicting requests for time and resources. This document will 1034 identify the major components of these systems, and show component 1036 relationships. However, for the sake of completeness and to serve as 1038 an introduction to the protocols in general, a more extensive list of 1040 terms, and brief definitions are included here. Essential parts of the 1042 system model have expanded definitions in this document where the 1044 components of the model are introduced. 1046 9.1 Calendaring lexicon 1048 Alarm, Reminder 1050 An asynchronous mechanism providing feedback for a pending or past 1052 event or to-do. 1054 Busy Time 1056 A period of time that is not available for scheduling. 1058 Calendar 1060 A particular collection of calendar objects. 1062 Calendar Object 1064 The objects that can be found in a calendar. The objects are 1066 events, to-dos, journals, free/busies, time zones and alarms. 1068 Objects also include properties and may include other objects. 1070 A calendar object is identified by unique delimiters. 1072 Calendar Date 1074 A day identified by its position within the calendar year. 1076 Calendar Scale 1078 A particular type of calendar year, for example, Gregorian, Buddhist 1080 Era, Japanese Emperor Era, Chinese Lunar, Islamic, and Jewish 1082 Calendars. 1084 Calendar Service 1086 A Calendar Service (CS) stores a collection of calendars and interacts 1088 with the Calendar User Agent (CUA) via the Calendar Access Protocol 1090 (CAP). 1092 Calendar User Agent (CUA) 1094 A CUA mediates the interactions between a calendar user and his 1096 calendar. It represents the information stored in the calendar to the 1098 user, and enables the user to manipulate it. This is a particular 1100 instance of the interactive process used by a calendar user. 1102 Coordinate Universal Time (UTC) 1104 The time scale maintained by the Bureau International de l'Heure 1106 (International Time Bureau). UTC is often incorrectly referred to as 1108 GMT. 1110 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 1112 Daylight Saving Time (DST) 1114 An adjustment to local time to accommodate annual changes in the 1116 number of daylight hours. DST is also known as Advanced Time, Summer 1118 Time, or Legal Time. Daylight Saving Time adjustments in the Southern 1120 Hemisphere are opposite to those in the Northern Hemisphere. 1122 Event 1124 A calendar object that defines a scheduled activity, minimally 1126 specified by a start and end calendar date and time of day and a 1128 description. 1130 Free Time 1132 A period of time available for scheduling on a calendar. 1134 FreeBusy 1136 FreeBusy objects describe blocks of allocated and unallocated time 1138 on a calendar. They do not contain a description why the time is 1140 allocated. 1142 Gregorian Calendar 1144 A calendar scale in general use beginning in 1582. The Gregorian 1146 Calendar scale is based on a solar calendar consisting of common years 1148 made up of 365 days and leap years made up of 366 days; both divided 1150 into 12 sequential months. 1152 Journal 1154 A calendar object that defines a collection of information intended 1156 for human presentation and is minimally specified by a calendar date 1158 and one or more descriptions. 1160 Local Time 1162 The clock time in public use in a locale. Local time is often 1164 referenced by the customary name for the time zone in which it is 1166 located. The relationship between local time and UTC is based on the 1168 offset(s) that are in use for a particular time zone. In general, the 1170 formula is as follows: 1172 local time = UTC + (offset) 1174 Period 1176 A duration of time, specified as either a defined length of time or by 1178 its beginning and end points. 1180 Properties 1182 Attributes that apply to calendar objects or calendars. A calendar 1184 object is a named set of properties. Properties can also be used 1186 to produce variants to suit a particular purpose. 1188 Recurrence Rule 1190 A notation used to represent repeating occurrences, or the exceptions 1192 to such a repetition of an event or a to-do. The recurrence rule can 1194 also be used in the specification of a time zone description. 1196 ietf-draft-calsch-mod-01.txt Internet Calendar Model J. Noerenberg 1198 Repeating Event or To-do 1200 An event or to-do that repeats for one or more additional occurrences. 1202 The recurrence may be defined with discrete dates and times and/or 1204 with a recurrence rule. 1206 Standard Time 1208 Introduced by Sir Sanford Fleming and others around 1870, standard 1210 time is a scheme for dividing the world into zones where the same time 1212 would be kept. The original proposal was to divide the world into 24 1214 zones, each zone having a width of 15 degrees of longitude. The center 1216 zone was originally the meridian passing through Greenwich, England, 1218 called Greenwich Mean Time (GMT). The time in the zones was 1220 decremented by one hour per zone going westwards and was incremented 1222 by one hour per zone going eastwards from GMT. Changes have been made 1224 to the original proposal to accommodate political boundaries. In 1226 addition, some countries and regions specify 30 or 45 minute offsets, 1228 rather than the full 60 minute offset. Standard time is also known as 1230 Winter Time in some regions. 1232 GMT and UTC are generally equivalent. However, by international 1234 agreement, the GMT term is discouraged in favor of the term UTC for 1236 all general time keeping. 1238 Time Zone 1240 A geographic region to which a specified offset from UTC applies. 1242 While offsets can frequently be calculated by knowing the longitudinal 1244 distance from Greenwich, England, local conventions frequently alter 1246 the calculation, complicating the determination of local time. Local 1248 convention may also assign a label to identify the time zone. There 1250 is no world-wide standard for labels. 1252 To-do 1254 A calendar object that defines an action item and is minimally 1256 specified by an effective calendar date and time of day, a due 1258 calendar date and time of day, a priority and a description. 1260 john noerenberg 1262 jwn2@qualcomm.com 1264 pager: jwn2@pager.qualcomm.com