[09:34:16] --- simvai has joined
[09:45:52] --- simvai has left
[09:47:29] --- simvai has joined
[10:12:10] --- cyrus_daboo has joined
[10:12:44] <cyrus_daboo> Hi, Cyrus here.
[10:13:13] --- bdesruisseaux has joined
[10:16:57] <bdesruisseaux> Info for remote participants... Agenda: http://tools.ietf.org/wg/calsify/agenda68 Slides: http://www3.ietf.org/proceedings/07mar/slides/calsify-0.pdf Audio stream: http://videolab.uoregon.edu/events/ietf/ietf686.m3u
[10:20:21] --- alexis has joined
[10:20:36] <cyrus_daboo> The audio stream has suddenly gone very quite.
[10:20:51] --- afh@jabber.netzwert.ag has joined
[10:22:00] --- csch has joined
[10:24:56] --- alexeymelnikov has joined
[10:25:27] --- apn has joined
[10:25:52] <alexeymelnikov> I will try to scribe
[10:25:57] <cyrus_daboo> Audio is not loud - is Elito speaking into mic?>
[10:26:17] <alexeymelnikov> Agenda bashing
[10:26:17] <apn> Hold on, mic was off
[10:26:30] <cyrus_daboo> Better!
[10:26:53] <csch> Audio ok now!
[10:27:42] <alexeymelnikov> 2445bis - very close to WGLC
[10:28:20] <alexeymelnikov> Thanks to Bernard for working on 2445bis
[10:28:29] --- barryleiba has joined
[10:28:47] <alexeymelnikov> Weekly jabber sessions helped to move forward with the document
[10:29:43] <alexeymelnikov> It might be possible that 2445bis would change as a result of 2446bis changes
[10:30:13] <alexeymelnikov> Eliot asked Bernard not to update the draft before we close all issues
[10:30:36] <alexeymelnikov> Chairs will ask Eric Burger to find an Apps Review Team reviewer
[10:31:22] <alexeymelnikov> We will ask IANA to have an early look at 2445bis IANA considerations
[10:31:33] <alexeymelnikov> Milestones are out of date
[10:32:14] <cyrus_daboo> Name please?
[10:32:27] <cyrus_daboo> Who was on the mic?
[10:32:32] <apn> This was Jonathan Lennox
[10:32:33] <alexeymelnikov> John Lennox?
[10:32:44] <cyrus_daboo> Thanks...
[10:33:30] <alexeymelnikov> Bernard: when is IETF LC?
[10:33:55] <cyrus_daboo> I agree that IESG/IETF review of all docs together is better.
[10:33:55] <alexeymelnikov> Eliot: will WGLC each document, then request IETF LC for all of them at the same time
[10:34:43] <alexeymelnikov> Jonathan will talk about discontinuity issue
[10:34:51] <alexeymelnikov> Issue 73 is closed
[10:35:19] <alexeymelnikov> 23, 78 are closed as well
[10:36:12] <alexeymelnikov> Issue 10 (end date not inclusive, VTODO) - no text
[10:36:37] <alexeymelnikov> Issue 11 (additional examples)
[10:36:52] <alexeymelnikov> Call for people to send Bernard their favorite examples
[10:37:25] <cyrus_daboo> I don't care about leap seconds!
[10:37:27] <alexeymelnikov> Issue 71: leap-second discontinuity
[10:37:34] <csch> Lawyers might ...
[10:37:52] <alexeymelnikov> Jonathan: ignore leap seconds, don't generate them ever
[10:37:56] <csch> There is a difference between Dec-31-xxxx 24:00 and Jan-01-xxxx 00:00
[10:37:58] <csch> (legally)
[10:37:59] <alexeymelnikov> No objections to the proposal
[10:38:34] <cyrus_daboo> DEC-31 XXX 24:00 DOES NOT EXIST - Dec 31 23:59:60 does!
[10:38:41] <cyrus_daboo> When there is a leap second.
[10:38:45] <alexeymelnikov> Bernard: do we want to allow leap seconds in ABNF?
[10:39:20] <csch> I know - lawyers don't - they call it 24:00
[10:39:23] <csch> anyway ...
[10:39:42] --- mtcarrasco has joined
[10:39:48] <alexeymelnikov> Dave Crocker: if this is intended for humans, then this doesn't matter
[10:40:07] <alexeymelnikov> Jonathan (previously): duration can be 1 second longer
[10:41:00] <csch> computers don't see the :60 anyway, don't they? Most unices just adjust their internal timer ticks to have a day, which is 1/86400 longer than usual - so software doesn't see the :60 ?!?!
[10:41:40] <alexeymelnikov> Dave Crocker: we can live with imprerfection, as we can live with duplicate deliveries in SMTP
[10:42:27] <cyrus_daboo> I agree with Patrik - we still need a way to represent leap seconds - but for duration calculations with use nominal duration.
[10:42:50] <alexeymelnikov> Paf: be careful about saying "ignore leap second", as you don't want your application to crash when they see/display "60 seconds"
[10:44:11] <alexeymelnikov> Eliot: for purposes of duration, we will use nominal duration, which will ignore leap seconds
[10:44:57] <alexeymelnikov> Issue 67 (Duration and VFREEBUSY request)
[10:45:44] <alexeymelnikov> Bernard: In VFREEBUSY one can specify both DTEND and DURATION
[10:47:04] <cyrus_daboo> +1 with Bernard
[10:47:06] <alexeymelnikov> Don't change iCalendar and maybe change iTIP later
[10:47:40] <alexeymelnikov> Issues 8, 68, 69, 70
[10:48:07] <bdesruisseaux> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-March/001581.html
[10:49:04] <alexeymelnikov> Jonathan is talking
[10:49:12] <bdesruisseaux> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-March/001612.html
[10:49:21] --- guenther has joined
[10:50:18] <alexeymelnikov> If the time is repeated: do we pick the first, the second, both?
[10:51:41] <alexeymelnikov> Sometimes an event can occur 3 times (corner case)
[10:54:11] <alexeymelnikov> Possible solutions:
[10:54:28] <alexeymelnikov> (Not going to type them :-))
[10:55:23] <alexeymelnikov> Eliot: handling of repeated event is not specified, ask user for guidance
[10:55:51] <alexeymelnikov> Jonathan: for automatic processing, there is no user
[10:56:20] <alexeymelnikov> Eliot: on entry, a user is always involved
[10:56:47] <alexeymelnikov> Eliot: "an error should be logged"
[10:56:53] <cyrus_daboo> With data entry - you cannot control what may happen in the future with new timezone definitions. If those het automatically applied, then old rules may now generate a disconntinuity when they did not before.
[10:57:59] <cyrus_daboo> The trouble with moving DTEND to the earlier time is that it may end up less than DTSTART!
[10:59:27] <cyrus_daboo> I have to think some more about that and see if I can come up with an example of what I mean
[11:00:33] <alexeymelnikov> Eliot: we will go with R1, unless there some objections/counter-examples
[11:01:08] <alexeymelnikov> Moving on to the "skipped" cases
[11:02:08] <alexeymelnikov> Jonathan suggest to use S1, but not sure
[11:02:57] <alexeymelnikov> (this might be slightly surprising that 03:00:00 is one second after 01:59:59
[11:03:03] <alexeymelnikov> Or maybe S2
[11:03:38] <alexeymelnikov> Bernard: VTIMEZONE uses time which is skipped
[11:03:46] <alexeymelnikov> Jonathan: this is a special case
[11:06:01] <alexeymelnikov> Eliot: ask Paul Vixie (who did cron)
[11:06:56] <alexeymelnikov> Bernard: Suggest S2, as this matches VTIMEZONE behavior
[11:07:18] --- nsb has joined
[11:08:46] <alexeymelnikov> Another corner case: an island moved from UTC-10 to UTC+14 (skipping a day)
[11:08:59] --- guenther has left
[11:10:47] <alexeymelnikov> We go with S2
[11:11:42] <alexeymelnikov> People who generate events with DTEND before DTSTART should be punished
[11:12:16] <csch> Interaction with the famous remote-strangulation-protocol required here? :-)
[11:13:08] <alexeymelnikov> Issue 79 (the DTSTART is always an onset date-time of an observance)
[11:14:49] <alexeymelnikov> Why DSTART is always duplicated in RDATE? To work around the limitation on have a single one subcomponent
[11:16:12] <bdesruisseaux> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue79
[11:17:31] <cyrus_daboo> No objection from me.
[11:17:43] <alexeymelnikov> Proposal: DTSTART always specify an onset
[11:18:05] <alexeymelnikov> + Remove the restriction to have only one component
[11:18:12] <alexeymelnikov> No objection to the change
[11:18:38] --- frank has joined
[11:18:45] <cyrus_daboo> I am still on the fence with RDATE < DTSTART.
[11:18:58] <cyrus_daboo> I think it wasn't completely closed.
[11:19:13] --- resnick has joined
[11:21:18] --- resnick has left
[11:21:22] --- resnick has joined
[11:21:51] <alexeymelnikov> Eliot: issue not in the tracker: update Security Considerations section
[11:22:00] <cyrus_daboo> iTIP is a much bigger problem wrt security than iCalendar
[11:22:09] --- frank has left
[11:22:39] <alexeymelnikov> Bernard: need some text on Internationalization
[11:22:57] <alexeymelnikov> Patrik?
[11:23:09] <alexeymelnikov> He got volunteered
[11:23:20] <cyrus_daboo> We recognize that we are not going to attempt to fix any deficiencies in i18N, right?
[11:23:51] <cyrus_daboo> SEQUENCE -> iTIP - yes.
[11:24:20] <bdesruisseaux> Cyrus: You want to talk about VLOCALIZE ?
[11:25:04] <cyrus_daboo> A brief mention of that and VAVAILABILITY would be worthwhile to remind folks that these extensions exist
[11:25:15] <alexeymelnikov> Eliot: Make DTSTAMP optional in iCalendar, iTIP will make it mandatory
[11:26:20] <alexeymelnikov> Bernard: change semantics of DTSTAMP for scheduling, so that it would mean something
[11:27:35] <alexeymelnikov> Jonathan: want to reopen a closed issue
[11:27:43] <bdesruisseaux> Correction: Bernard will keep semantic of DTSTAMP for scheduling... and define a new semantic outside the scope of scheduling
[11:27:58] --- patrik@frobbit.se has joined
[11:29:19] <alexeymelnikov> Bernard: description of some properties is missing
[11:30:05] <alexeymelnikov> Moving on to iTIP
[11:30:22] <alexeymelnikov> No slides for iTIP
[11:31:46] <alexeymelnikov> Eliot: 2 known issues: IANA consideration, description of SEQUENCE processing
[11:33:03] <cyrus_daboo> Issue1: DURATION in VREEBUSY
[11:33:19] <cyrus_daboo> Allowed in 2445 but not defined in 2446
[11:33:59] <cyrus_daboo> I think it is useful to have the DURATION.
[11:34:11] <cyrus_daboo> The question is whether existing products will know what to do with it.
[11:37:30] <alexeymelnikov> Bernard: does anybody know of an application sending VFREEBUSY now?
[11:40:16] <alexeymelnikov> Cyrus: Which methods to keep in the iTIP
[11:40:45] <alexeymelnikov> PUBLISH - want to keep
[11:41:06] <alexeymelnikov> REQUEST, REPLY - keep
[11:41:32] <alexeymelnikov> ADD and CANCEL - keep both, but clarify behaviour
[11:41:47] <alexeymelnikov> Bernard: the most complicated feature of iTIP
[11:42:23] <alexeymelnikov> Bernard: CANCEL is to cancel an instance? Can this be done by sending the updated request?
[11:43:05] <alexeymelnikov> Eliot: (personal opinion) CANCEL is deployed, removing it might be too disruptive
[11:43:23] --- nsb has left
[11:43:27] <alexeymelnikov> Cyrus: the issue with both is recurrent events
[11:43:57] <alexeymelnikov> More complex example - removing one attendee from one instance
[11:44:10] <alexeymelnikov> Recurrence handling in iTIP is problematic
[11:44:49] <alexeymelnikov> REFRESH is the easy one and should be kept
[11:45:43] <alexeymelnikov> Suggest to remove COUNTER, DECLINECOUNTER
[11:45:50] --- kdz has joined
[11:46:10] <alexeymelnikov> But some people have said that they use them in production
[11:51:16] <cyrus_daboo> Thanks Ted.
[11:51:31] <cyrus_daboo> But you did not use a British accent :-)
[11:52:47] <resnick> Being a tourist here: What is/are the i18n issue(s)?
[11:53:16] <patrik@frobbit.se> I also want to know :-) as I am to write clarification text :-) :-)
[11:53:25] <patrik@frobbit.se> I.e. I will check with people, so you and I can sync later Pete
[11:53:46] <cyrus_daboo> Well - iCal requires use of utf-8 by default, so charsets are not much of a problem. Language tags on the other hand are an issue.
[11:53:47] <resnick> If they're easy enough, I'll help. If they're hard, I let you do them Patrik. ;-)
[11:53:52] --- kdz has left
[11:53:58] <cyrus_daboo> How do we do multi-lingual components.
[11:54:26] <cyrus_daboo> I am ok with that timetable.
[11:55:32] <cyrus_daboo> I don't think iMIP requires all that much work...
[11:55:52] <resnick> So, Cyrus: You're thinking of event descriptions with multiple languages?
[11:56:56] <csch> Good idea - that's certainly think of very realistic scenarios for this!
[11:57:00] <patrik@frobbit.se> Or issues like right to left scripts etc...
[11:57:09] <cyrus_daboo> Yes Pete - there has been discussion of this in Calconnect with various proposals put forward on dealing with it. Its a really big issue for event publishing services, but it is complex because there are several steps involved - authoring, publishing, retrieval - each of which may have slightly different requirements.
[11:57:30] <resnick> Hmmmm......
[11:57:37] <patrik@frobbit.se> Are the issues summarized somewhere?
[11:57:42] <cyrus_daboo> I think we need to punt on this issue in 2445bis and do multi-lingual components as an extension. i.e. I hope IESG does not push back on that for 2445bis.
[11:57:43] --- mtcarrasco has left
[11:57:46] <patrik@frobbit.se> I could not find it on the issue tracker.
[11:57:49] --- r.szabo has joined
[11:58:06] --- apn has left
[11:58:07] <resnick> Maybe I'll invite Patrik to come over here to my machine and we'll video conference with you for a moment.
[11:58:11] <patrik@frobbit.se> Multilingual is for me worse than "just" a charset/script issue.
[11:58:16] <patrik@frobbit.se> ok
[11:58:27] <cyrus_daboo> Ok
[11:58:40] --- csch has left
[11:59:08] --- alexis has left
[11:59:18] --- patrik@frobbit.se has left
[11:59:26] --- r.szabo has left
[11:59:32] --- barryleiba has left
[11:59:32] --- barryleiba has joined
[11:59:33] <cyrus_daboo> BTW By multi-lingual I really mean multi-0lingual variants of the same component - so that people can retrieve an event description in their own language.
[12:00:24] <resnick> Declined me?
[12:00:29] --- afh@jabber.netzwert.ag has left
[12:00:31] <cyrus_daboo> Trying from my end.
[12:00:40] <resnick> k
[12:00:55] <cyrus_daboo> I think there is a firewall issue.
[12:03:32] --- bdesruisseaux has left
[12:03:35] --- barryleiba has left
[12:04:26] --- alexeymelnikov has left
[12:19:15] --- resnick has left
[12:22:16] --- frank has joined
[12:22:38] --- cyrus_daboo has left
[12:24:08] --- frank has left