[10:33:30] --- pigdog has joined
[10:38:38] --- Aki has joined
[10:45:23] --- Lisa has joined
[10:45:34] <Lisa> Morning
[10:46:01] <pigdog> good morning
[10:46:07] --- JonLennox has joined
[10:46:23] <pigdog> aki will lead things off in about 15 minutes
[10:48:50] <JonLennox> Good morning
[10:49:33] --- alexeymelnikov has joined
[10:49:58] <alexeymelnikov> Morning
[10:51:21] <pigdog> howdy. aki's going to run things today. baby in hand=1 finger typing. slow
[10:52:44] <Aki> T minus 8 minutes. Hi everyone!
[11:01:09] --- bernard.desruisseaux has joined
[11:01:33] <Aki> Ok, I think we're about ready to start.
[11:02:12] <Aki> First, some agenda bashing.
[11:02:51] <alexeymelnikov> No Cyrus today?
[11:02:56] <Aki> Eliot and I were thinking to revisit all of the issues that didn't show clear consensus one way or the other, and see where we stand currently.
[11:03:55] <Aki> Eliot was nice enough to put a bunch of issues into the tracker. Link here: http://ofcourseimright.com/cgi-bin/roundup/calsify/
[11:04:31] <Aki> Alexey: seems Cyrus isn't joingin us today.
[11:04:58] <bernard.desruisseaux> Tried reaching him on his mobile but to no avail...
[11:05:35] <Aki> We'll also be sending a summary of conclusions on each issue from the meeting.
[11:06:15] <Aki> Anyway, to start, AFAICS, issue 28 is the first one that was left hanging.
[11:07:24] <alexeymelnikov> Bernard is to propose some text :-)
[11:07:33] <bernard.desruisseaux> yep. we have consensus.
[11:07:48] <Aki> Cool.
[11:08:08] <Aki> Then add that to the rest that need text. ;)
[11:08:51] <Aki> Next up is one of the newer issues, this marked as #56 in the tracker.
[11:08:55] <bernard.desruisseaux> Please change the status of the issue in the tracker
[11:09:03] <pigdog> bernard, what's the text?
[11:09:36] <bernard.desruisseaux> Eliot: I don't have the text yet for #28.
[11:09:50] <pigdog> ok, so what's the change in the tracker?
[11:09:59] <bernard.desruisseaux> Change the status to concensus
[11:10:10] <pigdog> ack
[11:10:28] <Aki> What was the consensus?
[11:11:33] <bernard.desruisseaux> Consensus for issue 28: Relax the requirement. RDATE is not required if you specify an exception component for a recurrence instance for which you modified the duration...
[11:12:48] <pigdog> copied to the tracker
[11:12:51] <Aki> Ok, good. How about #56?
[11:13:30] <Lisa> Should we shift to a more rigid rule ordering in the long run?
[11:13:41] <bernard.desruisseaux> I don't believe so.
[11:13:49] <alexeymelnikov> I think we've reached consensus that FREQ is always first (for backward compatibility), the rest is unordered
[11:14:09] <Lisa> We can say that for rfc2445bis, parsing agents MUST accept rules in any order, but software creating events MUST generate them in this particular order.
[11:14:25] <Lisa> Ok, more confusing than all or none, but livable.
[11:14:57] <alexeymelnikov> Lisa: Right. It is not clear if anybody generates RRULEs where FREQ is not the first
[11:15:00] <bernard.desruisseaux> Nothing (almost) is ordered in iCalendar...
[11:15:17] <bernard.desruisseaux> I don't see how changing this would reduce the complexity...
[11:15:40] <bernard.desruisseaux> Alexey: You're probably right, but does it matter?
[11:16:03] <alexeymelnikov> Well, you either fix the text or the ABNF. I don't really care.
[11:16:38] <bernard.desruisseaux> My understanding was that we would leave the ABNF pretty much as is... and specify in the text that FREQ does not need to appear first...
[11:17:40] <Lisa> that seems likely to lead to interoperability bugs; a way to compensate some would be to have public test suites of VEVENTS that include FREQ in later positions.
[11:17:42] <JonLennox> I don't think the text should allow constructs forbidden by the ABNF.
[11:17:56] <JonLennox> The other way around is okay, though.
[11:18:32] <pigdog> if we've gotten to the point where we have a defacto standard of FREQ being first, codifying the way lisa suggests protects (perhaps overly) simple implementations. there are proponents on both sides. i favor the protection.
[11:18:33] <alexeymelnikov> I tend to treat ABNF as the authoritative source as well
[11:19:07] <JonLennox> I'd be inclined to write the ABNF to allow FREQ anywhere, and put in the text that clients MUST put it first but MUST accept it anywhere.
[11:19:08] <bernard.desruisseaux> So far, we've treated the text has authoritative
[11:19:29] <bernard.desruisseaux> I would also prefer to fix the ABNF to allow FREQ anywhere
[11:19:42] <alexeymelnikov> I agree with JonLennox
[11:19:54] <pigdog> as do i
[11:20:43] <Aki> So I think we're agreeing to fix the ABNF to allow FREQ anywhere, but add constraints to the text about FREQ being always first.
[11:20:52] <bernard.desruisseaux> With this approach there are tons of MUST accept anything, but MUST generate something specific that the spec should add....
[11:21:12] <bernard.desruisseaux> MUST accept iCalendar specified in lowercase, but MUST generate in uppercase
[11:21:22] <alexeymelnikov> I can take a stub at updated ABNF
[11:21:47] <alexeymelnikov> (only for this issue :-))
[11:22:00] <Aki> Bernard: you are right; same as saying "MUST abide by the Jon Postel rule) ;)
[11:22:50] <pigdog> well, we should be looking to harden the spec. this is one way to do it.
[11:23:52] <Aki> Alexey: will you propose text as Lisa was proposing as well?
[11:24:51] <alexeymelnikov> Aki: I wasn't planning to, but I can if you want
[11:25:08] <bernard.desruisseaux> Just to be clear here... the only ambiguity had to do with FREQ.
[11:25:35] <bernard.desruisseaux> It was clear in the text and in the ABNF that all the other rule parts could appear in any order... I don't think we should change that.
[11:25:49] <pigdog> here, yes.
[11:26:35] <Aki> Right; I'll record an action item for Alexey here. Moving on...
[11:27:26] <Aki> Issue #58
[11:27:53] <Aki> Do we have consensus on this? (Notes indicate this was left open in San Diego)
[11:28:22] <pigdog> i think we did.
[11:28:26] <pigdog> not that anyone cared
[11:29:00] <bernard.desruisseaux> We should change the ABNF to match the text, as was done in all other cases where the ABNF didn't match the text!
[11:29:17] <pigdog> i agree
[11:29:26] <bernard.desruisseaux> That is, DESCRIPTION may occur more than once in a VJOURNAL.
[11:29:38] <Aki> Ok, good. Two '+1's on the list, too, so we can close this one. Bernard, I gather you'll make the change?
[11:29:45] <bernard.desruisseaux> Yes
[11:29:57] <bernard.desruisseaux> Please change state of issue to Concensus.
[11:30:06] <Aki> #58 closed. Moving on...
[11:31:40] <Aki> Issue #59: what's up with that?
[11:33:01] <bernard.desruisseaux> If you have a VEVENT with a DTSTART;VALUE=DATE but without DTEND and DURATION and TRANSP. What is the transparency of this event? and for how long...
[11:33:40] <bernard.desruisseaux> The authoritative pieces of the text specify that if no DTEND nor DURATION then the day event lasts 1 day
[11:34:01] <bernard.desruisseaux> Furthermore, the default transparency is always OPAQUE
[11:34:10] <bernard.desruisseaux> Simple change.
[11:35:01] <pigdog> so, the change is in transparency or what?
[11:35:10] <Aki> I believe Cyrus was saying he'd prefer a default transparency of TRANSPARENT on the list.
[11:35:20] <bernard.desruisseaux> I'm not too concerned with this clarification.... I don't believe there are a lot of VEVENT with DTSTART;VALUE=DATE that doesn't have DTEND or DURATION or the TRANSP property set explicitly for that matter.
[11:36:02] <pigdog> the problem as i see it is that often times the limitation here is in the UI and not in the protocol
[11:36:13] <bernard.desruisseaux> Cyrus thought there were applications that didn't specify DTEND or DURATION and neither TRANSP and assumed TRANSP was TRANSPARENT...
[11:36:33] <bernard.desruisseaux> From what I know this is not the case... I've asked Cyrus to prove me wrong...
[11:37:10] <bernard.desruisseaux> Eliot: Correct.
[11:37:25] <Aki> Ok, let's take this to the list then; the ball is on Cyrus' court.
[11:37:32] <bernard.desruisseaux> If the UI assume that a day event is transparent... it should explicilty specify TRANSP:TRANSPARENT.
[11:38:06] <Aki> Moving on to issue #62
[11:39:05] <Aki> Notes say more discussion needed.
[11:39:43] <Aki> List discussion seemed to indicate this was a sticky issue back in the day as well. ;)
[11:39:44] <bernard.desruisseaux> The issue here is that if you change the RRULE of an event...
[11:40:04] <bernard.desruisseaux> some recurrence instances may disappear... and some recurrence instances may appear.
[11:40:30] <bernard.desruisseaux> The text says that the RECURRENCE-ID of some recurrence instances may change
[11:40:35] <bernard.desruisseaux> I find this totally misleading...
[11:40:59] <bernard.desruisseaux> Recurrence instances have not changes. You have deleted some. You have added new ones.
[11:41:48] --- cyrus_daboo has joined
[11:42:00] <Lisa> So you would say that a recurrence-id should not be changed for any instance that still occurs at the same time/day/duration, after the rule change?
[11:42:35] <cyrus_daboo> Sorry folks - joining late - had a home emergency to deal with.
[11:42:44] <bernard.desruisseaux> I'm not saying "it should not change". It will be the same! That's all!
[11:43:04] <Lisa> I wouldn't assume that in some other implementation it will be the same :)
[11:43:09] <Aki> Cyrus: no problem; we've generated a ton of action items for you. I kid, I kid. ;)
[11:43:34] <bernard.desruisseaux> Lisa: I don't understand
[11:43:47] <Lisa> You're stating an invariant, which isn't actually an invariant if I'm a creative implementor. We need requirements for that.
[11:44:38] <bernard.desruisseaux> I don't believe there is any room for creativity here!
[11:45:03] <bernard.desruisseaux> You have an RRULE that genereates a bunch of DATE or DATE-TIME values... those are your RECURRENCE-ID values...
[11:45:20] <cyrus_daboo> The issue of changing an RRULE is not really a 2445 one per se, but really 2446. What you do with your own components is really up to you and your client implementation. But how you go about rescheduling with others had better be very well defined.
[11:45:39] <bernard.desruisseaux> You change this RRULE... it generates a bunch of DATE or DATE-TIME values... some dates are gone... some dates are new... some dates are the same...
[11:45:59] <bernard.desruisseaux> the dates that are the same... have the same RECURRENCE-ID values... how could that not be?
[11:46:07] <cyrus_daboo> The policy I want to take for 2446bis is to say that a change to the original RRULE is NOT allowed. Instead you have to cancel/truncate the current event set and create a new one for the new rule.
[11:47:17] <Lisa> Bernard you're most likely right in practice, but a creative implementor could switch between forms of DATE-TIME.
[11:47:24] <bernard.desruisseaux> I agree with Cyrus that this is more an iTIP related issue than an iCalendar related issue. My proposal was to remove the misleading statement from iCalendar.
[11:47:57] <bernard.desruisseaux> The issue in iTIP with changing the RRULE is that some implementations will actually expect to receive METHOD:CANCEL for the cancelled recurrence instances...
[11:47:59] <Lisa> Cyrus does your policy work for CalDAV as well? It's important for synching between two different clients, isn't it?
[11:48:12] <cyrus_daboo> Consider this case: a set of weekly meetings for 10 times. Each has an exception with a different set of attachments in each. We later decide we need to skip week 5, but push all the instances out a week - so still 10 in total but with a one week gap. How do you correlate the new instance R-ID with the old?
[11:49:23] <pigdog> is the recurrance id used as an index or key?
[11:50:54] <bernard.desruisseaux> Purpose: This property is used in conjunction with the "UID" and "SEQUENCE" property to identify a specific instance of a recurring "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property value is the effective value of the "DTSTART" property of the recurrence instance.
[11:51:31] <pigdog> right. so changing a recurrence-id for an instance that hasn't changed seems to me to be a horrible idea.
[11:52:26] <alexeymelnikov> Usings Cyrus' example: But is it the same instance or another one moved one week later?
[11:52:38] <bernard.desruisseaux> Eliot: I agree.
[11:53:31] <Aki> Ok, we've got 7 minutes left. I'm sensing we need to take this to the list. However, I believe if we take Bernard's suggestion, we might be able to punt this one for 2556bis.
[11:53:34] <pigdog> so alexey, what you're saying is that the problem we're facing is that the key is tied to the date/time.
[11:53:48] <Lisa> That does seem to be a problem on reflection.
[11:54:17] <pigdog> ok, i agree with aki. take to list.
[11:54:29] <alexeymelnikov> So only the client regenerating instances would know for sure.
[11:55:08] <cyrus_daboo> In my example, ideally you want to preserve each instance and shift them a week later as each has its own set of attachments etc. Canceling the 5th one and adding an '11th' one would be wrong, as the attachment info for no 5 would be lost, and the others would be out of sync.
[11:56:20] <pigdog> right. classic case could be a tv show that gets cancelled for a week due to some unforseen event, and has an episode DESCRIPTION
[11:56:34] <cyrus_daboo> Right - the client regenerating should be able to get the intent from the user and adjust R-ID for each overridden instance to either preserve the override data or throw away as needed. But iTIP does not provide a way to convey that mapping to attendees, which is why a CANCEL followed by new meeting is the better solution there.
[11:56:59] <pigdog> or a better key?
[11:57:28] <Aki> So #62 remains open. Take it to the list.
[11:58:33] <Aki> We have about 2 minutes, so I think we can stop here.
[11:58:47] <pigdog> thanks aki.
[11:58:52] <pigdog> and all
[11:59:15] <Aki> Thanks everyone, same time next week?
[11:59:31] <alexeymelnikov> Ok.
[11:59:33] <Lisa> Nov 23 is Thanksgiving
[11:59:34] <bernard.desruisseaux> ok
[11:59:35] <Lisa> in the US :)
[11:59:38] <JonLennox> Next week Thursday is Thanksgiving in the US. (National holiday)
[11:59:44] <pigdog> doh!
[11:59:50] <pigdog> two weeks
[12:00:22] <Aki> Hmm.. Ok, let's move that instance a week further -- but with the same description! ;-)
[12:00:33] <alexeymelnikov> :-)
[12:00:52] <Aki> So back here in 2 weeks. Saga continues on the list in the mean time, though.
[12:01:12] <Aki> Cheers!
[12:01:19] <pigdog> ciap
[12:01:20] <pigdog> ciao
[12:01:23] --- pigdog has left
[12:01:25] <alexeymelnikov> Bye
[12:01:53] --- alexeymelnikov has left
[12:01:55] --- Aki has left
[12:02:45] <cyrus_daboo> FYI I'm on vacation the week after next so won't be able to attend.
[12:03:15] --- cyrus_daboo has left
[12:04:15] --- JonLennox has left
[12:37:39] --- oliver88 has joined
[13:27:43] --- Lisa has left
[13:46:10] --- oliver88 has left
[14:52:51] --- bernard.desruisseaux has left