[10:46:46] --- pigdog has joined
[10:47:13] --- alexeymelnikov has joined
[10:47:27] <alexeymelnikov> Hi
[10:47:33] <alexeymelnikov> Thanks for the reminder!
[10:47:43] <pigdog> welcomes and good afternoon!
[10:54:22] <pigdog> we'll start in 5 minutes assuming we have a quarum
[10:55:39] <alexeymelnikov> Ok
[10:58:47] --- bernard.desruisseaux has joined
[11:00:12] <pigdog> hi bernard
[11:00:56] <pigdog> we'll wait another minute or two. maybe cyrus will join?
[11:01:58] <pigdog> alexy- do you see bernard online?
[11:02:08] <pigdog> he sort of half shows on my display
[11:02:13] <alexeymelnikov> Yes, he is in the chat room ;-)
[11:02:52] <pigdog> (just pinging cyrus now)
[11:02:59] <alexeymelnikov> I just did too
[11:03:16] --- cyrus_daboo has joined
[11:03:20] <pigdog> hi cyrus and welcome
[11:03:27] <pigdog> bernard, are you there?
[11:03:40] <bernard.desruisseaux> yes, i'm here
[11:03:45] <pigdog> ah welcome as well.
[11:03:59] <pigdog> aki won't make it today, unfortunately, so let's proceed and see who joins us.
[11:04:20] <pigdog> we'll be working off the issue tracker again today
[11:04:21] <bernard.desruisseaux> I just ping cyrus too :-)
[11:04:32] <pigdog> cyrus has now gotten three pings and is in fact on ;-)
[11:04:39] <cyrus_daboo> Who needs a VALARM when I have Bernard, Alexey and Elliot to send me IMs!
[11:04:46] <alexeymelnikov> Before I forget: is it possible to add link to the tracker to the Calsify WG web page?
[11:04:48] <pigdog> hahaha!!
[11:05:01] <pigdog> sure. let me talk to lisa and aki about it
[11:05:18] <pigdog> before we go further, bernard has mentioned that he plans to put out an update that addresses the following issues:
[11:05:36] <pigdog> 16 28 29 32 34 40 43 44 46 48 51 52 53 56 57 58 59 60
[11:05:50] <pigdog> that's a whole lot of work. thank you again, bernard.
[11:05:55] <bernard.desruisseaux> correct
[11:06:16] <alexeymelnikov> It might be easier to show what is left?
[11:06:16] <pigdog> before looking at the issue tracker, does anyone want to agenda bash?
[11:06:50] <pigdog> alexey, i will try to improve the interface to do that, but I think we're down to only a few issues, really.
[11:06:53] <alexeymelnikov> Just going through open issues as usual is fine with me
[11:07:18] <pigdog> ok, then on to the issue tracker.
[11:07:30] <pigdog> i believe today we start with issue 55 unless I'm mistaken
[11:08:02] <pigdog> this is based on the wg meeting as i recall
[11:08:11] <bernard.desruisseaux> What about issue 19 to 23?
[11:08:51] <pigdog> backing up...
[11:08:55] <pigdog> we need new iana text
[11:08:56] <cyrus_daboo> Yes. Just as follow up the mobile TC in calconnect will be discussing some issues wrt how mobile devices can downgrade complex RRULEs next week. That is my preference rather than doing profiles.
[11:09:20] <cyrus_daboo> I still think MINUTE/SECOND FREQ and BYxxx should go though.
[11:09:49] <pigdog> ok, we are now discussing two issues. let's stick with 55 for the moment
[11:09:55] <cyrus_daboo> Though one could argue having something repeat every 15 minutes could be useful (ie. perhaps keep FREQ=MINUTE).
[11:11:05] <pigdog> is there any reason to believe that any application would be written to actually use the calendaring spec that measures events in seconds, rather than simply using sleep()?
[11:11:31] <pigdog> i mean, does someone want to set an alarm when we have a leap second?
[11:11:41] <pigdog> as a recurring rule?
[11:12:08] <pigdog> bernard, comments?
[11:12:13] <bernard.desruisseaux> I'm not following you
[11:12:19] <cyrus_daboo> I can't see any utilitly to calendaring at a resolution of seconds.
[11:12:27] <bernard.desruisseaux> hello? test??
[11:12:39] <bernard.desruisseaux> I'm not following you Eliot!
[11:12:40] <cyrus_daboo> Even being allowed to specify times with second resolution is pushing it!
[11:12:41] <pigdog> still here
[11:12:45] <alexeymelnikov> Yes, we can read you Bernard
[11:12:54] <pigdog> so issue 55 says remove FREQ=SECONDLY/MINUTELY
[11:12:56] <bernard.desruisseaux> I'm not following you
[11:13:00] <bernard.desruisseaux> Eliot
[11:13:18] <pigdog> we seem to be having a jabber problem.
[11:13:29] <pigdog> bernard can you see my messages?
[11:13:32] <bernard.desruisseaux> yes
[11:13:34] <pigdog> ok
[11:13:53] <pigdog> so Issue 55 says remove FREQ=SECONDLY/MINUTELY (amongst other things)
[11:14:01] <pigdog> when would FREQ=SECONDLY be useful?
[11:14:03] <bernard.desruisseaux> I don't believe there are "serious" use cases for both FREQ=SECONDLY and the BYSECOND rule part
[11:14:18] <pigdog> so let's nuke both
[11:14:20] <cyrus_daboo> Agreed - seconds are definitely out.
[11:14:30] <bernard.desruisseaux> FREQ=MINUTELY and BYMINUTE are more arguable.
[11:14:50] <bernard.desruisseaux> Do we actually need *both*?
[11:14:55] <cyrus_daboo> I think BYMINUTE is pretty hard to justify - FREQ=MINUTELY is harder.
[11:15:15] <alexeymelnikov> So iCalendar can't be used in nuclear power plants :-)
[11:15:19] <cyrus_daboo> We could do away with BYMINUTE but keep the FREQ=MIN
[11:15:31] <pigdog> that's what i'm thinking
[11:15:46] <pigdog> because MINUTELY == sleep(60)
[11:15:46] <bernard.desruisseaux> Can you please give an example
[11:16:10] <pigdog> sorry- you want a useful example of MINUTELY?
[11:17:16] <bernard.desruisseaux> Well I'd like to see examples with both and really convince ourselves about which one we should keep
[11:18:14] <pigdog> i don't see why both are needed
[11:18:19] <cyrus_daboo> The question is whether MINUTELY/SECONDLY are really being used to represent events, or alarms? Remember VALARAM already has a simple "repeat" mechanism that allows multiple recurring alarms on a single event.
[11:18:29] <pigdog> but i could be convinced that one is
[11:18:42] <bernard.desruisseaux> I understand that now, given that DTSTART must be synchronized with the RRULE, BYMINUTE would only be specified when 2 or more values... else it would be useless
[11:18:46] <cyrus_daboo> So if the only use case is for alarms, then we don't need them in RRULE.
[11:20:46] <pigdog> For calendaring I have a hard time finding good examples
[11:20:56] <cyrus_daboo> Also, MINUTELY/SECONDLY should not be allowed unbounded because they would generate an unmanageable dataset. Given that requirement of being bounded, you can always use RDATEs to get the set you want.
[11:21:29] <cyrus_daboo> Chances are F=M/S would be bounded as a small set.
[11:22:09] <pigdog> ok, i think we need a proposal to the mailing list for this with a discussion as to the implications
[11:22:12] <bernard.desruisseaux> Currently, I see FREQ=SECONDLY as a tool for hacker to perform DoS...
[11:22:38] <pigdog> that's a good point
[11:22:55] <alexeymelnikov> Indeed
[11:23:05] <pigdog> but i suspect you could accomplish the nearly the same impact with BYHOUR
[11:23:11] <pigdog> or maybe several BYHOUR events
[11:23:26] <cyrus_daboo> Well, any good implementation will have built-in limits. That should be stated in security considerations.
[11:23:31] <bernard.desruisseaux> The reason I'd like to see examples for both is because you can use BYMINUTE to get the same result at FREQ=MINUTELY
[11:23:42] <bernard.desruisseaux> Cyrus: Yes
[11:23:50] <bernard.desruisseaux> Cyrus: Yes
[11:24:03] <pigdog> bernard: right
[11:24:24] <bernard.desruisseaux> RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 is equivalent to: RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16
[11:24:58] <pigdog> so it seems like we're willing to nuke MINUTELY, SECONDLY, and BYSEC
[11:25:12] <pigdog> is that what i'm hearing?
[11:25:19] <pigdog> (reading)
[11:25:30] <alexeymelnikov> Yes
[11:25:42] <cyrus_daboo> Well by minute can be used to get a more sophisticated set: e.g. every 15 minutes in the first 45 of an hour, then every five minutes, then every minute in the last 5: BYMINUTE=15,30,45,50,55,56,57,58,59. However, I can only see this as an alarm use case not an event use case.
[11:26:01] <cyrus_daboo> BYMINUTE should go as well.
[11:26:10] <pigdog> want to create two separate parsers?
[11:26:28] <bernard.desruisseaux> BYMINUTE is more flexible than FREQ=MINUTELY
[11:26:53] <bernard.desruisseaux> We could keep BYMINUTE and get rid of FREQ=MINUTELY
[11:27:09] <cyrus_daboo> Come up with a valid use case for BYMINUTE...
[11:27:20] <pigdog> i think that's the only open question- is whether or not to get rid of BYMINUTE.
[11:27:38] <pigdog> why don't we pose Cyrus' question to the list?
[11:28:24] <pigdog> ok.. let's close on this issue
[11:29:00] <pigdog> let's agree for the moment that BYSEC, SECONDLY and MINUTELY are gone. let's leave open the question of BYMINUTE but have a bias toward getting rid of it if nobody can show a valid case. fair?
[11:29:21] <cyrus_daboo> OK.
[11:29:23] <bernard.desruisseaux> Cyrus: a "serious" use case is hard to come up with
[11:29:35] <alexeymelnikov> Ok
[11:29:40] <pigdog> bernard?
[11:29:47] <bernard.desruisseaux> I like this.
[11:29:51] <pigdog> ok
[11:29:52] <pigdog> done
[11:29:58] <pigdog> moving on
[11:30:08] <pigdog> (give me just a moment to note the issue)
[11:30:09] <bernard.desruisseaux> for some reason I don't see my own text...
[11:30:18] <bernard.desruisseaux> let me get out and come back...
[11:30:21] --- bernard.desruisseaux has left
[11:30:21] <cyrus_daboo> Given that the BY... rules are more complicated to handle than FREQ rules, I think if we dump F=MIN, then we should do BYMIN too - but lets hear from others.
[11:31:22] <pigdog> ok, the next thing in that issue talks about a table to be submitted. clearly we need this resolved first
[11:31:38] <pigdog> so what i propose is that we start the discussion on list. may i ask for a volunteer?
[11:31:49] <pigdog> cyrus?
[11:32:04] <cyrus_daboo> OK....
[11:32:13] <pigdog> thanks!
[11:32:33] <pigdog> i'm getting some delayed messages from bernard.. there may be chat room problems
[11:32:41] <pigdog> it looks like bernard is gone
[11:32:46] <pigdog> he's trying to get back in
[11:32:59] <alexeymelnikov> I don't see him anymore
[11:33:02] <pigdog> please stand by a sec
[11:33:04] --- bernard.desruisseaux has joined
[11:33:06] <cyrus_daboo> OK - I've added a VTODO with FREQ=MINUTELY to my calendar to remind me to do this :-D
[11:33:08] <bernard.desruisseaux> I'm back
[11:33:10] <bernard.desruisseaux> sorry guys
[11:33:39] <pigdog> ok. we're leaving issue 55 for now
[11:33:43] <pigdog> moving back to issue 19
[11:34:18] <pigdog> as i recall i think i opened my mouth and inserted my foot by offering to help here.
[11:34:42] <pigdog> if people would like, I will take ownership of this one and provide some cleaned up text to the list.
[11:34:54] <bernard.desruisseaux> Thanks
[11:34:57] <alexeymelnikov> Sure :-)
[11:35:24] <bernard.desruisseaux> At a high level we need:
[11:35:27] <pigdog> ok, Athlete's Tongue here i come. please feel free to correct whatever i send. i'll probably ping you guys off line about one or two questions.
[11:35:36] <pigdog> (do continue, tho Bernard)
[11:35:41] <bernard.desruisseaux> Template for new component Template for new property Template for new parameter
[11:36:08] <bernard.desruisseaux> What about new values?
[11:36:15] <pigdog> do we need to hold onto the MIME type as well?
[11:36:21] <pigdog> which as i recall is in 2445
[11:36:26] <alexeymelnikov> Yes, we need templates for new values too
[11:36:45] <pigdog> anything else?
[11:37:01] <bernard.desruisseaux> yes!
[11:37:04] <alexeymelnikov> I can check my notes
[11:37:14] <cyrus_daboo> I think its harder to justify new values. We should leave that out.
[11:37:22] <bernard.desruisseaux> Alexey was mentionning that we would need separate registry for a lot of things...
[11:37:31] <pigdog> cyrus: i agree
[11:37:34] <bernard.desruisseaux> for instance the CUTYPE parameter allows "iana-token"
[11:37:52] <bernard.desruisseaux> We would need a specific registery for new "CUTYPE" values...
[11:38:06] <bernard.desruisseaux> ... all this is according to Alexey!
[11:38:08] <alexeymelnikov> It would be fine to say that some values can't be extended
[11:38:12] <pigdog> perhaps the way to handle this is in the standard of review required
[11:38:16] <cyrus_daboo> OK - you mean enumerated values. I thought you were taking about new VALUE= types.
[11:38:30] <bernard.desruisseaux> Alexey not all values can be extended. Only some allow iana-token
[11:38:33] <alexeymelnikov> Yes, every time one mentions iana-token, there need to be a separate registry
[11:38:59] <cyrus_daboo> A separate registry for each enumerated type.
[11:39:08] <alexeymelnikov> Correct
[11:39:23] <cyrus_daboo> That's a lot!
[11:39:28] <alexeymelnikov> Bernard: of course, but if an enumerated type can't be extended, then it shouldn't mention iana-token
[11:39:29] <pigdog> ok, let me go through the draft and see how many of those there are. we have to be careful to not inundate the iana (not that a whole lot goes on here, right)?
[11:39:38] <bernard.desruisseaux> So the IANA section should have 4 Templates... *and* introduce all the specific registeries
[11:39:51] <cyrus_daboo> Why not one registry that includes the property value to indicate which enumeration it applies to?
[11:40:02] <bernard.desruisseaux> I like that
[11:40:15] <bernard.desruisseaux> This is the approache we would use for the template anyway...
[11:40:25] <alexeymelnikov> That might work
[11:40:43] <pigdog> ok, my problem for now. look for somethiing before the next jabber
[11:40:45] <cyrus_daboo> So perhaps use iana-cutype-token in the ABNF, then use that ABNF element as an entry in the registry.
[11:41:04] <bernard.desruisseaux> Cyrus: exactly what I was asking myself...
[11:41:37] <pigdog> if that is what people want me to try i'll try it. that will require several changes throughout the draft.
[11:41:55] <pigdog> shall i proceed along those lines?
[11:42:00] <bernard.desruisseaux> yes
[11:42:02] <cyrus_daboo> I think that makes sense
[11:42:09] <alexeymelnikov> Yes
[11:42:17] <pigdog> ok
[11:42:18] <pigdog> moving on
[11:43:14] <pigdog> issues 20, 21 are to the other docs
[11:43:27] <pigdog> how about we proceed to issue 61?
[11:43:34] <pigdog> ection 4.2 Property Parameters: ianaparam
[11:43:45] <pigdog> this seems related to our previous discussion
[11:43:47] <bernard.desruisseaux> 23
[11:44:16] <bernard.desruisseaux> Okay... for 23 the ball is in my court
[11:44:23] <pigdog> right.
[11:44:25] <pigdog> 61?
[11:44:36] <bernard.desruisseaux> no 27
[11:45:22] <pigdog> 27: cyrus to propose text.
[11:45:47] <pigdog> (misowned in the roundup database)
[11:45:49] <pigdog> my mistake
[11:45:54] <pigdog> moving to 61, please?
[11:47:12] <pigdog> is there any objection to cyrus' proposed change?
[11:47:20] <bernard.desruisseaux> for 27?
[11:47:23] <pigdog> 61
[11:47:31] <pigdog> (cyrus owes text for 27)
[11:47:59] <bernard.desruisseaux> Cyrus: do you have a solution for 27??
[11:48:44] <bernard.desruisseaux> Not only are there ambiguity between DTEND and DURATION... but there are ambiguity with DURATION alone
[11:49:03] <bernard.desruisseaux> I believe I sent a mail to the mailing on this subject with a proposal
[11:49:06] <cyrus_daboo> No - but I think a section on how to deal with "time/date anomalies" might be useful (e.g. dst shift, leap days).
[11:49:53] <pigdog> cyrus, can you propose that text and an appropriate insertion point?
[11:50:02] <cyrus_daboo> We will never be able to eliminate the ambiguity - the best option is to try and detect it and flag to the user to make sure they are aware and can choose the appropriate behavior.
[11:50:08] <bernard.desruisseaux> http://lists.osafoundation.org/pipermail/ietf-calsify/2006-October/001306.html
[11:50:53] <bernard.desruisseaux> Cyrus: In Montreal we had talked about you providing text such that user interface would prompt the user...
[11:51:04] <bernard.desruisseaux> But later on we figure there was other issues...
[11:51:50] <pigdog> gone quiet... we need to figure out how to proceed with this issue
[11:52:05] <cyrus_daboo> Right. I think all we can do is document these edge cases as known issues.
[11:52:30] <cyrus_daboo> We could give explicit rules on how to deal with them as per your message.
[11:52:37] <bernard.desruisseaux> Initially the issue was: Do you want a recurrence instance to end a the same time of the day as the first instance ... or do you want a recurrence instance to simply have the same duration.
[11:52:58] <bernard.desruisseaux> I always said duration... like the draft. And I was happy! :-)
[11:53:03] <bernard.desruisseaux> Then I realized... wait a minute!
[11:53:09] <bernard.desruisseaux> Event duratino is not clear...
[11:53:16] <pigdog> right- to me that depended on whether you used DURATION or DTEND
[11:53:33] <bernard.desruisseaux> Do you want the recurrence instance to have the EXACT duration of the first instance or its NOMINAL duration...
[11:53:50] <bernard.desruisseaux> P1D might be 23 hours, 24 hours, or 25 hours...
[11:54:10] <cyrus_daboo> If DURATION is used the instance will use that.
[11:54:25] <bernard.desruisseaux> Eliot look at my message.
[11:54:36] <cyrus_daboo> i.e. P1D may be 23, 24 or 25 hours, but PT24H is always 24 hours.
[11:55:12] <cyrus_daboo> With DTEND things are harder.
[11:55:23] <bernard.desruisseaux> well... it depends if there was a negative or positive leap second in that range...
[11:55:58] <cyrus_daboo> I'm happy to leap over the issue of leap seconds, given that they are not predicatble.
[11:56:15] <bernard.desruisseaux> Same here!
[11:56:38] <pigdog> why is DTEND *harder*?
[11:57:07] <pigdog> DTEND specifies a precise end!
[11:57:16] <bernard.desruisseaux> I disagree with Cyrus here. In my opinion, DTEND is really easy. There is no ambiguity. The only problem, is that well... sometime you won't get want you want
[11:57:52] <bernard.desruisseaux> With DTEND you can only get the EXACT duration ... and this is want the recurrence instance will end up having as their duration...
[11:57:57] <cyrus_daboo> That's a problem!
[11:58:28] <cyrus_daboo> I specify an event as midnight to 8 am, I expect it to be that even if there is a DST shift in between.
[11:58:32] <alexeymelnikov> Seems like the document should give advice to developers on which one to use when
[11:58:38] <pigdog> so the problem here is that the draft does not actually define what a day is
[11:59:05] <pigdog> is that right?
[11:59:35] <pigdog> I'm happy if we did define that
[11:59:45] <cyrus_daboo> It does state somewhere that a day may varying in length (hours).
[12:00:09] <cyrus_daboo> P1D is very clearly one day not 24 hours.
[12:00:13] <bernard.desruisseaux> Yes. RFC 2445 doesn't clearly define dur-day
[12:00:27] <cyrus_daboo> Really?
[12:00:43] <pigdog> cyrus, where does it say that a day may vary?
[12:00:56] <bernard.desruisseaux> It assumes that everybody knows what a day is I guess! ;-)
[12:01:11] <pigdog> the assumptions we challenge.
[12:01:22] <bernard.desruisseaux> of course
[12:01:30] <pigdog> ok, we need to wrap this hour up. who wants to take a crack at breaking this logjam?
[12:02:01] <bernard.desruisseaux> If you have an event that starts at midnight and the duratino is P1D than I would expect this event to end at midnight of the following day regardless if there was a time zone during during this day...
[12:02:22] <pigdog> i agree.
[12:02:34] <pigdog> and i think we might even have a consensus here
[12:02:45] <pigdog> it's just that we need text to explain it
[12:02:47] <bernard.desruisseaux> If an event start at 2:30 AM and last P1D and the time zone shift occurs on the next day at 2:00
[12:03:03] <bernard.desruisseaux> that is, 2:30 AM in local time does not exist...
[12:03:22] <bernard.desruisseaux> will the meeting end at 3:30 AM, that is, 24 hours later?
[12:03:26] <bernard.desruisseaux> I guess it should
[12:03:46] <cyrus_daboo> Then the client warns the user and the user writes an RDATE exception for that giving the correct behavior (23 or 25 hours).
[12:04:25] <bernard.desruisseaux> You are giving a "best pratice recommendation" here.
[12:04:30] <pigdog> the problem now is that you have different DST shifts, and so it's not the guy proposing the event, but the one accepting the event that has a problem
[12:04:42] <bernard.desruisseaux> I think we need a normative statement.
[12:05:02] <pigdog> ok, let me repeat: anyone want to take ownership of this knot?
[12:05:34] <pigdog> we can't close the issue without an owner.
[12:05:47] <cyrus_daboo> Maybe Bernard and I can thrash something out on one or our weekly calls....
[12:05:50] <bernard.desruisseaux> but we already have an owner in the tracker! ;-)
[12:06:23] <pigdog> i think cyrus is saying that he can't own this alone
[12:06:46] <bernard.desruisseaux> thinking...
[12:07:21] <cyrus_daboo> I think Bernard and I have different views on this right now and we need to come to consensus with each other in order to have a proposal to put to everyone else.
[12:07:51] <pigdog> ok. we'll let this issue sit for now, but we'll need to resolve it soon.
[12:07:52] <bernard.desruisseaux> 4 people replied to my message on the mailing list. Cyrus can you please reply to this thread with your view?
[12:08:13] <bernard.desruisseaux> I think it would be the right way to proceed with this issue.
[12:08:43] <pigdog> i need to move on. can everyone join us next week this time?
[12:09:19] <bernard.desruisseaux> Sorry I can't!
[12:09:34] <alexeymelnikov> I can
[12:09:43] <pigdog> bernard, can you propose another time?
[12:09:46] <cyrus_daboo> OK for me, but not the week after
[12:09:57] <pigdog> (i'd like the author on the call)
[12:10:05] <bernard.desruisseaux> next tuesday (Dec 12) same time?
[12:10:15] <pigdog> tuesday 8:00am pst?
[12:10:22] <pigdog> alexey, cyrus?
[12:10:27] <cyrus_daboo> Fine.
[12:10:37] <alexeymelnikov> Probably Ok
[12:11:02] <pigdog> ok. thanks for attending today. see you in the jabber room tuesday at 8:00am pst / 4:00pm UTC
[12:11:08] <bernard.desruisseaux> Thanks!
[12:11:12] <cyrus_daboo> Ok.
[12:11:15] --- pigdog has left
[12:11:15] --- cyrus_daboo has left
[12:11:20] <alexeymelnikov> Bye
[12:11:26] --- alexeymelnikov has left
[12:12:39] --- bernard.desruisseaux has left
[12:55:58] --- oliver88 has joined
[13:28:56] --- oliver88 has left
[13:29:07] --- oliver88 has joined
[13:36:01] --- oliver88 has left
[14:59:00] --- bernard.desruisseaux has joined
[15:04:37] --- bernard.desruisseaux has left
[15:04:40] --- bernard.desruisseaux has joined
[15:04:55] --- bernard.desruisseaux has left
[15:05:01] --- bernard.desruisseaux has joined
[15:05:13] --- bernard.desruisseaux has left
[15:05:14] --- bernard.desruisseaux has joined
[15:05:19] --- bernard.desruisseaux has left