idnits 2.17.1 draft-ietf-calsch-sch-00.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 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 962: '...g: This property SHOULD NOT include li...' RFC 2119 keyword, line 1413: '...ent descriptions MAY make use of the t...' RFC 2119 keyword, line 1415: '...ent descriptions SHOULD NOT assume tha...' RFC 2119 keyword, line 1418: '...ent descriptions MAY make use of the t...' RFC 2119 keyword, line 1420: '...ent descriptions SHOULD NOT assume tha...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 87 has weird spacing: '...nt also defin...' == Line 1502 has weird spacing: '...want to keep ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 25, 1996) is 10014 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 1521' is mentioned on line 181, but not defined ** Obsolete undefined reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Missing Reference: 'RFC 822' is mentioned on line 1195, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Unused Reference: 'MIME-CSCT' is defined on line 2299, but no explicit reference was found in the text == Unused Reference: 'NIST' is defined on line 2316, but no explicit reference was found in the text == Unused Reference: 'RFC-1522' is defined on line 2327, but no explicit reference was found in the text == Unused Reference: 'RFC-1738' is defined on line 2331, but no explicit reference was found in the text == Unused Reference: 'RFC-1835' is defined on line 2337, but no explicit reference was found in the text -- No information found for draft-dawson-csct - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MIME-CSCT' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIME-DIR' -- Possible downref: Normative reference to a draft: ref. 'MIME-PROP' == Outdated reference: A later version (-03) exists of draft-ietf-822ext-mime-reg-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1522 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Downref: Normative reference to an Historic RFC: RFC 1835 ** Obsolete normative reference: RFC 1872 (Obsoleted by RFC 2112) Summary: 18 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Calendar Working Group Derik Stenerson 3 INTERNET DRAFT Alec Dun 4 draft-ietf-calsch-sch-00.txt Microsoft 5 Expires May 30, 1997 November 25, 1996 7 MIME application/calendar Content Type 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document defines a MIME message format for openly scheduling 30 meetings with others across the Internet. This definition is 31 independent of any particular scheduling application. A new MIME 32 Content-Type "APPLICATION/CALENDAR" is defined to contain scheduling 33 data, including appointments, appointment requests for single events, 34 appointment requests for recurring events, appointment responses. The 35 scope of this revision of the draft is the MIME format for meeting 36 requests and responses. This the "on the wire" format; no attempt is 37 made to define the storage format for the calendar information. 39 Internet-Draft 11/25/96 41 Table of Contents 42 1. Overview............................................................3 43 1.1 Introduction .....................................................3 44 1.2 Scope ............................................................3 45 1.3 Appointment request/reply semantics ..............................4 46 2. Application/Calendar content type...................................5 47 2.1 Purpose, inheritance .............................................5 48 2.2 Registration .....................................................5 49 2.3 General usage, issues, restrictions ..............................7 50 3. Appointment Requests................................................9 51 3.1 Description ......................................................9 52 3.2 Properties .......................................................9 53 3.3 Usage Specifics .................................................28 54 3.4 General Examples ................................................39 55 4. Appointment Responses..............................................42 56 4.1 Description .....................................................43 57 4.2 Properties ......................................................43 58 4.3 Examples ........................................................44 59 5. Acknowledgements...................................................45 60 6. Author's Addresses.................................................46 61 Internet-Draft 11/25/96 63 1. Overview 65 1.1 Introduction 67 With the recent explosion in Personal Information Management and 68 electronic mail based Group Scheduling software, there is a clear and 69 present need for a standard means for such software to inter-operate 70 across the Internet. Individuals and groups in all parts of the world 71 need to be able to communicate schedule information and arrange 72 meetings with one another in order to conduct business. Given the ties 73 to messaging that exist in the arena of group communication and 74 scheduling, the MIME [RFC-1521] message format and its extensible 75 architecture is an obvious choice for an infrastructure to base a 76 means for transporting calendaring data across the Internet. 78 This document defines a standard for using a new MIME Content-Type 79 "application/calendar" to encapsulate meeting request and response 80 data in a textual format. 82 The "application/calendar" Content-Type defines a general framework 83 and format for holding calendaring information in a simple "type: 84 value" format. This format and value datatype definitions are based on 85 the "application/directory" specification as defined in [MIME-DIR]. 86 Mechanisms are included to specify alternate character set, language, 87 encoding and other meta-information. This document also defines the 88 procedure by which particular application/calendar Content-Type 89 formats, called profiles, may be defined and registered, and the 90 conventions such formats must follow. These profiles will be used to 91 help applications processing the data to interpret it correctly. For 92 example, profile will be used to define an appointment request and 93 another will define an appointment response. It is expected that other 94 documents will be produced that define formats for various 95 applications. 97 1.2 Scope 99 The scope of this draft is the base definition of the 100 application/calendar MIME Content-Type, the definition of the profile 101 format for appointment requests and responses, and to discuss the 102 issues surrounding these concepts. This the "on the wire" format. No 103 attempt is made to outline the storage format for the calendar 104 information, the features that a scheduling application should 105 support, nor any of the user interface characteristics of such 106 calendaring and scheduling applications. 108 Internet-Draft 11/25/96 110 1.3 Appointment request/reply semantics 112 1.3.1 Appointment Request 114 An appointment is a collection of properties representing a range of 115 time on a individual's or group's calendar that is associated with an 116 activity or event, often involving interactions with other individuals 117 or groups. For example, it may be a 1 hour conference call from 14:00 118 to 15:00. Such an scheduled event is created by one individual (the 119 organizer) requesting another individual or group (attendees) to 120 participate in an activity at a particular time. To encapsulate such a 121 request in a MIME message using the "application/calendar" Content- 122 Type, we define a REQUEST profile to represent the required collection 123 of attributes that make up a appointment request. 125 Figure 1 describes the appointment request flow: 127 +-------------+ 128 | Appointment |_____________\ Attendee(s) 129 | Request | / 130 +-------------+ 132 Figure 1 : Appointment requests 134 An appointment request can be for single event or for one which occurs 135 more than once (recurring event). For example, weekly meetings could 136 be described using a single appointment with a recurring pattern, 137 thereby reducing the storage requirements. 139 1.3.2 Appointment Response 141 Appointment response messages update attendance status for each 142 attendee, and are issued by the attendee after receiving an 143 appointment request. 145 Figure 2 describes the appointment request/response flow: 147 +-------------+ 148 | Appointment |_____________\ Attendee(s) 149 | Request | / | 150 +-------------+ | 151 | 152 +-------------+ 153 Appointment /_____________| Appointment | 154 Organizer \ | Response | 155 +-------------+ 157 Internet-Draft 11/25/96 159 Figure 2 : Appointment response 161 Here, the appointment organizer issues an appointment request. The 162 attendee receives the request and issues an appointment response back 163 to the organizer. 165 Note that appointment responses are not required for each appointment 166 request, and in some cases, particularly informational appointment 167 requests sent to a large group of people, the meeting organizer will 168 find responses undesirable. 170 2. Application/Calendar content type 172 2.1 Purpose, inheritance 174 The purpose of the "application" Content-Type as defined in section 175 7.4 of [RFC-1521] is "for data to be processed by mail-based uses of 176 application programs." Calendaring and scheduling data falls into this 177 category as suggested by [RFC-1521]. The "application/calendar" 178 Content-Type is used to hold textual calendaring and scheduling 179 information. The MIME Calendar Content Type may utilize any of the 180 standard MIME content header fields such as those defined by [RFC 181 822], [RFC 1521], and [RFC 1766] 183 The definition is fashioned after and borrows heavily from the 184 application/directory Content-Type specification as defined in [MIME- 185 DIR]. 187 2.2 Registration 189 The application/calendar is defined as follows, using the MIME media 190 type registration template from [MIME-REG]. 192 To: ietf-types@uninett.no 193 Subject: Registration of MIME media type application/calendar 195 MIME media type name: application 197 MIME subtype name: calendar 199 Required parameters: none 201 Optional parameters: charset, profile 203 Internet-Draft 11/25/96 205 The "charset" parameter is as defined in [RFC-1521] for other body 206 parts. It is used to identify the default character set used within 207 the body part. Note that alternate character sets can be specified on 208 a per value basis using the "charset" type parameter as specified for 209 "contentline" in [MIME-DIR]. 211 The "profile" parameter is used as a guide to applications 212 interpreting the information contained within the body part. It should 213 not be used to exclude or require particular pieces of information 214 unless a profile definition specifically calls for this behavior. The 215 value of the "profile" parameter is defined as follows. Note that 216 profile names are case insensitive (i.e., the profile name 217 "Appointment" is the same as "APPOINTMENT" and "appointment" and 218 "apPointMent"). 220 profile := x-token / iana-token 222 x-token := 226 iana-token := 231 Specific profiles definitions are discussed in detail in this 232 document. 234 Encoding considerations: As specified by the Content-Transfer-Encoding 235 header field. Note that each value may also have an inline encoding 236 associated with it. This encoding is independent of the encoding for 237 the body part as a whole (i.e., inline encodings are performed first, 238 then Content-Transfer-Encoding is applied to the entire body part). 240 Security considerations: Calendar item information may be public or 241 private. This specification does not include any access control 242 mechanism to guarantee data privacy on a per-property or per Content- 243 Type basis. Also, properties used in this Content-Type may include 244 references to Uniform Resource Locators that may be programmed 245 resources. Implementers and users of this specification should be 246 aware of the network security implications of accepting and parsing 247 such information. 249 Interoperability considerations: Applications and downstream customers 250 of this data must understand the types of information within the 251 Content-Type, as defined in this document. 253 Internet-Draft 11/25/96 255 Published specification: The published specification is as defined in 256 this document. 258 Person & email address to contact for further information: 260 Derik Stenerson 261 Microsoft Corporation 262 One Microsoft Way 263 Redmond, WA 98052 264 USA 265 deriks@microsoft.com 266 +1.206.936.5522 268 Intended usage: COMMON 270 Author/Change controller: 272 Derik Stenerson 273 Microsoft Corporation 274 One Microsoft Way 276 Redmond, WA 98052 277 USA 278 deriks@microsoft.com 279 +1.206.936.5522 281 Alec Dun 282 Microsoft Corporation 283 One Microsoft Way 284 Redmond, WA 98052 285 USA 286 alecdu@microsoft.com 287 +1.206.936.4544 289 2.3 General usage, issues, restrictions 291 The "application/calendar" Content-Type is used to hold textual 292 calendaring and scheduling information. The MIME Calendar Content Type 293 may utilize any of the standard MIME content header fields 295 Example: 297 Content-Type: application/calendar; charset=iso-8859-1 298 Content-Transfer-Encoding: quoted-printable 299 Content-Language: de 300 Content-ID: 302 Internet-Draft 11/25/96 304 2.3.1 Use of the multipart/related Content-Type 306 The multipart/related Content-Type can hold the application/calendar 307 body part and additional body part(s) for content that already has a 308 natural MIME representation. For example, along with the textual 309 information describing the event, an appointment request could also 310 include a map showing the location in the form of a JPEG image. 312 The root body part within the multipart/related body part is specified 313 as defined in [RFC-1872] by a "start" parameter, or it is the first 314 body part in the absence of such a parameter. The root body part must 315 have a Content-Type of "application/calendar". This part holds text 316 information, optionally defines the name and source of the 317 information, and makes reference to subsequent body parts holding 318 additional text and/or non-text item property information via their 319 URL Content-IDs as explained in [MIME-DIR]. Body parts referred to do 320 not have to be in any particular order. 322 2.3.2 Body part Content 324 In general, the format for the content is as described in the [MIME- 325 DIR] "contentline". In simple terms, the content consists of one or 326 more CRLF-separated lines. Each "contentline" or property is in the 327 form of a simple "type: value" format. Specific exceptions, will be 328 covered in detail in this document. 330 The collection of "type: value" pairs included in the body part are 331 used to define the calendaring data being transmitted. These type 332 definitions, once they are defined, can be reused to defined unique 333 types calendaring objects that convey specific meaning when 334 interpreted together. The Content-Type "profile" parameter is used to 335 name this unique object, so applications can properly interpret the 336 meaning calendaring data enclosed within the body part. Profiles are 337 for appointment requests and responses are defined in this document. 339 A application/calendar body part can only contain one calendaring 340 object. For example, one appointment request or one appointment 341 response per application/calendar body part. If the sending agent 342 wishes to enclose multiple requests in a single message, multiple body 343 parts should be used, using the multipart/mixed MIME Content-Type. 344 This has an added advantage in that if the client is using IMAP as the 345 access protocol, it could access individual appointments from the 346 message by body part. 348 Note that the *types* of the properties (text, d-t, bool) are also 349 defined in [MIME-DIR]. 351 Internet-Draft 11/25/96 353 3. Appointment Requests 355 3.1 Description 357 The Appointment REQUEST content profile definition 359 Profile name: REQUEST 361 Profile purpose: Indicates schema of REQUEST item 363 Profile intended usage: COMMON 365 Example: 367 Content-Type: application/calendar; profile="request" 369 3.2 Properties 371 An Appointment Request is made up of a collections of properties, 372 which are grouped logically according to function below. 374 Appointment time properties: The appointment time properties describe 375 the start and end time of the appointment, including time zone 376 information (either explicit or encoded), and optionally including 377 recurrence pattern information to describe a repeating event. The time 378 properties required for an appointment are: 380 Start 381 End 383 and the Recurrence Pattern property names, all of which are defined 384 above in Section 3.2.3: 386 RPDescr 387 DW 388 DM 389 DY 390 WY 391 MY 392 HI 393 DI 394 WI 395 MI 396 YI 397 TStartInst 399 Internet-Draft 11/25/96 401 TEndInst 402 DStart 403 DEnd 404 DExcept 405 DOrigExcept 406 TZID 407 TZBias 408 TZDstBias 409 TZStdBias 410 TZStdTrans 411 TZDstTrans 412 TZDS 413 TZSrc 414 CalTypeID 416 Core appointment properties: These properties are the base components 417 that make up an appointment, some of which are optional. 419 Description 420 Summary 421 Location 422 Resources 423 Confidentiality 424 Priority 425 Category 427 Attendees: Properties that represent the individuals or groups that 428 will participate in the activity. 430 AttendReq 431 AttendOpt 432 AttendFyi 433 AttendOwner 435 Appointment data processing properties: appointment attributes used in 436 processing the scheduling data. 438 ID 439 ApptVersion 440 ApptID 441 Rsvp 442 RequestType 444 3.2.1 Example: Simple meeting request. 446 Internet-Draft 11/25/96 448 This example demonstrates a simple appointment request in the 449 application/calendar MIME Content-Type. 451 To: Larry , Curly , 452 Moe 453 From: Shemp 454 Subject: Hey, we need to make some money! 455 MIME-Version: 1.0 456 Message-ID: 457 Content-Type: application/calendar; profile="request" 459 Start;value=d-t: 22 Oct 1996 17:00:00 UT 460 End;value=d-t: 22 Oct 1996 19:30:00 UT 461 ID: 462 Location: Conference Room 3384 463 Categories: Business 464 Categories: Review 465 Summary: A new plan 466 Resources: Projector 467 Resources: VCR 468 Resources: Rubber Mallet 469 Description: Let's make a new plan. Any conflicts will be 470 resolved the Rubber Mallet. Nuk! Nuk! Nuk!" 472 This example shows a simple one time meeting request, using a variety 473 of the optional properties. 475 3.2.2 appointment time properties 477 The single instance start and end date time property names are defined 478 below: 480 3.2.2.1 Start 482 Name: Start 483 Data type: D-T 484 Purpose: Start date and time of the item, in UTC. 485 Encoding: 486 Required: YES 487 Multi-valued: SOMETIMES 488 Intended usage: COMMON 490 3.2.2.2 End 492 Name: End 493 Data type: D-T 495 Internet-Draft 11/25/96 497 Purpose: End date and time of the item in UTC. 498 Encoding: 499 Required: YES 500 Multi-valued: SOMETIMES 501 Intended usage: COMMON 503 3.2.3 Recurrence Properties 505 3.2.3.1 DW 507 Name: DW 508 Data type: TEXT 509 Purpose: (DaysOfWeek) A list of the individual days of the week 510 that the appointment can occur. 511 Encoding: Sun, Mon, Tue, Wed, Thu, Fri, Sat. The values are 512 case insensitive and non-localizable. 513 Special notes: For example: A recurring weekly Appointment that 514 occurs on Monday and Wednesday sets DW equal to "Mon, 515 Wed". 516 Required: NO 517 Multi-valued: ALWAYS 518 Intended usage: COMMON 520 3.2.3.2 DM 522 Name: DM 523 Data type: INT 524 Purpose: (DaysOfMonth) 525 A list of the individual days of the month that the 526 appointment can occur. 527 Encoding: 1 to 31 / -31 to -1. 0 is undefined. 528 Special notes: Negative values specify an offset from the end 529 of the month. Negative one is the last day of the 530 month. For example, a recurring monthly Appointment 531 that occurs on the first and tenth days sets 532 DM equal to "1, 10". 533 Required: NO 534 Multi-valued: ALWAYS 535 Intended usage: COMMON 537 3.2.3.3 DY 539 Name: DY 541 Internet-Draft 11/25/96 543 Data type: INT 544 Purpose: (DaysOfYear) 545 A list of the individual days of the year that the 546 appointment can occur. 547 Encoding: 1 to 366 / -366 to -1. 0 is undefined. 548 Special notes: Negative values specify an offset from the end 549 of the year. Negative one is the last day of the 550 year. For example, a recurring yearly Appointment 551 that occurs on the forty-first and two hundredth days 552 sets DY equal to "41, 200". 553 Required: NO 554 Multi-valued: ALWAYS 555 Intended usage: LIMITED USE 557 3.2.3.4 WY 559 Name: WY 560 Data type: INT 561 Purpose: (WeeksOfYear) 562 A list of the individual weeks of the year that the 563 appointment can occur. 564 Encoding: 1 - 53 565 Special notes: For example, a recurring appointment that occurs 566 in the fourth and twenty-fifth weeks sets WY 567 equal to "4, 25". 568 Required: NO 569 Multi-valued: SOMETIMES 570 Intended usage: LIMITED USE 572 3.2.3.5 MY 574 Name: MY 575 Data type: INT 576 Purpose: (MonthsOfYear) 577 A list of the individual months of the year that the 578 appointment can occur. 579 Encoding: 1 - 12 580 Special notes: For example, a recurring appointment that occurs 581 in the fourth and tenth months sets MY equal 582 to "4, 10". 583 Required: NO 584 Multi-valued: SOMETIMES 585 Intended usage: COMMON 587 Internet-Draft 11/25/96 589 3.2.3.6 HI 591 Name: HI 592 Data type: TIME 593 Purpose: (HourInterval) 594 Interval between hours for a recurrence pattern. 595 Encoding: 596 Special notes: 597 Time Zone information, if specified as part of time 598 is ignored. 599 For example, run security sweep every 45 minutes, HI = 600 00:45 601 Required: NO 602 Multi-valued: NEVER 603 Intended usage: COMMON 605 3.2.3.7 DI 607 Name: DI 608 Data type: INT 609 Purpose: (DayInterval) 610 Interval between days for a recurrence pattern. 611 Encoding: 612 Special notes: For example, every other day has 613 DI = 2. 614 Required: NO 615 Multi-valued: NEVER 616 Intended usage: COMMON 618 3.2.3.8 WI 620 Name: WI 621 Data type: INT 622 Purpose: (WeekInterval) 623 Interval between weeks for a recurrence pattern. 624 Encoding: 625 Special notes: For example, pay day every two weeks has a 626 WI of 2. 627 When the value of WI is 5 and is combined with 628 MI, WI it takes on the meaning of "Last". For 629 Example, to specify the last weekday of the 630 month: 631 WI: 5 632 MI: 1 634 Internet-Draft 11/25/96 636 DW: Mon, Tue, Wed, Thu, Fri 638 Required: NO 639 Multi-valued: SOMETIMES 640 Intended usage: COMMON 642 3.2.3.9 MI 644 Name: MI 645 Data type: INT 646 Purpose: (MonthInterval) 647 Interval between months for a recurrence pattern. 648 Encoding: 649 Special notes: For example, a quarterly appointment, every 650 three months, has a MI of 3. Property 651 taxes, due every six months, have a MI 652 of 6. 653 Required: NO 654 Multi-valued: SOMETIMES 655 Intended usage: COMMON 657 3.2.3.10 YI 659 Name: YI 660 Data type: INT 661 Purpose: (YearInterval) 662 Interval between years for a recurrence pattern. 663 Encoding: 664 Special notes: For example, the Summer Olympics have a 665 YI of 4. 666 Required: NO 667 Multi-valued: SOMETIMES 668 Intended usage: COMMON 670 3.2.3.11 TStartInst 672 Name: TStartInst 673 Data type: Time 674 Purpose: Start time for the appointment within the recurring 675 pattern. 676 Encoding: local time or UTC is acceptable 677 Special notes: if absent, the appointment is assumed to start 678 at 00:00:00 on the date specified for DStart. 679 Required: NO 680 Multi-valued: SOMETIMES 682 Internet-Draft 11/25/96 684 Intended usage: COMMON 686 3.2.3.12 TEndInst 688 Name: TEndInst 689 Data type: Time 690 Purpose: End time for the appointment within the recurring 691 pattern. 692 Encoding: local time or UTC is acceptable 693 Special notes: if absent, the appointment is assumed to end 694 at 23:59:59 on the date specified for DEnd. 695 Required: NO 696 Multi-valued: SOMETIMES 697 Intended usage: COMMON 699 3.2.3.13 DStart 701 Name: DStart 702 Data type: DATE 703 Purpose: Start date for the recurring pattern. 704 Encoding: The time zone information is specifically not 705 required in date format. Instead it is specified 706 separately as an unambiguous set of rules that can be 707 interpreted easily by the recipient. If the time 708 zone is specified in the date format, the time zone 709 rules should have precedence. 710 Required: YES 711 Multi-valued: NEVER 712 Intended usage: COMMON 714 3.2.3.14 DEnd 716 Name: DEnd 717 Data type: DATE 718 Purpose: End date for the recurrence pattern. 719 Encoding: The time zone information is specifically not 720 required in date format. Instead it is specified 721 separately as an unambiguous set of rules that can be 722 interpreted easily by the recipient. If the time 723 zone is specified in the date format, the time zone 724 rules should have precedence. 725 Special notes: DEnd will be used to calculate the number of 726 transitions in and out of DST that must be listed as 727 part of the time zone rules for the recurring 729 Internet-Draft 11/25/96 731 appointment. 732 Required: YES 733 Multi-valued: NEVER 734 Intended usage: COMMON 736 3.2.3.15 RPDescr 738 Name: RPDescr 739 Data type: TEXT 740 Purpose: Human-readable definition of recurrence pattern. 741 Encoding: 742 Special notes: Some examples of this string are 743 "Every 3 months, on the 12th day, from 12/1/96" 744 "Every week on Wednesday from 7/10/96 to 745 12/31/96" 746 This property is highly-recommended when sending 747 a recurring appointment request so clients have 748 a text description of the pattern to display. 749 Required: NO 751 Multi-valued: SOMETIMES 752 Intended usage: COMMON 754 3.2.3.16 DExcept 756 Name: DExcept 757 Data type: DATE 758 Purpose: Instance date of an exception to the recurring 759 pattern. 760 Encoding: 761 Special notes: An exception is an appointment or appointments 762 that are excluded from a recurrence pattern. 763 Required: NO 764 Multi-valued: ALWAYS 765 Intended usage: COMMON 767 3.2.3.17 DOrigExcept 769 Name: DOrigExcept 770 Data type: DATE 771 Purpose: Original Instance date of the exception to the 772 recurrence pattern. 773 Encoding: 774 Required: NO 775 Multi-valued: NEVER 776 Intended usage: COMMON 778 Internet-Draft 11/25/96 780 3.2.3.18 StartOfWeek 782 Name: StartOfWeek 783 Data type: TEXT 784 Purpose: A list of the individual days of the week that the 785 week can start on. 786 Encoding: Sun, Mon, Tue, Wed, Thu, Fri, Sat. The values are 787 case insensitive and non-localizable. 788 Special notes: For example: 789 European calendar often start on Monday. 790 This is only required for calculating patterns 791 when the week interval is greater than one. 792 Required: NO 793 Multi-valued: ALWAYS 794 Intended usage: COMMON 796 3.2.3.19 TZID 798 Name: TZID 799 Data type: TEXT 800 Purpose: An ID that can be used to identify the time zone 801 (could be a name, a number, likely that we want an 802 IANA registry of time zone/daylight rule names) 803 Encoding: 804 Special Notes: 805 Required: NO 806 Multi-valued: NEVER 807 Intended usage: COMMON 809 3.2.3.20 TZBias 811 Name: TZBias 812 Data type: TEXT 813 Purpose: time delta from UTC (e.g. +08:00) 814 Encoding: [sign] hour, as defined in [RFC-822] 815 Special Notes: if a sign "-" is not specified, it is 816 assumed to be a positive value 817 Required: YES 818 Multi-valued: NEVER 819 Intended usage: COMMON 821 Internet-Draft 11/25/96 823 3.2.3.21 TZDstBias 825 Name: TZDstBias 826 Data type: TEXT 827 Purpose: time delta used in "Daylight Savings Time", 828 e.g. -01:00 (one hour) 829 Encoding: [sign] hour, as defined in [RFC-822] 830 Special Notes: if a sign "-" is not specified, it is 831 assumed to be a non-negative value. 832 Can be omitted, if the value is -01:00. 833 Required: NO 834 Multi-valued: NEVER 835 Intended usage: COMMON 837 3.2.3.22 TZStdBias 839 Name: TZStdBias 840 Data type: TEXT 841 Purpose: time delta used in "Standard Time", 842 e.g. 00:00 843 Encoding: [sign] hour, as defined in [RFC-822] 844 Special Notes: if a sign "-" is not specified, it is 845 assumed to be a non-negative 846 can be omitted if the value is 0, but should be 847 respected if present 848 Required: NO 849 Multi-valued: NEVER 850 Intended usage: LIMITED USE 852 3.2.3.23 TZStdTrans 854 Name: TZStdTrans 855 Data type: D-T (date-time) 856 Purpose: a generated list of one or more date-time values that 857 describe the transition to Standard Time for the 858 duration of the recurring pattern. 859 Encoding: 860 Special Notes: Client implementers may want to restrict the 861 end date for a recurring pattern to limit the number 862 of items in the list. 863 Not required if no transitions are used. 864 Required: NO 865 Multi-valued: SOMETIMES 866 Intended usage: COMMON 868 Internet-Draft 11/25/96 870 3.2.3.24 TZDstTrans 872 Name: TZDstTrans 873 Data type: D-T (date-time) 874 Purpose: a generated list of one or more date-time values that 875 describe the transition to Daylight Savings Time 876 for the duration of the recurring pattern. 877 Encoding: 878 Special Notes: Client implementers may want to restrict the 879 end date for a recurring pattern to limit the number 880 of items in the list. 881 Not required if no transitions are used. 882 Required: NO 883 Multi-valued: SOMETIMES 884 Intended usage: COMMON 886 3.2.3.25 TZDS 888 Name: TZDS 889 Data type: DATE 890 Purpose: A date stamp to indicate the freshness of this time 891 zone definition. Could be used by the recipient 892 application to decided whether to use this data or 893 attempt to use a newer rule. 894 Encoding: 895 Special Notes: 896 Required: NO 897 Multi-valued: NEVER 898 Intended usage: LIMITED USE 900 3.2.3.26 TZSrc 902 Name: TZSrc 903 Data type: URL 904 Purpose: URL to approved IANA time zone specification 905 information. Using this client may attempt to gather 906 more up to date time zone information. 907 Encoding: 908 Special Notes: 909 Required: NO 910 Multi-valued: NEVER 911 Intended usage: LIMITED USE 913 Internet-Draft 11/25/96 915 3.2.3.27 CalTypeID 917 Name: CalTypeID 918 Data type: TEXT 919 Purpose: an identifier for the reference Calendar. Choice 920 of calendar will affect date specifications and 921 recurrence patterns 922 Encoding: one of the following case insensitive values 923 "Gregorian". Other types yet to be defined 924 Special Notes: "Gregorian" is assumed if not specified 925 If a unrecognized/unsupported calendar type is 926 received, the client should issue an appropriate 927 error. 928 It is expected that additional calendar types 929 will need to be defined and registered. 930 Required: NO 931 Multi-valued: NEVER 932 Intended usage: COMMON 934 3.2.4 Core appointment properties 936 3.2.4.1 Description 938 Name: Description 939 Data type: TEXT default, URL 940 Purpose: A user-specified description of the appointment. 941 Encoding: 942 Special notes: This property is intended to accommodate more 943 verbose descriptions than the Summary property. 944 For example, it could be used to keep the agenda 945 for a meeting. 946 This property may refer to another MIME body 947 part. In particular, a URL to an HTML body part 948 would give you the ability to have a rich-text 949 description. 950 Required: NO 951 Multi-valued: SOMETIMES 952 Intended usage: COMMON 954 3.2.4.2 Summary 956 Name: Summary 957 Data type: TEXT 958 Purpose: A brief description of the appointment 960 Internet-Draft 11/25/96 962 Encoding: This property SHOULD NOT include line breaks 963 Required: NO 964 Multi-valued: SOMETIMES 965 Intended usage: COMMON 967 3.2.4.3 Location 969 Name: Location 970 Data type: TEXT 971 Purpose: Describes the location of the appointment 972 Encoding: 973 Special notes: [none] 974 Required: NO 975 Multi-valued: SOMETIMES 976 Intended usage: COMMON 978 3.2.4.4 Resources 980 Name: Resources 981 Data type: TEXT 982 Purpose: Contains resources needed for the appointment 983 Encoding: 984 Special Notes: Possible resources include, 985 Projector 986 VCR 987 Computer 988 Coffee Machine 989 Car 990 Required: NO 991 Multi-valued: ALWAYS 992 Intended usage: COMMON 994 3.2.4.5 Confidentiality 996 Name: Confidentiality 997 Data type: TEXT 998 Purpose: Rating of appointment's confidentiality. 999 Encoding: Three possible values are defined. 1000 "Public": Item is viewable by all users, subject to 1001 global security restrictions of the system. 1002 The item affects free-busy time 1003 calculations and display. 1004 "Private": Item is not viewable by all users, subject 1005 to security restrictions of the system. 1007 Internet-Draft 11/25/96 1009 The item affects free-busy time 1010 calculations and display. 1011 "Confidential": Item is not viewable by all users, 1012 subject to security restrictions of the 1013 system. The item does not affect free-busy 1014 time calculations and display. 1015 All values are case insensitive. 1016 Special notes: Absence of this property indicates that the item 1017 is "Public". 1018 Required: NO 1019 Multi-valued: SOMETIMES 1020 Intended usage: COMMON 1022 3.2.4.6 Priority 1024 Name: Priority 1025 Data type: INT 1026 Purpose: Denotes appointment priority 1027 Encoding: This value should not be negative 1028 Special Notes: Smaller values denote higher priority. 1029 Required: NO 1030 Multi-valued: SOMETIMES 1031 Intended usage: COMMON 1033 3.2.4.7 Category 1035 Name: Category 1036 Data type: TEXT 1037 Purpose: Contains appointment categorisations 1038 Encoding: 1039 Special Notes: Possible categories include, 1040 Education 1041 Holiday 1042 Meeting 1043 Miscellaneous 1044 Phone Call 1045 Sick Day 1046 Special Occasion 1047 Travel 1048 Vacation 1049 Business 1050 Personal 1051 Required: NO 1052 Multi-valued: ALWAYS 1053 Intended usage: COMMON 1055 Internet-Draft 11/25/96 1057 3.2.5 Attendee properties. 1059 3.2.5.1 AttendReq 1061 Name: AttendReq 1062 Data type: TEXT default, URL 1063 Purpose: Optional property used to list required attendees. 1064 Encoding: 1065 Special notes: If the property is absent, it is assumed that 1066 the recipients on the [RFC 822]"To:" header 1067 are the required recipients. 1068 If on the other hand, the property is present, 1069 the recipients listed in the "To:" header are 1070 ignored. 1071 This may be a multi-valued [RFC-822] recipient 1072 list, or it may be of type URL, referring to a 1073 vCard object, for example, to allow access to 1074 more data than just the address. 1075 Multiple attendees may be specified by including 1076 multiple instances of this property within the 1077 MIME calendaring entity. 1078 Required: NO 1079 Multi-valued: SOMETIMES 1080 Intended usage: COMMON 1082 3.2.5.2 AttendOpt 1084 Name: AttendOpt 1085 Data type: TEXT default, URL 1086 Purpose: Optional property used to list optional attendees. 1087 Encoding: 1088 Special notes: If the property is absent, it is assumed that 1089 the recipients on the [RFC 822]"Cc:" header 1090 are the required recipients. 1091 If on the other hand, the property is present, 1092 the recipients listed in the "Cc:" header are 1093 ignored. 1094 This may be a multi-valued [RFC-822] recipient 1095 list, or it may be of type URL, referring to a 1096 vCard object, for example, to allow access to 1097 more data than just the address. 1098 Multiple attendees may be specified by including 1099 multiple instances of this property within the 1100 MIME calendaring entity. 1102 Internet-Draft 11/25/96 1104 Required: NO 1105 Multi-valued: SOMETIMES 1106 Intended usage: COMMON 1108 3.2.5.3 AttendFyi 1109 Name: AttendFyi 1110 Data type: TEXT default, URL 1111 Purpose: Optional property used to list attendees to receive 1112 the request as a "for your information" (FYI) 1113 Encoding: 1114 Special notes: If the property is absent, it is assumed that 1115 the recipients on the [RFC 822]"Bcc:" header 1116 are the required recipients. 1117 If on the other hand, the property is present, 1118 the recipients listed in the "Bcc:" header are 1119 ignored. 1120 This may be a multi-valued [RFC-822] recipient 1121 list, or it may be of type URL, referring to a 1122 vCard object, for example, to allow access to 1123 more data than just the address. 1124 Multiple attendees may be specified by including 1125 multiple instances of this property within the 1126 MIME calendaring entity. 1127 Required: NO 1128 Multi-valued: SOMETIMES 1129 Intended usage: COMMON 1131 3.2.5.4 AttendOwner 1133 Name: AttendOwner 1134 Data type: TEXT default, URL 1135 Purpose: Optional property used to list the owner(s) attendees. 1136 Encoding: 1137 Special notes: If the property is absent, there is no owner(s). 1138 This may be a multi-valued [RFC-822] recipient 1139 list, or it may be of type URL, referring to a 1140 vCard object, for example, to allow access to 1141 more data than just the address. 1142 Multiple attendees may be specified by including 1143 multiple instances of this property within the 1144 MIME calendaring entity. 1145 Required: NO 1146 Multi-valued: SOMETIMES 1147 Intended usage: COMMON 1149 Internet-Draft 11/25/96 1151 3.2.6 Appointment data processing property name definitions 1153 3.2.6.1 ID 1155 Name: ID 1156 Data type: TEXT 1157 Purpose: Unique ID for the parent item 1158 Encoding: ID format is the same as MessageID, as described in 1159 [RFC 822] 1160 Special notes: An ID is necessary to correlate responses with 1161 appointment requests and recurrence exceptions with 1162 parent recurrences. 1163 Required: NO 1164 Multi-valued: NEVER 1165 Intended usage: COMMON 1167 3.2.6.2 ApptVersion 1169 Name: ApptVersion 1170 Data type: D-T 1171 Purpose: Datetime of the last change to the appointment that 1172 would invalidate attendee responses prior to the 1173 change. An example of such a change is the 1174 rescheduling of an appointment. 1175 Special notes: Absence of this property implies that all 1176 attendees' responses are valid. 1177 Encoding: 1178 Required: NO 1179 Multi-valued: NEVER 1180 Intended usage: COMMON 1182 3.2.6.3 ApptID 1184 Name: ApptID 1185 Data type: TEXT 1186 Purpose: ID of the parent recurring item. 1187 Special note: If an appointment needs to be rescheduled, the 1188 client generates a new appointment request with 1189 the ApptID property equal to the original 1190 appointment's ID property. Recipients need to 1191 verify whether an appointment request is for a 1192 new appointment, cancellation, or rescheduled 1193 appointment. 1194 Encoding: ApptID format is the same as MessageID, as 1195 described in [RFC 822] 1197 Internet-Draft 11/25/96 1199 Required: NO 1200 Multi-valued: NEVER 1201 Intended usage: COMMON 1203 3.2.6.4 Rsvp 1205 Name: Rsvp 1206 Data type: BOOL 1207 Purpose: Flag denoting whether the appointment organizer 1208 requests an attendance response from appointment 1209 attendees. 1210 Encoding: 1211 Special notes: TRUE = response is requested, 1212 FALSE = response is not requested. 1213 Some appointments do not require 1214 attendance tracking or the organizer 1215 does not care. This property should 1216 be set accordingly. 1217 If the property is absent, it is 1218 assumed FALSE. 1219 Required: NO 1220 Multi-valued: SOMETIMES 1221 Intended usage: COMMON 1223 3.2.6.5 RequestType 1225 Name: RequestType 1226 Data type: TEXT 1227 Purpose: Indicates the type of the request. 1228 Encoding: One of the following values: 1229 "Request" Request to attend appointment. 1230 "Cancel" Request to cancel appointment. 1231 Values are case insensitive. 1232 Special Notes: If the value is absent, "Request" is assumed. 1233 Required: NO 1234 Multi-valued: NEVER 1235 Intended usage: COMMON 1237 3.3 Usage Specifics 1239 Here is some additional information on constructing and sending 1240 meeting requests. 1242 Internet-Draft 11/25/96 1244 3.3.1 Date, Time, and Time zone issues 1246 3.3.1.1 Introduction 1248 Before defining the collection of properties used to specify the 1249 appointment, a discussion of the requirements for specifying event 1250 time is required. Representing the time and date in an unambiguous 1251 manner such that all recipients can accurately interpret it is 1252 critical for scheduling applications. The problem of specifying a date 1253 and time is simple when an event and all attendees are in one 1254 location. However, when the attendees and location span multiple time 1255 zones, more care is required to accurately communicate a fixed time 1256 due to the variety of rules that define these time zones, and is 1257 additionally complicated by the fact that over time these rules change 1258 in unpredictable ways (government edict, etc.). 1260 3.3.1.2 Definitions 1262 Before continuing the discussion, here are some useful definitions: 1263 . Local time: The "by the clock time" for your location. 1264 . Time zone bias: The time delta from the local time at the zero 1265 (prime) meridian, usually in hours and minutes, based roughly on 1266 the difference in longitude of your location and the zero meridian 1267 (every 15 degrees of longitude represents one hour) 1268 . Standard Time (ST) bias: Rarely, if ever used. The time delta used 1269 in calculating Standard Time. 1270 . Daylight Savings Time (DST) bias: The time delta used in 1271 calculating DST. Usually -60 minutes. 1272 . Standard Time Transition: The rule that describes when the 1273 transition to ST starts. Can be a pattern such as "Last Sunday in 1274 October at 2:00:00 AM", or a specific date and time. Not all zones 1275 switch on the same day and time, in there are 17 or more different 1276 rules. 1277 . Daylight Savings Time Transition: The rule that describes when the 1278 transition to DST starts. Can be a pattern such as "First Sunday 1279 in April at 2:00:00 AM", or a specific date and time. 1280 . Coordinated Universal Time (UTC): Often used as a means to specify 1281 time in a unambiguous manner. UTC = local time + Bias, where Bias 1282 is either(Time zone bias + ST bias) or (Time zone bias + DST bias). 1284 For example, UTC for 9am Pacific Standard Time is 1286 UTC = 0900 + 0800 + 0 = 1700 1288 And, UTC for 9am Pacific Daylight Savings Time is 1290 Internet-Draft 11/25/96 1292 UTC = 0900 + 0800 + (-0100) = 1600 1294 . A note on GMT vs UTC: Greenwich Mean Time (GMT) is a 24 hour 1295 astronomical time system based on the local time at Greenwich, 1296 England. GMT can be considered equivalent to Coordinated Universal 1297 Time (UTC) when fractions of a second are not important. However, 1298 by international agreement, the term UTC is recommended for all 1299 general timekeeping applications, and use of the term GMT is 1300 discouraged. 1302 3.3.1.3 Single Event Date and Time Specification 1304 Despite the complexity of rules time zones, specifying a single event 1305 time in an unambiguous manner is fairly simple. Given that the event 1306 time needs to be interpreted by user agents in multiple time zones, 1307 the event time must be described in a manner that allows the recipient 1308 agent to interpret the time in relation to the recipient's own time 1309 zone. Specifying the time of the appointment in local time only is not 1310 workable, in that the recipient agent would have to have accurate 1311 knowledge of both the event's time zone and his own time zone to 1312 calculate the correct time value for the recipient's schedule. 1313 Specifying the event's local time, plus the event's time zone 1314 information is workable, but requires more data and to be transmitted 1315 and more calculations required by the recipient. Instead, event 1316 start/end time and date can be specified by sender in Coordinated 1317 Universal Time (UTC), calculated based on the current known rules for 1318 the time zone and the date/time of the event. Then the recipient agent 1319 need only convert from UTC to its local time using the rules for his 1320 time zone. 1322 3.3.1.4 Recurring Event Date and Time Specification 1324 The main issue that requires the event date and time specification for 1325 recurring events more complicated is that these events may be defined 1326 such that they cross the boundaries of a daylight transition (ST to 1327 DST and back). For example, an recurring appointment at 08:00 should 1328 remain at 08:00 regardless of the daylight transitions that may 1329 happen. 1331 A recurring event can be specified with the following properties. For 1332 clarity a description is provided with property names in parenthesis 1333 (). Full definitions of the property names will be covered in section 1334 3.2. 1336 1) Event date and time, relative to a particular time zone. Could be 1337 UTC, but will often be local time. (TStartInst, 1338 TEndInst, DStart, DEnd, StartOfWeek) 1340 Internet-Draft 11/25/96 1342 2) Time zone Id (TZID): An ID that can be used to identify the time 1343 zone (could be a name, a number, likely that we want an IANA 1344 registry of time zone/daylight rule names. Needs to be defined) 1346 3) Time zone Rules, composed of the following: 1347 a) Time zone Bias (TZBias): time delta from UTC (e.g. 08:00) 1348 b) Daylight Bias (TZDstBias): time delta used in "Daylight 1349 Savings Time", e.g. -01:00 (one hour) 1350 c) Optional Standard Bias (TZStdBias): time delta used in 1351 "Standard Time". Should be 0 everywhere, but could be non-zero. 1353 4) Transition Rules, not required if no transitions are in use, 1354 composed of the following: 1355 a) Standard Transition (TZStdTrans): a list of absolute date/times 1356 bounded by the end date of the recurrence pattern 1357 b) Daylight Transition (TZDstTrans): a list of absolute 1358 date/times bounded by the end date of the recurrence pattern 1360 5) Optional Calendar Type identifier (CalTypeID). Gregorian should be 1361 assumed if absent. Alternate calendar types may require alternate 1362 date/time formats and recurrence pattern definitions. 1364 6) Optional Time Zone Date Stamp (TZDS): A date stamp to indicate the 1365 freshness of this time zone definition. Could be used by the recipient 1366 application to decided whether to use this data or use to a newer 1367 rule. 1369 7) Optional URL (TZSrc) to approved IANA time zone specification 1370 information. (Client app Use the standard (that we define) for the 1371 time zone label to translate to a URL.?) 1373 8) recurrence pattern for the repeating events 1375 Explanation: 1377 Given the event time, the time zone bias values, and the transition 1378 rules, the recipient can accurately translate the event time into the 1379 proper value for the recipient time zone. The even time (TStartInst, 1380 TEndInst) could be either local time or UTC -- given either, it is 1381 possible to calculate the other provided that the time zone 1382 information/rules are available. 1384 The time zone information is specifically not required in date format 1385 for DStart and DEnd. Instead it is specified separately as an 1386 unambiguous set of rules that can be interpreted easily by the 1388 Internet-Draft 11/25/96 1390 recipient. If the time zone is specified in the date format, the time 1391 zone rules should have precedence. 1393 Time zone rules assume that UTC = local time + Bias, where Bias is one 1394 of (Time zone Bias + Std Bias) or (Time zone Bias + Daylight Bias). 1396 Daylight Bias (TZDstBias) can be omitted, if the value is -0100. 1398 Standard Bias (TZStdBias) can be omitted if the value is 0, but should 1399 be respected if present. 1401 If Time zone (TZBias), Standard (TZStdBias) and Daylight (TZDstBias) 1402 Bias are 0, the time should be interpreted as UTC. 1404 Transition Rules (TZStdTrans, TZDstTrans) should be omitted if there 1405 are no transitions or if a single event is specified. 1407 The presence of the Calendar Type (CalTypeID) allows the sender to 1408 express the recurrence pattern in another calendar type (for example 1409 Hijri). Absence of the Calendar type means Gregorian. If a recipient 1410 is unable to handle the calendar type sent, it should do something 1411 reasonable. 1413 Recipients of event descriptions MAY make use of the time zone 1414 identifier TZID (for example, to correct for outdated DST rules), but 1415 creators of event descriptions SHOULD NOT assume that recipients will 1416 look at the time zone identifier. 1418 Recipients of event descriptions MAY make use of the time zone source 1419 URL (TZSrc) (for example, to correct for outdated DST rules), but 1420 creators of event descriptions SHOULD NOT assume that recipients will 1421 look at the time zone source URL identifier. 1423 Aside: Absence of time zone information altogether in a repeating 1424 event could indicate that this is a floating event (i.e. not tied to a 1425 time zone), e.g. I go running at 0700 no matter where I am in the 1426 world. However, this is NOT specified as valid in this standard as the 1427 author cannot imagine a situation where group scheduling could make 1428 use of this feature. However, a feature rich client application may 1429 allow a user to create such an appointment for personal scheduling. 1431 3.3.1.5 Time zone of meeting 1433 One interesting aspect of meeting requests is what time zone should be 1434 used when scheduling the meeting. This applies to both single and 1435 recurring meetings. 1437 Internet-Draft 11/25/96 1439 For example, if I schedule a weekly meeting at 9am and in my locale, 1440 there is no daylight savings time, but in your locale there is, then 1441 if my time zone was used to schedule the meeting, then the meeting 1442 would be 9am all the time for me, but 9am during the winter and 8am 1443 during the summer for you. 1445 There can be arguments made for the time being always 9am in my time, 1446 or always 9am in your time. We could pick an arbitrary rule and say 1447 that the sender of the meeting's time zone is used, however in the 1448 case where we are both going to a meeting in another city, we'd 1449 probably want to use the time zone of where we are meeting. 1451 Ultimately the time zone that should be used comes down to a 1452 preference of the organizer and the attendees. The key requirement is 1453 that the meeting must occur at the same time for all attendees. Given 1454 this, from a coordination standpoint, it is unimportant which time 1455 zone is used, as long as everyone knows when the meeting is. As an 1456 option, the application could allow the user to manually pick the time 1457 zone that should be used for the meeting. 1459 3.3.1.6 Changes to local time zone shift rules 1461 Another issue that must be discussed is how to handle changes to time 1462 zone shift rules. These don't happen all that often, but they need to 1463 be discussed. 1465 For a single event specified in UTC, a time zone shift rule change may 1466 change the apparent time of the meeting. For example, if a local 1467 government changed from using daylight savings time to not using 1468 daylight savings time, then a meeting scheduled at 9:00am local time 1469 may change to 8:00am relative to attendees of the meeting who are 1470 located in the time zone that changed. 1472 There are a couple recommended ways a change like this can be handled. 1473 The first would be to prompt the creator of the meeting to reschedule 1474 the meeting, or allow an attendee of the meeting to ask that the 1475 meeting be rescheduled. Another would be to automatically reschedule 1476 the meeting if the software detected a time zone rule change, although 1477 this may be problematic if the other attendees are busy at the new 1478 time. 1480 For a recurring event, a time zone shift may also change the apparent 1481 time of the meeting. The same recommendations for handling time zone 1482 shift rule changes for single events also will work for recurring 1483 events. 1485 Internet-Draft 11/25/96 1487 Although this is beyond the scope of this draft, it may also be useful 1488 for applications to have access to a server from which time zone rule 1489 information can be easily retrieved. 1491 Example: UTC and Time Zone Rule change and the ambiguity 1493 Suppose I'm in Seattle (UTC-0800 Pacific Time) and you are in another 1494 time zone. I book a conference call with you at 9am on April 30 in 1495 Seattle. The UTC for April 30 9am is 1600 based on the rules for 1496 Daylight Savings Time (See example calculations above in the 1497 definitions). Now suppose that the rule for Seattle's transition to 1498 DST change after I've booked this appointment such that the transition 1499 date to DST is now after April 30. 9am on April 30 in Seattle is now 1500 calculated as 1700 UTC, because the appointment is no longer in DST. 1501 However, your schedule knows of this appointment by 1600 UTC, not 1700 1502 UTC, so we're out of synchronization; if I want to keep this 1503 appointment I need to adjust my calendar to reflect that this 1504 appointment is now at 8am my time (1600 UTC using the Standard Time 1505 rule). I may simply want my schedule to adjust the appointment so that 1506 the meeting time has effectively changed; after all, when I booked the 1507 call with you at 1700 UTC, you were available and you are hard to get 1508 with, so I'll adjust. On the other hand, if the call requires a 1509 resource booked for a particular time in my time zone, then I'll want 1510 the meeting to stay where it is by the clock(9am) and will need to 1511 reschedule with you. 1513 Since these rule changes tend to be relatively infrequent, a minimum 1514 implementation MAY USE the UTC format for specifying time and date for 1515 single instance appointments. This specifically does not restrict 1516 client from sending out the more detailed information to specify the 1517 event time including time zone deltas and labels used to identify the 1518 time zone, etc. For example, the time zone information could be 1519 specified by using the recurring event specification below (i.e. a 1520 single event is a repeating event with one instance). 1522 3.3.2 Recurrence patterns 1524 3.3.2.1 The Recurrence Model 1526 The recurrence model is based on specifying one or more restrictions, 1527 similar to a database query, combined with reference date and time 1528 information. Each restriction, or pattern, is combined with the next 1529 pattern using the logical AND operation. 1531 The use of individual properties to describe components of the pattern 1532 allows for a wide variety of patterns to be specified without 1534 Internet-Draft 11/25/96 1536 specialised parsing or grammar. The specification for the recurrence 1537 patterns is discussed in detail below. 1539 Five properties are used to denote specific days or months. These are: 1541 DW // DaysOfWeek 1542 DM // DaysOfMonth 1543 DY // DaysOfYear 1544 WY // WeeksOfYear 1545 MY // MonthsOfYear 1547 Five properties describe the interval between instances of the 1548 pattern. 1550 HI // HourInterval 1551 DI // DayInterval 1552 WI // WeekInterval 1553 MI // MonthInterval 1554 YI // YearInterval 1556 Using these properties, it is possible to describe calendar-based 1557 recurring patterns. (Examples of non-calendar-based patterns include 1558 Easter and Winter Solstice which are based on lunar patterns.) 1560 A unique feature of the above properties is that they may be used in 1561 combination to represent arbitrarily complex recurrence patterns. 1563 Recurring patterns have ten properties describing the date and time of 1564 the recurring item. The Start and End single-instance appointment 1565 properties are not used. 1567 TStartInst 1568 TEndInst 1569 DStart 1570 DEnd 1571 DExcept 1572 DOrigExcept 1573 WStart 1574 TZBias 1575 TZDstBias 1576 TZStdBias 1577 TZStdTrans 1578 TZDstTrans 1580 The two time-related fields hold the item's start and end time. The 1581 two date-related fields cover the start and end dates of the recurring 1582 pattern. It is required to have a start and end date for a pattern; 1584 Internet-Draft 11/25/96 1586 unbounded patterns are not allowed, however no restriction is set on 1587 the start or end date. The start of week (WStart) property is used to 1588 indicate what day of the week your calendar starts on. For example, in 1589 Europe it is common for calendars to start on Monday. The Exception 1590 Date and Original Exception Date hold exceptions to the recurring 1591 pattern. 1593 The following is used to define the reference calendar to be used for 1594 calculations of the recurrence patterns. The default is Gregorian. No 1595 additional calendar types are defined at this time. A registration 1596 procedure for defining new calendar types will need to be created. 1598 CalTypeID 1600 A single property is defined to contain the textual description of the 1601 pattern 1603 RPDescr 1605 All of the above property names are defined in detail in Section 3.2. 1607 3.3.2.2 Examples 1609 The following examples depict recurring patterns using this model. 1610 Note that the usage of the value= parameter is optional as 1611 specified in [MIME-DIR] 1613 Example 1: 1614 Christmas Day (December 25th) is described as: 1616 RPDescr: December 25, every year 1617 MY: 12 1618 DM: 25 1619 YI: 1 1621 Example 2: 1622 A weeknight television broadcast is described as: 1624 DW;value=text: Mon, Tue, Wed, Thu, Fri 1625 WI;value=int: 1 1626 TStartInst;value=time: 21:00 1627 TEndInst;value=time: 22:00 1628 RPDescr: Monday-Friday, every week, 9:00p.m.-10:00 p.m. 1630 Example 3: 1632 Internet-Draft 11/25/96 1634 Pay-day, the 15th and last day of the month is described as: 1636 DM;value=int: 15, -1 1637 MI;value=int: 1 1638 TStartInst;value=time: 12:00 1639 TEndInst;value=time: 12:00 1640 RPDescr: 15th and last day of the month at noon 1642 Example 4: 1643 U.S. Presidential Election Day is described as: 1645 DM;value=int: 2,3,4,5,6,7,8 1646 DW: Tue 1647 MY;value=int: 11 1648 YI;value=int: 4 1649 RPDescr: First Tuesday after a Monday in November, every four years 1651 (Since there must be a Monday in November before the election day, Nov 1652 1 is disqualified.) 1654 Example 5: 1655 A monthly recurring monthly appointment for the first Monday of the 1656 month that starts on 1 Aug 1996 and ends on 1 Aug 1998, includes time 1657 zone usage. Time zone is Pacific (UTC-0800). Daylight Transition 1658 Date is First Sunday in April at 2:00:00 AM and 1659 Standard Transition Date is Last Sunday in October at 2:00:00 AM. 1660 TZStdBias is defaulted to 0 1662 TStartInst: 8:00 1663 TEndInst: 09:00 1664 DStart: 1 Aug 1996 1665 DEnd: 31 Aug 1998 1666 DM: 1,2,3,4,5,6,7 1667 DW: Mon 1669 3.3.3 Change/cancellation semantics 1671 Often meetings are rescheduled, cancelled or otherwise changed. When 1672 a meeting is changed, the attendees of the meeting need to be notified 1673 of the change, and their calendars need to be updated. 1675 The key problem in modifying a meeting is that of matching the new 1676 meeting with the meeting that exists on the calendars of the 1677 attendees. This is solved by specifying both an ID for the meeting 1679 Internet-Draft 11/25/96 1681 (created at the original instantiation of the meeting), a version 1682 number which indicates which change is the most recent when there are 1683 multiple changes, and a request type which specifies if the change is 1684 an updated meeting or if it is a cancellation of the meeting. 1686 3.3.3.1 Changing/cancelling an event. 1688 When the creator of a meeting wants to change all instances of a 1689 meeting in some way, then the creator sends a completely updated 1690 meeting request to all the attendees. The ApptID of the updated 1691 request contains the ID specified in the original meeting request. It 1692 also has an updated ApptVersion property. 1694 Attendees receiving the updated meeting request look for the previous 1695 meeting based on the ApptID of the meeting, and replace the existing 1696 meeting with the new one if the version stamp is newer than the 1697 existing version stamp. The ID of the meeting stays the same as the 1698 original meeting ID so that further changes can be co-ordinated. 1700 To cancel a single event, a meeting request is sent where the 1701 RequestType property is "Cancel". This meeting need only include the 1702 ApptID property referring to the ID of the original meeting. 1704 3.3.3.2 Changing/cancelling one instance of a recurring event. 1706 In the case where I wish to change a single instance of a recurring 1707 event, a complete new appointment is constructed which is the 1708 exception. The appointment gets a new ID, and the ApptID property is 1709 set to the ID of the original meeting request. A new ApptVersion is 1710 constructed for the exception. The DOrigExcept property is used to 1711 specify which instance of the recurring event this event is an 1712 exception to. 1714 To cancel a single event, a meeting request is sent where the 1715 RequestType property is "Cancel". This meeting includes: the ApptID 1716 property which refers to the ID of the original meeting, and the 1717 DOrigExcept property which refers to which instance of the recurring 1718 event this cancellation is an exception to. 1720 3.3.3.3 Complex changes 1722 There will be some changes that will be fairly complex to express in 1723 terms of changing a meeting. In these cases, changes should be 1724 handled by cancelling the meeting and creating one or more new 1725 meetings. 1727 Internet-Draft 11/25/96 1729 3.3.4 Attendees 1731 Attendees are defined to be the individuals, groups, or resources that 1732 are invited to an appointment or event. Each attendee must have an 1733 address that can be used to deliver the appointment request to. There 1734 are several classes of attendees, including required, optional, owner, 1735 organizer, and informational (or FYI). 1737 Attendees for an appointment can be identified and classified in the 1738 MIME message in a number of ways. The default mechanism uses the 1739 "To:", "Cc:" and "Bcc:" message header fields as defined in [RFC-822]. 1740 Individuals, groups and resources are all assumed to be valid 1741 recipients that can be specified in the format of [RFC-822] address 1742 message header. Attendees in the "To:" header are "required", those in 1743 the "Cc:" header are "optional", and the "Bcc:" header contains 1744 "informational" or FYI attendees. The organizer classification is 1745 assumed to be the appoint request originator ("From:"). The owner 1746 classification can not be readily specified in the standard [RFC-822] 1747 header fields, but can be specified using an alternate mechanism as 1748 described below. 1750 Optionally, the various classifications of attendees can be specified 1751 using the following named properties in the "application/calendar" 1753 Content-Type: AttendReq, AttendOpt, AttendFyi, and AttendOwner. These 1754 named properties when used, have precedence over the [RFC-822] header 1755 fields. When a named Attendee property is used, the semantically 1756 matching RFC-822 header is ignored. No special treatment is made for 1757 individuals, groups, or resources; all are assumed to have a valid 1758 address. These property names are defined in detail in above. 1760 3.4 General Examples 1762 3.4.1 Example: Minimal appointment request 1764 This demonstrates a minimal appointment request in the 1765 application/calendar MIME Content-Type. The appointment has a start 1766 and end date-time. 1768 To: Franklin W. Dixon 1769 From: Carolyn Keene 1770 Subject: Discuss contract issues 1771 MIME-Version: 1.0 1772 Message-ID: 1773 Content-Type: application/calendar; profile="request" 1774 Content-ID: 1776 Internet-Draft 11/25/96 1778 ID: 1779 Start;value=d-t: 22 Oct 96 14:00:00 UT 1780 End;value=d-t: 22 Oct 96 15:00:00 UT 1782 3.4.2 Example: Cancelling a meeting 1784 To: Larry , Curly , 1785 Moe 1786 From: Shemp 1787 Subject: Hey, we need to make some money! 1788 MIME-Version: 1.0 1789 Message-ID: 1790 Content-Type: application/calendar; profile="request" 1792 RequestType: Cancel 1793 ApptID: 1794 Description: Let's just go eat instead. 1796 3.4.3 Example: Recurring appointment request 1798 This demonstrates a recurring appointment request in the 1799 application/calendar MIME Content-Type. The recurring pattern 1800 describes the United States Election Day: 1802 To: President 1803 From: Vice President 1804 Subject: Don't forget to vote! 1805 MIME-Version: 1.0 1806 Message-ID: 1807 Content-Type: application/calendar; profile="request" 1808 Content-ID: 1810 ID: 1811 TStartInst;value=time: 10:00 1812 TEndInst;value=time: 10:15 1813 DStart;value=date: 1 Jan 1996 1814 DEnd;value=date: 1 Jan 2008 1815 TZID: EST 1816 TZBias: +05:00 1817 DM;value=int: 2,3,4,5,6,7,8 1818 DW: Tue 1819 MY;value=int: 11 1820 YI;value=int: 4 1821 RPDescr: First Tuesday after a Monday in November, every four 1822 years" 1824 Internet-Draft 11/25/96 1826 3.4.4 Recurring appointment with time zone shifts. 1828 This demonstrates a recurring appointment request in the 1829 application/calendar MIME Content-Type. The recurring pattern 1830 describes a monthly recurring monthly appointment for the first Monday 1831 of the month that starts on 1 Aug 1996 and ends on 1 Aug 1998, 1832 includes time zone usage. Time zone is Pacific (UTC-0800). Daylight 1833 Transition Date is First Sunday in April at 2:00:00 AM and 1834 Standard Transition Date is Last Sunday in October at 2:00:00 AM. 1835 TZStdBias is defaulted to 0 1837 To: Marketing Team 1838 From: Mr Big 1839 Subject: Monthly Review. 1840 MIME-Version: 1.0 1841 Message-ID: 1842 Content-Type: application/calendar; profile="request" 1843 Content-ID: 1845 ID: 1846 TStartInst: 8:00 1847 TEndInst: 09:00 1848 DStart: 1 Aug 1996 1849 DEnd: 1 Aug 1998 1850 DM: 1,2,3,4,5,6,7 1851 DW: Mon 1852 TZID: PST 1853 TZBias: +08:00 1854 TZDstBias: -01:00 1855 TZStdTrans: 27 Oct 1996 02:00 1856 TZDstTrans: 6 Apr 1997 02:00 1857 TZStdTrans: 26 Oct 1997 02:00 1858 TZDstTrans: 5 Apr 1998 02:00 1860 3.4.5 Example: One time exception to recurring meeting 1862 To: President 1863 From: Vice President 1864 Subject: Don't forget to vote! 1865 MIME-Version: 1.0 1866 Message-ID: 1867 Content-Type: application/calendar; 1868 profile="request" 1869 Content-ID: 1871 Start;value=d-t: 7 Nov 1996 15:30 UT 1872 End;value=d-t: 7 Nov 1996 15:45 UT 1874 Internet-Draft 11/25/96 1876 ApptID: 1877 DOrigExcept;value=date: 5 Nov 1996 1878 Summary: Rescheduling due to invasion. 1880 3.4.6 Example: Cancelling an instance of a recurring meeting 1882 To: President 1883 From: Vice President 1884 Subject: Don't forget to vote! 1885 MIME-Version: 1.0 1886 Message-ID: 1887 Content-Type: application/calendar; 1888 profile="request" 1889 Content-ID: 1891 ApptID: 1892 Summary: Cancelling due to invasion. 1893 RequestType: Cancel 1894 DOrigExcept;value=date: 5 Nov 1996 1895 Description: There is no time to vote for ourselves this year. 1897 3.4.7 Example: Appointment and message body in the same message. 1899 This uses the multipart/related Content-Type to add non-textual 1900 appointment data: 1902 To: Franklin W. Dixon 1903 From: Carolyn Keene 1904 Subject: Discuss contract issues 1905 MIME-Version: 1.0 1906 Message-ID: 1907 Content-Type: multipart/related; 1908 boundary=fence; 1909 type="application/calendar"; 1910 start="" 1911 Content-ID: 1913 --fence 1914 Content-Type: application/calendar; profile="request" 1915 Content-ID: 1917 Start: 22 Oct 96 14:00:00 UT 1918 End: 22 Oct 96 15:00:00 UT 1919 Location: Applegate Building, Suite 410 1920 Map;value=url: "id5@sample.com" 1922 Internet-Draft 11/25/96 1924 --fence 1925 Content-Type: image/jpeg 1926 Content-ID: "id5@sample.com" 1928 <...image data goes here...> 1930 --fence-- 1932 4. Appointment Responses 1934 4.1 Description 1936 The Appointment RESPONSE content definition profile. 1938 Profile name: RESPONSE 1940 Profile purpose: Indicates schema of RESPONSE items 1942 Profile special notes: Responses should include as many original 1943 appointment request properties as possible. 1944 The minimum fields in the response are 1945 Response, ApptID, and ApptVersion. The 1946 other fields are included for cases where 1947 User Agents do not support automatic 1948 correlation of responses. 1950 Profile intended usage: COMMON 1952 Example: 1954 Content-Type: application/calendar; profile="response" 1956 Profile property names: All defined for appointment request plus: 1957 ApptResponse 1959 4.2 Properties 1961 4.2.1 ApptResponse 1963 Name: ApptResponse 1964 Data type: TEXT 1965 Purpose: Attendee's response for the Appointment. 1967 Internet-Draft 11/25/96 1969 Encoding: Three values are defined: 1970 "Accept": Attendee accepted the 1971 appointment request 1972 and will attend the 1973 appointment. 1974 "Decline": Attendee declined the 1975 appointment 1976 request and will not attend 1977 the appointment. 1978 "Tentative": Attendee is not sure if he 1979 can attend and has 1980 tentatively accepted the 1981 request, but does not 1982 guarantee he will attend. 1984 All values are case insensitive. 1986 Special notes: Absence of this property indicates that 1987 the response is "Accept". 1988 Required: YES 1989 Multi-valued: NEVER 1990 Intended usage: COMMON 1992 4.3 Examples 1994 4.3.1 Example: Simple appointment response 1996 This demonstrates an appointment responses. The minimum fields in the 1997 response are Response, ApptID, and ApptVersion. The other fields are 1998 included for cases where User Agents do not support automatic 1999 correlation of responses. 2001 To: Carolyn Keene 2002 From: Franklin W. Dixon 2003 Subject: Discuss contract issues 2004 MIME-Version: 1.0 2005 Message-ID: 2006 Content-Type: application/calendar; profile="response" 2008 Response: ACCEPT 2009 ApptID: 2010 ApptVersion;value=d-t: 21 Oct 96 17:02:34 UT 2011 Start;value=d-t: 22 Oct 96 17:00:00 UT 2012 End;value=d-t: 22 Oct 96 18:00:00 UT 2013 Summary: Let's have a meeting 2015 Internet-Draft 11/25/96 2017 4.3.2 Example: decline response to recurring appointment 2019 This demonstrates an appointment response to a 2020 recurring appointment or recurring appointment exception 2021 request: 2023 To: Carolyn Keene 2024 From: Franklin W. Dixon 2025 Subject: Discuss contract issues 2026 MIME-Version: 1.0 2027 Message-ID: 2028 Content-Type: application/calendar; profile="response" 2030 Response: DECLINE 2031 ApptID: 2032 ApptVersion;value=d-t: 21 Oct 96 17:02:34 PST 2033 RPDescr: "Every Tuesday" 2034 Summary: No I can't have a meeting on Tuesdays 2036 4.3.3 Example: Accept response to recurring appointment 2038 Example demonstrates an appointment response to a 2039 recurring appointment or recurring appointment exception 2040 request: 2042 To: Carolyn Keene 2043 From: Franklin W. Dixon 2044 Subject: Discuss contract issues 2045 MIME-Version: 1.0 2046 Message-ID: 2047 Content-Type: application/calendar; profile="response" 2049 Response: Accept 2050 ApptVersion;value=d-t: 21 Oct 96 17:02:34 PST 2051 ApptID: 2052 DOrigExcept;value=date: 28 Oct 1996 2053 Summary: But I can have a meeting on this Tuesday 2055 5. Acknowledgements 2057 This document is the result of the collective effort of a large number 2058 of people on the IETF Calendar Working group mailing list. Although 2059 any enumeration seems doomed to suffer from egregious omissions, the 2060 following are among the many contributors to this effort: 2062 Internet-Draft 11/25/96 2064 Darren Shakib 2065 Alec Dun 2066 Frank Dawson 2067 Harald.T.Alvestrand 2068 Keith Moore 2069 Pete Resnick 2070 Ross Finlayson 2071 Lewis Geer 2072 Mark Horton 2073 John C Klensin 2074 Chris Newman 2075 Philippe Kahn 2076 Anik Ganguly 2077 Ken Shan 2078 Brian Deen 2079 Patrik Faltstrom 2080 Denis BIGORGNE 2081 Peter O'Leary 2082 Roger Fajman 2083 C. Harald Koch 2084 Hal Howard 2085 David Boreham 2086 Ned Freed 2087 Andrew Shuman 2088 Nathaniel Borenstein 2089 Tim Howes 2090 Andras Salamon 2091 Bill Bliss 2092 Theodore Lorek 2093 Mark Towfiq 2094 Larry Osterman 2095 James L. Weiner 2096 Robert Visnov 2097 Frederick G.M. Roeber 2098 William Wyatt 2099 Mark Handley 2100 Chuck Grandgent 2101 William P. Spencer 2102 Robert Moskowitz 2103 Steve Carter 2104 Ian Ferrell 2106 Format and some descriptions were borrowed from the [MIME-DIR] and 2107 [MIME-PROP] drafts. 2109 Internet-Draft 11/25/96 2111 6. Author's Addresses 2113 Derik Stenerson 2115 Microsoft 2116 One Microsoft Way 2117 Redmond, WA 98052 2118 USA 2119 deriks@microsoft.com 2120 +1.206.936.5522 2122 Alec Dun 2123 Microsoft Corporation 2124 One Microsoft Way 2125 Redmond, WA 98052 2126 USA 2127 alecdu@microsoft.com 2128 +1.206.936.4544 2130 Darren Shakib 2131 Microsoft 2132 One Microsoft Way 2133 Redmond, WA 98052 2134 darrens@microsoft.com 2135 +1.206.936.6405 2137 Appendix A Registration of new profiles 2139 This section defines procedures by which new profiles are registered 2140 with the IANA and made available to the Internet community. Note that 2141 non-IANA profiles may be used by bilateral agreement, provided the 2142 associated profile names follow the "X-" convention defined above. 2144 The procedures defined here are designed to allow public comment and 2145 review of new profiles, while posing only a small impediment to the 2146 definition of new profiles. 2148 Registration of a new profile is accomplished by the following steps. 2150 Define the profile 2152 A profile is defined by completing the following template. 2154 To: [mailing list TBD] 2155 Subject: Registration of application/calendar MIME profile XXX 2157 Profile name: 2159 Internet-Draft 11/25/96 2161 Profile purpose: 2163 Profile property names: 2165 Profile special notes (optional): 2167 Profile Intended usage: (one of COMMON, LIMITED USE or 2168 OBSOLETE) 2170 Property Descriptions: (list of property descriptions in 2171 following format) 2173 Name: 2175 Data type: 2177 Purpose: 2179 Encoding: 2181 Special notes (optional): 2183 Required: (one of YES, NO) 2185 Multi-Valued: (one of ALWAYS, NEVER, SOMETIMES) 2187 Intended usage: (one of COMMON, LIMITED USE or OBSOLETE) 2189 The explanation of what goes in each field in the template follows. 2191 Profile name: The name of the profile as it will appear in the 2192 application/calendar MIME Content-Type "profile" header parameter. 2194 Profile purpose: The purpose of the profile (e.g., to represent 2195 information about people, printers, documents, etc.). Give a short but 2196 clear description. 2198 Profile property names: The list of property names associated with the 2199 profile. This list of names is to be expected but not required in the 2200 profile. Other names not mentioned in the profile definition may also 2201 be present. 2203 Profile special notes: Any special notes about the profile, how it is 2204 to be used, etc. This section of the template may also be used to 2205 define an ordering on the types that appear in the Content-Type, if 2206 such an ordering is required. 2208 Internet-Draft 11/25/96 2210 Property Descriptions: Precedes the list of property descriptions for 2211 the profile. Each property definition starts with the "Name:" tag. 2213 Name: The name of the property, as it will appear in the body of an 2214 application/calendar MIME Content-Type "name: value" line to the left 2215 of the colon ":". 2217 Data type: The expected data type for the property. Possible values 2218 listed in [MIME-DIR]. 2220 Purpose: The purpose of the property (e.g., to represent a name,postal 2221 address, IP address, etc.). Give a short but clear description. 2223 Encoding: The encoding a value of the type must have in the body of an 2224 application/calendar MIME Content-Type. This description must be 2225 precise and must not violate the general encoding rules defined in 2226 section [MIME-DIR]. 2228 Special notes: Any special notes about the property, how it is to be 2229 used, etc. 2231 Required: YES indicates that the property MUST be present in the 2232 property list of a item of an item of this type profile. No indicates 2233 that this property MAY appear in the property list. 2235 Multi-Valued: ALWAYS indicates that the property will expected to be 2236 multi-valued. NEVER indicates that the property MUST NOT be multi- 2237 valued. SOMETIMES indicates that the property MAY be multi-valued, 2238 but that most implementations will not make it multi-valued. 2240 Intended usage: COMMON indicates that most items of this profile will 2241 include this property. LIMITED USE indicates that this property will 2242 rarely be included. OBSOLETE indicates that use of this property 2243 SHOULD NOT be used. 2245 Post the profile definition 2247 The profile description must be posted to the new profile discussion 2248 list, [mailing list TBD]. 2250 Allow a comment period 2252 Discussion on the new profile must be allowed to take place on the 2253 list for a minimum of two weeks. Consensus must be reached on the 2254 profile before submitting the profile for approval 2256 Internet-Draft 11/25/96 2258 Submit the profile for approval 2260 Once the two-week comment period has elapsed, and the proposer is 2261 convinced consensus has been reached on the profile, the registration 2262 application should be submitted to the Profile Reviewer for approval. 2263 The Profile Reviewer is appointed by the Application Area Directors 2264 and may either accept or reject the profile registration. An accepted 2265 registration should be passed on by the Profile Reviewer to the IANA 2266 for inclusion in the official IANA profile registry. The registration 2267 may be rejected for any of the following reasons. 1) Insufficient 2268 comment period; 2) Consensus not reached; 3) Technical deficiencies 2269 raised on the list or elsewhere have not been addressed. The Profile 2270 Reviewer's decision to reject a profile may be appealed by the 2271 proposer to the IESG, or the objections raised can be addressed by the 2272 proposer and the profile resubmitted. 2274 Appendix B Profile Change Control 2276 Existing profiles may be changed using the same process by which they 2277 were registered. 2279 Define the change 2281 Post the change 2283 Allow a comment period 2285 Submit the profile for approval 2287 Note that the original author or any other interested party may 2288 propose a change to an existing profile, but that such changes should 2289 only be proposed when there are serious omissions or errors in the 2290 published specification. The Profile Reviewer may object to a change 2291 if it is not backwards compatible, but is not required to do so. 2293 Profile definitions can never be deleted from the IANA registry, but 2294 profiles which are no longer believed to be useful can be declared 2295 OBSOLETE by a change to their "intended use" field. 2297 References 2299 [MIME-CSCT], Dawson, Frank, "MIME Calendaring and Scheduling Content 2300 Type, Internet Draft draft-dawson-csct-00.txt, October 1996 2302 [MIME-DIR] Howes,T., Smith, M., "A MIME Content-Type for Directory 2303 Information", Internet-draft-ietf-asid-mime-direct-01.txt, February, 2304 1996. 2306 Internet-Draft 11/25/96 2308 [MIME-PROP] Shakib, Darren, "A MIME Content-Type for Tagged Property 2309 Value Storage", Internet-Draft draft-shakib-mime-prop-00.txt, 2310 July 1996. 2312 [MIME-REG] Freed, N., Postel, J., "Multipurpose Internet Mail 2313 Extensions (MIME) - Part Four: Registration Procedures", Internet- 2314 Draft draft-ietf-822ext-mime-reg-02.txt, December 1995. 2316 [NIST] "Time and Frequency FAQ", National Institute of Standards and 2317 Technology Time and Frequency Division, publication on the World Wide 2318 Web: http://www.boulder.nist.gov 2320 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 2321 Messages", STD 11, RFC 822, August 1982. 2323 [RFC-1521] Borenstein, N., Freed, N., "MIME (Multipurpose Internet 2324 Mail Extensions) Part One: Mechanisms for Specifying and Describing 2325 the Format of Internet Message Bodies", RFC 1521, September 1993. 2327 [RFC-1522] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2328 Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522, 2329 September 1993. 2331 [RFC-1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform 2332 Resource Locators (URL)", RFC 1738, December 1994. 2334 [RFC 1766] H. Alvestrand, _Tags for the Identification of Languages_, 2335 UNINETT, RFC 1766, March 1995. 2337 [RFC-1835] 2338 Deutsch, et al., "Architecture of the WHOIS++ service", RFC 1835, 2339 August 1995. 2341 [RFC-1872] Levinson, E., "The MIME Multipart/Related Content-type," 2342 RFC 1872, December 1995. 2344 Expires May 30, 1997