[00:54:44] --- DougRoyer has left
[00:55:00] --- DougRoyer has become available
[01:34:53] --- pguenther has become available
[01:37:12] --- mrose has become available
[01:38:58] --- lisa has become available
[01:39:07] <lisa> Morning
[01:39:33] --- bdesruisseaux has become available
[01:39:56] <DougRoyer> morning, the audio is working. I can hear talking and I could hear someone testing the mic.
[01:40:07] <lisa> Excellent
[01:48:32] --- apn has become available
[01:49:05] <apn> Good morning everyone
[01:58:26] --- ray_atarashi has become available
[02:01:39] --- Hollenbeck has become available
[02:02:05] --- Ted_Hardie has become available
[02:02:11] --- mike has become available
[02:02:58] --- Barry Leiba has become available
[02:03:09] --- rlbob has become available
[02:03:47] <rlbob> lisa: calconnect is supporting cal work by gathering requirements, interop results, etc
[02:04:03] <rlbob> similar input from others is welcome too
[02:04:10] <Ted_Hardie> Was there an intro of the two folks at the front who aren't Lisa and Aki?
[02:04:17] <rlbob> charter review
[02:04:51] <rlbob> up front are lisa dusseault and aki niemi, co-chairs of the brand-new wg
[02:05:25] <rlbob> also up front are chris stone and bernard desruisseau, who are speaking
[02:05:49] <Hollenbeck> Ted: yes
[02:05:52] --- shmaes has become available
[02:06:24] --- ob has become available
[02:06:25] <rlbob> draft authors: bernard doing ... ? and alexei melnikov doing itip
[02:07:05] <rlbob> will be using new PROTO WG process: WG chairs will shepherd docs thru IESG process
[02:07:46] <rlbob> intent is to move core stds to Draft standard status
[02:07:48] <bdesruisseaux> I will be co-editor with Chris for RFC2445bis
[02:08:00] <rlbob> this may leave some products behind
[02:08:08] --- ludomp has become available
[02:08:41] <rlbob> some 2445 etc features may be removed, even though some impls may exist
[02:09:13] <rlbob> caldav status is noted (work is ongoing) but is not on agenda of this WG
[02:09:56] <rlbob> aki has been working on cal/sched using SIP events, early draft is linked from calsify links page
[02:10:03] <bdesruisseaux> http://ietf.webdav.org/calsify
[02:10:15] <apn> The draft name for the SIP event based cal is 'draft-niemi-sipping-cal-events-00'
[02:10:30] <rlbob> US timezone change coming up, example of stuff we have to deal with
[02:11:40] <rlbob> pete resnick: question about moving to Draft Std: how do we decide whether impls are "independently developed"
[02:12:13] <rlbob> ted hardie: criterion is code bases spose to be independent
[02:12:47] <rlbob> th: there can be a question of independence when developers work together, there's a reasonableness test
[02:13:03] --- pguenther has left: Disconnected
[02:13:41] <rlbob> pr: so chairs/wg have to be proactive in finding out whether impls were really independent
[02:14:23] <rlbob> th: devs talking is OK, still have to have doc that is independently implementable, without talking
[02:14:49] <rlbob> eliot lear: have to worry about feature velocity, if it's too slow might have to recycle at proposed
[02:15:08] --- faw has become available
[02:15:25] <rlbob> rohan mahy: is there split between basic and advanced feature dev?
[02:15:32] <rlbob> lisa: will get to that
[02:16:28] <rlbob> chris stoner: pending legislation on US changes sched for 2007
[02:16:40] --- tonyhansen has become available
[02:16:50] <rlbob> ld: 2445bis strategy:
[02:17:34] <rlbob> may involve bringing some impls up to speed to get to DS
[02:18:11] <rlbob> cs: intent is not to strip everything out, still need useful features
[02:19:06] <DougRoyer> ICal was originally for small devices as well as huge applications. I would hope be some place in the middle.
[02:19:13] --- resnick has become available
[02:19:29] <DougRoyer> oops (i hope the goal is in the middle)
[02:19:30] <rlbob> calconnect posted questionnaires to ietf lists re recurrences and timezones
[02:19:57] <rlbob> and is hosting interop events
[02:21:00] <rlbob> timezones have variability in impls, very useful but painful
[02:22:14] <rlbob> recurrences: rescheduling overlapping entries is a big problem, much variation
[02:22:25] <DougRoyer> Can the details of the cal connect results be posted? Only the summary or conclusion of tests does not help non cal connect members.
[02:22:48] <rlbob> unbounded rules are implemented, can be a problem
[02:22:49] <lisa> The interop results that are used to justify RFC2445 work will all be posted.
[02:22:59] <DougRoyer> :-)
[02:23:46] <rlbob> cs: yes, results will be posted, minus vendor names (when requested)
[02:24:02] <rlbob> ld: WG will only use publicly posted data
[02:24:29] <rlbob> cs: even calconnect members should post to calsify list re interop observations
[02:25:01] <rlbob> cs: awkward rules in recurrence a problem, eg Feb 29?
[02:25:36] <rlbob> bd: timezones: apps usually support only finite tz set
[02:26:12] <rlbob> support for arbitrary new tz objects not realistic
[02:26:47] <rlbob> maybe constrain tz defs to only those defs relevant to current event
[02:27:02] <DougRoyer> I think we should use the simplified VTIMEZONE entries (2445 valid) of RDATE only and drop recurring rules. It would make it easier for everyone to parse them.
[02:27:08] <rlbob> jeff mccullough: compilng use case data
[02:27:19] --- cnewman has become available
[02:27:37] <rlbob> re tz, recurrence, etc
[02:28:08] <rlbob> features with few impls: vtodos, vjournal, geo property, ...
[02:29:33] <rlbob> patrik faltstrom: once was AD when cal was being worked on, recommended avoiding tz, or having abstraction layer
[02:30:01] <rlbob> eg event happens at location, location has tz
[02:30:38] <rlbob> WG did include tz defs, and indeed there are problems
[02:31:05] <rlbob> time to step back and look at what should happen, must be stringent and precise
[02:32:18] <rlbob> nathaniel borenstein: people may think of locations rather than tz's
[02:32:54] <rlbob> chris newman: in olson tz db, names of tzs are location-based
[02:33:16] <DougRoyer> BTW: Mr Olson asked us to STOP calling it the 'Olson' database.
[02:33:21] <rlbob> so could create iana registry of those names, et voila
[02:33:35] <rlbob> eliot: is olson tz db sufficiently normative?
[02:34:09] <rlbob> cn: only thing more normative is to go to govts themselves, which info is often anecdotal
[02:34:48] <rlbob> cn: not standardizing the zones themselves, just the names ...
[02:35:16] <DougRoyer> Part of my proposal includes GEO locations
[02:35:26] <rlbob> pete: asked UN once, they said it's a regional problem, anybody asked them recently?
[02:35:36] <rlbob> apparently not
[02:35:52] --- lisa has left
[02:36:29] <rlbob> th: echo patrik, part of issue is that humans handle heuristics, but ops should be useful even without them
[02:36:56] <rlbob> eg some events need coordination, may not have physical location, no human to coord
[02:37:40] <rlbob> nsb: should use GMT when tz not known
[02:38:13] <rlbob> re iana, will need network service not just registry since defs are dynamic
[02:38:19] <Ted_Hardie> The question of whether GMT is a timezone is harder question than it might appear
[02:38:55] <rlbob> rohan: re iana ...
[02:39:34] <rlbob> randy presuhn, chair of lang tag registry: yes, exactly this problem, need to indicate timing of reg entry creation etc, can be done with iana reg
[02:40:06] <rlbob> cs: some tzs change based on local custom
[02:40:45] <rlbob> cn: yes, on olson list you see that changes are regular, not iana material
[02:41:18] <rlbob> pf: this argues for removing tz defs from events
[02:41:53] <rlbob> ld: has anyone implemented a cal agent that looks up tz data live? apparently not
[02:42:10] <rlbob> bd: oracle clients download tzs from their cal server
[02:42:26] <rlbob> using proprietary means
[02:43:40] <rlbob> paul guenther: report on changes on tzs in australia for sydney olympics in Risks Digest
[02:44:00] <DougRoyer> speak up!
[02:44:44] <rlbob> ... (nokia): have experiences with trying to do tzs, had lots of problems, went to just +-UTC, worked better for users
[02:45:22] <rlbob> keith moore: how to handle recurring events that cross tz?
[02:45:35] <Ted_Hardie> Corby speaking
[02:45:55] <rlbob> corby wilson: hasn't been a problem, haven't had such events
[02:47:00] <rlbob> ld: so solution depends on server, doesn't work when it's client-client?
[02:47:04] <rlbob> corby: true
[02:48:10] <rlbob> patrik: example event: recurring event at 9PM New York time, so was at different times re UTC at different times of year
[02:48:53] <rlbob> nsb: maybe client should pre-compute offsets ...
[02:49:20] <rlbob> pg: and that was the "risk" since for olympics the def changed post-compute
[02:49:44] <cnewman> I spent several years lurking on the Olson timezone database mailing list because it was fun in a wierd way. There are effectively continuous discussions of changes to the database. One person will post about a newspaper article about a timezone change, and there will be people calling around trying to confirm the report. Once confirmed, a database update is pushed. This is something that can only be done by a committed group of fanatics because there is no international registry.
[02:50:45] <DougRoyer> cnewman: Yes, that;s why many of us hope to use that DataBase
[02:51:06] <rlbob> ld: i-d was submitted on tz registry, by doug royer, also tz service
[02:51:57] <rlbob> technical issues: scale, security, etc
[02:52:30] <cnewman> This is why we should treat the timezone names as an IANA registry, but we should not get IANA involved in the zone definitions themselves.
[02:52:31] <rlbob> authoritativeness/political issues: maintained by volunteers, they make judgements
[02:53:02] <rlbob> question about status that this document should be given: experimental?
[02:54:21] <rlbob> bd: maybe passing identifiers and pointers would work best, current spec requires passing definition
[02:55:05] <rlbob> km: even listing issues would be useful, since registry question is significant
[02:56:19] <rlbob> rohan: having changing defs on server creates push/pull problem: does service notify, or wait for client to pull?
[02:57:10] <rlbob> pf: is this tz problem not calendar-specific but maybe worth its own special effort?
[02:58:17] <rlbob> cs: tz changes affect things like heating/cooling schedules in buildings
[02:59:15] <rlbob> cn: with politics and people involved, can't ever have perfect tech solution, so can have good-enough solution and leave it to quality-of-impl position
[02:59:50] <rlbob> pete: willing to look into finding International Body to take on this problem
[02:59:55] --- apn has left: Replaced by new connection
[03:00:09] --- apn has become available
[03:01:06] <DougRoyer> Maybe take the TZ issue to the CALSCH list so it does not distract CALSIFY ?
[03:01:34] --- Barry Leiba has left
[03:01:43] <rlbob> ld: please make concrete proposals to the list
[03:01:59] --- Ted_Hardie has left: Logged out
[03:02:03] <rlbob> ld: thanks for coming, see you on the list
[03:02:05] --- bdesruisseaux has left
[03:02:06] --- Hollenbeck has left
[03:02:06] --- cnewman has left
[03:02:07] --- ob has left
[03:02:09] --- mike has left
[03:02:10] --- rlbob has left
[03:02:16] --- apn has left
[03:02:59] --- lisa has become available
[03:03:25] <DougRoyer> Lisa: You were not on this list when i said: Maybe take the TZ issue to the CALSCH list so it does not distract CALSIFY ?
[03:03:40] --- ray_atarashi has left
[03:04:52] --- ludomp has left
[03:05:27] <DougRoyer> What was the attendance ?
[03:08:22] --- mrose has left
[03:11:09] --- lisa has left
[03:13:28] --- mrose has become available
[03:19:43] --- oern has become available
[03:19:46] --- oern has left
[03:20:51] --- resnick has left: Disconnected
[03:20:55] --- faw has left: Disconnected
[03:26:06] --- mrose has left
[03:31:13] --- tonyhansen has left
[03:32:02] --- shmaes has left
[03:35:34] --- lisa has become available
[03:37:25] <lisa> Hi Doug
[03:37:34] <lisa> Attendance was good
[03:37:40] <lisa> Roughly 50-60
[03:39:52] --- lisa has left
[04:37:02] --- bdesruisseaux has become available
[04:49:03] --- bdesruisseaux has left
[12:33:44] --- DougRoyer has left