[08:34:57] veikko.punkka joins the room [08:35:41] veikko.punkka leaves the room [14:38:02] eliot.lear joins the room [14:40:52] alexey.melnikov joins the room [14:41:06] Hi Eliot [14:41:19] hi Alexey! how are you? [14:41:39] Busy coding :-) [14:41:46] of course [14:42:26] I just returned from FOSDEM/XMPP Summit on Monday evening [14:42:33] How are you? [14:43:23] things are good. busy wondering whether IETF will survive [14:43:41] attendance at minneapolis was way down [14:44:23] I am really hoping that IETF will survive [14:44:28] me too [14:45:56] Please see http://trac.tools.ietf.org/wg/calsify/trac/raw-attachment/wiki/RFC2446bis/Review_RFC2446bis_2008-09.pdf [http://trac.tools.ietf.org/wg/calsify/trac/raw-attachment/wiki/RFC2446bis/Review_RFC2446bis_2008-09.pdf] [14:49:05] 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. [14:53:13] now it's snowing! [14:56:21] bernard.desruisseaux joins the room [14:56:29] hi bernard! [14:56:31] how are you?! [14:56:53] I'm fine, and you? [14:57:05] doing well. enjoying a snow storm at the moment [14:57:15] we obviously need to wait for cyrus [14:57:56] Hi Bernard [14:58:30] Hi Alexey! [14:58:38] Speaking of snow storms: I am so happy that snow in London has melted. Snow in London is a wrong thing ;-) [14:58:59] you guys aren't happy unless you have rain [14:59:11] right [14:59:35] Yes, I very much like rain :-) [14:59:53] you must, judging your locale ;-) [14:59:57] I like snow too, but elsewhere - Moscow, Canada, Alpes, etc... [15:00:08] moscow is too cold [15:00:18] good place for an ietf, except it's expensive! [15:00:24] cold AND expensive! [15:00:25] cyrus joins the room [15:00:34] hi cyrus and welcome! [15:00:41] Hi Cyrus [15:00:56] Just in time to save us from the talk about weather ;-) [15:01:07] Hi - so for some reason your invite for Wednesday got cancelled on my calendar when the Friday one came in. So much for iTIP interoperability! [15:01:28] indeed! and that was generated with iCal! [15:01:43] ;-) [15:01:52] we'll wait just until 5 after the hour [15:03:15] If people have not done so already, please download copies of the docs off the wiki - http://trac.tools.ietf.org/wg/calsify/trac/wiki/RFC2446bis [15:03:25] The Review and Issues pdfs. [15:03:40] and #include ;-) [15:04:21] Speaking of which we are in somewhat of a bind wrt the new IPR rules given that we are updating old specs. Will have to figure out what we can do about that. [15:04:37] Truely an ugly mess! [15:04:45] i have not sent anything to the list because I hope the matter resolves itself within the month [15:05:13] but authors, my recommendation is that you hold off on new versions until that has happened [15:05:17] reinhold joins the room [15:05:25] Greetings Reinhold! [15:05:30] Hi all! [15:05:43] ok, it's time to begin. [15:05:47] Hi Reinhold! [15:06:06] hi [15:06:06] i would like to start by saying that this meeting must end promptly at the top of the hour, sadly. [15:06:17] all decisions are only final on the mailing list [15:06:23] i will post minutes from this session [15:06:55] now, i would propose that we go down the issues that cyrus has highlighted from reinhold's list [15:07:05] starting with #25 [15:07:10] does that work with you cyrus? [15:07:25] Sure [15:07:32] any objections? [15:07:47] Fine with me ;-) [15:07:51] ok, please proceed cyrus [15:09:02] Sec. 3.2.2.6 (p.21): How does the uninvited CU find out whether the Organizer added him/her or not. The draft only says that the Organizer MAY send a CANCEL if he rejects the new Attendee. However, if he does not, then the uninvited Attendee has no way of knowing whether he was added or not. A sentence should be added clarifying this situation. Should the uninvited CU simply send a REFRESH to the organizer? If he does not get a response there either, he can deduce that he was not added (see Sec. 6.1.6) [15:09:09] #25 is about forwarding an invite to an uninvited Attendee. [15:09:49] right5 [15:09:52] It does not state clearly how the new attendee gets to know they really were added to the event. [15:10:25] reinhold's suggestion is to send a REFRESH [15:10:39] I think this one is simple: we add a statement that the "Organizer SHOULD send out an iTIP REQUEST to at least the new Attendee to inform them that they have been accepted into the event". [15:10:58] reinhold? [15:11:02] Well, the problem with REFRESH is that it is not automatic, so the uninvited CU has to do some manual operations. [15:11:14] I think the onus should be on the Organizer to send out a REQUEST given that the Organizer has to send out a CANCEL when refusing. [15:11:29] I think the REQUEST (with RSVP set to false?) would be the most sensible solution. [15:11:43] cyrus? [15:11:44] others? [15:12:01] it sounds like there is some agreement on REQUEST [15:12:14] The organizer MAY send out a CANCEL when refusing... [15:12:29] does that work for everyone? [15:12:54] Yes, for accepted answers, a REQUEST is sent, for declined answers by uninvited CUs a CANCEL MAY be sent. Makes sense to me. [15:13:10] cyrus? [15:13:28] Use of REQUEST make sense to me [15:13:34] I agree. Same solution applies for other "forwarding" text such as 3.4.2.4. [15:13:42] ok! [15:13:44] done [15:13:48] The only thing that might be mentioned is whether the RSVP should be set to a specific value. After all the organizer already has a positive answer, so he does not need another answer [15:14:02] indeed [15:14:09] the next issue is issue 30 [15:14:11] I've re-read section 3.2.2.6 and unless I'm missing something [15:14:13] Question though: is it a "SHOULD" to send the REQUEST or a "MAY", given that the CANCEL is MAY. [15:14:34] the text doesn't say how the Organizer A gets to know that Attendee B as forwarded the REQUEST to the uninvited Attendee C... [15:14:52] definitely a SHOULD (otherwise the uninvited CU will again not know if he was added). [15:15:17] bernard: what's the concern? [15:15:19] The text only specify that Attendee B "may" (lower case?) invite another uninvited CU by forwarding the request... [15:16:07] bernard.desruisseaux: yes, the organizer might not even know where the uninvited CU got the invitation from. Therefore he is also free to simply ignore it. However, if he accepts it, the CU should be notified. [15:16:31] It seems we're concerned about what the Organizer should send to the unvinted CU... but it is not clear to me when/how the Organizer was nofied of the request being forwarded... [15:16:41] Bernard - yes there is no way to specify who did a forward. Adding that capability would be a new feature. [15:17:01] Not sure we want to go there... [15:17:08] the issue at hand is that attendee B has responded, and not how the attendee got the invite [15:17:15] and no we shouldn't get off the point [15:17:22] we've got a lot of issues to cover in a little time [15:17:29] let's please move to issue 30 [15:17:40] Sec. 3.2.5 (p.24f ): I don’t understand how ADD should work exactly. rfc2445bis says that an instance of an event is identified by the UID and the RECURRENCE-ID. If we don’t allow a RECURRENCE-ID, how does the resulting sequence of events look in iCalendar notation (i.e. what would the Organizer send in response to a REFRESH)? I suppose it would work to add the additional date as an RDATE or a second RRULE, but only if none of the other properties is different from the original event. Sec. 4.4.7 gives an example of this case (but since it does not point out that an RDATE was added, it is very hard to figure out how the ADD was handled). If some properties are different for a single ADDed event, this can still be represented as an added RDATE and a second VEVENT using RECURRENCE-ID to specify the added instance. However, if an ADD message tries to add a recurring event with some property values different from the original (already recurring) event, then I simply don’t see how this can be represented in iCalendar. RECURRENCE-ID;RANGE=THISANDFUTURE can not be used, because the change should only apply to the instances of one RRULE, not of both. 5 An example of this problem is the first example in Sec. 4.4.7: The original RRULE recurs on TU in ≫The White Room≪. The ADD message adds a second rule on TH, but the location is now ≫The usual conference room≪ (see also issue 95). I don’t see how these two combined can be properly represented in the same event in iCalendar. The example says that they are equivalent to the REQUEST given in Sec. 4.4.7, but that REQUEST seems to ignore the different LOCA- TION property value of the ADD. I think it should be clarified, how such colliding messages should be handled. In particular, do all other property values except DTSTART, RDATE and RRULE have to coincide with the original REQUEST? If not, we should clarify how that case can be handled (i.e. either discard all information from the ADD, which does not coincide? Or try to merge them as much as possible? Or simply disallow adding recurring events to an already recurring event with different properties.) The same clarification is needed for VTODO (p.47) [15:18:13] OK, so #30 I have already fixed. [15:18:16] In my opinion the text should start with "when Organizer gets a REPLY from an uninvited Attendee".... [15:18:32] if you have a fix, cyrus, my mistake. [15:18:43] let's please move on. reinhold, please review when a draft is updated [15:18:54] issue 40? [15:18:57] sorry [15:18:58] 33 [15:19:05] ? [15:19:08] Bernard - I will use your proposed text... [15:19:14] cyrus: How was #30 fixed? [15:19:58] Cyrus: thanks [15:20:16] reinhold my suggestion is that we use this time to help cyprus resolve issues that doesn't have proposals for, or for which he has concerns. [15:20:32] in turn, cyprus, could you please send cyprus the fix in email, copying the list preferrably [15:20:54] if we realize we have a disagreement, we can reschedule the issue [15:20:56] 33? [15:21:12] Sec. 3.2.5 (p.26): Why is it a MUST that all Attendees have to be included if the whole event is cancelled? The STATUS property already tells the CU(A) whether the whole event was cancelled or only some Attendees uninvited. Can’t a CUA also send out individual CANCEL messages to each of the Attendees with only that one Attendee included in the VEVENT? This would prevent privacy issues, because sending out the email addresses of all Attendees is not always desirable (see also issue 18). The same holds for VTODO (p.49) [15:21:51] Oops - sorry I misread by spread sheet. I have NOT fixed #30. [15:22:01] ah [15:22:07] well, back to 30 then [15:22:32] The key question is whether RRULE/RDATE/EXDATE should be allowed in a component sent via an ADD. [15:22:50] eliot.lear: I simply don't see how this case can be represented in iCalendar at all. [15:23:54] At least the case where an additional RRULE was added and some other props changed. [15:23:59] The intro to the section says ADD is used to "add one or more instances". i.e. somehow multiple instances are added. But the restriction table only allows one component to be sent. [15:24:07] The other cases are simpler. [15:24:19] cyrus: multiple instances can by added by an RRULE... [15:24:43] but if the original VEVENT already has an RRULE you end up with multiple RRULE [15:25:01] So I think it was originally allowed to include RRULE/RDATE/EXDATE with the assumption that those would somehow be merged into the "master" instance by the attendee CUA. How that is done is not clear. [15:25:02] which you should no longer do [15:25:20] bernard.desruisseaux: Yes, that's the problem. If you additionally change some other props for the second rule, you can no longer represent this sequence of events in iCalendar... [15:25:40] Right. The new spec restricts what can now be done with RRULE, so the current ADD table is not correct. [15:25:46] Let's look at the basic case... Adding a recurring instance to a single instance event... [15:26:10] right. what would be the fix? [15:26:28] I think we definitely have to remove RRULE. But what about RDATE? If I am adding multiple instances all with the same info but different dates, isn't RDATE OK - given that it would be simple to merge? [15:26:34] RRULE 0+? [15:26:49] Either the Organizer (on his side) will have created a new RRULE for the two instances... or else add an RDATE to the master component [15:27:34] A more complex scenario... you want to convert a single instance into a recurring component... [15:27:36] Yes, RDATE is fine, that can be merged by adding the RDATE and changing the changed props by another component with the same UID using the RECURRENCE-ID. [15:27:53] original event only had DTSTART... With METHOD:ADD you want to add an RRULE to it... [15:28:13] Bernard - there are always two ways to do this: one is to send a REQUEST with the complete new definition. That is allowed. The other is ADD for "incremental" change. [15:28:20] I would be happy to disallow this workflow! [15:28:24] Also easy, simply add the RRULE to the original event - as long as the other props have not been changed... [15:28:25] ADD is supposed to be the simple case. [15:29:07] Do we have interop info on the use of ADD? [15:29:12] So lets go with simple: RRULE 0 and RDATE 0 and EXDATE 0. To add multiple instances, one iTIP message per instance is required. [15:29:14] so reinhold, what is your proposal? [15:29:26] or do you agree with cyrus? [15:29:35] and what would be the impact on existing apps? [15:29:43] Cyrus' proposal is definitely the easy route... [15:30:14] RRULE 0 RDATE 0+ EXDATE 0 would be more flexible and would work [15:30:31] It makes sense to me to use ADD only for simple changes and a new REQUEST for more complex changes. I have no idea on the impact on existing implementations, though. [15:30:57] Event EXDATE 0+ would work, I think... [15:31:22] When would you need EXDATE in a ADD? [15:31:30] Text would say something like: "When an ORGANIZER adds an instance to an event via an RDATE property, the Organizer's CUA MAY use the ADD method to send out that change. Alternatively if the ORGANIZER makes a bigger change, by for example updating an RRULE, then the Organizer's CUA MUST use a REQUEST to update all attendees.". [15:31:31] if RRULE is disallow [15:32:17] i.e. ADD only makes sense when the Organizer adds an RDATE. [15:32:36] so which is it- Cyrus' table or Bernard's? [15:32:53] (Though one could argue a single instance is added when COUNT is changed in an RRULE - but I think that should be sent as a REQUEST). [15:32:54] I would be happy to get rid of ADD completely! [15:33:06] So I don't mind Cyrus's proposal... [15:33:11] I am sure IBM folks would complain about losing ADD. [15:33:24] My proposal is in the "simply" mode of this WG! [15:33:29] let's go with cyrus' wording, barring any objections? [15:33:31] simplify [15:33:37] ADD also makes sense to change just one instance of an RRULE using RECURRENCE-ID... [15:33:40] Very few applications actually support the addition of RDATE to an event... [15:33:53] going once [15:34:00] going twice [15:34:10] Issue 33, then, please! [15:34:11] Reinhold: ADD shouldn't be use for change though [15:34:11] I don't mind whether it's RDATE 0 or RDATE 0+ [15:34:25] Sec. 3.2.5 (p.26): Why is it a MUST that all Attendees have to be included if the whole event is cancelled? The STATUS property already tells the CU(A) whether the whole event was cancelled or only some Attendees uninvited. Can’t a CUA also send out individual CANCEL messages to each of the Attendees with only that one Attendee included in the VEVENT? This would prevent privacy issues, because sending out the email addresses of all Attendees is not always desirable (see also issue 18). The same holds for VTODO (p.49) [15:34:47] here on it's face I would tend to agree with Reinhold. Is there any reason not to allow for the above? [15:35:05] or should it in fact be standard practice? [15:35:10] Cyrus: Don't forget that RDATE can be use to modify the duration of a recurrence instance (i.e., not to actually add a new instance). Your current wording was ok I think. Make sure this is clear in the draft. [15:35:59] Is the value of STATUS in METHOD:CANCEL made clear anywhere in the spec? [15:36:33] I would reword this so that the CANCEL is sent to the uninvited CU only. Of course, the organizer is always free to send a message to anone else he wants to, but he shouldn't be required. [15:36:50] STATUS in CANCEL is a thorny issue. We ran into issues with IBM on that one. They treat a CANCEL with StATUS:CANCELLED different from one without STATUS. [15:37:15] right, but isn't reinhold's privacy concern valid? [15:37:56] Ahm, sorry, had something else in mind... sending a REQUEST requires the organizer only to add the one attendee he invites in a message (i.e. he can send out individual invitations), but for CANCEL he can't to that. [15:38:11] yes [15:38:14] So change the table description text to something like: "lists some or all of the Attendees being removed from the event" [15:38:46] right. but i think some discussion might also be in order, so that people understand the privacy concerns. [15:39:11] and perhaps add text in the main text: "the Organizer's CUA MAY choose to send a single CANCEL to all Attendees, or separate CANCEL messages to different sets of Attendees, provided that all attendees being removed from an event are sent a message" [15:39:28] all: does that sound reasonable? [15:39:56] Privacy concern ought to be addressed in general in Security Considerations rather than each time in each table section. [15:40:16] i'm happy for you to move the text into Security Considerations [15:40:21] cyrus: Regarding your STATUS:CANCELLED claim with IBM, that's exactly the issue: An event with STATUS:CANCELLED is a cancelled event, no need to add all attendees, an event without STATUS is an event where only that attendee was removed, but the event still occurs. So IBM is completely right. [15:40:52] This is issue #34? [15:41:19] no issue 33, right? [15:41:39] Reinhold: I don't believe the STATUS:CANCELLED behavior is explicitly stated that way anywhere in the specs... [15:41:46] #33 [15:42:00] cyrus: but isn't that how most implementations run with it? [15:42:13] bernard.desruisseaux leaves the room [15:42:37] cyrus: it is in the table in sec 3.2.5: [15:42:39] | STATUS | 0 or 1 | MUST be set to CANCELLED to | | | | cancel the entire event. If | | | | uninviting specific "Attendees" | | | | then MUST NOT be included. | [15:43:24] OH, I guess I didn't read that properly :-[ [15:44:03] i think there is still a privacy concern though [15:44:09] So, STATUS is enough to determine whether the whole even has been cancelled. Now the issue only boils down to the privacy issue. [15:44:25] bernard.desruisseaux joins the room [15:44:30] BTW Bernard has dropped off - connection problems. [15:44:34] Oh, he is back! [15:44:38] Am I back ? [15:44:40] ok [15:44:42] yes you are [15:44:58] eliot.lear: Exactly, I don't see the need to require all attendees to be listed. [15:45:37] right, but on the other hand, if the event is CANCELLED then the gig is up based on whether CANCELLED is included. [15:46:16] Reinhold: so in the entire CANCEL case, sending the attendee list should be optional. In the attendee removal case, each attendee removed MUST be sent an iTIP message listing them as an ATTENDEE. [15:46:18] the only issue is if the organizer wants to keep the list of ATTENDEEs private [15:46:29] is that correcT? [15:46:58] Organizer MAY specify the event is really cancelled with STATUS:CANCELLED (but should not be forced to do so) [15:47:05] cyrus: Yes, the organizer can send out individual CANCEL messages, listing only that one attendee. Everything would still work. [15:47:10] Right. But that also relates to whether the original REQUEST to the Attendees listed all Attendees, or whether there was one request per attendee only listing them. [15:47:33] Organizer should NOT be REQUIRED to specify all Attendees that are uninvited in a METHOD:CANCEL [15:47:40] indeed. [15:47:50] Totally agree. [15:48:05] i think we all seem to be in fundamental agreement here, although there may be some potential coherency problems depending on underlying transport used. [15:48:07] He should also not be required to list all attendees if the whole event is cancelled. [15:48:21] if we are agreed, i can live with that [15:48:26] I think security considerations should state that "Organizers are free to send out separate iTIP messages to each attendee only listing that attendee int he Attendee list for privacy reasons." Then we make sure the restriction tables/body text allows that possibility. [15:48:45] right, and let's review MUST language in that section [15:48:55] I like that. Cyrus, will this change impact IBM? [15:49:21] bernard's issue with requireing STATUS:CANCELLED can easily be circumwented by first removing all attendees (no STATUS) and then finally cancelling the whole event (which then does not have any attendees any more), so this is a non-issue anyway. [15:49:26] It is useful for the attendee's CUA to have their Attendee property present when matching up event details. I think I would prefer to still require Attendee to be present ion the STATUS:CANCELLED case. [15:49:43] reinhold: good point [15:50:17] when you say "Attendee property present" do you mean the entire set of attendees? [15:50:23] or just themselves? ;-) [15:50:42] cyrus: Yes, if sending out individual cancels, of course the receipient of that one cancel must still be listed as attendee. But the other attendees should not. [15:51:28] Does not have to be entire - but has to at least include the ATTENDEE property for the attendee sent the iTIP message in order to allow them to match the message to their copy of the event. [15:51:40] ok, we are in agreement then [15:51:47] yes [15:51:54] let's move on to issue 40 [15:52:07] Sec. 3.2.7 (p.31): At the end of this section, it should be clarified how the Organizer reacts to the COUNTER. Declining it is clear, but if he accepts it, does he have to send out a new REQUEST to all Attendees or can he simply do nothing, too? In particular, if an Attendee 6 sends a COUNTER with significant changes and does not receive a DECLINECOUNTER, can he assume that the Organizer has accepted it or does he have to treat it like receiving a DE- CLINECOUNTER? How does he learn about it other than sending a REFRESH? [15:52:14] (ignore the 6) [15:53:00] In my opinion, COUNTER / DECLINECOUNTER are broken. [15:53:20] can the answer be to REFRESH the others? [15:53:22] There is no way to match a specific COUNTER request with a DECLINECOUNTER response [15:53:42] #40 is similar to #25. Basically we need to add text stating that "the Organizer SHOULD send out a REQUEST to all attendees affected by the change triggered by accepting the COUNTER" [15:53:51] I think that's basically the same issue as the one with the uninvited CU. The easy way would be to require the ORGANIZER to send a new REQUEST. [15:53:56] ok. [15:53:56] Also, there is no systematic way to know if your COUNTER has been accepted [15:54:25] for the moment, let's keep whether COUNTER is entirely broken off the table [15:54:32] Bernard: we can't address the COUNTER/DECLINECOUNTER match issue without a wholesale change to the way iTIP message works. I am also not convinced that a client would care... [15:54:55] cyrus & reinhold, you two seem to be in agreement. cyrus, can you clarify the text? [15:55:39] and does 59 devolve to this as well? [15:55:58] eliot.lear: REFRESH can't be used, because REFRESH are sent by the attendees to request an updated version of an event. [15:56:02] The Organizer is always free to include a COMMENT about why something changed. Does not help CUAs that need to programmatically track COUNTER behavior, but I don't think any care about that. [15:56:15] reinhold: ack [15:56:36] reinhold, i believe you and cyrus are in agreement on REQUEST, and that is good enough for me. [15:56:39] eliot.lear: #59 is exactly the same as #25, just for VTODO, so I think we have discussed this already. [15:56:41] Text as per previous message: "the Organizer's CUA SHOULD send out a REQUEST to all attendees affected by the change triggered by accepting the COUNTER" [15:56:56] ok [15:57:03] ok [15:57:23] cyrus, can you address 59 as you did 25? if so we can move on [15:57:42] Yes. #59 will be fixed as per #25. [15:57:57] that gets us to 64 [15:57:59] 64. 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). [15:58:19] Its good to be able to kill two birds with one stone (so long as you are not an ornithologist). :-) [15:58:27] ;-) [15:59:28] page 48 [16:00:20] The issue of whether SEQUENCE has to change on CANCEL is contraversial. The IBM folks absolutely refuse to bump SEQUENCE. Others (MS?) insist it MUST be done as per the spec. We will never have agreement on this. [16:00:23] Page 51 in bis-08 (second paragraph above the constraints table for CANCEL) [16:00:39] guys - i'm sorry. i've run out of time. Cyrus, if you can address this issue and any others on list, that would really help move things along. in the meantime, i will chat with you on friday [16:01:16] Okay, see you on friday (I'll be a little late then) [16:01:22] See you on Friday! [16:01:28] Bye [16:02:00] Bye. [16:02:18] eliot.lear leaves the room [16:02:23] bernard.desruisseaux leaves the room [16:17:44] reinhold leaves the room [16:30:31] alexey.melnikov leaves the room