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