[09:46:04] --- mikeadouglass has joined
[09:56:53] --- eliot.lear has joined
[09:57:05] <eliot.lear> good afternoon
[09:57:45] <mikeadouglass> Good morning
[09:57:55] <eliot.lear> howdy and welcome!
[09:58:35] <mikeadouglass> Thought it was about time I joined
[09:59:04] <eliot.lear> good. we'll agenda bash in about 5 minutes. people mostly join at the last minute
[10:00:12] --- bdesruisseaux has joined
[10:00:18] <eliot.lear> hi bernard!
[10:00:23] <bdesruisseaux> Hi!
[10:00:26] <bdesruisseaux> Hi Mike!
[10:00:34] <mikeadouglass> Hi Bernard
[10:00:41] <eliot.lear> how was CalConnect?
[10:01:04] <bdesruisseaux> People have commented that it was the best roundtable ever!
[10:01:13] <eliot.lear> excellent!
[10:01:20] <eliot.lear> anything to bring back to calsify?
[10:01:25] <bdesruisseaux> We did 3 demos.
[10:01:29] <eliot.lear> nice
[10:02:01] <bdesruisseaux> 1- CalDAV calendar-schedule 2- Server to server scheduling 3- Free Busy URL
[10:02:17] <eliot.lear> very nice
[10:02:52] <eliot.lear> ok, we'll wait just a few more moments for cyrus to get on. i see he's online
[10:03:52] --- cyrus_daboo has joined
[10:03:59] <eliot.lear> hi cyrus and welcome
[10:04:15] <cyrus_daboo> Hi
[10:04:29] <eliot.lear> ok, let's agenda bash for a moment
[10:04:36] <eliot.lear> 1. 2445bis status
[10:04:40] <eliot.lear> 2. 2446 issues
[10:04:44] <eliot.lear> 3 aob
[10:05:04] <eliot.lear> n.b., we obviously don't have a lot of folks on, so we'll need to take stuff to the list
[10:05:09] <eliot.lear> objections to agenda?
[10:05:14] <bdesruisseaux> nope
[10:05:20] <cyrus_daboo> That's fine.
[10:05:24] <mikeadouglass> OK
[10:05:32] <eliot.lear> alexey can't make it today, and we'll need to find a better time for aki
[10:05:50] <eliot.lear> so let's put that last one as part of aob
[10:06:16] <eliot.lear> starting with 2445bis, i think we have two outstanding issues from nigel
[10:06:31] <eliot.lear> bernard does that sound right?
[10:07:02] <bdesruisseaux> Yes
[10:07:18] <bdesruisseaux> + Issue 63, + Cyrus comments on STANDARD and DAYLIGHT
[10:07:26] <bdesruisseaux> + last comment from Jon
[10:07:42] <bdesruisseaux> + previous last calls comments from Jon (partially addressed)
[10:07:45] <eliot.lear> did anyone require that issue 63 get dealt with?
[10:08:34] <bdesruisseaux> Who cares about me?
[10:08:36] <bdesruisseaux> :-)
[10:08:47] <eliot.lear> bernard, do you have a proposal to close the issue?
[10:09:01] <bdesruisseaux> Seriously, issue 63 is important in the context of iTIP with the removal RANGE
[10:09:25] <eliot.lear> ok, but we need proposed text.
[10:09:31] <cyrus_daboo> Agreed. At this point I think it will be required for iTIP.
[10:09:35] <bdesruisseaux> I raised the issue 3 times already! The proposal is to clarify that RDATE may be less than DTSTART
[10:10:28] <bdesruisseaux> I understand that cyrus will reply with "+1" on the list? :-)
[10:10:30] <eliot.lear> {i'm reviewing}
[10:10:46] <cyrus_daboo> BTW Bernard: its true that EXDATE >= DTSTART right?
[10:11:02] <cyrus_daboo> i.e. You should never have an RDATE and EXDATE being the same value.
[10:11:26] --- fabio.silva has joined
[10:11:28] <cyrus_daboo> Is that actually stated: 'no EXDATE for a matching RDATE'?
[10:11:33] <bdesruisseaux> Cyrus, nope!
[10:11:43] <bdesruisseaux> Actually iCalendar makes it clear that EXDATE can exclude DTSTART
[10:12:10] <eliot.lear> gentlemen, i see Bernard's message of August 3rd being the last message about issue 63
[10:12:11] <bdesruisseaux> I believe you could have EXDATE match an RDATE... in that case the EXDATE would exclude the RDATE. Why do you ask?
[10:12:19] <eliot.lear> and i see no follow ups to that message
[10:12:31] <cyrus_daboo> That seems silly - just remove the RDATE.
[10:13:25] <bdesruisseaux> Eliot: My mail of Sept 14 mentions that issue 63 is important for issue 85 (iTIP)
[10:13:43] <eliot.lear> i believe you, but i'm trying to find consensus about i63
[10:13:56] <bdesruisseaux> Cyrus: I don't disagree, but I don't think any change is required... at this time.
[10:13:58] <eliot.lear> so it seems like i need to highlight that one and send out a note for comment.
[10:14:12] <bdesruisseaux> Eliot: Right. Please do.
[10:14:17] <cyrus_daboo> I think if we are clarifying RDATE we should do the same for EXDATE.
[10:14:49] <eliot.lear> As to Cyrus' comments on DAYLIGHT and STANDARD, those are non-controversial. can you make the change?
[10:15:14] <bdesruisseaux> Yes, for DAYLIGHT and STANDARD
[10:15:26] <eliot.lear> good. now let's go back to nigel's comments
[10:15:31] <cyrus_daboo> FYI that was the only real issue I found with using the new IANA templates in the VAVAILABILITY spec, so other than that I think they are OK.
[10:15:38] <bdesruisseaux> Cyrus: I guess we ought to clarify that EXDATE can also be less than DTSTART
[10:16:16] <eliot.lear> text, then, please.
[10:16:19] <eliot.lear> now going back to nigel
[10:16:27] <cyrus_daboo> If we allow EXDATE == RDATE then that would have to be true. If instead we say that you never have an EXDATE equal to RDATE - you just remove the RDATE, then that would not be true.
[10:17:14] <eliot.lear> i refer you to nigel's message of 21-Sep. Does everyone have it?
[10:18:32] <eliot.lear> hmm. should i take that as a "no"?
[10:18:46] <eliot.lear> we are in Section 3.3.10
[10:18:51] <bdesruisseaux> Digging for the mail
[10:19:34] <cyrus_daboo> I don't see anything from Nigel on 21 Sep.
[10:19:59] <eliot.lear> cyrus, what's your preferred email address right now?
[10:20:07] <cyrus_daboo> cyrus@daboo.name [mailto:cyrus@daboo.name]
[10:20:12] <eliot.lear> (anyone else want a copy?)
[10:20:22] <eliot.lear> (here it comes)
[10:20:41] <cyrus_daboo> Got it - almost as fast as IM!
[10:20:49] <eliot.lear> astonishing, given cisco servers
[10:20:54] <eliot.lear> bernard, got a copy?
[10:21:17] <bdesruisseaux> It was not on the list right? http://lists.osafoundation.org/pipermail/ietf-calsify/2007-September/thread.html
[10:21:32] <bdesruisseaux> My thunderbird is frozen for some reasons...
[10:21:47] <eliot.lear> ok, let me send you a quick copy
[10:23:21] <eliot.lear> nigel is concerned, firstly about the requirement for UTC in the DATE-TIME value
[10:24:49] <cyrus_daboo> Well he agrees with the requirement - he is simply complaining that the text repeats itself.
[10:25:02] <eliot.lear> and it is difficult to read
[10:25:04] <eliot.lear> and i agree
[10:25:23] <eliot.lear> i think it is repetitive
[10:25:37] --- jonlennox has joined
[10:25:54] <eliot.lear> hi jonathan! great timing. we'll get to you next!
[10:26:16] <eliot.lear> bernard, got the email yet?
[10:26:47] <jonlennox> Sorry I'm late -- xmpp.us's jabber server seems to be down, so I had to create myself a new account
[10:26:58] <eliot.lear> no worries. glad you're here
[10:27:13] <bdesruisseaux> Yep, got the mail.
[10:27:28] <eliot.lear> so there are three issues with nigel's 21 sep email
[10:27:45] <eliot.lear> 1 is readability of that one paragraph, and the one sentence.
[10:28:13] <cyrus_daboo> It is repetitive. I'm thinking that breaking out each requirement into a bulleted list would expose those duplicates and allow us to simply it a bit and make the requirements a little clearer. However, that would be a new formatting "style" for this section and would need to be applied to the other paragrphs as well.
[10:28:32] <eliot.lear> bernard?
[10:29:40] <cyrus_daboo> Another option would be a table...
[10:29:55] <eliot.lear> i don't think the last table actually helped, mind you
[10:30:09] <eliot.lear> or at least it didn't drive consensus
[10:30:19] <bdesruisseaux> The issue here is info repeated in more than one place in the spec..
[10:30:29] <eliot.lear> right
[10:30:37] <bdesruisseaux> It's hard to draw the line...
[10:30:50] <bdesruisseaux> The section on VTIMEZONE talks about UNTIL...
[10:31:02] <eliot.lear> but here the paragraph is very difficult to read
[10:31:07] <bdesruisseaux> I believe UNTIL should talk about UNTIL... right? :-)
[10:31:39] <eliot.lear> i think the fundamental issue here is readability, and not duplication.
[10:32:44] <bdesruisseaux> Okay, I'll take the action item to propose a rewrite on the paragraph.
[10:32:48] <bdesruisseaux> Let's take this to the list.
[10:32:59] <eliot.lear> ok.
[10:33:24] <cyrus_daboo> To be honest with you both the FREQ and INTERVAL paragraphs above could do with some tidy up too. I will propose some minor tweaks.
[10:33:50] <eliot.lear> thank you. if they're editorial, bernard you can include them without further discussion.
[10:33:57] <eliot.lear> but be sure they are...
[10:34:08] <bdesruisseaux> will do
[10:34:16] <cyrus_daboo> No change to meaning - just tidy up and clarification.
[10:34:21] <eliot.lear> right
[10:34:31] <eliot.lear> this brings us to nigel's next point which is substantial
[10:34:35] <eliot.lear> BYSETPOS
[10:34:51] <eliot.lear> here i think i can call for consensus.
[10:35:02] <eliot.lear> either people will agree or disagree, but a consensus is needed for the change.
[10:35:06] <eliot.lear> what do you think?
[10:37:15] <eliot.lear> hello?
[10:37:24] <cyrus_daboo> just re-reading...
[10:37:40] <bdesruisseaux> Nigel doesn't like the text that was added based on a proposal from Jon if I'm not mistaken...
[10:38:22] <cyrus_daboo> I agree that specifically calling out weekly, monthly and yearly mis-represents the fact that secondly, minutely and hourly are valid too.
[10:39:05] <bdesruisseaux> See: http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001383.html
[10:39:05] <eliot.lear> Should we propose that the sentence start with "For example,"
[10:39:06] <eliot.lear> ?
[10:39:11] <jonlennox> Which e-mail should I be looking at here?
[10:39:25] <eliot.lear> that of nigel swinsen's dated 21 september
[10:39:26] <bdesruisseaux> Actually, Jon was reporting text from Eric Busboom
[10:39:56] <cyrus_daboo> Right - but that doesn't make it right!
[10:39:57] <jonlennox> I don't know that I got that one.
[10:40:08] <eliot.lear> (it's heading to your columbia address now)
[10:40:16] <jonlennox> Thanks
[10:40:20] <eliot.lear> then what is wrong?
[10:40:34] <eliot.lear> is the reasoning inductive or not?
[10:40:49] <cyrus_daboo> What is wrong is that it only specifies weekyl, monthly and yearly in the text.
[10:41:02] <cyrus_daboo> A better solution might be to simply say:
[10:41:21] <cyrus_daboo> 'For example, in a WEEKLY rule, the interval would be one week'
[10:41:39] <eliot.lear> ok, we agree.
[10:41:42] <jonlennox> I agree too
[10:41:46] <cyrus_daboo> And leave it at that. The 'For example' prefix does not imply that it is only restricted to WEEKLY.
[10:41:46] <eliot.lear> bernard?
[10:42:21] <bdesruisseaux> I agree!
[10:42:35] <eliot.lear> ok.
[10:42:38] <eliot.lear> next
[10:42:53] <eliot.lear> that leaves that big table.
[10:43:34] <eliot.lear> it looks like for this one i need to come up with a crisp way to present both sides and then send that to the list. does that seem about right?
[10:44:27] <eliot.lear> i think we need a consensus call for the change. but he's right about this being important
[10:44:40] <eliot.lear> comments, please?
[10:44:41] <cyrus_daboo> To be clear: Nigel is just suggesting removing the 'Note' items and adding some generic text instead.
[10:44:45] <cyrus_daboo> Right?
[10:44:50] <eliot.lear> yes
[10:44:52] <bdesruisseaux> Yes
[10:45:01] <eliot.lear> again, this is a clarity thing
[10:45:14] <bdesruisseaux> While I don't really like the notes... I haven't seen a better way to present the info so far
[10:45:35] <eliot.lear> so i take it you object to his suggested changes?
[10:45:57] <cyrus_daboo> Well Nigel's text does do a better job of explaining exactly what "special expand" in the Notes actually means.
[10:46:19] <bdesruisseaux> I found that merging the cells was more confusing
[10:46:43] <eliot.lear> i don't agree. i think it adds readibility. but that's not my concern right now. my concern is the text. i don't care so much about the merging of cells
[10:47:21] <cyrus_daboo> Maybe we keep the notes but explicitly spell out what "special expand" means in each case.
[10:47:37] <cyrus_daboo> That will add a lot of text but will be clearer.
[10:47:37] <eliot.lear> bernard, do you object to nigel's text?
[10:48:23] <bdesruisseaux> I don't mind
[10:48:35] <eliot.lear> can you send a note indicating that?
[10:48:40] <eliot.lear> what do others think?
[10:48:54] <eliot.lear> cyrus, i take it that your comments support nigel's changes?
[10:49:00] <eliot.lear> fabio? mike?
[10:49:04] <eliot.lear> jonathan?
[10:49:32] <cyrus_daboo> Minor formatting issue: I still think the table cell's should show 'Note' and then Nigel's text is the only 'Note'.
[10:49:47] <eliot.lear> ok.
[10:50:03] <cyrus_daboo> But what he has written is a reasonable description of what happens.
[10:50:07] <eliot.lear> please let's take this to the list and support those changes. by my count, we've agreed with each issue he's raised here.
[10:50:25] <eliot.lear> we now need to move to jonathan's messages.
[10:50:41] <bdesruisseaux> My understanding is that we change Note 1 and Note 2 to "See Note" and use Nigel's text as the Note.
[10:50:43] <bdesruisseaux> Right?
[10:50:52] <cyrus_daboo> Yes.
[10:50:54] <eliot.lear> right, but you need to send that to the list
[10:51:13] <bdesruisseaux> Ok
[10:51:38] <eliot.lear> so, now i am looking at jonathan's message of august 13
[10:52:07] <cyrus_daboo> Which one?
[10:52:08] <jonlennox> I think I actually sent three that day
[10:52:18] <eliot.lear> first is 3.3.6 DURATION
[10:52:41] <eliot.lear> proposal is to add text
[10:52:49] <eliot.lear> + If the local time when a nominal duration would end does not exist,+ or occurs more than once, in the duration's timezone, it is+ interpreted in the same manner as an explicit DATE-TIME value+ describing that date and time, as specified in section 3.3.5.
[10:53:05] <eliot.lear> comments, please?
[10:53:12] <jonlennox> Obviously I'm in favor. :-)
[10:53:16] <eliot.lear> ;-)
[10:53:32] <eliot.lear> "judge, how do you plead?" "not guilty. case dismissed.
[10:53:33] <jonlennox> This is the "P1D one day before a DST shift" problem.
[10:53:35] <eliot.lear> ;-)
[10:56:03] <eliot.lear> comments?
[10:56:13] <bdesruisseaux> I'm okay
[10:56:28] <eliot.lear> others?
[10:57:02] <cyrus_daboo> I don't like the text "duration's timezone". A duration does not itself have a timezone, rather the time being altered by the duration does.
[10:57:25] <jonlennox> As long as the idea is there I'm fine with wordsmithing for clarity.
[10:57:51] <eliot.lear> s/duration/event's/?
[10:58:11] <bdesruisseaux> Couldn't we strike (remove) /in the duration's timezone,/ ?
[10:58:53] <jonlennox> Well, I want it to be clear that it's timezone issues we're talking about here. "Local time" implies it but I like calling it out.
[10:58:57] <jonlennox> I'm good with Eliot's suggeston.
[10:59:22] <cyrus_daboo> Except that duration is used beyond just VEVENTs.
[10:59:26] <bdesruisseaux> can't say 'event' needs to be 'calendar component' I think
[10:59:32] <bdesruisseaux> right
[11:00:20] <eliot.lear> that's awkward, but i'm okay with it. bernard, can we leave it to you to wordsmith?
[11:00:24] <cyrus_daboo> Plus saying 'duration would end' is wrong to as a negative duration actually specifies a start time.
[11:00:26] <eliot.lear> we don't need a committee on this one
[11:00:31] <jonlennox> This is getting complex enough that I'm tempted to go with bernard's suggestion instead.
[11:00:54] <eliot.lear> if you're okay with that, jonathan, then we're done
[11:01:03] <eliot.lear> (with that issue)
[11:01:14] <cyrus_daboo> I don't like Bernard's solution. So I guess I need to propose something myself...
[11:01:23] <eliot.lear> ok
[11:01:40] <eliot.lear> but let's not stew on this one.
[11:01:53] <eliot.lear> let's go to the text below, which is of more concern
[11:02:02] <eliot.lear> can people stay on for a while longer?
[11:02:12] <jonlennox> I'm okay
[11:02:13] <bdesruisseaux> Ok, so Cyrus will propose text to the list. Now my question, where do we add the text?
[11:02:35] <bdesruisseaux> Near the end of the Description of the DURATION value type (section 3.3.6) ?
[11:02:48] <eliot.lear> that's what i was thinking
[11:02:50] <jonlennox> I think that makes the most sense
[11:03:04] <bdesruisseaux> good
[11:03:28] <cyrus_daboo> If the local time determined by adding a nominal duration to a date-time value does not exist, or occurs more than once, in the timezone of the date-time value used, it is interpreted in the same manner as an explicit DATE-TIME value describing that date and time, as specified in section 3.3.5.
[11:03:36] <cyrus_daboo> That's what I propose!
[11:03:53] <eliot.lear> cyrus, can you cut and paste that in a response to jonathan and the list?
[11:03:55] <jonlennox> That works for me
[11:04:01] <cyrus_daboo> Will do.
[11:04:04] <eliot.lear> thanks
[11:04:33] <eliot.lear> are we pulling our definitions from ISO 8601.2004?
[11:04:52] <jonlennox> "nominal", "accurate", and "exact" durations, you mean?
[11:04:57] <eliot.lear> yep
[11:06:01] <jonlennox> That's not freely available anywhere, is it?
[11:06:08] <bdesruisseaux> sorry... back to cyrus's proposal... what if the DTSTART was a local date-time ?
[11:06:11] <eliot.lear> no. USD $126
[11:06:16] <bdesruisseaux> not UTC, no TZID !
[11:07:21] <cyrus_daboo> If there is no TZID you have no idea about discontinuities etc except by applying your default "calendar" timezone to the values.
[11:07:47] <cyrus_daboo> Sure we could go into that in a lot more detail but I think that would make matters worse.
[11:08:05] <eliot.lear> yep
[11:09:00] <bdesruisseaux> s/in the timezone of the date-time value used/in the time zone being used/
[11:09:11] <cyrus_daboo> My text "in the timezone of the date-time value used" can be applied to either local, utc or floating time. For the later its is the "calendar" timezone being used to calculate floating.
[11:09:12] <bdesruisseaux> that would address this...
[11:09:38] <cyrus_daboo> Sure that would be OK. Since I have already sent my text to the list you will have to correct my email messaged!
[11:09:47] <eliot.lear> please do
[11:09:53] <eliot.lear> are we ready to move on?
[11:09:53] <bdesruisseaux> and you will agree :-) ?
[11:10:09] <cyrus_daboo> If I am in a good mood ;-)
[11:10:17] <bdesruisseaux> lol
[11:10:20] --- eliot.lear has left
[11:11:44] --- mikeadouglass has left
[11:11:56] --- eliot.lear has joined
[11:12:26] <eliot.lear> ok
[11:12:27] <eliot.lear> sorry about that
[11:12:32] <eliot.lear> can we move on?
[11:12:42] <eliot.lear> i'd like to get back to the nomina/accurate definitions
[11:12:43] <cyrus_daboo> Sure, but I don't have much more time...
[11:12:56] <eliot.lear> they're not well specified. jonathan is correct
[11:12:58] <cyrus_daboo> Lets try and finish the 2445 issues though
[11:13:01] <eliot.lear> and that will be come an issue
[11:13:20] <eliot.lear> so either they're being referenced from the iso spec or we have to clearly define them
[11:13:21] <eliot.lear> which is it?
[11:13:46] <jonlennox> My inclination would be to define them; we don't normatively reference the ISO spec otherwise.
[11:13:50] <jonlennox> I don't think
[11:13:58] <cyrus_daboo> I think its an important enough concept that we should define it here - or at least summarize the ISO definition.
[11:14:40] <eliot.lear> if we mean to use them then we should reference them.
[11:14:55] <bdesruisseaux> We only have this statement right now: > The format can represent nominal durations (weeks and days) and accurate durations (hours, minutes, and seconds).
[11:15:13] <bdesruisseaux> section 3.3.6
[11:15:51] <eliot.lear> well, but you use it
[11:16:19] <eliot.lear> so
[11:16:22] <eliot.lear> your choice
[11:16:30] <eliot.lear> my concern is this:
[11:16:42] <eliot.lear> we do not want to use terms that sound like ISO definitions but aren't
[11:16:45] <eliot.lear> that will confuse people more
[11:16:52] <eliot.lear> it has to be exact
[11:16:55] <jonlennox> We also use the term "exact duration", which isn't defined anywhere I don't think.
[11:17:12] <bdesruisseaux> I believe exact should be 'accurate'
[11:17:49] <jonlennox> I'm not sure it's the same concept
[11:17:55] <bdesruisseaux> 2.1.7 nominal duration duration expressed amongst others in years, months, weeks or days NOTE The duration of a calendar year, a calendar month, a calendar week or a calendar day depends on its position in the calendar. Therefore, the exact duration of a nominal duration can only be evaluated if the duration of the calendar years, calendar months, calendar weeks or calendar days used are known.
[11:18:42] <eliot.lear> 2.1.7?
[11:18:51] <jonlennox> Of 8601 I assume you mean?
[11:19:07] <bdesruisseaux> 8601 !
[11:19:11] <eliot.lear> ah
[11:19:17] <eliot.lear> ok. then you need to make a more clear reference
[11:19:20] <eliot.lear> to each term you use
[11:19:27] <eliot.lear> sorry - for each term you use
[11:19:31] <eliot.lear> that's not clear enough.
[11:19:49] <jonlennox> Does 8601 define "exact duration"?
[11:19:54] <jonlennox> Since it uses it there?
[11:19:54] <bdesruisseaux> 4.4.3 Duration General Duration can be expressed by a combination of components with accurate duration (hour, minute and second) and components with nominal duration (year, month, week and day). The term duration will be used to designate expressions containing components with accurate duration, with nominal duration, or both.
[11:20:17] <bdesruisseaux> After re-reading here's my understand...
[11:20:41] <bdesruisseaux> Duration components can be either nominal or accurate...
[11:21:28] <bdesruisseaux> When you evaluate a duration from a given position in the calendar you obtain an exact duration..
[11:22:05] <eliot.lear> hahah 8601 doesn't properly define "exact duration"
[11:22:16] <eliot.lear> but you come as close as is needed since you tell everyone how to calculate it
[11:22:52] <eliot.lear> looking at 8601, you pretty much did cut and paste the definition
[11:22:56] <eliot.lear> (s)
[11:23:25] <jonlennox> Bernard: that's my understanding as well
[11:24:32] <eliot.lear> i don't see any text changes here
[11:24:42] <eliot.lear> does anyone else?
[11:25:37] <jonlennox> I'd either add a definition of "exact duration" (even though 8601 doesn't use it) or else replace our use of the term with something more expanded.
[11:25:51] <jonlennox> Er, doesn't provide it
[11:26:17] <bdesruisseaux> I could add a sentence about "exact duration"...
[11:26:38] <jonlennox> Especially since the wording where we use it is that recurrences of events specified by DTEND/DTSTART use the same exact duration.
[11:27:16] <eliot.lear> bernard, if you would add a definition, that would be fine.
[11:27:25] <eliot.lear> moving on
[11:27:34] <eliot.lear> that text will need to be sent to the list, of course
[11:27:37] <jonlennox> Okay
[11:28:10] <eliot.lear> this brings us to jonathan's second message
[11:28:36] <eliot.lear> (although please note the editorials in the first message)
[11:28:39] <jonlennox> The problem of aligning a rule with BYSETPOS=-1 with DTSTART
[11:29:45] <cyrus_daboo> Jonathan's analysis is right.
[11:30:01] <cyrus_daboo> Not sure about the best way to fix it though...
[11:30:58] <cyrus_daboo> Actually, no I take that back. I need to think some more about this.
[11:31:30] <cyrus_daboo> Jonathan can you give an example of a rule where it is not OK for DTSTART to match the first instance when BYSETPOS is used?
[11:31:57] --- fabio.silva has left
[11:32:10] <jonlennox> Well, I think this actually gets into the issue of what the "set" is in BYSETPOS.
[11:32:50] <bdesruisseaux> I will have to go soon...
[11:33:00] <jonlennox> I was under the impression that it was recurrences based on the FREQ of the time specified by DTSTART.
[11:33:25] <jonlennox> I.e. if DTSTART is a Tuesday in a WEEKLY rule, a new set starts every Tuesday.
[11:33:53] <jonlennox> And then BYSETPOS=-1 means "the last event before Tuesday".
[11:34:09] <jonlennox> Changing DTSTART changes the definition of the rule.
[11:35:04] <cyrus_daboo> But you have to have another BYxxx part present when BYSETPOS is used.
[11:35:24] <cyrus_daboo> So doesn't that other BYxxx part "pin" the DTSTART?
[11:35:52] <jonlennox> Hmm.
[11:35:57] <jonlennox> Yes, probably.
[11:36:02] <bdesruisseaux> That other BYxxx would need to include the DTSSTART
[11:36:25] <bdesruisseaux> Jon, can you provide an example RRULE that is problematic ?
[11:37:16] <eliot.lear> guys - i have to go shortly.
[11:37:19] <jonlennox> Not off the top of my head; I'd have to construct it.
[11:37:36] <eliot.lear> jonathan, if you're okay with doing that, let's not make a change for now.
[11:37:45] <eliot.lear> and let's see what you come up with
[11:37:54] <jonlennox> Okay.
[11:38:05] <bdesruisseaux> If we have RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
[11:38:29] <bdesruisseaux> then DTSTART would need itself to be a last work day of a month...
[11:39:11] <jonlennox> This gets into the definition of the "set" again. If it restarts at the beginning of the unit proper, not at the recurrence of DTSTART, there's no problem.
[11:40:10] <bdesruisseaux> I don't get it! SOrry!
[11:40:10] <eliot.lear> guys, can you send me your availability for the next week so that i can sync with aki on a new time?
[11:40:12] <jonlennox> (Obviously you have to use WKST for WEEKLY.)
[11:40:47] <bdesruisseaux> Eliot: You want to schedule the session earlier right?
[11:40:53] <eliot.lear> i think aki does
[11:41:03] <eliot.lear> and we need to get him back on the jabbers
[11:41:12] <bdesruisseaux> Jon are you east coast?
[11:41:14] <jonlennox> Yes.
[11:41:19] <eliot.lear> anyway, if you can send me your availabilities, i will coordinate with aki
[11:41:28] <cyrus_daboo> Well soon I will have my free-busy data publically available vua the new free-busy URL stuff being done in Calconnect and via the server-to-server protocol so you will be able to see it without me having to send it to you.
[11:41:46] <eliot.lear> now all i'll need is leopard
[11:42:08] <eliot.lear> anyway, i think this is the last open issue
[11:42:15] <eliot.lear> and then we move on to 2446 bis
[11:42:22] <eliot.lear> we'll do that at the next jabber
[11:42:26] <eliot.lear> thanks all
[11:42:27] <jonlennox> There was also the recurrence of day durations.
[11:42:28] <cyrus_daboo> There is a plugin to Thunderbird/Lightning that allows access to free-busy data via a URL.
[11:42:38] <jonlennox> My third message of that day
[11:42:51] <eliot.lear> ah right.
[11:43:12] <eliot.lear> can people comment on that one to the list?
[11:43:16] <bdesruisseaux> Jon: For the recurring day event... I'm not sure I agree with you anymore...
[11:43:16] <eliot.lear> this is:
[11:43:26] <eliot.lear> The definition of RRULE says: If the duration of the recurring component is specified with the "DTEND" or "DUE" property, then the same exact duration will apply to all the members of the generated recurrence set.This is correct for DTEND or DUE specified with VALUE=DATE-TIME, but I thinkit's wrong for DTEND or DUE (and thus also DTSTART) with VALUE=DATE. Inthis latter case, I think it's clear that the desired outcome is alwaysfor the event to last a nominal number of days, not the exact duration oftime of the first instance of the recurrence set.
[11:43:57] <bdesruisseaux> In order to keep it simple... let's this be exact duration...
[11:44:04] <jonlennox> Bernard: I don't think an all-day event should last an hour less or more on the day of a DST change.
[11:44:12] <bdesruisseaux> If it's not what you want... then use DURATION... Simple...
[11:44:39] <jonlennox> That's true
[11:45:19] <jonlennox> And there is some merit to saying that a DATE is always equivalent to a DATE-TIME with the time 00:00:00
[11:45:27] <bdesruisseaux> Yes
[11:46:32] <eliot.lear> ok, guys. have a good one.
[11:46:37] <bdesruisseaux> Thanks!
[11:46:42] <bdesruisseaux> Bye!
[11:46:46] --- eliot.lear has left
[11:46:50] --- bdesruisseaux has left
[11:47:14] --- cyrus_daboo has left
[11:47:17] --- jonlennox has left