[12:22:58] --- JMcA has left: Logged out
[12:23:12] --- JMcA has joined
[14:40:02] --- JMcA has left
[19:50:35] --- bernard.desruisseaux has joined
[19:51:25] --- hardie@qualcomm.com has joined
[19:51:35] --- jonathanclark has joined
[19:51:39] --- utashiro has joined
[19:51:49] --- cyrus_daboo has joined
[19:52:28] <hardie@qualcomm.com> Lisa changes roles
[19:52:38] <hardie@qualcomm.com> And starts cracking the whip at her chair
[19:52:42] --- rlbob has joined
[19:52:44] --- ray_atarashi has joined
[19:53:07] <rlbob> lisa: stepping down as chair to become advising AD
[19:53:22] <rlbob> lisa: work going too slow, too little progress since last IETF
[19:53:30] <rlbob> lisa: soliciting draft editors
[19:54:15] <rlbob> cyrus reviews some issues
[19:54:19] --- nsb has joined
[19:54:42] <rlbob> cyrus: driving force was simplification of iCal
[19:55:01] <rlbob> as partial solution to interop problems
[19:55:20] --- aki has joined
[19:55:20] <rlbob> much interop experience has been gained recently
[19:56:01] <rlbob> observation is that removing things isn't so useful; rather fixing brokenness is more useful
[19:56:24] <rlbob> do others agree?
[19:57:04] <rlbob> ted hardie: still seems like simplification is in order
[19:57:13] <rlbob> to reduce complexity
[19:57:43] <rlbob> cyrus: more interop problems are around dynamic, ie scheduling, rather than static
[19:57:46] <rlbob> th: yes
[19:58:03] <rlbob> nathaniel: point also is to get on standards track
[19:58:14] <rlbob> hence remove things that aren't used
[19:59:25] <rlbob> cyrus: proposal is to put less-used things in separate docs
[19:59:50] <rlbob> chris newman: don't support splitting, would like to remove stuff like vtimezone to improve interop
[20:00:04] <rlbob> cyrus: have to replace vtimezone with something ...
[20:00:49] --- bernard.desruisseaux has left
[20:00:50] <rlbob> cn: root of problem is that products use existing platform tz infra, vtimezone doesn't fit
[20:01:01] --- bernard.desruisseaux has joined
[20:01:12] <rlbob> cn: can revive timezone registry proposal if needed
[20:01:24] --- randy has joined
[20:02:23] <rlbob> eliot lear: don't want to destabilize existing impls, might want to treat ical with kidgloves since it's so widely used
[20:03:47] <rlbob> chair: might want to create new milestone for submitting new Proposed Std, move Draft milestone further out
[20:04:19] <rlbob> (chair is Aki, sorry)
[20:04:34] <rlbob> bernard D on 2445 issues
[20:05:00] <rlbob> bd: clarify that only charsets are UTF8 and US ASCII
[20:05:28] --- Eliot.Lear has joined
[20:05:32] <rlbob> non-us-ascii would use UTF8 production rules
[20:06:31] <rlbob> bd: clarify how to handle method param for ical object sequence
[20:06:43] <rlbob> bd: components should have "iana-prop" value
[20:07:40] <rlbob> clarify semantics of percent-complete outside of iTip ...
[20:08:15] <rlbob> bd: maybe not specify incrementing of Sequence value
[20:08:45] <rlbob> delegated-from and -to properties require mailto URI, too restrictive
[20:09:48] <rlbob> ted: surely only some URI schemes make sense, better to have a restricted list
[20:10:12] <rlbob> lisa: maybe make it multi-valued also?
[20:10:41] <rlbob> bd: backward compatibility not an issue ...
[20:10:58] <rlbob> cyrus: can have silly URI values even with useful schemes
[20:12:21] <rlbob> cyrus: so list might be mailto:, ldap:, http:, sip: ?
[20:13:03] <rlbob> bd: in cal consortium talking about new "calendar user" URI, if that happens could it be used?
[20:13:41] <rlbob> eliot: does this imply that impls will have to map these other URIs to email addrs?
[20:14:27] <rlbob> bd: don't think so, these would have to be handled for many purposes, eg server discovery
[20:15:20] <rlbob> ted: "im:" uri scheme is protocol-independent, for finding out which protocol is used
[20:15:38] <rlbob> ted: but probably simpler to base URI scheme off the server-server protocol
[20:16:58] --- cyrus_daboo has left: Replaced by new connection
[20:18:11] <rlbob> bd: ABNF broken on some components, says optional but really required per text
[20:18:14] <hardie@qualcomm.com> Actually, what I meant was that it was probably easier to base the server discovery mechanism off the server-to-server protocol
[20:18:44] --- utashiro has left
[20:19:04] <rlbob> bd: valarm processing not well-handled
[20:19:30] <rlbob> should have new property to preserve state info
[20:20:00] <rlbob> bd: valarm action:procedure has poor interop, security issues, should deprecate
[20:20:19] <rlbob> (hum taken, much humming agrees with deprecation)
[20:20:55] <rlbob> bd: clarify how to specify name of inline attachment
[20:21:30] <rlbob> use "name" param on content-type header?
[20:21:44] <rlbob> cn: this has been deprecated since RFC 1521
[20:22:21] <rlbob> cn: can't have content-type param that spans multiple content types
[20:22:31] <rlbob> cn: use content-disposition instead
[20:22:52] <rlbob> nathaniel: this would be compatible with email
[20:24:01] <rlbob> cyrus: need "display-disposition" param? as well as filename?
[20:24:25] <rlbob> nb: content-disposition gets you all for free
[20:25:03] <rlbob> aki: seems like content-disp is overkill if you just want filename
[20:25:16] <rlbob> aki: is there backward-compat issue?
[20:25:18] --- Eliot.Lear has left
[20:25:30] <rlbob> bd: can add new x-params ...
[20:26:06] <rlbob> lisa: use case for inline display of logos and such in invitations
[20:26:59] <rlbob> eliot: yes, this case is important, since some cal systems use these
[20:27:30] <rlbob> bd: sounds like just param for filename is all that's needed
[20:28:04] --- Eliot.Lear has joined
[20:28:34] <rlbob> bd: not possible to handle double-quotes in param value, eg RL "Bob"
[20:29:18] <rlbob> bd: could propose backslash-escaping, could be compat problem
[20:29:38] <rlbob> cn: IMAP made this change going from -2 to -4 ...
[20:30:06] <rlbob> bd: clarify vfreebusy use to block time
[20:30:24] <rlbob> clarify dtend use ...
[20:30:49] <rlbob> aki: bernard, please make proposals to list on handling
[20:30:58] <rlbob> cyrus: 2446 issues
[20:31:10] --- Eliot.Lear has left
[20:31:51] <rlbob> change tables to list only exceptions to 2445 rules, or make tables complete? propose making complete
[20:32:44] <rlbob> cyrus: allow refresh of published event? publish doesn't expect response, can ask for refresh?
[20:32:58] --- Eliot.Lear has joined
[20:33:35] <rlbob> cyrus: concept of forwarding unclear in general iTip case
[20:34:10] <rlbob> permit forwarding op to include additional data? is this iTip or iTip profile?
[20:35:02] <rlbob> bd: issue is can someone add comment when forwarding, identify who added which comment?
[20:35:36] <rlbob> cyrus: sequence change rules changes ...
[20:36:35] <rlbob> create table of props and indicate which changes must/should/may result in sequence change?
[20:36:50] --- Eliot.Lear has left
[20:38:12] <rlbob> rohan: can't say how to process things automatically that require judgement ...
[20:39:01] <rlbob> eliot: changed seq number when IETF agenda changed ... but did impls do anything with it?
[20:39:19] <rlbob> eliot: sounds like UI issue
[20:39:57] <rlbob> ted: sounds like another property is needed to indicate major/minor change from point of view of organizer
[20:40:50] <rlbob> ted: or make explicit a "need to re-accept" indication
[20:41:10] <rlbob> ted: then seq num can change on every change of any kind
[20:42:00] <rlbob> lisa: would be easy to add UI for organizer to indicate this info
[20:42:48] <rlbob> cyrus: state examples of "right way to do scheduling"?
[20:43:05] <rlbob> aki: how about "scheduling scenarios" doc
[20:43:17] --- JeffMC has joined
[20:43:23] <rlbob> ted: probably not normative, but can have "darn good examples"
[20:43:55] <rlbob> leifj: could use as input to interop reports, ie test scenarios
[20:44:17] <rlbob> alexei melnikov on 2447 status
[20:44:46] <rlbob> am: new rev out, a few issues remain
[20:45:16] <rlbob> am: allow infinite multipart/mixed nesting? interop issue?
[20:45:40] <hardie@qualcomm.com> So, I think you could use them as input to interop reports, but interop reports have a special property: they have to show each *feature* implemented twice by independent code bases. That doesn't usually say much about how they fit together--so they are usually not given a sequence.
[20:45:54] <rlbob> cyrus: certainly clients use nesting now ...
[20:46:06] <rlbob> aki: need to ask this question on the list
[20:46:22] <rlbob> nb: nesting will happen, not handling it is a bug
[20:46:23] <hardie@qualcomm.com> So it might be input, but I doubt you would be able to generate a complete interop report by going through "darn good examples" sections.
[20:46:59] <rlbob> am: add examples of 8bit and QP data
[20:47:10] <rlbob> am: address IANA considerations section
[20:47:27] <rlbob> maybe text should move to iMip ...
[20:48:09] <rlbob> am: sec considerations: require impls to support S/MIME, is anyone doing it?
[20:48:41] <rlbob> cyrus: any email client that can do S/MIME can do it, some can
[20:48:52] <rlbob> aki: can't drop, IESG would have problem
[20:49:34] <hardie@qualcomm.com> tinyurl we need you!
[20:49:35] <rlbob> cyrus: report on recurrence recommendations from CalConnect
[20:49:48] --- jonathanclark has left: Replaced by new connection
[20:50:00] <rlbob> do without multiple rrules and exrules?
[20:50:17] <rlbob> do without exrules altogether?
[20:50:31] --- nsb has left
[20:50:39] <rlbob> remove thisandprior
[20:50:42] <hardie@qualcomm.com> http://tinyurl.com/jeyq8
[20:51:09] <rlbob> Jeff McCullough, report on CC interop event
[20:51:37] <rlbob> interop improving
[20:51:49] <rlbob> scheduling with rrules still problematic
[20:52:08] <rlbob> caldav interop improving also, moving forward
[20:52:35] --- JeffMC has left
[20:52:58] <rlbob> aki: turnout a little disappointing (approx 20), let's get moving on list, see you in Montreal
[20:52:58] --- bernard.desruisseaux has left
[20:53:12] <rlbob> nb: calconnect in May in Boston also
[20:53:17] --- rlbob has left
[20:53:18] <aki> Thanks everyone!
[20:53:35] --- ray_atarashi has left
[20:54:51] --- aki has left
[21:12:09] --- hardie@qualcomm.com has left: Disconnected.