[06:45:49] --- fabio.silva has joined
[09:03:17] --- reinhold has joined
[09:24:32] --- Alexey has joined
[09:29:33] --- eliot.lear has joined
[09:29:57] <eliot.lear> hi everyone
[09:32:45] <eliot.lear> waiting for others still
[09:33:01] --- aki has joined
[09:33:07] <eliot.lear> hi aki!
[09:33:11] <aki> Hi eliot
[09:33:26] <aki> DST giving me a hard time still ;)
[09:34:12] <eliot.lear> ;-)
[09:34:31] <eliot.lear> try molars on a 15 month old. wait. you just had that recently too...
[09:35:19] <eliot.lear> pinging others now
[09:35:40] --- cyrus_daboo has joined
[09:35:44] <eliot.lear> welcome cyrus
[09:35:53] <cyrus_daboo> Hi
[09:35:56] <aki> Hi
[09:36:53] <aki> Let's wait a minute (is Bernard joining?)
[09:37:16] <Alexey> Hi everybody
[09:37:30] <aki> Hi Alexey
[09:37:49] <aki> Ok, I think we should start now
[09:38:02] <aki> First a recap from two weeks ago
[09:38:15] <aki> (we missed last week due to conflicts, DST and all that)
[09:38:43] <aki> We spent quite a bit of time on issue #85
[09:38:58] <aki> With some strawman proposal for a way forward.
[09:39:03] <aki> Where are we with that?
[09:40:17] <eliot.lear> aki, i didn't see anything sent to the list.
[09:40:47] <aki> Do we need to handle it today? Cyrus?
[09:41:35] <cyrus_daboo> No it can wait. My priority right now is to get all my drafts done before the deadline. iTIP being one of those.
[09:42:03] <aki> Ok
[09:42:28] <aki> Then I propose we pick issues from the tracker today and try to sort them out
[09:43:41] <aki> I've sent issue 95 proposal on the list
[09:44:11] <aki> No replies yet; perhaps a couple of +1's and we turn that sucker into closed ;-)
[09:45:04] <eliot.lear> i think that would help.
[09:45:49] <eliot.lear> in general we seem to not be gaining consensus around the deprecations
[09:46:25] <eliot.lear> i personally think we should be able to do away with decline-counter still, but it needs more forceful argument
[09:46:29] <eliot.lear> (for instance)
[09:47:50] <cyrus_daboo> If we keep COUNTER then I see no reason to do away with DECLINE-COUNTER.
[09:48:07] <eliot.lear> sorry- i think we could probably do away with both
[09:48:21] <eliot.lear> i presume you agree ;-)
[09:48:59] <cyrus_daboo> Well I am really on the fence. We have heard from a few people that they do have that feature in their products and that customers do use it a lot.
[09:49:45] <eliot.lear> i know they have it in their products, but do customers really use it?
[09:50:22] <cyrus_daboo> They claim so.
[09:50:28] <fabio.silva> hm... would REPLY be used to replace COUNTER, or it would be simply dropped?
[09:51:31] <eliot.lear> or does the organizer simply issue a new invite?
[09:51:32] <cyrus_daboo> One option is to REPLY with DECLINED but include a COMMENT indicating the details of a counter (e.g. a suggested new time, place etc).
[09:52:53] <cyrus_daboo> The question is, when you COUNTER, do you always want to counter with a single alternative, or would it be better to counter with multiple possibilites. The later is important when you you lots of attendees that you have to match the counter proposal to as well.
[09:53:00] <fabio.silva> Then I'd rather keep COUNTER; COMMENT seems to lack structure counter-propose something...
[09:53:29] <eliot.lear> on an academic level...
[09:53:40] <fabio.silva> I was trying to solve this issue of suggesting multiple possibilities with draft-silva-events...
[09:53:41] <eliot.lear> i'm wondering if that might be a good thing.
[09:54:08] <eliot.lear> if we're looking for a way to ease implementation, how much mechanism is needed to implement counter?
[09:54:28] <aki> Let me put it in another way.
[09:54:40] <aki> Does not implementing COUNTER hurt interop?
[09:54:56] <aki> I.e., is this a feature implementations can safely drop?
[09:55:50] <cyrus_daboo> Well that argument could be applied to all features, and then we have an empty spec with 100% interoperability :-)
[09:56:05] <cyrus_daboo> The key here is whether there is a valid and important use case to support this feature.
[09:56:19] <fabio.silva> I agree that implementing it can be demanding, but I wouldn't deprecate COUNTER because of this...
[09:56:20] <eliot.lear> but cyrus, my experience is that this feature is very spottily implemented
[09:56:26] <cyrus_daboo> Not whether it interoperates well (if it does not then it needs attention in the spec).
[09:57:23] <fabio.silva> Cyrus, I believe that replying with multiple alternatives is a very important use case...
[09:58:03] <cyrus_daboo> Fabio, I believe you are right, but that implies a much bigger change to the current iTIP spec than I think we want to tackle right now. I would much rather see that as an extension.
[09:58:11] <fabio.silva> ...maybe we don't feel that much because of current interop issues, but for the future it will be a requirement
[09:58:28] <eliot.lear> isn't that what f/b is for?
[09:58:34] <fabio.silva> Yes, Cyrus, I do agree with you
[09:58:42] <aki> (and for instance, use the comment field in a DECLINE?)
[09:58:42] <aki> If it is, and people implement is and claim it's used, then I don't see a strong argument to deprecate.
[09:58:42] --- aki has left
[09:59:06] <fabio.silva> I don't think it is iTIP role to provide this "multiple counter" feature
[09:59:23] <cyrus_daboo> We need a "weighted" free-busy option: i.e. "I am a software engineer and I prefer meetings in the afternoon, but at a pinch I will meet in the morming".
[09:59:47] <eliot.lear> hmm
[09:59:58] <eliot.lear> but that's not counter
[10:00:01] <eliot.lear> that's f/b
[10:00:04] <cyrus_daboo> There is also the issue of fixed time-slots - i.e. you can book me for 15 minute intervals on 1/4 hour boundaries only.
[10:00:11] <fabio.silva> We tried to provide this time ranking with the extensions on the draft, by reusing f/b components
[10:00:23] --- aki has joined
[10:00:36] <aki> (sorry, dropped out for a sec)
[10:01:07] <fabio.silva> Anyway, I believe that the "simple" counter feature should be present on iTIP (whether on COUNTER itself, or with a modifies REPLY)
[10:02:28] <eliot.lear> my concern is just that it is poorly supported today. either we cut bate or we continue fishing for stronger interoperability. which means more user demand. i just don't see that in the priority list. am i wrong?
[10:02:35] <cyrus_daboo> Eliot - I think we need to look at what both Notes and Exchange do - they are the major implementations of scheduling to date that operate in an environment where COUNTER is more likely to be used. I know Notes definitely has it.
[10:02:47] <eliot.lear> exchange implements counter
[10:03:02] <fabio.silva> Eliot, f/b works like a "flat" free-busy information. Attaching it in a counter method (which is what I propose in the extensions draft) would denote availability for the currently negotiated event
[10:03:34] <fabio.silva> I would see them as complementary features
[10:03:53] <eliot.lear> fabio, do you envision someone integrating something like doodle (http://www.doodle.ch) in their calendaring system, where you paint a calendar for a specific event?
[10:04:31] <eliot.lear> on the other hand, if major implementations have already implemented counter, perhaps we should just leave it alone and move on
[10:04:57] <eliot.lear> does leopard ical do it?
[10:05:01] <fabio.silva> I didn't know this service, but seems that would be the idea
[10:05:17] <eliot.lear> how about kde?
[10:05:24] <eliot.lear> kcal?
[10:05:35] <cyrus_daboo> Event "negotiation" like doodle is an interesting possibility, however, in a busy environment, the latency involved makes it a non-starter as by the time everyone has replied, slots that earlier respondents may have said were free, are no longer free.
[10:05:51] <eliot.lear> that's my experience
[10:06:12] <eliot.lear> but that argues against keeping this stuff
[10:06:32] <eliot.lear> again, if i'm wrong and there's generally good interoperability we can just move on
[10:07:27] <cyrus_daboo> I don't know whether there has been a rigorous study of interoperability wrt COUNTER. That is something we can request Calconnect to do - but that likely won't happen until the next interop in February.
[10:08:27] <eliot.lear> so the question is what do we do in the meantime
[10:08:42] <eliot.lear> right now, with a chair hat on, i would say that there is no consensus to remove
[10:09:26] <cyrus_daboo> Agreed.
[10:09:37] <eliot.lear> ok, let's move on for now then.
[10:10:32] <aki> Picking the next one on the list, how about issue #88?
[10:10:52] <aki> That's about clarifying CANCEL definition
[10:11:32] <aki> ok, wait
[10:11:54] <aki> We skipped issue 86, deprecating SEQUENCE
[10:12:18] <eliot.lear> there was quite a bit of chatter on the list about this...
[10:12:56] <cyrus_daboo> We had chatter about removing it, as well as, if we keep it, when should it be incremented (particularly in regard to CANCELs).
[10:13:26] <eliot.lear> i think bernard, in particular argued that we need to keep it for METHOD:REPLY
[10:13:36] <cyrus_daboo> The later has a long history of contention on ietf-calendar.
[10:14:03] <eliot.lear> i think we also talked about moving text from 2445bis to 2446bis about when to bump
[10:14:25] <cyrus_daboo> At this point I think I have very nearly convinced myself that we do need it. If so, the spec needs to be much clearer on what its purpose is.
[10:14:59] <eliot.lear> ok, for both this and CANCEL are you requesting or proposing text?
[10:15:08] <eliot.lear> (or planning to propose text?)
[10:16:12] <cyrus_daboo> For CANCEL I think the proposal is clear, and I would like to update the spec for that right now.
[10:16:36] <cyrus_daboo> For SEQUENCE I need to propose text and then we get consensus on that before it goes into the spec.
[10:16:52] <cyrus_daboo> That won't happen before draft deadline.
[10:17:21] <eliot.lear> ok, so we'll look for new text for each.
[10:18:32] <aki> I think issue 89 is also in need of a text proposal.
[10:20:08] <cyrus_daboo> Right, for 88 & 89 I propose I change the text for the next revision, then we seek consensus on that. For 86 we need consensus on the list first wrt text changes.
[10:20:09] <aki> How about issue 90?
[10:21:32] <cyrus_daboo> Text is there. Again I can add that into the next revision. The only thing is I am not sure whether that represents actual protocol behavior, or should go into an "implementation guide" section.
[10:21:53] <aki> Cyrus: sounds good to me. The changes are minor anyway.
[10:22:00] <cyrus_daboo> Not all clients store data in native iCalendar format, so the advice is not always applicable.
[10:22:41] <eliot.lear> i think the issue is what happens if the event is exported somehow
[10:23:22] <cyrus_daboo> Yes, that is effectively what you would see.
[10:24:05] <eliot.lear> ok, next?
[10:24:12] <aki> Then, seems 91 is a minor correction as well.
[10:24:29] <aki> Apart from 86, is there an issue that requires more discussion?
[10:25:55] <aki> Is issue 67 still outstanding?
[10:26:55] <aki> Title: "Section Duration: VFREEBUSY request"
[10:27:58] <cyrus_daboo> Statement is still in 2445bis.
[10:28:45] <cyrus_daboo> I am not sure that anyone has implemented that behavior in iTIP (since iTIP did not allow it) so I suggest we remove the statement from 2445bis.
[10:29:24] <eliot.lear> we need bernard for this one
[10:30:23] <aki> Leaving 67 open then. I will up the thread on the list to try and finish it.
[10:30:31] <eliot.lear> ok, it's half past.
[10:30:39] <eliot.lear> same time next week?
[10:31:29] <aki> Personally, I think we need some mailing list traffic to justify the chats.
[10:31:42] <cyrus_daboo> OK.
[10:32:20] <aki> At least the issues in the tracker are either queued for the next version, or really need a proposal/discussion on list.
[10:32:38] <eliot.lear> ok
[10:33:14] <aki> So what say you we schedule the next one in two weeks, and dedicate on agenda bashing / IETF 70 preparations?
[10:33:42] <eliot.lear> that sounds good to me. others?
[10:35:22] <aki> If nobody objects, I'll announce on the list
[10:35:27] <eliot.lear> thanks aki
[10:35:39] <Alexey> Sure
[10:35:52] <aki> Allright, we're done.
[10:35:56] <aki> Thanks all!
[10:36:06] <aki> Bye
[10:36:19] --- eliot.lear has left
[10:36:21] --- aki has left
[10:37:50] <fabio.silva> bye!
[10:37:52] --- fabio.silva has left
[10:48:53] --- cyrus_daboo has left
[11:05:12] --- Alexey has left
[11:30:51] --- reinhold has left