[09:43:07] --- aki has joined
[09:47:32] --- fabio.silva has joined
[09:54:06] <aki> We'll be starting in 8 minutes
[09:56:21] --- jonlennox has joined
[09:58:10] --- bdesruisseaux has joined
[10:00:05] <aki> We'll start in a couple of minutes
[10:00:21] <aki> Eliot and Alexey won't be able to join today
[10:01:06] <aki> Oh, and hi everyone! :)
[10:02:11] --- cyrus_daboo has joined
[10:02:52] <aki> Ok, I think we can start
[10:03:11] <aki> Welcome
[10:03:52] <aki> As for agenda, let's take a look at the remaining 2445bis issues, then spend time on 2446bis
[10:04:08] <aki> Bernard, where are we with 2445bis issues?
[10:04:57] <bdesruisseaux> Not much progress has been done on the mailing list.
[10:05:17] <bdesruisseaux> I did some work on the draft for simple issues ...
[10:05:48] <bdesruisseaux> I haven't receive any good or bad feedback on my proposal to clarify the use of DTSTAMP
[10:06:16] <bdesruisseaux> Eliot mentionned on the last conf call that he liked the proposal, but I haven't heard anything else.
[10:06:53] <cyrus_daboo> Send one more message on that asking for comments and I promise to look at it again and do a + or - 1 depening on what I think.
[10:07:02] <cyrus_daboo> If you're lucky it will be +12
[10:07:25] <aki> Sounds good
[10:08:15] <aki> What about the apps area review comments?
[10:09:00] <bdesruisseaux> There were only 4 comments and not much substance I would say.
[10:09:52] <aki> Can you reply to the reviewer, though, if you haven't already?
[10:09:59] <cyrus_daboo> The one key issue was clarifying the order of the BY parts - but we decided on the phone last time that that is already spelled out in text. So I think a reply to the review could point that out.
[10:10:13] <bdesruisseaux> At the last conf call we talked about Issue 12: http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue12
[10:11:44] <bdesruisseaux> The question is whether: RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 is equivalent to: RRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=-1SU
[10:12:04] <bdesruisseaux> BTW, the answer MUST be yes!
[10:12:55] <jonlennox> Because that's what people implement?
[10:13:01] <bdesruisseaux> Indeed!
[10:13:33] <bdesruisseaux> And all the time zone examples in the RFC were using the FREQ=YEARLY form
[10:13:53] <cyrus_daboo> And the rule is BYMONTH is applied first to produce a set of dates, and then BYDAY is applied to THAT set.
[10:14:25] <cyrus_daboo> That is true for all ordered combination of BYxxx parts.
[10:14:41] <aki> Do we have a proposal?
[10:14:41] <jonlennox> Cyrus: what does RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10,11 mean, then?
[10:14:46] <cyrus_daboo> But it might be good to put this example in and explain this explicitly.
[10:15:06] <jonlennox> There's this whole implicit concept of "set" that's very poorly defined.
[10:15:17] <bdesruisseaux> Right.
[10:15:36] <bdesruisseaux> In the section the text first say: Each BYDAY value can also be preceded by a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific day within the MONTHLY or YEARLY "RRULE".
[10:15:54] <bdesruisseaux> And only later in the section you can read: If multiple BYxxx rule parts are specified, then after evaluating the specified FREQ and INTERVAL rule parts, the BYxxx rule parts are applied to the current set of evaluated occurrences in the following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated.
[10:16:05] <bdesruisseaux> As such Cyrus is right.
[10:16:06] <cyrus_daboo> I would expect that rule to give you the first Sunday in month 10 only.
[10:16:31] <jonlennox> Cyrus: there was a minus there -- did you miss it?
[10:16:31] <bdesruisseaux> IMO, the text on BYDAY should be changed...
[10:16:52] <cyrus_daboo> Yes - so the last Sunday in the 11th month
[10:17:29] <cyrus_daboo> i.e. you start with the set of all days in the year (FREQ=YEARLY), you reduce to the set of days in months 10,11 (BYMONTH=10,11), then reduce to the last Sunday in that set.
[10:18:04] <bdesruisseaux> No quite.
[10:18:05] <cyrus_daboo> That is different from FREQ=MONTHLY with the same byxxx parts. That generates the last Sunday in each of month's 10 and 11.
[10:18:14] <bdesruisseaux> It is not "the last Sunday in that set"
[10:18:58] <jonlennox> Ick -- that makes constant-time interval-intersection calculations much harder. But if that's what the spec says, it's what it says...
[10:19:43] <bdesruisseaux> It is actually "all the last Sunday that occur in the 11th month"
[10:19:43] <cyrus_daboo> Of course what I said does not match what happens in Mulberry - so clearly I don't know what I am talking about!
[10:19:55] <bdesruisseaux> :-)
[10:20:09] <jonlennox> Bernard: what's the distinction?
[10:20:35] <cyrus_daboo> I guess the question is whether BYMONTH=10,11 generates two sets or one. If two sets then you get the last SU in each of them, if one then you get one SU.
[10:21:04] <jonlennox> I think we had some rough consensus was that the "set" was the dates within a recurrence of the FREQ.
[10:21:24] <cyrus_daboo> FYI My iCalendar code is now publically available at: http://trac.mulberrymail.com/repos/browser
[10:21:24] <jonlennox> At least for BYSETPOS. Anything else is impossbily hard to specify.
[10:22:15] <bdesruisseaux> Jon: Right, it depends how you define set...
[10:23:10] <bdesruisseaux> Is the set all the generated date-time, or all the generated date-time for a given period specified by FREQ...
[10:23:28] <jonlennox> The distinction between BYSETPOS and BYDAY=<num>, then, is that sets begin at the recurrence of DTSTART, whereas BYDAY integers begin at the conceptual beginning of the time unit?
[10:23:49] <jonlennox> Bernard: has to be the latter, otherwise a BYSETPOS only indicates a single occurrence.
[10:23:56] <jonlennox> Which is nonsensical.
[10:24:01] <bdesruisseaux> Right.
[10:24:26] <jonlennox> Unless you want to define some other set-delimiter other than the FREQ, but I have no idea what that would be.
[10:26:02] <jonlennox> Before we get too far down this, though, we should probably see what existing implementations actually do with "RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10,11"
[10:26:31] <cyrus_daboo> Looks to me like I implemented a whole bunch of special cases for BYDAY and I believe a lot of that came from what libical did.
[10:28:14] <aki> I think we have two choices here
[10:29:00] <aki> Either just add an additional example that uses FREQ=MONTHLY and clarify that to mean the same
[10:29:41] <aki> Or propose something more elaborate on how sets are formed by these rules
[10:30:34] <aki> Or did I get it completely wrong? ;)
[10:30:35] <bdesruisseaux> An example is not sufficient. We need clear normative text
[10:31:45] <aki> Others?
[10:31:51] <jonlennox> I agree with Bernard
[10:32:23] <aki> Bernard, do you think you could form a proposal for this new text?
[10:32:40] <jonlennox> Too much of the RRULE definition has to be reverse-engineered from the examples in 2445, which means that everyone disagrees about the cases not in the examples.
[10:33:01] <cyrus_daboo> Can we agree on this? Depends on what each of the iCal library vendors have done.
[10:33:07] <bdesruisseaux> Aki you are asking me for a lot of work!
[10:33:30] <cyrus_daboo> I can try codifying the special cases I implemented.
[10:33:48] <aki> Sorry Bernard :)
[10:33:49] <cyrus_daboo> But that may not agree with what others did. But at least it is a starting poiunt...
[10:33:55] <jonlennox> There was a list of special cases defined by the calendar interop guidelines, wasn't there?
[10:36:54] <cyrus_daboo> Hey - the recurrence table I did for Calconnect actually codifies all this via some notes atthe end of the table.
[10:37:02] <cyrus_daboo> Did you get those notes Bernard?
[10:37:13] <jonlennox> I think that's what I was thinking of
[10:37:54] <cyrus_daboo> See Appendix A in http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf
[10:38:51] <bdesruisseaux> Cyrus what do you get with: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//vi BEGIN:VEVENT UID:20070517T120000Z-A2F32B@example.com DTSTAMP:20070517T120000Z DTSTART;TZID=America/New_York:20071028T100000 DURATION:PT1H RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10,11;COUNT=6 SUMMARY:Test RRULE END:VEVENT BEGIN:VTIMEZONE TZID:America/New_York LAST-MODIFIED:20050809T050000Z BEGIN:DAYLIGHT DTSTART:20070311T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT BEGIN:STANDARD DTSTART:20071104T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST END:STANDARD END:VTIMEZONE END:VCALENDAR
[10:40:27] <bdesruisseaux> Oracle Calendar gives me: Oct. 28, 2007 Nov. 25, 2007 Oct. 26, 2008 Nov. 30, 2008 Oct. 25, 2009 Nov. 29, 2009
[10:40:59] <cyrus_daboo> That is what I got in Mulberry. Let me check iCal.
[10:42:06] <cyrus_daboo> Same in iCal.
[10:43:10] <cyrus_daboo> Should get exactly the same if FREQ=MONTHLY is used too.
[10:44:57] <aki> Folks, are we getting somewhere?
[10:45:35] <bdesruisseaux> Looks like none of us were really prepared for this session :-(
[10:45:38] <cyrus_daboo> I think the Notes in the recurrence table cover these issues. If we include the table and those plus some examples we ought to be ok.
[10:45:52] <jonlennox> So in other words, the presence of BYMONTH in a FREQ=YEARLY RRULE changes the semantics of the BYDAY number to day-in-month from day-in-year?
[10:46:06] <jonlennox> But it doesn't apply to "sets" like BYSETPOS does.
[10:46:17] <cyrus_daboo> Yes.
[10:46:58] <aki> Is there enough to work with here?
[10:47:46] <jonlennox> I think that's just a simple addition to the definition of BYDAY.
[10:48:31] <aki> Good, then I propose we take this to the list. Cyrus, can you do that?
[10:48:50] <cyrus_daboo> Its not all that simple. There are actually three special cases for BYDAY based on FREQ value, and in each of those cases there are separate variants based on the presence of other BYxxx parts...
[10:50:01] <aki> Cyrus, what do you propose we do?
[10:50:21] <cyrus_daboo> I ca n re-post the recurrence table + notes and ask that we include that verbatim in 2445bis to clarify the BYDAY special cases. But I think Bernard was going to do that anyway?
[10:50:43] <bdesruisseaux> I'm in the process of adding this table to the draft.
[10:51:03] <bdesruisseaux> This table will need to go through a thorough review...
[10:51:21] <cyrus_daboo> Ok, then I think Bernard is addressing this, and I agree that further review is good.
[10:51:58] <bdesruisseaux> For the case of BYDAY, I was wondering if we should simply change: If present, this indicates the nth occurrence of the specific day within the MONTHLY or YEARLY "RRULE".
[10:52:49] <bdesruisseaux> to make reference to the computed set so far... instead of only the FREQ value specified... ?
[10:53:28] <cyrus_daboo> just add ", with some special case behavior as described in the notes with the recurrence table shown in section NN".
[10:53:46] <bdesruisseaux> Right... it is... more complicated than what I just said
[10:54:20] <cyrus_daboo> Right - text byitself would be hard and likely add to the confusion. Just a reference to the table + notes would be better.
[10:54:30] <aki> Let's take this to the list, then.
[10:55:26] <aki> We have 8 minutes left, anything else on 2445bis?
[10:56:34] <aki> Cyrus, do we start with 2446bis issues, or call it a day?
[10:56:37] <jonlennox> I had some other open issues which I was supposed to provide text for, but I'm not sure I remember what they were?
[10:56:44] <jonlennox> For 2445bis?
[10:57:46] <cyrus_daboo> Lets call it a day....
[10:57:46] <bdesruisseaux> http://www3.ietf.org/proceedings/07mar/minutes/calsify.txt
[10:58:34] <jonlennox> Okay, I'll try to get to those
[10:59:17] <aki> Good, thanks for attending everyone
[10:59:32] <aki> See you next week, and let's be active on email in the meantime!
[11:00:57] <aki> Bye!
[11:01:27] --- aki has left
[11:07:24] --- jonlennox has left
[11:07:43] --- fabio.silva has left
[12:21:30] --- bdesruisseaux has left
[13:49:14] --- cyrus_daboo has left