[09:26:42] --- aki has joined
[09:33:16] --- bdesruisseaux has joined
[09:33:24] <aki> Hi Bernard
[09:33:34] <bdesruisseaux> Hi!
[09:33:43] <aki> How are you?
[09:33:54] <bdesruisseaux> Busy! :-(
[09:34:02] <bdesruisseaux> but going well!
[09:34:04] <bdesruisseaux> About you?
[09:34:15] <aki> Doing well. Busy too.
[09:34:25] <aki> SO are the others, I presume :)
[09:34:35] <bdesruisseaux> Have people started to use their special lamp in Finland? :-)
[09:35:06] <aki> Special lamp? Was this something that was on the daily show?
[09:35:08] <bdesruisseaux> My yougest one ask me yesterday why we were waking up in the middle of the night!
[09:35:17] <aki> ??
[09:35:32] <aki> Ah, right.
[09:35:41] <aki> Yeah, it gets you every fall. ;)
[09:35:47] <bdesruisseaux> Exactly
[09:35:56] <aki> Waiting for spring...
[09:36:41] <aki> Hmm... seems we're here alone, and you're busy, so let's call it a day.
[09:36:54] <aki> We need to think about whether we need these chats at this point.
[09:37:02] <bdesruisseaux> I happy with that for today...
[09:37:09] --- cyrus_daboo has joined
[09:37:09] <bdesruisseaux> We absolutely need them for iTIP.
[09:37:20] <bdesruisseaux> Hi Cyrus!
[09:37:21] <cyrus_daboo> Hi
[09:37:25] <aki> Ah, here's Cyrus. Hi
[09:37:53] <aki> That may be all. Eliot's on vacation. Don't know about Alexey.
[09:37:54] <bdesruisseaux> Perhaps this is not a good time slot for these sessions...
[09:38:05] <cyrus_daboo> Alexey is on vacation.
[09:38:18] <aki> If only we had a way to get free/busy out of people's calendars. ;)
[09:38:20] <bdesruisseaux> The dead line for the next IETF is approaching fast...
[09:38:31] <bdesruisseaux> Aki: When do you plan to complete your revision?
[09:38:41] <aki> You mean review?
[09:38:54] <bdesruisseaux> :-)!
[09:38:57] <aki> Before next meeting in any case. Do you have patches lined up?
[09:39:00] <bdesruisseaux> Yes! REVIEW!
[09:39:18] <bdesruisseaux> Few of them
[09:39:38] <bdesruisseaux> I'll try to make a blitz this week
[09:39:46] <aki> Excellent.
[09:40:08] <aki> The review is part of the PROTOS writeup, which is what gets sent along with the draft to IESG
[09:40:48] <aki> Cyrus, what's happening with iTIP?
[09:41:10] <cyrus_daboo> Not a lot. I have a bunch of minor changes ready to go in.
[09:41:19] <cyrus_daboo> The major issues are still outstanding.
[09:41:36] <aki> What can we do to move those along?
[09:42:00] <bdesruisseaux> The issues brought up by the removal of RANGE=THISANDFUTURE are still not closed, right?
[09:42:03] <cyrus_daboo> Now that I have more time on my plate I will start doing a through review and add issues to the tracker.
[09:42:30] <aki> Good.
[09:42:40] <cyrus_daboo> RANGE will not be closed until I can convince myself that your proposals to work around it will work.
[09:43:55] <bdesruisseaux> So far we have looked at the cases of an Organizer updating a component.. that was fine.
[09:44:07] <bdesruisseaux> We looked at the case of an Attendee also... no problem...
[09:44:33] <bdesruisseaux> BUT, we haven't really look at what happens when an Organizer does changes... and multiple Attendees do such changes as well...
[09:44:51] <cyrus_daboo> Well I do consider sending out the entire revision set a "problem". It may not be as big a problem as interpretation of RANGE=, but it is still a problem, scalability wise.
[09:44:58] <bdesruisseaux> I was looking for an evil scenario this morning...
[09:45:41] <cyrus_daboo> Remember, from an ORGANIZER's standpoint, they can always just send everything, and it will all be OK (subject to the issues with SEQUENCE number).
[09:46:15] <bdesruisseaux> Not sure what you mean by "everything"
[09:46:27] <bdesruisseaux> With unbounded rule it may be tricky
[09:46:33] <cyrus_daboo> The master component and all overridden instances.
[09:47:38] <cyrus_daboo> With unbounded you do the trick you mentioned: all past instances are RDATEs, and the ongoing instances are covered by the unbounded RRULE.
[09:48:08] <bdesruisseaux> Right.
[09:48:31] <bdesruisseaux> Let me try a ridiculous use case...
[09:49:34] <cyrus_daboo> The problem we had with ATTENDEEs, was that to do RANGE-style replies (e.g. "I accept from this instance onwards), then the ATTENDEE would have to effectively change the RRULE in a similar way. Then the question is whether an ORGANIZER's client can cope with the attendee making such a big change.
[09:49:58] <bdesruisseaux> One attendee replies that he will attendee every other instance in the future of a weekly meeting (i.e., attend every two weeks only)
[09:50:37] <cyrus_daboo> Can't be done!
[09:50:43] <bdesruisseaux> Another attendee replies that he will attend every third week only...
[09:50:50] <cyrus_daboo> But then you couldn't do that with RANGE= eitehr!
[09:51:01] <bdesruisseaux> Right...
[09:51:06] <cyrus_daboo> You would have had to use multiple RRULEs.
[09:51:14] <cyrus_daboo> But those are gone too!@
[09:51:17] <bdesruisseaux> That's what I think too
[09:51:27] <bdesruisseaux> LOL
[09:51:29] <aki> This starts to sound like a reservation system. Perhaps a corner case we don't need to solve?
[09:52:06] <cyrus_daboo> The best that you can do is accept/decline out to some finite point in the future, then leave the remainder as NEEDS-ACTION for ther unbounded rule.
[09:52:07] <bdesruisseaux> I tend to agree... That's why I said it was "ridiculous" !
[09:52:39] <cyrus_daboo> What isn'
[09:52:48] <bdesruisseaux> Actually... The attendee could send multiple replies...
[09:53:07] <bdesruisseaux> One reply for the 'even' weeks... and another one for the 'odd' weeks...
[09:53:24] <aki> That could work couldn't it?
[09:53:37] <cyrus_daboo> What isn't ridiculous is that in all likelihood, a recurring meeting will need to have every instance be an overridden instances as there are nearly always one-off exceptions for one attendee or another in an ongoing meeting with lots of attendees.
[09:53:38] <bdesruisseaux> With iTIP you are fine.
[09:54:32] <bdesruisseaux> My concern really is about the Organizer having to represent all this information in a single iCalendar stream with only 1 RRULE...
[09:55:02] <cyrus_daboo> But its not clear that it is OK for an ATTENDEE to modify the RRULE sent by the ORGANIZER. I bet most clients today won't understand that.
[09:56:00] <bdesruisseaux> Well... you can also look at the problem the other way around... There are no client out there that will allow you to accept every other week in the future...
[09:56:10] <cyrus_daboo> The stream will end up with overridden components for each rrule instance up to some point in the future where the organizer has to say enough is enough, and just leave all attendees as needs-action.
[09:58:58] <bdesruisseaux> This is the pragmatic approache. Nothing goes on for ever... We are all going to die...
[09:59:39] <cyrus_daboo> So ban unbounded rules in iTIP.
[09:59:58] <cyrus_daboo> At least iTIP REQUEST, they are probably OK in PUBLISH.
[10:00:18] <bdesruisseaux> Who the hell you think you are to schedule me for ever? :-)
[10:01:16] <aki> That isn't a bad approach.
[10:01:37] <aki> So let me try to summarize.
[10:01:38] <bdesruisseaux> On the other hand, some calendar clients will create recurring event unbounded by default...
[10:01:57] <bdesruisseaux> unless you go in some advanced/custom menu to limit the set
[10:03:27] <bdesruisseaux> [Waiting for Aki's summary...]
[10:03:31] <aki> Issue 85: attendees accepting from some point forward is problematic without RANGE.
[10:04:21] <aki> One solution is to forbid unbounded rules,
[10:05:05] <aki> and have attendees single out reply to those instances that they can't make.
[10:05:22] <aki> Close? :)
[10:05:56] <cyrus_daboo> Unbounded rules are also silly for automated attendees (e.g. rooms) that need to check each instance against their current calendar see whether they are free or not. Unless you have some clever algorithmic method for that, you have to expand the rule set and check each one (which of course does not work for unbounded).
[10:06:17] <bdesruisseaux> I like this one!
[10:07:11] <bdesruisseaux> While I like the idea of banning unbounded rules... There was always a number of people against this idea at CalConnect...
[10:07:13] <cyrus_daboo> OK, if we want to pursue this we need to document all the problem with unbounded rules in the issue tracker then propose the solution to the list. I know there will be some people that will complain loudly about such a change.
[10:07:47] <aki> Will you Cyrus take the ball here?
[10:07:48] <bdesruisseaux> Looks like the way to move this forward
[10:07:53] <aki> Propose this to list?
[10:08:25] <cyrus_daboo> Remember, what is "unbounded" anyway? There is nothing to stop me creating a "bounded" rule with an until set to 99991231T235959 - which to all intents and purposes is "unbounded" as far as iCalendar goes!
[10:09:05] <cyrus_daboo> So its not whether it is bounded or unbounded that counts, rather the number of instances in the set.
[10:09:36] <cyrus_daboo> We would have to limit the maximum number of instances in the set, rather than say "bounded" only.
[10:09:37] <aki> True. And it's impossible to propose any sensible figure as to what's too much.
[10:09:41] <bdesruisseaux> Yes. I've brought up this fact many times. The world ends in year 9999 for iCalendar...
[10:10:32] <bdesruisseaux> Most servers will want to limit the number of instances...
[10:10:43] <cyrus_daboo> I think it is reasonable to have a meeting that covers the period of one year, and then require the organizer to send out another one for the next year etc.
[10:10:57] <bdesruisseaux> with FREQ=SECONDLY the numbers of instances goes fast
[10:11:08] <cyrus_daboo> After all, in the real world we have paper calendars/dairies that are only one year's worth of data.
[10:11:48] <aki> One year sounds reasonable, as a suggestion (with caveat that FREQ counts of course)
[10:11:57] <cyrus_daboo> Well for human scheduling, SECONDLY and MINUTELY are silly states.
[10:12:13] <bdesruisseaux> I don't believe one year as a limit makes sense
[10:12:19] <bdesruisseaux> Think about yearly events...
[10:12:19] <aki> Yeah, and I will only attend every other second... ;)
[10:12:40] <bdesruisseaux> Why shouldn't I be able to specify at least 5 instances in the future?
[10:13:19] <cyrus_daboo> For yearly events you PUBLISH the unbounded rule (e.g. "Wedding Anniversary"). Then for each year you "invite" your wife to dinner, or lunch or whatever - each year is different in some way.
[10:13:25] <aki> Bernard: but typically don't you really need some out-of-band exchange anyway to schedule that much into the future?
[10:13:38] <aki> Cyrus: exactly, starts to sound more like PUBLISH
[10:14:11] <bdesruisseaux> If we go back to the analogy with the paper calendar... or paper agenda...
[10:14:51] <bdesruisseaux> Our great-great-grand-father (ok... our parents!) probably wasted a couple of hours at the beginng of each year
[10:15:30] <bdesruisseaux> to transcribe in their new agenda... all the recurring events still ocurring in the coming year...
[10:16:10] <bdesruisseaux> at CalConnect we talked about server that would truncate an unbounded rule in practice... but would actually have the capability of generating the future instances... in the future...
[10:16:20] <cyrus_daboo> Right, but "anniversaries" can remain unbounded. The actual celebration of an anniversary is really a one-off event different each year.
[10:16:33] <aki> But were those recurring meetings were scheduled vs. just published
[10:16:46] <cyrus_daboo> I am not going to invite you to my birthday part every year into the future.
[10:17:11] <bdesruisseaux> Cyrus: You have the "daily note" to remind you of the anniversary... and perhaps a separate event for the celebration
[10:17:19] <cyrus_daboo> Exactly!
[10:17:38] <cyrus_daboo> The separate event is a single instance - not recurring. So no problems with that.
[10:17:39] <bdesruisseaux> The daily note will most likely be identical for ever
[10:17:47] <aki> I guess ultimately we can't give a hard limit, and some will try to schedule an event with too many instances, and that'll be annoying.
[10:18:08] <aki> But nothing breaks, right? If we just tell people it's not a good idea, and suggest a limit?
[10:18:26] <cyrus_daboo> Right. iTIP does have a status code that allows an attendee to reply, but say that the set was truncated on their end.
[10:19:27] <aki> So Cyrus, will you take this up with the list?
[10:19:35] <cyrus_daboo> |==============+============================+=========================| | 2.11 | Success, unbounded RRULE | RRULE property name and | | | clipped at some finite | value MAY be specified. | | | number of instances | Number of instances MAY | | | | also be specified. | |==============+============================+=========================|
[10:19:51] <cyrus_daboo> Sorry - that probably does not look very good in IM client.
[10:20:18] <aki> Got the point. :) Seems exactly what is needed here.
[10:20:39] <cyrus_daboo> The description for that code is bogus. What is an "RRULE property name"?
[10:21:15] <cyrus_daboo> Well, all those codes need reviewing. I will add that to my task list.
[10:21:52] <bdesruisseaux> Cyrus: The third column talks about the "offending data" that can be specified in the REQUEST-STATUS
[10:22:34] <bdesruisseaux> As such... it simply means that you could see REQUEST-STATUS:2.11;Success blah blah;RRULE=FREQ=DAILY
[10:23:28] <cyrus_daboo> Yes, OK.
[10:23:35] <aki> Good.
[10:23:53] <aki> I think this was it for today. I think it was productive
[10:23:58] <cyrus_daboo> But it does not let the attendee tell the organizer at what point the truncation happended.
[10:24:23] <bdesruisseaux> Nope
[10:24:48] <bdesruisseaux> BTW, just noticed that REQUEST-STATUS can occur more than once.. weird
[10:25:00] <cyrus_daboo> No - that absolutely makes sense.
[10:25:23] <cyrus_daboo> If there is more than one problem you can indicate each one back to the organizer.
[10:26:16] <bdesruisseaux> How do you handle a reply with both a 2.x (success) and a 3.x (Error) REQUEST-STATUS?
[10:26:34] <cyrus_daboo> Well, silly cases like that are...silly!
[10:26:58] <bdesruisseaux> Well, have a look at 4.4.9 Error Reply To A Request in iTIP!
[10:27:05] <bdesruisseaux> You have an example!
[10:27:10] <bdesruisseaux> :-)
[10:27:30] <cyrus_daboo> I think if there are multiple, they must all be of the same numeric category (same "short return code" as defined in 2445).
[10:28:02] <cyrus_daboo> Arghh!
[10:28:28] <cyrus_daboo> So in that example, did the meeting get scheduled or not?
[10:29:32] <bdesruisseaux> Well, of course it did! An Invalid Property Name is a minor issue... but how would an application know that! :-)
[10:29:38] <cyrus_daboo> I think that is just wrong. We should require that all request status items have the same short status code.
[10:30:08] <cyrus_daboo> The description of 3.xx in 2445 states that the "request was not successful".
[10:30:26] <cyrus_daboo> But 2.xx is "request completed successfully".
[10:30:27] <bdesruisseaux> I would re-evaluate whether we absolutely need multiple request-status
[10:30:33] <cyrus_daboo> So they are in conflict.
[10:30:42] <cyrus_daboo> We need to rule that combination out.
[10:32:36] <bdesruisseaux> Can you submit an issue for this one as well?
[10:32:44] <bdesruisseaux> I have to run to a meeting
[10:32:46] <aki> I'm just typing this one in.
[10:32:51] <bdesruisseaux> Great!
[10:32:54] <cyrus_daboo> OK, thanks!
[10:32:54] <aki> I think we're done.
[10:32:58] <cyrus_daboo> Sure.
[10:33:03] <aki> It was a good one. Thanks!
[10:33:03] <bdesruisseaux> Cheers!
[10:36:07] <aki> Bye
[10:36:16] <cyrus_daboo> Bye.
[10:36:20] --- cyrus_daboo has left
[10:37:48] <aki> (added as issue 95)
[10:37:52] --- aki has left
[12:06:50] --- bdesruisseaux has left