[08:12:15] --- reschke has joined
[08:14:00] --- Bruce_Kahn has left: Disconnected
[08:17:04] --- rjs3 has joined
[08:38:13] --- Bruce_Kahn has joined
[08:38:27] <Bruce_Kahn> Morn'n folks.
[08:40:45] <rjs3> morning
[08:41:13] <Bruce_Kahn> Is anyone here in Minneapolis or are we all remote?
[08:41:47] <rjs3> I'm in the room. Though if someone closer to the WG is available to scribe I suspect I'd prefer they did it
[08:42:27] <Bruce_Kahn> Im in MA so I cant...
[08:43:31] <rjs3> I figured, given that theres 3 people in the room at the moment ;)
[08:45:28] <Bruce_Kahn> Guess someone forgot to send out an iCalendar notice to the WG about the meeting. :^)
[08:58:19] <rjs3> Nathaniel is going to serve as chair... "attendence is far more than I predicted"
[09:01:28] <rjs3> doing introductions
[09:02:47] --- mrose has joined
[09:03:34] <rjs3> slide: agenda
[09:04:17] --- hardie has joined
[09:04:34] <rjs3> need an editor to update 2445, 2446, 2447 -- we have volunteers
[09:05:05] <Bruce_Kahn> Add me to the list of possible candidates...
[09:05:07] <rjs3> changes are the result of interop testing -- we'd like to do more testing 1Q 2004
[09:05:44] --- leg has joined
[09:05:48] <rjs3> cyrus: list of open issues?
[09:05:52] <rjs3> chair: not reall
[09:06:14] <rjs3> nathaniel: is that bruce kahn? oooooo...cool
[09:06:14] <rjs3> .
[09:06:15] --- NFreed has joined
[09:07:10] <rjs3> lots of activity on list -- but little resolved
[09:07:21] <rjs3> no consensus -- hard to determine the problems
[09:07:39] <rjs3> doug has agreed to turn over editorship of the CAP draft to Nathaniel
[09:08:41] <rjs3> discussion of key issues: versioning, abnf, recurrence-id, scoping, vfreebusy, calscale
[09:08:56] <rjs3> not too many people in room confident to discuss technical issues
[09:09:10] --- mrose has left
[09:09:30] --- mrose has joined
[09:09:47] <rjs3> chris newman: suggest IMAP-like use of capabilities vs version numbers
[09:09:58] <rjs3> or capabilities with version numbers
[09:10:45] <Bruce_Kahn> Are there issues in CAP regarding RECURRENCE-ID or is that on the issue list due to the WG summer discussions on 2445??
[09:11:16] <rjs3> still discussing versioning specifically.
[09:12:08] <NFreed> Both versioning and capability announcement have their issues, but I tend
[09:12:38] <NFreed> to favor capability announcement in protocols.
[09:13:07] <NFreed> Media types offer a different set of concerns, of course.
[09:13:29] <rjs3> (side discussion about client-side capabilities)
[09:14:50] <leg> and the fact is, the server-only capabilities in IMAP have served us badly for some things, like MAILBOX-REFERRALS.
[09:14:51] <rjs3> mark crispin: IMAP view was that the [large] base protocol is mandatory to implement, is CAP the same?
[09:15:46] <rjs3> chris newman: a number of optional features in this spec should become extensions. One thing we should be sure to get right is a good extension mechanism
[09:18:39] <rjs3> chair: It looks like the documents we are revising *will be* a major version change anyway
[09:19:18] <rjs3> bob morgan: is it reasonable to put out a cap spec if the underlying ical stuff is broken?
[09:19:42] <Bruce_Kahn> There are not lots of changes for 2445-2447. Mostly clarifications really.
[09:19:46] <rjs3> chris newman: we need to move cap forward regardless, and I anticipate that they will move forward at the same time
[09:19:54] <rjs3> leg: is there a list of these changes?
[09:19:59] <rjs3> nathaniel: no.
[09:20:06] <leg> list of changes to the iCalendar specs
[09:20:10] <leg> or rather, list of problems
[09:20:20] <rjs3> chris: we really need this to move forward
[09:21:21] <rjs3> chair: anyone involved in implementing cap now?
[09:21:25] <NFreed> The MIME/822 experience provides an example that it is possible
[09:21:42] <rjs3> cyrus: me, but I'm waiting to see where the spec is going first
[09:21:46] <NFreed> to move forward with one specification even though a specification it
[09:21:55] <NFreed> depends on is in critical need of revision.
[09:23:17] <rjs3> chair: anyone want to improve the capabilities stuff in CAP (by supplying text)?
[09:23:33] <rjs3> cyrus: current capability command looks reasonable
[09:23:47] <rjs3> some concerns over the round trips it involves
[09:25:44] <Bruce_Kahn> FYI: Last known compiled issues list for 2445 is at http://www.softwarestudio.org/iCal/2445Issues.html (Dated 15Aug01)
[09:26:21] <rjs3> discussion over is CAP a repository of objects or a database scheduling server
[09:28:36] <leg> will rlbob ever get a chnace to speak?
[09:29:52] <rjs3> chair: do we feel it is a mistake to throw out the current on-wire protocol?
[09:30:11] <Bruce_Kahn> By on the wire are you referring to iTIP?
[09:31:34] <leg> on-the-wire: we're talking about CAP on BEEP
[09:32:33] --- nsb has joined
[09:34:15] <rjs3> dicussion on how much could be gained (lost?) by replacing repository parts of CAP with webdav
[09:35:31] --- kmurchison has joined
[09:36:11] <reschke> (if there's a question regarding what WebDAV does and doesn't, I'll be happy to answer that)
[09:36:17] <rjs3> problem: understanding recurring events in the context of webdav collections
[09:36:32] <leg> we have two webdav people here: ted & lisa.
[09:39:26] <reschke> if that's a containment question -- multiple bindings (dates) to the same recurring event should be able to model that
[09:41:04] <rjs3> Lisa agrees to write a document along the lines of "calandering over webdav" -- there seems to be interest in such a beast, except for the fact that it may draw the process out
[09:41:24] <hardie> I'm not sure I'm a "webdav" person. I'm more of an idea rat.
[09:41:49] <rjs3> Nathaniel will continue to work on the CAP protocol in parallel
[09:42:02] <NFreed> It seems clear to me that webdav is going to be used for calendaring so
[09:42:13] <NFreed> a document describing the issues that arise would be a good idea no matter
[09:42:15] <NFreed> what.
[09:42:35] <NFreed> Whether or not it would be a viable replacement for CAP is something for
[09:42:38] <NFreed> the WG to decide.
[09:43:08] <NFreed> I think having both would be best for now.
[09:43:27] <rjs3> ted sharing ned's opinion
[09:45:19] --- jaltman has joined
[09:45:20] <NFreed> (It is just me, or does calendaring seem especially subject to the
[09:45:45] <NFreed> problem of mulitple representations? We have iCal<->iCall in XML,
[09:46:14] <NFreed> itip<->irip<->imip<->webdav<->CAP. And yes, I know there are
[09:46:17] <rjs3> (discussion of how Exchange uses webdav)
[09:46:27] <NFreed> semantic differences, but these tend to fade from 10,000 feet.)
[09:46:51] <Bruce_Kahn> All XML flavors of iCalendar have been expired and no longer updated.
[09:47:13] <NFreed> So has interesting in publishing an XML mappping disappeared?
[09:47:30] <NFreed> fsinteresting$interest$$
[09:47:44] <Bruce_Kahn> It pops up now and then but the WG has not opt'd for one due to legacy reasons.
[09:47:57] <NFreed> Good.
[09:48:08] <rjs3> rough consensus to pursue calandering over webdav and cleaning up CAP in parallel
[09:48:23] <leg> lisa volunteers to write up stuff on current use of webdav & calendaring.
[09:48:43] <Bruce_Kahn> iTIP was intended to model the C&S workflow process and iMIP and iRIP were to be 'bindings' of iTIP over different transports.
[09:49:35] --- dcrocker has joined
[09:49:36] <Bruce_Kahn> iRIP was declared obsolete by CAP so CAP should be a binding of iTIP when doing workflow. When not doing workflow its a free-for-all...
[09:51:05] <rjs3> moving on to scoping
[09:56:26] <rjs3> minor clarifications needed -- moving on to ABNF
[09:56:46] <rjs3> Must be fixed -- must be complete ABNF for standards-track protocol
[09:57:19] <NFreed> ABNF completeness and syntactic correctness is something both the
[09:57:22] <NFreed> IESG and the RFC Editor now check.
[09:57:47] <rjs3> Cyrus would also like for all the ABNF to be in one place
[09:57:52] <NFreed> Other sorts of errors may or may not get noticed, of course.
[09:58:22] <rjs3> Other issues: EXPAND and QUERYID
[09:58:26] <rjs3> no one in room is "up to speed"
[09:58:39] <rjs3> cyrus: haven't stored queries been thrown out a while ago?
[09:59:06] <Bruce_Kahn> I concur. For 2445 we decided not to duplicate the ABNF and as a result we missed a couple omissions.
[09:59:17] <rjs3> chair: if no one stands up for it....
[09:59:27] <rjs3> More minor issues: Alarms/SEQUENCE
[09:59:37] <rjs3> Can there be two identical objects in the same calander?
[09:59:46] <rjs3> leg: doesn't the UID prevent this?
[09:59:58] <NFreed> Is the argument for collected ABNF in addition to having the relevant
[10:00:13] <NFreed> rules in the sections that describe them, or instead of?
[10:00:13] <Bruce_Kahn> Regarding UID: Not for repeating instances.
[10:00:49] <nsb> Bruce can you try to explain the problem to us?
[10:00:49] <Bruce_Kahn> iCal has 5 notes to the effect of duplicates should be collapsed into 1 copy (paraphasing a bit)
[10:01:20] <Bruce_Kahn> The issue was the need to change VALARMs to include a unique identifier or not.
[10:01:42] <Bruce_Kahn> The only case where this is necessary is if an event has duplicate identical VALARMs.
[10:02:11] <Bruce_Kahn> I questioned this usage case. I also noted that for entities, iCal and CAP have text prohibiting duplicates.
[10:02:48] <nsb> Should VALARMS have UIDs?
[10:03:25] <Bruce_Kahn> The are only necessary if the design will allow exact duplicates.
[10:03:32] <rjs3> leg: according to microsoft, valarms have uids. server should generate uids for objects that do not have them
[10:03:38] <Bruce_Kahn> They are unnecessary in all other cases.
[10:03:50] <rjs3> CALSCALE
[10:04:06] <Bruce_Kahn> Since alarms do not exist outside the vevent and events have UIDs, should alarms?
[10:05:56] <rjs3> chair: this can probably be lumped in with capabilities (support of other calander scales)
[10:06:07] <leg> a vevent may have multiple alarms.
[10:06:15] <rjs3> Next Steps (slides are outdated) ->
[10:06:33] <rjs3> Do we keep the WG open? If so, why?
[10:06:44] <rjs3> bob morgan: interoperability
[10:06:59] <rjs3> chair: thats probably too vague
[10:07:34] <rjs3> framework: "What do we expect people to do soon in a standard way that they cannot do now in a standard way?"
[10:07:42] <Bruce_Kahn> Multiple alarms are fine (AUDIO and DISPLAY, etc) but are exact duplicates of any practical use?
[10:09:02] <rjs3> 2 possibilities: intraorganization / interorganization focus
[10:11:19] <rjs3> chris: people are likely more often getting paid for the intraorganization problem.
[10:14:41] <rjs3> (discussion about use of ical objects within IETF)
[10:18:07] <rjs3> review of charter...
[10:19:09] <rjs3> topic of chair of the WG
[10:20:14] <rjs3> pat is willing to stay on or step down. Bob and Ned have both offered their time as well
[10:20:42] <NFreed> Right. I'm willing to serve as a co-chair if that's what's needed. Of course
[10:20:57] <NFreed> this will mean Ted will have to assume the role of sheparding AD.
[10:21:19] <rjs3> chris: suggests bob + pat until march when we rediscuss
[10:21:24] <hardie> warning to all: Ted is meaner than Ned...
[10:21:36] <NFreed> How true...
[10:24:17] <rjs3> chair: how important is it for us to update our charter/goals?
[10:24:22] <rjs3> ted: beyond critical
[10:25:15] <NFreed> I agree. A charter update is essential.
[10:26:35] <rjs3> strawman: close WG, have a BOF next time (do background work in the meantime)
[10:27:49] --- dcrocker has left: Disconnected
[10:31:04] <rjs3> ted: there are significant players in this product space who have not participated. can you change the atmosphere of the WG enough to fix this, or is a new group necessary?
[10:31:43] <rjs3> (ted) there is a SIGNIFICANT cost to reopening the group
[10:36:49] <rjs3> discussion of open vs closed (design team with review) development process
[10:46:28] <nsb> Goals: 3 documents (new charter - Bob, new CAP draft - nathaniel, webdav/calendar draft - Lisa. Target date: End of January. Then reevaluate the continued future of the list.
[10:47:30] <rjs3> that's it
[10:47:45] --- rjs3 has left
[10:50:22] --- jaltman has left: Disconnected
[10:52:18] --- kmurchison has left
[10:54:19] --- NFreed has left
[10:56:34] --- hardie has left: Disconnected
[10:58:24] --- reschke has left
[11:00:30] --- leg has left: Disconnected
[11:01:00] --- mrose has left
[11:03:12] --- nsb has left: Disconnected
[11:13:02] --- Bruce_Kahn has left
[11:46:52] --- heikki has joined
[11:54:20] --- heikki has left
[12:37:17] --- pieter has joined
[13:25:09] --- capps has joined
[15:25:07] --- kmurchison has joined
[15:25:17] --- kmurchison has left