Application Working Group Doug Royer/INET-Consulting LLC Internet Draft September 3, 2003 Expires: February 2004 RECURRENCE-ID in iCal draft-royer-rid-ical-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 February 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. ABSTRACT The initial version of this draft are going to be controversial. The idea is to develope ways to make the various ways of using the [iCAL] and [iTIP] "RECURRENCE-ID" property work between vendors. 1. Definitions The following definitions will be used in this memo: update Within this memo 'update' means a change to an object *without* modifying, addition, or deletion any of DTSTART, DTEND, RRULE, RDATE, EXRULE, or EXDATE. reschedule Within this memo 'reschedule' means a change to an object that Royer Expires: February 2004 [Page 1] Internet Draft RECURRENCE-ID in iCal September 3, 2003 does modify, add, or delete any of DTSTART, DTEND, RRULE, RDATE, EXRULE, or EXDATE. These also include objects with and without RECURRENCE-ID in the object. single instance reschedule This means an object that is METHOD:REQUEST with a RECURRENCE- ID property value set to an existing instance known to the "Attendee". full update An object sent that causes one or more GUI instances to be replaced and is a complete replacement for the object. 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 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. Royer Expires: February 2004 [Page 2] Internet Draft RECURRENCE-ID in iCal September 3, 2003 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. 2. Currently Perceived Models This is an attempt to summarize the views sent on the CALSCH working group mailing list (the WG). There are claims that there are two basic camps; "fixed" (F) and "changing" (C) RECURRENCE-IDs. However I think after re-reading the hundreds of emails that there are several variations of the "fixed" camp. There also some that think that how you invite an "Attendee" is related to the RECURRENCE-ID issue. INITIALLY I AM NOT GOING TO FILL IN THE EXAMPLES FOR VIEWS THAT I DO NO HOLD SO AS NOT TO MISREPRESENT THOSE VIEWS. I WILL ADD EXAMPLES AS SENT TO ME OR THE WG AND I WILL FILL IN THE BLANKS. I INVITE OTHERS TO SUBMIT DETAILS, EXAMPLES, AND OTHER MISSING VIEWS!!! 3. Fixed (F) The fixed model seems to be that the RECURRENCE-ID is fixed to the effective start date of the original object. There seems to be some confusion as to what the term 'original' means. Some seem to imply that it means the SEQUENCE:0 object (F-S0), others imply that a full update resets the instances to a new 'original' set (F-U). Some in the F camp think that you have to send out the original SEQUENCE:0 object to all "Attendees" and then send them a series of single instance reschedules in order for a newly invited "Attendee" to be invited. This sequence may or might not include METHOD:ADD objects. (F-S0-SERIES) Some think that a SEQUENCE:0 followed by 'U' reschedules results in a GUI pattern that does not necessarily equal a SEQUENCE:U object GUI pattern. There have been statements that they are not equivalent. I am not sure if all in the F camp think that is true. (F-!EQUIV) Royer Expires: February 2004 [Page 3] Internet Draft RECURRENCE-ID in iCal September 3, 2003 There have also been assertions that if the GUI pattern changes in a conflicting way that you have to cancel all GUI instances for that UID and re-issue a new UID object (F-CANCEL). This breaks down into to more camps; (1) those that think that you have to send a series of cancels, the SEQUENCE:0 CANCEL followed by series if instance CANCELs that would replicate the original series as described in F-S0-SERIES, and (2) those that think that you can send a METHOD:CANCEL object that has recurrence rules that describe the GUI pattern that is to be canceled. 3.1 Fixed Issues with 3rd Party Invitations. There have been posts that claim that the changing model can not work with DELEGATED object. 3.2 Fixed Example Usages **I would like to get a sequence of transactions as [iCAL] objects for each of the above views.** This will be added after the WG thinks that the "Fixed (F)" ( (See Section Page ) ) section is accurately described. 3.2.1 F - Single instance reschedule I think this is the same in both models, that is send an iTIP 4.4.2 object? 3.2.2 F - Full Update Two camps here, (1) send the new object which is the same as the 'C' camp, or (2) CANCEL all of the objects and then re-issue a new UID. 4. Inviting an Attendee There seems to be some that think that this is related to RECURRENCE-ID usage. Some think that if you add RECURRENCE-ID to a REQUEST object that it is sometimes an invitation to a single instance. Others feel that there does not need to be another specific way to invite an "Attendee" a single instance. 4.1 New Invitation Needed Those that think that there needs to be a unique way to invite an "Attendee" to a single instance of an existing UID have failed to submit Royer Expires: February 2004 [Page 4] Internet Draft RECURRENCE-ID in iCal September 3, 2003 any justification for the need for a new way to invite "Attendees". My guess is that they feel that all "Attendee"s must have an exact same copy of the object for a UID. Which seems odd because the entire purpose they declare for this need precludes that they are going to have an exact copy of the object. As they just get an object with RECURRENCE-ID and not an exact copy. Other arguments seem to be that they do not want to track who gets what objects. Yet again they have no problem knowing that when they need to send the single instance invitation with RECURRENCE-ID or any updates to that "Attendee". Although no answer has been submitted, it is my guess they think you have to send the "Attendee" a REQUEST with a RECURRENCE-ID followed by multiple METHOD:ADD object to invite them to multiple instances, or perhaps they think you have to send multiple REQUEST objects each with a RECURRENCE-ID. 4.1.1 Invite to a Single Instances This example shows how this camp thinks you should add an "Attendee" to exactly one instance of an existing UID using REQUEST/RECURRENCE-ID. 4.1.2 Invite to exactly Multiple Instances - with RECURRENCE-ID This example shows how this camp thinks you should add an "Attendee" to exactly more than one and less than all instances of an existing UID using multiple REQUEST/RECURRENCE-ID objects. 4.2 No new Invitation Needed Those that think that there is no need for a new way to invite an attendee fell that you just send the effected "Attendee"s object that contain the one or more instances they are requested to attend. They point out that this allows the "Organizer" CUA to not have to generate multiple REQUEST/RECURRENCE-ID objects or one REQUEST/RECURRENCE-ID object followed by multiple ADD objects to invite that "Attendee" to more than one but less than all GUI patterns as seen by the "Organizer". Royer Expires: February 2004 [Page 5] Internet Draft RECURRENCE-ID in iCal September 3, 2003 4.3 Invite Attendee Examples This section describes how to invite new "Attendees" to existing objects using the procedures described in [iTIP]. 4.3.1 Invite to Exactly One Instance - one object This example shows how this camp thinks you should add an "Attendee" to exactly one instance of an existing UID with no RECURRENCE-ID used. For a existing UID that has 5 instances, Monday, Tuesday, Wednesday, Thursday, and Friday and you with to invite the new "Attendee" to the Tuesday meeting. Assume the "Organizer"s view is SEQUENCE:10 of the object when the "Organizer" first wishes to invite the "Attendee". Send the Attendee: SEQUENCE:11 DTSTART:...Tuesday ATTENDEE...:newUser ..rest of VEVENT data 4.3.2 Invite to multiple Instance - one object This example shows how this camp thinks you should add an "Attendee" to more than one and less than all instances of an existing UID with no RECURRENCE-ID used. For a existing UID that has 5 GUI instances, Monday, Tuesday, Wednesday, Thursday, and Friday and you with to invite the new "Attendee" to the Tuesday and Thursday meetings. Assume the "Organizer"s view is SEQUENCE:10 of the object when the "Organizer" first wishes to invite the "Attendee". Send the Attendee: SEQUENCE:11 DTSTART:...Tuesday... RDATE:...Thursday... ATTENDEE...:newUser ..rest of VEVENT data 5. Changing Model (C) The changing model has declared that SEQUENCE:0 followed by U updates is equivalent to the SEQUENCE:U object. So that it does not matter how the "Attendee" got to SEQUENCE:U because the net result is that SEQUENCE:0 plus U reschedules both replicate the exact same GUI pattern for the "Attendee". Royer Expires: February 2004 [Page 6] Internet Draft RECURRENCE-ID in iCal September 3, 2003 5.1 Changing Example Usages 5.1.1 C - Single instance reschedule This example shows how this camp thinks you should do a single instance reschedule For a existing UID that has 5 GUI instances, Monday, Tuesday, Wednesday, Thursday, and Friday all at 1pm. And you wish to change the Friday GUI instance to 2pm. The last object sent by the "Organizer" was SEQUENCE:10 SEQUENCE:11 RECURRENCE-ID:...Friday...1pm DTSTART:...Firday...2pm ..rest of VEVENT data 5.1.2 C - Full Update This example shows how this camp thinks you should do a single instance reschedule For a existing UID that has 5 instances, Monday, Tuesday, Wednesday, Thursday, and Friday all at 1pm. And you wish to change them all to 2pm. The last object sent by the "Organizer" was SEQUENCE:10 SEQUENCE:11 DTSTART:...Monday...2pm RRULE;FREQ=DAILY;COUNT=5 ..rest of VEVENT data 5.2 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 (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 Royer Expires: February 2004 [Page 7] Internet Draft RECURRENCE-ID in iCal September 3, 2003 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 6. 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: February 2004 [Page 8] Internet Draft RECURRENCE-ID in iCal September 3, 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: February 2004 [Page 9] Internet Draft RECURRENCE-ID in iCal September 3, 2003 Funding for the RFC Editor function is currently provided by the Internet Society. Royer Expires: February 2004 [Page 10]