Application Working Group Doug Royer/INET-Consulting LLC Internet Draft December 27, 2003 Expires: May 2004 iCalendar Scheduling draft-royer-calsch-ex-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire May 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. ABSTRACT A proposal to specify booked persistent data in calendar stores to track "SEQUENCE" and "DTSTAMP" property values for CUAs with direct access to calendar stores. With iMIP the iCalendar CUA's do not see the others stored CS data. With WebDAV, HTTP, or FTP access, the CUA can see into the public data of other calendars. The storage of persistent data mandated by [iTIP] has not been standardized yet. This memo proposes a way to standardize on those persistent items. Also included are ways to make the various ways of using the [iCAL] and [iTIP] "RECURRENCE-ID" property work between vendors and to document the procedures to work with "RECURRENCE-ID"s. Comments about this proposed standard should be sent to the "calsch@ietf.org" mailing list. Royer Expires: May 2004 [Page 1] Internet Draft iCalendar Scheduling December 27, 2003 1. Definitions The following definitions will be used in this memo: uid-object An [iCAL] object that is uniquly identifed by a UID. The term "uid-object" will be used to mean any version of an object with a given UID. So all [iCAL] objects with the same UID are the same "uid-object". update Within this memo 'update' means a change to a uid-object without modifying, addition, or deletion any of DTSTART, DTEND, RRULE, RDATE, EXRULE, or EXDATE. reschedule Within this memo 'reschedule' means a change one or more of the instances to an uid-object that does modify, add, or delete any of DTSTART, DTEND, RRULE, RDATE, EXRULE, or EXDATE. These also include uid-objects with and without RECURRENCE- IDs. single instance reschedule This means an [iCAL] object that has a METHOD:REQUEST with a RECURRENCE-ID property value set to an existing instance and UID already known to the "Attendee". full update An [iCAL] object sent that causes one or more GUI instances to be replaced and is a complete replacement for an [iCAL] object where the UID is already known to the "Attendee". This would be an object without RECURRENCE-ID sent in the object. GUI instance The effective start date/time as seen on the CUs GUI without regard to how it is represented in any [iCAL] object for a single UID at a specific point in time. object instance The term 'object instance' or will refer to the effective start date/time of any one specific single instance in an [iCAL] object that may or might not have any of RRULE, RDATE, EXRULE, or EXDATE. GUI pattern The 'GUI pattern' will refer to the full set of effective start dates/times of all instances as seen on the CUs GUI without regard to how it is represented in any [iCAL] object Royer Expires: May 2004 [Page 2] Internet Draft iCalendar Scheduling December 27, 2003 for a single UID at a specific point in time. object pattern The term 'object pattern' will refer to the effective start dates/times of all instances in a specific [iCAL] object that may or might not have any of RRULE, RDATE, EXRULE, or EXDATE. GUI cancel If the "Organizer" issues an object that has an effect of removing one or more GUI instances from the CUs GUI if accepted. This can be a METHOD:CANCEL or full object update and it will be referred to as a 'GUI cancel'. instance cancel A specific [iCAL] object issued by the "Organizer" that informs a CUA that one or more GUI instances are to be removed. This can be a METHOD:CANCEL or a full update. method:cancel A specific METHOD:CANCEL object issued by the "Organizer" that informs the "Attendee" to cancel one or more GUI instances. update cancel A specific object issued by the "Organizer" that informs a CUA to cause a GUI cancel and is *not* a METHOD:CANCEL object. This can also be a 'full update'. 2. New parameters [iTIP] and [iMIP] describe ways to transfer scheduling information. This memo proposes a standard way for CUAs to understand persistent booked entry information mandated by [iTIP]. This was not need in [iMIP] as the CUA's never could see the other stored data. [iCAL] and [iTIP] have left many with different understandings of how to store and negotiate changes to entries. After reading the large number of CALSCH working group posts on this topic the author believes these methods will allow all procedures posted to interoperate. This memo also proposes the standard ways for implementations to store and exchange [iCAL] information. Conforming [CAP] applications will add XXXX [where XXXX is the RFC number of this draft when published] to their CAP-VERSION property value to indicate compliance to this specification. In [iTIP] "2.1.5 Message Sequencing" it states that the organizer needs to persist the "DTSTAMP" and "SEQUENCE" property values in order to Royer Expires: May 2004 [Page 3] Internet Draft iCalendar Scheduling December 27, 2003 determine when newer or older versions of replies have been received from an attendee. In addition each attendee will need to persist this information in order to determine if there is an update or old information in a REQUEST or other object received from the organizer. This memo proposes new parameters that will not be forwarded using [iTIP] and will be removed when sending [iTIP] objects. These parameters will be viewable using [CAP]. Prior to [CAP] this information was stored in vendor specific ways and did not need to be accessible to alternate vendor implementations. Now that [CAP] allows direct access to the CS, there needs to be new parameters added so that a proliferation of new and incompatible "X-" objects are not created that perform the same operations. 2.1 ACK-DTSTAMP The "ACK-DTSTAMP" parameter is added to the "ATTENDEE" property value in the organizers CS to signify the "DTSTAMP" value that was in the newest "REPLY" from an attendee. The organizer adds the "ACK-DTSTAMP" to each attendees "ATTENDEE" property as the organizer accepts "REPLY" methods from attendees. The value is always from the newest object accepted by the organizer from the attendee. In the organizers CS a missing ACK- SEQUENCE by a CS that supports this specification means that the attendee as not replied. The "ACK-DTSTAMP parameter is added to the "ATTENDEE" property in the attendees CS to signify the "DTSTAMP" property value in the last "REQUEST", "ADD" or other method received received from the organizer. The attendee only adds the "ACK-DTSTAMP" to its own "ATTENDEE" property and to any delegated to attendees. In the attendees CS a missing ACK- SEQUENCE by a CS that supports this specification means that the attendee has not replied. Parameter Name: ACK-DTSTAMP Purpose: The property indicates the date/time of the instance of the newest "DTSTAMP" property value that the attendee had replied. The value MUST be specified in the UTC (Z) time format. Value Type: DATE-TIME Format Definition: The property is defined by the following notation: ackdtstamp = "ACK-DTSTAMP" "=" date-time "Z" Royer Expires: May 2004 [Page 4] Internet Draft iCalendar Scheduling December 27, 2003 Example: ATTENDEE;ACK-SEQUENCE=0;PARTSTAT=ACCEPTED ;ACK-DTSTAMP=20031211T190100Z:cap://Royer.com/Doug 2.2 ACK-SEQUENCE The "ACK-SEQUENCE" parameter is added to the "ATTENDEE" property value in the organizers CS to signify the "SEQUENCE" value that was in the newest "REPLY" from an attendee. The organizer adds the "ACK-SEQUENCE" to each attendees "ATTENDEE" property as the attendee sends "REPLY" methods. The value is always from the newest object accepted by the organizer. In the organizers CS a missing ACK-SEQUENCE by a CS that supports this specification means that the attendee as not replied. The "ACK-SEQUENCE parameter is added to the "ATTENDEE" property in the attendees CS to signify the "SEQUENCE" property value in the last "REQUEST", "ADD" or other method received from the organizer. The attendee only adds the "ACK-SEQUENCE" to its own "ATTENDEE" property and to any delegated to attendees. In the attendees CS a missing ACK- SEQUENCE by a CS that supports this specification means that the attendee has not replied. Parameter Name: ACK-SEQUENCE Purpose: The property indicates the "SEQUENCE" number of the newest reply sent by the attendee. Value Type: INTEGER Format Definition: The property is defined by the following notation: acksequence = "ACK-SEQUENCE" "=" integer Example: ATTENDEE;ACK-SEQUENCE=12;PARTSTAT=ACCEPTED ;ACK-DTSTAMP=20021210T010100Z:mailto:Doug@Royer.com 2.3 SENT-DTSTAMP The "SENT-DTSTAMP" parameter is added to the "ATTENDEE" property value in the organizers CS to signify the "DTSTAMP" value that was last sent to the attendee. The organizer adds the "SENT-DTSTAMP" to each Royer Expires: May 2004 [Page 5] Internet Draft iCalendar Scheduling December 27, 2003 attendees "ATTENDEE" property as the organizer sends objects to an attendee. The value is always from the newest object sent by the organizer to the attendee. In the organizers CS a missing SENT-SEQUENCE by a CS that supports this specification means that the organizer has not sent an object to that attendee. This parameter is not used by the attendees except in "ATTENDEE" properties that have a "DELEGATED-TO" parameter. Parameter Name: SENT-DTSTAMP Purpose: The property indicates the date/time of the instance of the newest "DTSTAMP" property value that the attendee sent to the organizer. The value MUST be specified in the UTC (Z) time format. Value Type: DATE-TIME Format Definition: The property is defined by the following notation: sentdtstamp = "SENT-DTSTAMP" "=" date-time "Z" Example: ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T190100Z ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T195000Z :cap://Royer.com/Doug ATTENDEE ;PARTSTAT=DELEGATED ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T192000Z ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T1930000Z ;DELEGATED-TO="mailto:User@Example.com" :mailto:Doug@Royer.com The above example would signify that the organizer last sent a "SEQUENCE:3" object and the last object from the attendee was for a "SEQUENCE:0" object. Royer Expires: May 2004 [Page 6] Internet Draft iCalendar Scheduling December 27, 2003 2.4 SENT-SEQUENCE The "SENT-SEQUENCE" parameter is added to the "ATTENDEE" property value in the organizers CS to signify the "SEQUENCE" value that was in the newest object sent to the attendee. The organizer adds the "SENT- SEQUENCE" to each attendees "ATTENDEE" property as objects are sent, In the organizers CS a missing SENT-SEQUENCE by a CS that supports this specification means that the organizer has not sent an object to that attendee. This parameter is not used by the attendees except in "ATTENDEE" properties that have a "DELEGATED-TO" parameter. Parameter Name: ACK-SEQUENCE Purpose: The property indicates the "SEQUENCE" number of the newest object sent by the organizer. Value Type: INTEGER Format Definition: The property is defined by the following notation: sentequence = "ACK-SEQUENCE" "=" integer Example: ATTENDEE;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T190100Z ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T195000Z :cap://Royer.com/Doug ATTENDEE ;PARTSTAT=DELEGATED ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T192000Z ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T1930000Z ;DELEGATED-TO="mailto:User@Example.com" :mailto:Doug@Royer.com 3. Commenting examples In this specification comments to examples will be included in the Royer Expires: May 2004 [Page 7] Internet Draft iCalendar Scheduling December 27, 2003 examples and will not be part of the data stored. These example comments will all start with '#' as in this example: ATTENDEE ;SENT-SEQUENCE=0 # This is a comment ;SENT-DTSTAMP=20031211T190100Z # that may span lines. :mailto:upn-b@example.com # Or not. 4. Inviting an Attendee The one way to invite attendees is described in [iTIP]. That is you send them an iCalendar object that contains the descriptions about the event where you wish the attendee to attend. Assume this original [iTIP] object were sent to attendees A-E: (EXAMPLE 'A') BEGIN:VCALENDAR ... PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 ... BEGIN:VEVENT UID:1 SEQUENCE:0 ORGANIZER:mailto:upn-a@example.com ATTENDEE:mailto:upn-b@example.com ATTENDEE:mailto:upn-c@example.com ATTENDEE:mailto:upn-d@example.com ATTENDEE:mailto:upn-e@example.com DTSTAMP:20031210T190000Z DTSTART:20031215T200000Z DTEND:20031215T210000Z RRULE:FREQ=DAILY;COUNT=5 SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT END:VCALENDAR Here is what the organizer would have in the booked entry at this point in time. (EXAMPLE 'B' - the organizes booked entry at this point) Royer Expires: May 2004 [Page 8] Internet Draft iCalendar Scheduling December 27, 2003 BEGIN:VEVENT UID:1 SEQUENCE:0 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190000Z # with this DTSTAMP value :mailto:upn-b@example.com # to 'upn-b' ATTENDEE ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190000Z # with this DTSTAMP value :mailto:upn-c@example.com # to 'upn-c'. ATTENDEE ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190000Z # with this DTSTAMP value :mailto:upn-d@example.com # to 'upn-d'. ATTENDEE ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190000Z # with this DTSTAMP value :mailto:upn-e@example.com # to 'upn-e'. DTSTAMP:20031211T190100Z # DTSTAMP of 'this' object. DTSTART:20031215T200000Z DTEND:20031215T210000Z RRULE:FREQ=DAILY;COUNT=5 SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT At this point any organizer CUA could determine that all 4 attendees were invited. The organizer CUA could tell that no "REPLY" method objects for "UID:1" had been processed by any owner CUA because there was no "ACK-DTSTAMP" or "ACK-SEQUENCE" property. Now assume that all 4 attendees accepted the meeting request as sent. The attendees need to somehow remember the "DTSTAMP" property value of the organizer object they replied to so that if they get another object with the same "UID" and "SEQUENCE" property values then they will know it is an update to the "VEVENT" component when the "DTSTAMP" property value is newer. And if the "DTSTAMP" property value of the new object is older than the "ACK-DTSTAMP" parameter value then they know that they can ignore the older data. At this point all 4 attendees have a booked entry in their CS. Note that per [CAP] booked entries have no "METHOD" property. In this example attendee 'upn-b@example.com' stores the "DTSTAMP" property value of the original object (EXAMPLE 'A' above) in the "ACK-DTSTAMP" parameter so Royer Expires: May 2004 [Page 9] Internet Draft iCalendar Scheduling December 27, 2003 that they can tell which version of the UID/SEQUENCE/DTSTAMP object they had when they did the "METHOD:REPLY". If they get a "UID:1" "SEQUENCE:0" object again, they compare the "DTSTAMP" property value against the "ACK-DTSTAMP" to determine if it is old or new information. Here is an example of the booked entry in the CS used by 'upn- b@example.com' after sending a "REPLY" method back to the organizer accepting the entry: (EXAMPLE 'C' - attendee 'upn-b@example.com' booked entry) BEGIN:VEVENT UID:1 SEQUENCE:0 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;ACK-SEQUENCE=0 # 'upn-b' ack'd this sequence ;ACK-DTSTAMP=20031210T190000Z # with this DTSTAMP value :mailto:upn-b@example.com # that matches the DTSTAMP ATTENDEE:mailto:upn-c@example.com # value sent in example 'A'. ATTENDEE:mailto:upn-d@example.com ATTENDEE:mailto:upn-e@example.com DTSTAMP:20031211T190200Z # DTSTAMP of 'this' object. DTSTART:20031215T200000Z DTEND:20031215T210000Z RRULE:FREQ=DAILY;COUNT=5 SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT Any attendee CUA could tell the last processed "SEQUENCE" and "DTSTAMP" values that had been replied to by an attendee CUA that had been accepted. The "ACK-SEQUENCE" and "SEQUENCE" values will not match during "COUNTER" method processing and negotiation as shown in another section of this specification. Here is an example of one of those replies ('upn-c@example.com') sent from an attendee back to the organizer. The "ACK-SEQUENCE" and "ACK- DTSTAMP" values are removed before being sent using [iTIP] to the organizer as shown in this example: (EXAMPLE 'D' - reply of 'upn-c@example.com' back to organizer) BEGIN:VCALENDAR VERSION:2.0 METHOD:REPLY ... Royer Expires: May 2004 [Page 10] Internet Draft iCalendar Scheduling December 27, 2003 BEGIN:VEVENT UID:1 SEQUENCE:0 ORGANIZER:mailto:upn-a@example.com ATTENDEE;PARTSTAT=ACCEPTED:mailto:upn-c@example.com DTSTAMP:20031211T190300Z # DTSTAMP of 'this' REPLY object. REQUEST-STATUS:2.0;Success END:VEVENT END:VCALENDAR And the organizer would have to persist the following information about the attendees per section 2.1.5 of [iTIP]; the "SEQUENCE" and "DTSTAMP" property values for each attendees response. The organizer needs to remember which "SEQUENCE" and "DTSTAMP" values each attendee sent back to the organizer. These are the "DTSTAMP" property values of the attendees "METHOD:REPLY" (as in example 'D' above), and not the value from the organizers original "METHOD:REQUEST". In this way the attendee can update their participation status or other information and if received out of order the organizer can tell which is the newest. Here is what the organizer could have as its booked entry for "UID:1" in the organizers CS at this point in time and after all attendees replied they would attend: (EXAMPLE 'E' - the organizes booked entry at this point) BEGIN:VEVENT UID:1 SEQUENCE:0 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190100Z # The 'DTSTAMP' value of that object. ;ACK-SEQUENCE=0 # Attendee acknowledged SEQUENCE:0 ;ACK-DTSTAMP=20031211T190200Z :mailto:upn-b@example.com # To 'upn-b'. ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190100Z # The 'DTSTAMP' value of that object. ;ACK-SEQUENCE=0 # Attendee acknowledged SEQUENCE:0 ;ACK-DTSTAMP=20031211T190300Z # Matches DTSTAMP from example 'D' :mailto:upn-c@example.com # To 'upn-c'. ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object Royer Expires: May 2004 [Page 11] Internet Draft iCalendar Scheduling December 27, 2003 ;SENT-DTSTAMP=020031211T190100Z # The 'DTSTAMP' value of that object. ;ACK-SEQUENCE=0 # Attendee acknowledged SEQUENCE:0 ;ACK-DTSTAMP=20031211T190400Z :mailto:upn-d@example.com # To 'upn-d'. ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190100Z # The 'DTSTAMP' value of that object. ;ACK-SEQUENCE=0 # Attendee acknowledged SEQUENCE:0 ;ACK-DTSTAMP=20031211T190500Z :mailto:upn-e@example.com # To 'upn-e'. DTSTAMP:20031211T190600Z # DTSTAMP of 'this' object. DTSTART:20031215T200000Z DTEND:20031215T210000Z RRULE:FREQ=DAILY;COUNT=5 SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT Note that in example 'E' the "ACK-SEQUENCE" and "ACK-DTSTAMP" parameters match the values in the "REPLY" objects sent from the individual attendees and not from anything the organizer generated. In example 'D' attendee 'upn-c' did a "REPLY" to "SEQUENCE:0" of "UID:1" and set the "REPLY" objects "DTSTAMP" property value to "20031211T190300Z", which match the persisted entries in the organizers booked object for the 'upn-c' "ATTENDEE" entry for "UID:1". Had the organizer updated something and not needed to update the "SEQUENCE" property value and then sent a new "UID:1" "SEQUENCE:0" object, it would have generated a newer "DTSTAMP" property value for that update object and the "SENT-DTSTAMP" parameter values would be newer than the "ACK-DTSTAMP" parameter values and any organizer CUA could tell that the the non reschedule updates had not been processed by any organizer CUA. 4.1 Invite to a Single Instances Any UPN could be added to one, two, three, four, or all five instances of "UID:1". This next example shows how to add a new attendee to exactly one instance of an existing object. To add to more than just one add the correct "RRULE", "EXRULE", "RDATE", or "EXDATE" properties and send the object. If the organizer determines that the other attendees ('upn-b'-'upn-e') do not need to see that "Attendee" 'upn-f' is being invited to this one Royer Expires: May 2004 [Page 12] Internet Draft iCalendar Scheduling December 27, 2003 instances of "UID:1" then the organizer could send the following object only to 'upn-f@example.com'. In this example 'upn-f@example.com' would not know about the 1st, 3rd, 4th, or 5th instances in the "UID:1" "SEQUENCE:0" object sent to the other 'upn-b'-'upn-e' attendees. Here 'upn-f@example.com' is being invited only to the 2nd instance at "20031216T200000Z": (EXAMPLE 'F' - sent only to 'F@example.com') BEGIN:VCALENDAR METHOD:REQUEST VERSION:2.0 ... BEGIN:VEVENT UID:1 SEQUENCE:1 ORGANIZER:mailto:upn-a@example.com ATTENDEE:mailto:upn-f@example.com DTSTAMP:20031211T190700Z DTSTART: DTEND:20031217T210000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT END:VCALENDAR The attendees 'upn-b' - 'upn-e' could have been sent the "UID:1" "SEQUENCE:1" object. However as their CUA may require human intervention and they would be required to reply with a "METHOD:REPLY" if they were to get that "UID:1" "SEQUENCE:1" object. The had organizer determined they did not need to see that additional attendees were invited, so there is no need to send them the "UID:1" "SEQUENCE:1" update that does not effect them or their booked objects. Now assume that 'upn-f@example.com' says they will attendee the meeting and they sent a reply with a "DTSTAMP" property value of "20031211T190800Z". Note that booked entries may at times contain objects that can not be represented in one "VEVENT" (or other) component. That is reflected below by having more than one "VEVENT" component that is in the CS making up the one booked "UID:1" object. Do not confuse [iTIP] objects with booked objects. Booked objects contain the information about an entry and [iTIP] us used to transfer and coordinate information exchange. Now the organizers booked entry could be: Royer Expires: May 2004 [Page 13] Internet Draft iCalendar Scheduling December 27, 2003 (EXAMPLE 'G' - the organizes booked entry at this point) BEGIN:VEVENT UID:1 SEQUENCE:1 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190000Z # The 'DTSTAMP' value of that object. ;ACK-SEQUENCE=0 # Attendee acknowledged SEQUENCE:0 ;ACK-DTSTAMP=20031211T190200Z :mailto:upn-b@example.com # To 'upn-b'. ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190000Z # The 'DTSTAMP' value of that object. ;ACK-SEQUENCE=0 # Attendee acknowledged SEQUENCE:0 ;ACK-DTSTAMP=20031211T190300Z :mailto:upn-c@example.com # To 'upn-c'. ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190000Z # The 'DTSTAMP' value of that object. ;ACK-SEQUENCE=0 # Attendee acknowledged SEQUENCE:0 ;ACK-DTSTAMP=20031211T190400Z :mailto:upn-d@example.com # To 'upn-d'. ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190000Z # The 'DTSTAMP' value of that object. ;ACK-SEQUENCE=0 # Attendee acknowledged SEQUENCE:0 ;ACK-DTSTAMP=20031211T190500Z :mailto:upn-e@example.com # To 'upn-e'. DTSTAMP:20031211T190900Z DTSTART:20031215T200000Z DTEND:20031215T210000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 RRULE:FREQ=DAILY;COUNT=5 END:VEVENT BEGIN:VEVENT: UID:1 SEQUENCE:1 ORGANIZER:mailto:upn-a@example.com ATTENDEE Royer Expires: May 2004 [Page 14] Internet Draft iCalendar Scheduling December 27, 2003 ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=1 # Organizer sent SEQUENCE:0 object ;SENT-DTSTAMP=20031211T190700Z # The 'DTSTAMP' value of that object. ;ACK-SEQUENCE=1 ;ACK-DTSTAMP=20031211T190800Z # Matches DTSTAMP from 'upn-f' reply. :mailto:upn-f@example.com DTSTAMP:20031211T190900Z DTSTART:20031217T200000Z DTEND:20031217T210000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT Any organizer CUA could tell that only 'upn-f' had been sent the "SEQUENCE:1" object and that for what ever reason the organizer determined that the other attendees did not need to be sent an update. The two "VEVENT" components are shown separate as it would be impossible to represent one "VEVENT" component that represented the instances for all of the invited attendees. Above the booked object is at "SEQUENCE:1" and only attendee 'upn-f' as replied to "SEQUENCE:1". The other attendees last replied to "SEQUENCE:0" and it does not matter because the organizer determine they do not need to know that 'upn-f' is attending and no change was made to the patter of instances since their 'SEQUENCE:0' "REPLY". The "SEQUENCE" property value is set to '1' in the booked entry because that is the latest version of the object. The object sent to 'upn-f@example.com' results in exactly one GUI instance on the 'upn-f@example.com's GUI. The object sent to 'upn- b@example.com' through 'upn-e@example.com' results in five instances on 'upn-b@example.com' through 'upn-e@example.com' GUIs. 5. Adding instances There are two ways described in [iTIP] to add instances and they are a full update and using the "ADD" method. 5.1 Adding instances with full update The organizer sends all effected attendees an update that includes the new instances. The new instance will be 20040101T100000Z. Royer Expires: May 2004 [Page 15] Internet Draft iCalendar Scheduling December 27, 2003 The organizers CUA looks at the booked object in the organizers CS compares the instances to the new instances the organizer wishes to add to get a list of the effected attendees. Then the organizer updates the booked entry by adding the new instances and increments the "SEQUENCE" property value to '2' at the same time. At this point the organizers booked entry contains: (EXAMPLE 'H' - the organizes booked entry at this point) BEGIN:VEVENT UID:1 SEQUENCE:2 # Updated ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 ;SENT-DTSTAMP=20031211T190000Z ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T190200Z :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 ;SENT-DTSTAMP=20031211T190000Z ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T190300Z :mailto:upn-c@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 ;SENT-DTSTAMP=20031211T190000Z ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T190400Z :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=0 ;SENT-DTSTAMP=20031211T190000Z ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T190500Z :mailto:upn-e@example.com DTSTAMP:20031211T191000Z # Updated DTSTART:20031215T200000Z DTEND:20031215T210000Z RDATE:20040101T100000Z. # Added SUMMARY:Standards Meeting STATUS:CONFIRMED Royer Expires: May 2004 [Page 16] Internet Draft iCalendar Scheduling December 27, 2003 LOCATION: Los Angles, building B room R1 RRULE:FREQ=DAILY;COUNT=5 END:VEVENT BEGIN:VEVENT: UID:1 SEQUENCE:2 # Updated ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=1 ;SENT-DTSTAMP=20031211T190700Z ;ACK-SEQUENCE=1 ;ACK-DTSTAMP=20031211T190800Z :mailto:upn-f@example.com DTSTAMP:20031211T191000Z # Updated DTSTART:20031217T200000Z DTEND:20031217T210000Z RDATE:20040101T100000Z. # Added SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT Now any organizer CUA could tell that no attendee had been sent any "SEQUENCE:2" objects. Then the organizers CUA sends the following objects: (EXAMPLE 'I' sent to 'upn-b' - 'upn-e' @example.com) BEGIN:VCALENDAR METHOD:REQUEST VERSION:2.0 ... BEGIN:VEVENT UID:1 SEQUENCE:2 ORGANIZER:mailto:upn-a@example.com ATTENDEE:mailto:upn-b@example.com ATTENDEE:mailto:upn-c@example.com ATTENDEE:mailto:upn-d@example.com ATTENDEE:mailto:upn-e@example.com DTSTAMP:20031210T191100Z DTSTART:20031215T200000Z DTEND:20031215T210000Z RDATE:20040101T100000Z. RRULE:FREQ=DAILY;COUNT=5 Royer Expires: May 2004 [Page 17] Internet Draft iCalendar Scheduling December 27, 2003 SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT END:VCALENDAR (This is sent to 'upn-f@example.com) BEGIN:VCALENDAR METHOD:REQUEST VERSION:2.0 ... BEGIN:VEVENT UID:1 SEQUENCE:2 ORGANIZER:mailto:upn-a@example.com ATTENDEE:mailto:upn-f@example.com DTSTAMP:20031211T191200Z DTSTART:20031217T200000Z DTEND:20031217T210000Z RDATE:20040101T100000Z. SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT END:VCALENDAR Now the organizers booked entry has: (EXAMPLE 'J' - the organizes booked entry at this point) BEGIN:VEVENT UID:1 SEQUENCE:2 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=2 ;SENT-DTSTAMP=20031210T191100Z # Matches example 'I' ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T190200Z :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=2 ;SENT-DTSTAMP=20031210T191100Z # Matches example 'I' ;ACK-SEQUENCE=0 Royer Expires: May 2004 [Page 18] Internet Draft iCalendar Scheduling December 27, 2003 ;ACK-DTSTAMP=20031211T190300Z :mailto:upn-c@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=2 ;SENT-DTSTAMP=20031210T191100Z # Matches example 'I' ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T190400Z :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=2 ;SENT-DTSTAMP=20031210T191100Z # Matches example 'I' ;ACK-SEQUENCE=0 ;ACK-DTSTAMP=20031211T190500Z :mailto:upn-e@example.com DTSTAMP:20031211T191000Z DTSTART:20031215T200000Z DTEND:20031215T210000Z RDATE:20040101T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 RRULE:FREQ=DAILY;COUNT=5 END:VEVENT BEGIN:VEVENT: UID:1 SEQUENCE:2 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=2 ;SENT-DTSTAMP=20031210T191200Z # Matches example 'I' ;ACK-SEQUENCE=1 ;ACK-DTSTAMP=20031211T190800Z :mailto:upn-f@example.com DTSTAMP:20031211T191000Z DTSTART:20031217T200000Z DTEND:20031217T210000Z RDATE:20040101T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT Showing that all attendees had been sent the "SEQUENCE:2" objects. And Royer Expires: May 2004 [Page 19] Internet Draft iCalendar Scheduling December 27, 2003 remembering the "DTSTAMP" property value of the sent object. Any organizer CUA could tell that at this point no attenee replies had been processed as the "ACK-SEQUENCE" values are less than the "SENT-SEQUENCE" values. Assume they all reply to the "UID:1" "SEQUENCE:2" object and they will all attend. At this point the organizers booked entry contains: (EXAMPLE 'K' - the organizes booked entry at this point) BEGIN:VEVENT UID:1 SEQUENCE:2 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=2 ;SENT-DTSTAMP=20031210T191100Z # Matches example 'I' ;ACK-SEQUENCE=2 ;ACK-DTSTAMP=20031211T191300Z :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=2 ;SENT-DTSTAMP=20031210T191100Z # Matches example 'I' ;ACK-SEQUENCE=2 ;ACK-DTSTAMP=20031211T191400Z :mailto:upn-c@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=2 ;SENT-DTSTAMP=20031210T191100Z # Matches example 'I' ;ACK-SEQUENCE=2 ;ACK-DTSTAMP=20031211T191500Z :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=2 ;SENT-DTSTAMP=20031210T191100Z # Matches example 'I' ;ACK-SEQUENCE=2 ;ACK-DTSTAMP=20031211T191600Z :mailto:upn-e@example.com DTSTAMP:20031211T191800Z DTSTART:20031215T200000Z DTEND:20031215T210000Z RDATE:20040101T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED Royer Expires: May 2004 [Page 20] Internet Draft iCalendar Scheduling December 27, 2003 LOCATION: Los Angles, building B room R1 RRULE:FREQ=DAILY;COUNT=5 END:VEVENT BEGIN:VEVENT: UID:1 SEQUENCE:2 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=2 ;SENT-DTSTAMP=20031210T191200Z # Matches example 'I' ;ACK-SEQUENCE=2 ;ACK-DTSTAMP=20031211T191700Z :mailto:upn-f@example.com DTSTAMP:20031211T191800Z DTSTART:20031217T200000Z DTEND:20031217T210000Z RDATE:20040101T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT Any organizer CUA can tell that all 5 attendees have replied to the lastest version of "UID:1" and will attend. 5.1.1 Adding two instances with ADD Another way to add an instances is with the "ADD" method. An advantage to the "ADD" method is that it allows other information about the related events to change. For example the "LOCATION" property value could change just for one or more of the added instances. So in this example two instances will be added to "UID:1" and they are "20040102T100000Z" and "20040103T090000Z" and the location for these instance will be 'New York, building T, room 1200'. The organizer increments the "SEQUENCE" property value for the booked entry to '3' and adds the new instances. Then this same object can be sent to all of the attending or effected attendees. (EXAMPLE 'L') BEGIN:VCALENDAR METHOD:ADD VERSION:2.0 Royer Expires: May 2004 [Page 21] Internet Draft iCalendar Scheduling December 27, 2003 ... BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE:mailto:upn-b@example.com ATTENDEE:mailto:upn-c@example.com ATTENDEE:mailto:upn-d@example.com ATTENDEE:mailto:upn-e@example.com ATTENDEE:mailto:upn-f@example.com DTSTAMP:20031211T192000Z DTSTART:20040102T100000Z DTEND:20040102T110000Z RDATE:20040103T090000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT END:VCALENDAR Now assume they all reply and will attend. The organizers booked entry could then look like this: (EXAMPLE 'K' - the organizes booked entry at this point) # The LA Meetings are unique to 'upn-b' - 'upn-e'. BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192100Z :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192200Z :mailto:upn-c@example.com ATTENDEE ;PARTSTAT=ACCEPTED Royer Expires: May 2004 [Page 22] Internet Draft iCalendar Scheduling December 27, 2003 ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192300Z :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-e@example.com DTSTAMP:20031211T192600Z DTSTART:20031215T200000Z DTEND:20031215T210000Z RDATE:20040101T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 RRULE:FREQ=DAILY;COUNT=5 END:VEVENT # The New York Meetings are common to all attendees at this point. BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192100Z :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192200Z :mailto:upn-c@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192300Z Royer Expires: May 2004 [Page 23] Internet Draft iCalendar Scheduling December 27, 2003 :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-e@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-f@example.com DTSTAMP:20031211T192600Z DTSTART:20040102T100000Z DTEND:20040102T110000Z RDATE:20040103T090000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT # Unique to 'upn-f' BEGIN:VEVENT: UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-f@example.com DTSTAMP:20031211T192600Z DTSTART:20031217T200000Z DTEND:20031217T210000Z RDATE:20040101T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT Any organizer CUA can tell that all attendees have acknowladged the Royer Expires: May 2004 [Page 24] Internet Draft iCalendar Scheduling December 27, 2003 "UID:1" "SEQUENCE:3" requests. At this point any CUA and UPN that had access and that fetched "UID:1" with from the organizers CS with "EXPAND:TRUE" would get back 7 instances. 20031215T200000Z 20031216T200000Z 20031217T200000Z 20031218T200000Z 20031219T200000Z 20040102T100000Z 20040103T090000Z Which are the "RECURRENCE-ID" property values for the 7 instances of the booked "UID:1" object at this point in time. So a query for just the "UID" and "RECURRENCE-ID" properties of "VEVENT" components that covered that time span with "EXPAND:TRUE" property, would return: (EXAMPLE 'L' - RECURRENCE-ID values returned at this point) BEGIN:VREPLY ... BEGIN:VEVENT UID:1 RECURRENCE-ID:20031215T200000Z END:VEVENT BEGIN:VEVENT UID:1 RECURRENCE-ID:20031216T200000Z END:VEVENT BEGIN:VEVENT UID:1 RECURRENCE-ID:20031217T200000Z END:VEVENT BEGIN:VEVENT UID:1 RECURRENCE-ID:20031218T200000Z END:VEVENT BEGIN:VEVENT UID:1 RECURRENCE-ID:20031219T200000Z END:VEVENT BEGIN:VEVENT UID:1 RECURRENCE-ID:20040102T100000Z END:VEVENT BEGIN:VEVENT Royer Expires: May 2004 [Page 25] Internet Draft iCalendar Scheduling December 27, 2003 UID:1 RECURRENCE-ID:20040103T090000Z END:VEVENT ... END:VREPLY The "RECURRENCE-ID" property values are computed values. CS's or CUA's that have advertised "RECUR-EXPAND" in the CSs "CAPABILITY" reply are the only endpoints that can compute "RECURRENCE-ID" values. The reason that "DTSTART" is not altered or recomputed is because it is not a computed value. "DTSTART" was set by some organizer and MUST NOT be altered outside of [iTIP] negotiations. 6. Delegation Delegation is the act of assigning one attendee to participate in an event in place of the original attendee as described in [iCAL] and [iTIP]. 6.1 One attendee delegates all meeting to another Here 'upn-b@example.com' delegates all of their meetings to 'upn- g@example.com'. The current "SEQUENCE" property value is '3'. User 'upn-b@example.com' still wishes to get copies of the updates, so the "PARTSTAT" parameter value in this delegation is set to the "NON-PARTICIPANT" value and not the "DELEGATED" value per [iTIP] section 3.2.2.3. So 'upn- b@example.com' would send the following object to the organizer: (EXAMPLE 'M') BEGIN:VCALENDAR METHOD:REPLY VERSION:2.0 ... BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;ROLE=NON-PARTICIPANT ;PARTSTAT=DELEGATED Royer Expires: May 2004 [Page 26] Internet Draft iCalendar Scheduling December 27, 2003 ;DELEGATED-FROM="mailto:upn-b@example.com" :mailto:upn-g@example.com ATTENDEE ;DELEGATED-TO="mailto:upn-g@example.com" :mailto:upn-g@example.com DTSTAMP:20031211T195000Z REQUEST-STATUS:2.0;Success END:VEVENT END:VCALENDAR The organizer would compare the "UID", "SEQUENCE" properties (as seen in example 'K') and find that 'upn-b' had already replied to "UID:1" "SEQUENCE:3". So then the "DTSTAMP" property value of "20031211T195000Z" in the "REPLY" method would be compared to the "ACK-DTSTAMP" parameter for the "ATTENDEE" property with the 'upn-b' value. As the "DTSTAMP" value is newer then the "ACK-DTSTAMP" value (and the "UID" and "SEQUENCE" property values are the same), the organizer would know that this is an update from the attendee. At the same time 'upn-b@example.com' would forward a copy of the event information to 'upn-g@example.com' as booked and stored in 'upn- b@example.com' CS adding the "REQUEST" method, and the "DELEGATED-TO" and "DELEGATED-FROM" "ATTENDEE" parameters to create these [iTIP] messages: (EXAMPLE 'N') BEGIN:VCALENDAR METHOD:REQUEST VERSION:2.0 ... BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;DELEGATED-FROM="mailto:upn-b@example.com" :mailto:upn-g@example.com ATTENDEE:mailto:upn-c@example.com ATTENDEE:mailto:upn-d@example.com ATTENDEE:mailto:upn-e@example.com ATTENDEE ;DELEGATED-FROM="mailto:upn-b@example.com" :mailto:upn-g@example.com DTSTAMP:20031211T195100Z DTSTART:20031215T200000Z DTEND:20031215T210000Z Royer Expires: May 2004 [Page 27] Internet Draft iCalendar Scheduling December 27, 2003 RDATE:20040101T100000Z. SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 RRULE:FREQ=DAILY;COUNT=5 END:VEVENT BEGIN:VEVENT UID:1 SEQUENCE:3 METHOD:ADD ORGANIZER:mailto:upn-b@example.com ATTENDEE ;DELEGATED-TO="mailto:upn-g@example.com" :mailto:upn-b@example.com ATTENDEE:mailto:upn-c@example.com ATTENDEE:mailto:upn-d@example.com ATTENDEE:mailto:upn-e@example.com ATTENDEE:mailto:upn-f@example.com ATTENDEE ;DELEGATED-FROM="mailto:upn-b@example.com" :mailto:upn-g@example.com DTSTAMP:20031211T195200Z DTSTART:20040102T100000Z DTEND:20040102T110000Z RDATE:20040103T090000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT Note above that the "ADD" Method has the same "SEQUENCE" property value as the "REQUEST" method object. This is because per [iTIP] 2.1.4, the organizer increments the "SEQUENCE" property values, not the attendees and not when sending a delegation request. The attendee 'upn-g' would notice that the "UID" value was not in the 'upn-g' CS, so this is a new object. By checking the "ATTENDEE" property value for the 'upn-g' entry, then 'upn-g' can tell this is a delegation because the "DELEGATED-FROM" parameter value is present in the "ATTENDEE" property which has the 'upn-g' value. Now 'upn-g@example.com accepts the meeting by sending to both 'upn- b@example.com' and the organizer a "REPLY" method: (EXAMPLE 'O') Royer Expires: May 2004 [Page 28] Internet Draft iCalendar Scheduling December 27, 2003 BEGIN:VCALENDAR METHOD:REPLY VERSION:2.0 ... BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;DELEGATED-FROM="mailto:upn-b@example.com" :mailto:upn-g@example.com DTSTAMP:20031211T195300Z REQUEST-STATUS:2.0;Success END:VEVENT END:VCALENDAR If the objects had been sent using [iMIP] or because 'upn-g' may not be at work until later. The update from 'upn-b' may arrive before or after the 'upn-g' "REPLY" method. The organizer must be prepared to get those object in any order. Now assume that the organizer accepts the delegation. At this point the booked entry in the organizers CS would contain: (EXAMPLE 'P' - the organizers booked entry at this point) # The LA Meetings are unique to 'upn-b' - 'upn-e' and 'upn-g'. BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;ROLE=NON-PARTICIPANT ;PARTSTAT=DELEGATED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T195000Z # Matched example 'M' ;DELEGATED-TO="mailto:upn-g@example.com" :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192200Z :mailto:upn-c@example.com Royer Expires: May 2004 [Page 29] Internet Draft iCalendar Scheduling December 27, 2003 ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192300Z :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-e@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-e@example.com ATTENDEE ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T195300Z # Matched example 'O' ;DELEGATED-FROM="mailto:upn-b@example.com" :mailto:upn-g@example.com DTSTAMP:20031211T210000Z DTSTART:20031215T200000Z DTEND:20031215T210000Z RDATE:20040101T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 RRULE:FREQ=DAILY;COUNT=5 END:VEVENT # The New York Meetings are common to all attendees at this point. BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' Royer Expires: May 2004 [Page 30] Internet Draft iCalendar Scheduling December 27, 2003 ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192100Z :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192200Z :mailto:upn-c@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192300Z :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-e@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-f@example.com ATTENDEE ;ROLE=NON-PARTICIPANT ;PARTSTAT=DELEGATED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T195300Z # Matched example 'O' ;DELEGATED-FROM="mailto:upn-b@example.com" :mailto:upn-g@example.com DTSTAMP:20031211T1210000Z DTSTART:20040102T100000Z DTEND:20040102T110000Z RDATE:20040103T090000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT Royer Expires: May 2004 [Page 31] Internet Draft iCalendar Scheduling December 27, 2003 # Unique to 'upn-f' BEGIN:VEVENT: UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z # Matched example 'L' ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-f@example.com DTSTAMP:20031211T1210000Z DTSTART:20031217T200000Z DTEND:20031217T210000Z RDATE:20040101T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT 6.2 One attendee delegates one instance to another Now 'upn-g@example.com' delegates one instance in a set to 'upn- h@example.com'. Here 'upn-g' can not attendee the 20040103T090000Z meeting so sends a single instance delegation to 'upn-h'. The "RECURRENCE-ID" property is added above so that when 'upn-h' sends a "REPLY" method to the organizer, the the "RECURRENCE-ID" will be added to that "REPLY" method. Then the organizer wil know that 'upn-h' is only beeing delegated to attend that one instance. The following is sent to 'upn-h': (EXAMPLE 'Q') BEGIN:VCALENDAR VERSION:2.0 METHOD:REQUEST ... BEGIN:VEVENT UID:1 SEQUENCE:3 RECURRENCE-ID:20040103T090000Z # Added. ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=DELEGATED Royer Expires: May 2004 [Page 32] Internet Draft iCalendar Scheduling December 27, 2003 ;DELEGATED-TO="mailto:upn-h@example.com" :mailto:upn-g@example.com ATTENDEE ;DELEGATED-FROM="mailto:upn-g@example.com" :mailto:upn-h@example.com DTSTAMP:20031211T200100Z DTSTART:20040102T100000Z DTEND:20040102T110000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT And 'upn-g' sends a "REPLY" to the organizer: (EXAMPLE 'R') BEGIN:VCALENDAR VERSION:2.0 METHOD:REPLY ... BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com RECURRENCE-ID:20040103T090000Z # Added. ATTENDEE ;DELEGATED-FROM="mailto:upn-g@example.com" # to this instance. :mailto:upn-h@example.com DTSTAMP:20031211T200100Z REQUEST-STATUS:2.0;Success END:VEVENT END:VCALENDAR The "RECURRENCE-ID" property must be supplied above in example 'R' or the organizer would think that is it a replacement for the entire set of "UID:1" "SEQUENCE:3" object reply. So by adding the "RECURRENCE-ID" the organizer will know that the "UID:1" "SEQUENCE:3" object that has the instance start time of "20040103T090000Z" is the instance being delegated. Now assume that 'upn-h' and the organizer accept the delegation. At this point the organizer has this information in the organizers CS: (EXAMPLE 'U' - the organizers booked entry at this point) # The LA Meetings are unique to 'upn-b' - 'upn-e' and 'upn-g' Royer Expires: May 2004 [Page 33] Internet Draft iCalendar Scheduling December 27, 2003 BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;ROLE=NON-PARTICIPANT ;PARTSTAT=DELEGATED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T200100Z ;DELEGATED-TO="mailto:upn-g@example.com" :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192200Z :mailto:upn-c@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192300Z :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-e@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-e@example.com ATTENDEE ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T200100Z ;DELEGATED-FROM="mailto:upn-b@example.com" :mailto:upn-g@example.com Royer Expires: May 2004 [Page 34] Internet Draft iCalendar Scheduling December 27, 2003 DTSTAMP:20031211T200100Z DTSTART:20031215T200000Z DTEND:20031215T210000Z RDATE:20040101T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 RRULE:FREQ=DAILY;COUNT=5 END:VEVENT # Entries common to 'upn-b' - 'upn-f'. (not to upn-g or upn-h) BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192100Z :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192200Z :mailto:upn-c@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192300Z :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-e@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z Royer Expires: May 2004 [Page 35] Internet Draft iCalendar Scheduling December 27, 2003 ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-f@example.com DTSTAMP:20031211T200200Z DTSTART:20040102T100000Z DTEND:20040102T110000Z RDATE:20040103T090000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT # Unique to 'upn-f' BEGIN:VEVENT: UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z :mailto:upn-f@example.com DTSTAMP:20031211T200200Z DTSTART:20031217T200000Z DTEND:20031217T210000Z RDATE:20040101T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT # Unique to 'upn-g' # 20040103T090000Z missing as it is delegated to 'upn-h' (below) BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T200100Z :mailto:upn-g@example.com Royer Expires: May 2004 [Page 36] Internet Draft iCalendar Scheduling December 27, 2003 DTSTAMP:20031211T200200Z DTSTART:20040102T100000Z DTEND:20040102T110000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT # The one instance delegated to 'upn-h' # BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=DELEGATED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192400Z ;DELEGATED-TO="upn-h@example.com" :mailto:upn-g@example.com DTSTAMP:20031211T200200Z DTSTART:20040103T090000Z # The delegated date/time DTEND:20040102T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT # Unique to 'upn-h' BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=DELEGATED ;SENT-SEQUENCE=3 ;SENT-DTSTAMP=20031211T192000Z ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T200300Z ;DELEGATED-FROM="upn-g@example.com" :mailto:upn-h@example.com DTSTAMP:20031211T200200Z DTSTART:20040103T090000Z DTEND:20040102T100000Z SUMMARY:Standards Meeting Royer Expires: May 2004 [Page 37] Internet Draft iCalendar Scheduling December 27, 2003 STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT 6.3 The meeting is forwarded to a non-attendee Some uses will need or want to forward copies of event to potential attendees that were not in the original list of attendees sent by the organizer. This is not the same as delegation, this is simply a forward of a copy of a "REQUEST" object. In some cases this will be a desired feature. An example is when one attendee forwards to another an event about a public meeting open to all citizens. And in other cases the meeting is closed and all attempts by uninvited attendees will be rejected or ignored. 6.4 Organizer gets a non-attendee REPLY For each "REPLY" method the organizer receives it should be checked against the invited attendees in the CS. If the attendee that sent the "REPLY" is not in the currently booked object and does not contain a "DELEGATED-FROM" parameter, then the organizer knows that a non invited attendee is requesting to be able to attend the event. Assume that 'upn-b' simply forwards this one meeting to 'upn-i'. They could forward the entire set, or any one or more instances of the set of meetings: (EXAMPLE 'V') BEGIN:VEVENT UID:1 SEQUENCE:3 METHOD:REQUEST ORGANIZER:mailto:upn-a@example.com ATTENDEE:mailto:upn-i@example.com DTSTAMP:20031211T192900Z DTSTART:20040102T100000Z DTEND:20040102T110000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT Royer Expires: May 2004 [Page 38] Internet Draft iCalendar Scheduling December 27, 2003 Now the currently uninvited attendee then sends a "REPLY" method to the organizer: (EXAMPLE 'W') BEGIN:VEVENT UID:1 SEQUENCE:3 METHOD:REQUEST ORGANIZER:mailto:upn-a@example.com ATTENDEE;PARTSTAT=ACCEPTED:mailto:upn-i@example.com DTSTAMP:20031211T192900Z DTSTART:20040102T100000Z DTEND:20040102T110000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT The organizer can choose to accept or decline the new attendee. 6.4.1 Disallow new attendee According to [iTIP] the organizer can ignore the request or send a "CANCEL" to the uninvited attendee. This specification recommends sending the "CANCEL" method and add a "COMMENT" property so that the uninvited attendee can not mistake the lack of reply for a missing, forgotten packet or acceptance: (EXAMPLE 'X') BEGIN:VEVENT UID:1 SEQUENCE:3 METHOD:CANCEL ORGANIZER:mailto:upn-a@example.com DTSTAMP:20031211T192900Z COMMENT:Sorry, it is a closed meeting. LOCATION: New York, building T, room 1200 END:VEVENT And again, the organizer knowing that it is in fact part of a recurring set of entries may or might not add the "RECURRENCE-ID" property to the above object: (EXAMPLE 'Y') Royer Expires: May 2004 [Page 39] Internet Draft iCalendar Scheduling December 27, 2003 RECURRENCE-ID:20040103T090000Z 6.4.2 Allow new attendee According to [iTIP] the organizer simply adds the new "ATTENDEE" to the list of attendees and this means they are accepted At this point the organizer has this information in the organizers CS: (EXAMPLE 'Z' - the organizers booked entry at this point) BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=NON-PARTICIPANT ;ACK-SEQUENCE=3 ;DELEGATED-TO="mailto:upn-g@example.com" ;ACK-DTSTAMP=20031211T192500Z :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T191900Z :mailto:upn-c@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192000Z :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192100Z :mailto:upn-e@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192700Z ;DELEGATED-FROM="mailto:upn-b@example.com" :mailto:upn-g@example.com DTSTAMP:20031211T192800Z DTSTART:20031215T200000Z DTEND:20031215T210000Z RDATE:20040101T100000Z. SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 Royer Expires: May 2004 [Page 40] Internet Draft iCalendar Scheduling December 27, 2003 RRULE:FREQ=DAILY;COUNT=5 END:VEVENT BEGIN:VEVENT: UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192200Z :mailto:upn-f@example.com DTSTAMP:20031211T192300Z DTSTART:20031217T200000Z DTEND:20031217T210000Z RDATE:20040101T100000Z. SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: Los Angles, building B room R1 END:VEVENT BEGIN:VEVENT UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=NON-PARTICIPANT ;ACK-SEQUENCE=3 ;DELEGATED-TO="mailto:upn-g@example.com" ;ACK-DTSTAMP=20031211T192500Z :mailto:upn-b@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T191900Z :mailto:upn-c@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192000Z :mailto:upn-d@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192100Z :mailto:upn-e@example.com ATTENDEE ;PARTSTAT=ACCEPTED Royer Expires: May 2004 [Page 41] Internet Draft iCalendar Scheduling December 27, 2003 ;ACK-SEQUENCE=3 ;ACK-DTSTAMP=20031211T192700Z ;DELEGATED-FROM="mailto:upn-b@example.com" :mailto:upn-g@example.com DTSTAMP:20031211T192300Z DTSTART:20040102T100000Z DTEND:20040102T110000Z RDATE:20040103T090000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT BEGIN:VEVENT: UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=3 ;DELEGATED-FROM="mailto:upn-b@example.com" ;ACK-DTSTAMP=20031211T192200Z :mailto:upn-f@example.com DTSTAMP:20031211T192300Z DTSTART:20040102T100000Z DTEND:20040102T110000Z RDATE:20040103T090000Z EXDATE:20040103T090000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT BEGIN:VEVENT: UID:1 SEQUENCE:3 ORGANIZER:mailto:upn-a@example.com ATTENDEE ;PARTSTAT=DELEGATED ;ACK-SEQUENCE=3 ;DELEGATED-TO="mailto:upn-h@example.com" ;ACK-DTSTAMP=20031211T192200Z :mailto:upn-g@example.com ATTENDEE ;PARTSTAT=ACCEPTED ;ACK-SEQUENCE=3 ;DELEGATED-FROM="mailto:upn-g@example.com" ;ACK-DTSTAMP=20031211T192200Z Royer Expires: May 2004 [Page 42] Internet Draft iCalendar Scheduling December 27, 2003 :mailto:upn-h@example.com ATTENDEE;PARTSTAT=ACCEPTED:mailto:upn-i@example.com DTSTAMP:20031211T192300Z DTSTART:20040103T090000Z DTEND:20040103T100000Z SUMMARY:Standards Meeting STATUS:CONFIRMED LOCATION: New York, building T, room 1200 END:VEVENT The fact that the organizer can choose to allow or disallow the new attendee by doing no over the wire protocol is why this specification suggests that the organizer SHOULD send a "CANCEL" back to any declined new attendee. Without sending a "CANCEL" is would be impossible for the new attendee to know if they are or are not on the meeting list. 7. Changing the time of one or more instances If the organizer needs to change the time of one or more instances to a set of meetings, then the organizer needs to increment the "SEQUENCE" property value and send the new meeting times to the effected attendees. There are two [iTIP] ways this can be done if exactly one meeting time is being changed. A single instance update is a specific type of update that informs the effected attendees of exactly one date/time change. A single instance update is an [iTIP] "3.2.2.1" rescheduling of an object with a "RECURRENCE-ID" property added. The other way is to send out an entire new set of full updates to the effected attendees. These objects do not have a "RECURRENCE-ID" property in the object. There is some debate on how the single instance update effects the "RECURRENCE-ID" values as seen by the attendees. So this specification deprecates the single instance update using the "RECURRENCE-ID" property. This specification suggests that the organizer SHOULD send a full update for any reschedule to avoid the confusion between implementations. In this example three dates have changed and they are; 20031216T200000Z meeting is changing to 20031216T180000Z, 20031217T200000Z meeting is changing to 20031217T180000Z, and the 20031218T200000Z meeting is changing to 20031218T180000Z. Royer Expires: May 2004 [Page 43] Internet Draft iCalendar Scheduling December 27, 2003 In this example the organizer will only send the updates to the attendees that will be effected for each change. The other attendees if sent the new "SEQUENCE" object would be forced to issue a "REPLY" method even when the change did not effect them. That would cause extra bandwidth round trip delays and could cause some confusion to the CU while they try to figure out why the are getting an update that has no effect on them. If the organizer had wished all attendees to see the entire attendee list, then the organizer would have to send the entire update to all attendees and not just those effected by the change. 7.1 Acting on behaif of another This is similar to delegated, except the original attendee will be attending the meeting, it is just that the original attendee may have an administrative assistant perform the scheduling. These are "ATTENDEE" properties with the "SENT-BY" parameter. xxx 8. CANCEL instances xxx 8.1 Instance cancel xxx 8.2 Single instance cancel xxx 8.3 Multiple instance cancel xxx 9. Working with RECURRENCE-ID xxx Royer Expires: May 2004 [Page 44] Internet Draft iCalendar Scheduling December 27, 2003 9.1 RECURRENCE-ID xxx 9.2 RECURRENCE-ID in expanded object xxx 9.3 RECURRENCE-ID in instance change xxx 9.4 REFRESH xxx 9.4.1 Getting ADD with no such UID in attendee CS xxx 9.4.2 REFRESH and single instance updates with RECURRENCE-ID xxx 9.5 COUNTER xxx 9.5.1 When ACK-SEQUENCE and SEQUENCE do not match xxx 9.6 Bibliography [iCAL] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998 ftp://ftp.isi.edu/in-notes/rfc2445.txt [iTIP] Silverberg, S., Mansour, S., Dawson, F. and Hopson, R., "iCalendar Transport-Independent Interoperability Protocol Royer Expires: May 2004 [Page 45] Internet Draft iCalendar Scheduling December 27, 2003 (iTIP) Events, BusyTime, To-dos and Journal Entries", RFC 2446, November 1998 ftp://ftp.isi.edu/in-notes/rfc2446.txt [iMIP] Dawson, F., Mansour, S. and Silverberg, "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 2447, November 1998 ftp://ftp.isi.edu/in-notes/rfc2447.txt [CAP] Royer, D., Babics, G., Hill, P. Mansour, S. "Calendar Access Protocol (CAP)", work in progress, draft-ietf-calsch-cap-12.txt [INVITATION] Royer, D. "How to create dynamic UPNs for invited ATTENDEEs", work in progress, draft-royer-calsch-dynamic-upn-01.txt 10. Author's Address Doug Royer http://INET-Consulting.com 1795 W. Broadway #266 Idaho Falls, Idaho 83402 US Phone: 208-520-4044 Fax: 866-594-8574 EMail: Doug@Royer.com URI: http://Royer.com/People/Doug Royer Expires: May 2004 [Page 46] Internet Draft iCalendar Scheduling December 27, 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than nglish. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Royer Expires: May 2004 [Page 47] Internet Draft iCalendar Scheduling December 27, 2003 Funding for the RFC Editor function is currently provided by the Internet Society. Royer Expires: May 2004 [Page 48]