[13:50:56] eliot.lear joins the room [13:50:57] cyrus leaves the room [13:56:44] cyrus joins the room [13:57:55] hi cyrus [13:57:57] how are you? [13:58:31] alexey.melnikov joins the room [13:58:34] Good. [13:58:37] hi alexey! [13:58:48] hi alexey! [13:58:55] Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: # The IETF plenary session, # Any IETF working group or portion thereof. # The IESG or any member thereof on behalf of the IESG. # The IAB or any member thereof on behalf of the IAB. # Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices. # The RFC Editor or the Internet-Drafts function. All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public. Acknowledge and Continue [13:58:56] Good morning/afternoon [13:58:58] bernard.desruisseaux joins the room [13:59:03] greetings bernard! [13:59:08] Hi guys! [13:59:23] we'll start in just a little bit [14:00:25] by my recollection we need to continue issue 64. is that right? [14:01:18] testing 1 2 3. am i still here? [14:01:26] yes you are [14:02:18] everyone ready to go? [14:02:32] OK. #64 it is. [14:02:37] i realize we don't have reinhold, but i hope he'll join us soon [14:02:48] Sec. 3.4.5 (p.48): ≫When a VTODO is cancelled≪ Does this mean only when the whole VTODO (with all its recurrence instances) is cancelled, or does it mean whenever a CANCEL is sent, in particular also when only a single ATTENDEE is unassigned? The same holds for VEVENT (p.26). [14:04:24] so- first of all, cyrus, do you understand rainhold's question [14:04:26] ? [14:04:54] So the issue of whether SEQUENCE is required to be bumped on a CANCEL is controversial. I don't believe we will ever get agreement on this. Maybe the best thing is to add an "interop" note stating that some clients always bump it, others do not. [14:05:27] hang on a sec. i don't know how we got into a discussion of SEQUENCE. [14:06:01] i'm not sure i understand his question. [14:06:07] Look at section 2.1.4 - it states clearly that sequence is bumped for a CANCEL or ADD. [14:06:16] yes [14:06:48] Reinhold is making reference to: When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be incremented. [14:06:56] I think his issue is with the wording "When a VTODO is cancelled" - specifically use of "cancelled" vs CANCEL. [14:07:43] ok, i think we need to clarify with him, because i am not convinced that his issue has to do with the sequence #. [14:07:53] The text ought to be: "As per section 2.1.4, when a CANCEL message is sent for a VTODO component, the SEQUENCE property of that component MUST be incremented." [14:07:56] i thought he had confusion about the cancellation function [14:08:23] and devolving back to whether one needed to a single or multiple cancellations [14:08:36] however, i could be wrong [14:08:38] There are several ways a component can be "cancelled". Same is true for an "addition". [14:08:44] right [14:09:19] i see [14:09:21] hang on a sec [14:09:31] Maybe section 1.4 could expand a bit on all the ways a cancellation (lower case) can be done with the various METHODs. [14:09:51] let's not speculate on this one. cyrus, can you send him an email and copy the list? [14:09:58] OK. [14:10:16] cyrus: if you remove an attendee are you required to bump sequence? [14:10:22] ok, then let's please move next to issue 67 [14:10:26] bernard, the text says so [14:10:32] or seemingly does [14:10:35] wait [14:10:38] that's if you cancel [14:10:43] right :-) [14:10:46] If you send a CANCEL you have to bump the sequence. [14:11:13] Issue 67 [14:11:14] If the counterproposal only contains some minor modiﬁcations (e.g. correcting typos in the description), does the Organizer still have to send the REQUEST to all Attendees and set RSVP=TRUE? [14:11:15] You could remove an Attendee and send them a REQUEST with their new "view" of the event - then sequence would not have to be bumped! [14:11:44] cyrus: that's why I'm asking... but I believe this would be wrong... This should be clarified... [14:11:51] I'm okay to move on [14:11:51] this comes back to the UI discussion we had previously, and it would seem to me that the same logic for that applies here [14:12:25] can we apply that same logic here by reference? [14:13:23] The current text says that the Organizer SHOULD reset RSVP to TRUE. [14:13:39] I think that is sufficient. i.e. I don't see any need to change what is there now. [14:14:08] right. but while i am woefully unqualified to represent reinhold, let me try for the moment [14:14:27] Humm... [14:14:30] Maybe: "The Organizer SHOULD set RSVP to TRUE if a significant change has occurred to cause a re-schedule of the vtodo". But then we run into the situation of what "significant" is. [14:15:03] what is the fundamental difference between a VTODO and a VEVENT? [14:15:13] Actually, I don't believe there should be any statement here.... [14:15:34] If the Organizer accept the counter then he will accept it... that's it... [14:15:49] Then... once it's accepted... the same rule apply as if the Organizer did the change on his own.. [14:16:08] The text in 3.2.7 for VEVENT says nothing about RSVP. Should we simply adopt that? i.e. no difference between VTODO and VEVENT? [14:16:09] Same business apply, if it's a significant change bump sequence etc. etc... [14:16:32] if that works in practice [14:16:38] i could also argue the other side [14:16:51] that is- EVERYTHING in a VTODO is important to the person being assigned [14:16:52] In short, I don't understand why we need to futher specify what happens here when the COUNTER is accepted [14:17:25] so first help me understand whether i am grasping the issue correctly [14:17:32] and then tell me which way you think fits [14:17:36] or correct me ;-) [14:17:52] I don't see why a VTODO is different from a VEVENT. [14:19:26] i think Reinhold's point is that if the change is not significant, why require anything in addition? and does the RSVP=TRUE have to involve all attendees? [14:19:29] What we need is a general statement about when it is appropriate to set RSVP=TRUE. e.g. in 3.4.2.1. [14:20:20] cyrus, if we think about how VTODO is used, do the COMMENTs generally contain work assignments that others might need to know about it? [14:20:41] that is the only reason i wonder whether this is more specific to VTODO than general [14:20:59] alexey and bernard, please chime in as well [14:21:08] VTODO's in iTIP are not used all that often. I don't think Outlook event supports it at all. Bernard can comment more. [14:21:52] Apple iCal doesn't support task assignment. Outlook doesn't support VTODO at all. [14:22:48] bernard, what about @ oracle? [14:23:07] I have the feeling that both the COUNTER section for VEVENT and VTODO have been written with the idea that COUNTER was only used to request a reschedule... [14:23:15] It's not... COUNTER can be used for anything... [14:23:19] and it's always fair to say, "i'd rather not say" or "i don't know" [14:24:06] what i would suggest for this question is an answer that says something along the lines of one of the following: [14:24:13] I'm my opinion, for both VEVENT and VTODO we should simply say that if the Organizer accepts the COUNTER ... then he changes the component... and then does whatever he would have been required to do if he had done the change on his own... that's it! [14:24:37] oo [14:24:39] nice text [14:24:46] cyrus? [14:24:53] That is pretty much what the VEVENT text already says. i.e. we should just make VTODO say the same thing. [14:25:02] Eliot: Oracle OCS 10g supports VTODO but not task assignement. Oracle Beehive supports VTODO and task assignment. [14:25:04] it's not very prescriptive, but then this is a fuzzy area [14:25:24] ok, so then cyrus, we'll run with what you suggest if that's okay [14:25:34] So for #67 I will just make VTODO text the same as VEVENT. [14:25:52] Cyrus: Section 3.2.7 says: The "Organizer" accepts the counter proposal by rescheduling the event as described in section 3.2.2.1 Rescheduling an Event. [14:26:03] ok [14:26:08] Issue 70, please [14:26:09] 70. Sec. 3.4.8 (p.55): What does the comment for ATTENDEE mean? Does it mean that in a DECLINECOUNTER the Organizer has to insert all original Attendees? [14:26:17] Section 3.2.7 needs to be more generic... [14:26:34] Perhaps that has already been addressed by other issues raised by Reinhold [14:27:07] #40 dealt with re-wording 3.2.7. [14:27:17] issue 70, please [14:27:47] why do other ATTENDEES even know of the COUNTER? [14:27:58] question is about: VTODO 1 ATTENDEE 1+ MUST for all attendees [14:28:00] right? [14:28:04] yes [14:28:12] On #70 - look at the DECLINECOUNTER tables for VEVENT and VTODO. Why are they so different? [14:28:23] It should be ATTENDEE 1 [14:28:31] bernard, right [14:28:46] e.g. VEVENT DECLINECOUNTER has ATTENDEE 0 [14:29:06] that should be 1 as well, right? [14:29:10] Right! [14:29:22] cyrus? [14:29:35] Well... I would vote for 1... but then 0 would work too... [14:29:57] Could be 0 or 1. Strictly speaking there is no need to include ATTENDEE as the DECLINECOUNTER only goes back to the one person that sent the COUNTER in the first place. [14:30:11] With '0' the Attendee ends up being specified as a Recipient of the iTIP message and is not listed in the iTIP messages [14:30:57] that's an argument for 1. [14:31:16] why do you say so? [14:31:20] It would be better to have 1. How about "0 or 1 - SHOULD be present and set to the cuaddr of the Attendee that sent the COUNTER to which the DECLINECOUNTER message is replying to". [14:31:54] The SHOULD gives us backwards compatibility for VEVENT at least. [14:32:03] bernard, having the attendee not be present in the iTIP message sounds like a recipe for all sorts of confusion [14:32:31] reinhold joins the room [14:32:45] i've seen at least one implementation in which if you're not listed, the message doesn't get processed [14:33:05] so this is why i like cyrus' approach [14:33:11] Hi all! [14:33:13] eliot: Yes, on a REQUEST that would be a problem. [14:33:15] hello reinhold! [14:33:39] I'm also okay with Cyrus approach. As long as VEVENT and VTODO have the same requirement with respect to ATTENDEE. [14:33:45] Hi Reinhold [14:33:52] Which issue are you discussing? [14:33:58] we are now on 70 [14:34:01] (And sorry for being late) [14:34:16] we will go back to one of the earlier issues after this because we had a question [14:34:24] but first, are we resolved on 70? [14:34:29] (I think we are) [14:34:39] I am happt to have ATTENDEE be 0 or 1 with my text. [14:34:41] I think we are [14:34:46] ok [14:34:55] let's please return to issue 64 [14:35:01] But the VEVENT and VTODO tables are still very different. [14:35:05] Cyrus: Please mention that 0 is simply there for backward compatibility though [14:35:07] Not finished on #70 yet. [14:35:19] bernard, +1 [14:35:32] cyrus, ack? [14:35:45] VEVENT DECLINECOUNTER has the bare minimum properties required and all others set to 0. VTODO has the others as optionaly Why the difference? [14:36:15] i agree with you that at least the ATTENDEE properties should match [14:36:18] Bad copy'n'paste is probably the answer! [14:36:23] ;-) [14:36:33] reinhold, this was a good catch [14:36:37] My proposal is to make VTODO look exactly like VEVENT. [14:36:40] Tables that is. [14:36:52] all: please comment [14:37:50] ? [14:37:59] I don't like the fact that currently you are forbidden to specify what exactly you are decline-countering in a VEVENT [14:38:23] UID is there. You can correlate with that. [14:38:29] Nope! [14:38:35] What if I sent two COUNTER? [14:38:37] | COMMENT | 0+ | [14:38:54] Well now we are back to your issue with COUNTER in general. We can't address that. [14:38:58] COMMENT:Sorry I can't at the time you proposed [14:39:11] cyrus: right [14:39:16] but that may be worth addressing [14:39:21] after we are done with this list [14:39:28] Ah, that's indeed a good catch, too. [14:39:55] what i propose, actually, is this: [14:40:05] counter to what i just said... [14:40:11] it seems to me that we need to reconsider COUNTER [14:40:24] and that it's not worth piddling around with just the EVENT table [14:40:27] No puns please! [14:40:41] and specifically Bernard's concern [14:40:43] that's homework [14:40:52] Cyrus, can you take up the charge? [14:41:19] and specifically address Bernard's concern about what to use as a key when there are two COUNTERs in flight from the same ATTENDEE? [14:42:02] Well what I propose is this: I will change ATTENDEE to 0 or 1 in the VEVENT table, and make the rest of the VTODO table the same as VEVENT (i.e. set all the other props to 0). Then Bernard can bring up the general issue of COUNTER on the list once I publish a new draft. If there is consensus to deal with that we can do another round of changes. [14:42:21] I still don't think Bernard's point is a big concern. [14:42:35] Hold on! [14:43:01] I will not push to get a perfect correlation between COUNTER and DECLINECOUNTER... [14:43:03] but... [14:43:20] In my opinion it should be allowed to specify property values in the DECLINECOUNTER response... [14:43:41] Bernard: can you make a proposal for table changes? [14:43:43] if the properties are specified than they should be set to the values that were COUNTERed... [14:43:59] Ah, OK. [14:44:06] Proposal: Make VEVENT's table more like VTODO's table... [14:44:16] that's good but fuzzy [14:44:27] can you send the list a table? [14:44:31] should take you 1 minute [14:44:45] Exact. Not perfect. Not a big change and perhaps good enough... and more in line with what implementors will leverage [14:45:06] and at the same time address Reinhold's concern by correcting the comment? [14:45:11] I can go with making VEVENT like VTODO (plus the ATTENDEE change to 0 or 1). [14:45:19] Good. [14:45:31] No action item for me then! RIght? [14:45:34] then we should be able to close this out, but i'd like the table on the list. [14:46:07] bernard, you said "more like" but i don't know what that means specifically [14:46:21] I don't think we need the whole table to the list. Just a comment that we are making them consistent. [14:46:22] and so, please just take the VTODO table, cut, paste, edit, and send [14:46:42] Actually if sending to the list, both VEVENT and VTODO need to be sent. [14:46:48] indeed [14:47:07] that way we won't have to revisit this issue [14:47:18] which i think we can all agree would not be fun [14:47:22] Cyrus: what about the clarification that if the properties are specified... then their value must be the one that was COUNTERed? [14:48:39] must or MUST? [14:48:45] Agreed they must match the COUNTER. That probably needs to be in text above rather than on each one in the table? [14:49:01] seems so [14:49:47] but, euh, can one use COUNTER to suggest the addition or removal of ATTENDEEs? :-) [14:50:09] Poo! You are a trouble maker! [14:50:32] shit disturber I think would be more accurate :-( [14:50:46] yeah. and that seems very possible. ok, first let's resolve Reinhold's key issue. [14:50:57] Bernard, i still think it is to you to send a table for VEVENT and VTODO [14:51:15] that would help us understand exactly what you are asking for [14:51:43] but i think you've just pointed out that there really is no way to say what within the VEVENT or VTODO you are countering [14:51:59] bernard, can you agree to send the text? [14:52:06] Bernard I can send you the current XML if you would prefer to edit that and generate tables. [14:52:17] just a snippit, tho cyrus [14:52:37] I'm okay to simply work with the TXT version... [14:52:48] OK. [14:52:50] ok. [14:53:08] before we go back to issue 64, please know that i will be requesting additional jabbers [14:53:11] But then... I'm not sure what I'm asking for would work... because of ATTENDEEs... [14:53:13] we're going to run out of time [14:53:44] a single consistent recommendation that you think WOULD work would suffice ;-) [14:53:57] returning to issue 64 [14:54:00] Unless we make ATTENDEE 1+ [14:54:16] Reinhold, can you please explain what you meant here [14:54:18] Eliot: :-) lol [14:54:25] Sec. 3.4.5 (p.48): ≫When a VTODO is cancelled≪ Does this mean only when the whole VTODO (with all its recurrence instances) is cancelled, or does it mean whenever a CANCEL is sent, in particular also when only a single ATTENDEE is unassigned? The same holds for VEVENT (p.26). [14:55:06] The idea is to allow the DECLINECOUNTER to specify the data that was not accepted... [14:55:21] That is, repeat the exact same thing as in the COUNTER [14:55:22] There is the sentence in the paragraph about CANCEL for VTODO: " When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be incremented." [14:55:35] as such the DECLINECOUNTER table would be identical to the COUNTER table! Easy! [14:55:51] bernard: good [14:56:07] ok, so cyrus, you were 100% correct as to Reinhold's meaning [14:56:16] In this context, is "cancelled" to be understood as "the task has been completely cancelled" or as "there is a CANCEL message sent". I.e. if one removes only one attendee, is it also A MUST that the SEQUENCE must be incremented. [14:56:26] and you had a textual suggestion [14:56:59] Reinhold, section 2.1.4 states that any use of CANCEL requires SEQUENCE to be bumped - so yes even removal of one attendee. [14:57:27] Okay, so why do we need that sentence in 3.4.5 then? [14:57:35] My proposal is to have text referring back to section 2.1.4. [14:58:02] "As noted in Section 2.1.4, when a CANCEL method is used, the SEQUENCE property value MUST be incremented." [14:58:17] reinhold? [14:58:24] Sounds good. [14:58:29] moving on [14:58:34] issue 95 [14:58:36] That would replace the whole paragraph. And it would be used in VEVENT as well. [14:58:50] Sec. 4.4.7 (p.93f ): It would be very helpful if the comments included an explanation how the added times are added to the original VEVENT. In particular, a single event is added by 11 adding its DTSTART as an RDATE to the original event, possibly with another VEVENT using RECURRENCE-ID to modify some of its properties if the properties of the ADD diﬀered from the original event. Similarly, another recurring event can be added by either modifying the existing RRULE or adding a second RRULE (however, rfc2445bis deprecates the use of two RRULEs for a calendar component!). However, it is not clear how one should proceed if the added recurring event diﬀers from the original event (e.g. has a diﬀerent LOCATION like the second example of this section). As explained in 30, the second example adds another recurrence rule to an event with an already existing recurrence rule, but the added event has a diﬀerent LOCATION than the original event. The PUBLISH example, which is claimed to be equal to the REQUEST and the subsequent ADD, however, ignores this changed LOCATION property value and only uses the LOCATION property value of the original event. It should be clariﬁed if changed property values in the ADD should really be ignored or not. If not, this case with an added recurrence needs to be explained further (whether and how it can be represented in iCalendar at all!). [14:59:59] First off our proposal for #30 actually makes the examples wrong, as the ADD includes an RRULE and we no longer allow that. [15:00:01] Basically the same as #30. Since we clarified that RRULE and RDATE are not allowed, this section needs to be adjusted. [15:00:22] cyrus, would you take a stab at this on list? [15:00:40] actually, could you take a stab at this one and the rest on list? [15:00:51] the further we get in email, the fewer jabbers we need ;-) [15:01:41] otherwise we are adjourned for today [15:01:44] I think we need to confirm #30 on the list first. If everyone agrees to that then fixing the example can be done as part of the draft update for #30. [15:01:50] ok [15:01:57] i sent a summary earlier [15:02:04] thanks everyone! [15:02:26] eliot.lear leaves the room [15:02:31] Bye [15:02:38] cyrus leaves the room [15:02:44] Bye [15:02:49] alexey.melnikov leaves the room [15:02:55] bye [15:02:59] bernard.desruisseaux leaves the room [15:10:01] bye [15:10:08] reinhold leaves the room