[09:53:05] --- pigdog has joined
[09:56:48] --- bernard.desruisseaux has joined
[09:56:55] --- alexeymelnikov has joined
[09:56:58] <pigdog> good morning guys!
[09:57:04] <pigdog> (afternoon, alexey)
[09:57:06] <alexeymelnikov> Hi everybody
[09:57:09] <bernard.desruisseaux> Good morning!
[09:57:16] <pigdog> how are things going?
[09:57:28] <bernard.desruisseaux> Good! How's you kid?
[09:57:34] <bernard.desruisseaux> hour
[09:57:37] <bernard.desruisseaux> your
[09:57:38] <pigdog> not so bad.
[09:58:00] <pigdog> it turns out chickenpox is one of those things that you can get at six months without too many problems. and she doesn't even have the coordination to scratch
[09:58:31] <pigdog> so, aki won't make today's jabber
[09:58:39] <bernard.desruisseaux> I hope you are vacinnated Eliot!
[09:58:48] <pigdog> i got it when i was a baby as well
[09:58:54] <bernard.desruisseaux> good for you!
[09:58:59] <pigdog> (so my parents say - let's hope their memory is correct)
[09:59:05] <alexeymelnikov> :-)
[09:59:09] <bernard.desruisseaux> :-)
[09:59:27] <pigdog> so, alexey, are you ready to go through issues on the *other* documents?
[09:59:36] <pigdog> i think we
[09:59:45] <pigdog> i think we're getting close to being able to do that
[09:59:46] --- reinhold has joined
[09:59:52] <pigdog> good afternoon reinhold
[10:00:10] --- cyrus_daboo has joined
[10:00:16] <bernard.desruisseaux> Hi Reinhold and Cyrus
[10:00:16] <pigdog> hi cyrus!
[10:00:21] <cyrus_daboo> Hi.
[10:00:27] <alexeymelnikov> Hi
[10:00:39] <pigdog> ok, let's start now, and others can catch up as able
[10:00:44] <pigdog> agenda bashing:
[10:00:55] <alexeymelnikov> eliot: do you want to review issues for iTIP/iMIP today?
[10:00:59] <pigdog> 1. I'd like a sense of the room about how close we are to closing 2445bis.
[10:01:11] <pigdog> 2. remaining 2445 issues
[10:01:23] <pigdog> 3. agenda for 2446/2447bis docs
[10:01:32] <pigdog> alexey: not today - no warning
[10:01:37] <alexeymelnikov> Ok
[10:01:44] <pigdog> does that agenda suit everyone?
[10:01:49] <cyrus_daboo> Fine.
[10:01:51] <alexeymelnikov> Fine
[10:02:05] <pigdog> reinhold/bernard?
[10:02:06] <bernard.desruisseaux> yep
[10:02:08] <alexeymelnikov> Quick question in relationship to 1: was my list of "older" issues accepted?
[10:02:17] <pigdog> it will be
[10:02:26] <reinhold> Fine with me.
[10:02:35] <pigdog> if they're old, then it's an administrative blunder that the standard shouldn't suffer for
[10:02:51] <pigdog> ok, so, let's start with 1
[10:02:59] <alexeymelnikov> Ok, so I can start posting my issues one by one to the mailing list
[10:03:06] <reinhold> BTW, there was an old list of issues with 2445 and their proposed/agreed solution. Has that ever been looked at for 2445bis?
[10:03:22] <pigdog> not that i know of - but let's go to the agenda
[10:03:25] <pigdog> 1.
[10:03:52] <pigdog> i'd like to ask bernard to comment briefly on what he sees as remaining work. my own opinion is that we have yet to resolve "simplification"
[10:03:55] <alexeymelnikov> Bernard?
[10:03:58] <pigdog> comments, bernard?
[10:04:37] <bernard.desruisseaux> Here's a status update: - We need to reach concensus on about 14 issues. - There are 3 or 4 issues that needs to be added to the tracker. - I'm currently modifying the draft for 9 or 10 issues on which consensus was reached recently. - We will need to re-work Introduction / IANA Considerations / Security Considerations.
[10:04:52] <reinhold> pigdog, 2445bis is so far no "simplification", rather a clarification / bug fix "release"
[10:05:10] <bernard.desruisseaux> I think it is both.
[10:05:25] <pigdog> ok, let's not argue that point right now.
[10:05:46] <pigdog> if we have 14 issues (that perhaps doesn't agree with my count), perhaps bernard the best thing to do is to get right to them.
[10:05:51] <pigdog> can you lead the discussion or should i?
[10:06:02] <pigdog> (this would be 2)
[10:06:05] <bernard.desruisseaux> Let me get he issue numbers. Hold on.
[10:06:24] <pigdog> (insert elevator music here)
[10:07:00] <bernard.desruisseaux> 19 21 54 55 63 64 67 68 69 70 71 72 73 74
[10:07:16] <alexeymelnikov> What is the URL for the tracker again?
[10:07:17] <pigdog> ok. let's start with 19
[10:07:27] <pigdog> http://www.ofcourseimright.com/cgi-bin/roudnup/calsify
[10:07:37] <alexeymelnikov> Thanks
[10:07:51] <cyrus_daboo> Except that link does not work.
[10:07:54] <pigdog> ok, i owe bernard text and a proposal
[10:08:00] <bernard.desruisseaux> I've been relying on issue 19 for everything related to IANA.
[10:08:06] <pigdog> oops - it's "roundup"
[10:08:07] <bernard.desruisseaux> This is a BIG issue.
[10:08:13] <cyrus_daboo> Yes - typo.
[10:08:24] <pigdog> i'm sorry i've been delayed with the text.
[10:08:49] <pigdog> but i have notes from the previous jabbers and the consensus seems to be a table that points to sections (i won't regurgitate the whole jabber from the last time)
[10:09:24] <pigdog> if people can deal with my lame tardiness i should be able to work on this a bit tomorrow
[10:09:28] <pigdog> and we can move on
[10:09:32] <pigdog> agreed?
[10:09:41] <bernard.desruisseaux> Yes. Let's move on.
[10:09:48] <cyrus_daboo> Yes.
[10:09:56] <pigdog> ok, that brings us to 21
[10:10:28] <pigdog> first, i'm not entirely sure this is a 2445bis issue any longer, but i am close to convincing myself that our changes are backward compatible
[10:10:36] <pigdog> given the case, i would answer "no"
[10:10:41] <pigdog> is there disagreement?
[10:10:47] <bernard.desruisseaux> I agree.
[10:10:47] <alexeymelnikov> I tend to agree with you
[10:10:48] <cyrus_daboo> BTW for iana stuff - we now have two extension proposals on the table VVENUE and VAVAILABILITY. It would be good for one of those to use the new iana stuff once we have it but before we last call just to make sure it all makes sense when actually used.
[10:11:02] <pigdog> (cyrus: agree)
[10:11:10] <alexeymelnikov> cyrus: +1
[10:11:16] <pigdog> as to 21?
[10:11:17] <bernard.desruisseaux> cyrus: +1
[10:11:41] <cyrus_daboo> 21: - no we do not need a mime type (or iCal VERSION for that matter).
[10:11:44] <reinhold> I don't see anything that's not backward-compatible in 2445bis.
[10:11:53] <pigdog> ok, i'm hearing consensus
[10:12:02] <reinhold> (Except for the clarification that DTEND for dates is really exclusive)
[10:12:13] <bernard.desruisseaux> Can we discuss issue 54 right away?
[10:12:23] <pigdog> i think that's just a clarification. bernard, do we need to defer 21?
[10:12:39] <cyrus_daboo> We did fix some things that may mean existing implementations are broken because their way of doing it is now "wrong".
[10:12:43] <bernard.desruisseaux> I think we can close 21 with no change.
[10:12:49] <cyrus_daboo> But that does not warrant a version bump IMHO.
[10:13:02] <pigdog> ok, we have consensus on 21. will verify with the list.
[10:13:20] <bernard.desruisseaux> Issue 54 is the version bump.
[10:13:28] <bernard.desruisseaux> I agree with Cyrus that we don't need it.
[10:13:30] <reinhold> changing VERSION to 2.1 will break lots of implementations that explicitly check for 2.0
[10:13:45] <pigdog> i think the same logic for 54 applies to 21.
[10:13:51] <pigdog> (or visa versa)
[10:14:31] <alexeymelnikov> Agreed
[10:14:38] <reinhold> With wrongly implemented behavior that has now been clarified, one can always argue that's bug in the implementation.
[10:14:39] <cyrus_daboo> One thing we have not done is figure out if anyone breaks if we send multiple version numbers, which is allowed in the spec.
[10:14:53] <reinhold> Okay, sorry, have to leave for half an hour.
[10:15:06] <pigdog> ok, i think we're moving on.
[10:15:15] <cyrus_daboo> Or did someone check that VERSION:2.0,2.1 will break?
[10:15:35] <cyrus_daboo> In any case, we probably don't need it.
[10:15:38] <pigdog> cyrus: ok to move on?
[10:15:49] <cyrus_daboo> Yes - move on (.org).
[10:15:52] <pigdog> ;-)
[10:15:53] <reinhold> cyrus_daboo: I double that many implementations are ready for multiple verxsion numbers
[10:15:59] <pigdog> issue 55
[10:16:10] <pigdog> this is the big one
[10:16:36] <pigdog> let me see if i can summarize the objections
[10:17:05] <pigdog> "this standard is meant to be sufficiently general to be used for both calendaring and scheduling, and so removal of these components is inconsistent with that goal."
[10:17:27] <cyrus_daboo> Lets not block on this any more. Leave them in. We will need to write an implementation guide explaining how clients should downgrade in an interoperable way when they receive recurrence they cannot cope with. Calconnect TC-Mobile is interested in providing some statement on that.
[10:18:00] <pigdog> cyrus, if you are okay with that, let's propose it to the list, and see if we can get that added as a work item to the charter.
[10:18:12] <pigdog> do others agree?
[10:18:46] <bernard.desruisseaux> I agree with status quo on the issue. Not sure about new work item!
[10:19:09] <pigdog> we would have to find an owner, i think
[10:19:16] <pigdog> but let's save that part for later
[10:19:24] <pigdog> alexey? reinhold?
[10:19:26] <alexeymelnikov> Fine with me
[10:19:35] <cyrus_daboo> I'm not sure it needs to be an rfc per se. Maybe part of an update to 3283 (which we have not agreed to update at present).
[10:19:52] <bernard.desruisseaux> At some point we will want to revise RFC 3283: Guide to Internet Calendaring.
[10:20:03] <bernard.desruisseaux> cyrus: +1 !
[10:20:27] <cyrus_daboo> Like get rid of all those CAP references!
[10:20:31] <pigdog> ok... i think we have consensus.
[10:20:57] <pigdog> just a moment - sending email now...
[10:21:46] <pigdog> ok..
[10:22:07] <pigdog> Issue 63
[10:23:09] <pigdog> is there an argument in favor of this change at this time?
[10:23:21] <bernard.desruisseaux> Well...
[10:23:48] <cyrus_daboo> Just to be sure: if RRULE is present, we now require that DTSTART match the first instance of the RRULE, right?
[10:23:51] <bernard.desruisseaux> To me it was a simple clarification. It is obvious to me that you need to allow an RDATE value less than the value of DTSTART
[10:24:01] <bernard.desruisseaux> Cyrus: Yes.
[10:24:31] <pigdog> so is this still an issue?
[10:24:33] <cyrus_daboo> That holds irrespective of the presence of any RDATE.
[10:24:59] <bernard.desruisseaux> Yes.
[10:25:14] <cyrus_daboo> So RDATE could be used to get the "old" behavior back where the DTSTART was not the first generated instance of the RRULE.
[10:25:37] <cyrus_daboo> But it would be a lot clearer and hopefully interoperable, unlike the current situation.
[10:25:49] <bernard.desruisseaux> Absolutely. That was discussed back then.
[10:26:08] <cyrus_daboo> But we probably need to make clear that RDATE before DTSTART is a bad thing in a STANDARD or DAYLIGHT component.
[10:26:11] <pigdog> ok, so let me turn the question around: is there objection to this issue being accepted, reinhold?
[10:26:40] <cyrus_daboo> (Bernard and I were having VTIMEZONE issue discussions over the last few days).
[10:27:01] <pigdog> ok, apparently reinhold has stepped away.
[10:27:16] <pigdog> let us for the moment requery the list as to whether this issue can be accepted
[10:27:46] <cyrus_daboo> I think we can say RDATE<DTSTART, except in STANDARD or DAYLIGHT components.
[10:27:48] <bernard.desruisseaux> alexey ? cyrys?
[10:28:16] <bernard.desruisseaux> Cyrus: Why??
[10:28:49] <cyrus_daboo> The spec says for STD/DAY components that DTSTART represents the "onset" of the tz change - having an earlier RDATE would change that and may break existing processors that use that behavior of DTSTART.
[10:28:58] --- cmtalbert has joined
[10:29:23] <bernard.desruisseaux> cyrus: that's not quite right...
[10:30:07] <bernard.desruisseaux> You need to read the entire section....
[10:30:38] <bernard.desruisseaux> Unfortunately the information is how "onset date and time" are specified is scattered in the section...
[10:30:52] <bernard.desruisseaux> onset date and time can be specified by DTSTART, RDATE and RRULE...
[10:31:15] <cyrus_daboo> I am reading now and it is too vague (as we found before). We certainly need a ticket for a major clean-up of that section.
[10:31:50] <cyrus_daboo> But it does not explicitly state that DTSTART is the earliest onset - so we might get away with RDATE < DTSTART.
[10:32:20] <bernard.desruisseaux> I don't see why you say "get away". It was never forbidden!
[10:32:48] <pigdog> cyrus, would you be willing to accept the textual change?
[10:32:57] <pigdog> /4.8.5.3
[10:33:03] <pigdog> (sorry - wrong window)
[10:33:28] <cyrus_daboo> Subject to clarification of vtimezone behavior, I am ok with RDATE<DTSTART everywhere else.
[10:33:56] <pigdog> bernard, can you propose some clarifying text for VTIMEZONEs?
[10:34:09] <bernard.desruisseaux> BTW, I agree with Cyrus that we need to clean up the sectino on VTIMEZONE. So far I have proposed 3 text changes for this section.
[10:34:33] <bernard.desruisseaux> I need the chairs to accept to add a new issue to the tracker for this.
[10:34:33] <pigdog> ok... we're just not there then, but i believe we have consensus on this issue.
[10:34:50] <pigdog> since it is a derivative of an old one, no problem
[10:35:28] <pigdog> ok.. we'll move on in just a sec.
[10:36:19] <pigdog> Issue 64, then 67, 68, 69
[10:36:22] <pigdog> now 64
[10:37:07] <pigdog> unless there are objections, i'd like to declare consensus.
[10:37:35] <pigdog> consensus
[10:37:37] <bernard.desruisseaux> good
[10:37:51] <pigdog> 67
[10:38:11] <cyrus_daboo> Yes to 64.
[10:38:41] <bernard.desruisseaux> People at CalConnect seemed interested by (b).
[10:39:04] <pigdog> ok. 67. are there objections to (b)?
[10:39:27] <pigdog> it seems to me this moves the issue to iTIP
[10:39:27] <alexeymelnikov> Sorry, issue 64: what is the consensus?
[10:39:40] <bernard.desruisseaux> Eliot, actually... for rfc2445bis (b) also means status quo
[10:39:40] <pigdog> alexey: to accept the text
[10:40:00] <pigdog> bernard: got it
[10:40:05] <alexeymelnikov> Which? The last entry from Bernard lists multiple choices
[10:40:06] <cyrus_daboo> (b) is interesting, but is a significant change to iTIP. For now I propose we leave it in, but discuss later during iTIP bis. If we decide we do not want to change iTIP for compataibility reasons, then we have to come back and remove from 2445bis.
[10:40:21] <pigdog> alexey: that's issue 67
[10:40:34] <pigdog> issue 67: we have no consensus
[10:41:15] <pigdog> ok. anyone object to leaving this one for iTIP and moving on - for now?
[10:41:26] <cyrus_daboo> That seems best right now.
[10:42:04] <reinhold> Okay, I'm back (student came for an oral exam). I'm now reading up and trying to respond to the discussion:
[10:42:26] <pigdog> (I'm just writing up results of 67)
[10:42:37] <reinhold> 1) issue 55 (deprecating Minutely/secondly): I'd like to leave them in, too. In particular, KAlarm uses minutely recurrences already.
[10:43:29] <pigdog> Issue 68
[10:44:47] <pigdog> First, is there agreement that the examples be forbidden? Second, is there agreement that we need text (or have I missed the text)?
[10:45:00] <bernard.desruisseaux> No!
[10:45:20] <bernard.desruisseaux> We need the ability to specify time that don't exist in VTIMEZONE components!
[10:45:20] <pigdog> Bernard, you do not agree.
[10:45:44] <reinhold> 2) regarding issue 63 (RDATE earlier than DTSTART): I don't like that idea. It makes implementations much harder, as you have to loop through all events in the calendar instead of simply checking DTSTART>=first shown date.
[10:46:04] <pigdog> reinhold, please take to list
[10:46:23] <bernard.desruisseaux> Reinhold: This is an implementation detail.
[10:46:39] <pigdog> please let's stay on issue 68 for now.
[10:46:46] <cyrus_daboo> reinhold: you can cache a "virtual" dtstart that is the lower of dtstart and any rdate.
[10:47:21] <pigdog> i am prepared to close this issue with no change unless we (a) have agreement and (b) have text. do others agree with bernard that this isn't a good idea?
[10:47:40] <reinhold> 3) I'm fine with 64 (request status)
[10:48:09] <cyrus_daboo> 68: I agree with Bernard. A recurring event that uses a valid time (2.30 am on Sunday) should be valid across a DST transition. What we need to do is clarify how clients handle such times. i.e. shift to 3.30 am or 1.30 am on the transition day.
[10:48:21] <bernard.desruisseaux> Eliot: I haven't said that it was not a good idea. I''m simply saying that it's more complex than that...
[10:48:22] <reinhold> 4) PERIOD values in f/b (issue 67): Is there support out there from implementations? If not, I don't think it's a good idea to explicitly allow them.
[10:49:02] <pigdog> bernard, do you want to propose text?
[10:49:47] <reinhold> 5) Issue 68: Requiring UTC for times falling into a DST shift causes problems when you want to create a recurring event that start e.g. at 2:30 at a date where the clock is moved from 3:00 to 2:00. You can't use UTC in that case as the rule might not even exist in UTC, and the proposal is to disallow local time, too.
[10:50:20] <bernard.desruisseaux> Eliot: No.
[10:50:22] <pigdog> on 68, i don't think he's saying "use UTC". i think he's saying, don't reference times that don't exist
[10:50:29] <pigdog> or that exist twice
[10:50:33] <pigdog> within a single timezone
[10:50:40] <pigdog> but now i'm conjecturing
[10:50:52] <pigdog> ok, absent text this issue will be closed.
[10:50:56] <reinhold> That reschedulled event would have the proper DTSTART (which is before the original DTSTART), thus causing no problems.
[10:51:35] <pigdog> i'm sorry- i just noticed.
[10:51:45] <pigdog> we can split this into two
[10:52:05] <pigdog> one: don't specify times that either don't exist or exist twice, and (b) the UTC issue
[10:52:17] <pigdog> (the first issue being (a)
[10:52:18] <cyrus_daboo> I think we need some text pointing out the overlap/missing time issue with recommendations on how clients handle that.
[10:52:35] <alexeymelnikov> Cyrus: I agree
[10:52:41] <pigdog> ok, we need a volunteer to write text. cyrus? alexey?
[10:52:45] <pigdog> reinhold?
[10:52:59] <alexeymelnikov> Not me :-)
[10:53:15] <alexeymelnikov> as I am not in the best position to recommend anything
[10:53:20] <cyrus_daboo> I will try. Bernard, where is the best place for something like that?
[10:53:39] <bernard.desruisseaux> What do you mean?
[10:53:59] <cyrus_daboo> Where in 2445bis would you want to describe timezone disconntinutuiy problems?
[10:54:38] <pigdog> ready to move on to Issue 69?
[10:55:05] <cyrus_daboo> Sure...
[10:55:39] <pigdog> ok, same sort of thing. first, do people agree with the author's assessment?
[10:56:55] <bernard.desruisseaux> The "naive" behavior describe by Jonathan is bad.
[10:57:34] <bernard.desruisseaux> Looks like one of those thing that would make sense to computer scientist but not everybody else...
[10:57:46] --- jonlennox has joined
[10:57:56] <pigdog> Mr. Lennox! Just in time!
[10:58:00] <jonlennox> Excellent!
[10:58:02] <bernard.desruisseaux> Hi Jonathan!
[10:58:07] <alexeymelnikov> Hi
[10:58:13] <jonlennox> I just got back from vacation, and realized that the calsify meeting was today.
[10:58:22] <cyrus_daboo> My own feeling is that if one of start or end is outside the discontinuity, then the "effective" duration should be used to calculate when the other ought to occur (UTC-wise) and that defines it.
[10:58:34] <pigdog> well, please go to http://www.ofcourseimright.com/cgi-bin/roundup/calsify
[10:59:10] <cyrus_daboo> If both start/end fall within the discontinuity - you get what you deserve!
[10:59:11] <pigdog> we are on Issue 69, but to get Cyrus out of a jam, here, perhaps we would ask you to consider working with Bernard to provide some clarifying text? there is some disagreement about your proposal
[10:59:30] <pigdog> for issues 68 and 69
[10:59:51] <jonlennox> Give me a sec to review which ones those were
[11:00:13] <cyrus_daboo> Besides, its not clear how clients are supposed to present a UI for a discontinuity - that's a pretty messy problem too.
[11:01:12] <pigdog> cyrus: as a working group chair, i don't think i could put forth a document that talks about effective duration without a normative definition.
[11:01:22] <pigdog> where is that?
[11:01:31] <cyrus_daboo> I thought we had that for the recurrence stuff?
[11:01:34] <jonlennox> For 68, my proposal was "don't use ambiguous or nonexistant times". It's client-dependnet what you do instead.
[11:02:01] <jonlennox> One solution is to use UTC, another is to specify the time in a different non-UTC timezone.
[11:02:17] <reinhold> Both don't work with recurrence rules, though.
[11:02:24] <jonlennox> Right.
[11:02:47] <pigdog> ok, so how do we handle recurrences?
[11:03:21] <jonlennox> I have an extreme solution, which resolves all the issues but potentially at too much of a change from existing practice:
[11:03:23] <bernard.desruisseaux> Eliot: For issue 27 I will need to introduce/define "nominal duration" and "exact duration".
[11:03:45] <pigdog> which one of those did cyrus mean?
[11:03:51] <jonlennox> Do all recurrences as thought discontinuities don't exist.
[11:03:55] <jonlennox> Er, as though.
[11:04:34] <pigdog> how do most UIs handle that case?
[11:04:47] <jonlennox> This is the generalization of the "nominal duration" algorithm.
[11:04:49] <reinhold> KOrganizer simply doesn't care about discontinuities.
[11:05:16] <pigdog> so what reinhold, what do you do with a recurring event that hits at a time that doesn't exist? ignore it?
[11:05:53] <pigdog> but i think i agree with bernard, perhaps these issues are dependent on 27?
[11:06:27] <pigdog> anyone still there?
[11:06:35] <bernard.desruisseaux> Still here
[11:06:37] <cyrus_daboo> Yes - thinking...
[11:06:37] <jonlennox> I am.
[11:06:55] <bernard.desruisseaux> I'm not sure they are dependent... but yes it is related. But then everything is
[11:07:40] <jonlennox> It's also complicated by the apparent decision to keep BYSECOND and BYMINUTE.
[11:07:45] <reinhold> We also don't show discontinuities (i.e. there is the hour 02:00-03:00, even if it doesn't exist or exists twice)
[11:08:18] <cyrus_daboo> We could state that clients SHOULD NOT generate explicit DTSTART/DTEND/RDATE that falls on a discontinuity. For a recurrign event that spans a discontinuity and includes an instance that intersects a discontinuity - the nominal duration (or exact) should be used.
[11:08:41] <pigdog> jonathon, can you propose text on these two issues (and possibly the next) based what cyrus just wrote?
[11:09:03] <bernard.desruisseaux> hold on...
[11:09:05] <jonlennox> Cyrus: are you talking about the start time hitting the discontinuity, or the extent?
[11:09:20] <bernard.desruisseaux> I for one do not agree with the "naive" behavior describe in issuee 69.
[11:10:02] <jonlennox> On reflection, I don't think it's the best solution either.
[11:10:02] <reinhold> neither do I, but then, when should the event occur?
[11:10:21] <bernard.desruisseaux> Actually, I think it would be "stupid" not "naive" (sorry Jonathan!)
[11:10:22] <cyrus_daboo> Either start or end in the discontinuity or start and end either side of one. The problem of both inside is still a problem!
[11:10:55] <bernard.desruisseaux> Well... Let's try to think like normal people... (oohh that hurts)
[11:11:11] <jonlennox> For the both-inside case, I also wonder if DURATION and DTEND should be handled differently.
[11:11:51] <pigdog> so the issue is really the start time. nominal duration would cover the other cases..
[11:12:02] <bernard.desruisseaux> Should an event scheduled to start at a local time that occurs twice ... should occur twice? Of course not!
[11:12:18] <jonlennox> I think that's probably true.
[11:12:34] <pigdog> guys- before we get too far into thisk can i ask that jonathon reconsider these issues and work offline with bernard to propose some alternative text?
[11:12:39] <pigdog> we have other issues to address
[11:12:41] <jonlennox> And an event scheduled to both start and end in a time that doesn't occur should still occur sometime, probably.
[11:12:45] <bernard.desruisseaux> Ok. Now the question is which one do we choose. It is important to agree on that!
[11:13:07] <bernard.desruisseaux> If we look at VTIMEZONE, we "sort of" choose the first instance...
[11:13:48] <bernard.desruisseaux> but then that's no where stated as such... instead, the RFC specifies that the DTSTART needs to be considered with TZOFFSETFROM ...
[11:13:58] <bernard.desruisseaux> which means... well the first time the local time occurs...
[11:14:28] <bernard.desruisseaux> I agree with Jonathan... The event should occur.
[11:14:29] <reinhold> Which makes sense (e.g. 2:30 is 2,5 hours after midnight, which would be the first occurrence local time)
[11:14:55] <pigdog> ok... can we put some normative text around it?
[11:15:33] <jonlennox> Well, we should informally decide on what the actual behavior should be, first.
[11:15:36] <bernard.desruisseaux> I wanted to do some tests with the Standard C library and Java to find out what happens when you don't think about these issues... and hence would be what I would call "naive behavior".
[11:16:06] <bernard.desruisseaux> ... and that would most likely be what the current implementation are doing today! :-)
[11:16:15] <jonlennox> It depends very much on how you implement calendar math.
[11:16:26] <bernard.desruisseaux> yes
[11:16:37] <jonlennox> I imagine that different implementations do the naive behavior differently.
[11:16:44] <jonlennox> Especially for things like COUNT and BYSETPOS.
[11:17:16] <pigdog> so, we are running out of time, and i have to understand what our next steps on these issues are.
[11:17:35] <pigdog> barring no next steps, we either must close the issue or block.
[11:17:52] <bernard.desruisseaux> Who believes those issues are REALLY hurting interoperability today?
[11:18:16] <jonlennox> I'll try to send a unified proposal to the list.
[11:18:37] <jonlennox> Bernard: probably not very often, exactly because DST transitions are chosen to be a time-of-day and day-of-week when not much is going on.
[11:18:49] <pigdog> thank you jonathan. please address issues 68 and 69. i propose that these issues not block.
[11:19:11] <pigdog> if you can tackle the third issue (Issue 70) that would be good as well.
[11:19:16] <pigdog> shall we briefly review that issue?
[11:19:44] <bernard.desruisseaux> Eliot, I would to discuss 3 issues not in the tracker
[11:20:26] <pigdog> if they've been introduced elsewhere, ok. otherwise, we should stick to what exists today
[11:20:56] <bernard.desruisseaux> I'm talking of issues that were discussed at the 65th IETF meeting
[11:21:00] <jonlennox> Is the issue I raised of recurrences with their start and end in different timezones addressed?
[11:21:10] <bernard.desruisseaux> but never made it to the tracker.
[11:21:11] <jonlennox> I sent that to the list, but I don't see it in the tracker.
[11:21:14] <pigdog> ok, bernard.
[11:21:31] <bernard.desruisseaux> 1- IETF 65 and 66: The CAL-ADDRESS and the DELEGATED-FROM,    DELEGATED-TO, and SENT-BY parameters require mailto URI    values.    The consensus was that other URI schemes should be allowed    but that we should specify exactly which URI schemes are    allowed. The restricted list of allowed URI schemes has    not yet been determined.
[11:21:34] <pigdog> If it is not 68, 69, or 70, i think those were the three you had
[11:22:00] <bernard.desruisseaux> 71 is also from Jon
[11:22:21] <pigdog> ok, thanks.
[11:22:22] <jonlennox> 71 is pretty uncontroversial, I think, though it needs normative text.
[11:22:27] <jonlennox> But that's not the one I was talking about.
[11:22:30] <reinhold> Jon, doesn't the RFC say that the duration of the initial occurence should be applied to all occurrences?
[11:22:51] <bernard.desruisseaux> Reinhold: See issue 27.
[11:23:09] <pigdog> bernard, on the issue you just raised, you say we need to specify URI schemes. are they fairly obvious or not?
[11:23:25] <bernard.desruisseaux> I don't know!
[11:23:30] <bernard.desruisseaux> Let me try...
[11:23:55] <jonlennox> The other issue I had was http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001387.html ; I don't see it in the tracker.
[11:23:55] <bernard.desruisseaux> We need to allow: mailto, ldap, xmpp, im, ... help!
[11:24:44] <pigdog> would those all work today?
[11:25:06] <bernard.desruisseaux> Jon: Your issue is related to issue 65: http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001351.html
[11:25:12] <cyrus_daboo> http:
[11:25:14] <cyrus_daboo> https:
[11:25:31] <jonlennox> Bernard: yes.
[11:25:39] <jonlennox> It's a complication of that.
[11:25:50] <alexeymelnikov> I guess it depends on how URIs being used. If they are purely identifiers, then they might work
[11:26:02] <bernard.desruisseaux> Jon: I think issue 27 and 65 covers everything. No?
[11:27:10] <bernard.desruisseaux> Jon: We allow DTSTART and DTEND to have different TZID. When DTEND is specified, the recurrence instances will inherit the "exact duration" of the instance defined by DTSTART/DTEND (who cares they had different time zone...). No?
[11:27:18] <reinhold> jonlennox: The RFC contains a SHOULD, which means "unless there are good reasons against". In the case of airline flights, there are reasons, so that's fine with the rfc, isn't it?
[11:27:31] <reinhold> bernard.desruisseaux: I agree.
[11:27:36] <pigdog> bernard, on this old issue: i think you sent me text with which to open an issue. since I suspect nobody else will do it, i suspect you should propose a list.
[11:27:58] <pigdog> i'll open an issue to track. reasonable?
[11:28:16] <jonlennox> So everything will use the actual duration of the first instance? That's potentially counter-intuitive, but well-defined, so okay.
[11:28:16] <bernard.desruisseaux> Yes. Go ahead.
[11:28:21] <bernard.desruisseaux> One comment though...
[11:28:32] <bernard.desruisseaux> RFC 2445 required "mailto URI"...
[11:28:42] <reinhold> About Issue 27: I think that the two cases of DURATION and DTEND should be treated differently. DURATION should apply in the given form (with 1D meaning "increase the date by 1), DTEND should use an implied duration calculated from the first occurrence.
[11:28:43] <bernard.desruisseaux> Are we conformatable to start accepting new URIs?
[11:29:02] <bernard.desruisseaux> I think we should... But is there any backward compability issues here?
[11:29:22] <pigdog> that would be my concern. what does the group think? cyrus? reinhold? others?
[11:29:26] <alexeymelnikov> Bernard: maybe we should say "MUST support mailto, SHOULD/MAY support others"?
[11:30:10] <jonlennox> Reinhold: what does "implied duration" mean, though? A count of UTC seconds, or an implied number of D/H/M/S?
[11:30:26] <pigdog> guys - please let's have one discussion
[11:30:31] <jonlennox> Sorry.
[11:30:46] <pigdog> as to Alexey's suggestion?
[11:31:16] <bernard.desruisseaux> Alexey's suggestion would work for me.
[11:31:29] <cyrus_daboo> I think it should say: "MUST support any URI scheme, however, only mailto:, xmpp:, ..., are currently defined as having any useful meaning as a calendar user address". We may still invent a new scheme for scheduling and we should leave the door open for that.
[11:31:31] <reinhold> I'm fine with any URL (we haven't implemented DELEGATED-FROM, DELEGATED-TO, and SENT-BY anyway). I see no reason why a standard should restrict these values to only email.
[11:32:27] <bernard.desruisseaux> Cyrus: While I would like to keep the door open, Ted was pretty clear that we should have a "restricted list" of URI schemes. . . Which mean no open door...
[11:32:39] <reinhold> After all, an attendee can have any URI, so restricting special roles to email seems artificial to me.
[11:32:40] <cyrus_daboo> Strictly speaking actually only mailto: has meaning in the context of iMIP. Nothing else describes use of other URIs. The calendar server-to-server protocol work will likely define the use of others.
[11:33:06] <pigdog> Ok, I'm now recalling the conversation.
[11:33:25] <pigdog> i believe the issue is that there are semantic means to the URIs that require code
[11:33:26] <reinhold> cyrus_daboo: But we are not talking about iMIP, this is only about iCalendar in general. Shouldn't this restriction rather go to the iMIP/iTIP specs instead?
[11:33:37] <bernard.desruisseaux> For years people have been asking... What about "conference rooms" ?
[11:33:43] <cyrus_daboo> I guess I disagree with ted at this point. It should be up to iTIP profiles to define what an acceptable calendar address is.
[11:33:56] <bernard.desruisseaux> You want to specify an ATTENDEE;CUTYPE=RESOURCE
[11:34:14] <bernard.desruisseaux> What's the calendar user address for the conference room?
[11:34:23] <bernard.desruisseaux> The conference room doesn't have an email address...
[11:34:33] <cyrus_daboo> If you are using iMIP there would be an email address "assigned" to the room.
[11:34:51] <alexeymelnikov> Bernard: It can be an email address, XMPP, HTTP, ...
[11:35:02] <cyrus_daboo> If you use CalDAV schedule it might the the http URI to the wedbdav principal resource of the room.
[11:35:12] <pigdog> is it possible to get into a situation where a participant couldn't be reached because the application didn't understand the scheme?
[11:35:29] <bernard.desruisseaux> Alexey: Well.... according to RFC 2445 is MUST be a mailto URI! Which is what we need to change! :-)
[11:35:34] <cyrus_daboo> The key thing is that the system knows how to deliver the invite to the appropriate recipient.
[11:35:41] <alexeymelnikov> A conference room might have an email address, but not necessarily a mailbox
[11:35:50] <bernard.desruisseaux> If the conference room has an entry in the directory server you could use an LDAP URI ...
[11:36:06] <cyrus_daboo> Sure the email may get forwarded to the admin who manages the room etc
[11:36:19] <alexeymelnikov> Eliot: yes, we can get into such situation
[11:36:20] <cyrus_daboo> ldap is fine too.
[11:36:31] <alexeymelnikov> Cyrus: yes
[11:36:46] <pigdog> Ok, so we need text to explain how that situation is handled (or not), right?
[11:36:48] <cyrus_daboo> The issue is whether things like ftp really make sense.
[11:37:14] <pigdog> do we need normative text explaining the use of each URI?
[11:37:15] <cyrus_daboo> Sorry, I have to go at this point....
[11:37:38] <pigdog> ok, actually so do i. let's take this one to email. thanks all for participating!!!!
[11:37:39] <reinhold> But we have the MAILTO: restriction only in the delegated-to/from and sent-by, not for other types of attendees.
[11:37:40] <alexeymelnikov> Maybe we should say that each URI schema would need some text explaining how it can be used in iCalendar
[11:37:41] <bernard.desruisseaux> How about an IANA registry of allow URI scheme for calendar user address? :)
[11:37:54] <pigdog> ;-)
[11:37:57] <pigdog> bye for now!
[11:38:02] --- pigdog has left
[11:38:09] <alexeymelnikov> Bernard: yes, I was actually thinking about this!
[11:38:13] --- cyrus_daboo has left
[11:43:00] --- reinhold has left
[11:46:30] --- cmtalbert has left
[12:09:04] --- alexeymelnikov has left
[12:20:34] --- jonlennox has left
[12:43:57] --- bernard.desruisseaux has left