[08:48:11] --- lebb has joined
[08:58:00] --- Aki has joined
[08:59:49] --- pigdog has joined
[09:00:22] --- bernard.desruisseaux has joined
[09:00:45] --- cyrus_daboo has joined
[09:00:52] <pigdog> yep!
[09:00:53] --- hardie@jabber.psg.com has joined
[09:01:09] <hardie@jabber.psg.com> pigdog, you are Eliot?
[09:01:17] <bernard.desruisseaux> Audio stream: http://videolab.uoregon.edu/events/ietf/ietf664.m3u Slides: http://www3.ietf.org/proceedings/06jul/slides/calsify-0.pdf http://www3.ietf.org/proceedings/06jul/slides/calsify-1.ppt http://www3.ietf.org/proceedings/06jul/slides/calsify-2.pdf
[09:01:19] --- patrik has joined
[09:01:28] <pigdog> yes, i'm eliot
[09:01:39] <patrik> Hi eliot!
[09:01:44] <pigdog> hi patrik
[09:02:15] --- JeffMc has joined
[09:03:06] --- rlbob has joined
[09:03:31] <rlbob> i'll be scribing into the chat room ...
[09:03:33] --- alexeymelnikov has joined
[09:03:39] <rlbob> goals and milestones
[09:04:17] <rlbob> seeking completion in Jan 2007, ie submission of PS docs to IESG
[09:04:25] <rlbob> bernard:
[09:04:36] <pigdog> (thanks for jabber scribing, Bob)
[09:04:45] <rlbob> bd: review of RFC2445bis
[09:04:52] <rlbob> draft -01 curent
[09:05:16] <rlbob> html version available with change-tracking
[09:05:41] <rlbob> http://tools.ietf.org/wg/calsify/...
[09:06:00] <rlbob> issues:
[09:06:23] <rlbob> 8 issues today ...
[09:06:50] <rlbob> clarify number of recurrence instances generated by multiple RRULE properties
[09:07:36] <rlbob> [example given]
[09:08:15] <pigdog> please use microphone
[09:08:18] <rlbob> clarifying text will be added
[09:09:05] <rlbob> issue (2): is the first recurrence instance, defined by DTSTART, always excluded by EXRULE?
[09:09:53] <rlbob> counter-intuitive example given ...
[09:10:03] <pigdog> does anyone blindly follow the RFC?
[09:10:21] --- kmurchison has joined
[09:10:40] <rlbob> opinions sought from implementors ...
[09:11:16] <rlbob> cyrus: exrules don't get used that much, there are unexplored edge cases
[09:12:48] <rlbob> cyrus: in this case, exrule does something odd, would make sense to say DTSTART isn't in the set, this could make interop worse, he's on the fence
[09:13:29] <rlbob> bd: could say DTSTART is part of count for ... but not part of count for EXRULE
[09:14:40] <rlbob> bd: [various processing alternatives presented]
[09:16:04] <rlbob> aki: probably need to do this via email
[09:16:32] <rlbob> cd: no idea about how EXRULEs are handled in general, have to ask implementors
[09:16:49] <rlbob> cd: having RRULE and EXRULE be different isn't that bad
[09:17:10] <rlbob> aki: so, bd, you'll send question to list, with example
[09:17:27] <rlbob> bd: should add example of EXRULE use to RFC also
[09:18:24] <rlbob> bd: (3) how shouled BYHOUR, BYMINUTE, BYSECOND rule parts be handled when DTSTART is a DATE value?
[09:19:00] <rlbob> bd: example given, this should be clarified
[09:19:44] <rlbob> bd: recurrence instances would be date value types
[09:19:52] <rlbob> q: why?
[09:20:35] <pigdog> one approach would be to disallow this bizarre combination.
[09:20:35] <rlbob> cyrus: what would TZ be? would be floating, why then not do date-time to begin with
[09:20:48] <pigdog> does anyone do this?
[09:21:39] <rlbob> cyrus: don't see how you can have RRULE by hour when START is all-day event
[09:22:31] <pigdog> MUST NOT generate MUST ignore...
[09:23:00] <rlbob> cyrus: no way to have error in ical, so processing is ignore and carry on?
[09:23:14] <rlbob> bd: example could be worse ...
[09:23:22] <pigdog> i'd ignore the whole VEVENT or print a diagnostic.
[09:24:23] <rlbob> bd: OK with "ignore" idea
[09:24:35] <rlbob> aki: so we have consensus on this, will confirm on list
[09:25:12] <alexeymelnikov> clarification: ignore the whole VEVENT, not just RRULE
[09:25:19] <rlbob> bd: (4) 4.3.10 on UNTIL rule ... should clarify whether UNTIL can define a DATE value
[09:25:42] <rlbob> bd: should clarify whther UNTIL must ahve the same value type as DTSTART
[09:26:19] <pigdog> that sounds perfectly reasonable.
[09:27:05] <rlbob> bd: propose that value type of UNTIL must match
[09:27:39] <pigdog> agree
[09:27:46] <rlbob> bd: does it also have to match local-time-ness of DTSTART?
[09:28:00] --- bernard.desruisseaux has left
[09:28:15] --- bernard.desruisseaux has joined
[09:28:17] <rlbob> cyrus: could produce inconsistent results in different tzs
[09:28:24] <pigdog> !!
[09:28:48] <rlbob> cyrus: propose that it always be UTC
[09:28:53] --- alexeymelnikov has left: Replaced by new connection
[09:29:04] <rlbob> cyrus: or maybe needs more thought ...
[09:29:12] --- Thomas Roessler has joined
[09:30:03] <rlbob> aki: so two issues ...
[09:30:13] <JeffMc> Haven't we already agreed that recurrence rules should not be local time, not UTC?
[09:31:01] <pigdog> jeffmc930: too many nots there. resend?
[09:31:14] <rlbob> bd: (5) 4.8.5.4 rrule: should clarify that it doesn't matter whether DTEND or DURATION were used in ical object. what matters is the "duration" of the first recurrence instance
[09:32:08] <rlbob> bd: can be a problem with tz changes, is duration more important, or end time?
[09:32:10] <JeffMc> You're right. Haven't we already agreed that recurrence rules should be in local time, not UTC?
[09:32:42] <rlbob> bd: presumably not many events span tz changes
[09:32:48] <pigdog> yes. the only case where things get weird, IMHO is when you use a DATE and not a DATE-TIME
[09:33:34] --- ray_atarashi has joined
[09:34:12] <rlbob> cyrus: airline flight example, duration is fixed, work-shift example, end-hour may be fixed
[09:35:02] <rlbob> bd: is shift example relevant? people don't book their workdays in calendar
[09:35:24] <rlbob> patrik: needs to be clear in spec which wins
[09:36:22] <patrik> ping
[09:36:22] --- Thomas Roessler has left: Lost connection
[09:36:22] --- kmurchison has left: Lost connection
[09:36:22] --- ray_atarashi has left: Lost connection
[09:36:22] --- Aki has left: Lost connection
[09:36:22] --- cyrus_daboo has left: Lost connection
[09:36:22] --- lebb has left: Lost connection
[09:36:22] --- rlbob has left: Lost connection
[09:36:25] <pigdog> ack
[09:36:35] --- Lisa has joined
[09:36:39] <patrik> It seems some people lost network connectivity here
[09:36:48] <Lisa> I just forgot about jabber :)
[09:36:51] <pigdog> there was a blip, i think
[09:37:02] <pigdog> audio stopped for a moment, but seems to be working now
[09:37:03] <patrik> Yup
[09:37:11] <pigdog> or was... things just got quiet
[09:37:17] <hardie@jabber.psg.com> both, maybe
[09:37:21] <hardie@jabber.psg.com> no one is at the mic
[09:37:31] <pigdog> ok, now i hear stuff
[09:40:30] <pigdog> sense of the room?
[09:44:20] --- cyrus_daboo has joined
[09:44:53] --- Aki has joined
[09:45:15] --- ray_atarashi has joined
[09:49:26] --- alexeymelnikov has joined
[09:56:05] <pigdog> that makes sense.
[09:56:19] <pigdog> (agree with cyrus)
[09:56:25] <pigdog> lisa?
[09:56:28] --- rlbob has joined
[09:56:39] <Lisa> I can imagine doing all kinds of innovative use cases working around that restriction, so sure.
[09:56:46] <Lisa> (My comment was speaking as an individual, btw)
[09:56:50] <rlbob> patrik: this is why calendar clients suck simon: agree with proposal, question for others, how would DTEND ... cyrus: when you generate set of instances, start with start date, could do same with end cyrus: just put note in spec saying that client implementors should warn users when creating events that cross tz changes simon: can't expand DTEND, have to use duration of first occurrence cyrus: propose leaving text as is, with warning note aki: so cyrus will write that text and work with bd and get to list? cyrus: jeffmc points out that spec says that RRULES have to be in floating time, so only one issue in (4) bd: (6) 4.8.5.4 rule, should clarify whether RDATE is required even when the recurrence instance is redefined in separate component bd: surprised by "MUST" in current spec, should be sufficient to have separate component, shouldn't require RDATE property cyrus: thinking from IETF perspective, this proposal makes things simpler, so agree aki: so seems to be agreement on this bd: (7) clarify whether DTSTART is required in VTODO and VJ components when the RRULE or EXRULE properties are defined in those components cyrus: proposal given ... VTODOs have due dates usually, not START, so don't require? bd: can client just add DTSTART even though user didn't specify? cyrus: depends on how client use DTSTART lisa d: can't work out this model in this room, people doing clever things with VTODOs and VJOURNALs, eg Chandler personal todo lists behave differently than tracker systems may have to wait a couple of years to get behavior aki: so proposing that recurrence works same in VTODO as VEVENT? bd: recurrence defined independent of component type ... but VTODOs don't have to have these elements cyrus: can live with having to have START, but not to default to DUE
[09:56:53] <pigdog> i understand
[09:57:07] <rlbob> [catching up with notes taken while offline]
[09:57:41] <rlbob> bd: (8) CAL-ADDRESS value type should be redefined to restrict the URI schemes allowed
[09:58:06] <rlbob> eg mailto, http, ldap, xmpp
[09:58:30] <rlbob> leifj: is it a way to reach somebody, or identifier of participant?
[09:58:40] <rlbob> bd: identifier
[09:59:21] <rlbob> leifj: reachable is more problematic
[09:59:52] <rlbob> bd: should define new URI scheme, eg "scheduledto"?
[10:00:55] <rlbob> thomas: if it's identifier, any URI can do this
[10:02:05] <rlbob> thomas: wouldn't restrict it, can leave it open, if people put junk in, it won't be useful, but can't know this up front
[10:02:49] <pigdog> TFTP?!
[10:03:54] <Lisa> How about ISBN URIs in CalAddress? :)
[10:04:24] <rlbob> ted h: often ask doc authors about odd URI schemes, if just identifier than any OK, if it's reachability then have to restrict, recommend splitting into two URIs?
[10:05:01] <rlbob> ted h: if reachability, pick mandatory-to-implement, say that others can be added later, but bear burden of definition
[10:05:50] <rlbob> aki: this is proposing multi-valued CAL-ADDRESS ...
[10:05:53] <pigdog> the current URI Value Definition (3.3.13) needs a better reference for URIs.
[10:06:46] <pigdog> microphone?
[10:07:45] <rlbob> bd: new URI scheme was discussed at calconnect ... cyrus will discuss in his slides
[10:08:05] <rlbob> new slide set: cyrus, 2446bis
[10:08:14] <rlbob> current version is -02
[10:08:58] <rlbob> c: major changes were fixes to component/property tables
[10:09:28] <rlbob> c: problems with itip mostly come from recurrence
[10:09:37] <rlbob> so more changes coming related to that
[10:11:08] <rlbob> c: (1) in CANCEL method, option (b) says multiple recurrence-ids can be sent, but 2445 says only one
[10:11:30] <rlbob> c: propose to remove option (b) text
[10:11:34] <rlbob> bd: agree
[10:12:21] <rlbob> c: (2) COMMENT property can be added to REPLY, but no way to tell that apart from COMMENTs sent in request
[10:12:54] --- tlr@w3.org has joined
[10:13:36] <rlbob> c: itip allows REPLY to send whole request back, with appt mods, or just "relevant" parts, some client interop problems
[10:14:11] <pigdog> i think you want two parameters: originator and date
[10:14:25] <pigdog> (really date-time)
[10:14:42] <rlbob> bd: could add or reuse SENT-BY, from organizer
[10:15:24] <rlbob> c: no way to include per-attendee properties/values
[10:15:44] <rlbob> lisa d: hmm, sounds like conversations/threads inside event ...
[10:15:51] <Lisa> I'm sure Chandler could use it, though.
[10:16:12] <rlbob> aki: could have many comments from each user
[10:16:34] <pigdog> if you turn this stuff inside out and add a comment to the attendee property, that sounds like quite a reworking.
[10:16:38] <rlbob> c: might want to show just last comment to user
[10:16:46] <Lisa> It's an interesting general problem, in fact email has the same problem with quoting of previous messages. Could there be a general format for a conversation, simple enough to embed in mail and events?
[10:17:11] <pigdog> well one or more conversations
[10:17:37] <Lisa> yep
[10:17:37] <rlbob> c: 2445 says only one COMMENT param, would have to relax
[10:17:49] <pigdog> should this be done with existing COMMENT or with a new COMMENT?
[10:17:58] <pigdog> or is this the thing that requires us to bump our version field?
[10:18:22] <rlbob> c: (3) most impls discard VALARMs sent via itip, so why are they allowed?
[10:18:56] <pigdog> this is done already. why DISALLOW it?
[10:19:09] <pigdog> how does this impact interoperability to change this?
[10:19:38] <pigdog> i personally have set VALARMs for various differing events that i wanted to apply to my attendees
[10:19:50] <pigdog> that's not to say that they couldn't override them.
[10:20:38] <rlbob> c: could lead to user confusion, helps make things simpler
[10:21:08] <pigdog> i could imagine a client that actually preferred receiving some people's alarms and not others'
[10:21:23] <rlbob> aki: some useful cases, if users can override is this OK?
[10:21:56] <pigdog> agree with cyrus' last comment- add a note in security considerations
[10:22:02] <rlbob> c: maybe just warn clients that care should be taken when receiving ALARMs
[10:22:31] <rlbob> c: (4) no version number for iTIP, is one needed?
[10:23:06] <rlbob> alexei m: are there incompatible changes?
[10:23:42] <rlbob> c: changes so far are backwards compatible, probably
[10:24:18] <rlbob> c: but might be changes, so should we anticipate?
[10:24:45] <rlbob> lisa: should support clients advertising which versions of iCal they support
[10:24:55] --- hantula@jabber.org has joined
[10:25:53] <rlbob> bd: hard to tell difference between sending invite and forwarding one as fyi
[10:27:40] <rlbob> bd: implies difference between organizer and sender, maybe new verb in iTIP to represent this
[10:27:57] <rlbob> bd: so this might imply new version
[10:29:21] <rlbob> c: new verbs is alternative to version number
[10:29:41] <pigdog> the other option is to bump iMIP version numbers, but i don't think that's a great idea.
[10:29:58] <rlbob> alexei: version would help if wanted to change meaning of existing verb
[10:30:06] <pigdog> i would do both- use new verbs for now and add a new version for future use
[10:30:47] <rlbob> c: so maybe no version number needed?
[10:31:24] <rlbob> bd: any support for adding new verb for forwarding case?
[10:33:46] <rlbob> [discussion of forwarding case]
[10:35:29] <rlbob> how does organizer know that forwarded-to person has been "legitimately" invited, "party-crasher" case in spec
[10:35:50] <rlbob> (cyrus asks)
[10:36:24] <rlbob> c: call out two distinct cases, forward as invite, and forward as fyi
[10:36:45] <rlbob> c: should do via organizer
[10:37:28] <rlbob> ted: organizer could grant right to invitees to forward
[10:37:45] <rlbob> c: there's no access control in iTIP ...
[10:38:27] <rlbob> ted: lots of human behavior built around current forwarding
[10:39:25] <rlbob> ted: adding new "non-actionable" forward implies some way to retain current behavior
[10:39:44] <rlbob> c: delegation already covered by existing properties
[10:40:05] <rlbob> ted: this is downgrade from delegation
[10:40:43] <rlbob> ted: worry about protocol mech changes that imply user behavior changes
[10:41:23] <rlbob> simon: isn't this very appl-dependent? sometimes organizer would want unsolicited accepts?
[10:41:28] --- Nacho.Mas has joined
[10:42:10] <rlbob> c: maybe need indication on invite that forwarding is OK
[10:42:32] <rlbob> kurt z: someone could still forward
[10:42:33] <Lisa> I like it when Cyrus uses words like "irrespective". So proper and educated.
[10:42:53] <rlbob> rlbob: starting to sound like DRM requirements ...
[10:43:55] <pigdog> rlbob: lol!
[10:43:57] <rlbob> c: itip has "class" indicating confidential etc, but no specified behavior around this
[10:44:27] <rlbob> bd: class is like ALARM ...
[10:46:07] <rlbob> rlbob aside to pigdog: Microsoft has already implemented DRM precisely to prevent unwanted forwarding of email messages (and other stuff, that's a prime exec-appeal use case)
[10:46:33] <rlbob> aki: feedback from ADs?
[10:46:55] <rlbob> alexei: how about doc identifying this as known issue?
[10:47:13] <rlbob> lisa: hmm, dunno
[10:47:18] <pigdog> this chair's reaction would be that we should at LEAST take a shot at those issues here first.
[10:47:52] <pigdog> yes, there will be pushback - from me!
[10:48:12] <rlbob> [discussion of S/MIME role in all this]
[10:48:35] <rlbob> ted: should get security review
[10:49:29] <rlbob> lisa: IESG recently made rec: "message integrity is good" but didn't say how
[10:49:52] <rlbob> aki: will followup with authors, arrange for sec review
[10:51:15] <rlbob> alexei: issue in iMIP regarding multipart-mixed, have to pick one part, maybe some language consideration?
[10:51:20] <Lisa> Not quite RLBob: IESG recently approved (probably without looking too closely) a document that said that "message integrity" would be needed to solve some security considerations, but that documentd didn't even have a reference to any message integrity drafts.
[10:51:38] <Lisa> I think that's much more of an oversight or not bothering than making a statement or recommendation.
[10:52:31] <rlbob> alexei: so should remove text on how to pick one?
[10:52:50] <rlbob> aki: does anyone actually send multipart-alternative?
[10:53:09] <pigdog> yes!
[10:53:23] <pigdog> there is now about a 1 min audio delay
[10:53:41] <rlbob> alexei: so no resolution here, will take to list
[10:54:22] <rlbob> now entering general discussion ...
[10:54:26] <alexeymelnikov> (alexey) Eliot: what kind of multipart/alternatives is being used?
[10:54:43] <pigdog> text/html/ical
[10:54:54] <pigdog> this is standard for Outlook, apparently
[10:54:56] <rlbob> (sorry for misspelling your name, alexey ...)
[10:55:10] <pigdog> great job on the jabbering, bob
[10:55:54] <rlbob> cyrus: discussion of new URI scheme, mailto may force assigning email addresses to schedulable resources like rooms
[10:56:10] <alexeymelnikov> (alexey) Eliot: so no multipart/alternative with *multiple* calendars? Should this just be disallowed?
[10:56:28] <rlbob> so maybe new "scheduleto" URI
[10:57:02] --- ray_atarashi has left
[10:57:03] <rlbob> thomas: why new scheme? why not eg use http URI?
[10:57:34] <rlbob> c: want automated response capability, so resource can get scheduled
[10:58:24] <rlbob> t: don't see how new URI scheme helps with this
[10:59:11] <rlbob> c: caldav is over http, "http" may not be precise enough
[10:59:36] <rlbob> c: scheduleto can solve via magic in SRV lookup, maybe
[11:00:38] <rlbob> t: why another layer of indirection, why not just put the URIs in themselves?
[11:01:53] <rlbob> lisa: URI scheme is blunt instrument, kinda want purpose and scope and such, could annotate existing URIs with more stuff, ala micro-format work
[11:02:43] <pigdog> do we want something like cal.dav:... and cal.mail:... etc?
[11:02:56] <rlbob> t: can type URIs, playing role X in this context
[11:03:01] --- kdz has joined
[11:03:21] <Lisa> It would be really fun to try to expand URI Schemes but I think a lot of people, starting with the W3C (like Thomas who is talking now) might have something to say about it!
[11:03:54] <pigdog> sorry, i thought the . was already allowed
[11:04:11] --- kdz has left
[11:04:19] <rlbob> aki: rohan mahy has draft registering calendar uris in enum ...
[11:05:01] <hardie@jabber.psg.com> the . is allowed. xmlrpc.beep
[11:05:27] <rlbob> aki: would prefer multi-valued
[11:06:11] <rlbob> aki: eg can send iTIP message via SIP to conf bridge, to book it
[11:07:01] <rlbob> leifj: enum sounds like way to add semantics to URIs, Patrik might have opinion
[11:07:31] --- kdz has joined
[11:07:55] <rlbob> c: so, seems to be pushback on new scheme, but still want scheduling service using caldav, so implies caldav: scheme?
[11:08:46] <rlbob> lisa: W3C says scheme is transport, not semantic, so it would be http:, not caldav:
[11:10:18] <rlbob> patrik: this discussion has gone on for a long time between IETF and W3C, with no resolution ...
[11:10:47] <rlbob> patrik: listen to implementors on this
[11:12:32] <rlbob> bd: a scheduling example, how does scheduler know how to schedule "mailto: foo"
[11:12:57] <rlbob> ted: answer in mailto case is obvious, isn't it?
[11:13:33] <pigdog> i think the bigger problem is when looking at free/busy info for Lisa.
[11:14:06] <pigdog> i may know lisa's email address and it's probably the case that her system will handle email. but i'd like to schedule a meeting with her when she's willing to meet.
[11:14:35] <rlbob> bd: but want real-time scheduling, not via email, so mailto: isn't good
[11:15:10] <rlbob> ted: so, she has to give a different identifier to indicate that
[11:15:22] <pigdog> who's at the mike?
[11:15:42] <rlbob> kurt: problem is in semantics of URIs
[11:16:38] <rlbob> cyrus: could obviously automate via email too
[11:17:09] <rlbob> aki: root of problem is bootstrapping, what's on the business card
[11:17:46] <rlbob> bd: no server-server protocol for scheduling now, this implies new scheme when we have one
[11:18:17] <pigdog> why isn't this new s2s protocol caldav?
[11:18:19] <rlbob> bd: so can wait until then?
[11:21:56] <pigdog> what this discussion has shown is that we are arguing absent a concrete proposal
[11:22:01] <Lisa> Pigdog: it might be caldva
[11:22:10] <rlbob> patrik: could use enum on her phone number
[11:22:44] <rlbob> lisa: many fascinating things going on with registering new URI schemes and mime types
[11:23:29] <rlbob> rlbob: look at XRI work, being standardized in OASIS, designed just for this problem, may be loonie fringe ...
[11:24:19] <rlbob> ted: URI reg changes recently based on much uncomfortable experience, now provisional vs permanent registrations
[11:25:05] --- kdz has left
[11:25:09] <rlbob> ted: so don't worry about what everyone else has done, you'll know when you need a new scheme because behavior will be new
[11:26:12] <pigdog> we *have* a shiny new protocol, right?
[11:26:29] <rlbob> ted: (more good advice than I could capture)
[11:27:53] --- hardie@jabber.psg.com has left
[11:27:54] <rlbob> aki: eliot says "concrete proposal needed", second that
[11:27:55] --- hantula@jabber.org has left: Logged out
[11:27:56] <pigdog> thanks again bob!
[11:28:03] <rlbob> aki: adjourned, see you in SD
[11:28:10] <rlbob> my pleasure
[11:28:19] <JeffMc> Thanks for the scribbing Bob.
[11:28:19] <rlbob> keeps me from reading email ...
[11:28:24] <pigdog> hah!
[11:28:32] --- bernard.desruisseaux has left
[11:28:37] --- pigdog has left
[11:28:38] <rlbob> or at least replying to it
[11:28:41] --- rlbob has left
[11:28:53] --- JeffMc has left
[11:28:53] --- Lisa has left: Logged out
[11:29:11] --- alexeymelnikov has left: Replaced by new connection
[11:29:17] --- patrik has left
[11:32:02] --- cyrus_daboo has left
[11:32:29] --- Nacho.Mas has left
[11:33:16] --- kdz has joined
[11:35:28] --- Aki has left
[11:38:31] --- tlr@w3.org has left
[12:12:14] --- kdz has left
[12:17:12] --- kdz has joined
[12:41:04] --- kdz has left
[12:47:34] --- kdz has joined
[12:48:35] --- kdz has left
[13:30:30] --- Aki has joined
[13:30:35] --- Aki has left
[17:15:07] --- LOGGING STARTED