[09:35:52] --- eliot.lear has joined
[10:01:37] --- bdesruisseaux has joined
[10:01:55] <eliot.lear> hi bernard!
[10:02:00] <bdesruisseaux> hi eliot
[10:02:05] <eliot.lear> how goes?
[10:02:12] <bdesruisseaux> busy
[10:02:19] <eliot.lear> hmm...
[10:02:32] <eliot.lear> seems like we've had that conversation before ;-)
[10:02:39] <bdesruisseaux> :-)
[10:02:43] <bdesruisseaux> how about you?
[10:02:43] <eliot.lear> we'll wait a few for others
[10:02:47] <eliot.lear> things are good here
[10:02:55] <eliot.lear> today was a little nuts
[10:03:22] <eliot.lear> 2 cars in the shop, one accident, and then there is all the things one must do for a 1 yr old
[10:04:01] <eliot.lear> what do we have left open, from your pov?
[10:04:21] <bdesruisseaux> wait 'till the baby is 2 yr old... you'll then have to answer "Why?, Why?, Why?, ..."
[10:04:38] <eliot.lear> i'm a pretty crazy guy. she is going to be warped
[10:04:53] <eliot.lear> "what are those things?"
[10:05:04] <eliot.lear> "oh... those big long pipes generate clouds"
[10:05:31] <eliot.lear> ok, let me go rustle up cyrus
[10:06:08] --- cyrus_daboo has joined
[10:06:14] <eliot.lear> welcome cyrus
[10:06:19] <bdesruisseaux> hi cyrus
[10:06:22] <cyrus_daboo> Hi
[10:06:29] <eliot.lear> we're just chatting about ways to warp my daughter ;-)
[10:06:40] <eliot.lear> we'll start in a moment or two more
[10:07:17] <cyrus_daboo> FYI for next week - I rarely get in before 9.30 am EST due to kid dropoff etc so 9 am start is hard...
[10:07:50] <eliot.lear> is this just for next week?
[10:07:59] <eliot.lear> or is it a normal problem?
[10:08:00] <cyrus_daboo> Every week...
[10:08:06] <eliot.lear> oh...
[10:08:12] <eliot.lear> that's a problem.
[10:08:33] <eliot.lear> and you two have a 10:00am call right?
[10:08:52] <bdesruisseaux> yes
[10:08:53] <cyrus_daboo> On Tuesdays - yes
[10:09:01] <eliot.lear> so what about wednesdays?
[10:09:14] <cyrus_daboo> That would be OK.
[10:09:23] <eliot.lear> bernard?
[10:09:31] <eliot.lear> and i'm thinking of 10am est
[10:09:41] <bdesruisseaux> I have staff meeting at 10:30 every week on wednesday
[10:09:48] <eliot.lear> or 9:30 if you prefer
[10:10:07] <eliot.lear> the earlier the better from my perspective
[10:10:16] <bdesruisseaux> 9:30 - 10:30 would work on wednesday
[10:10:22] <eliot.lear> cyrus?
[10:10:30] <cyrus_daboo> Fine.
[10:10:59] <eliot.lear> ok. done. here's the catch. i'll need aki to run next week as i can't make that time, just for next week, but i'm not the critical player here
[10:11:22] <eliot.lear> ok, let's agenda bash for just a moment
[10:11:30] <bdesruisseaux> before you do...
[10:11:37] <bdesruisseaux> do we have quorum??
[10:11:42] <eliot.lear> i was about to say...
[10:11:47] <eliot.lear> since we are only 3
[10:12:09] <eliot.lear> i think the best we can do today is go over where we are and what is opened and what we can take to the mailing list
[10:12:20] <eliot.lear> if we do this quickly we're done by 4:30
[10:12:26] <eliot.lear> (my time)
[10:12:30] <bdesruisseaux> Great
[10:13:00] <eliot.lear> so, let's start with 2445bis.
[10:13:07] <eliot.lear> i believe we still have one of jonathan
[10:13:11] <eliot.lear> 's
[10:13:14] <eliot.lear> issues opened
[10:13:20] <eliot.lear> but that we closed the other two.
[10:13:52] <eliot.lear> we should have closed all of nigel issues, but I think some email still needs to get sent by bernard on accepting his changes
[10:13:54] <bdesruisseaux> the potential issue with BYSETPOS is still open
[10:13:59] <eliot.lear> right
[10:14:02] <bdesruisseaux> yes
[10:14:31] <eliot.lear> bernard, you sent an email objecting to jonathan's proposal.
[10:14:45] <eliot.lear> i would like to understand whether this should block publication. that discussion will happen on list
[10:14:53] <eliot.lear> i will start it shortly
[10:15:11] <eliot.lear> what other issues do we have to resolve with 2445bis before calling it done?
[10:15:45] --- jonlennox has joined
[10:15:53] <eliot.lear> [waiting for bernard to reply]
[10:15:57] <eliot.lear> welcome jonathan
[10:16:21] <jonlennox> Morning
[10:16:29] <bdesruisseaux> I think I convinced Jonathan last week that we should not do the change he was proposing. I don't think that should block...
[10:16:41] <bdesruisseaux> Hi Jon! Good timing!
[10:16:47] <jonlennox> The DTEND DATE issue, you mean?
[10:16:50] <jonlennox> There was also the BYSETPOS issue.
[10:16:52] <bdesruisseaux> Yes
[10:17:10] <eliot.lear> i think we're talking about bysetpos
[10:17:57] <bdesruisseaux> Eliot: You were talking about my objection to Jon's proposal. That's the one about DTEND DATE
[10:18:27] <eliot.lear> oops. yes. sorry.
[10:18:28] <jonlennox> The DTEND DATE issue I can see not worrying about; the results are maybe a bit surprising but as you mentioned it's easy enough to construct your calendars so it's not a problem.
[10:18:52] <eliot.lear> if that's the case, let's move away from it.
[10:18:59] <jonlennox> The surprising behavior should maybe be mentioned explicitly, but that's an editorial issue.
[10:19:18] <eliot.lear> that leaves open what, then?
[10:19:38] <eliot.lear> [btw, aki says he can make next wed 9:30 - 10:30 est]
[10:19:55] <jonlennox> My question about BYSETPOS indicates that I think there's still confusion about what a "set" is.
[10:19:55] --- fabio.silva has joined
[10:20:08] <eliot.lear> welcome fabio
[10:20:29] <fabio.silva> hi, all!
[10:20:59] <eliot.lear> that would certainly be a problem.
[10:21:03] <eliot.lear> do others agree?
[10:21:04] <jonlennox> If you have a (2445 recurrence, ignoring the DTSTART restrictions) DTSTART=2007-08-15;FREQ=MONTHLY;BYDAY=FR;BYSETPOS=-1
[10:21:23] <jonlennox> Does that mean "the last friday of the month", or "the last friday before the 15th of the month"?
[10:21:59] <eliot.lear> how would you get the latter interpretation?
[10:22:15] <cyrus_daboo> Right _ I don't see how you can get the later.
[10:22:31] <jonlennox> You expand the "freq" to get the 15th of every month.
[10:22:58] <jonlennox> When you expand the BYDAY, you get one "set" of fridays corresponding to each recurrence of FREQ.
[10:23:08] <jonlennox> Then you pick the last one of each set.
[10:23:24] <eliot.lear> i see what you're saying. you're saying that BYSETPOS operates on the entire set, while the other interpretation excludes DTSTART from the operation. right?
[10:23:38] <cyrus_daboo> And BYDAY expands to every Friday in the month...
[10:23:49] <eliot.lear> [btw, i think we have enough of a quorum to discuss this]
[10:24:05] <bdesruisseaux> The RRULE:FREQ=MONTHLY;BYDAY=FR;BYSETPOS=-1 means the last Friday of the month, as such, according to the new restriction, DTSTART SHOULD specify a day that is a last friday of a month.
[10:24:54] <jonlennox> You're introducing a concept of "the month" which is definitely non-obvious.
[10:25:14] <eliot.lear> really?
[10:25:18] <jonlennox> I.e., does this mean that BYSETPOS in a FREQ=WEEKLY rule has to respect WKST?
[10:26:40] <cyrus_daboo> Yes.
[10:26:54] <bdesruisseaux> I think it should... but I don't believe that's written anywhere
[10:26:57] <jonlennox> That definitely needs to be explained.
[10:27:21] <eliot.lear> here is the most difficult question we seem to have: where?
[10:27:23] <cyrus_daboo> If you do RRULE:FREQ=WEEKLY;BYDAY=SU,SA;WKST=MO;BYSETPOS=-1, then you will get SU not SA.
[10:27:23] <jonlennox> If that's the case, though, my complaint about BYSETPOS alignment goes away.
[10:27:42] <eliot.lear> that seems reasonable
[10:27:43] <jonlennox> I think in the description of BYSETPOS.
[10:27:52] <jonlennox> It needs to define "the set".
[10:28:31] <jonlennox> We added some text to that effect, but it needs to be clarified that it starts at the *beginning* of the interval defined by the FREQ.
[10:28:53] <eliot.lear> bernard, can you find the right place and propose something to the list?
[10:28:55] <jonlennox> I.e. not the recurrence of the DTSTART, but at WKST or the numeric start.
[10:29:18] <bdesruisseaux> Eliot: I can *try* !
[10:29:27] <eliot.lear> ok, and here's more bad news
[10:29:31] <eliot.lear> we need a new draft.
[10:29:32] <cyrus_daboo> Examples on page 133 actually show that working in practice.
[10:29:44] <eliot.lear> but it doesn't have to happen quickly
[10:29:49] <eliot.lear> before ietf would be fine
[10:30:09] <eliot.lear> is that the last issue with 2445bis?
[10:30:40] <bdesruisseaux> :-) of course not!
[10:31:09] <eliot.lear> which issue, bernard, do you believe still requires resolution, to the point of holding up the document?
[10:31:11] <cyrus_daboo> The description of WKST says it is significant only in WEEKLY when INTERVAL is greater than 1. Actually it is significant if the INTERVAL is also 1. i.e. independent of interval.
[10:31:29] <cyrus_daboo> So I think we just need to remove the INTERVAL restriction and we are done.
[10:31:33] <bdesruisseaux> i was kidding! I think it's the last "tracked" issue that was left open
[10:31:39] <eliot.lear> ah. good.
[10:32:11] <bdesruisseaux> Cyrus: We should add that WKST also matters when BYSETPOS is used.
[10:32:23] <bdesruisseaux> Cyrus: I'd like to come back to your example... to make sure I understand...
[10:32:32] <eliot.lear> bernard, i think that's the only text we should add
[10:32:44] <bdesruisseaux> The example: RRULE:FREQ=WEEKLY;BYDAY=SU,SA;WKST=MO;BYSETPOS=-1 is pretty artificial (i.e., doesn't make much sense)
[10:33:08] <bdesruisseaux> If I understand correctly, the BYDAY rule part really is superfluous here.
[10:33:10] <bdesruisseaux> correct?
[10:33:19] <cyrus_daboo> Compare with RRULE:FREQ=WEEKLY;BYDAY=SU,SA;WKST=SU;BYSETPOS=-1
[10:33:51] <bdesruisseaux> My point here ... if you have FREQ=WEEKLY and BYSETPOS there is no reason to have BYDAY
[10:33:52] <bdesruisseaux> no?
[10:33:58] <cyrus_daboo> No - WEEKLY/BYDAY=X,Y means every X and Y day in the week.
[10:34:04] <bdesruisseaux> Unless you want to create an empty set...
[10:34:24] <jonlennox> There are probably more complex rules you could construct where it matters? Though you might need to throw in a BYMONTHDAY
[10:35:09] <eliot.lear> guys - what was the problem with the proposal to clarify BYSETPOS?
[10:35:12] <bdesruisseaux> BYDAY specifies specify week day... BYSETPOS with FREQ=WEEKLY also end up specifying a specific week day... Right?
[10:35:19] <eliot.lear> and specifically adding the text about WKST?
[10:35:37] <cyrus_daboo> OK, yes - BYDAY and BYSETPOS can do the same thing in a WEEKLY rule.
[10:35:39] <bdesruisseaux> Eliot: Just trying to make sure I understand...
[10:35:51] <eliot.lear> ok. do you?
[10:36:00] <jonlennox> Eliot: we're trying to construct an example where it would actually be necessary.
[10:36:20] <eliot.lear> ok, now i understand
[10:36:35] <bdesruisseaux> It seems that BYSETPOS with FREQ=WEEKLY is pretty useless... :-)
[10:37:03] <eliot.lear> well, it's redundant
[10:37:20] <bdesruisseaux> Just use BYDAY and be done with it...
[10:37:41] <eliot.lear> ok, if we understand this issue, can we move along?
[10:37:54] <cyrus_daboo> But we should not require that restriction. If I want to use BYSETPOS or BYDAY or both I should be able to.
[10:38:09] <jonlennox> Bernard: possibly if you were intersecting with a BYMONTHDAY, though it would still be an odd way to write the rue.
[10:38:11] <jonlennox> rule.
[10:38:12] <cyrus_daboo> Yes - there are always multiple ways to generate the same set in RRULE!
[10:38:21] <bdesruisseaux> BYSETPOS is only useful for interval with varying number of days (YEAR, MONTH, ...)
[10:39:04] <cyrus_daboo> And BYHOUR on DST transition days!
[10:39:12] <bdesruisseaux> that was my "..."
[10:39:15] <cyrus_daboo> s/BYHOUR/HOURLY/
[10:39:29] <eliot.lear> so then do we need any clarifying text or not?
[10:39:40] <eliot.lear> if we've agreed it makes no difference?
[10:40:08] <bdesruisseaux> 1- Clarify what a set is. 2- Clarify that WKST matters for BYSETPOS... but gee... that's useless... so do we need to talk about it?
[10:40:18] <cyrus_daboo> I think the statement about when BYSETPOS is useful would be handy. Perhaps add some notes to the table.
[10:40:34] <bdesruisseaux> There we go! More notes in the table! :-)
[10:40:42] <eliot.lear> no more notes in the table please.
[10:40:48] <bdesruisseaux> lol
[10:41:11] <eliot.lear> at most a comment about when BYSETPOS is useful
[10:41:17] <eliot.lear> and now can we move on please?
[10:41:43] <bdesruisseaux> cool
[10:41:53] <eliot.lear> jonathan? cyrus?
[10:41:55] <eliot.lear> fabio?
[10:41:58] <eliot.lear> all good to go?
[10:42:02] <jonlennox> I'm okay
[10:42:22] <cyrus_daboo> Right now the BYSETPOS row in the table shows 'Limit' for all FREQ values. We could just put N/A for SECONDLY, MINUTELY, DAILY, WEEKLY.
[10:42:37] <cyrus_daboo> But a comment is fine too.
[10:42:45] <eliot.lear> then let it be a comment please
[10:43:05] <fabio.silva> ok
[10:43:07] <eliot.lear> let me take a moment to tell you all what will ahppen next.
[10:43:35] <eliot.lear> aki and i have agreed that he will take rfc2445bis through the sheparding process.
[10:44:13] <eliot.lear> he will do a detailed reading and raise questions where he thinks it's appropriate. i suspect at this point that he will largely ask clarifying questions
[10:44:30] <eliot.lear> the sooner he has the next rev of the draft the sooner he can start this review
[10:44:37] <eliot.lear> questions?
[10:44:40] <bdesruisseaux> I hear you
[10:45:02] <bdesruisseaux> My only concern would be... what about the issues iTIP will raise?
[10:45:09] <cyrus_daboo> OK, but bear in mind there may still be mods to 2445bis driven by 2446bis issues (e.g. moving description of when SEQUENCE changes into 2446bis).
[10:45:15] <eliot.lear> we are aware
[10:45:20] <bdesruisseaux> For instance, the text about the SEQUENCE should probably disappear
[10:45:28] <eliot.lear> we'll get to that next.
[10:45:35] <cyrus_daboo> OK. Then I think Aki doing a full-up review at this stage is a good idea.
[10:46:01] <cyrus_daboo> Further changes to 2445bis are likely to be small deltas.
[10:46:08] <eliot.lear> let's all stop for just a moment and congratulate first bernard and then ourselves for making it to this point
[10:46:11] <bdesruisseaux> Oh!
[10:46:15] <bdesruisseaux> Issue 63!
[10:46:15] <eliot.lear> congratulations, bernard!
[10:46:20] <bdesruisseaux> We need it for iTIP!
[10:46:54] <bdesruisseaux> We need to allow RDATE to be less than DTSTART
[10:47:15] <eliot.lear> well, apparently i was a bit premature there
[10:47:35] <bdesruisseaux> Yes, you can take your words back!
[10:47:40] <eliot.lear> ;-)
[10:48:17] <bdesruisseaux> Cyrus: What's your take on issue 63?
[10:48:50] <bdesruisseaux> Putting you on the spot as the Editor of iTIP... and the raiser of issue... 85 I believe which is related!
[10:48:55] <cyrus_daboo> I see no reason why RDATE should not be allowed to be less than DTSTART, irrespective of any need in iTIP.
[10:49:10] <eliot.lear> there is one person who objects. it's george sexton.
[10:49:29] <eliot.lear> his objection is based on the counter-intuitive nature of the change
[10:49:47] <cyrus_daboo> I still think we have not closed the issue about whether RANGE=, RDATE<DTSTART, or some other mechanism is needed to deal with range changes in iTIP.
[10:49:56] <cyrus_daboo> I know Bernard thinks its closed!
[10:50:13] <bdesruisseaux> Wow! I didn't know that!
[10:50:46] <bdesruisseaux> Let me clarify, I'd rather not re-introduce the RANGE parameter...
[10:50:47] <cyrus_daboo> Well I think you're definitely voting for not having RANGE= come back...
[10:51:15] <bdesruisseaux> I've tried to find all the use cases where it was/is believe that RANGE is needed... and found alternatives to do without RANGE...
[10:51:52] <cyrus_daboo> The question is whether those alternatives are palatable.
[10:52:23] <bdesruisseaux> I'm worried we will not have great interoperability with RANGE.
[10:52:47] <eliot.lear> we have consensus to remove RANGE
[10:53:05] <eliot.lear> that is clear from the list
[10:53:19] <bdesruisseaux> On the other hand the alternative are useing simple brute force... SImple is known to work!
[10:53:43] <eliot.lear> i'd like to come back to issue 63
[10:54:15] <cyrus_daboo> Except that it poses scalability questions. Sending the entire set (including data for events in the past that you really don't care about) is not going to scale to 100's attendees and lots of instances.
[10:54:19] <eliot.lear> i'm willing to call this VERY rough consensus, but rough enough.
[10:54:45] <cyrus_daboo> OK, on 63 I think that is fine regardless of iTIP.
[10:55:15] <eliot.lear> then we're closed on issue 63.
[10:55:18] <eliot.lear> back to issue 48
[10:55:57] <eliot.lear> let me ask you this, cyrus: do you implement RANGE?
[10:57:54] <eliot.lear> here is a comment from jeffrey harris:
[10:57:55] <eliot.lear> +1 to deprecating RANGE. While we lose some semantic power, itsimplifies life, and I think the major use cases for RANGE can behandled by just re-issuing a truncated version of the old event plus anew event. This is what several clients already do.
[10:58:05] <eliot.lear> is that a reasonable approach to the scaling problem?
[10:58:19] <bdesruisseaux> Yes!
[10:58:33] <bdesruisseaux> But it brings new issues that were discussed at the list IETF meeting...
[10:58:34] <cyrus_daboo> Not sure what iCal does. On a simple unbounded recurrence where you change the time going forward, it truncates the old one and creates a new one.
[10:58:41] <bdesruisseaux> s/list/last/
[10:58:48] <eliot.lear> sounds familiar!
[10:59:00] <eliot.lear> then let's please let this sleeping dog liew
[10:59:04] <eliot.lear> s/w//
[10:59:05] <bdesruisseaux> Cyrus: Last time I checked, iCal was breaking the meeting in two... Just like Jeffrey is mentionning
[11:00:06] <eliot.lear> guys: i come back to what i said earlier. barring howls from cyrus over that last issue, i'd like to close RFC 2445bis (excepting issues with 2446bis)
[11:00:11] <bdesruisseaux> Mind you... breaking a meeting in two parts is fine when you are the organizer
[11:00:17] <bdesruisseaux> but not when your're the attendee
[11:00:36] <eliot.lear> and with that i also need to close this jabber session.
[11:00:55] <eliot.lear> in those immortal words, "take it to the list". but i hope we're done.
[11:00:55] <cyrus_daboo> Exactly as an attendee I might want to say I will attendee all the meetings from some point on, but not the ones before.
[11:01:34] <bdesruisseaux> and right now your client will break the meeting in two... change the UID of one of them... and God knows what the organizer will receive!
[11:01:35] <bdesruisseaux> :-)
[11:01:48] <cyrus_daboo> YUP!
[11:01:56] <eliot.lear> see you all next wednesday in the chat.
[11:02:00] --- eliot.lear has left
[11:02:04] <cyrus_daboo> Actually I am not sure what happens in the iTIP case.
[11:02:13] <cyrus_daboo> Will experiment...
[11:02:27] <bdesruisseaux> Send me a report! I'm interested!
[11:02:29] <bdesruisseaux> Cheers!
[11:02:32] --- bdesruisseaux has left
[11:03:04] <jonlennox> Later!
[11:03:06] --- jonlennox has left
[11:04:04] --- cyrus_daboo has left
[11:26:12] --- fabio.silva has left