idnits 2.17.1 draft-ietf-calsch-itip-04.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. Found some kind of copyright notice around line 5030 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-24) 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 == The page length should not exceed 58 lines per page, but there was 99 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1 Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 1543 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([UNICODE], [RFC-1983], [ICMS], [US-ASCII], [VCAL], [VCARD], [ID-UTF8], [RFC-2045], [ISO8601], [RFC-2046], [RFC-1847], [RFC-821], [RFC-2119], [RFC-822]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 474: '..." property value MUST be incremented e...' RFC 2119 keyword, line 477: '..." property value MUST NOT be increment...' RFC 2119 keyword, line 580: '... One instance MUST be present...' RFC 2119 keyword, line 581: '... At least one instance MUST be present...' RFC 2119 keyword, line 583: '... Multiple instances MAY be present...' (335 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 960 has weird spacing: '...rameter of th...' == Line 1301 has weird spacing: '...an also be us...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: VFREEBUSY 1 ATTENDEE 1 (address of recipient replying) DTSTAMP 1 DTEND 1 DateTime values must be in UTC DTSTART 1 DateTime values must be in UTC FREEBUSY 1+ (values MUST all be of the same data type. Multiple instances are allowed. Multiple instances MUST be sorted in ascending order. Values MAY NOT overlap) ORGANIZER 1 MUST be the request originator's address UID 1 -- 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 (May 11, 1998) is 9480 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'ICMS' on line 4913 looks like a reference -- Missing reference section? 'RFC-2119' on line 4943 looks like a reference -- Missing reference section? 'RFC-822' on line 2720 looks like a reference -- Missing reference section? 'RFC-1847' on line 4857 looks like a reference -- Missing reference section? 'ID-UTF8' on line 4917 looks like a reference -- Missing reference section? 'ISO8601' on line 4925 looks like a reference -- Missing reference section? 'VCAL' on line 4929 looks like a reference -- Missing reference section? 'VCARD' on line 4933 looks like a reference -- Missing reference section? 'RFC-821' on line 4937 looks like a reference -- Missing reference section? 'RFC-1983' on line 4940 looks like a reference -- Missing reference section? 'RFC-2045' on line 4946 looks like a reference -- Missing reference section? 'RFC-2046' on line 4951 looks like a reference -- Missing reference section? 'UNICODE' on line 4955 looks like a reference -- Missing reference section? 'US-ASCII' on line 4959 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steve Silverberg, Microsoft 3 INTERNET-DRAFT Steve Mansour, Netscape 4 Calendaring and Scheduling Working Group Frank Dawson, Lotus 5 | Receiver | 385 | | | | 386 +----------+ +----------+ 388 There are several variations of this diagram in which the Sender and 389 Receiver take on various roles of a "Calendar User Agent" (CUA) or a 390 "Calendar Service" (CS). These variants are detailed in the Model 391 document [ICMS]. 393 The architecture of iTIP is depicted in the diagram below. An 394 application written to this specification may work with bindings for the 395 store-and-forward transport, the real time transport, or both. Also note 396 that iTIP could be bound to other transports. 398 +------------------------------------------+ 399 | iTIP | 400 +------------------------------------------+ 401 |Real-time | Store-and-Fwd | Other | 402 |Transport | Transport | Transports... | 403 +------------------------------------------+ 405 2.1 Application Protocol 407 In the iTIP model, a calendar entry is created and managed by an 408 "Organizer". The "Organizer" interacts with other CUs by sending one or 409 more of the iTIP messages listed above. "Attendees" use the "REPLY" 410 method to communicate their status. "Attendees" do not make direct 411 changes to the master calendar entry. They can, however, use the 412 "COUNTER" method to suggest changes to the "Organizer". In any case, the 413 "Organizer" has complete control over the master calendar entry. 415 2.1.1 Calendar Entry State 417 There are two distinct states relevant to calendar entries: the overall 418 state of the entry and the state associated with an "Attendee" to that 419 entry. 421 The state of an entry is defined by the "STATUS" property and is 422 controlled by the "Organizer." There is no default value for the 423 "STATUS" property. The "Organizer" sets the "STATUS" property to the 424 appropriate value for each calendar entry. 426 The state of a particular "Attendee" relative to an entry is defined by 427 the "partstat" parameter in the "ATTENDEE" property for each "Attendee". 428 When an "Organizer" issues the initial entry, "Attendee" status is 429 unknown. The "Organizer" specifies this by setting the "partstat" 430 parameter to "NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" 431 property "partstat" parameter to an appropriate value as part of a 432 "REPLY" message sent back to the "Organizer". 434 2.1.2 Delegation 436 Delegation is defined as the process by which an "Attendee" grants 437 another CU (or several CUs) the right to attend on their behalf. The 438 "Organizer" is made aware of this change because the delegating 439 "Attendee" informs the "Organizer". These steps are detailed in the 440 REQUEST method section. 442 2.1.3 Acting on Behalf of other Calendar Users 444 In many organizations one user will act on behalf of another to organize 445 and/or respond to meeting requests. ITIP provides two mechanisms that 446 support these activities. 448 First, the "Organizer" is treated as a special entity, separate from 449 "Attendees". All responses from "Attendees" flow to the "Organizer", 450 making it easy to separate a calendar user organizing a meeting from 451 calendar users attending the meeting. Additionally, iCalendar provides 452 descriptive roles for each "Attendee". For instance, a role of "chair" 453 may be ascribed to one or more "Attendees". The "chair" and the 454 "Organizer" may or may not be the same calendar user. This maps well to 455 scenarios where an assistant may manage meeting logistics for another 456 individual who chairs a meeting. 458 Second, a "sent-by" parameter may be specified in either the "Organizer" 459 or "Attendee" properties. When specified, the "sent-by" parameter 460 indicates that the responding CU acted on behalf of the specified 461 "Attendee" or "Organizer". 463 2.1.4 Component Revisions 465 The "SEQUENCE" property is used by the "Organizer" to indicate revisions 466 to the calendar component. The rules for incrementing the "SEQUENCE" 467 number are defined in [iCAL]. For clarity, these rules are paraphrased 468 here in terms of how they are applied in [iTIP]. For a given "UID" in a 469 calendar component: 471 . For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property 472 value is incremented according to the rules defined in [iCAL]. 474 . The "SEQUENCE" property value MUST be incremented each time the 475 "Organizer" uses the "ADD" or "CANCEL" methods. 477 . The "SEQUENCE" property value MUST NOT be incremented when using 478 "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a 479 delegation "REQUEST". 481 In some circumstances the "Organizer" may not have received responses to 482 the final revision sent out. In this situation, the "Organizer" may wish 483 to send an update "REQUEST", and set "RSVP=TRUE" for all "Attendees", so 484 that current responses can be collected. 486 The value of the "SEQUENCE" property contained in a response from an 487 "Attendee" may not always match the "Organizer's" revision. 488 Implementations may choose to have the CUA indicate to the CU that the 489 response is to an entry that has been revised and allow the CU to decide 490 whether or not to accept the response. 492 2.1.5 Message Sequencing 494 CUAs that handle the [iTIP] application protocol must often correlate a 495 component in a calendar store with a component received in the [iTIP] 496 message. For example, an event may be updated with a later revision of 497 the same event. To accomplish this, a CUA must correlate the version of 498 the event already in its calendar store with the version sent in the 499 [iTIP] message. In addition to this correlation, there are several 500 factors that can cause [iTIP] messages to arrive in an unexpected order. 501 That is, an "Organizer" could receive a reply to an earlier revision of 502 a component AFTER receiving a reply to a later revision. 504 To maximize interoperability and to handle messages that arrive in an 505 unexpected order, use the following rules: 507 1. The primary key for referencing a particular iCalendar component is 508 the "UID" property value. To reference an instance of a recurring 509 component, the primary key is composed of the "UID" and the 510 "RECURRENCE-ID" properties. 512 2. The secondary key for referencing a component is the "SEQUENCE" 513 property value. For components where the "UID" is the same, the 514 component with the highest numeric value for the "SEQUENCE" property 515 obsoletes all other revisions of the component with lower values. 517 3. "Attendees" send "REPLY" messages to the "Organizer". For replies 518 where the "UID" property value is the same, the value of the 519 "SEQUENCE" property indicates the revision of the component to which 520 the "Attendee" is replying. The reply with the highest numeric value 521 for the "SEQUENCE" property obsoletes all other replies with lower 522 values. 524 4. In situations where the "UID" and "SEQUENCE" properties match, the 525 "DTSTAMP" property is used as the tie-breaker. The component with the 526 latest "DTSTAMP" overrides all others. Similarly, for "Attendee" 527 responses where the "UID" property values match and the "SEQUENCE" 528 property values match, the response with the latest "DTSTAMP" 529 overrides all others. 531 Hence, CUAs must persist the following component properties: "UID", 532 "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each 533 "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" and 534 "DTSTAMP" property values associated with the "Attendee's" response. 536 3 Application Protocol Elements 538 ITIP messages are "text/calendar" MIME entities that contain calendaring 539 and scheduling information. The particular type of [iCAL] message is 540 referred to as the "method type". Each method type is identified by a 541 "METHOD" property specified as part of the "text/calendar" content type. 542 The table below shows various combinations of calendar components and 543 the method types that this memo supports. 545 +=================================================+ 546 | | VEVENT | VTODO | VJOURNAL | VFREEBUSY | 547 |=================================================| 548 |Publish | Yes | Yes | Yes | Yes | 549 |Request | Yes | Yes | No | Yes | 550 |Refresh | Yes | Yes | No | No | 551 |Cancel | Yes | Yes | Yes | No | 552 |Add | Yes | Yes | Yes | No | 553 |Reply | Yes | Yes | No | Yes | 554 |Counter | Yes | Yes | No | No | 555 |Decline- | | | | | 556 |Counter | Yes | Yes | No | No | 557 +=================================================+ 559 Each method type is defined in terms of its associated components and 560 properties. Some components and properties are required, some are 561 optional and others are excluded. The restrictions are expressed in this 562 document using a simple "restriction table". The first column indicates 563 the name of a component or property. Properties of the iCalendar object 564 are not indented. Properties of a component are indented. The second 565 column contains "MUST" if the component or property must be present, 566 "MAY" if the component or property is optional, and "NOT" if the 567 component or property must not be present. Entries in the second column 568 sometimes contain comments for further clarification. 570 3.1 Common Component Restriction Tables 572 The restriction table below applies to properties of the iCalendar 573 object. That is, the properties at the outermost scope. The presence 574 column uses the following values to assert whether a property is 575 required, is optional and the number of times it may appear in the 576 iCalendar object. 578 Presence Value Description 579 -------------------------------------------------------------- 580 1 One instance MUST be present 581 1+ At least one instance MUST be present 582 0 Instances of this property Must NOT be present 583 0+ Multiple instances MAY be present 584 0 or 1 Up to 1 instance of this property MAY be present 585 --------------------------------------------------------------- 587 The tables also call out "X-PROPERTY" and "X-COMPONENT" to show where 588 vendor-specific properties and components can appear. The tables do not 589 lay out the restrictions of property parameters. Those restrictions are 590 defined in [iCAL]. 592 Component/Property Presence 593 ------------------- ---------------------------------------------- 594 CALSCALE 0 or 1 595 PRODID 1 596 VERSION 1 Value MUST be "2.0" 597 X-PROPERTY 0+ 599 DateTime values MAY refer to a "VTIMEZONE" component. The property 600 restrictions in the table below apply to any "VTIMEZONE" component in an 601 ITIP message. 603 Component/Property Presence 604 ------------------- ---------------------------------------------- 605 VTIMEZONE 0+ MUST be present if any date/time refers to 606 timezone 607 DAYLIGHT 0+ MUST be one or more of either STANDARD or 608 DAYLIGHT 609 COMMENT 0 or 1 610 DTSTART 1 MUST be local time format 611 RDATE 0+ if present RRULE MUST NOT be present 612 RRULE 0+ if present RDATE MUST NOT be present 613 TZNAME 0 or 1 614 TZOFFSET 1 615 TZOFFSETFROM 1 616 TZOFFSETTO 1 617 X-PROPERTY 0+ 618 LAST-MODIFIED 0 or 1 619 STANDARD 0+ MUST be one or more of either STANDARD or 620 DAYLIGHT 621 COMMENT 0 or 1 622 DTSTART 1 MUST be local time format 623 RDATE 0+ if present RRULE MUST NOT be present 624 RRULE 0+ if present RDATE MUST NOT be present 625 TZNAME 0 or 1 626 TZOFFSETFROM 1 627 TZOFFSETTO 1 628 X-PROPERTY 0+ 629 TZID 1 630 TZURL 0 or 1 631 X-PROPERTY 0+ 633 The property restrictions in the table below apply to any "VALARM" 634 component in an ITIP message. 636 Component/Property Presence 637 ------------------- ---------------------------------------------- 638 VALARM 0+ 639 ACTION 1 640 ATTACH 0+ 641 DESCRIPTION 0 or 1 642 DURATION 0 or 1 if present REPEAT MUST be present 643 REPEAT 0 or 1 if present DURATION MUST be present 644 SUMMARY 0 or 1 645 TRIGGER 1 646 X-PROPERTY 0+ 648 3.2 Methods for VEVENT Calendar Components 650 This section defines the property set restrictions for the method types 651 that are applicable to the "VEVENT" calendar component. Each method is 652 defined using a table that clarifies the property constraints that 653 define the particular method. 655 The following summarizes the methods that are defined for the "VEVENT" 656 calendar component. 658 +================+==================================================+ 659 | Method | Description | 660 |================+==================================================| 661 | PUBLISH | Post notification of an event. Used primarily as | 662 | | a method of advertising the existence of an | 663 | | event. | 664 | | | 665 | REQUEST | Make a request for an event. This is an explicit | 666 | | invitation to one or more "Attendees". Event | 667 | | Requests are also used to update or change an | 668 | | existing event. Clients that cannot handle | 669 | | REQUEST may degrade the event to view it as an | 670 | | PUBLISH. | 671 | | | 672 | REPLY | Reply to an event request. Clients may set their | 673 | | status ("partstat") to ACCEPTED, DECLINED, | 674 | | TENTATIVE, or DELEGATED. | 675 | | | 676 | ADD | Add one or more instances to an existing event. | 677 | | | 678 | CANCEL | Cancel one or more instances of an existing | 679 | | event. | 680 | | | 681 | REFRESH | A request is sent to an "Organizer" by an | 682 | | "Attendee" asking for the latest version of an | 683 | | event to be resent to the requester. | 684 | | | 685 | COUNTER | Counter a REQUEST with an alternative proposal, | 686 | | Sent by an "Attendee" to the "Organizer". | 687 | | | 688 | DECLINECOUNTER | Decline a counter proposal. Sent to an | 689 | | "Attendee" by the "Organizer". | 690 +================+==================================================+ 692 3.2.1 PUBLISH 694 The "PUBLISH" method in a "VEVENT" calendar component is an unsolicited 695 posting of an iCalendar object. Any CU may add published components to 696 their calendar. The "Organizer" MUST be present in a published iCalendar 697 component. "Attendees" MUST NOT be present. Its expected usage is for 698 encapsulating an arbitrary event as an iCalendar object. The "Organizer" 699 may subsequently update (with another "PUBLISH" method), add instances 700 to (with an "ADD" method), or cancel (with a "CANCEL" method) a 701 previously published "VEVENT" calendar component. 703 This method type is an iCalendar object that conforms to the following 704 property constraints: 706 Component/Property Presence 707 ------------------- ---------------------------------------------- 708 METHOD 1 MUST equal "PUBLISH" 709 VEVENT 1+ 710 DTSTAMP 1 711 DTSTART 1 712 ORGANIZER 1 713 SUMMARY 1 Can be null. 714 UID 1 715 RECURRENCE-ID 0 or 1 only if referring to an instance of a 716 recurring calendar component. Otherwise it 717 MUST NOT be present. 718 SEQUENCE 0 or 1 MUST be present if value is greater than 0, 719 MAY be present if 0 720 ATTACH 0+ 721 CATEGORIES 0 or 1 This property may contain a list of values 722 CLASS 0 or 1 723 COMMENT 0 or 1 724 CONTACT 0+ 725 CREATED 0 or 1 726 DESCRIPTION 0 or 1 Can be null 727 DTEND 0 or 1 if present DURATION MUST NOT be present 728 DURATION 0 or 1 if present DTEND MUST NOT be present 729 EXDATE 0+ 730 EXRULE 0+ 731 GEO 0 or 1 732 LAST-MODIFIED 0 or 1 733 LOCATION 0 or 1 734 PRIORITY 0 or 1 735 RDATE 0+ 736 RELATED-TO 0+ 737 RESOURCES 0 or 1 This property MAY contain a list of values 738 RRULE 0+ 739 STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED 740 TRANSP 0 or 1 741 URL 0 or 1 742 X-PROPERTY 0+ 744 ATTENDEE 0 745 REQUEST-STATUS 0 747 VALARM 0+ 748 VFREEBUSY 0 749 VJOURNAL 0 750 VTODO 0 751 VTIMEZONE 0+ MUST be present if any date/time refers to a 752 timezone 753 X-COMPONENT 0+ 755 3.2.2 REQUEST 757 The "REQUEST" method in a "VEVENT" component provides the following 758 scheduling functions: 760 . Invite "Attendees" to an event; 761 . Reschedule an existing event; 762 . Response to a REFRESH request; 763 . Update the details of an existing event, without rescheduling it; 764 . Update the status of "Attendees" of an existing event, without 765 rescheduling it; 766 . Reconfirm an existing event, without rescheduling it; 767 . Forward a "VEVENT" to another uninvited CU. 768 . For an existing "VEVENT" calendar component, delegate the role of 769 "Attendee" to another CU; 770 . For an existing "VEVENT" calendar component, changing the role of 771 "Organizer" to another CU. 773 The "Organizer" originates the "REQUEST". The recipients of the 774 "REQUEST" method are the CUs invited to the event, the "Attendees". 775 "Attendees" use the "REPLY" method to convey attendance status to the 776 "Organizer". 778 The "UID" and "SEQUENCE" properties are used to distinguish the various 779 uses of the "REQUEST" method. If the "UID" property value in the 780 "REQUEST" is not found on the recipient's calendar, then the "REQUEST" 781 is for a new "VEVENT" calendar component. If the "UID" property value is 782 found on the recipient's calendar, then the "REQUEST" is for a 783 rescheduling, an update, or a reconfirm of the "VEVENT" calendar 784 component. 786 For the "REQUEST" method, multiple "VEVENT" components in a single 787 iCalendar object are only permitted when for components with the same 788 "UID" property. That is, a series of recurring events may have 789 instance-specific information. In this case, multiple "VEVENT" 790 components are needed to express the entire series. 792 This method type is an iCalendar object that conforms to the following 793 property constraints: 795 Component/Property Presence 796 ----------------------------------------------------------------- 797 METHOD 1 MUST be "REQUEST" 798 VEVENT 1+ All components MUST have the same UID 799 ATTENDEE 1+ 800 DTSTAMP 1 801 DTSTART 1 802 ORGANIZER 1 803 SEQUENCE 0 or 1 MUST be present if value is greater than 0, 804 MAY be present if 0 805 SUMMARY 1 Can be null 806 UID 1 808 ATTACH 0+ 809 CATEGORIES 0 or 1 This property may contain a list of values 810 CLASS 0 or 1 811 COMMENT 0 or 1 812 CONTACT 0+ 813 CREATED 0 or 1 814 DESCRIPTION 0 or 1 Can be null 815 DTEND 0 or 1 if present DURATION MUST NOT be present 816 DURATION 0 or 1 if present DTEND MUST NOT be present 817 EXDATE 0+ 818 EXRULE 0+ 819 GEO 0 or 1 820 LAST-MODIFIED 0 or 1 821 LOCATION 0 or 1 822 PRIORITY 0 or 1 823 RDATE 0+ 824 RECURRENCE-ID 0 or 1 only if referring to an instance of a 825 recurring calendar component. Otherwise it 826 MUST NOT be present. 827 RELATED-TO 0+ 828 REQUEST-STATUS 0+ 829 RESOURCES 0 or 1 This property MAY contain a list of values 830 RRULE 0+ 831 STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED 832 TRANSP 0 or 1 833 URL 0 or 1 834 X-PROPERTY 0+ 836 VALARM 0+ 837 VTIMEZONE 0+ MUST be present if any date/time refers to 838 a timezone 839 X-COMPONENT 0+ 841 VFREEBUSY 0 842 VJOURNAL 0 843 VTODO 0 845 3.2.2.1 Rescheduling an Event 847 The "REQUEST" method may be used to reschedule an event. A rescheduled 848 event involves a change to the existing event in terms of its time or 849 recurrence intervals and possibly the location or description. If the 850 recipient CUA of a "REQUEST" method finds that the "UID" property value 851 already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP") 852 property value in the "REQUEST" method is greater than the value for the 853 existing event, then the "REQUEST" method describes a rescheduling of 854 the event. 856 3.2.2.2 Updating or Reconfirmation of an Event 858 The "REQUEST" method may be used to update or reconfirm an event. An 859 update to an existing event does not involve changes to the time or 860 recurrence intervals, and might not involve a change to the location or 861 description for the event. If the recipient CUA of a "REQUEST" method 862 finds that the "UID" property value already exists on the calendar and 863 that the "SEQUENCE" property value in the "REQUEST" is the same as the 864 value for the existing event, then the "REQUEST" method describes an 865 update of the event details, but no rescheduling of the event. 867 The update "REQUEST" method is the appropriate response to a "REFRESH" 868 method sent from an "Attendee" to the "Organizer" of an event. 870 The "Organizer" of an event may also send unsolicited "REQUEST" methods. 871 The unsolicited "REQUEST" methods may be used to update the details of 872 the event without rescheduling it, to update the "partstat" parameter of 873 "Attendees", or to reconfirm the event. 875 3.2.2.3 Delegating an Event to another CU 877 Some calendar and scheduling systems allow "Attendees" to delegate their 878 presence at an event to another calendar user. ITIP supports this 879 concept using the following workflow. Any "Attendee" may delegate their 880 right to participate in a calendar VEVENT to another CU. The implication 881 is that the delegate participates in lieu of the original "Attendee"; 882 NOT in addition to the "Attendee". The delegator MUST notify the 883 "Organizer" of this action using the steps outlined below. 884 Implementations may support or restrict delegation as they see fit. For 885 instance, some implementations may restrict a delegate from delegating a 886 "REQUEST" to another CU. 888 The "Delegator" of an event forwards the existing "REQUEST" to the 889 "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property 890 with the calendar address of the "Delegate". The "Delegator" MUST also 891 send a "REPLY" method to the "Organizer" with the "Delegator's" 892 "ATTENDEE" property "partstat" parameter value set to "delegated". In 893 addition, the "delegated-to" parameter MUST be included with the 894 calendar address of the "Delegate". 896 In response to the request, the "Delegate" MUST send a "REPLY" method to 897 the "Organizer" and optionally, to the "Delegator". The "REPLY" method " 898 SHOULD include the "ATTENDEE" property with the "delegated-from" 899 parameter value of the "Delegator's" calendar address. 901 The "Delegator" may continue to receive updates to the event even though 902 they will not be attending. This is accomplished by When the "Delegator" 903 sends "REPLY" to the "Organizer" 905 3.2.2.4 Changing the Organizer 907 The situation may arise where the "Organizer" of a VEVENT is no longer 908 able to perform the "Organizer" role and abdicates without passing on 909 the "Organizer" role to someone else. When this occurs the "Attendees" 910 of the VEVENT may use out-of-band mechanisms to communicate the 911 situation and agree upon a new "Organizer". The new "Organizer" should 912 then send out a new "REQUEST" with a modified version of the VEVENT in 913 which the "SEQUENCE" number has been incremented and value of the 914 "ORGANIZER" property has been changed to the calendar address of the new 915 "Organizer". 917 3.2.2.5 Sending on Behalf of the Organizer 919 There are a number of scenarios that support the need for a calendar 920 user to act on behalf of the "Organizer" without explicit role changing. 921 This might be the case if the CU designated as "Organizer" was sick or 922 unable to perform duties associated with that function. In these cases 923 iTIP supports the notion of one CU acting on behalf of another. Using 924 the "sent-by" parameter, a calendar user could send an updated "VEVENT" 925 REQUEST. In the case where one CU sends on behalf of another CU, the 926 "Attendee" responses are still directed back towards the CU designated 927 as "Organizer". 929 3.2.2.6 Forwarding to An Uninvited CU 931 An "Attendee" invited to an event may invite another uninvited CU to the 932 event. The invited "Attendee" accomplishes this by forwarding the 933 original "REQUEST" method to the uninvited CU. The "Organizer" decides 934 whether or not the uninvited CU is added to the attendee list. If the 935 "Organizer" decides not to add the uninvited CU no further action is 936 required, however the "Organizer" MAY send the uninvited CU a "CANCEL" 937 message. If the "Organizer" decides to add uninvited CU, a new 938 "ATTENDEE" property is added for the uninvited CU with its property 939 parameters set as the "Organizer" deems appropriate. When forwarding a 940 "REQUEST" to another CU, the forwarding "Attendee" MUST NOT make changes 941 to the VEVENT property set. 943 3.2.2.7 Updating Attendee Status 945 The "Organizer" of an event may also request updated status from one or 946 more "Attendees. The "Organizer" sends a "REQUEST" method to the 947 "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The 948 "SEQUENCE" property for the event is not changed from its previous 949 value. A recipient will determine that the only change in the "REQUEST" 950 is that their "RSVP" property parameter indicates a request for updated 951 status. The recipient SHOULD respond with a "REPLY" method indicating 952 their current status with respect to the "REQUEST". 954 3.2.3 REPLY 956 The "REPLY" method in a "VEVENT" calendar component is used to respond 957 (e.g., accept or decline) to a "REQUEST" or to reply to a delegation 958 "REQUEST". When used to provide a delegation response, the "Delegator" 959 SHOULD include the calendar address of the "Delegate" on the "delegated- 960 to" property parameter of the "Delegator's" "ATTENDEE" property. The 961 "Delegate" SHOULD include the calendar address of the "Delegator" on the 962 "delegated-from" property parameter of the "Delegate's" "ATTENDEE" 963 property. 965 The "REPLY" method may also be used to respond to an unsuccessful 966 "REQUEST" method. Depending on the value of the "REQUEST-STATUS" 967 property no scheduling action may have been performed. 969 The "Organizer" of an event may receive the "REPLY" method from a CU not 970 in the original "REQUEST". For example, a "REPLY" may be received from a 971 "Delegate" to an event. In addition, the "REPLY" method may be received 972 from an unknown CU (a "Party Crasher"). This uninvited "Attendee" may be 973 accepted, or the "Organizer" may cancel the event for the uninvited 974 "Attendee" by sending a "CANCEL" method to the uninvited "Attendee". 976 An "Attendee" can include a message to the "Organizer" using the 977 "COMMENT" property. For example, if the user indicates tentative 978 acceptance and wants to let the "Organizer" know why, the reason can be 979 expressed in the "COMMENT" property value. 981 The "Organizer" may also receive a "REPLY" from one CU on behalf of 982 another. Like the scenario enumerated above for the "Organizer", 983 "Attendees" may have another CU respond on their behalf. This is done 984 using the "sent-by" parameter. 986 The optional properties listed in the table below (those listed as "0+" 987 or "0 or 1") MUST NOT be changed from those of the original request. If 988 property changes are desired the COUNTER message must be used. 990 This method type is an iCalendar object that conforms to the following 991 property constraints: 993 Component/Property Presence 994 ------------------- ---------------------------------------------- 995 METHOD 1 MUST be "REPLY" 997 VEVENT 1+ All components MUST have the same UID 998 ATTENDEE 1 MUST be the address of the Attendee 999 replying. 1000 DTSTAMP 1 1001 ORGANIZER 1 1002 RECURRENCE-ID 0 or 1 only if referring to an instance of a 1003 recurring calendar component. Otherwise it 1004 must NOT be present. 1005 UID 1 MUST be the UID of the original REQUEST 1007 SEQUENCE 0 or 1 MUST if non-zero, MUST be the sequence 1008 number of the original REQUEST. MAY be 1009 present if 0. 1011 ATTACH 0+ 1012 CATEGORIES 0 or 1 This property may contain a list of values 1013 CLASS 0 or 1 1014 COMMENT 0 or 1 1015 CONTACT 0+ 1016 CREATED 0 or 1 1017 DESCRIPTION 0 or 1 1018 DTEND 0 or 1 if present DURATION MUST NOT be present 1019 DTSTART 0 or 1 1020 DURATION 0 or 1 if present DTEND MUST NOT be present 1021 EXDATE 0+ 1022 EXRULE 0+ 1023 GEO 0 or 1 1024 LAST-MODIFIED 0 or 1 1025 LOCATION 0 or 1 1026 PRIORITY 0 or 1 1027 RDATE 0+ 1028 RELATED-TO 0+ 1029 RESOURCES 0 or 1 This property MAY contain a list of values 1030 REQUEST-STATUS 0+ 1031 RRULE 0+ 1032 STATUS 0 or 1 1033 SUMMARY 0 or 1 1034 TRANSP 0 or 1 1035 URL 0 or 1 1036 X-PROPERTY 0+ 1038 VTIMEZONE 0 or 1 MUST be present if any date/time refers to a 1039 timezone 1040 X-COMPONENT 0+ 1042 VALARM 0 1043 VFREEBUSY 0 1044 VJOURNAL 0 1045 VTODO 0 1047 3.2.4 ADD 1049 The "ADD" method in a "VEVENT" calendar component is used to add one or 1050 more instances to an existing "VEVENT". Unlike the "REQUEST" method, 1051 when using issuing an "ADD" method, the "Organizer" does not send the 1052 full "VEVENT" description; only the new instance(s). The "ADD" method is 1053 especially useful if there are instance-specific properties to be 1054 preserved in a recurring "VEVENT". For instance, an "Organizer" may have 1055 originally scheduled a weekly Thursday meeting. At some point, several 1056 instances changed. Location or start time may have changed, or some 1057 instances may have unique "DESCRIPTION" properties. The "ADD" method 1058 allows the "Organizer" to add new instances to an existing event using a 1059 single ITIP message without redefining the entire recurring pattern. 1061 The "UID" must be that of the existing event. If the "UID" property 1062 value in the "ADD" is not found on the recipient's calendar, then the 1063 recipient SHOULD send a "REFRESH" to the "Organizer" in order to be 1064 updated with the latest version of the "VEVENT". If an "Attendee" 1065 implementation does not support the "ADD" method it should respond with 1066 a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH". 1068 This method type is an iCalendar object that conforms to the following 1069 property constraints: 1071 Component/Property Presence 1072 ------------------- ---------------------------------------------- 1073 METHOD 1 MUST be "ADD" 1074 VEVENT 1 1075 DTSTAMP 1 1076 DTSTART 1 1077 ORGANIZER 1 1078 SEQUENCE 1 MUST be greater than 0 1079 SUMMARY 1 Can be null 1080 UID 1 MUST match that of the original event 1082 ATTACH 0+ 1083 ATTENDEE 0+ 1084 CATEGORIES 0 or 1 This property MAY contain a list of values 1085 CLASS 0 or 1 1086 COMMENT 0 or 1 1087 CONTACT 0+ 1088 CREATED 0 or 1 1089 DESCRIPTION 0 or 1 Can be null 1090 DTEND 0 or 1 if present DURATION MUST NOT be present 1091 DURATION 0 or 1 if present DTEND MUST NOT be present 1092 EXDATE 0+ 1093 EXRULE 0+ 1094 GEO 0 or 1 1095 LAST-MODIFIED 0 or 1 1096 LOCATION 0 or 1 1097 PRIORITY 0 or 1 1098 RDATE 0+ 1099 RELATED-TO 0+ 1100 RESOURCES 0 or 1 This property MAY contain a list of values 1101 RRULE 0+ 1102 STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED 1103 TRANSP 0 or 1 1104 URL 0 or 1 1105 X-PROPERTY 0+ 1107 RECURRENCE-ID 0 1108 REQUEST-STATUS 0 1110 VALARM 0+ 1111 VTIMEZONE 0+ MUST be present if any date/time refers to 1112 a timezone 1113 X-COMPONENT 0+ 1115 VFREEBUSY 0 1116 VTODO 0 1117 VJOURNAL 0 1119 3.2.5 CANCEL 1121 The "CANCEL" method in a "VEVENT" calendar component is used to send a 1122 cancellation notice of an existing event request to the "Attendees". The 1123 message is sent by the "Organizer" of the event. For a recurring event, 1124 either the whole event or instances of an event may be cancelled. To 1125 cancel the complete range of recurring event, the "UID" property value 1126 for the event MUST be specified and a "RECURRENCE-ID" MUST NOT be 1127 specified in the "CANCEL" method. In order to cancel an individual 1128 instance of the event, the "RECURRENCE-ID" property value for the event 1129 MUST be specified in the "CANCEL" method. 1131 There are two options for canceling a sequence of instances of a 1132 recurring "VEVENT" calendar component: 1134 (a) the "RECURRENCE-ID" property for an instance in the sequence MUST be 1135 specified with the "RANGE" property parameter value of THISANDPRIOR 1136 (or THISANDFUTURE) to indicate cancellation of the specified 1137 "VEVENT" calendar component and all instances before (or after); or 1139 (b) individual recurrence instances may be cancelled by specifying 1140 multiple "RECURRENCE-ID" properties corresponding to the instances to 1141 be cancelled. 1143 When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be 1144 incremented. 1146 This method type is an iCalendar object that conforms to the following 1147 property constraints: 1149 Component/Property Presence 1150 ------------------- ---------------------------------------------- 1151 METHOD 1 MUST be "CANCEL" 1153 VEVENT 1+ All must have the same UID 1154 ATTENDEE 0+ MUST include all "Attendees" being removed 1155 the event. MUST include all "Attendees" if 1156 the entire event is cancelled. 1157 DTSTAMP 1 1158 ORGANIZER 1 1159 SEQUENCE 1 1160 UID 1 MUST be the UID of the original REQUEST 1162 COMMENT 0 or 1 1163 ATTACH 0+ 1164 CATEGORIES 0 or 1 This property may contain a list of values 1165 CLASS 0 or 1 1166 CONTACT 0+ 1167 CREATED 0 or 1 1168 DESCRIPTION 0 or 1 1169 DTEND 0 or 1 if present DURATION MUST NOT be present 1170 DTSTART 0 or 1 1171 DURATION 0 or 1 if present DTEND MUST NOT be present 1172 EXDATE 0+ 1173 EXRULE 0+ 1174 GEO 0 or 1 1175 LAST-MODIFIED 0 or 1 1176 LOCATION 0 or 1 1177 PRIORITY 0 or 1 1178 RDATE 0+ 1179 RECURRENCE-ID 0 or 1 MUST be present if referring to one or more 1180 or more recurring instances. Otherwise it 1181 MUST NOT be present 1182 RELATED-TO 0+ 1183 RESOURCES 0 or 1 1184 RRULE 0+ 1185 STATUS 0 or 1 MUST be set to CANCELLED. If uninviting 1186 specific "Attendees" then MUST NOT be 1187 included. 1188 SUMMARY 0 or 1 1189 TRANSP 0 or 1 1190 URL 0 or 1 1191 X-PROPERTY 0+ 1192 REQUEST-STATUS 0 1194 VTIMEZONE 0+ MUST be present if any date/time refers to 1195 a timezone 1196 X-COMPONENT 0+ 1198 VTODO 0 1199 VJOURNAL 0 1200 VFREEBUSY 0 1201 VALARM 0 1203 3.2.6 REFRESH 1205 The "REFRESH" method in a "VEVENT" calendar component is used by 1206 "Attendees" of an existing event to request an updated description from 1207 the event "Organizer". The "REFRESH" method must specify the "UID" 1208 property of the event to update. A recurrence instance of an event may 1209 be requested by specifying the "RECURRENCE-ID" property corresponding to 1210 the associated event. The "Organizer" responds with the latest 1211 description and version of the event. 1213 This method type is an iCalendar object that conforms to the following 1214 property constraints: 1216 Component/Property Presence 1217 ------------------- ---------------------------------------------- 1218 METHOD 1 MUST be "REFRESH" 1220 VEVENT 1 1221 ATTENDEE 1 MUST be the address of requestor 1222 DTSTAMP 1 1223 ORGANIZER 1 1224 UID 1 MUST be the UID associated with original 1225 REQUEST 1226 COMMENT 0 or 1 1227 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a 1228 recurring calendar component. Otherwise it 1229 must NOT be present. 1230 X-PROPERTY 0+ 1232 ATTACH 0 1233 CATEGORIES 0 1234 CLASS 0 1235 CONTACT 0 1236 CREATED 0 1237 DESCRIPTION 0 1238 DTEND 0 1239 DTSTART 0 1240 DURATION 0 1241 EXDATE 0 1242 EXRULE 0 1243 GEO 0 1244 LAST-MODIFIED 0 1245 LOCATION 0 1246 PRIORITY 0 1247 RDATE 0 1248 RELATED-TO 0 1249 REQUEST-STATUS 0 1250 RESOURCES 0 1251 RRULE 0 1252 SEQUENCE 0 1253 STATUS 0 1254 SUMMARY 0 1255 TRANSP 0 1256 URL 0 1258 X-COMPONENT 0+ 1260 VTODO 0 1261 VJOURNAL 0 1262 VFREEBUSY 0 1263 VTIMEZONE 0 1264 VALARM 0 1266 3.2.7 COUNTER 1268 The "COUNTER" method for a "VEVENT" calendar component is used by an 1269 "Attendee" of an existing event to submit to the "Organizer" a counter 1270 proposal to the event description. The "Attendee" sends this message to 1271 the "Organizer" of the event. 1273 The counter proposal is an iCalendar object consisting of a VEVENT 1274 calendar component describing the complete description of the alternate 1275 event. 1277 The "Organizer" rejects the counter proposal by sending the "Attendee" a 1278 VEVENT "DECLINECOUNTER" method. The "Organizer" accepts the counter 1279 proposal by rescheduling the event as described in section 3.2.2.1 1280 Rescheduling an Event. 1282 This method type is an iCalendar object that conforms to the following 1283 property constraints: 1285 Component/Property Presence 1286 ------------------- ---------------------------------------------- 1287 METHOD 1 MUST be "COUNTER" 1289 VEVENT 1 1290 DTSTAMP 1 1291 DTSTART 1 1292 ORGANIZER 1 MUST be the "Organizer" of the original 1293 event 1294 SEQUENCE 1 MUST be present if value is greater than 0, 1295 MAY be present if 0 1296 SUMMARY 1 Can be null 1297 UID 1 MUST be the UID associated with the REQUEST 1298 being countered 1300 ATTACH 0+ 1301 ATTENDEE 0+ Can also be used to propose other 1302 "Attendees" 1303 CATEGORIES 0 or 1 This property may contain a list of values 1304 CLASS 0 or 1 1305 COMMENT 0 or 1 1306 CONTACT 0+ 1307 CREATED 0 or 1 1308 DESCRIPTION 0 or 1 1309 DTEND 0 or 1 if present DURATION MUST NOT be present 1310 DURATION 0 or 1 if present DTEND MUST NOT be present 1311 EXDATE 0+ 1312 EXRULE 0+ 1313 GEO 0 or 1 1314 LAST-MODIFIED 0 or 1 1315 LOCATION 0 or 1 1316 PRIORITY 0 or 1 1317 RDATE 0+ 1318 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a 1319 recurring calendar component. Otherwise it 1320 MUST NOT be present. 1321 RELATED-TO 0+ 1322 REQUEST-STATUS 0+ 1323 RESOURCES 0 or 1 This property may contain a list of values 1324 RRULE 0+ 1325 STATUS 0 or 1 Value must be one of CONFIRMED/TENATIVE/ 1326 CANCELLED 1327 TRANSP 0 or 1 1328 URL 0 or 1 1329 X-PROPERTY 0+ 1331 VALARM 0+ 1332 VTIMEZONE 0+ MUST be present if any date/time refers to 1333 a timezone 1334 X-COMPONENT 0+ 1336 VTODO 0 1337 VJOURNAL 0 1338 VFREEBUSY 0 1340 3.2.8 DECLINECOUNTER 1342 The "DECLINECOUNTER" method in a "VEVENT" calendar component is used by 1343 the "Organizer" of an event to reject a counter proposal submitted by an 1344 "Attendee". The "Organizer" must send the "DECLINECOUNTER" message to 1345 the "Attendee" that sent the "COUNTER" method to the "Organizer". 1347 This method type is an iCalendar object that conforms to the following 1348 property constraints: 1350 Component/Property Presence 1351 ------------------- ---------------------------------------------- 1352 METHOD 1 MUST be "DECLINECOUNTER" 1354 VEVENT 1 1355 DTSTAMP 1 1356 ORGANIZER 1 1357 UID 1 MUST, same UID specified in original 1358 REQUEST and subsequent COUNTER 1359 COMMENT 0 or 1 1360 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a 1361 recurring calendar component. Otherwise it 1362 MUST NOT be present. 1363 REQUEST-STATUS 0+ 1364 SEQUENCE 0 OR 1 MUST be present if value is greater than 0, 1365 MAY be present if 0 1366 X-PROPERTY 0+ 1368 ATTACH 0 1369 ATTENDEE 0 1370 CATEGORIES 0 1371 CLASS 0 1372 CONTACT 0 1373 CREATED 0 1374 DESCRIPTION 0 1375 DTEND 0 1376 DTSTART 0 1377 DURATION 0 1378 EXDATE 0 1379 EXRULE 0 1380 GEO 0 1381 LAST-MODIFIED 0 1382 LOCATION 0 1383 PRIORITY 0 1384 RDATE 0 1385 RELATED-TO 0 1386 RESOURCES 0 1387 RRULE 0 1388 STATUS 0 1389 SUMMARY 0 1390 TRANSP 0 1391 URL 0 1393 X-COMPONENT 0+ 1394 VTODO 0 1395 VJOURNAL 0 1396 VFREEBUSY 0 1397 VTIMEZONE 0 1398 VALARM 0 1400 3.3 Methods For VFREEBUSY Components 1402 This section defines the property set for the methods that are 1403 applicable to the "VFREEBUSY" calendar component. Each of the methods is 1404 defined using a restriction table. 1406 This document only addresses the transfer of busy time information. 1407 Applications desiring free time information MUST infer this from 1408 available busy time information. 1410 The busy time information within the iCalendar object MAY be grouped 1411 into more than one "VFREEBUSY" calendar component. This capability 1412 allows busy time periods to be grouped according to some common 1413 periodicity, such as a calendar week, month, or year. In this case, each 1414 "VFREEBUSY" calendar component MUST include the "ATTENDEE", "DTSTART" 1415 and "DTEND" properties in order to specify the source of the busy time 1416 information and the date and time interval over which the busy time 1417 information covers. 1419 The "FREEBUSY" property value MAY include a list of values, separated by 1420 the COMMA character (ASCII decimal 44). Alternately, multiple busy time 1421 periods MAY be specified with multiple instances of the "FREEBUSY" 1422 property. Both forms MUST be supported by implementations conforming to 1423 this document. Duplicate busy time periods SHOULD NOT be specified in an 1424 iCalendar object. However, two different busy time periods MAY overlap. 1426 "FREEBUSY" properties should be sorted such that their values are in 1427 ascending order, based on the start time, and then the end time, with 1428 the earliest periods first. For example, today's busy time information 1429 should appear after yesterday's busy time information. And the busy time 1430 for this half-hour should appear after the busy time for earlier today. 1432 Since events may span a day boundary, free busy time period may also 1433 span a day boundary. Individual "A" requests busy time from individuals 1434 "B", "C" and "D". Individual "B" and "C" replies with busy time data to 1435 individual "A". Individual "D" does not support busy time requests and 1436 does not reply with any data. If the transport binding supports 1437 exception messages, then individual "D" returns an "unsupported 1438 capability" message to individual "A". 1440 The following summarizes the methods that are defined for the 1441 "VFREEBUSY" calendar component. 1443 |================|==================================================| 1444 | Method | Description | 1445 |================|==================================================| 1446 | PUBLISH | Publish unsolicited busy time data. | 1447 | REQUEST | Request busy time data. | 1448 | REPLY | Reply to a busy time request. | 1449 |================|==================================================| 1451 3.3.1 PUBLISH 1453 The "PUBLISH" method in a "VFREEBUSY" calendar component is used to 1454 publish busy time data. The method may be sent from one CU to any other. 1455 The purpose of the method is to provide a message for sending 1456 unsolicited busy time data. That is, the busy time data is not being 1457 sent as a "REPLY" to the receipt of a "REQUEST" method. 1459 The "ATTENDEE" property must be specified in the busy time information. 1460 The value is the CU address of the originator of the busy time 1461 information. 1463 This method type is an iCalendar object that conforms to the following 1464 property constraints: 1466 Component/Property Presence 1467 ------------------- ---------------------------------------------- 1468 METHOD 1 MUST be "PUBLISH" 1470 VFREEBUSY 1+ 1471 DTSTAMP 1 1472 DTSTART 1 DateTime values must be in UTC 1473 DTEND 1 DateTime values must be in UTC 1474 FREEBUSY 1+ MUST be BUSYTIME. Multiple instances are 1475 allowed. Multiple instances must be sorted 1476 in ascending order 1477 ORGANIZER 1 MUST contain the address of originator of 1478 busy time data. 1480 COMMENT 0 or 1 1481 CONTACT 0+ 1482 X-PROPERTY 0+ 1483 URL 0 or 1 Specifies busy time URL 1485 ATTENDEE 0 1486 DURATION 0 1487 REQUEST-STATUS 0 1488 UID 0 1490 X-COMPONENT 0+ 1492 VEVENT 0 1493 VTODO 0 1494 VJOURNAL 0 1495 VTIMEZONE 0 1496 VALARM 0 1498 3.3.2 REQUEST 1500 The "REQUEST" method in a "VFREEBUSY" calendar component is used to ask 1501 a "Calendar User" for their busy time information. The request may be 1502 for a busy time information bounded by a specific date and time 1503 interval. 1505 This message only permits requests for busy time information. The 1506 message is sent from a "Calendar User" requesting the busy time 1507 information to one or more intended recipients. 1509 If the originator of the "REQUEST" method is not authorized to make a 1510 busy time request on the recipient's calendar system, then an exception 1511 message SHOULD be returned in a "REPLY" method, but no busy time data 1512 need be returned. 1514 This method type is an iCalendar object that conforms to the following 1515 property constraints: 1517 Component/Property Presence 1518 ------------------- ---------------------------------------------- 1519 METHOD 1 MUST be "REQUEST" 1521 VFREEBUSY 1 1522 ATTENDEE 1+ contain the address of the calendar store 1523 for which busy time is being requested. 1524 DTEND 1 DateTime values must be in UTC 1525 DTSTAMP 1 1526 DTSTART 1 DateTime values must be in UTC 1527 ORGANIZER 1 MUST be the request originator's address 1528 UID 1 1529 COMMENT 0 or 1 1530 CONTACT 0+ 1531 X-PROPERTY 0+ 1533 FREEBUSY 0 1534 DURATION 0 1535 REQUEST-STATUS 0 1536 URL 0 1538 X-COMPONENT 0+ 1539 VALARM 0 1540 VEVENT 0 1541 VTODO 0 1542 VJOURNAL 0 1543 VTIMEZONE 0 1545 3.3.3 REPLY 1547 The "REPLY" method in a "VFREEBUSY" calendar component is used to 1548 respond to a busy time request. The method is sent by the recipient of a 1549 busy time request to the originator of the request. 1551 The "REPLY" method may also be used to respond to an unsuccessful 1552 "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy time 1553 information may be returned. 1555 This method type is an iCalendar object that conforms to the following 1556 property constraints: 1558 Component/Property Presence 1559 ------------------- ---------------------------------------------- 1560 METHOD 1 MUST be "REPLY" 1562 VFREEBUSY 1 1563 ATTENDEE 1 (address of recipient replying) 1564 DTSTAMP 1 1565 DTEND 1 DateTime values must be in UTC 1566 DTSTART 1 DateTime values must be in UTC 1567 FREEBUSY 1+ (values MUST all be of the same data 1568 type. Multiple instances are allowed. 1569 Multiple instances MUST be sorted in 1570 ascending order. Values MAY NOT overlap) 1571 ORGANIZER 1 MUST be the request originator's address 1572 UID 1 1574 COMMENT 0 or 1 1575 CONTACT 0+ 1576 REQUEST-STATUS 0+ 1577 URL 0 or 1 (specifies busy time URL) 1578 X-PROPERTY 0+ 1579 DURATION 0 1580 SEQUENCE 0 1582 X-COMPONENT 0+ 1583 VALARM 0 1584 VEVENT 0 1585 VTODO 0 1586 VJOURNAL 0 1587 VTIMEZONE 0 1589 3.4 Methods For VTODO Components 1591 This section defines the property set for the methods that are 1592 applicable to the "VTODO" calendar component. Each of the methods is 1593 defined using a restriction table that specifies the property 1594 constraints that define the particular method. 1596 The following summarizes the methods that are defined for the "VTODO" 1597 calendar component. 1599 +================+==================================================+ 1600 | Method | Description | 1601 |================+==================================================| 1602 | PUBLISH | Post notification of a VTODO. Used primarily as | 1603 | | a method of advertising the existence of a VTODO.| 1604 | | | 1605 | REQUEST | Assign a VTODO. This is an explicit assignment to| 1606 | | one or more Calendar Users. The REQUEST method | 1607 | | is also used to update or change an existing | 1608 | | VTODO. Clients that cannot handle REQUEST MAY | 1609 | | degrade the method to treat it as a PUBLISH. | 1610 | | | 1611 | REPLY | Reply to a VTODO request. Attendees MAY set | 1612 | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, | 1613 | | DELEGATED, PARTIAL, and COMPLETED. | 1614 | | | 1615 | ADD | Add one or more instances to an existing to-do. | 1616 | | | 1617 | CANCEL | Cancel one or more instances of an existing | 1618 | | to-do. | 1619 | | | 1620 | REFRESH | A request sent to a VTODO Organizer asking for | 1621 | | the latest version of a VTODO. | 1622 | | | 1623 | COUNTER | Counter a REQUEST with an alternative proposal. | 1624 | | | 1625 | DECLINECOUNTER | Decline a counter proposal by an Attendee. | 1626 +================+==================================================+ 1628 3.4.1 PUBLISH 1630 The "PUBLISH" method in a "VTODO" calendar component has no associated 1631 response. It is simply a posting of an iCalendar object that maybe added 1632 to a calendar. It MUST have an "Organizer". It MUST NOT have 1633 "Attendees". Its expected usage is for encapsulating an arbitrary 1634 "VTODO" calendar component as an iCalendar object. The "Organizer" MAY 1635 subsequently update (with another "PUBLISH" method), add instances to 1636 (win an "ADD" method), or cancel (with a "CANCEL" method) a previously 1637 published "VTODO" calendar component. 1639 This method type is an iCalendar object that conforms to the following 1640 property constraints: 1642 Component/Property Presence 1643 ------------------- ---------------------------------------------- 1644 METHOD 1 MUST be "PUBLISH" 1645 VTODO 1+ 1646 DTSTAMP 1 1647 DTSTART 1 1648 ORGANIZER 1 1649 PRIORITY 1 1650 SEQUENCE 0 or 1 MUST be present if value is greater than 1651 0, MAY be present if 0 1652 SUMMARY 1 Can be null. 1653 UID 1 1655 ATTACH 0+ 1656 CATEGORIES 0 or 1 This property may contain a list of values 1657 CLASS 0 or 1 1658 COMMENT 0 or 1 1659 CONTACT 0+ 1660 CREATED 0 or 1 1661 DESCRIPTION 0 or 1 Can be null 1662 DUE 0 or 1 If present DURATION MUST NOT be present 1663 DURATION 0 or 1 If present DUE MUST NOT be present 1664 EXDATE 0+ 1665 EXRULE 0+ 1666 GEO 0 or 1 1667 LAST-MODIFIED 0 or 1 1668 LOCATION 0 or 1 1669 PERCENT-COMPLETE 0 or 1 1670 RDATE 0+ 1671 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a 1672 recurring calendar component. Otherwise 1673 it MUST NOT be present. 1675 RELATED-TO 0+ 1676 RESOURCES 0 or 1 This property may contain a list of values 1677 RRULE 0+ 1678 STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- 1679 PROCESS/CANCELLED 1680 URL 0 or 1 1681 X-PROPERTY 0+ 1683 ATTENDEE 0 1684 REQUEST-STATUS 0 1686 VTIMEZONE 0+ MUST be present if any date/time refers to 1687 a timezone 1688 VALARM 0+ 1689 X-COMPONENT 0+ 1691 VFREEBUSY 0 1692 VEVENT 0 1693 VJOURNAL 0 1695 3.4.2 REQUEST 1697 The "REQUEST" method in a "VTODO" calendar component provides the 1698 following scheduling functions: 1700 . Assign a to-do to one or more "Calendar Users"; 1701 . Reschedule an existing to-do; 1702 . Update the details of an existing to-do, without rescheduling it; 1703 . Update the completion status of "Attendees" of an existing to-do, 1704 without rescheduling it; 1705 . Reconfirm an existing to-do, without rescheduling it; 1706 . Delegate/reassign an existing to-do to another "Calendar User". 1708 The assigned "Calendar Users" are identified in the "VTODO" calendar 1709 component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property value 1710 sequences. 1712 The originator of a "REQUEST" is the "Organizer" of the to-do. The 1713 recipient of a "REQUEST" is the "Calendar User" assigned the to-do. The 1714 "Attendee" uses the "REPLY" method to convey their acceptance and 1715 completion status to the "Organizer" of the "REQUEST". 1717 The "UID", "SEQUENCE", and "DTSTAMP" properties are used to distinguish 1718 the various uses of the "REQUEST" method. If the "UID" property value in 1719 the "REQUEST" is not found on the recipient's calendar, then the 1720 "REQUEST" is for a new to-do. If the "UID" property value is found on 1721 the recipient's calendar, then the "REQUEST" is a rescheduling, an 1722 update, or a reconfirm of the "VTODO" calendar object. 1724 If the "Organizer" of the "REQUEST" method is not authorized to make a 1725 to-do request on the "Attendee's" calendar system, then an exception is 1726 returned in the "REQUEST-STATUS" property of a subsequent "REPLY" 1727 method, but no scheduling action is performed. 1729 For the "REQUEST" method, multiple "VTODO" components in a single 1730 iCalendar object are only permitted when for components with the same 1731 "UID" property. That is, a series of recurring events may have 1732 instance-specific information. In this case, multiple "VTODO" 1733 components are needed to express the entire series. 1735 This method type is an iCalendar object that conforms to the following 1736 property constraints: 1738 Component/Property Presence 1739 ------------------- ---------------------------------------------- 1740 METHOD 1 MUST be "REQUEST" 1741 VTODO 1+ All components must have the same UID 1742 ATTENDEE 1+ 1743 DTSTAMP 1 1744 DTSTART 1 1745 ORGANIZER 1 1746 PRIORITY 1 1747 SEQUENCE 0 or 1 MUST be present if value is greater than 1748 0, MAY be present if 0 1749 SUMMARY 1 Can be null. 1750 UID 1 1752 ATTACH 0+ 1753 CATEGORIES 0 or 1 This property may contain a list of 1754 values 1755 CLASS 0 or 1 1756 COMMENT 0 or 1 1757 CONTACT 0+ 1758 CREATED 0 or 1 1759 DESCRIPTION 0 or 1 Can be null 1760 DUE 0 or 1 If present DURATION MUST NOT be present 1761 DURATION 0 or 1 If present DUE MUST NOT be present 1762 EXDATE 0+ 1763 EXRULE 0+ 1764 GEO 0 or 1 1765 LAST-MODIFIED 0 or 1 1766 LOCATION 0 or 1 1767 PERCENT-COMPLETE 0 or 1 1768 RDATE 0+ 1769 RECURRENCE-ID 0 or 1 present if referring to an instance of a 1770 recurring calendar component. Otherwise 1771 it MUST NOT be present. 1772 RELATED-TO 0+ 1773 RESOURCES 0 or 1 This property may contain a list of 1774 values 1775 RRULE 0+ 1776 STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- 1777 PROCESS 1778 URL 0 or 1 1779 X-PROPERTY 0+ 1781 REQUEST-STATUS 0 1783 VALARM 0+ 1784 VTIMEZONE 0+ MUST be present if any date/time refers 1785 to a timezone 1786 X-COMPONENT 0+ 1788 VEVENT 0 1789 VFREEBUSY 0 1790 VJOURNAL 0 1792 3.4.2.1 REQUEST for Rescheduling a VTODO 1794 The "REQUEST" method may be used to reschedule a "VTODO" calendar 1795 component. 1797 Rescheduling a "VTODO" calendar component involves a change to the 1798 existing "VTODO" calendar component in terms of its start or due time or 1799 recurrence intervals and possibly the description. If the recipient CUA 1800 of a "REQUEST" method finds that the "UID" property value already exists 1801 on the calendar, but that the "SEQUENCE" property value in the "REQUEST" 1802 is greater than the value for the existing VTODO, then the "REQUEST" 1803 method describes a rescheduling of the "VTODO" calendar component. 1805 3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO 1807 The "REQUEST" method may be used to update or reconfirm a "VTODO" 1808 calendar component. Reconfirmation is merely an update of "Attendee" 1809 completion status or overall "VTODO" calendar component status. 1811 An update to an existing "VTODO" calendar component does not involve 1812 changes to the start or due time or recurrence intervals, nor generally 1813 to the description for the "VTODO" calendar component. If the recipient 1814 CUA of a "REQUEST" method finds that the "UID" property value already 1815 exists on the calendar and that the "SEQUENCE" property value in the 1816 "REQUEST" is the same as the value for the existing event, then the 1817 "REQUEST" method describes an update of the "VTODO" calendar component 1818 details, but not a rescheduling of the "VTODO" calendar component. 1820 The update "REQUEST" is the appropriate response to a "REFRESH" method 1821 sent from an "Attendee" to the "Organizer" of a "VTODO" calendar 1822 component. 1824 Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a 1825 "VTODO" calendar component. The unsolicited "REQUEST" methods are used 1826 to update the details of the "VTODO" (without rescheduling it or 1827 updating the completion status of "Attendees") or the "VTODO" calendar 1828 component itself (i.e., reconfirm the "VTODO"). 1830 3.4.2.3 REQUEST for Delegating a VTODO 1832 The "REQUEST" method is also used to delegate or reassign ownership of a 1833 "VTODO" calendar component to another "Calendar User". For example, it 1834 may be used to delegate an "Attendee's" role (i.e. "chair", or 1835 "participant") for a "VTODO" calendar component. The "REQUEST" method is 1836 sent by one of the "Attendees" of an existing "VTODO" calendar component 1837 to some other individual. An "Attendee" of a "VTODO" calendar component 1838 MUST NOT delegate to the "Organizer" of the event. 1840 For the purposes of this description, the "Attendee" delegating the 1841 "VTODO" calendar component is referred to as the "Delegator". The 1842 "Attendee" receiving the delegation request is referred to as the 1843 "Delegate". 1845 The "Delegator" of a "VTODO" calendar component MUST forward the 1846 existing "REQUEST" method for a "VTODO" calendar component to the 1847 "Delegate". The "VTODO" calendar component description MUST include the 1848 "Delegator's" up-to-date "VTODO" calendar component definition. The 1849 "REQUEST" method MUST also include an "ATTENDEE" property with the 1850 calendar address of the "Delegate". The "Delegator" MUST also send a 1851 "REPLY" method back to the "Organizer" with the "Delegator's" "Attendee" 1852 property "partstat" parameter value set to "DELEGATED". In addition, the 1853 "delegated-to" parameter MUST be included with the calendar address of 1854 the "Delegate". A response to the delegation "REQUEST" is sent from the 1855 "Delegate" to the "Organizer" and optionally, to the "Delegator". The 1856 "REPLY" method from the "Delegate" SHOULD include the "ATTENDEE" 1857 property with their calendar address and the "delegated-from" parameter 1858 with the value of the "Delegator's" calendar address. 1860 The delegation "REQUEST" method MUST assign a value for the "RSVP" 1861 property parameter associated with the "Delegator's" "Attendee" property 1862 to that of the "Delegate's" "ATTENDEE" property. For example if the 1863 "Delegator's" "ATTENDEE" property specifies "RSVP=TRUE", then the 1864 "Delegate's" "ATTENDEE" property MUST specify "RSVP=TRUE". 1866 3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User 1868 An "Attendee" assigned a "VTODO" calendar component may send the "VTODO" 1869 calendar component to another new CU, not previously associated with the 1870 "VTODO" calendar component. The current "Attendee" assigned the "VTODO" 1871 calendar component does this by forwarding the original "REQUEST" method 1872 to the new CU. The new CU can send a "REPLY" to the "Organizer" of the 1873 "VTODO" calendar component. The reply contains an "ATTENDEE" property 1874 for the new CU. 1876 The "Organizer" ultimately decides whether or not the new CU becomes 1877 part of the to-do and is not obligated to do anything with a "REPLY" 1878 from a new (uninvited) CU. If the "Organizer" does not want the new CU 1879 to be part of the to-do, the new "ATTENDEE" property is not added to the 1880 "VTODO" calendar component. The "Organizer" MAY send the CU a "CANCEL" 1881 message to indicate that they will not be added to the to-do. If the 1882 "Organizer" decides to add the new CU, the new "ATTENDEE" property is 1883 added to the "VTODO" calendar component. Furthermore, the "Organizer" is 1884 free to change any "ATTENDEE" property parameter from the values 1885 supplied by the new CU to something the "Organizer" considers 1886 appropriate. 1888 3.4.2.5 REQUEST Updated Attendee Status 1890 An "Organizer" of a "VTODO" may request an updated status from one or 1891 more "Attendees". The "Organizer" sends a "REQUEST" method to the 1892 "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The 1893 "SEQUENCE" property for the "VTODO" is not changed from its previous 1894 value. A recipient determines that the only change in the "REQUEST" is 1895 that their "RSVP" property parameter indicates a request for an updated 1896 status. The recipient SHOULD respond with a "REPLY" method indicating 1897 their current status with respect to the "REQUEST". 1899 3.4.3 REPLY 1901 The "REPLY" method in a "VTODO" calendar component is used to respond 1902 (e.g., accept or decline) to a request or to reply to a delegation 1903 request. It is also used by an "Attendee" to update their completion 1904 status. When used to provide a delegation response, the "Delegator" MUST 1905 include the calendar address of the "Delegate" in the "delegated-to" 1906 parameter of the "Delegator's" "ATTENDEE" property. The "Delegate" MUST 1907 include the calendar address of the "Delegator" on the "delegated-from" 1908 parameter of the "Delegate's" "ATTENDEE" property. 1910 The "REPLY" method MAY also be used to respond to an unsuccessful 1911 "VTODO" calendar component "REQUEST" method. Depending on the "REQUEST- 1912 STATUS" value, no scheduling action may have been performed. 1914 The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" 1915 method from a "Calendar User" not in the original "REQUEST". For 1916 example, a "REPLY" method MAY be received from a "Delegate" of a "VTODO" 1917 calendar component. In addition, the "REPLY" method MAY be received from 1918 an unknown "Calendar User", having been forwarded the "REQUEST" by an 1919 original "Attendee" of the "VTODO" calendar component. This uninvited 1920 "Attendee" MAY be accepted, or the "Organizer" MAY cancel the "VTODO" 1921 calendar component for the uninvited "Attendee" by sending them a 1922 "CANCEL" method. 1924 This method type is an iCalendar object that conforms to the following 1925 property constraints: 1927 Component/Property Presence 1928 ------------------- --------------------------------------------- 1929 METHOD 1 MUST be "REPLY" 1930 VTODO 1+ All component MUST have the same UID 1931 ATTENDEE 1+ 1932 DTSTAMP 1 1933 ORGANIZER 1 1934 REQUEST-STATUS 1+ 1935 UID 1 MUST must be the address of the replying 1936 attendee 1938 ATTACH 0+ 1939 CATEGORIES 0 or 1 This property may contain a list of values 1940 CLASS 0 or 1 1941 COMMENT 0 or 1 1942 CONTACT 0+ 1943 CREATED 0 or 1 1944 DESCRIPTION 0 or 1 1945 DTSTART 0 or 1 1946 DUE 0 or 1 If present DURATION MUST NOT be present 1947 DURATION 0 or 1 If present DUE MUST NOT be present 1948 EXDATE 0+ 1949 EXRULE 0+ 1950 GEO 0 or 1 1951 LAST-MODIFIED 0 or 1 1952 LOCATION 0 or 1 1953 PERCENT-COMPLETE 0 or 1 1954 PRIORITY 0 or 1 1955 RDATE 0+ 1956 RELATED-TO 0+ 1957 RESOURCES 0 or 1 This property may contain a list of values 1958 RRULE 0+ 1959 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a 1960 Recurring calendar component. Otherwise it 1961 MUST NOT be present 1962 SEQUENCE 0 or 1 MUST be the sequence number of 1963 the original REQUEST if greater than 0. 1964 MAY be present if 0. 1965 STATUS 0 or 1 1966 SUMMARY 0 or 1 Can be null 1967 URL 0 or 1 1968 X-PROPERTY 0+ 1970 VTIMEZONE 0 or 1 MUST be present if any date/time refers to 1971 a timezone 1972 X-COMPONENT 0+ 1974 VALARM 0 1975 VEVENT 0 1976 VFREEBUSY 0 1978 3.4.4 ADD 1980 The "ADD" method in a "VTODO" calendar component is used to add one or 1981 more instances to an existing to-do. 1983 If the "UID" property value in the "ADD" is not found on the recipient's 1984 calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" 1985 in order to be updated with the latest version of the "VTODO". If an 1986 "Attendee" implementation does not support the "ADD" method it should 1987 respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH". 1989 The "SEQUENCE" property value is incremented as the sequence of to-dos 1990 has changed. 1992 This method type is an iCalendar object that conforms to the following 1993 property constraints: 1995 Component/Property Presence 1996 ------------------- ---------------------------------------------- 1997 METHOD 1 MUST be "ADD" 1998 VTODO 1 1999 DTSTAMP 1 2000 ORGANIZER 1 2001 PRIORITY 1 2002 SEQUENCE 1 MUST be greater than 0 2003 SUMMARY 1 Can be null. 2004 UID 1 MUST match that of the original to-do 2006 ATTACH 0+ 2007 ATTENDEE 0+ 2008 CATEGORIES 0 or 1 This property may contain a list of 2009 values 2010 CLASS 0 or 1 2011 COMMENT 0 or 1 2012 CONTACT 0+ 2013 CREATED 0 or 1 2014 DESCRIPTION 0 or 1 Can be null 2015 DTSTART 0 or 1 2016 DUE 0 or 1 If present DURATION MUST NOT be present 2017 DURATION 0 or 1 If present DUE MUST NOT be present 2018 EXDATE 0+ 2019 EXRULE 0+ 2020 GEO 0 or 1 2021 LAST-MODIFIED 0 or 1 2022 LOCATION 0 or 1 2023 PERCENT-COMPLETE 0 or 1 2024 RDATE 0+ 2025 RELATED-TO 0+ 2026 RESOURCES 0 or 1 This property may contain a list of 2027 values 2028 RRULE 0+ 2029 STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- 2030 PROCESS 2031 URL 0 or 1 2032 X-PROPERTY 0+ 2034 RECURRENCE-ID 0 2035 REQUEST-STATUS 0 2037 VALARM 0+ 2038 VTIMEZONE 0+ MUST be present if any date/time refers 2039 to a timezone 2040 X-COMPONENT 0+ 2042 VEVENT 0 2043 VJOURNAL 0 2044 VFREEBUSY 0 2046 3.4.5 CANCEL 2048 The "CANCEL" method in a "VTODO" calendar component is used to send a 2049 cancellation notice of an existing "VTODO" calendar request to the 2050 "Attendees". The message is sent by the "Organizer" of a "VTODO" 2051 calendar component to the "Attendees" of the "VTODO" calendar component. 2052 For a recurring "VTODO" calendar component, either the whole "VTODO" 2053 calendar component or instances of a "VTODO" calendar component may be 2054 cancelled. To cancel the complete range of a recurring "VTODO" calendar 2055 component, the "UID" property value for the "VTODO" calendar component 2056 MUST be specified and a "RECURRENCE-ID" MUST NOT be specified in the 2057 "CANCEL" method. In order to cancel an individual instance of a 2058 recurring "VTODO" calendar component, the "RECURRENCE-ID" property value 2059 for the "VTODO" calendar component MUST be specified in the "CANCEL" 2060 method. 2062 There are two options for canceling a sequence of instances of a 2063 recurring "VTODO" calendar component: 2065 (a) the "RECURRENCE-ID" property for an instance in the sequence MUST be 2066 specified with the "RANGE" property parameter value of THISANDPRIOR 2067 (or THISANDFUTURE) to indicate cancellation of the specified "VTODO" 2068 calendar component and all instances before (or after); or 2070 (b) individual recurrence instances may be cancelled by specifying 2071 multiple "RECURRENCE-ID" properties corresponding to the instances to 2072 be cancelled. 2074 When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be 2075 incremented. 2077 This method type is an iCalendar object that conforms to the following 2078 property constraints: 2080 Component/Property Presence 2081 ------------------- --------------------------------------------- 2082 METHOD 1 MUST be "CANCEL" 2083 VTODO 1 2084 ATTENDEE 0+ include all "Attendees" being removed from 2085 the todo. MUST include all "Attendees" if 2086 the entire todo is cancelled. 2087 UID 1 MUST must echo original UID 2088 DTSTAMP 1 2089 ORGANIZER 1 2090 SEQUENCE 1 2092 ATTACH 0+ 2093 CATEGORIES 0 or 1 This property MAY contain a list of values 2094 CLASS 0 or 1 2095 COMMENT 0 or 1 2096 CONTACT 0+ 2097 CREATED 0 or 1 2098 DESCRIPTION 0 or 1 2099 DTSTART 0 or 1 2100 DUE 0 or 1 If present DURATION MUST NOT be present 2101 DURATION 0 or 1 If present DUE MUST NOT be present 2102 EXDATE 0+ 2103 EXRULE 0+ 2104 GEO 0 or 1 2105 LAST-MODIFIED 0 or 1 2106 LOCATION 0 or 1 2107 PERCENT-COMPLETE 0 or 1 2108 RDATE 0+ 2109 RECURRENCE-ID 0 or 1 MUST only if referring to one or more 2110 instances of a recurring calendar 2111 component. Otherwise it MUST NOT be 2112 present. 2113 RELATED-TO 0+ 2114 RESOURCES 0 or 1 This property MAY contain a list of values 2115 RRULE 0+ 2116 PRIORITY 0 or 1 2117 STATUS 0 or 1 If present it MUST be set to "CANCELLED". 2118 MUST NOT be used if purpose is to remove 2119 "ATTENDEES" rather than cancel the entire 2120 VTODO. 2121 URL 0 or 1 2122 X-PROPERTY 0+ 2124 REQUEST-STATUS 0 2126 VTIMEZONE 0 or 1 MUST be present if any date/time refers to 2127 a timezone 2128 X-COMPONENT 0+ 2130 VALARM 0 2131 VEVENT 0 2132 VFREEBUSY 0 2134 3.4.6 REFRESH 2136 The "REFRESH" method in a "VTODO" calendar component is used by 2137 "Attendees" of an existing "VTODO" calendar component to request an 2138 updated description from the "Organizer" of the "VTODO" calendar 2139 component. The "Organizer" of the "VTODO" calendar component MAY use 2140 this method to request an updated status from the "Attendees". The 2141 "REFRESH" method MUST specify the "UID" property corresponding to the 2142 "VTODO" calendar component needing update. 2144 A refresh of a recurrence instance of a "VTODO" calendar component may 2145 be requested by specifying the "RECURRENCE-ID" property corresponding to 2146 the associated "VTODO" calendar component. The "Organizer" responds with 2147 the latest description and rendition of the "VTODO" calendar component. 2148 In most cases this will be a REQUEST unless the "VTODO" has been 2149 cancelled, in which case the ORGANIZER MUST send a "CANCEL". This method 2150 is intended to facilitate machine processing of requests for updates to 2151 a "VTODO" calendar component. 2153 This method type is an iCalendar object that conforms to the following 2154 property constraints: 2156 Component/Property Presence 2157 ------------------- --------------------------------------------- 2158 METHOD 1 MUST be "REFRESH" 2159 VTODO 1 2160 ATTENDEE 1 2161 DTSTAMP 1 2162 UID 1 MUST echo original UID 2164 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a 2165 Recurring calendar component. Otherwise it 2166 MUST NOT be present 2167 X-PROPERTY 0+ 2169 ATTACH 0 2170 CATEGORIES 0 2171 CLASS 0 2172 COMMENT 0 2173 CONTACT 0 2174 CREATED 0 2175 DESCRIPTION 0 2176 DTSTART 0 2177 DUE 0 2178 DURATION 0 2179 EXDATE 0 2180 EXRULE 0 2181 GEO 0 2182 LAST-MODIFIED 0 2183 LOCATION 0 2184 ORGANIZER 0 2185 PERCENT-COMPLETE 0 2186 PRIORITY 0 2187 RDATE 0 2188 RELATED-TO 0 2189 REQUEST-STATUS 0 2190 RESOURCES 0 2191 RRULE 0 2192 SEQUENCE 0 2193 STATUS 0 2194 URL 0 2196 X-COMPONENT 0+ 2198 VALARM 0 2199 VEVENT 0 2200 VFREEBUSY 0 2201 VTIMEZONE 0 2202 3.4.7 COUNTER 2204 The "COUNTER" method in a "VTODO" calendar component is used by an 2205 "Attendee" of an existing "VTODO" calendar component to submit to the 2206 "Organizer" a counter proposal for the "VTODO" calendar component. The 2207 "Attendee" sends the message to the "Organizer" of the "VTODO" calendar 2208 component. 2210 The counter proposal is an iCalendar object consisting of a "VTODO" 2211 calendar component describing the complete description of the alternate 2212 "VTODO" calendar component. 2214 The "Organizer" rejects the counter proposal by sending the "Attendee" a 2215 "DECLINECOUNTER" method. The "Organizer" accepts the counter proposal by 2216 sending all of the "Attendees" of the "VTODO" calendar component a 2217 "REQUEST" method rescheduling the "VTODO" calendar component. In the 2218 latter case, the "Organizer" SHOULD reset the individual "RSVP" property 2219 parameter values to TRUE on each "ATTENDEE" property; in order to force 2220 a response by the "Attendees". 2222 This method type is an iCalendar object that conforms to the following 2223 property constraints: 2225 Component/Property Presence 2226 ------------------- ---------------------------------------------- 2227 METHOD 1 MUST be "COUNTER" 2228 VTODO 1 2229 ATTENDEE 1+ 2230 DTSTAMP 1 2231 ORGANIZER 1 2232 PRIORITY 1 2233 SUMMARY 1 Can be null 2234 UID 1 2236 ATTACH 0+ 2237 CATEGORIES 0 or 1 This property MAY contain a list of values 2238 CLASS 0 or 1 2239 COMMENT 0 or 1 2240 CONTACT 0+ 2241 CREATED 0 or 1 2242 DESCRIPTION 0 or 1 Can be null 2243 DTSTART 0 or 1 2244 DUE 0 or 1 If present DURATION MUST NOT be present 2245 DURATION 0 or 1 If present DUE MUST NOT be present 2246 EXDATE 0+ 2247 EXRULE 0+ 2248 GEO 0 or 1 2249 LAST-MODIFIED 0 or 1 2250 LOCATION 0 or 1 2251 PERCENT-COMPLETE 0 or 1 2252 RDATE 0+ 2253 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a 2254 recurring calendar component. Otherwise it 2255 MUST NOT be present. 2256 RELATED-TO 0+ 2257 REQUEST-STATUS 0+ 2258 RESOURCES 0 or 1 This property MAY contain a list of values 2259 RRULE 0 or 1 2260 SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. 2261 MUST be present if non-zero. MAY be present 2262 if zero. 2263 STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- 2264 PROCESS/CANCELLED 2265 URL 0 or 1 2266 X-PROPERTY 0+ 2268 VALARM 0+ 2269 VTIMEZONE 0 or 1 MUST be present if any date/time refers to 2270 a timezone 2271 X-COMPONENT 0+ 2273 VEVENT 0 2274 VFREEBUSY 0 2276 3.4.8 DECLINECOUNTER 2278 The "DECLINECOUNTER" method in a "VTODO" calendar component is used by 2279 an "Organizer" of "VTODO" calendar component to reject a counter 2280 proposal offered by one of the "Attendees". The "Organizer" sends the 2281 message to the "Attendee" that sent the "COUNTER" method to the 2282 "Organizer". 2284 This method type is an iCalendar object that conforms to the following 2285 property constraints: 2287 Component/Property Presence 2288 ------------------- --------------------------------------------- 2289 METHOD 1 MUST be "DECLINECOUNTER" 2291 VTODO 1 2292 ATTENDEE 1+ MUST for all attendees 2293 DTSTAMP 1 2294 ORGANIZER 1 2295 SEQUENCE 1 MUST echo the original SEQUENCE number 2296 UID 1 MUST echo original UID 2298 ATTACH 0+ 2299 CATEGORIES 0 or 1 This property may contain a list of values 2300 CLASS 0 or 1 2301 COMMENT 0 or 1 2302 CONTACT 0+ 2303 CREATED 0 or 1 2304 DESCRIPTION 0 or 1 2305 DTSTART 0 or 1 2306 DUE 0 or 1 If present DURATION MUST NOT be present 2307 DURATION 0 or 1 If present DUE MUST NOT be present 2308 EXDATE 0+ 2309 EXRULE 0+ 2310 GEO 0 or 1 2311 LAST-MODIFIED 0 or 1 2312 LOCATION 0 or 1 2313 PERCENT-COMPLETE 0 or 1 2314 PRIORITY 0 or 1 2315 RDATE 0+ 2316 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a 2317 recurring calendar component. Otherwise 2318 it MUST NOT be present. 2319 RELATED-TO 0+ 2320 REQUEST-STATUS 0+ 2321 RESOURCES 0 or 1 This property MAY contain a list of values 2322 RRULE 0+ 2323 STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- 2324 PROCESS 2325 URL 0 or 1 2326 X-PROPERTY 0+ 2328 VTIMEZONE 0+ MUST be present if any date/time refers to 2329 a timezone 2330 X-COMPONENT 0+ 2332 VALARM 0 2333 VEVENT 0 2334 VFREEBUSY 0 2336 3.5 Methods For VJOURNAL Components 2338 This section defines the property set for the methods that are 2339 applicable to the "VJOURNAL" calendar component. 2341 The following summarizes the methods that are defined for the "VJOURNAL" 2342 calendar component. 2344 +================+==================================================+ 2345 | Method | Description | 2346 |================+==================================================| 2347 | PUBLISH | Post a journal entry. Used primarily as a method | 2348 | | of advertising the existence of a journal entry. | 2349 | | | 2350 | ADD | Add one or more instances to an existing journal | 2351 | | entry. | 2352 | | | 2353 | CANCEL | Cancel one or more instances of an existing | 2354 | | journal entry. | 2355 +================+==================================================+ 2356 3.5.1 PUBLISH 2358 The "PUBLISH" method in a "VJOURNAL" calendar component has no 2359 associated response. It is simply a posting of an iCalendar object that 2360 may be added to a calendar. It MUST have an "Organizer". It MUST NOT 2361 have "Attendees". The expected usage is for encapsulating an arbitrary 2362 journal entry as an iCalendar object. The "Organizer" MAY subsequently 2363 update (with another "PUBLISH" method) or cancel (with a "CANCEL" 2364 method) a previously published journal entry. 2366 This method type is an iCalendar object that conforms to the following 2367 property constraints: 2369 Component/Property Presence 2370 ------------------- ---------------------------------------------- 2371 METHOD 1 MUST be "PUBLISH" 2372 VJOURNAL 1+ 2373 DESCRIPTION 1 Can be null. 2374 DTSTAMP 1 2375 DTSTART 1 2376 ORGANIZER 1 2377 UID 1 2379 ATTACH 0+ 2380 CATEGORIES 0 or 1 This property MAY contain a list of values 2381 CLASS 0 or 1 2382 COMMENT 0 or 1 2383 CONTACT 0+ 2384 CREATED 0 or 1 2385 EXDATE 0+ 2386 EXRULE 0+ 2387 LAST-MODIFIED 0 or 1 2388 RDATE 0+ 2389 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a 2390 recurring calendar component. Otherwise 2391 it MUST NOT be present. 2392 RELATED-TO 0+ 2393 RRULE 0+ 2394 SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. 2395 MUST be present if non-zero. MAY be 2396 present if zero. 2397 STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED 2398 SUMMARY 0 or 1 Can be null 2399 URL 0 or 1 2400 X-PROPERTY 0+ 2402 ATTENDEE 0 2404 VALARM 0+ 2405 VTIMEZONE 0+ MUST be present if any date/time refers to 2406 a timezone 2407 X-COMPONENT 0+ 2409 VEVENT 0 2410 VFREEBUSY 0 2411 VTODO 0 2413 3.5.2 ADD 2415 The "ADD" method in a "VJOURNAL" calendar component is used to add one 2416 or more instances to an existing "VJOURNAL" entry. There is no response 2417 to the "Organizer". 2419 If the "UID" property value in the "ADD" is not found on the recipient's 2420 calendar, then the recipient MAY treat the "ADD" as a "PUBLISH". 2422 This method type is an iCalendar object that conforms to the following 2423 property constraints: 2425 Component/Property Presence 2426 ------------------- ---------------------------------------------- 2427 METHOD 1 MUST be "ADD" 2428 VJOURNAL 1 2429 DESCRIPTION 1 Can be null. 2430 DTSTAMP 1 2431 DTSTART 1 2432 ORGANIZER 1 2433 SEQUENCE 1 MUST be greater than 0 2434 UID 1 MUST match that of the original journal 2436 ATTACH 0+ 2437 CATEGORIES 0 or 1 This property MAY contain a list of values 2438 CLASS 0 or 1 2439 COMMENT 0 or 1 2440 CONTACT 0+ 2441 CREATED 0 or 1 2442 EXDATE 0+ 2443 EXRULE 0+ 2444 LAST-MODIFIED 0 or 1 2445 RDATE 0+ 2446 RELATED-TO 0+ 2447 RRULE 0+ 2448 STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED 2449 SUMMARY 0 or 1 Can be null 2450 URL 0 or 1 2451 X-PROPERTY 0+ 2453 ATTENDEE 0 2454 RECURRENCE-ID 0 2456 VALARM 0+ 2457 VTIMEZONE 0 or 1 MUST be present if any date/time refers to 2458 a timezone 2459 X-COMPONENT 0+ 2461 VEVENT 0 2462 VFREEBUSY 0 2463 VTODO 0 2465 3.5.3 CANCEL 2467 The "CANCEL" method in a "VJOURNAL" calendar component is used to send a 2468 cancellation notice of an existing journal entry. The message is sent by 2469 the "Organizer" of a journal entry. For a recurring journal entry, 2470 either the whole journal entry or instances of a journal entry may be 2471 cancelled. To cancel the complete range of a recurring journal entry, 2472 the "UID" property value for the journal entry MUST be specified and a 2473 "RECURRENCE-ID" property MUST NOT be specified in the "CANCEL" method. 2474 In order to cancel an individual instance of the journal entry, the 2475 "RECURRENCE-ID" property value for the journal entry MUST be specified 2476 in the "CANCEL" method. 2478 There are two options for canceling a sequence of instances of a 2479 recurring "VJOURNAL" calendar component: 2481 (a) the "RECURRENCE-ID" property for an instance in the sequence MUST be 2482 specified with the "RANGE" property parameter value of THISANDPRIOR 2483 (or THISANDFUTURE) to indicate cancellation of the specified "VTODO" 2484 calendar component and all instances before (or after); or 2486 (b) individual recurrence instances may be cancelled by specifying 2487 multiple "RECURRENCE-ID" properties corresponding to the instances to 2488 be cancelled. 2490 When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be 2491 incremented. 2493 This method type is an iCalendar object that conforms to the following 2494 property constraints: 2496 Component/Property Presence 2497 ------------------- --------------------------------------------- 2498 METHOD 1 MUST be "CANCEL" 2499 VJOURNAL 1+ All MUST have the same UID 2500 DTSTAMP 1 2501 ORGANIZER 1 2502 SEQUENCE 1 2503 UID 1 MUST be the UID of the original REQUEST 2505 ATTACH 0+ 2506 ATTENDEE 0+ 2507 CATEGORIES 0 or 1 This property MAY contain a list of values 2508 CLASS 0 or 1 2509 COMMENT 0 or 1 2510 CONTACT 0+ 2511 CREATED 0 or 1 2512 DESCRIPTION 0 or 1 2513 DTSTART 0 or 1 2514 EXDATE 0+ 2515 EXRULE 0+ 2516 LAST-MODIFIED 0 or 1 2517 RDATE 0+ 2518 RECURRENCE-ID 0 or 1 only if referring to an instance of a 2519 recurring calendar component. Otherwise 2520 it MUST NOT be present. 2521 RELATED-TO 0+ 2522 RRULE 0+ 2523 STATUS 0 or 1 MAY be present, must be "CANCELLED" if 2524 present 2525 SUMMARY 0 or 1 2526 URL 0 or 1 2527 X-PROPERTY 0+ 2529 REQUEST-STATUS 0 2531 VTIMEZONE 0+ MUST be present if any date/time refers to 2532 a timezone 2533 X-COMPONENT 0+ 2534 VALARM 0 2535 VEVENT 0 2536 VFREEBUSY 0 2537 VTODO 0 2539 3.6 Status Replies 2541 The "REQUEST-STATUS" property may include the following values: 2543 |==============+============================+=========================| 2544 | Short Return | Longer Return Status | Offending Data | 2545 | Status Code | Description | | 2546 |==============+============================+=========================| 2547 | 2.0 | Success. | None. | 2548 |==============+============================+=========================| 2549 | 2.1 | Success but fallback taken | Property name and value | 2550 | | on one or more property | MAY be specified. | 2551 | | values. | | 2552 |==============+============================+=========================| 2553 | 2.2 | Success, invalid property | Property name MAY be | 2554 | | ignored. | specified. | 2555 |==============+============================+=========================| 2556 | 2.3 | Success, invalid property | Property parameter name | 2557 | | parameter ignored. | and value MAY be | 2558 | | | specified. | 2559 |==============+============================+=========================| 2560 | 2.4 | Success, unknown non- | Non-standard property | 2561 | | standard property ignored. | name MAY be specified. | 2562 |==============+============================+=========================| 2563 | 2.5 | Success, unknown non | Property and non- | 2564 | | standard property value | standard value MAY be | 2565 | | ignored. | specified. | 2566 |==============+============================+=========================| 2567 | 2.6 | Success, invalid calendar | Calendar component | 2568 | | component ignored. | sentinel (e.g., BEGIN: | 2569 | | | ALARM) MAY be | 2570 | | | specified. | 2571 |==============+============================+=========================| 2572 | 2.7 | Success, request forwarded | Original and forwarded | 2573 | | to Calendar User. | caluser addresses MAY | 2574 | | | be specified. | 2575 |==============+============================+=========================| 2576 | 2.8 | Success, repeating event | RRULE or RDATE property | 2577 | | ignored. Scheduled as a | name and value MAY be | 2578 | | single component. | specified. | 2579 |==============+============================+=========================| 2580 | 2.9 | Success, truncated end date| DTEND property value | 2581 | | time to date boundary. | MAY be specified. | 2582 |==============+============================+=========================| 2583 | 2.10 | Success, repeating VTODO | RRULE or RDATE property | 2584 | | ignored. Scheduled as a | name and value MAY be | 2585 | | single VTODO. | specified. | 2586 |==============+============================+=========================| 2587 | 2.11 | Success, unbounded RRULE | RRULE property name and | 2588 | | clipped at some finite | value MAY be specified. | 2589 | | number of instances | Number of instances MAY | 2590 | | | also be specified. | 2591 |==============+============================+=========================| 2592 | 3.0 | Invalid property name. | Property name MAY be | 2593 | | | specified. | 2594 |==============+============================+=========================| 2595 | 3.1 | Invalid property value. | Property name and value | 2596 | | | MAY be specified. | 2597 |==============+============================+=========================| 2598 | 3.2 | Invalid property parameter.| Property parameter name | 2599 | | | and value MAY be | 2600 | | | specified. | 2601 |==============+============================+=========================| 2602 | 3.3 | Invalid property parameter | Property parameter name | 2603 | | value. | and value MAY be | 2604 | | | specified. | 2605 |==============+============================+=========================| 2606 | 3.4 | Invalid calendar component | Calendar component | 2607 | | sequence. | sentinel MAY be | 2608 | | | specified (e.g., BEGIN: | 2609 | | | VTIMEZONE). | 2610 |==============+============================+=========================| 2611 | 3.5 | Invalid date or time. | Date/time value(s) MAY | 2612 | | | be specified. | 2613 |==============+============================+=========================| 2614 | 3.6 | Invalid rule. | Rule value MAY be | 2615 | | | specified. | 2616 |==============+============================+=========================| 2617 | 3.7 | Invalid Calendar User. | Attendee property value | 2618 | | |MAY be specified. | 2619 |==============+============================+=========================| 2620 | 3.8 | No authority. | METHOD and Attendee | 2621 | | | property values MAY be | 2622 | | | specified. | 2623 |==============+============================+=========================| 2624 | 3.9 | Unsupported version. | VERSION property name | 2625 | | | and value MAY be | 2626 | | | specified. | 2627 |==============+============================+=========================| 2628 | 3.10 | Request entity too large. | None. | 2629 |==============+============================+=========================| 2630 | 3.11 | Required component or | Component or property | 2631 | | property missing. | name MAY be specified. | 2632 |==============+============================+=========================| 2633 | 3.12 | Unknown component or | Component or property | 2634 | | property found | name MAY be specified | 2635 |==============+============================+=========================| 2636 | 3.13 | Unsupported component or | Component or property | 2637 | | property found | name MAY be specified | 2638 |==============+============================+=========================| 2639 | 3.14 | Unsupported capability | Method or action MAY | 2640 | | | be specified | 2641 |==============+============================+=========================| 2642 | 4.0 | Event conflict. Date/time | DTSTART and DTEND | 2643 | | is busy. | property name and values| 2644 | | | MAY be specified. | 2645 |==============+============================+=========================| 2646 | 5.0 | Request MAY supported. | Method property value | 2647 | | | MAY be specified. | 2648 |==============+============================+=========================| 2649 | 5.1 | Service unavailable. | ATTENDEE property value | 2650 | | | MAY be specified. | 2651 |==============+============================+=========================| 2652 | 5.2 | Invalid calendar service. | ATTENDEE property value | 2653 | | | MAY be specified. | 2654 |==============+============================+=========================| 2655 | 5.3 | No scheduling support for | ATTENDEE property value | 2656 | | user. | MAY be specified. | 2657 |==============+============================+=========================| 2659 3.7 Implementation Considerations 2661 3.7.1 Working With Recurrence Instances 2663 iCalendar includes a recurrence grammar to represent recurring events. 2664 The benefit of such a grammar is the ability to represent a number of 2665 events in a single object. However, while this simplifies creation of a 2666 recurring event, meeting instances still need to be referenced. For 2667 instance, an "Attendee" may decline the third instance of a recurring 2668 Friday event. Similarly, the "Organizer" may change the time or location 2669 to a single instance of the recurring event. 2671 Since implementations may elect to store recurring events as either a 2672 single event object or a collection of discreet, related event objects, 2673 the protocol is designed so that each recurring instance may be both 2674 referenced and versioned. Hence, implementations that choose to maintain 2675 per-instance properties (such as "ATTENDEE" property "partstat" 2676 parameter) may do so. However, the protocol does not require per- 2677 instance recognition unless the instance itself must be renegotiated. 2679 The scenarios for recurrence instance referencing are listed below. For 2680 purposes of simplification a change to an event refers to a "trigger 2681 property." That is, a property that has a substantive effect on the 2682 meeting itself such as start time, location, due date (for "VTODO" 2683 calendar component components) and possibly description. 2685 "Organizer" initiated actions: 2687 . "Organizer" deletes or changes a single instance of a recurring 2688 event 2689 . "Organizer" makes changes that affect all future instances 2690 . "Organizer" makes changes that affect all previous instances 2691 . "Organizer" deletes or modifies a previously changed instance 2693 "Attendee" initiated actions: 2695 . "Attendee" changes status for a particular recurrence instance 2696 . "Attendee" sends Event-Counter for a particular recurrence instance 2698 An instance of a recurring event is assigned a unique identification, 2699 "RECURRENCE-ID" property, when that instance is renegotiated. 2700 Negotiation may be necessary when a substantive change to the event or 2701 to-do has be made (such as changing the start time, end time, due date 2702 or location). The "Organizer" can identify a specific recurrence 2703 instance using the "RECURRENCE-ID" property. The property value is equal 2704 to the date/time of the instance. If the "Organizer" wishes to change 2705 the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID" 2706 property and the new "DTSTART" and "DTEND" values reflect the change. 2707 Note that after the change has occurred, the "RECURRENCE-ID" has changed 2708 to the new "DTSTART" value. 2710 3.7.2 Attendee Property Considerations 2712 The "ORGANIZER" property is required on published events, to-dos, and 2713 journal entries for two reasons. First, only the "Organizer" is allowed 2714 to update and redistribute an event or to-do component. It follows that 2715 the "ORGANIZER" property MUST be present in the event, to-do, or journal 2716 entry component so that the CUA has a basis for authorizing an update. 2717 Second, it is prudent to provide a point of contact for anyone who 2718 receives a published component in case of problems. 2720 There are valid [RFC-822] addresses that represent groups. Sending email 2721 to such an address results in mail being sent to multiple recipients. 2722 Such an address may be used as the value of an "ATTENDEE" property. 2724 Thus, it is possible that the recipient of a "REQUEST" does not appear 2725 explicitly in the list. 2727 It is recommended that the general approach to finding a "Calendar User" 2728 in an attendee list be as follows: 2730 1. Search for the "Calendar User" in the attendee list where 2731 "TYPE=INDIVIDUAL" 2733 2. Failing (1) look for attendees where "TYPE=GROUP" or 'TYPE=UNKNOWN". 2734 The CUA then determines if the "Calendar User" is a member of one of 2735 these groups. If so, the "REPLY" method sent to the "Organizer" MUST 2736 contain a new "ATTENDEE" property in which: 2737 . the "type" property parameter is set to INDIVIDUAL 2738 . the "member" property parameter is set to the name of the group 2740 3. Failing (2) the CUA MAY ignore or accept the request as the "Calendar 2741 User" wishes. 2743 3.7.3 X-Tokens 2745 To make iCalendar objects extensible, new property types MAY be inserted 2746 into components. These properties are called X-Tokens as they are 2747 prefixed with "X-". A client is not required to make sense of X-Tokens. 2748 Clients are not required to save X-Tokens or use them in replies. 2750 4 Examples 2752 4.1 Published Event Examples 2754 In the calendaring and scheduling context, publication refers to the one 2755 way transfer of event information. Consumers of published events simply 2756 incorporate the event into a calendar. No reply is expected. Individual 2757 "A" publishes an event. Individual "B" reads the event and incorporates 2758 it into their calendar. Events are published in several ways including: 2759 embedding the event as an object in a web page, e-mailing the event to a 2760 distribution list, and posting the event to a newsgroup. 2762 The table below illustrates the sequence of events between the publisher 2763 and the consumers of a published event. 2765 +-------------------------------------------------------------------+ 2766 | Action | "Organizer" | 2767 +---------------------------------+---------------------------------+ 2768 | Publish an event | "A" sends or posts a PUBLISH | 2769 | | message | 2770 +---------------------------------+---------------------------------+ 2771 | "B" reads a published event | | 2772 +---------------------------------+---------------------------------+ 2773 | Publish an updated event | "A" sends or posts a PUBLISH | 2774 | | message | 2775 +---------------------------------+---------------------------------+ 2776 | "B" reads the updated event | | 2777 +---------------------------------+---------------------------------+ 2778 | Cancel a published event | "A" sends or posts a CANCEL | 2779 | | message | 2780 +---------------------------------+---------------------------------+ 2781 | "B" reads the canceled event | | 2782 | publication | | 2783 +---------------------------------+---------------------------------+ 2785 4.1.1 A Minimal Published Event 2787 The iCalendar object below describes a single event that begins on July 2788 1, 1997 at 20:00 UTC. This event contains the minimum set of properties 2789 for a "PUBLISH" for a "VEVENT" calendar component. 2791 BEGIN:VCALENDAR 2792 METHOD:PUBLISH 2793 PRODID:-//ACME/DesktopCalendar//EN 2794 VERSION:2.0 2795 BEGIN:VEVENT 2796 ORGANIZER:mailto:a@example.com 2797 DTSTART:19970701T200000Z 2798 DTSTAMP:19970611T190000Z 2799 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 2800 UID:0981234-1234234-23@example.com 2801 END:VEVENT 2802 END:VCALENDAR 2804 4.1.2 Changing A Published Event 2806 The iCalendar object below describes an update to the event described in 2807 4.1.1, the time has been changed, an end time has been added, and the 2808 sequence number has been adjusted. 2810 BEGIN:VCALENDAR 2811 METHOD:PUBLISH 2812 VERSION:2.0 2813 PRODID:-//ACME/DesktopCalendar//EN 2814 BEGIN:VEVENT 2815 ORGANIZER:mailto:a@example.com 2816 DTSTAMP:19970612T190000Z 2817 DTSTART:19970701T210000Z 2818 DTEND:19970701T230000Z 2819 SEQUENCE:1 2820 UID:0981234-1234234-23@example.com 2821 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 2822 END:VEVENT 2823 END:VCALENDAR 2824 The "UID" property is used by the client to identify the event. The 2825 "SEQUENCE" property indicates that this is a change to the event. The 2826 event with a matching UID and sequence number 0 is superseded by this 2827 event. 2829 The "SEQUENCE" property provides a reliable way to distinguish different 2830 versions of the same event. Each time an event is published, its 2831 sequence number is incremented. If a client receives an event with a 2832 sequence number 5 and finds it has the same event with sequence number 2833 2, the event SHOULD be updated. However, if the client received an event 2834 with sequence number 2 and finds it already has sequence number 5 of the 2835 same event, the event MUST NOT be updated. 2837 4.1.3 Canceling A Published Event 2839 The iCalendar object below cancels the event described in 4.1.1. This 2840 cancels the event with "SEQUENCE" property of 0, 1, and 2. 2842 BEGIN:VCALENDAR 2843 METHOD:CANCEL 2844 VERSION:2.0 2845 PRODID:-//ACME/DesktopCalendar//EN 2846 BEGIN:VEVENT 2847 ORGANIZER:mailto:a@example.com 2848 COMMENT:DUKES forfeit the game 2849 SEQUENCE:2 2850 UID:0981234-1234234-23@example.com 2851 DTSTAMP:19970613T190000Z 2852 END:VEVENT 2853 END:VCALENDAR 2855 4.1.4 A Rich Published Event 2857 This example describes the same event as in 4.1.1, but in much greater 2858 detail. 2860 BEGIN:VCALENDAR 2861 PRODID:-//ACME/DesktopCalendar//EN 2862 METHOD:PUBLISH 2863 SCALE:GREGORIAN 2864 VERSION:2.0 2865 BEGIN:VTIMEZONE 2866 TZID:America-Chicago 2867 TZURL:http://zones.stds_r_us.net/tz/America-Chicago 2868 BEGIN:STANDARD 2869 DTSTART:19671029T020000 2870 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 2871 TZOFFSETFROM:-0500 2872 TZOFFSETTO:-0600 2873 TZNAME:CST 2874 END:STANDARD 2875 BEGIN:DAYLIGHT 2876 DTSTART:19870405T020000 2877 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 2878 TZOFFSETFROM:-0600 2879 TZOFFSETTO:-0500 2880 TZNAME:CDT 2881 END:DAYLIGHT 2882 END:VTIMEZONE 2883 BEGIN:VEVENT 2884 ORGANIZER:mailto:a@example.com 2885 ATTACH:http://www.dukes.com/ 2886 CATEGORIES:SPORTS EVENT,ENTERTAINMENT 2887 CLASS:PRIVATE 2888 DESCRIPTION:MIDWAY STADIUM\n 2889 Big time game. MUST see.\n 2890 Expected duration:2 hours\n 2891 DTEND;TZID=America-Chicago:19970701T180000 2892 DTSTART;TZID=America-Chicago:19970702T160000 2893 DTSTAMP:19970614T190000Z 2894 STATUS:CONFIRMED 2895 LOCATION;VALUE=URL:http://www.midwaystadium.com/ 2896 PRIORITY:2 2897 RESOURCES:SCOREBOARD 2898 SEQUENCE:3 2899 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 2900 UID:0981234-1234234-23@example.com 2901 RELATED-TO:0981234-1234234-14@example.com 2902 BEGIN:VALARM 2903 TRIGGER:-PT2H 2904 ACTION:DISPLAY 2905 DESCRIPTION:You should be leaving for the game now. 2906 END:VALARM 2907 BEGIN:VALARM 2908 TRIGGER:-PT30M 2909 ACTION:AUDIO 2910 END:VALARM 2911 END:VEVENT 2912 END:VCALENDAR 2914 The "RELATED-TO" field contains the "UID" property of a related calendar 2915 event. The "SEQUENCE" property 3 indicates that this event supersedes 2916 versions 0, 1, and 2. 2918 4.1.5 Anniversaries or Events attached to entire days 2920 This example demonstrates the use of the "value" parameter to tie a 2921 "VEVENT" to day rather than a specific time. 2923 BEGIN:VCALENDAR 2924 PRODID:-//ACME/DesktopCalendar//EN 2925 METHOD:PUBLISH 2926 VERSION:2.0 2927 BEGIN:VEVENT 2928 ORGANIZER:mailto:a@example.com 2929 DTSTAMP:19970614T190000Z 2930 UID:0981234-1234234-23@example.com 2931 DTSTART;VALUE=DATE:19970714 2932 RRULE:FREQ=YEARLY;INTERVAL=1 2933 SUMMARY: Bastille Day 2934 END:VEVENT 2935 END:VCALENDAR 2937 4.2 Group Event Examples 2939 Group events are distinguished from published events in that they have 2940 "Attendees" and that there is interaction between the "Attendees" and 2941 the "Organizer" with respect to the event. Individual "A" requests a 2942 meeting between individuals "A", "B", "C" and "D". Individual "B" 2943 confirms attendance to the meeting. Individual "C" declines attendance. 2944 Individual "D" tentatively confirms attendance. The following table 2945 illustrates the the message flow between these individuals. A, the CU 2946 scheduling the meeting, is referenced as the "Organizer". 2948 +--------------------------------------------------------------------+ 2949 | Action | "Organizer" | Attendee | 2950 +--------------------------------------------------------------------+ 2951 | Initiate a meeting | "A" sends a REQUEST | | 2952 | request | message to "B", "C",| | 2953 | | and "D" | | 2954 +--------------------------------------------------------------------+ 2955 | Accept the meeting | | "B" sends a REPLY | 2956 | request | | message to "A" with its | 2957 | | | ATTENDEE "partstat" para-| 2958 | | | set to "accepted" | 2959 +--------------------------------------------------------------------+ 2960 | Decline the meeting| | "C" sends a REPLY | 2961 | request | | message to "A" with its | 2962 | | | ATTENDEE "partstat" para-| 2963 | | | set to "declined" | 2964 +--------------------------------------------------------------------+ 2965 | Tentatively accept | | "D" sends a REPLY | 2966 | the meeting request| | message to "A" with its | 2967 | | | ATTENDEE "partstat" para-| 2968 | | | set to "tentative" | 2969 +--------------------------------------------------------------------+ 2970 | Confirm meeting | "A" sends a REQUEST | | 2971 | status with | message to "B" and | | 2972 | attendees | "D" with updated | | 2973 | | information. | | 2974 +--------------------------------------------------------------------+ 2976 4.2.1 A Group Event Request 2978 A sample meeting request is sent from "A" to "B", "C", and "D". _E_ is 2979 also sent a copy of the request but is not expected to attend and need 2980 not reply. "E" illustrates how CUAs might implement an "FYI" type 2981 feature. Note the use of the "role" parameter. The default value for the 2982 "role" parameter is "req-participant" and it need not be enumerated. In 2983 this case we are using the value "non-participant" to indicate "E" is a 2984 non-attending CU. The parameter is not needed on other "Attendees" since 2985 "participant" is the default value. 2987 BEGIN:VCALENDAR 2988 PRODID:-//ACME/DesktopCalendar//EN 2989 METHOD:REQUEST 2990 VERSION:2.0 2991 BEGIN:VEVENT 2992 ORGANIZER:Mailto:A@example.com 2993 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com 2994 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com 2995 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com 2996 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com 2997 ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com 2998 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com 2999 DTSTAMP:19970611T190000Z 3000 DTSTART:19970701T200000Z 3001 DTEND:19970701T2000000Z 3002 SUMMARY:Conference 3003 UID:calsrv.example.com-873970198738777@example.com 3004 SEQUENCE:0 3005 STATUS:CONFIRMED 3006 END:VEVENT 3007 END:VCALENDAR 3009 4.2.2 Reply To A Group Event Request 3011 Attendee "B" accepts the meeting. 3013 BEGIN:VCALENDAR 3014 PRODID:-//ACME/DesktopCalendar//EN 3015 METHOD:REPLY 3016 VERSION:2.0 3017 BEGIN:VEVENT 3018 ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com 3019 ORGANIZER:MAILTO:A@example.com 3020 UID:calsrv.example.com-873970198738777@example.com 3021 SEQUENCE:0 3022 REQUEST-STATUS:2.0;Success 3023 DTSTAMP:19970612T190000Z 3024 END:VEVENT 3025 END:VCALENDAR 3027 "B" could have declined the meeting or indicated tentative acceptance by 3028 setting the "ATTENDEE" "partstat" parameter to "declined" or 3029 "tentative", respectively. Also, "REQUEST-STATUS" is not required in 3030 successful transactions. 3032 4.2.3 Update An Event 3034 The event is moved to a different time. The combination of the "UID" 3035 property (unchanged) and the "SEQUENCE" (bumped to 1) properties 3036 indicate the update. 3038 BEGIN:VCALENDAR 3039 PRODID:-//ACME/DesktopCalendar//EN 3040 METHOD:REQUEST 3041 VERSION:2.0 3042 BEGIN:VEVENT 3043 ORGANIZER:Mailto:A@example.com 3044 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3045 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 3046 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com 3047 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com 3048 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE; 3049 CUTYPE=ROOM:Mailto:Conf@example.com 3050 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com 3051 DTSTART:19970701T180000Z 3052 DTEND:19970701T190000Z 3053 SUMMARY:Phone Conference 3054 UID:calsrv.example.com-873970198738777@example.com 3055 SEQUENCE:1 3056 DTSTAMP:19970613T190000Z 3057 STATUS:CONFIRMED 3058 END:VEVENT 3059 END:VCALENDAR 3061 4.2.4 Countering an Event Proposal 3063 "A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal to 3064 "A" to change the time and location. 3066 "A" sends the following "REQUEST": 3068 BEGIN:VCALENDAR 3069 PRODID:-//ACME/DesktopCalendar//EN 3070 METHOD:REQUEST 3071 VERSION:2.0 3072 BEGIN:VEVENT 3073 ORGANIZER:Mailto:A@example.com 3074 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3075 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 3076 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com 3077 DTSTART:19970701T190000Z 3078 DTEND:19970701T200000Z 3079 SUMMARY:Discuss the Merits of the election results 3080 LOCATION:Green Conference Room 3081 UID:calsrv.example.com-873970198738777a@example.com 3082 SEQUENCE:0 3083 DTSTAMP:19970611T190000Z 3084 STATUS:CONFIRMED 3085 END:VEVENT 3086 END:VCALENDAR 3088 "B" sends "COUNTER" to "A", requesting changes to time and place. "B" 3089 uses the "COMMENT" property to communicate a rationale for the change. 3090 Note that the "SEQUENCE" property is NOT incremented on a "COUNTER". 3092 BEGIN:VCALENDAR 3093 PRODID:-//ACME/DesktopCalendar//EN 3094 METHOD:COUNTER 3095 VERSION:2.0 3096 BEGIN:VEVENT 3097 ORGANIZER:Mailto:A@example.com 3098 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3099 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 3100 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com 3101 DTSTART:19970701T160000Z 3102 DTEND:19970701T190000Z 3103 DTSTAMP:19970612T190000Z 3104 SUMMARY:Discuss the Merits of the election results 3105 LOCATION:Green Conference Room 3106 COMMENT:This time works much better and I think the big conference 3107 room is too big 3108 UID:calsrv.example.com-873970198738777a@example.com 3109 SEQUENCE:0 3110 DTSTAMP:19970611T190000Z 3111 END:VEVENT 3112 END:VCALENDAR 3114 "A" accepts the changes from "B". To accept a counter-proposal, the 3115 "Organizer" sends a new event "REQUEST" with an incremented sequence 3116 number. 3118 BEGIN:VCALENDAR 3119 PRODID:-//ACME/DesktopCalendar//EN 3120 METHOD:REQUEST 3121 VERSION:2.0 3122 BEGIN:VEVENT 3123 ORGANIZER:Mailto:A@example.com 3124 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3125 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 3126 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com 3127 DTSTAMP:19970613T190000Z 3128 DTSTART:19970701T160000Z 3129 DTEND:19970701T190000Z 3130 SUMMARY:Discuss the Merits of the election results - changed to 3131 meet B's schedule 3132 LOCATION:Green Conference Room 3133 UID:calsrv.example.com-873970198738777@example.com 3134 SEQUENCE:1 3135 STATUS:CONFIRMED 3136 END:VEVENT 3137 END:VCALENDAR 3139 Instead, "A" rejects "B's" counter proposal 3141 BEGIN:VCALENDAR 3142 PRODID:-//ACME/DesktopCalendar//EN 3143 METHOD:DECLINECOUNTER 3144 VERSION:2.0 3145 BEGIN:VEVENT 3146 ORGANIZER:Mailto:A@example.com 3147 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 3148 COMMENT:Sorry, I cannot change this meeting time 3149 UID:calsrv.example.com-873970198738777@example.com 3150 SEQUENCE:0 3151 DTSTAMP:19970614T190000Z 3152 END:VEVENT 3153 END:VCALENDAR 3155 4.2.5 Delegating an Event 3157 When delegating an event request to another "Calendar User", the 3158 "Delegator" must both update the "Organizer" with a "REPLY" and send a 3159 request to the "Delegate". There is currently no protocol limitation to 3160 delegation depth. It is possible for the original delegate to delegate 3161 the meeting to someone else, and so on. When a request is delegated from 3162 one CUA to another there are a number of responsibilities required of 3163 the "Delegator". The "Delegator" MUST: 3165 . Send a "REPLY" to the "Organizer" with the following updates: 3166 . The "Delegator's" "ATTENDEE" property "partstat" parameter set to 3167 "delegated" and the "delegated-to" parameter is set to the address 3168 of the "Delegate" 3169 . Add an additional "ATTENDEE" property for the "Delegate" with the 3170 "delegated-from" property parameter set to the "Delegator" 3171 . Indicate whether they want to continue to receive updates when the 3172 "Organizer" sends out updated versions of the event. Setting the 3173 "rsvp" property parameter to "TRUE" will cause the updates to be 3174 sent, setting it to "FALSE" causes no further updates to be sent. 3175 Note that in either case, if the "Delegate" declines the invitation 3176 the "Delegator" will be notified. 3177 . The "Delegator" MUST also send a copy of the original "REQUEST" 3178 method to the "Delegate". 3180 It is not required that the "Delegate" include the "Delegator" in their 3181 "REPLY" method. However, it is strongly advised since this will inform 3182 the "Delegator" whether the "Delegate" plans to attend the meeting. 3183 [Editors note: How so?] If the "Delegate" declines the meeting, the 3184 "Delegator" may elect to delegate the "REQUEST" to another CUA. The 3185 process is the same. 3187 +---------------------------------------------------------------------+ 3188 | Action | "Organizer" | Attendee | 3189 +---------------------------------------------------------------------+ 3190 | Initiate a meeting | "A" sends a REQUEST | | 3191 | request | message to "B" and | | 3192 | | "C" | | 3193 +---------------------------------------------------------------------+ 3194 | Delegate: | | "C" sends a REPLY to "A" | 3195 | "C" delegates to | | with the ATTENDEE. | 3196 | "E" | | "partstat" parameter set | 3197 | | | to "delegated" and with a| 3198 | | | new "ATTENDEE" property | 3199 | | | for "E". "E's" ATTENDEE | 3200 | | | "delegated-from" param | 3201 | | | is set to "C". "C's" | 3202 | | | ATTENDEE "delegated-to" | 3203 | | | param is set to "E". | 3204 | | | "C" sends REQUEST message| 3205 | | | to "E" with the original | 3206 | | | meeting request | 3207 | | | information. The | 3208 | | | "partstat" property | 3209 | | | parameter for "C" is set | 3210 | | | to "delegated" and the | 3211 | | | "delegated-to" | 3212 | | | parameter is set to | 3213 | | | the address of "E". An | 3214 | | | "ATTENDEE" property is | 3215 | | | added for "E" and the | 3216 | | | "delegated-from" | 3217 | | | parameter is set to | 3218 | | | the address of "C". | 3219 +---------------------------------------------------------------------+ 3220 | Confirm meeting | | "E" sends REPLY message | 3221 | attendance | | to "A" and optionally "C"| 3222 | | | with its "partstat" | 3223 | | | property parameter set | 3224 | | | to "ACCEPTED" | 3225 +---------------------------------------------------------------------+ 3226 | Optional: | "A" sends REQUEST | | 3227 | Redistribute | message to "B", "C" | | 3228 | meeting to | and "E". | | 3229 | attendees | | | 3230 +---------------------------------------------------------------------+ 3232 "C" responds to the "Organizer". 3234 BEGIN:VCALENDAR 3235 PRODID:-//ACME/DesktopCalendar//EN 3236 METHOD:REPLY 3237 VERSION:2.0 3238 BEGIN:VEVENT 3239 ORGANIZER:MAILTO:A@Example.com 3240 ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- 3241 TO="Mailto:E@example.com":Mailto:C@example.com 3242 UID:calsrv.example.com-873970198738777@example.com 3243 SEQUENCE:0 3244 REQUEST-STATUS:2.0;Success 3245 DTSTAMP:19970611T190000Z 3246 END:VEVENT 3247 END:VCALENDAR 3249 Attendee "C" delegates presence at the meeting to "E". 3251 BEGIN:VCALENDAR 3252 PRODID:-//ACME/DesktopCalendar//EN 3253 METHOD:REQUEST 3254 VERSION:2.0 3255 BEGIN:VEVENT 3256 ORGANIZER:Mailto:A@example.com 3257 ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- 3258 TO="Mailto:E@example.com":Mailto:C@example.com 3259 ATTENDEE;RSVP=TRUE; 3260 DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com 3261 DTSTART:19970701T180000Z 3262 DTEND:19970701T200000Z 3263 SUMMARY:Phone Conference 3264 UID:calsrv.example.com-873970198738777@example.com 3265 SEQUENCE:0 3266 STATUS:CONFIRMED 3267 DTSTAMP:19970611T190000Z 3268 END:VEVENT 3269 END:VCALENDAR 3271 4.2.6 Delegate Accepts the Meeting 3273 To accept a delegated meeting, the delegate, "E", sends the following 3274 message to "A" and "C": 3276 BEGIN:VCALENDAR 3277 PRODID:-//ACME/DesktopCalendar//EN 3278 METHOD:REPLY 3279 VERSION:2.0 3280 BEGIN:VEVENT 3281 ORGANIZER:MAILTO:A@Example.com 3282 ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED- 3283 FROM="Mailto:C@example.com":Mailto:E@example.com 3284 ATTENDEE;PARTSTAT=DELEGATED; 3285 DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com 3286 UID:calsrv.example.com-873970198738777@example.com 3287 SEQUENCE:0 3288 REQUEST-STATUS:2.0;Success 3289 DTSTAMP:19970614T190000Z 3290 END:VEVENT 3291 END:VCALENDAR 3292 4.2.7 Delegate Declines the Meeting 3294 In this example the "Delegate" declines the meeting request and sets the 3295 "ATTENDEE" property "partstat" parameter to "DECLINED". The "Organizer" 3296 SHOULD resend the "REQUEST" to "C" with the "partstat" parameter of the 3297 "Delegate" set to "declined". This lets the "Delegator" know that the 3298 "Delegate" has declined and provides an opportunity to the "Delegator" 3299 to either accept the request or delegate it to another CU. 3301 Response from "E" to "A" and "C". Note the use of the "COMMENT" property 3302 "E" uses to indicate why the delegation was declined. 3304 BEGIN:VCALENDAR 3305 PRODID:-//ACME/DesktopCalendar//EN 3306 METHOD:REPLY 3307 VERSION:2.0 3308 BEGIN:VEVENT 3309 ORGANIZER:MAILTO:A@Example.com 3310 ATTENDEE;PARTSTAT=DELEGATED; 3311 DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com 3312 ATTENDEE;PARTSTAT=DECLINED; 3313 DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com 3314 COMMENT:Sorry, I will be out of town at that time. 3315 UID:calsrv.example.com-873970198738777@example.com 3316 SEQUENCE:0 3317 REQUEST-STATUS:2.0;Success 3318 DTSTAMP:19970614T190000Z 3319 END:VEVENT 3320 END:VCALENDAR 3322 "A" resends the "REQUEST" method to "C". "A" may also wish to express 3323 the fact that the item was delegated in the "COMMENT" property. 3325 BEGIN:VCALENDAR 3326 PRODID:-//ACME/DesktopCalendar//EN 3327 METHOD:REQUEST 3328 VERSION:2.0 3329 BEGIN:VEVENT 3330 ORGANIZER:MAILTO:A@Example.com 3331 ATTENDEE;PARTSTAT=DECLINED; 3332 DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com 3333 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 3334 UID:calsrv.example.com-873970198738777@example.com 3335 SEQUENCE:0 3336 SUMMARY:Phone Conference 3337 DTSTART:19970701T180000Z 3338 DTEND:19970701T200000Z 3339 DTSTAMP:19970614T200000Z 3340 COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR 3341 INVITATION 3342 END:VEVENT 3343 END:VCALENDAR 3344 4.2.8 Forwarding an Event Request 3346 The protocol does not prevent an "Attendee" from "forwarding" an 3347 "VEVENT" calendar component to other "Calendar Users". Forwarding 3348 differs from delegation in that the forwarded "Calendar User" (often 3349 referred to as a "Party Crasher") does not replace the forwarding 3350 "Calendar User". Implementations are not required to add the "Party 3351 Crasher" to the "Attendee" list and hence there is no guarantee that a 3352 "Party Crasher" will receive additional updates to the Event. The 3353 forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the 3354 attendee list. The "Organizer" MAY add the forwarded "Calendar User" to 3355 the attendee list. 3357 4.2.9 Cancel A Group Event 3359 Individual "A" requests a meeting between individuals "A", "B", "C", and 3360 "D". Individual "B" declines attendance to the meeting. Individual "A" 3361 decides to cancel the meeting. The following table illustrates the 3362 sequence of messages that would be exchanged between these individuals. 3364 Messages related to a previously canceled event ("SEQUENCE" property 3365 value is less than the "SEQUENCE" property value of the "CANCEL" 3366 message) MUST be ignored. 3368 +--------------------------------------------------------------------+ 3369 | Action | "Organizer" | "Attendee" | 3370 +--------------------------------------------------------------------+ 3371 | Initiate a meeting | "A" sends a REQUEST | | 3372 | request | message to "B", "C",| | 3373 | | and "D" | | 3374 +--------------------------------------------------------------------+ 3375 | Decline the meeting| | "B" sends a "REPLY" | 3376 | request | | message to "A" with its | 3377 | | | "partstat" para- | 3378 | | | set to "declined". | 3379 +--------------------------------------------------------------------+ 3380 | Cancel the meeting | "A" sends a CANCEL | | 3381 | | message to "B", "C" | | 3382 | | and "D" | | 3383 +--------------------------------------------------------------------+ 3385 The example shows how "A" cancels the event. 3387 BEGIN:VCALENDAR 3388 PRODID:-//ACME/DesktopCalendar//EN 3389 METHOD:CANCEL 3390 VERSION:2.0 3391 BEGIN:VEVENT 3392 ORGANIZER:Mailto:A@example.com 3393 ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com 3394 ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com 3395 ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com 3396 ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com 3397 COMMENT:Mr. B cannot attend. It's raining. Lets cancel. 3398 UID:calsrv.example.com-873970198738777@example.com 3399 SEQUENCE:1 3400 STATUS:CANCELLED 3401 DTSTAMP:19970613T190000Z 3402 END:VEVENT 3403 END:VCALENDAR 3405 4.2.10 Removing Attendees 3407 "A" wants to remove "B" from a meeting. This is done by sending a 3408 "CANCEL" to "B" and removing "B" from the attendee list in the master 3409 copy of the event. 3411 +--------------------------------------------------------------------+ 3412 | Action | "Organizer" | "Attendee" | 3413 +--------------------------------------------------------------------+ 3414 | Remove an "B" | "A" sends a CANCEL | | 3415 | as an "Attendee" | message to "B" | | 3416 +--------------------------------------------------------------------+ 3417 | Update the master | "A" sends the | | 3418 | copy of the event | updated event to | | 3419 | | the remaining | | 3420 | | "Attendees" | | 3421 +--------------------------------------------------------------------+ 3423 The original meeting includes "A", "B", "C", and "D". The example below 3424 shows the "CANCEL" that "A" sends to "B". Note that in the example below 3425 the "STATUS" property is omitted. This is used when the meeting itself 3426 is cancelled and not when the intent is to remove an "Attendee" from the 3427 Event. 3429 BEGIN:VCALENDAR 3430 PRODID:-//ACME/DesktopCalendar//EN 3431 METHOD:CANCEL 3432 VERSION:2.0 3433 BEGIN:VEVENT 3434 ORGANIZER:Mailto:A@example.com 3435 ATTENDEE:mailto:B@example.com 3436 COMMENT:You're off the hook for this meeting 3437 UID:calsrv.example.com-873970198738777@example.com 3438 DTSTAMP:19970613T193000Z 3439 SEQUENCE:1 3440 END:VEVENT 3441 END:VCALENDAR 3443 The updated master copy of the event is shown below. The "Organizer" MAY 3444 resend the updated event to the remaining "Attendees". Note that "B" has 3445 been removed. 3447 BEGIN:VCALENDAR 3448 PRODID:-//ACME/DesktopCalendar//EN 3449 METHOD:REQUEST 3450 VERSION:2.0 3451 BEGIN:VEVENT 3452 ORGANIZER:Mailto:A@example.com 3453 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3454 ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com 3455 ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com 3456 ATTENDEE;TYPE=ROOM:CR_Big@example.com 3457 ATTENDEE;ROLE=NON-PARTICIPANT; 3458 RSVP=FALSE:Mailto:E@example.com 3459 DTSTAMP:19970611T190000Z 3460 DTSTART:19970701T200000Z 3461 DTEND:19970701T203000Z 3462 SUMMARY:Phone Conference 3463 UID:calsrv.example.com-873970198738777@example.com 3464 SEQUENCE:2 3465 STATUS:CONFIRMED 3466 END:VEVENT 3467 END:VCALENDAR 3469 4.2.11 Replacing the Organizer 3471 The scenario for this example begins with "A" as the "Organizer" for a 3472 recurring meeting with "B", "C", and "D". "A" receives a new job offer 3473 in another country and drops out of touch. "A" left no forwarding 3474 address or way to be reached. Using out-of-band communication, the 3475 other "Attendees" eventually learn what has happened and reach an 3476 agreement that "B" should become the new "Organizer" for the meeting. To 3477 do this, "B" sends out a new version of the event and the other 3478 "Attendees" agree to accept "B" as the new "Organizer". "B" also removes 3479 "A" from the event. 3481 When the "Organizer" is replaced, the "SEQUENCE" property value MUST be 3482 incremented. 3484 This is the message "B" sends to "C" and "D" 3486 BEGIN:VCALENDAR 3487 PRODID:-//ACME/DesktopCalendar//EN 3488 METHOD:REQUEST 3489 VERSION:2.0 3490 BEGIN:VEVENT 3491 ORGANIZER:Mailto:B@example.com 3492 ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com 3493 ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com 3494 ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com 3495 DTSTAMP:19970611T190000Z 3496 DTSTART:19970701T200000Z 3497 DTEND:19970701T203000Z 3498 RRULE:FREQ=WEEKLY 3499 SUMMARY:Phone Conference 3500 UID:123456@example.com 3501 SEQUENCE:1 3502 STATUS:CONFIRMED 3503 END:VEVENT 3504 END:VCALENDAR 3506 4.3 Busy Time Examples 3508 Busy time objects can be used in several ways. First, a CU may request 3509 busy time from another CU for a specific range of time. That request can 3510 be answered with a busy time Reply. Additionally, a CU may simply 3511 publish busy their busy time for a given interval and point other CUs to 3512 the published location. The following examples outline both scenarios. 3514 Individual "A" publishes busy time for one week. 3516 BEGIN:VCALENDAR 3517 PRODID:-//ACME/DesktopCalendar//EN 3518 VERSION:2.0 3519 METHOD:PUBLISH 3520 BEGIN:VFREEBUSY 3521 DTSTAMP:19980101T124100Z 3522 ORGANIZER:MAILTO:A@Example.com 3523 DTSTART:19980101T124200Z 3524 DTEND:19980107T124200Z 3525 FREEBUSY:19980101T180000Z/19980101T190000Z 3526 FREEBUSY:19980103T020000Z/19980103T050000Z 3527 FREEBUSY:19980107T020000Z/19980107T050000Z 3528 FREEBUSY:19980113T000000Z/19980113T010000Z 3529 FREEBUSY:19980115T190000Z/19980115T200000Z 3530 FREEBUSY:19980115T220000Z/19980115T230000Z 3531 FREEBUSY:19980116T013000Z/19980116T043000Z 3532 END:VFREEBUSY 3533 END:VCALENDAR 3535 Individual "A" requests busy time from individuals "B", "C". Individual 3536 "B" and "C" replies with busy time data to individual "A". The following 3537 table illustrates the sequence of messages that would be exchanged 3538 between these individuals. 3540 +--------------------------------------------------------------------+ 3541 | Action | "Organizer" | Attendee | 3542 +--------------------------------------------------------------------+ 3543 | Initiate a busy | "A" sends "REQUEST" | | 3544 | time request | message to "B" and | | 3545 | | and "C" | | 3546 +--------------------------------------------------------------------+ 3547 | Reply to the "BUSY"| | "B" sends a "REPLY" | 3548 | request with "BUSY"| | message to "A" with | 3549 | time data | | busy time data | 3550 +--------------------------------------------------------------------+ 3551 4.3.1 Request Busy Time 3553 "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time 3555 BEGIN:VCALENDAR 3556 PRODID:-//ACME/DesktopCalendar//EN 3557 METHOD:REQUEST 3558 VERSION:2.0 3559 BEGIN:VFREEBUSY 3560 ORGANIZER:Mailto:A@example.com 3561 ATTENDEE;ROLE=CHAIR:Mailto:A@example.com 3562 ATTENDEE:Mailto:B@example.com 3563 ATTENDEE:Mailto:C@example.com 3564 DTSTAMP:19970613T190000Z 3565 DTSTART:19970701T080000Z 3566 DTEND:19970701T200000 3567 UID:calsrv.example.com-873970198738777@example.com 3568 END:VFREEBUSY 3569 END:VCALENDAR 3571 4.3.2 Reply To A Busy Time Request 3573 "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component to 3574 "A" 3576 BEGIN:VCALENDAR 3577 PRODID:-//ACME/DesktopCalendar//EN 3578 METHOD:REPLY 3579 VERSION:2.0 3580 BEGIN:VFREEBUSY 3581 ORGANIZER:MAILTO:A@example.com 3582 ATTENDEE:Mailto:B@example.com 3583 DTSTART:19970701T080000Z 3584 DTEND:19970701T200000Z 3585 UID:calsrv.example.com-873970198738777@example.com 3586 FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M 3587 DTSTAMP:19970613T190030Z 3588 END:VFREEBUSY 3589 END:VCALENDAR 3591 "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30. 3593 4.4 Recurring Event and Time Zone Examples 3595 4.4.1 A Recurring Event Spanning Time Zones 3597 This event describes a weekly phone conference. The "Attendees" are each 3598 in a different time zone. 3600 BEGIN:VCALENDAR 3601 PRODID:-//ACME/DesktopCalendar//EN 3602 METHOD:REQUEST 3603 VERSION:2.0 3604 BEGIN:VTIMEZONE 3605 TZID:America-SanJose 3606 TZURL:http://zones.stds_r_us.net/tz/America-SanJose 3607 BEGIN:STANDARD 3608 DTSTART:19671029T020000 3609 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3610 TZOFFSETFROM:-0700 3611 TZOFFSETTO:-0800 3612 TZNAME:PST 3613 END:STANDARD 3614 BEGIN:DAYLIGHT 3615 DTSTART:19870405T020000 3616 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 3617 TZOFFSETFROM:-0800 3618 TZOFFSETTO:-0700 3619 TZNAME:PDT 3620 END:DAYLIGHT 3621 END:VTIMEZONE 3622 BEGIN:VEVENT 3623 ORGANIZER:Mailto:A@example.com 3624 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A@example.COM 3625 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr 3626 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp 3627 DTSTAMP:19970613T190030Z 3628 DTSTART;TZID=America-SanJose:19970701T140000 3629 DTEND;TZID=America-SanJose:19970701T150000 3630 RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU 3631 RDATE;TZID=America-SanJose:19970910T140000 3632 EXDATE;TZID=America-SanJose:19970909T140000 3633 EXDATE;TZID=America-SanJose:19971028T140000 3634 SUMMARY:Weekly Phone Conference 3635 UID:calsrv.example.com-873970198738777@example.com 3636 SEQUENCE:0 3637 STATUS:CONFIRMED 3638 END:VEVENT 3639 END:VCALENDAR 3641 The first two components of this iCalendar object are the time zone 3642 components. The "DTSTART" date coincides with the first instance of the 3643 RRULE property. 3645 The recurring meeting is defined in a particular time zone, presumably 3646 that of the originator. The client for each "Attendee" has the 3647 responsibility of determining the recurrence time in the "Attendee's" 3648 time zone. 3650 The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT. 3651 "Attendee" B@example.fr is in France where the local time on this date 3652 is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in Japan 3653 where local time is 8 hours ahead of UTC or Wednesday, July 2 at 06:00. 3654 The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property 3655 results in 20 instances. The last instance falls on Tuesday, November 3656 11, 1997 2:00pm PDT. The "RDATE" property adds another instance: WED, 3657 10-SEP-1997 2:00 PM PST. 3659 There are two exceptions to this recurring appointment. The first one 3660 is: 3662 TUE, 09-SEP-1997 23:00 GMT 3663 TUE, 09-SEP-1997 14:00 PDT 3664 WED, 10-SEP-1997 06:00 JST 3666 and the second is: 3668 TUE, 28-OCT-1997 23:00 GMT 3669 TUE, 28-OCT-1997 14:00 PST 3670 WED, 29-OCT-1997 06:00 JST 3672 4.4.2 Modify A Recurring Instance 3674 In this example the "Organizer" issues a recurring meeting. Later the 3675 "Organizer" changes an instance of the event by changing the "DTSTART" 3676 property. Note the use of "RECURRENCE-ID" property and "SEQUENCE" 3677 property in the second request. 3679 Original Request: 3681 BEGIN:VCALENDAR 3682 METHOD:REQUEST 3683 PRODID:-//RDU Software//NONSGML HandCal//EN 3684 VERSION:2.0 3685 BEGIN:VEVENT 3686 UID:guid-1@host1.com 3687 SEQUENCE:0 3688 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z 3689 ORGANIZER:Mailto:A@example.com 3690 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3691 ATTENDEE:Mailto:B@example.com 3692 ATTENDEE:Mailto:C@example.com 3693 ATTENDEE:Mailto:D@example.com 3694 DESCRIPTION:IETF-C&S Conference Call 3695 CLASS:PUBLIC 3696 SUMMARY:IETF Calendaring Working Group Meeting 3697 DTSTART:19970601T210000Z 3698 DTEND:19970601T220000Z 3699 LOCATION:Conference Call 3700 DTSTAMP:19970526T083000Z 3701 STATUS:CONFIRMED 3702 END:VEVENT 3703 END:VCALENDAR 3704 The event request below is to change the time of a specific instance. 3705 This changes the July 1st instance to July 3rd. 3707 BEGIN:VCALENDAR 3708 METHOD:REQUEST 3709 PRODID:-//RDU Software//NONSGML HandCal//EN 3710 VERSION:2.0 3711 BEGIN:VEVENT 3712 UID:guid-1@host1com 3713 RECURRENCE-ID:19970701T210000Z 3714 SEQUENCE:1 3715 ORGANIZER:Mailto:A@example.com 3716 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3717 ATTENDEE:Mailto:B@example.com 3718 ATTENDEE:Mailto:C@example.com 3719 ATTENDEE:Mailto:D@example.com 3720 DESCRIPTION:IETF-C&S Conference Call 3721 CLASS:PUBLIC 3722 SUMMARY:IETF Calendaring Working Group Meeting 3723 DTSTART:19970703T210000Z 3724 DTEND:19970703T220000Z 3725 LOCATION:Conference Call 3726 DTSTAMP:19970626T093000Z 3727 STATUS:CONFIRMED 3728 END:VEVENT 3729 END:VCALENDAR 3731 4.4.3 Cancel an Instance 3733 In this example the "Organizer" of a recurring event deletes the August 3734 1st instance. 3736 BEGIN:VCALENDAR 3737 METHOD:CANCEL 3738 PRODID:-//RDU Software//NONSGML HandCal//EN 3739 VERSION:2.0 3740 BEGIN:VEVENT 3741 UID:guid-1@host1.com 3742 ORGANIZER:Mailto:A@example.com 3743 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3744 ATTENDEE:Mailto:B@example.com 3745 ATTENDEE:Mailto:C@example.com 3746 ATTENDEE:Mailto:D@example.com 3747 RECURRENCE-ID:19970801T210000Z 3748 SEQUENCE:2 3749 STATUS:CANCELLED 3750 DTSTAMP:19970721T093000Z 3751 END:VEVENT 3752 END:VCALENDAR 3753 4.4.4 Cancel Recurring Event 3755 In this example the "Organizer" wishes to cancel the entire recurring 3756 event and any exceptions. 3758 BEGIN:VCALENDAR 3759 METHOD:CANCEL 3760 PRODID:-//RDU Software//NONSGML HandCal//EN 3761 VERSION:2.0 3762 BEGIN:VEVENT 3763 UID:guid-1@host1.com 3764 ORGANIZER:Mailto:A@example.com 3765 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3766 ATTENDEE:Mailto:B@example.com 3767 ATTENDEE:Mailto:C@example.com 3768 ATTENDEE:Mailto:D@example.com 3769 DTSTAMP:19970721T103000Z 3770 STATUS:CANCELLED 3771 SEQUENCE:3 3772 END:VEVENT 3773 END:VCALENDAR 3775 4.4.5 Change All Future Instances 3777 This example changes the meeting location from a conference call to 3778 Seattle starting September 1 and extends to all future instances. 3780 BEGIN:VCALENDAR 3781 METHOD:REQUEST 3782 PRODID:-//RDU Software//NONSGML HandCal//EN 3783 VERSION:2.0 3784 BEGIN:VEVENT 3785 UID:guid-1@host1.com 3786 RECURRENCE-ID;THISANDFUTURE:19970901T210000Z 3787 SEQUENCE:3 3788 ORGANIZER:Mailto:A@example.com 3789 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3790 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 3791 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 3792 ATTENDEE;RSVP=TRUE:Mailto:D@example.com 3793 DESCRIPTION:IETF-C&S Discussion 3794 CLASS:PUBLIC 3795 SUMMARY:IETF Calendaring Working Group Meeting 3796 DTSTART:19970901T210000Z 3797 DTEND:19970901T220000Z 3798 LOCATION:Building 32, Microsoft, Seattle, WA 3799 DTSTAMP:19970526T083000Z 3800 STATUS:CONFIRMED 3801 END:VEVENT 3802 END:VCALENDAR 3803 4.4.6 Add A New Instance To A Recurring Event 3805 This example adds a one-time additional instance to the recurring event. 3806 "Organizer" adds a second July meeting on the 15th. 3808 BEGIN:VCALENDAR 3809 METHOD:ADD 3810 PRODID:-//RDU Software//NONSGML HandCal//EN 3811 VERSION:2.0 3812 BEGIN:VEVENT 3813 UID:123456789@host1.com 3814 SEQUENCE:4 3815 ORGANIZER:Mailto:A@example.com 3816 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3817 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 3818 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 3819 ATTENDEE;RSVP=TRUE:Mailto:D@example.com 3820 DESCRIPTION:IETF-C&S Conference Call 3821 CLASS:PUBLIC 3822 SUMMARY:IETF Calendaring Working Group Meeting 3823 DTSTART:19970715T210000Z 3824 DTEND:19970715T220000Z 3825 LOCATION:Conference Call 3826 DTSTAMP:19970629T093000Z 3827 STATUS:CONFIRMED 3828 END:VEVENT 3829 END:VCALENDAR 3831 4.4.7 Add A New Series of Instances To A Recurring Event 3833 The scenario for this example involves an ongoing meeting, originally 3834 set up to occur every Tuesday. The "Organizer" later decides that the 3835 meetings need to be on Tuesdays and Thursdays, but does not want to 3836 reschedule the entire meeting or lose any of the per-instance 3837 information already collected. 3839 The original event: 3841 BEGIN:VCALENDAR 3842 METHOD:REQUEST 3843 PRODID:-//RDU Software//NONSGML HandCal//EN 3844 VERSION:2.0 3845 BEGIN:VEVENT 3846 UID:123456789@host1.com 3847 SEQUENCE:0 3848 RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY 3849 ORGANIZER:Mailto:A@example.com 3850 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3851 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 3852 SUMMARY:Review Accounts 3853 DTSTART:19980303T210000Z 3854 DTEND:19980303T220000Z 3855 LOCATION:The White Room 3856 DTSTAMP:19980301T093000Z 3857 STATUS:CONFIRMED 3858 END:VEVENT 3859 END:VCALENDAR 3861 Assume that many other updates happen to this event and that a lot of 3862 instance-specific information exists in the recurring series. The 3863 "SEQUENCE" property value is 7 for the next update. Now the "Organizer" 3864 wants to add Thursdays to the event: 3866 BEGIN:VCALENDAR 3867 METHOD:ADD 3868 PRODID:-//RDU Software//NONSGML HandCal//EN 3869 VERSION:2.0 3870 BEGIN:VEVENT 3871 UID:123456789@host1.com 3872 SEQUENCE:7 3873 RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY 3874 ORGANIZER:Mailto:A@example.com 3875 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3876 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 3877 SUMMARY:Review Accounts 3878 DTSTART:19980303T210000Z 3879 DTEND:19980303T220000Z 3880 DTSTAMP:19980303T193000Z 3881 LOCATION:The Usual conference room 3882 STATUS:CONFIRMED 3883 END:VEVENT 3884 END:VCALENDAR 3886 Alternatively, if the "Organizer" is not concerned with per-instance 3887 updates, the entire event can be rescheduled using a "REQUEST". This is 3888 done by using the "UID" of the event to reschedule and including the 3889 modified "RRULE". Note, that since this is an entire rescheduling of the 3890 event, any instance-specific information will be lost. 3892 BEGIN:VCALENDAR 3893 METHOD:REQUEST 3894 PRODID:-//RDU Software//NONSGML HandCal//EN 3895 VERSION:2.0 3896 BEGIN:VEVENT 3897 UID:123456789@host1.com 3898 SEQUENCE:7 3899 RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY 3900 ORGANIZER:Mailto:A@example.com 3901 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3902 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 3903 SUMMARY:Review Accounts 3904 DTSTART:19980303T210000Z 3905 DTEND:19980303T220000Z 3906 DTSTAMP:19980303T193000Z 3907 LOCATION:The White Room 3908 STATUS:CONFIRMED 3909 END:VEVENT 3910 END:VCALENDAR 3912 The next series of examples illustrate how an "Organizer" would respond 3913 to a "REFRESH" submitted by an "Attendee" after a series of instance- 3914 specific modifications. To convey all instance-specific changes, the 3915 "Organizer" must provide the latest event description and the relevant 3916 instances. The first three examples show the history including the 3917 initial "VEVENT" request and subsequent instance changes and finally the 3918 "REFRESH". 3920 Original Request: 3922 BEGIN:VCALENDAR 3923 METHOD:REQUEST 3924 PRODID:-//RDU Software//NONSGML HandCal//EN 3925 VERSION:2.0 3926 BEGIN:VEVENT 3927 UID:123456789@host1.com 3928 SEQUENCE:0 3929 RDATE:19980304T180000Z 3930 RDATE:19980311T180000Z 3931 RDATE:19980318T180000Z 3932 ORGANIZER:Mailto:A@example.com 3933 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3934 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 3935 SUMMARY:Review Accounts 3936 DTSTART:19980304T180000Z 3937 DTEND:19980304T200000Z 3938 DTSTAMP:19980303T193000Z 3939 LOCATION:Conference Room A 3940 STATUS:CONFIRMED 3941 END:VEVENT 3942 END:VCALENDAR 3944 Organizer changes 2nd instance Location and Time: 3946 BEGIN:VCALENDAR 3947 METHOD:REQUEST 3948 PRODID:-//RDU Software//NONSGML HandCal//EN 3949 VERSION:2.0 3950 BEGIN:VEVENT 3951 UID:123456789@host1.com 3952 SEQUENCE:1 3953 RECURRENCE-ID:19980311T180000Z 3954 ORGANIZER:Mailto:A@example.com 3955 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3956 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 3957 SUMMARY:Review Accounts 3958 DTSTART:19980311T160000Z 3959 DTEND:19980311T180000Z 3960 DTSTAMP:19980306T193000Z 3961 LOCATION:The Small conference room 3962 STATUS:CONFIRMED 3963 END:VEVENT 3964 END:VCALENDAR 3966 Organizer adds a 4th instance of the meeting using the "ADD" method 3968 BEGIN:VCALENDAR 3969 METHOD:ADD 3970 PRODID:-//RDU Software//NONSGML HandCal//EN 3971 VERSION:2.0 3972 BEGIN:VEVENT 3973 UID:123456789@host1.com 3974 SEQUENCE:2 3975 ORGANIZER:Mailto:A@example.com 3976 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3977 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 3978 SUMMARY:Review Accounts 3979 DTSTART:19980315T180000Z 3980 DTEND:19980315T200000Z 3981 DTSTAMP:19980307T193000Z 3982 LOCATION:Conference Room A 3983 STATUS:CONFIRMED 3984 END:VEVENT 3985 END:VCALENDAR 3987 If "B" requests a "REFRESH", "A" responds with the following to capture 3988 all instance-specific data. In this case both the initial request and an 3989 additional "VEVENT" that specifies the instance-specific data are 3990 included. Because these are both of the same type (they are both 3991 "VEVENTS"), they can be conveyed in the same iCalendar object. 3993 BEGIN:VCALENDAR 3994 METHOD:REQUEST 3995 PRODID:-//RDU Software//NONSGML HandCal//EN 3996 VERSION:2.0 3997 BEGIN:VEVENT 3998 UID:123456789@host1.com 3999 SEQUENCE:2 4000 RDATE:19980304T180000Z 4001 RDATE:19980311T160000Z 4002 RDATE:19980315T180000Z 4003 Error! Bookmark not defined. 4004 ORGANIZER:Mailto:A@example.com 4005 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4006 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4007 SUMMARY:Review Accounts 4008 DTSTART:19980304T180000Z 4009 DTEND:19980304T200000Z 4010 DTSTAMP:19980303T193000Z 4011 LOCATION:Conference Room A 4012 STATUS:CONFIRMED 4013 END:VEVENT 4015 BEGIN:VEVENT 4016 Error! Bookmark not defined. 4018 SEQUENCE:2 4019 RECURRENCE-ID:19980311T160000Z 4020 Error! Bookmark not defined. 4021 ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined. 4022 ATTENDEE;Error! Bookmark not defined. 4023 SUMMARY:Review Accounts 4024 DTSTART:19980311T160000Z 4025 DTEND:19980304T180000Z 4026 DTSTAMP:19980306T193000Z 4027 LOCATION:The Small conference room 4028 STATUS:CONFIRMED 4029 END:VEVENT 4031 END:VCALENDAR 4033 4.4.8 Counter An Instance Of A Recurring Event 4035 In this example one of the "Attendees" counters the "DTSTART" property 4036 of the proposed second July meeting. 4038 BEGIN:VCALENDAR 4039 METHOD:COUNTER 4040 PRODID:-//RDU Software//NONSGML HandCal//EN 4041 VERSION:2.0 4042 BEGIN:VEVENT 4043 UID:guid-1@host1.com 4044 RECURRENCE-ID:19970715T210000Z 4045 SEQUENCE:4 4046 ORGANIZER:Mailto:A@example.com 4047 ATTENDEE;ROLE=CHAIR;RSVP=TRUE:Mailto:A@example.com 4048 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4049 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 4050 ATTENDEE;RSVP=TRUE:Mailto:D@example.com 4051 DESCRIPTION:IETF-C&S Conference Call 4052 CLASS:PUBLIC 4053 SUMMARY:IETF Calendaring Working Group Meeting 4054 DTSTART:19970715T220000Z 4055 DTEND:19970715T230000Z 4056 LOCATION:Conference Call 4057 COMMENT:May we bump this by an hour? I have a conflict 4058 DTSTAMP:19970629T094000Z 4059 END:VEVENT 4060 END:VCALENDAR 4062 4.4.9 Error Reply To A Request 4064 The following example illustrates a scenario where a meeting is proposed 4065 containing an unsupported property and a bad property. 4067 Original Request 4068 BEGIN:VCALENDAR 4069 METHOD:REQUEST 4070 PRODID:-//RDU Software//NONSGML HandCal//EN 4071 VERSION:2.0 4072 BEGIN:VEVENT 4073 UID:guid-1@host1.com 4074 SEQUENCE:0 4075 RRULE:FREQ=MONTHLY;BYMONTHDAY=1 4076 ORGANIZER:Mailto:A@example.com 4077 ATTENDEE;ROLE=CHAIR:Mailto:A@example.com 4078 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4079 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 4080 ATTENDEE;RSVP=TRUE:Mailto:D@example.com 4081 DESCRIPTION:IETF-C&S Conference Call 4082 CLASS:PUBLIC 4083 SUMMARY:IETF Calendaring Working Group Meeting 4084 DTSTART:19970601T210000Z 4085 DTEND:19970601T220000Z 4086 DTSTAMP:19970602T094000Z 4087 LOCATION:Conference Call 4088 STATUS:CONFIRMED 4089 FOO:BAR 4090 END:VEVENT 4091 END:VCALENDAR 4093 Response from "B" to indicate that RRULE is not supported and an 4094 unrecognized property was encountered 4096 BEGIN:VCALENDAR 4097 PRODID:-//RDU Software//NONSGML HandCal//EN 4098 METHOD:REPLY 4099 VERSION:2.0 4100 BEGIN:VEVENT 4101 ORGANIZER:Mailto:A@example.com 4102 ATTENDEE:Mailto:B@example.com 4103 REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single 4104 event;RRULE 4105 REQUEST-STATUS:3.0;Invalid Property Name;FOO 4106 UID:guid-1@host1.com 4107 SEQUENCE:0 4108 DTSTAMP:19970603T094000Z 4109 END:VEVENT 4110 END:VCALENDAR 4112 4.5 Group To-do Examples 4114 Individual "A" creates a group task in which individuals "A", "B", "C" 4115 and "D" will participate. Individual "B" confirms acceptance of the 4116 task. Individual "C" declines the task. Individual "D" tentatively 4117 accepts the task. The following table illustrates the sequence of 4118 messages that would be exchanged between these individuals. Individual 4119 "A" then issues a "REQUEST" method to obtain the status of the to-do 4120 from each participant. The response indicates the individual 4121 "Attendee's" completion status. The table below illustrates the message 4122 flow. 4124 +--------------------------------------------------------------------+ 4125 | Action | "Organizer" | Attendee | 4126 +--------------------------------------------------------------------+ 4127 | Initiate a to-do | "A" sends a REQUEST | | 4128 | request | message to "B", "C",| | 4129 | | and "D" | | 4130 +--------------------------------------------------------------------+ 4131 | Accept the to-do | | "B" sends a "REPLY" | 4132 | request | | message to "A" with its | 4133 | | | "partstat" paramater | 4134 | | | set to "accepted". | 4135 +--------------------------------------------------------------------+ 4136 | Decline the to-do | | "C" sends a REPLY | 4137 | request | | message to "A" with its | 4138 | | | "partstat" parameter | 4139 | | | set to "declined". | 4140 +--------------------------------------------------------------------+ 4141 | Tentatively accept | | "D" sends a REPLY | 4142 | the to-do request | | message to "A" with its | 4143 | | | "partstat" parameter | 4144 | | | set to "tentative". | 4145 +--------------------------------------------------------------------+ 4146 | Check attendee | "A" sends a REQUEST | | 4147 | completion status | message to "B" and | | 4148 | | "D" with current | | 4149 | | information. | | 4150 +--------------------------------------------------------------------+ 4151 | Attendee indicates | | "B" sends a "REPLY" | 4152 | percent complete | | message indicating | 4153 | | | percent complete | 4154 +--------------------------------------------------------------------+ 4155 | Attendee indicates | | "D" sends a "REPLY" | 4156 | completion | | message indicating | 4157 | | | completion | 4158 +--------------------------------------------------------------------+ 4160 4.5.1 A VTODO Request 4162 A sample "REQUEST" with for a "VTODO" calendar component that "A" sends 4163 to "B", "C", and "D". 4165 BEGIN:VCALENDAR 4166 PRODID:-//ACME/DesktopCalendar//EN 4167 METHOD:REQUEST 4168 VERSION:2.0 4169 BEGIN:VTODO 4170 ORGANIZER:Mailto:A@example.com 4171 ATTENDEE;ROLE=CHAIR:Mailto:A@example.com 4172 ATTENDEE;RSVP=TRUE:B@example.com 4173 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 4174 ATTENDEE;RSVP=TRUE:Mailto:D@example.com 4175 DTSTART:19970701T170000Z 4176 DUE:19970722T170000Z 4177 PRIORITY:1 4178 SUMMARY:Create the requirements document 4179 UID:calsrv.example.com-873970198738777-00@example.com 4180 SEQUENCE:0 4181 DTSTAMP:19970717T200000Z 4182 STATUS:Needs Action 4183 END:VTODO 4184 END:VCALENDAR 4186 4.5.2 A VTODO Reply 4188 "B" accepts the to-do. 4190 BEGIN:VCALENDAR 4191 PRODID:-//ACME/DesktopCalendar//EN 4192 METHOD:REPLY 4193 VERSION:2.0 4194 BEGIN:VTODO 4195 ORGANIZER:Mailto:A@example.com 4196 ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com 4197 UID:calsrv.example.com-873970198738777-00@example.com 4198 COMMENT:I'll send you my input by e-mail 4199 SEQUENCE:0 4200 DTSTAMP:19970717T203000Z 4201 REQUEST-STATUS:2.0;Success 4202 END:VTODO 4203 END:VCALENDAR 4205 "B" could have declined the TODO or indicated tentative acceptance by 4206 setting the "partstat" property parameter sequence to "declined" or 4207 "tentative", respectively. 4209 4.5.3 A VTODO Request for Updated Status 4211 "A" requests status from all "Attendees". 4213 BEGIN:VCALENDAR 4214 PRODID:-//ACME/DesktopCalendar//EN 4215 METHOD:REQUEST 4216 VERSION:2.0 4217 BEGIN:VTODO 4218 ORGANIZER:Mailto:A@example.com 4219 ATTENDEE;ROLE=CHAIR:Mailto:A@example.com 4220 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 4221 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com 4222 UID:calsrv.example.com-873970198738777-00@example.com 4223 SUMMARY:Create the requirements document 4224 PRIORITY:1 4225 SEQUENCE:0 4226 STATUS:IN-PROCESS 4227 DTSTART:19970701T170000Z 4228 DTSTAMP:19970717T230000Z 4229 END:VTODO 4230 END:VCALENDAR 4232 4.5.4 A Reply: Percent-Complete 4234 A reply indicating the task being worked on and that "B" is 75% complete 4235 with "B's" part of the assignment. 4237 BEGIN:VCALENDAR 4238 PRODID:-//ACME/DesktopCalendar//EN 4239 METHOD:REPLY 4240 VERSION:2.0 4241 BEGIN:VTODO 4242 ORGANIZER:MAILTO:A@example.com 4243 ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com 4244 PERCENT-COMPLETE:75 4245 UID:calsrv.example.com-873970198738777-00@example.com 4246 DTSTAMP:19970717T233000Z 4247 SEQUENCE:0 4248 END:VTODO 4249 END:VCALENDAR 4251 4.5.5 A Reply: Completed 4253 A reply indicating that "D" completed "D's" part of the assignment. 4255 BEGIN:VCALENDAR 4256 PRODID:-//ACME/DesktopCalendar//EN 4257 METHOD:REPLY 4258 VERSION:2.0 4259 BEGIN:VTODO 4260 ORGANIZER:MAILTO:A@example.com 4261 ATTENDEE;PARTSTAT=COMPLETED:Mailto:D@example.com 4262 UID:calsrv.example.com-873970198738777-00@example.com 4263 DTSTAMP:19970717T233000Z 4264 SEQUENCE:0 4265 END:VTODO 4266 END:VCALENDAR 4268 4.5.6 An Updated VTODO Request 4270 Organizer "A" resends the "VTODO" calendar component. "A" sets the 4271 overall completion for the to-do at 40%. 4273 BEGIN:VCALENDAR 4274 PRODID:-//ACME/DesktopCalendar//EN 4275 METHOD:REQUEST 4276 VERSION:2.0 4277 BEGIN:VTODO 4278 ORGANIZER:Mailto:A@example.com 4279 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4280 ATTENDEE;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B@example.com 4281 ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D@example.com 4282 DTSTART:19970701T170000Z 4283 DUE:19970722T170000Z 4284 PRIORITY:1 4285 SUMMARY:Create the requirements document 4286 UID:calsrv.example.com-873970198738777-00@example.com 4287 SEQUENCE:1 4288 DTSTAMP:19970718T100000Z 4289 STATUS:IN-PROGRESS 4290 PERCENT-COMPLETE:40 4291 END:VTODO 4292 END:VCALENDAR 4294 4.5.7 Recurring VTODOs 4296 The following examples relate to recurring "VTODO" calendar components. 4298 4.5.7.1 Request for a Recurring VTODO 4300 In this example "A" sends a recurring "VTODO" calendar component to "B" 4301 and "D". 4303 BEGIN:VCALENDAR 4304 PRODID:-//ACME/DesktopCalendar//EN 4305 METHOD:REQUEST 4306 VERSION:2.0 4307 BEGIN:VTODO 4308 ORGANIZER:Mailto:A@example.com 4309 ATTENDEE;ROLE=CHAIR:Mailto:A@example.com 4310 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 4311 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com 4312 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR 4313 DTSTART:19980101T100000-0700 4314 DUE:19980103T100000-0700 4315 SUMMARY:Send Status Reports to Area Managers 4316 UID:calsrv.example.com-873970198738777-00@example.com 4317 SEQUENCE:0 4318 DTSTAMP:19970717T200000Z 4319 STATUS:NEEDS ACTION 4320 PRIORITY:1 4321 END:VTODO 4322 END:VCALENDAR 4323 4.5.7.2 Calculating due dates in recurring VTODOs 4325 The due date in a recurring "VTODO" calendar component is either a fixed 4326 interval specified in the "REQUEST" method or specified using the 4327 "RECURRENCE-ID" property. The former is calculated by applying the 4328 difference between "DTSTART" and "DUE" properties and applying it to 4329 each of the start of each recurring instance. Hence, if the initial 4330 "VTODO" calendar component specifies a "DTSTART" property value of 4331 "19970701T190000Z" and a "DUE" property value of "19970801T190000Z" the 4332 interval of one day which is applied to each recurring instance of the 4333 "VTODO" calendar component to determine the "DUE" date of the instance. 4335 4.5.7.3 Replying to an instance of a recurring VTODO 4337 In this example "B" updates "A" on a single instance of the "VTODO" 4338 calendar component. 4340 BEGIN:VCALENDAR 4341 PRODID:-//ACME/DesktopCalendar//EN 4342 METHOD:REPLY 4343 VERSION:2.0 4344 BEGIN:VTODO 4345 ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com 4346 PERCENT-COMPLETE:75 4347 UID:calsrv.example.com-873970198738777-00@example.com 4348 DTSTAMP:19970717T233000Z 4349 RECURRENCE-ID:19980101T170000Z 4350 SEQUENCE:1 4351 END:VTODO 4352 END:VCALENDAR 4354 4.6 Journal Examples 4356 The iCalendar object below describes a single journal entry for October 4357 2, 1997. The "RELATED-TO" property references the phone conference event 4358 for which minutes were taken. 4360 BEGIN:VCALENDAR 4361 METHOD:PUBLISH 4362 PRODID:-//ACME/DesktopCalendar//EN 4363 VERSION:2.0 4364 BEGIN:VJOURNAL 4365 DTSTART:19971002T200000Z 4366 ORGANIZER:MAILTO:A@Example.com 4367 SUMMARY:Phone conference minutes 4368 DESCRIPTION:The editors meeting was held on October 1, 1997. 4369 Details are in the attached document. 4370 UID:0981234-1234234-2410@example.com 4371 RELATED-TO:0981234-1234234-2402-35@example.com 4372 ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt 4373 END:VJOURNAL 4374 END:VCALENDAR 4376 4.7 Other Examples 4378 4.7.1 Event Refresh 4380 Refresh the event with "UID" property value of "guid-1-12345@host1.com": 4382 BEGIN:VCALENDAR 4383 PRODID:-//RDU Software//NONSGML HandCal//EN 4384 METHOD:REFRESH 4385 VERSION:2.0 4386 BEGIN:VEVENT 4387 ORGANIZER:Mailto:A@example.com 4388 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4389 ATTENDEE:Mailto:B@example.com 4390 ATTENDEE:Mailto:C@example.com 4391 ATTENDEE:Mailto:D@example.com 4392 UID: guid-1-12345@host1.com 4393 DTSTAMP:19970603T094000 4394 END:VEVENT 4395 END:VCALENDAR 4397 4.7.2 Bad RECURRENCE-ID 4399 Component instances are identified by the combination of "UID", 4400 "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request to 4401 an "Attendee", there are three cases in which an instance cannot be 4402 found. They are: 4404 1. The component with the referenced "UID" and "RECURRENCE-ID" has been 4405 found but the "SEQUENCE" number in the calendar store does not match 4406 that of the ITIP message. 4408 2. The component with the referenced "UID" has been found, the 4409 "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be found. 4411 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not 4412 support recurrences. 4414 In case (1), two things can happen. If the "SEQUENCE" number of the 4415 "Attendee's" instance is larger than that in the "Organizer's" message 4416 then the "Attendee" is receiving an out-of-sequence message and MUST 4417 ignore it. If the "SEQUENCE" number of the "Attendee's" instance is 4418 smaller, then the "Organizer" is sending out a newer version of the 4419 component and the "Attendee's" version needs to be updated. Since one or 4420 more updates have been missed, the "Attendee" SHOULD send a "REFRESH" 4421 message to the "Organizer" to get an updated version of the event. 4423 In case (2), something has gone wrong. Both the "Organizer" and the 4424 "Attendee" should have the same instances, but the "Attendee" does not 4425 have the referenced instance. In this case the "Attendee" SHOULD send a 4426 "REFRESH" to the "Organizer" to get an updated version of the event. 4428 In case (3), the limitations of the "Attendee's" CUA makes it impossible 4429 to match an instance other than the single instance scheduled. In this 4430 case, the "Attendee" need not send a "REFRESH" to the "Organizer". 4432 The example below shows a sequence in which an "Attendee" sends a 4433 "REFRESH" to the "Organizer". 4435 +--------------------------------------------------------------------+ 4436 | Action | "Organizer" | Attendee | 4437 +--------------------------------------------------------------------+ 4438 | Update an instance | "A" sends "REQUEST"| | 4439 | request | message to "B" | | 4440 +--------------------------------------------------------------------+ 4441 | Attendee requests | | "B" sends a "REFRESH" | 4442 | refresh because | | message to "A" | 4443 | "RECURRENCE-ID" was| | | 4444 | not found | | | 4445 +--------------------------------------------------------------------+ 4446 | Refresh the entire | "A" sends the | | 4447 | Event | latest copy of the | | 4448 | | Event to "B" | | 4449 +--------------------------------------------------------------------+ 4450 | Attendee handles | | "B" updates to the | 4451 | the request and | | latest copy of the | 4452 | updates the | | meeting. | 4453 | instance | | | 4454 +--------------------------------------------------------------------+ 4456 Request from "A": 4458 BEGIN:VCALENDAR 4459 METHOD:REQUEST 4460 PRODID:-//RDU Software//NONSGML HandCal//EN 4461 VERSION:2.0 4462 BEGIN:VEVENT 4463 UID:acme-12345@host1.com 4464 SEQUENCE:3 4465 RRULE:FREQ=WEEKLY 4466 RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z 4467 ORGANIZER:Mailto:A@example.com 4468 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4469 ATTENDEE:Mailto:B@example.com 4470 DESCRIPTION:IETF-C&S Conference Call 4471 SUMMARY:IETF Calendaring Working Group Meeting 4472 DTSTART:19970801T210000Z 4473 DTEND:19970801T220000Z 4474 RECURRENCE-ID:19970809T210000Z 4475 DTSTAMP:19970726T083000 4476 STATUS:CONFIRMED 4477 END:VEVENT 4478 END:VCALENDAR 4480 "B" has the event with "UID" property "acme-12345@host1.com" but "B's" 4481 "SEQUENCE" property value is "1" and the event does not have an instance 4482 at the specified recurrence time. This means that "B" has missed at 4483 least one update and needs a new copy of the event. "B" requests the 4484 latest copy of the event with the following refresh message: 4486 BEGIN:VCALENDAR 4487 PRODID:-//RDU Software//NONSGML HandCal//EN 4488 METHOD:REFRESH 4489 VERSION:2.0 4490 BEGIN:VEVENT 4491 ORGANIZER:Mailto:A@example.com 4492 ATTENDEE:Mailto:B@example.com 4493 UID:acme-12345@host1.com 4494 DTSTAMP:19970603T094000 4495 END:VEVENT 4496 END:VCALENDAR 4498 5 Application Protocol Fallbacks 4500 5.1 Partial Implementation 4502 Applications that support this memo are not required to support the 4503 entire protocol. The following describes how methods and properties 4504 SHOULD "fallback" in applications that do not support the complete 4505 protocol. If a method or property is not addressed in this section, it 4506 may be ignored. 4508 5.1.1 Event-Related Fallbacks 4510 Method Fallback 4511 -------------- ----------------------------------------------------- 4512 PUBLISH Required 4513 REQUEST PUBLISH 4514 REPLY Required 4515 ADD Required 4516 CANCEL Required 4517 REFRESH Required 4518 COUNTER Reply with Not Supported 4519 DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise 4520 reply with Not Supported 4521 iCalendar 4522 Property Fallback 4523 -------------- ----------------------------------------------------- 4524 CALSCALE Ignore; assume GREGORIAN 4525 PRODID Ignore 4526 METHOD Required as described in the Method list above 4527 VERSION Ignore 4529 Event-Related 4530 Components Fallback 4531 -------------- ----------------------------------------------------- 4532 VALARM Reply with Not Supported 4533 VTIMEZONE Required if any DateTime value refers to a time zone. 4535 Component 4536 Property Fallback 4537 -------------- ----------------------------------------------------- 4538 ATTACH Ignore 4539 ATTENDEE Required if EVENT-REQUEST is not implemented; 4540 otherwise reply with Not Supported 4541 CATEGORIES Ignore 4542 CLASS Ignore 4543 COMMENT Ignore 4544 COMPLETED Ignore 4545 CONTACT Ignore 4546 CREATED Ignore 4547 DESCRIPTION Required 4548 DURATION Reply with Not Supported 4549 DTSTAMP Required 4550 DTSTART Required 4551 DTEND Required 4552 EXDATE Ignore 4553 EXRULE Ignore Reply with Not Supported. If implemented, 4554 VTIMEZONE MUST also be implemented. 4555 GEO Ignore 4556 LAST-MODIFIED Ignore 4557 LOCATION Required 4558 ORGANIZER Ignore 4559 PRIORITY Ignore 4560 RELATED-TO Ignore 4561 RDATE Ignore 4562 RRULE Ignore. The first instance occurs on the DTStart 4563 property. If implemented, VTIMEZONE MUST also be 4564 implemented. 4565 RECURRENCE-ID Required if RRULE is implemented; otherwise Ignore 4566 REQUEST-STATUS Required 4567 RESOURCES Ignore 4568 SEQUENCE Required 4569 STATUS Ignore 4570 SUMMARY Ignore 4571 TRANSP Required if FREEBUSY is implemented; otherwise Ignore 4572 URL Ignore 4573 UID Required 4574 X- Ignore 4575 5.1.2 Free/Busy-Related Fallbacks 4577 Method Fallback 4578 -------------- ----------------------------------------------------- 4579 PUBLISH Implementations MAY ignore the METHOD type. The 4580 REQUEST-STATUS "3.14;Unsupported capability" MUST be 4581 returned. 4582 REQUEST Implementations MAY ignore the METHOD type. The 4583 REQUEST-STATUS "3.14;Unsupported capability" MUST be 4584 returned. 4585 REPLY Implementations MAY ignore the METHOD type. The 4586 REQUEST-STATUS "3.14;Unsupported capability" MUST be 4587 returned. 4589 iCalendar 4590 Property Fallback 4591 -------------- ----------------------------------------------------- 4592 CALSCALE Ignore; assume GREGORIAN. 4593 PRODID Ignore 4594 METHOD Required as described in the Method list above. 4595 VERSION Ignore 4597 Component 4598 Property Fallback 4599 -------------- ----------------------------------------------------- 4600 COMMENT Ignore 4601 CONTACT Ignore 4602 DTEND Required 4603 DTSTAMP Required 4604 DTSTART Required 4605 DURATION Required 4606 FREEBUSY Required 4607 ORGANIZER Ignore 4608 REQUEST-STATUS Ignore 4609 UID Required 4610 URL Ignore 4611 X- Ignore 4613 5.1.3 To-Do-Related Fallbacks 4615 Method Fallback 4616 -------------- ----------------------------------------------------- 4617 PUBLISH Required 4618 REQUEST PUBLISH 4619 REPLY Required 4620 ADD Required 4621 CANCEL Required 4622 REFRESH Required 4623 COUNTER Reply with Not Supported 4624 DECLINECOUNTER Required if VTODO - COUNTER is implemented; otherwise 4625 reply with Not Supported 4627 iCalendar 4628 Property Fallback 4629 -------------- ----------------------------------------------------- 4630 CALSCALE Ignore; assume GREGORIAN. 4631 PRODID Ignore 4632 METHOD Required as described in the Method list above. 4633 VERSION Ignore 4635 To-Do-Related 4636 Components Fallback 4637 -------------- ----------------------------------------------------- 4638 VALARM Reply with Not Supported 4639 VTIMEZONE Required if any DateTime value refers to a time zone. 4641 Component 4642 Property Fallback 4643 -------------- ----------------------------------------------------- 4644 ATTACH Ignore 4645 ATTENDEE Required if REQUEST is not implemented; otherwise 4646 ignore 4647 CATEGORIES Ignore 4648 CLASS Ignore 4649 COMMENT Ignore 4650 COMPLETED Required 4651 CONTACT Ignore 4652 CREATED Ignore 4653 DESCRIPTION Required 4654 DUE Required 4655 DURATION Ignore Reply with Not Supported 4656 DTSTAMP Required 4657 DTSTART Required 4658 EXDATE Ignore Reply with Not Supported 4659 EXRULE Ignore Reply with Not Supported. If implemented, 4660 VTIMEZONE MUST also be implemented. 4661 LAST-MODIFIED Ignore 4662 LOCATION Ignore 4663 ORGANIZER Ignore 4664 PERCENT-COMPLETE Ignore 4665 PRIORITY Required 4666 RECURRENCE-ID Ignore 4667 RELATED-TO Ignore 4668 REQUEST-STATUS Ignore 4669 RDATE Ignore 4670 RRULE Ignore. The first instance occurs on the DTSTART 4671 property. If implemented, VTIMEZONE MUST also be 4672 implemented. 4673 RESOURCES Ignore 4674 SEQUENCE Required 4675 STATUS Required 4676 SUMMARY Ignore 4677 URL Ignore 4678 UID Required 4679 X- Ignore 4681 5.1.4 Journal-Related Fallbacks 4683 Method Fallback 4684 -------------- ----------------------------------------------------- 4685 PUBLISH Implementations MAY ignore the METHOD type. The 4686 REQUEST-STATUS "3.14;Unsupported capability" MUST be 4687 returned. 4688 ADD Implementations MAY ignore the METHOD type. The 4689 REQUEST-STATUS "3.14;Unsupported capability" MUST be 4690 returned. 4691 CANCEL Implementations MAY ignore the METHOD type. The 4692 REQUEST-STATUS "3.14;Unsupported capability" MUST be 4693 returned. 4695 iCalendar 4696 Property Fallback 4697 -------------- ----------------------------------------------------- 4698 CALSCALE Ignore; assume GREGORIAN. 4699 PRODID Ignore 4700 METHOD Required as described in the Method list above. 4701 VERSION Ignore 4703 Journal-Related 4704 Components Fallback 4705 -------------- ----------------------------------------------------- 4706 VTIMEZONE Required if any DateTime value refers to a time zone. 4708 Component 4709 Property Fallback 4710 -------------- ----------------------------------------------------- 4711 ATTACH Ignore 4712 ATTENDEE Required if JOURNAL-REQUEST is implemented; otherwise 4713 ignore 4714 CATEGORIES Ignore 4715 CLASS Ignore 4716 COMMENT Ignore 4717 CONTACT Ignore 4718 CREATED Ignore 4719 DESCRIPTION Required 4720 DTSTAMP Required 4721 DTSTART Required 4722 EXDATE Ignore 4723 EXRULE Ignore Reply with Not Supported. If implemented, 4724 VTIMEZONE MUST also be implemented. 4725 LAST-MODIFIED Ignore 4726 ORGANIZER Ignore 4727 RECURRENCE-ID Ignore 4728 RELATED-TO Ignore 4729 RDATE Ignore. 4730 RRULE Ignore. The first instance occurs on the DTSTART 4731 property. If implemented, VTIMEZONE MUST also be 4732 implemented. 4733 SEQUENCE Required 4734 STATUS Ignore 4735 SUMMARY Required 4736 URL Ignore 4737 UID Required 4738 X- Ignore 4740 5.2 Latency Issues 4742 With a store-and-forward transport, it is possible for events to arrive 4743 out of sequence. That is, a "CANCEL" method may be received prior to 4744 receiving the associated "REQUEST" for the calendar component. This 4745 section discusses a few of these scenarios. 4747 5.2.1 Cancellation of an Unknown Calendar Component. 4749 When a "CANCEL" method is received before the original "REQUEST" method 4750 the calendar will be unable to correlate the "UID" property of the 4751 cancellation with an existing calendar component. It is suggested that 4752 messages that can not be correlated that also contain non-zero sequence 4753 numbers be held and not discarded. Implementations MAY age them out if 4754 no other messages arrive with the same "UID" property value and a lower 4755 sequence number. 4757 5.2.2 Unexpected Reply from an Unknown Delegate 4759 When an "Attendee" delegates an item to another CU they MUST send a 4760 "REPLY" method to the "Organizer" using the "ATTENDEE" properties to 4761 indicate that the request was delegated and to whom. Hence, it is 4762 possible for an "Organizer" to receive an "REPLY" from a CU not listed 4763 as one of the original "Attendees". The resolution is left to the 4764 implementation but it is expected that the calendaring software will 4765 either accept the reply or hold it until the related "REPLY" method is 4766 received from the "Delegator". If the version of the "REPLY" method is 4767 out of date the "Organizer" SHOULD treat the message as a "REFRESH" 4768 message and update the delegate with the correct version. 4770 5.3 Sequence Number 4772 Under some conditions, a CUA may receive requests and replies with the 4773 same "SEQUENCE" property value. The "DTSTAMP" property is utilized as a 4774 tie-breaker when two items with the same "SEQUENCE" property value are 4775 evaluated. 4777 6 Security Considerations 4779 ITIP is an abstract transport protocol which will be bound to a real- 4780 time transport, a store-and-forward transport, and perhaps other 4781 transports. The transport protocol will be responsible for providing 4782 facilities for authentication and encryption using standard Internet 4783 mechanisms that are mutually understood between the sender and receiver. 4785 6.1 Security Threats 4787 6.1.1 Spoofing the "Organizer" 4789 In iTIP, the "Organizer" (or someone working on the "Organizer's" 4790 behalf) is the only person authorized to make changes to an existing 4791 "VEVENT", "VTODO", "VJOURNAL" calendar component and republish it or 4792 redistribute updates to the "Attendees". An iCalendar object that 4793 maliciously changes or cancels an existing "VEVENT", "VTODO" or 4794 "VJOURNAL" calendar component may be constructed by someone other than 4795 the "Organizer" and republished or sent to the "Attendees". 4797 6.1.2 Spoofing the "Attendee" 4799 In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component (or 4800 someone working on the "Attendee's" behalf) is the only person 4801 authorized to update any parameter associated with their "ATTENDEE" 4802 property and send it to the "Organizer". An iCalendar object that 4803 maliciously changes the "ATTENDEE" parameters may be constructed by 4804 someone other than the real "Attendee" and sent to the "Organizer". 4806 6.1.3 Unauthorized Replacement of the Organizer 4808 There will be circumstances when "Attendees" of an event or to-do 4809 decide, using out-of-band mechanisms, that the "Organizer" must be 4810 replaced. When the new "Organizer" sends out the updated "VEVENT" or 4811 "VTODO" the "Attendee's" CUA will detect that the "Organizer" has been 4812 changed, but it has no way of knowing whether or not the change was 4813 mutually agreed upon. 4815 6.1.4 Eavesdropping 4817 The iCalendar object is constructed with human-readable clear text. Any 4818 information contained in an iCalendar object may be read and/or changed 4819 by unauthorized persons while the object is in transit. 4821 6.1.5 Flooding a Calendar 4823 Implementations MAY provide a means to automatically incorporate 4824 "REQUEST" methods into a calendar. This presents the opportunity for a 4825 calendar to be flooded with requests, which effectively block all the 4826 calendar's free time. 4828 6.1.6 Procedural Alarms 4830 The "REQUEST" methods for "VEVENT" and "VTODO" calendar components MAY 4831 contain "VALARM" calendar components. The "VALARM" calendar component 4832 may be of type "PROCEDURE" and MAY have an attachment containing an 4833 executable program. Implementations that incorporate these types of 4834 alarms are subject to any virus or malicious attack that may occur as a 4835 result of executing the attachment. 4837 6.1.7 Unauthorized REFRESH Requests 4839 It is possible for an "Organizer" to receive a "REFRESH" request from 4840 someone who is not an "Attendee" of an event or to-do. Only "Attendee's" 4841 of an event or to-do are authorized to receive replies to "REFRESH" 4842 requests. Replying to such requests to anyone who is not an "Attendee" 4843 may be a security problem. 4845 6.2 Recommendations 4847 For an application where the information is sensitive or critical and 4848 the network is subject is subject to a high probability of attack, iTIP 4849 transactions SHOULD be encrypted. This may be accomplished using public 4850 key technology, specifically Security Multiparts for MIME [RFC-1847] in 4851 the iTIP transport binding. This helps mitigate the threats of spoofing, 4852 eavesdropping and malicious changes in transit. 4854 6.2.1 Use of [RFC-1847] to secure iTIP transactions 4856 iTIP transport bindings MUST provide a mechanism based on Security 4857 Multiparts for MIME [RFC-1847] to enable authentication of the sender's 4858 identity, and privacy and integrity of the data being transmitted. This 4859 allows the receiver of a signed iCalendar object to verify the identity 4860 of the sender. This sender may then be correlated to an "ATTENDEE" 4861 property in the iCalendar object. If the correlation is made and the 4862 sender is authorized to make the requested change or update then the 4863 operation may proceed. It also allows the message to be encrypted to 4864 prevent unauthorized reading of the message contents in transit. iTIP 4865 transport binding documents describe this process in detail. 4867 Implementations MAY provide controls for users to disable this 4868 capability. 4870 6.2.2 Implementation Controls 4872 The threat of unauthorized replacement of the "Organizer" SHOULD be 4873 mitigated by a calendar system that uses this protocol by providing 4874 controls or alerts that make "Calendar Users" aware of such "Organizer" 4875 changes and allowing them to decide whether or not the request should be 4876 honored. 4878 The threat of flooding a calendar SHOULD be mitigated by a calendar 4879 system that uses this protocol by providing controls that may be used to 4880 limit the acceptable sources for iTIP transactions, and perhaps the size 4881 of messages and volume of traffic, by source. 4883 The threat of malicious procedural alarms SHOULD be mitigated by a 4884 calendar system that uses this protocol by providing controls that may 4885 be used to disallow procedural alarms in iTIP transactions and/or remove 4886 all alarms from the object before delivery to the recipient. 4888 The threat of unauthorized "REFRESH" requests SHOULD be mitigated by a 4889 calendar system that uses this protocol by providing controls or alerts 4890 that allow "Calendar User" to decide whether or not the request should 4891 be honored. An implementation MAY decide to maintain, for audit or 4892 historical purposes, "Calendar Users" who were part of an attendee list 4893 and who were subsequently uninvited. Similar controls or alerts should 4894 be provided when a "REFRESH" request is received from these "Calendar 4895 Users" as well. 4897 7 Acknowledgments 4899 A hearty thanks to the following individuals who have participated in 4900 the drafting, review and discussion of this memo: 4902 Anik Ganguly, Dan Hickman, Paul Hill, Daryl Huff, Bruce Kahn, Antoine 4903 Leca, Bob Mahoney, John Noerenberg, Leo Parker, John Rose, Doug Royer, 4904 Vinod Seraphin, Richard Shusterman, Derik Stenerson, John Sun, Kevin 4905 Tsurutome. 4907 8 Bibliography 4909 [iCAL] "Internet Calendaring and Scheduling Core Object Specification - 4910 iCalendar", Internet-Draft, October 1997, ftp://ftp.ietf.org/internet- 4911 drafts/draft-ietf-calsch-ical-07.txt. 4913 [ICMS] "Internet Calendaring Model Specification", Internet-Draft, 4914 October 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod- 4915 03.txt. 4917 [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", 4918 Internet-Draft, July 1996, ftp://ftp.ietf.org/internet-drafts/draft- 4919 yergeau-utf8-01.txt. 4921 [iMIP] "iCalendar Message-Based Interoperability Protocol - iMIP", 4922 Internet-Draft, October 1997, ftp://ftp.ietf.org/internet-drafts/draft- 4923 ietf-calsch-imip-05.txt. 4925 [ISO8601] "Data elements and interchange formats - information 4926 interchange - Representation of dates and times", ISO 8601, 1996-06-15, 4927 +1 (212) 642-4900 for ANSI Sales. 4929 [VCAL] "vCalendar - The Electronic Calendaring and Scheduling Format - 4930 Version 1.0", Versit Consortium, September 18, 1996, 4931 http://www.imc.org/pdi/vcal-10.doc. 4933 [VCARD] "vCard - The Electronic Business Card Exchange Format - Version 4934 2.1", Versit Consortium, September 18, 1996, 4935 http://www.imc.org/pdi/vcard-21.doc. 4937 [RFC-821] Postel, "Simple Mail Transfer Protocol", RFC 821, organization 4938 name, November 1996, http://ds.internic.net/rfc/rfc821.txt. 4940 [RFC-1983] "Internet Users' Glossary", RFC 1983, August 1996, 4941 http://ds.internic.net/rfc/rfc1983.txt. 4943 [RFC-2119] "Key words for use in RFCs to Indicate Requirement Levels", 4944 RFC 2119, March 1997, http://ds.internic.net/rfc/rfc2119.txt. 4946 [RFC-2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail 4947 Extensions - Part One - Format of Internet Message Bodies", RFC 2045, 4948 Innosoft, First Virtual, November 1996, 4949 http://ds.internic.net/rfc/rfc2045.txt. 4951 [RFC-2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail 4952 Extensions - Part Two - Media Types", RFC 2046, Innosoft, First Virtual, 4953 November 1996, http://ds.internic.net/rfc/rfc2046.txt. 4955 [UNICODE] The Unicode Consortium, "The Unicode Standard -Version 2.0", 4956 Addison-Wesley Developers Press, July 1996. UTF-8 is described in 4957 section A-2. 4959 [US-ASCII] Coded Character Set--7-bit American Standard Code for 4960 Information Interchange, ANSI X3.4-1986. 4962 9 Authors Addresses 4964 The following address information is provided in a MIME-VCARD, 4965 Electronic Business Card, format. 4967 The authors of this draft are: 4969 BEGIN:VCARD 4970 VERSION:2.1 4971 FN:Frank Dawson 4972 ORG:Lotus Development Corporation 4973 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- 4974 3502;USA 4975 TEL;WORK;MSG:+1-919-676-9515 4976 TEL;WORK;FAX:+1-919-676-9564 4977 EMAIL;INTERNET:Frank_Dawson@Lotus.com 4978 URL:http://home.earthlink.net/~fdawson 4979 END:VCARD 4981 BEGIN:VCARD 4982 VERSION:2.1 4983 FN:Ross Hopson 4984 ORG:On Technology, Inc. 4985 ADR;WORK;POSTAL;PARCEL:Suite 1600;;434 Fayetteville St. 4986 Mall, Two Hannover Square;Raleigh;NC;27601 4987 TEL;WORK;MSG:+1-919-890-4036 4988 TEL;WORK;FAX:+1-919-890-4100 4989 EMAIL;INTERNET:rhopson@on.com 4990 END:VCARD 4992 BEGIN:VCARD 4993 VERSION:2.1 4994 FN:Steve Mansour 4995 ORG:Netscape Communications Corporation 4996 ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 4997 View;CA;94043;USA 4998 TEL;WORK;MSG:+1-650-937-2378 4999 TEL;WORK;FAX:+1-650-937-2103 5000 EMAIL;INTERNET:sman@netscape.com 5001 END:VCARD 5003 BEGIN:VCARD 5004 VERSION:2.1 5005 FN:Steve Silverberg 5006 ORG:Microsoft Corporation 5007 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 5008 Redmond;WA;98052-6399;USA 5009 TEL;WORK;MSG:+1-425-936-9277 5010 TEL;WORK;FAX:+1-425-936-8019 5011 EMAIL;INTERNET:stevesil@Microsoft.com 5012 END:VCARD 5014 The iCalendar object is a result of the work of the Internet Engineering 5015 Task Force Calendaring and scheduling Working Group. The chairman of 5016 that working group is: 5018 BEGIN:VCARD 5019 FN:Anik Ganguly 5020 ORG:Campbel Services, Inc. 5021 ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern 5022 Highway;Southfield;MI;48075;USA 5023 TEL;WORK;MSG:+1-248-559-5955 5024 TEL;WORK;FAX:+1-248-559-5034 5025 EMAIL;INTERNET:anik@ontime.com 5026 END:VCARD 5028 10 Full Copyright Statement 5030 "Copyright (C) The Internet Society (date). All Rights Reserved. 5032 This document and translations of it may be copied and furnished to 5033 others, and derivative works that comment on or otherwise explain it or 5034 assist in its implmentation may be prepared, copied, published and 5035 distributed, in whole or in part, without restriction of any kind, 5036 provided that the above copyright notice and this paragraph are included 5037 on all such copies and derivative works. However, this document itself 5038 may not be modified in any way, such as by removing the copyright notice 5039 or references to the Internet Society or other Internet organizations, 5040 except as needed for the purpose of developing Internet standards in 5041 which case the procedures for copyrights defined in the Internet 5042 Standards process must be followed, or as required to translate it into 5043 languages other than English. 5045 The limited permissions granted above are perpetual and will may be 5046 revoked by the Internet Society or its successors or assigns. 5048 THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN "AS 5049 IS" BASIS AND THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 5050 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 5051 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 5052 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 5053 FITNESS FOR A PARTICULAR PURPOSE.