[08:28:11] --- alexeymelnikov has joined
[09:59:38] --- eliot.lear@gmail.com has joined
[10:00:48] <eliot.lear@gmail.com> hello
[10:02:56] --- akiniemi has joined
[10:03:10] <akiniemi> hi eliot
[10:03:13] <akiniemi> hi alexey
[10:03:17] <eliot.lear@gmail.com> hi!
[10:03:20] <eliot.lear@gmail.com> back in a moment
[10:03:23] --- eliot.lear@gmail.com has left
[10:03:54] <akiniemi> Alexey: how was the lemonade interim?
[10:04:21] <alexeymelnikov> Hi Aki
[10:04:29] <alexeymelnikov> Productive and busy :-)
[10:04:59] <alexeymelnikov> Good progress on all documents. Slower than expected (as expected ;-))
[10:05:14] <akiniemi> :)
[10:05:51] <alexeymelnikov> Should Cyrus/Bernard be joining us?
[10:06:02] <akiniemi> I'm just pinging Bernard...
[10:06:06] --- bdesruisseaux has joined
[10:06:15] <alexeymelnikov> I go get my tea, will be back shortly
[10:06:48] --- eliot.lear@gmail.com has joined
[10:07:16] --- cyrus_daboo has joined
[10:07:36] <cyrus_daboo> I am here....
[10:07:46] <akiniemi> Hi Cyrus
[10:08:09] <eliot.lear@gmail.com> howdy all
[10:08:22] <akiniemi> Let's wait one more minute and start
[10:08:34] <akiniemi> (Alexey is getting his tea ;)
[10:09:44] <akiniemi> Ok, let's start
[10:09:57] <akiniemi> Last week we spent a lot of time on issue 11 of 2445bis
[10:10:17] <akiniemi> I think we reached a conclusion, but have we followed up on that?
[10:10:51] <akiniemi> Haven't seen anything on the list
[10:11:54] <eliot.lear@gmail.com> hi- is it my jabber client or is aki the only person chatting right now?
[10:14:03] --- pigdog has joined
[10:14:04] <alexeymelnikov> :-)
[10:14:24] <alexeymelnikov> It is *not* your client
[10:14:32] --- eliot.lear@gmail.com has left
[10:14:43] <pigdog> (now over to pigdog)
[10:14:59] <pigdog> hi guys - i'm sorry i missed things last week. what do we need to do to wrap up 2445?
[10:15:19] <pigdog> (bis)
[10:15:42] <bdesruisseaux> There are a couple of issues not closed...
[10:15:55] <bdesruisseaux> or for which we haven't agreed on some text...
[10:16:12] <pigdog> i think i said i would start pounding out messages on those open issues as either let's get text or close. how about i proceed to do that now?
[10:16:24] <bdesruisseaux> Last week we discussed issue 11 a lot ... I think consensus was reached... but not text was proposed by anybody
[10:17:12] <bdesruisseaux> I was supposed to start doing that myself and have not... So, euh, yes, I guess you should proceed
[10:17:14] <akiniemi> I think Cyrus mentioned appendix A on the interop guidelines document in calconnect, and Bernard you mentioned you were in the process of putting that table into the draft.
[10:17:40] <cyrus_daboo> Right - I thought all we need was the table, plus revisions to existing text to make reference to it.
[10:17:56] <bdesruisseaux> I'm in the process of adding the table, but there are important foot notes to the table that I believe deserve more text in the spec
[10:18:11] <akiniemi> Right. And I think this needs to go to the mailing list, though. As a proposal to close issue 11.
[10:18:24] <pigdog> bernard, can you take that to the list?
[10:18:34] <bdesruisseaux> Cyrus: Do you want to post your table to the list?
[10:18:44] <bdesruisseaux> !
[10:18:46] <cyrus_daboo> I can do that.
[10:19:35] <pigdog> next open issue?
[10:19:42] <bdesruisseaux> My feeling last week was that it would probably be useful to clarify how to compute the recurrence set
[10:20:03] <bdesruisseaux> and maybe define what is a "set" during the computation...
[10:20:36] <pigdog> as normative text? that's fine although we can expect some debate on corner cases
[10:21:10] <bdesruisseaux> As normative text
[10:21:28] <bdesruisseaux> Probleme here is that we have no volunteer to write this text I think...
[10:21:49] <pigdog> ok, then is it worth holding up the doc?
[10:22:44] <pigdog> this is not something i want to do an open call for volunteers for, because that invites all sorts of mischief.
[10:23:03] <pigdog> if one of us doesn't do it, and it isn't required, then let's move on.
[10:23:11] <bdesruisseaux> let's move on
[10:23:28] <pigdog> then is there any reason this issue needs to remain opened?
[10:23:43] <pigdog> or will the table go in and then we close?
[10:23:57] <cyrus_daboo> Table goes in then we close.
[10:24:13] <pigdog> ok. next issue, please.
[10:24:20] <bdesruisseaux> I think Cyrus needs to post the table... discussion on the Notes may occur (or not) on the list... and we move on
[10:24:32] <pigdog> i see 71 and 73 are still open
[10:25:47] <bdesruisseaux> Consensus was reached in Prague for 71
[10:25:53] <akiniemi> 73 says: General agreement. Text needed.
[10:26:03] <cyrus_daboo> FYI email for #11 just sent.
[10:26:10] <pigdog> thanks, cyrus
[10:26:14] <bdesruisseaux> 71: We said we should ignore leap seconds
[10:26:42] <pigdog> ok. so marked
[10:27:12] <cyrus_daboo> But we do need to make mention of them, right?
[10:27:15] <bdesruisseaux> 73 was addressed in draft -06 actually
[10:27:36] <bdesruisseaux> 71: We need to clarify the text as such
[10:27:53] <cyrus_daboo> and we still allow '60' as a valid value for seconds in DATE-TIME values?
[10:28:45] <bdesruisseaux> My understanding was that you could still use '60', but that leap seconds should not be considered when computing exact durations
[10:28:56] <pigdog> bernard, right.
[10:29:46] <bdesruisseaux> In other words, if you are smart ass and what to make reference to this specific "instant" then you can...
[10:29:54] <pigdog> ok, that brings us to...
[10:29:56] <pigdog> issue 23?
[10:30:05] <bdesruisseaux> but computation of exact duration from a nominal duration should not be bothered with leap seconds
[10:30:16] <pigdog> there's your text
[10:30:21] <bdesruisseaux> 23 was also address in draft -06
[10:30:22] <pigdog> for leap seconds right there
[10:30:25] <pigdog> ok
[10:30:29] <cyrus_daboo> Right but a duration of 1 day on 31st December on the day of a leap second will be 24 * 60 *60 seconds, not that value plus 1.
[10:31:46] <akiniemi> closed 73, too
[10:32:23] <bdesruisseaux> cyrus: what's the problem?
[10:33:25] <cyrus_daboo> Nothing right now, but I will review what is there again. At the end of the day being one second off is really a non-issue.
[10:33:47] <pigdog> that's where i think the WG was in Prague
[10:33:49] <alexeymelnikov> That is why we spend hours discussing it ;-)
[10:33:54] <pigdog> ;-)
[10:33:59] <pigdog> moving on, please.
[10:34:16] <pigdog> Issue 67?
[10:34:42] <bdesruisseaux> We had consensus for status quo.
[10:35:02] <pigdog> where was that consensus? for some reason i didn't log it
[10:35:20] <bdesruisseaux> It is in the minutes!
[10:35:22] <cyrus_daboo> Status quo is wrong as there is in inconsistency between 2445 and 2446. We must fix that one way or another.
[10:35:41] <bdesruisseaux> That was discussed in Prague.
[10:36:00] <akiniemi> IIRC, the consensus was for status quo in 2445bis, and fix when we come to it in 2446bis
[10:36:04] <bdesruisseaux> iCal has a feature (fine), but iTIP doesn't allow you to make use of it (oh well).
[10:36:09] <cyrus_daboo> I think the consensus was to leave it as it is in 2445bis for now, until we discuss it in the context of 2446bis - at which point a change in 2445bis may be recommended.
[10:36:37] <pigdog> that would be fine. i'll reassing to 2446bis.
[10:36:43] <bdesruisseaux> go with me
[10:36:47] <bdesruisseaux> good...
[10:37:05] <pigdog> done
[10:37:05] <pigdog> next
[10:37:50] <pigdog> issue 70?
[10:39:24] --- pigdog has left: Replaced by new connection
[10:39:45] --- pigdog has joined
[10:40:17] <pigdog> sorry- got booted
[10:40:40] <akiniemi> we moderated? ;)
[10:40:54] <pigdog> and you nailed my vpn!
[10:41:05] <cyrus_daboo> The solution to those is to calculate the start/end via nomin al duration using UTC - then the is no ambiguity when it comes to discontinuties with durations.
[10:41:28] <pigdog> bernard, this is the text you wanted to add, referring to the ISO standard?
[10:41:56] <bdesruisseaux> hold on
[10:44:51] <bdesruisseaux> I'm currently having probleme figuring the difference between 27 and 71
[10:45:44] <bdesruisseaux> oh I get it...
[10:45:55] <bdesruisseaux> That's different!
[10:46:11] <bdesruisseaux> Nothing to do with how to compute the duration...
[10:46:20] <pigdog> right
[10:46:27] <bdesruisseaux> The issue is what to do when you end up on a time that doesn't exist
[10:46:37] <pigdog> do you care?
[10:46:44] <bdesruisseaux> Me?
[10:46:46] <bdesruisseaux> Nah!
[10:46:49] <bdesruisseaux> I sleep at night!
[10:47:06] <pigdog> but realistically i don't see why anyone would care.
[10:47:53] <pigdog> as long as you know the start time and the nominal duration, i don't understand why one would care about the end time unless you're attempting to schedule non-overlapping (e.g. back to back) events
[10:48:10] <cyrus_daboo> Right and the solution is to go back and apply the nominal duration to a UTC value, and then convert back to local. That way you always have a legitimate time with a "real" duration that matches the nominal duration. The only problem occurs when both the start and end are in the problem region, but there you apply the rules for the start, then do the UTC duration for the end.
[10:48:40] <pigdog> do we need to include that text?
[10:49:17] <cyrus_daboo> It should be part of the whole "how to handle dst discontinuities" section (if there is such a thing).
[10:49:35] <pigdog> Bernard?
[10:50:03] <bdesruisseaux> Yes, it should be part of this section if there is a volunteer to write this section!
[10:50:32] <pigdog> Is there a place for that text today?
[10:50:40] <pigdog> (without restructuring other texts)?
[10:50:49] <cyrus_daboo> Its all based on the Jonathan's suggestions, can he put something together?
[10:51:07] <pigdog> we can ask
[10:51:14] <bdesruisseaux> Well we could add an appendix!
[10:51:36] <pigdog> you're saying you don't want this to be normative, but it seems to me it should be
[10:52:02] <cyrus_daboo> Right - I would like something normative if possible.
[10:52:44] <bdesruisseaux> That was not my intent...
[10:53:03] <cyrus_daboo> BTW the Microsoft delegation at Calconnect a few weeks back were saying that DST discontinuity was one of the biggest things they wanted to see fixed. (Its a shame they don't participate in calsify.)
[10:54:11] <pigdog> ok, so we have some text, but we don't know where to stick it.
[10:55:21] <pigdog> ok, leave it for now. i'll ponder this and talk to aki about it
[10:55:22] <pigdog> next
[10:55:44] <pigdog> Issue 78?
[10:55:59] <pigdog> this looks like it should be closed
[10:56:26] <bdesruisseaux> This one was trivial.
[10:56:41] <pigdog> right. if you've already made the text change i'm closing it.
[10:56:51] <cyrus_daboo> Yes - close it. Bernard's proposal is fine.
[10:57:04] <bdesruisseaux> It was in draft -06.
[10:57:09] <pigdog> Issue 79
[10:58:25] <bdesruisseaux> My position: We need to clarify that "DTSTART" always specify a onset date-time of an observance and that its value does not need to be repeated in an "RDATE" property.
[10:59:04] <cyrus_daboo> OK. But the other issue (sorry not sure of the number) about whether it is the FIRST onset for that set is till open, right?
[10:59:35] <cyrus_daboo> i.e. can an RDATE in a VTZ sub-component be before the DTSTART?
[11:00:04] <bdesruisseaux> This is issue 63
[11:00:35] <akiniemi> ietf68 minutes do state consensus 79: 'No objection to proposed changes'
[11:00:51] <pigdog> ah. ok.
[11:00:55] <pigdog> updating the tracker
[11:00:55] <cyrus_daboo> Ok, but there was some push-back on the list for that one (63) at the time.
[11:01:08] <cyrus_daboo> I would like to see another consensus call on it.
[11:01:29] <pigdog> on issue 63?
[11:01:31] <akiniemi> cyrus: on 63 you mean? Are you fine with 79?
[11:01:38] <bdesruisseaux> Can you please state your own objections here for 63?
[11:01:41] <cyrus_daboo> Yes on 63. 79 can be closed.
[11:02:18] <cyrus_daboo> Well I can state the objections of others as I am ambivalent as to what should happen.
[11:02:49] <pigdog> cyrus, i think you need to leave it to others to reopen that issue, then.
[11:02:59] <pigdog> if you want it reopened, that's one thing/
[11:03:06] <cyrus_daboo> The objection was that for the purposes of time-range queries against iCalendar objects, relying on DTSTART as being always the first instance in a recurrence set is a useful optimization.
[11:03:30] <bdesruisseaux> It is an implementation detail.
[11:04:34] <pigdog> there were reasons it couldn't be, as i recall. timezones, as you mentioned
[11:04:36] <bdesruisseaux> Furthermore, the instance defined by DTSTART in a master component could be rescheduled in an exception component after other recurrence instances...
[11:05:13] <akiniemi> process interrupt: we're running overtime.
[11:05:23] <cyrus_daboo> Except that out-of-order rescheduling is a nightmare in iTIP!
[11:05:53] <pigdog> ok... so you DO need this issue revisited?
[11:06:09] <bdesruisseaux> But there is currently no restrictions in iCalendar to prevent recurrence instances to be rescheduled in any order, and nobody brought this up as an issue
[11:06:35] <pigdog> if so, you'll need to address the issues on the other side, and i'd ask for a proposal to address them.
[11:07:07] <cyrus_daboo> My position on this is that Bernard's proposal is fine - if the chair's are happy that we have consensus here and on the list then I am happy too!
[11:07:18] <pigdog> ok
[11:07:22] <pigdog> moving right along for now
[11:07:27] <pigdog> we'll stop here
[11:07:36] <pigdog> let me just state what i have open in the tracker
[11:07:51] <pigdog> issues 70, 81, and 82
[11:08:15] <pigdog> 10, 11, 71
[11:08:48] <pigdog> of those six issues, i will send out mail for each one asking if they need to gate the draft. anyone who wants to gate them must havew a proposal. objections?
[11:08:54] <akiniemi> Also 80; this was missing the correct topic
[11:09:16] <cyrus_daboo> On #63 review the thread 'Section 4.8.5.3 Recurrence Date/Times: RDATE < DTSTART'
[11:09:42] <akiniemi> And I'll take an action to cook up something on issue 80 myself.
[11:09:47] <pigdog> i am even willing to add 63 to the list - so long as people come up with a proposal.
[11:09:55] <pigdog> agreed?
[11:10:41] <bdesruisseaux> yep
[11:10:50] <pigdog> cyrus?
[11:11:43] <cyrus_daboo> Ok
[11:12:02] <pigdog> ok. thanks all for joining. thanks aki for taking over whilst i flew hither and yon
[11:12:25] <akiniemi> thanks all. bye!
[11:12:31] --- pigdog has left
[11:12:32] <alexeymelnikov> Bye
[11:12:35] --- alexeymelnikov has left
[11:12:36] <cyrus_daboo> I see we are on the preliminary agenda for Chicago.
[11:12:43] --- akiniemi has left
[11:12:47] --- bdesruisseaux has left
[11:12:51] --- cyrus_daboo has left