[09:51:57] --- pigdog has joined
[09:58:35] --- apn has joined
[09:58:51] --- apn has left
[10:01:40] --- Aki has joined
[10:01:47] <pigdog> hi aki!
[10:01:51] <Aki> Hi Eliot!
[10:02:00] <Aki> Hows it hanging? ;)
[10:02:00] <pigdog> i'm just finishing a call...
[10:02:25] --- bernard.desruisseaux has joined
[10:02:34] <pigdog> greetings bernard!
[10:03:13] <pigdog> hopefully we'll get a few more people
[10:03:39] <bernard.desruisseaux> Hi Eliot!
[10:03:47] <bernard.desruisseaux> I was having issue joining the room...
[10:03:51] <pigdog> ?
[10:03:53] <pigdog> how so?
[10:04:02] <bernard.desruisseaux> hold on
[10:04:03] --- bernard.desruisseaux has left
[10:04:06] --- bernard.desruisseaux has joined
[10:04:15] <bernard.desruisseaux> back with my jabber.org account
[10:04:17] <pigdog> hi again bernard!
[10:04:55] <pigdog> waiting for others...
[10:05:16] <bernard.desruisseaux> Alexey will join in a moment
[10:05:22] <pigdog> ack
[10:05:35] --- alexeymelnikov has joined
[10:05:58] <alexeymelnikov> Sorry for being late
[10:06:23] <pigdog> well, i'd like to think cyrus would join
[10:06:24] <Aki> No problem. I think we'll give it a few more minutes anyway.
[10:07:58] <alexeymelnikov> Cyrus is not in jabber
[10:08:06] <pigdog> i wonder if he can't attend
[10:08:58] <pigdog> hmm... wait a few more minutes
[10:10:14] <bernard.desruisseaux> Cyrus is not answering his cell
[10:10:18] <pigdog> ok, let's get going.
[10:10:24] <pigdog> some ground rules for today
[10:10:57] <pigdog> anything discussed or "agreed upon" will clearly require working group confirmation. four people ought not make too many decisions, and this is of course the normal procedure for ietf
[10:11:09] <pigdog> so, with that in mind, bernard, you had sent us some mail
[10:11:36] <pigdog> in which you proposed an agenda of 59, 61-73
[10:11:53] <pigdog> what i propose is that we see if we can come up with suggestions that can be taken to the list to close the issue. does that sound reasonable?
[10:11:56] <bernard.desruisseaux> right.
[10:12:10] <pigdog> alexey, aki?
[10:12:18] <alexeymelnikov> Sure
[10:12:28] <Aki> Ok.
[10:12:40] <pigdog> ok. the issue tracker can be found at http://www.ofcourseimright.com/cgi-bin/roundup/calsify
[10:13:03] <pigdog> may we please proceed then to issue 59?
[10:13:59] --- mattwillis has joined
[10:14:19] <pigdog> hello matt. we are on issue 59. this is the very issue that was discussed on the WG list this past week
[10:14:32] <mattwillis> Thanks
[10:14:40] <bernard.desruisseaux> For issue I sent a proposal: http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001341.html
[10:15:32] <bernard.desruisseaux> Cyrus replied back then with a concerne...
[10:16:21] <bernard.desruisseaux> I talked to him about this very recently... and I was expecting him to be here today to say "I'm fine with the proposed change, please go ahead".
[10:16:22] <pigdog> (reading)
[10:16:30] <bernard.desruisseaux> But I can't speak for him...
[10:16:41] * mattwillis reads as well
[10:17:19] <pigdog> my proposal is that since we have had discussion, we have a proposal, we either do or do not have agreement. the chairs shall ask the question.
[10:17:26] <pigdog> to the list
[10:18:35] <pigdog> from that we either have consensus or we don't? If we don't we don't move forward.
[10:18:54] <pigdog> those who say no must provide an alternative to the conflict
[10:19:03] <bernard.desruisseaux> Eliot, there is a contradiction in the draft right now. That needs to be resolved. Status quo is not fine!
[10:19:33] <pigdog> i will lean on "no'
[10:19:42] <pigdog> "no" voters to provide a non-conflicting alternative
[10:20:00] <pigdog> having the conflict removed is important and blocking
[10:20:20] <bernard.desruisseaux> good. let's move on to 61
[10:20:23] <mattwillis> I think the proposal is okay, and it resolves an issue we face in how to implement events with no DTEND and no DURATION.
[10:20:51] <pigdog> thanks, matt. i'm going to send the mail to the list this moment, so the matter doesn't get dropped. give me 15 secs
[10:21:09] --- reinhold has joined
[10:21:10] <bernard.desruisseaux> Matt please reply to the list!
[10:21:14] <mattwillis> will do
[10:21:17] <bernard.desruisseaux> Hi Reinhold!
[10:21:37] <reinhold> Hi everyone! Finally a session that I can attend!
[10:21:51] <pigdog> hi reinhold and welcome!
[10:22:00] <pigdog> ok, we are now on issue 61
[10:22:13] <pigdog> once again, the issue tracker can be found at http://www.ofcourseimright.com/cgi-bin/roundup/calsify
[10:23:19] <pigdog> my recollection is taht we have discussed this issue before. am i wrong?
[10:23:24] <alexeymelnikov> Cyrus's proposal for # 61 seems straightforward
[10:23:27] <reinhold> I completely agree with eliot.
[10:23:54] <pigdog> reinhold, you're hired ;-) but i don't know on what you agreed ;-)
[10:23:55] <bernard.desruisseaux> Same here.
[10:24:27] <reinhold> if x-params are allowed, then iana-registered params should be allowed even more.
[10:24:45] <pigdog> if we are agreed to accept cyrus's change, that's fine. we will need some policy language for IANA regarding their registration. i believe that ball is currently in my court
[10:25:03] <Aki> I think specifying "other-param" as well as "other-prop" is good.
[10:25:07] <bernard.desruisseaux> There is still an issue though...
[10:25:27] <bernard.desruisseaux> Are all parameters considered "iana-param" ?
[10:26:07] <pigdog> are we registering all parameters?
[10:26:16] <alexeymelnikov> I think the intention for iana-param is to cover everything not in your document
[10:26:43] <alexeymelnikov> Registering them with IANA is another issue
[10:26:51] <pigdog> right
[10:26:53] <reinhold> Yes, all the grammars list the iCalendar props/params, and additionally the ianaparam.
[10:27:09] <reinhold> So there is no need that all parameters are considered iana-params.
[10:27:37] <reinhold> Only those not in iCalendar should be iana-registered, so that we have a well-documented and -specified meaning for them, which can be used by all implementations.
[10:27:42] <pigdog> i'm fine with a the change as discussed in the issue. what about iana-prop and x-prop?
[10:28:05] <pigdog> (and I agree with reinhold re "only those not...""
[10:28:24] <bernard.desruisseaux> There is no iana-prop defined in RFC 2445.
[10:28:37] <pigdog> should there be?
[10:28:41] <pigdog> (in bis)
[10:28:55] <bernard.desruisseaux> I also agree that parametres defined in the spec should not be considered as iana-param.
[10:28:57] <alexeymelnikov> I think it should, for consistency
[10:29:17] <bernard.desruisseaux> I also think there should be an iana-prop.
[10:29:54] <pigdog> ok, then the proposal to the mailing list is to accept BOTH the ABNF listed an analogous ABNF for iana-prop/x-prop, right?
[10:29:54] <reinhold> Isn't iana-token uses for the prop name (at least in rfc 2445).
[10:30:04] <bernard.desruisseaux> In fact, CAP (RFC 4324) had defined an iana-prop
[10:31:01] <pigdog> reinhold, that seems to be the case. so now i'm confused.
[10:31:22] <pigdog> are we just renaming abnf?
[10:31:37] <bernard.desruisseaux> I don't believe so.
[10:31:42] <pigdog> ok, so what's the diff?
[10:31:54] <bernard.desruisseaux> iana-token could allow you to define a new component name, but not a new property.
[10:31:55] <reinhold> Actually, for params we introduce a middle layer (param-name = iana-token / x-name), but for properties we don't...
[10:32:27] <reinhold> Looking at line 544 of rfc 2445bis, it seems that it assumes all param names to be iana-regiestered...
[10:33:56] <pigdog> well, do we want to list every parameter in this doc with the IANA? it sounds like a whole lot of unnecessary paperwork. otherwise, we need some different abnf
[10:34:08] <bernard.desruisseaux> param-name is only used by param... which in turn is only used by contentline... which is not of much use!
[10:34:50] <bernard.desruisseaux> All the other ABNF rules (the important ones) use the xxxparam / ianaparam / xparam rules...
[10:35:14] <reinhold> contentline defines the form for the properties, according to the text of section 3.5
[10:35:19] <pigdog> just to be clear, if we're using iana* then it gets listed with IANA. is that the intent?
[10:35:54] <bernard.desruisseaux> ianaparam should mean ... registered to iana but not defined in this spec.
[10:36:20] <pigdog> ok, so we do need a change. probably something like the following:
[10:36:28] <bernard.desruisseaux> now the question is what will happen in the next revision of the spec...
[10:36:35] <pigdog> param-name = iana-token / iCalparam / x-name
[10:36:47] <reinhold> Okay, then we need some definition for all properties/params/componentes defined in rfc 2445bis
[10:37:06] --- Lisa has joined
[10:37:25] <bernard.desruisseaux> We already have "components" and "parameters"
[10:37:31] <bernard.desruisseaux> Hi Lisa!
[10:37:53] <Lisa> hi!
[10:38:02] <alexeymelnikov> Hello
[10:38:07] <pigdog> we're in an odd situation here because we're not defining any new properties with this rev
[10:38:11] --- cyrus_daboo has joined
[10:38:23] <pigdog> the only concerns are these:
[10:38:35] <cyrus_daboo> Sorry, had an unscheduled doctor's appointment.
[10:38:36] <pigdog> 1. what if a property / param gets deprecated in the next spec?
[10:38:46] <pigdog> 2. what happens when a property / param gets added?
[10:38:50] <pigdog> hi cyrus and lisa!
[10:38:58] <pigdog> so, we are on issue 61
[10:39:12] <pigdog> we've just realized that the spec as written would require registration of all parameters with iana.
[10:39:16] <pigdog> is that what we want?
[10:39:24] <pigdog> comments from the new additions?
[10:39:39] <bernard.desruisseaux> I think it would make sense to register everything...
[10:39:50] <alexeymelnikov> I was thinking that we should register everything with IANA
[10:40:14] <Lisa> If you want a 100% reliable way to avoid naming conflicts since parameters aren't namespaced.
[10:40:15] <bernard.desruisseaux> perhaps ianaparam should be renamed to future-param...
[10:40:25] <Aki> Iff we want to allow for the x- prefix, then there needs to be a rule for those in the ABNF.
[10:40:30] <cyrus_daboo> I think we could get away with only having to register additions to the existing spec. A number of rfc's do that. Having said that, however, IMAp ANNOTATE does register the new items it defines, so there is precedence the other way.
[10:40:38] <Lisa> A mixed, confusing approach would be to say that parameters used only in custom properties did not have to be registered.
[10:41:00] <Lisa> (because the custom property acts as a namespacing mechanism)
[10:41:14] <alexeymelnikov> LDAP specs registered *everything* recently (in a separate RFC)
[10:41:28] <cyrus_daboo> I certainly agree that we do not need a registration mechanism for X-.
[10:41:46] <Aki> it's all about what policy we dictate for params, props, etc. FCFS, RFC required, IETF consensus and all that. Seems an orthogonal issue to the ABNF.
[10:41:54] <cyrus_daboo> I could live with a separate doc to do all the registrations.
[10:42:07] <cyrus_daboo> But we do need to decide HOW new items should be vetted...
[10:42:25] <pigdog> i see no reason to have a separate doc, but i agree that we need to decide how new items should be vetted.
[10:42:39] <pigdog> so. the proposal to the list is as follows, if i hear everyone:
[10:43:05] <pigdog> register everything (reinhold can you live with that)?
[10:43:20] <pigdog> also, accept cyrus's wording for other-param
[10:43:33] <pigdog> but no need for iana-prop / x-prop.
[10:43:36] <pigdog> is that correct?
[10:43:36] --- Aki has left
[10:43:37] <cyrus_daboo> 2445 is pretty big as it is - having a separate section that registers all items would add a lot to that. Maybe if we changed the current spec so that the definitions of the components/properties/parameters were actuially iana registrations, then we could do both at the same time.
[10:43:47] <cyrus_daboo> But that would require some major re-edits to the existing content.
[10:43:48] <bernard.desruisseaux> If we change: fbparam = *( (";" fbtypeparam) / (";" xparam) ) to: fbparam = *( (";" fbtypeparam) / (";" xparam) / (";" ianaparam ) and that ianaparam means *all* parameters, then we may as well say: fbparam = *( (";" parameters) ) which is not what we want. We could go with: fbparam = *( (";" fbtypeparam) / (";" xparam) / (";" future-param ) ) where future-param would means registered parameters not defined here.
[10:44:39] --- Aki has joined
[10:44:46] <reinhold> pigdog: Of course, I can live with it (as long as I don't have to do the work ;-) )
[10:45:27] <cyrus_daboo> The big issue is whether we need separate registries for each type of property/parameter/value pairs. I think we can do without that so long as the registration templates allow restricting the use of the new item to specific comps/props/aparams etc
[10:45:28] <reinhold> I still think that for consistency we should do the same to props as the rfc does with params: add an ianaprop definition.
[10:45:30] <pigdog> cyrus, if we can make the template nice and tight, i think we're talking about two or three pages
[10:46:06] <pigdog> and i think the template really only needs to be name, RFC. This presumes of course a policy of RFCs for params, props, etc.
[10:46:34] <cyrus_daboo> I'm not convinced about two or three pages - if we need to add the restrictions of where each item can be used that will add a lot. True, descriptions of the items can always refer to the rfc section number above so that would be compact.
[10:46:35] <alexeymelnikov> Another option is too list all items as a table
[10:47:12] <alexeymelnikov> I think tables will end up being 2-3 pages
[10:47:38] <alexeymelnikov> But I am also fine with changing the section describing things into IANA registrations
[10:47:38] <pigdog> ok, i think we are blocking on IANA considerations here
[10:47:39] <cyrus_daboo> The template needs to be "name", "type" (component, property, parameter, property value, parameter value).
[10:47:56] <cyrus_daboo> and "reference" (to the rfc section).
[10:48:27] <Aki> The initial set IANA registrations could simply be an appendix. It's not essential reading; they're instructions for IANA, really.
[10:48:48] <cyrus_daboo> We might be able to do without registering values if we allow existing templates to be extended. i.e. a template for prop and param lists the allowed value types and allowed enumerated values. A new spec comes along and extends the existing template to add a new enumerated value.
[10:49:45] <pigdog> ok, so i owe text on IANA considerations. this issue 61 does not need to block on that. let's assume at least for the moment that we can make the section compact enough
[10:49:49] <alexeymelnikov> Aki: agreed
[10:50:40] <cyrus_daboo> Agreed - but I've heard enough complaints from implementors about the caldav spec being too big at 100+ pages and thus "presenting a hurdle to implementations" - even though a major portion of it is examples and formal xml defintiions. Adding a large appendix would give those people more of an excuse to not implement - they could say that we didn't make the spec simpler because we added 20 pages.
[10:50:40] <pigdog> the proposal on the table at this point is to accept Cyrus' suggested wording for other-param but not to accept iana-prop/x-prop. is that correct?
[10:51:02] <bernard.desruisseaux> I think the easiest / cheapest approach would be to extend the existing component / property / parameter definitions TO BE the IANA registration itself...
[10:51:21] <bernard.desruisseaux> I think we need iana-prop
[10:51:37] <alexeymelnikov> I agree with Bernard, especially as he is the editor ;-)
[10:51:40] <bernard.desruisseaux> I believe ianaparam and iana-prop are bad misleading names.
[10:51:57] <pigdog> bernard, do you want to propose an alternative?
[10:51:57] <alexeymelnikov> I also think we need iana-prop
[10:52:09] <bernard.desruisseaux> I thought I already proposed something!
[10:52:16] <bernard.desruisseaux> Again: change ianaparam to future-param
[10:52:26] <alexeymelnikov> That would be fine with me
[10:52:29] <bernard.desruisseaux> or future-iana-param...
[10:52:34] <bernard.desruisseaux> you get the idea
[10:52:35] <alexeymelnikov> Even better
[10:52:36] <pigdog> i do not recommend the use of the word "future"
[10:52:41] <reinhold> As soon as you register the param, it's no longer future, but existing
[10:52:49] <cyrus_daboo> I don't like "future" either.
[10:52:50] <pigdog> the problem with "future" is that it is misleading that it is not normative
[10:53:09] <bernard.desruisseaux> I agree that future is not really good...
[10:53:09] <pigdog> or at least not normative "today" for some value of today
[10:53:23] <cyrus_daboo> I see no problem with just 'iana-...', or perhaps your could use "std-..." or "standard-...".
[10:53:33] <pigdog> i agree with cyrus wrt iana-
[10:53:39] <pigdog> that's what you proposed, and the ABNF is simple
[10:53:56] <alexeymelnikov> (I don't really care about the name)
[10:54:01] <pigdog> so, let me see if i now have the proposal:
[10:54:10] <bernard.desruisseaux> but then... if fbparam allows iana-param... that means it allows all parameters...
[10:54:24] <bernard.desruisseaux> which is not what we want!
[10:54:40] <pigdog> do we need a separate registry?
[10:54:52] <bernard.desruisseaux> The idea was given that fbparam allows xparam it doesn't really make sense not to leave the door open to future standard parameters...
[10:55:01] <cyrus_daboo> No - the registration template will explicitly include restrictions of which params can apepar in which properties etc - again abnf is not normative wrt restrictions - the registrations are.
[10:55:35] <bernard.desruisseaux> Hummm....
[10:55:38] <Aki> how about a top rule of param = parameters / extensions, and split extension = iana-param / x-param. param would be the initial set, and policy applies to iana-param registrations? (Excuse bad BNF)
[10:55:54] <bernard.desruisseaux> People will invente new properties and will want to make use of existing parameters on them...
[10:56:10] <bernard.desruisseaux> the existing parameters will not specify anything for these new properties...
[10:56:36] <pigdog> so long as the docs that explain those new props explain which params can be used, what's the problem?
[10:56:47] <Aki> Agree: I don't think the registry even necessarily needs to say which params are allowed in which properties; as long as the reference to which the IANA entry points to describes it.
[10:56:57] <cyrus_daboo> That one is easy - the new property registration lists the parameters allowed. The harder one is someone wanting to use an existing parameter on an existing property. I am not sure we can allow that.
[10:57:38] <pigdog> cyrus, you mean an existing param that is not permited for the existing prop, right?
[10:58:16] <cyrus_daboo> Yes, e.g. you cannot register param CN for use on prop Location.
[10:58:22] <pigdog> right.
[10:58:28] <pigdog> so now the proposal on the table is:
[10:59:18] <pigdog> accept both of cyrus's suggestions, and implement consistently throughout the document (including fbparam). note restrictions within props. make a template, and make sure that the prop and param definitions cover the information in teh template. is that right?
[11:00:22] <alexeymelnikov> Looks right
[11:00:38] <pigdog> others?
[11:00:52] <reinhold> I like that proposal
[11:01:00] <bernard.desruisseaux> I'm fine. "ianaparam" is defined as "Some other IANA registered iCalendar parameter."
[11:01:26] <Aki> I think that's ok.
[11:01:50] <cyrus_daboo> Agreed.
[11:02:02] <bernard.desruisseaux> but wait :-)
[11:02:04] <pigdog> that would be a param listed in either this doc or in another RFC, right?
[11:02:22] <bernard.desruisseaux> Once rfc2445bis is published....
[11:02:35] <bernard.desruisseaux> I publish a RFC to define the parameter FOO.
[11:02:54] <bernard.desruisseaux> As such, FOO will be allowed on the FBTYPE property...
[11:03:19] <bernard.desruisseaux> We revise iCalendar once again.. and decide to specify the parameter FOO in the spec directly...
[11:03:47] <bernard.desruisseaux> If we keep ianaparam as "Some other IANA registered..." then there is a problem...
[11:04:09] <bernard.desruisseaux> FBTYPE would not allow the parameter FOO unless I specify it explicitly...
[11:04:22] <alexeymelnikov> So?
[11:04:31] <cyrus_daboo> No - the registry could be updated by the new spec and the now irrelevant registration removed or a note added.
[11:04:39] <cyrus_daboo> IANA can be flexible.
[11:04:57] <pigdog> i don't understand what you mean by "some other IANA registered". an iana-param is either a parameter specified in this document or in a later RFC. if they want to coalesce stuff later, that's fine. they'll have to determine an appropriate IANA consideration.
[11:05:00] <Aki> I don't agree. ABNF isn't expressive enough to make those restrictions. Much better if you're RFC that specifys FOO also says where it is allowed. IANA need not know; they just list FOO and a reference. Or am I confused?
[11:05:21] <cyrus_daboo> If we worry about all possible future universes of new calendaring extensions and spec we will never finish :-)
[11:05:50] <pigdog> yes, cyrus. that is my concern
[11:05:55] <alexeymelnikov> I agree with Cyrus :-)
[11:05:58] <pigdog> i think we have it about as close as we can.
[11:06:07] <bernard.desruisseaux> Ok! Let's move on... I agree this is not *really* important...
[11:06:13] <pigdog> Yeah!
[11:06:20] <pigdog> ok, issue 62 in 30 seconds.
[11:06:38] <cyrus_daboo> It is important in that there are already some extensions in the works that actually need to use this stuff so we had better get it right.
[11:06:59] <pigdog> ok
[11:08:08] <pigdog> issue 62 recurrence-id
[11:08:51] <pigdog> are there any objections to Bernard's proposal?
[11:09:30] <pigdog> going once
[11:09:31] <reinhold> Hmm, about issue 62: Assume I have an event every monday, and have one particular occurrence changed (using the RECURRENCE-ID). Now I move the whole event to recur on tuesday. It's not clear in general, to which occurrence that changed one really belongs...
[11:09:52] <alexeymelnikov> I might have to disappear now
[11:10:04] <pigdog> (thanks alexey!)
[11:10:26] <reinhold> So, I would agree with bernard. Unfortunately that means that the data of the changed item is lost.
[11:10:40] <pigdog> sorry - which data?
[11:10:46] <pigdog> you mean that the item itself is a change?
[11:11:08] <cyrus_daboo> Yes - this is an iTIP problem - I want to ban an update to an recurring event that modifies the base rule in such a way that recurrence-ids that attendees have can no longer be correlated with the new ones.
[11:11:43] <bernard.desruisseaux> If you want to preserver the particular occurence that was changed before the rule was changed, you could specify an RDATE with the orignal start time of this instance...
[11:11:57] <bernard.desruisseaux> the RECURRENCE-ID of this occurence would still be good...
[11:12:31] <cyrus_daboo> If that happens I believe the organizer has to cancel the original and send a completely new one. Or do some juggling with the existing RRULE pattern by overriding every instance to match the new pattern (yes that is stupid but it shows why the former approach is better).
[11:12:40] <Lisa> you want a "Do the right thing here!" rule :)
[11:12:47] <reinhold> Ah, right. But then that item would not be moved to tuesday... That's fine, I think, though.
[11:14:02] <pigdog> forgive me. i am not sure i see consensus, and i'm not clear on the issue in my own head.
[11:14:15] <Aki> Are we in agreement? Accept Bernard's proposal and add a "Do the right thing" rule in iTIP?
[11:14:32] <cyrus_daboo> One problem here is that an attendee might have added their own notes etc to a specific instance - but if there is a "global" reschedule they are going to loose track of that instance no matter what. There client could be smart and figure out how to transfer the attendee-specific info over. Perhaps what we need is a way in iTIP to do a 'RESCHEDULE' operation - new method perhaps?
[11:14:59] <cyrus_daboo> That would give clients the chance to correlate their data with the new schedule.
[11:15:39] <pigdog> that sounds reasonable - if you have a reschedule, you can provide correlating information...
[11:15:51] <pigdog> so are we accepting this change and making this iTIP's problem?
[11:16:33] <cyrus_daboo> Well the statement as -is is correct. In fact it is the driving force behind the recommendations we need to make in iTIP. So I think a statement of that nauture needs to be preserved, but iTIP is probably the best place for it. So, yes, remove from 2445bis - but add to 2446bis.
[11:17:03] <bernard.desruisseaux> How could one possibly correlate the specific recurrence instance for which the "RECURRENCE-ID" changed?
[11:17:46] <pigdog> you need an operation that has both old and new, right?
[11:17:47] <cyrus_daboo> You would have to send a map of (old-r-id, new-r-id) for every instance. Not practical in a lot of cases.
[11:17:53] <bernard.desruisseaux> The RECURRENCE-ID of an instance CANNOT change. Else, it's a different instance that we are talking about...
[11:18:59] <bernard.desruisseaux> There is currently no way of sending a map, and I don't see why you would do that...
[11:19:27] <bernard.desruisseaux> If you want to change the rule and preserve the old instances... just make RDATE for the old instances with their original RECURRENCE-ID...
[11:20:09] <cyrus_daboo> True but there are use cases where a meeting set needs to be pushed back a week, say, but the existing data for those instances preserved. The organizer can always do that with his set of info, but again any private info that attendees have will be lost.
[11:21:03] <bernard.desruisseaux> Keep the rule... define an overriden component for each instance.
[11:21:25] <reinhold> cyrus_daboo: If it's "pushed back" a week, how do you know it's not pushed forward 3 weeks?
[11:21:50] <reinhold> (assuming montly recurrences)
[11:22:08] <cyrus_daboo> Its not a case of preserving the old instances, but rather mapping them to new ones. Sure I could use an RDATE for each old one, and then override those to match the instances in the new rule, but what does 2445 have to say about an overridden instance that exactly matches a non-overridden one? Which one wins, or do both occur in the set?
[11:23:09] <cyrus_daboo> reinhold: ultimately the organizer knows the "real" intent of what is going on and they can determine how to move their instances around. The problem is communicating that to attendees - we can't right now.
[11:23:16] <bernard.desruisseaux> Are there UIs out there that allow you to push a recurrence back a week?
[11:23:57] <Lisa> Good question, we definitely want to know how important this is -- does it fall in the 80% or the 20% or less.
[11:24:07] <bernard.desruisseaux> I doubt. Most likely, the user either deletes the recurrence set or move individual instances. No?
[11:24:27] <cyrus_daboo> At this point I think our proposal should be to defer to iTIP discussions - lets not burden 2445bis with this.
[11:24:55] <pigdog> that being the case, is the room agreeable to bernard's proposal? any objections?
[11:25:01] <bernard.desruisseaux> I still think that we should remove the statement from rfc2445bis.
[11:25:02] <cyrus_daboo> It may be we have to invent a new mechanism to handle this case, and new properties etc to do that so there may be some impact back on 2445, but we might be able to avoid that too.
[11:25:15] <cyrus_daboo> I agree with removing it in 2445bis.
[11:25:17] <reinhold> In KOrganizer we allow moving events and adjusting the recurrence rule. However, that adjustment is not always possible (e.g. if you move an event on "last sunday every monthly" two days back, you can't represent this as as rrule).
[11:26:06] <reinhold> I also agree with removing it in 2445bis.
[11:26:27] <pigdog> ok. i'll send out the proposal.
[11:26:33] <Aki> Good.
[11:26:40] <cyrus_daboo> There are a lot of cases like that that iTIP needs to be better at: e.g. a recurring meeting every Monday that is then shifted to every Tuesday after a bunch have already ocurred. How to do that in iTIP?
[11:26:57] <pigdog> all, we are nearly out of time. i would like to thank you for a vigorous discussion. on next jabber session is this time period next Thursday.
[11:27:09] <pigdog> or do we miss a week due to calconnect?
[11:27:16] <cyrus_daboo> OK - I will be at Calconnect so won't be able to attend that one.
[11:27:26] <pigdog> i think we skip a week due to calconnect
[11:27:58] <pigdog> (hang on- checking calendar ;-)
[11:27:59] <bernard.desruisseaux> I'm working on draft -05 with the fixed ABNF in the txt version... as well as some editorial changes that Alexey sent to me.
[11:29:01] <pigdog> ok, the invite shows that we're on for next week, but i think our author's discussion said this would be pointless, so no jabber next week. but let's keep things going on the mailing list!
[11:29:26] <cyrus_daboo> Does that mean we push that instance back a week or just cancel it ;-)
[11:29:37] <pigdog> i *knew* that one was coming!
[11:29:42] <pigdog> ;-)
[11:29:46] <pigdog> thanks all for participating today!
[11:29:49] <Aki> :-)
[11:29:50] <bernard.desruisseaux> let's move this instance after all the other ones...
[11:29:58] <Lisa> bye guys
[11:30:03] <cyrus_daboo> Sorry, could not resist. We'll be getting plenty of that once we really get into iTIP.
[11:30:14] <Aki> Thanks, see you all in two weeks -1D
[11:30:25] --- cyrus_daboo has left
[11:30:30] <reinhold> Bye everyone!
[11:30:33] --- mattwillis has left
[11:30:34] --- Aki has left
[11:30:35] <pigdog> bye
[11:30:41] --- Lisa has left
[11:34:20] --- reinhold has left
[11:34:24] --- pigdog has left
[11:37:02] --- bernard.desruisseaux has left
[11:44:01] --- alexeymelnikov has left