[09:54:41] --- eliot.lear has joined
[10:01:28] --- alexeymelnikov has joined
[10:01:37] <eliot.lear> hello alexey
[10:01:43] <alexeymelnikov> Hi
[10:01:48] <eliot.lear> how goes?
[10:01:48] --- fabio.silva has joined
[10:01:55] <eliot.lear> greetings fabio
[10:01:58] <alexeymelnikov> Busy :-)
[10:02:04] <alexeymelnikov> Yourself?
[10:02:07] <fabio.silva> hi, eliot!
[10:02:27] <eliot.lear> well, our issue tracking system is in pieces on the floor behind me, so we'll be without for this chat ;-)
[10:03:08] <eliot.lear> we're expecting cyrus today but not bernard
[10:04:34] --- cyrus_daboo has joined
[10:04:40] <eliot.lear> greetings cyrus
[10:04:48] <cyrus_daboo> Hi
[10:04:53] <alexeymelnikov> Hi
[10:05:09] <eliot.lear> let's go ahead and get going.
[10:05:11] <eliot.lear> starting with an agenda
[10:05:28] <eliot.lear> today bernard cannot attend, as i mentioned, so we will table 2445bis issues
[10:05:34] <eliot.lear> largely we are waiting on bernard for a new draft
[10:05:55] <eliot.lear> this next draft will be WGLC'd with the exception that we may need to revisit some areas based on itip work
[10:06:17] <eliot.lear> today i've asked cyrus to talk a bit about open issues with itip
[10:06:33] <eliot.lear> the idea is to identify what we need to talk about and get things moving forward for ietf chicago
[10:06:57] <eliot.lear> we know from previous chats that there are several methods that need some work.
[10:07:06] <eliot.lear> with that i'd like to hand things over ti cyrus
[10:07:11] <eliot.lear> s/ti/to/
[10:07:50] <cyrus_daboo> OK, I would actual like to start but taking a higher level view - specifically identifying some key use cases and asking the question of what they would like like in iTIP.
[10:08:07] <eliot.lear> (fine)
[10:08:24] <cyrus_daboo> First: these use cases all revolve around recurring meetings. For the most part one-off meetings are easy to deal with.
[10:08:53] <cyrus_daboo> So consider a weekly meeting set to occur 20 times, with several attendees initially set up.
[10:09:24] <cyrus_daboo> First issue: how would the organizer cancel the last ten meetings?
[10:09:41] <eliot.lear> update?
[10:10:13] --- Aki has joined
[10:10:28] <fabio.silva> I'd think on cancel with recur-id...
[10:10:32] <cyrus_daboo> In the spec it suggests that multiple instances can be cancelled either using the RANGE= parameter (which we have removed from 2445bis) or by sending multiple RECURRENCE-IDs. The multiple R-IDs solution is just about OK in this case as we have ten to cancel.
[10:10:33] <Aki> Sorry; got tied up...
[10:10:56] <eliot.lear> ok
[10:11:20] <cyrus_daboo> So what were to happen if this were an unbounded recurring event? You can't send multiple R-IDs...
[10:12:18] <cyrus_daboo> Seems to me that we DO need a RANGE= parameter for that case.
[10:12:41] <alexeymelnikov> This sound convincing
[10:13:18] <eliot.lear> now to be clear, the use case you are handling is one where you are canceling all future events past a certain date?
[10:13:19] <cyrus_daboo> The only other alternative would be for the organizer to send out the entire request set again, but with it truncated to the now finite set of instances.
[10:13:41] <eliot.lear> (ok that answered my question)
[10:13:56] <fabio.silva> an update then...
[10:14:27] <cyrus_daboo> Use cancel all from time X going forward. One might also want cancel all from X going backward, but I think that is much rarer - so RANGE=THISANDPRIOR can stay out of 2445bis, but THISANDFUTUR may be needed.
[10:14:58] <cyrus_daboo> It could be we limit its use to ONLY MTHOD:CANCEL iTIP operations though.
[10:15:12] <cyrus_daboo> However, lets consider a second use case:
[10:16:04] <cyrus_daboo> Again a recurring meeting. This time I want to add an attendee to the third and subsequent instances. Again what to do?
[10:17:24] <cyrus_daboo> The ugly option is to send out a new REQUEST with overridden components for each of the 3rd, 4th, 5th etc instances. That would result in a very large data set as each instance has to be a complete event description.
[10:18:22] <eliot.lear> what's your proposal?
[10:18:28] <cyrus_daboo> The more compact option is to RANGE=THISANDFUTURE. But with that we run into the problem that led us to remove it - how to deal with multiple THISANDFUTURE parameters in the presence of multiple overrides.
[10:19:08] <cyrus_daboo> I am tempted to say that we need to bring back THISANDFUTURE but be very explicit about how it works across multiple instances.
[10:20:45] <eliot.lear> would i be correct in saying that a VEVENT is best considered in OO land as a class and then you have instances of that class? In which case your data set would be limited to diffs off of what you inhereted?
[10:20:52] <cyrus_daboo> (I am also assuming that we don't want to start inventing new protocol here - but if we did want to do that then some form of "incremental" change mechanism could be done that would make this work better).
[10:21:50] <cyrus_daboo> No - an overridden instance has to be a complete VEVENT object - i.e. it cannot "inherit" the SUMMARY of the master component - it has to have its own SUMMARY, even if the value is exactly the same as the master.
[10:22:19] <eliot.lear> i guess i'm not thinking about on-the-wire per-se
[10:22:41] <cyrus_daboo> The "incremental" things I was dreaming about would be more akin to OO inheritance.
[10:22:49] <eliot.lear> but if you say that it is pragmatically difficult to keep the dataset small i'll believe you.
[10:23:12] <eliot.lear> so, perhaps we can explore your dream a bit?
[10:23:14] <eliot.lear> ;-)
[10:23:42] <cyrus_daboo> Do I need to lie down on the couch and tell all :-)
[10:24:04] <fabio.silva> do you foresee any issues with such "inheritance" mechanism?
[10:24:39] <cyrus_daboo> I really think the handling of recurrence overrides like this needs some discussion at the meeting - face-to-face - plus we need input from MS & IBM folks to properly explain how they deal with it.
[10:25:00] <cyrus_daboo> The issue with anything new is it will not interoperate with existing clients.
[10:26:02] <eliot.lear> i think that's okay if we do a version bump & if we can use something in iMIP like multipart/alternative to provide something that would approximate the same behavior in earlier clients
[10:26:19] <eliot.lear> but it has to be worth it, obviously
[10:26:26] <eliot.lear> and that would be something for the wg to discuss
[10:26:46] <fabio.silva> I see
[10:26:59] <eliot.lear> bumping the version is a big deal
[10:27:56] <eliot.lear> ok, so cyrus, i will do my best to summarize this portion and post something to the list, and you'll present at IETF on the matter?
[10:28:08] <eliot.lear> also, let's all poke our microsoft and ibm friends to participate?
[10:28:17] <cyrus_daboo> Yes. We will need a lot of time to discuss this one and all the variants of it.
[10:28:30] <eliot.lear> ok. nearly the entire meeting is for itip
[10:28:45] <eliot.lear> do you have a next issue you'd like to raise now/
[10:28:46] <eliot.lear> ?
[10:28:56] <eliot.lear> actually
[10:28:59] <eliot.lear> before you go on
[10:29:24] <eliot.lear> if you have something more concrete for ietf by way of proposals, I think that would make the conversation go better ;-)
[10:29:58] <eliot.lear> i can see that the few folks on this chat agree in principle, but we don't fully understand the ramifications without something more flushed out. or at least i don't
[10:30:12] <eliot.lear> does that seem reasonable?
[10:31:23] <cyrus_daboo> Ok - let me just point out the other "big" issue (again I do not have a concrete proposal for that yet). This one is "when to update the SEQUENCE".
[10:31:31] <alexeymelnikov> Yes, it would be nice to see more details before the meeting
[10:32:23] <cyrus_daboo> What I plan to do is post the use case to the list before hand and ask for comments on how people currently do it or how they think it should be handled with the current spec.
[10:33:16] <eliot.lear> ok, if you would like to do that, it would be fine. otherwise, what we can do is refer people to this conversation and ask for specific comments.
[10:33:46] <eliot.lear> but i still think it would be helpful to have a proposal out there, even if we later decide not to use it. it would help crystalize peoples' thinking
[10:34:18] <cyrus_daboo> OK, maybe I can come up with a proposal for using THISANDFUTURE in a well-defined way.
[10:34:51] <eliot.lear> that would be helpful. but also if there is more than just some dreaming about OO that helps keep the dataset small, perhaps that's worth at least an email message
[10:34:52] <alexeymelnikov> Eliot: +1
[10:35:25] <eliot.lear> (even if it requires a flame retardant kbd)
[10:35:54] <fabio.silva> I agree
[10:36:35] <eliot.lear> now as we are all jumping on the "Cyrus do more work" bandwagon, i do want to recognize that this could be a lot of work
[10:37:08] <eliot.lear> to that end, if others want to help, now is a good time to volunteer...
[10:37:40] <eliot.lear> (if only bernard were here ;-)
[10:37:52] <Aki> if this becomes a multi-person effort, then I'd suggest writing an I-D
[10:37:56] <eliot.lear> ok, let's move on for now. SEQUENCE bumping?
[10:38:56] <cyrus_daboo> BTW it is interesting to note that there is no rfc errata for 2446 even though there are a lot for 2445. I think that says a lot about how much implementation has taken place (i.e. not that much and in most cases there was "private" aggreement on how to achieve interop - MS & IBM testing with each other only).
[10:39:44] <eliot.lear> true
[10:40:25] <cyrus_daboo> I propose that the new spec be very explicit about when SEQUENCE number should be changed. That would be done via a table that lists each method and component in sepecrate colums, with another column that describes what change would cause SEQUENCE to bump.
[10:41:03] <eliot.lear> what would be the possible values? Yes, no, maybe?
[10:41:07] <cyrus_daboo> Note that we also need to add a statement about the fact that at the end of the day, it is really up to the clients to figure out whether a significant change to an invite has occurred.
[10:41:22] <eliot.lear> i think that's in 2445bis
[10:41:39] <eliot.lear> quoting:
[10:41:40] <eliot.lear> In addition, changes made by the "Organizer" to other properties can also force the sequence number to be incremented. The "Organizer" CUA MUST increment the sequence number whenever it makes changes to properties in the calendar component that the "Organizer" deems will jeopardize the validity of the participation status of the "Attendees".
[10:41:41] <fabio.silva> but doesn't it depend on itip events?
[10:42:00] <cyrus_daboo> e.g. the organizer might not think that changing the location is a big deal and not bump sequence, but an attendee may not be able to physically get to the new location.
[10:42:50] <cyrus_daboo> But how can an Organizer know enough about Attendees to know when that should happen?
[10:42:53] <eliot.lear> in most implementations i've used, the SEQUENCE is bumped on location
[10:43:40] <cyrus_daboo> Ok - then lets be explicit and say SEQUENCE MUST be bumped when LOCATION changes - but that change has to be more than fixing a typo in the original value....
[10:43:40] <eliot.lear> this comes across in some CUAs as "notify attendees of the change?"
[10:43:45] <fabio.silva> we can explicitly list the properties that cause seq bumping (location, dtstart...), or force it to always happen (even in case of changes on things like coment...)
[10:44:04] <eliot.lear> we do list them, but LOCATION is not one such
[10:44:23] <eliot.lear> also, if we go with something like VVENUE, you might need to bump as well
[10:44:31] <fabio.silva> but what about description, for example? it can be (or not) a reason for updating...
[10:44:42] <eliot.lear> let me ask this question: is this a problem?
[10:44:49] <eliot.lear> in implementations today?
[10:45:11] <cyrus_daboo> Apparently some implementations use SEQUENCE to trigger an alert to the user that they need to take action again.
[10:45:13] <eliot.lear> at least in outlook, it's a fairly manual process, most of the time. in iCal, you guys try to hide it under the hood
[10:45:33] <eliot.lear> cyrus: yes
[10:45:35] <cyrus_daboo> So if SEQUENCE changes unnecessarily then users get an alert they really should not need.
[10:45:56] <eliot.lear> so the question devolves back to "what is unnecessarily"
[10:46:17] <eliot.lear> and i think we agree that location isn't in that set - except that location itself is sort of a poor property
[10:46:30] <eliot.lear> because do you really care if your telephone bridge # changes?
[10:46:42] <eliot.lear> which is often what people use in their lcoations
[10:47:16] <cyrus_daboo> Yes Location does have some issues. For example if you need to "invite" a meeting room to "book" it that room will be listed as an ATTENDEE, but likely you will also want to indicate the room in Location. You now have the problem of keeping the two in sync.
[10:47:26] <fabio.silva> what seq was always bumped, bu the CUA
[10:47:27] <eliot.lear> but let me ask another question. why is this an iTIP issue and not an iCal issue? OR... put another way, should we move the table from 2445bis to 2446bis
[10:47:49] <fabio.silva> ... being the CUA responsible to evaluate if user action is needed? (sorry)
[10:48:07] <eliot.lear> cyrus: right. i think this is where the VVENUE draft might help as well
[10:49:38] <cyrus_daboo> VVENUE helps by adding a reference parameter, but it should also add that on any ATTENDEE properties that are used to "book" the location too. It does not do that right now.
[10:50:07] <eliot.lear> ok. so to summarize this issue
[10:50:18] <eliot.lear> i think we have two questions
[10:50:46] <eliot.lear> first, should the list of properties requiring a bump and all that text i copied remain in 2445bis or move to 2446?
[10:51:04] <cyrus_daboo> So the question really boils down to this: is SEQUENCE actually a useful property? If the attendee CUA is going to have logic to determine what changed in an update and figure out whether user action is required, then SEQUENCE is really redundant.
[10:51:05] <fabio.silva> in fact, I would believe that this is iTIP, because depends on scheduling workflow
[10:51:06] <eliot.lear> second, should location be added to the list, or should we create a table that specifies bumping behavior explicitly?
[10:51:57] <cyrus_daboo> I think the behavior of SEQUENCE (if we keep it) should be in 2446. It does not really make sense outside of an iTIP exchange.
[10:51:58] <eliot.lear> cyrus: that's a fair point IFF we make all of this stuff completely deterministic
[10:51:59] <fabio.silva> cyrus, isn't sequence important for message ordering?
[10:52:29] <fabio.silva> I vote for moving to 2446, and creating a table
[10:52:47] <eliot.lear> well, what are our rules about DTSTAMP?
[10:53:20] <cyrus_daboo> Ah - thanks for bring that up. That is another problem with SEQUENCE. The spec also uses SEQUENCE as a means of ordering iTIP messages, so that duplicates, out-of-order issues can be handled. IMHO that is overlaoding SEQUENCE too much.
[10:53:58] <eliot.lear> and i think this is what DTSTAMP is meant for. to quote...
[10:54:12] <eliot.lear> This property is also useful to protocols such as [I-D.ietf-calsify-rfc2447bis] that have inherent latency issues with the delivery of content. This property will assist in the proper sequencing of messages containing iCalendar objects.
[10:54:22] <eliot.lear> "this property" being DTSTAMP
[10:54:48] <cyrus_daboo> I would much rather see a new top-level parameter such as ITIP-SEQUENCE at the same level as METHOD that gets incremented by the ORGANIZER each time he sends something. That property would have two values - ther ORGANIZER's sequence and the sequence of replies to that message from each attendee.
[10:55:37] <cyrus_daboo> That would eliminate all issues wrt to duplicates or out of order messages. It does not overload SEQUENCE or put any special requirements on DTSTAMP.
[10:55:58] <eliot.lear> but cyrus, those requirements are already there, right?
[10:56:15] <eliot.lear> (for dtstamp that is)
[10:56:40] <cyrus_daboo> But its not clear when DTSTAMP is supposed to change either!
[10:56:41] --- bdesruisseaux has joined
[10:57:04] <cyrus_daboo> Should an attendee CUA update the DTSTAMP value when it sends back a reply?
[10:57:20] <fabio.silva> I think so
[10:57:58] <cyrus_daboo> Thats debateable.
[10:58:10] <eliot.lear> i agree it's debatable.
[10:58:21] <eliot.lear> i think we may need another property for replies
[10:59:58] <eliot.lear> the combination r-id/seq in the original request indicates what you are replying to. the only issue then, is what the originator is meant to do with an updated DTSTAMP
[11:00:09] <eliot.lear> (from an invitee)
[11:00:11] <fabio.silva> and leave cuas free to set dtstamp?
[11:00:47] <eliot.lear> ok, it's 5:00pm here. i need to stop. here are the action items from today:
[11:00:58] <eliot.lear> 1. eliot to get the issue tracker back on line ;-)
[11:01:33] <eliot.lear> 2. cyrus to get proposals out the door regarding THISANDFUTURE a/o OO
[11:01:45] <eliot.lear> 3. eliot to summarize each of these issues to the list
[11:01:52] <eliot.lear> anything else?
[11:01:57] <eliot.lear> did i miss anything?
[11:02:17] <cyrus_daboo> Sounds right
[11:02:26] <eliot.lear> ok. going
[11:02:28] <eliot.lear> going
[11:02:33] <eliot.lear> gone.
[11:02:43] <eliot.lear> see you on the list
[11:02:51] <alexeymelnikov> Bye
[11:02:51] <eliot.lear> and thanks for participating!
[11:02:53] <Aki> see you, bye
[11:02:55] <cyrus_daboo> Bye
[11:02:56] --- alexeymelnikov has left
[11:02:57] --- Aki has left
[11:03:02] <fabio.silva> bye!
[11:03:06] --- eliot.lear has left
[11:03:08] --- cyrus_daboo has left
[11:03:10] --- fabio.silva has left
[13:48:04] --- bdesruisseaux has left