[05:47:46] --- oliver88 has joined
[05:47:49] --- oliver88 has left
[09:26:29] --- mikeh has joined
[10:32:51] --- pigdog has joined
[10:33:15] <pigdog> good afternoon. the fun begins in a little less than 1/2 hour
[10:45:37] <pigdog> The Fun Begins in 15 minutes
[10:47:11] --- bernard.desruisseaux has left
[10:47:14] --- bernard.desruisseaux has joined
[10:54:38] <pigdog> well, we start in 5 minutes
[11:00:40] <pigdog> well, awfully quiet
[11:00:48] <pigdog> let me ping alexey and cyrus
[11:02:08] <pigdog> we'll give people just a moment or two
[11:02:35] --- alexeymelnikov has joined
[11:02:41] <pigdog> welcome alexey
[11:02:48] <pigdog> we're going to wait just a moment or two to start
[11:03:02] --- cyrus_daboo has joined
[11:03:19] <pigdog> welcome cyrus
[11:03:23] <cyrus_daboo> Hi.
[11:04:03] <pigdog> so, i have to send Aki's regrets. he is in the midst of a reorg of some form. sort of reminds me of an old apple joke
[11:04:22] --- oliver88 has joined
[11:04:41] <pigdog> at the 1988 summer picnic they were serving fortune cookies that said "Congratulations! Your department won't be reorged for a year!"
[11:04:45] <pigdog> wasn't true for most
[11:04:58] <pigdog> ok, let's get going
[11:05:17] <oliver88> hi
[11:05:24] <pigdog> so the agenda is to continue down the list of open issues, with a recap from last week
[11:05:25] <pigdog> hi oliver
[11:05:32] <pigdog> would anyone like to agenda bash?
[11:05:52] <pigdog> ok, then.
[11:06:07] <pigdog> the brief recap is that last week we roughly speaking got from issue 13 to issue 17.
[11:06:22] <pigdog> we have to return to some of those issues briefly today and then we will press on
[11:06:41] <pigdog> as discussion from list indicated we do not yet have consensus text for issue 13.
[11:06:48] <pigdog> so, turning to that issue...
[11:07:00] <bernard.desruisseaux> right...
[11:07:23] <pigdog> are there any ideas as to how to better address the ambiguities that Bernard's test clearly identified?
[11:07:31] <bernard.desruisseaux> for issue 13 it turns out that implementors ended up with 3 different ways to interpret the draft
[11:07:53] <pigdog> bernard, which of the three was most popular?
[11:07:55] <bernard.desruisseaux> while I agree that the text is not clear on this particular issue...
[11:08:15] <bernard.desruisseaux> It depends how you define popular...
[11:08:29] <bernard.desruisseaux> # of implementation / market share !
[11:08:37] <cyrus_daboo> They are all used by different products of varying 'importance' .
[11:09:13] <pigdog> i guess the question is this: which would cause the least amount of disruption in the market place?
[11:09:30] <bernard.desruisseaux> the reason I think we ended up with 3 different ways of implementing this, 8 years after the RFC has been published ... is probably because this is NOT a very important issue...
[11:09:32] <pigdog> or confusion in the customer base (put another way)
[11:09:45] <bernard.desruisseaux> Else people would have agreed on a common solution while back...
[11:10:17] <pigdog> i could make a different argument that it hasn't been important up until now, but could become important
[11:10:22] <pigdog> consider the case of cisco.
[11:10:40] <pigdog> we reserve teleconference functions using iCalendar
[11:10:47] <pigdog> that's a real resource
[11:10:55] <cyrus_daboo> The key thing to remember is that this particular issue is actually rare - at this point I believe simply stating that DTSTART not being an instance in an RRULE is NOT RECOMMENDED. i.e. we document the fact that its non-interoperable and tell people not to do it.
[11:11:18] --- cyrus_daboo has left
[11:11:22] <pigdog> so, why don't we go for stronger than that?
[11:11:26] <pigdog> uhoh
[11:11:31] <pigdog> (lost cyrus)
[11:11:35] --- cyrus_daboo has joined
[11:11:41] --- cyrus_daboo has left
[11:11:52] <bernard.desruisseaux> The survey we ran was "what do you get when you import this ics file..."
[11:12:01] --- cyrus_daboo has joined
[11:12:18] <cyrus_daboo> back
[11:12:20] <pigdog> i actually like the text that cyrus wrote
[11:12:26] <bernard.desruisseaux> Another survey that would be interesting... is "can your calendar client application generate such an ics file..." ?
[11:12:33] <pigdog> but i wonder if you would rather go with something stronger.
[11:12:52] <pigdog> like DTSTART MUST be the first occurrence in an RRULE
[11:13:13] <pigdog> and then for backward compatibility sake, state how implementations would interpret it
[11:13:17] <cyrus_daboo> Bernard and I were discussing yesterday on our regular CalDAV call, and I believe he has a real proposal that actually goes a little further...
[11:13:27] <bernard.desruisseaux> yep
[11:13:31] <pigdog> please go on
[11:13:59] <bernard.desruisseaux> if we RECOMMEND or REQUIRE that DTSTART match the pattern of the rule...
[11:14:12] <bernard.desruisseaux> than obviously it becomes difficult to have more than one RRULE...
[11:14:25] <bernard.desruisseaux> since DTSTART would need to match them all!
[11:14:44] <pigdog> good point
[11:15:07] <bernard.desruisseaux> Given that very few (any??) iCalendar application provide support for multiple RRULE...
[11:15:35] <bernard.desruisseaux> we could specify a new requirements to say that you SHOULD NOT specify more than 1 RRULE... otherwise... you are on your own...
[11:16:07] <bernard.desruisseaux> Finally... has been discussed on the mailing list in a separate thread... We would "deprecate" EXRULE.
[11:16:24] <pigdog> i like both approaches.
[11:16:48] <pigdog> Bernard, can you propose text for the multiple RRULE issue?
[11:16:53] <pigdog> first, are there any objections?
[11:17:13] <bernard.desruisseaux> BTW, given that those are new requirements... and that in the future we may want to define how multiple RRULEs work and allow DTSTART that don't match the rule with a precise meaning... I would go with SHOULD NOT
[11:17:41] <pigdog> as opposed to MUST NOT?
[11:17:45] <bernard.desruisseaux> yep
[11:17:59] <bernard.desruisseaux> People can use them... but they are on their own ...
[11:18:13] <bernard.desruisseaux> The spec doesn't specify what they mean...
[11:18:26] <bernard.desruisseaux> later on we can decide to specify their meaning...
[11:18:43] <pigdog> I would have to think about what that later means
[11:18:51] <pigdog> but SHOULD NOT should be sufficient
[11:19:17] <pigdog> will you also state that the date specified in DTSTART be the first RRULE occurrence?
[11:20:04] <pigdog> hello?
[11:20:06] <bernard.desruisseaux> yes
[11:20:16] <bernard.desruisseaux> DTSTART is always part of the COUNT
[11:20:34] <bernard.desruisseaux> DTSTART is always a recurrence instance
[11:20:44] <bernard.desruisseaux> DTSTART SHOULD always match the pattern of the RRULE
[11:20:58] <pigdog> ok, then i think we have the issue on track for resolution. action is yours to propose precise text.
[11:21:08] <bernard.desruisseaux> Ok.
[11:21:15] <pigdog> moving on
[11:21:21] <bernard.desruisseaux> I have a question though...
[11:21:25] <pigdog> ?
[11:21:43] <bernard.desruisseaux> What does it mean "to deprecate EXRULE" ?
[11:21:43] <cyrus_daboo> Great - this also helps to start addressing some of the mobile vendors concerns with RRULEs - getting rid of multiple.
[11:22:10] <pigdog> to me it means "do not generate" for now.
[11:22:16] <bernard.desruisseaux> Do we change the text everywhere in the draft to no longer make reference to it?
[11:22:21] <pigdog> later one might update the spec to say "may ignore"
[11:22:38] <pigdog> i think you want to reduce it as much as possible
[11:22:51] <pigdog> but I think you should raise specific instances.
[11:22:54] <bernard.desruisseaux> Do we remove its definition completely? or move it in an appendix?
[11:23:39] <alexeymelnikov> If you have "changes since" section, you should mention that EXRULE is removed. And no need to mention it anywhere else
[11:23:47] <pigdog> no, i think you must keep it for now, but state clearly that it is deprecated and that implementations MUST NOT generate them.
[11:24:06] <pigdog> the next guy gets to remove it in the next rev
[11:24:12] <bernard.desruisseaux> a) Remove EXRULE completly from the draft b) Keep definition and mark it as deprecated c) Keep definition and specify MUST NOT use it (!) d) Keep definition and specify SHOULD NOT use it
[11:24:52] <pigdog> the only question is what a compliant system can do when it sees one that someone else generated
[11:25:02] <pigdog> a) respect it
[11:25:04] <pigdog> b) ignore it
[11:25:25] <bernard.desruisseaux> c) reject the object!
[11:25:28] <pigdog> this really depends on how many implementations there are of it
[11:25:42] <alexeymelnikov> I prefer b) or a) (probably b)), followed by d)
[11:25:54] <pigdog> what's d?
[11:26:29] <alexeymelnikov> "Keep definition and specify SHOULD NOT use it"
[11:26:55] <pigdog> SHOULD NOT generate
[11:26:59] <pigdog> right/
[11:27:00] <pigdog> ?
[11:27:16] <bernard.desruisseaux> e) Keep definition, mark it as deprecated, and specify SHOULD NOT generate it + change the text in the rest of the draft to no longer make reference to it...
[11:27:32] <pigdog> e is good so far...
[11:27:40] <pigdog> but now we have to answer the question of what happens when you see one?
[11:27:52] <alexeymelnikov> The way d) is specified it means SHOULD NOT generate and SHOULD NOT process
[11:28:04] <cyrus_daboo> Move it to an appendix of 'changes since 2445' under a sub-section 'deprecated features'.
[11:28:17] <alexeymelnikov> I agree with Cyrus
[11:28:22] <pigdog> bernard?
[11:28:28] <pigdog> oliver?
[11:28:33] <cyrus_daboo> NB These changes will also need to be reflected in iTIP (my job).
[11:28:33] <oliver88> 0
[11:28:59] <pigdog> ok, barring objection that's what we'll do
[11:29:18] <mikeh> What will the appendix say though?
[11:30:05] <pigdog> let me propose that bernard have the opportunity to tackle that before we continue on this issue. we're half through the hour and we should move along
[11:30:14] <mikeh> ok
[11:30:14] <cyrus_daboo> Something like: 'Use of EXRULE as defined in [2445] has been deprecated due to interoperability issues and lack of implementation support to actual generate EXRULEs'.
[11:30:15] <pigdog> mike, are you okay with us doing that?
[11:30:29] <pigdog> ok, thanks
[11:30:31] <cyrus_daboo> I don't think we need to repeat the full definition from 2445.
[11:30:58] <pigdog> let's please take this to the list
[11:31:00] <bernard.desruisseaux> People can always refere back to RFC 2445
[11:31:04] <cyrus_daboo> So thge 'deprecated features' sub-section will have items for:
[11:31:11] <cyrus_daboo> 1. No EXRULE
[11:31:19] <cyrus_daboo> 2. No multiple RRULEs.
[11:31:31] <cyrus_daboo> 3. No DTSTART different from RRULE.
[11:31:36] <pigdog> no (2) is not for the appendix
[11:31:41] <pigdog> neither is 3
[11:31:47] <pigdog> that must be in normative text
[11:31:56] <cyrus_daboo> It should still be listed in a 'changes' section.
[11:32:03] <pigdog> oh, i have no problem with that
[11:32:09] <pigdog> as long as it is first in normative text
[11:32:17] <pigdog> ready to move along?
[11:32:32] <bernard.desruisseaux> Yes. I have enough info to propose text to the list...
[11:32:45] <pigdog> ok...
[11:33:06] <pigdog> i believe this will bring us to issue 23
[11:33:35] <pigdog> there seems to be consensus on this issue. bernard, do you have text?
[11:34:08] <bernard.desruisseaux> Well... we simply need to fix the ABNF... no?
[11:34:28] <bernard.desruisseaux> Ooops... doh
[11:34:46] <bernard.desruisseaux> I need to propose text. I will.
[11:34:53] <pigdog> ok. thanks.
[11:35:24] <pigdog> moving on
[11:35:44] <pigdog> so now issue 24 is what we just discussed
[11:36:22] <pigdog> any objections to mark it as such and move on?
[11:36:33] <cyrus_daboo> It becomes irrelevant with our new solution.
[11:36:42] <bernard.desruisseaux> Well.. given that multiple RRULE will be NOT RECOMMENDED... this is no longer an issue.
[11:36:48] <bernard.desruisseaux> Right
[11:37:06] <pigdog> ok. moving right along then
[11:37:21] <pigdog> this brings us back to Issue 25
[11:37:30] <pigdog> we are deprecating EXRULE
[11:37:39] <pigdog> do we have precise text in the proposal that went to the mailing list?
[11:38:16] <bernard.desruisseaux> No. That will be part of my "omnibus proposal" that should address issue 13, 24, and 25 and maybe more!
[11:38:45] <pigdog> ok, so i will link this issue with the other two.
[11:39:48] <pigdog> ok, moving right along
[11:40:03] <pigdog> Issue 26
[11:40:45] <pigdog> we have text. is this in the -02 draft?
[11:41:19] <bernard.desruisseaux> It's not
[11:41:42] <pigdog> Does anyone object to the new text?
[11:42:00] --- oliver88 has left
[11:42:50] <pigdog> I believe we already have consensus on this issue. Bernard, please make the changes.
[11:42:58] <bernard.desruisseaux> ok
[11:43:05] <pigdog> moving on
[11:43:18] <pigdog> Issue 27
[11:43:42] --- oliver88 has joined
[11:43:45] <pigdog> AI is for Cyrus to propose text
[11:44:10] <pigdog> Cyrus, are you able to do this or should someone else?
[11:44:40] <pigdog> am i still live?
[11:44:46] <bernard.desruisseaux> Yes
[11:44:48] <alexeymelnikov> Yes you are
[11:44:51] <cyrus_daboo> Yes, just reviewing...
[11:45:31] <pigdog> i think the issue here as i recall is more of UI issue rather than anything else.
[11:45:31] <cyrus_daboo> I am not sure we have consensus on the right way to solve this.
[11:45:37] <cyrus_daboo> We have two options:
[11:46:26] <cyrus_daboo> 1) When determining the length of an instance, the original duration should be used (as inferred from DTEND-DTSTART, or DURATION).
[11:47:08] <cyrus_daboo> 2) When determining the length of an instance, as above for DURATION, but with DTEND, the DTEND value must be 'preserved'.
[11:47:47] <pigdog> i don't believe a computer can make a determination
[11:47:51] <cyrus_daboo> 'preserved' is somewhat complicated as it requires doing recurrence expand seed with the DTEND value, but that may not match the RRULE....
[11:47:56] <bernard.desruisseaux> I believed we had consensus on (1).
[11:48:05] <cyrus_daboo> At this point I think we need the simple case (1)
[11:48:41] <pigdog> i recall at the meeting that some people felt that DTEND was just as important
[11:48:54] <pigdog> consider the case of someone who simply marks off busytime in their schedule
[11:49:42] <pigdog> i thought the only thing needed here was some clarifying text to say that implementations should be prepared to offer users the option of either
[11:49:43] <bernard.desruisseaux> We should add a statement such as "regardless if DTEND or DURATION were used to specify the duration of the first recurrence instance..."
[11:50:00] <cyrus_daboo> suggestion:
[11:50:00] <bernard.desruisseaux> and Cyrus can propose a "Note:" for the implementors (a nice to have)
[11:50:02] <cyrus_daboo> When generating instances from an RRULE, the end time of an instance is determined from the duration derived from the difference between the DTSTART and DTEND properties, or DURATION properties in the component.
[11:50:24] <pigdog> right to both of you
[11:50:42] <pigdog> wait
[11:50:44] <pigdog> i'm sorry-
[11:50:46] <cyrus_daboo> slight tweak:
[11:50:48] <cyrus_daboo> When generating instances from an RRULE, the end time of an instance is determined from the duration derived from the difference between the DTSTART and DTEND properties, or DURATION properties in the component, together with the start time of that instance.
[11:51:19] <pigdog> Cyrus, is duration ALWAYS important?
[11:51:35] <pigdog> what i mean, is why would we word it in such a way that makes that inference?
[11:52:39] <cyrus_daboo> Not really sure why that would be an issue.
[11:53:01] <cyrus_daboo> Really we need some reasonable guidline on how the end time for an instance is determined.
[11:53:40] <pigdog> if DURATION is specified, then you have it. that's not the interesting case. the interesting case is DTEND
[11:54:41] <pigdog> one way to do it would be to convert to UTC and subtract, applying appropriate VTIMEZONE definitions
[11:55:02] <pigdog> you might also be able to do this in other ways
[11:55:11] <pigdog> the key point is that VTIMEZONEs MUST be observed
[11:55:26] <pigdog> right?
[11:55:31] <bernard.desruisseaux> Sigh
[11:55:47] <pigdog> or am i way off base?
[11:55:47] <bernard.desruisseaux> I create a recurring events with three instances...
[11:55:57] <bernard.desruisseaux> the first instance will last two hours...
[11:56:11] <bernard.desruisseaux> I want every instances to last two hours.... that's it.
[11:56:19] <bernard.desruisseaux> We don't care for the time zone shift...
[11:56:19] <pigdog> then you use DURATION
[11:56:25] <bernard.desruisseaux> it is not important enough.
[11:57:07] <bernard.desruisseaux> Implementations are currently using either DURATION or DTEND...
[11:57:31] <bernard.desruisseaux> and there decision to use either one was NOT based on this specific issue !
[11:58:04] <cyrus_daboo> We need a section that describes how to deal with DST 'edge cases'. These include the recurrence instance spanning a DST transition, as well as start/ent times that refer to times that do not exist or are duplicated during the actual DST shift.
[11:58:33] <pigdog> well, if you like i could take off my dilbert hat and propose some changes
[11:59:24] <cyrus_daboo> Bernard, can you write an iCal object that has a recurrence that has an instance for Sunday midnight to 8 am on the day of a DST shift, and uses DTSTART/DTEND. Then ask people to say what the actual end time was in their client.
[12:00:10] <cyrus_daboo> We should see the end as either 7 am or 9 am depending on the shift direction, and NOT 8 am.
[12:00:28] <pigdog> gentlemen, our time is up.
[12:00:42] <pigdog> we will leave this issue open, and I will take it to the list.
[12:00:54] <pigdog> thanks very much for your participation, again! i can see we're making great progress.
[12:00:55] <bernard.desruisseaux> Cyrus, we have had this discuss about 10 times...
[12:01:13] <pigdog> next week, i would like to have an authors call if that's okay
[12:01:21] <bernard.desruisseaux> I will send a proposal to the list for issue 27.
[12:01:27] <bernard.desruisseaux> ok
[12:01:31] <pigdog> ok, thanks bernard. thank you all.
[12:01:35] <cyrus_daboo> But no formal solution....
[12:01:47] <oliver88> What is an authors call?
[12:02:02] <pigdog> it is for the chairs to check in with the authors on how we are all doing
[12:02:16] <oliver88> thank you
[12:02:24] <pigdog> see you all next week.
[12:02:24] <cyrus_daboo> Telephone conference - i.e. we get to hear each other speak rather than see our typing.
[12:02:34] <pigdog> ciao
[12:02:40] --- pigdog has left
[12:02:52] <cyrus_daboo> bye.....
[12:02:54] --- cyrus_daboo has left
[12:03:42] <oliver88> bye
[12:03:45] --- oliver88 has left
[12:04:05] <alexeymelnikov> bye
[12:04:09] --- alexeymelnikov has left
[12:08:46] --- mikeh has left
[12:34:10] --- bernard.desruisseaux has left
[12:49:16] --- bernard.desruisseaux has joined
[12:50:15] --- bernard.desruisseaux has left