[10:08:22] --- pigdog has joined
[10:32:29] <pigdog> This meeting will begin in one half hour
[10:46:57] <pigdog> this meeting will start in 15 minutes
[11:00:10] --- alexeymelnikov has joined
[11:00:21] <pigdog> hi alexey! how's it going?
[11:00:43] <alexeymelnikov> Not bad, yourself?
[11:00:59] <pigdog> not too bad here either. no sign of bernard. this might be an awfully short jabber.
[11:01:37] <alexeymelnikov> Indeed
[11:02:04] <pigdog> we'll give it five monutes or so
[11:02:11] <pigdog> s/mon/min
[11:03:34] <alexeymelnikov> :-)
[11:05:58] <alexeymelnikov> No sign of Bernard in Jabber
[11:06:05] --- cyrus_daboo has joined
[11:06:12] <pigdog> hi cyrus..
[11:06:15] <cyrus_daboo> Hi
[11:06:16] <alexeymelnikov> Hi
[11:06:31] --- bernard.desruisseaux has joined
[11:06:32] <pigdog> i now see bernard online
[11:06:38] <pigdog> greetings bernard!
[11:06:42] <alexeymelnikov> Hi
[11:06:43] <bernard.desruisseaux> sorry guys
[11:06:44] <cyrus_daboo> I just pinged him in my VALARM mode.
[11:06:49] <pigdog> hah!
[11:07:00] <pigdog> ok, let's go ahead and get going.
[11:07:35] <pigdog> first, agenda bashing. i'd like to proceed down the issue list, noting, however that we have a bunch of issues that require some work of each of us- save alexey. alexey, you do realize that makes you a target?
[11:07:42] <pigdog> ;-)
[11:07:57] <pigdog> but seriously folks, any additions or subtractions to the agenda?
[11:08:28] <pigdog> ok
[11:08:43] <pigdog> before i suggest an issue to start from bernard, do you have a preference?
[11:08:48] <alexeymelnikov> I almost volunteered for the IANA issue, but you got there first :-)
[11:08:58] <bernard.desruisseaux> last time we covered issues 19-23 and 27
[11:09:06] <pigdog> right.
[11:09:29] <pigdog> just a moment. now checking my own list to see where to continue from
[11:09:32] <bernard.desruisseaux> Can we look at 36, 42, 47, 54, ..
[11:09:38] <pigdog> ok, that's good.
[11:09:40] <pigdog> 36?
[11:10:30] <bernard.desruisseaux> It is about x-name.
[11:10:42] <pigdog> yep. didn't we beat this one to death at some point?
[11:10:43] <bernard.desruisseaux> In RFC 2445 there was some inconsistency to say the least
[11:11:08] <bernard.desruisseaux> Eliot: Yes, but do we have concensus? The tracker doesn't say so!
[11:11:31] <pigdog> right. i think there was some confusion about what it means to be bilateral
[11:11:46] <bernard.desruisseaux> http://www3.ietf.org/proceedings/06nov/minutes/calsify.txt - Issue 36: X-name Status: no consensus
[11:11:50] <bernard.desruisseaux> :-)
[11:12:09] <alexeymelnikov> s/bilateral/mutual ?
[11:12:57] <pigdog> yes, but i would take into account Sam Robert's warning. I would like text somewhere saying that X-Names should be avoided, and that an IANA name is better used with an RFC behind it
[11:13:03] <pigdog> what do you think?
[11:13:33] <alexeymelnikov> Make sense
[11:13:46] <alexeymelnikov> Can you suggest specific text?
[11:14:02] <pigdog> I think Sam provided some. let's see if it's appropriate...
[11:14:18] <pigdog> he focuses on iTIP
[11:14:18] <bernard.desruisseaux> I don't think anybody can argue with Sam, but in practice... you'll see more people using x-name than iana-* ... let's face it.
[11:14:23] <cyrus_daboo> The trouble is a lot of clients DO generate X- names - so we should not have an outright statement about avoiding them. I think the comment in the tracker is good.
[11:14:25] <bernard.desruisseaux> Please look at : http://lists.osafoundation.org/pipermail/ietf-calsify/2006-August/001083.html
[11:15:30] <alexeymelnikov> And if the text says that X-names must be removed before sending to other clients, I don't think anybody is going to follow this restriction.
[11:15:36] <bernard.desruisseaux> Currently, RFC 2445 says: x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") ;; Reservered for experimental use. Not intended for use in > ; released products.
[11:15:55] <bernard.desruisseaux> The part that says : "Not intended for use in released products." is clearly WRONG!
[11:16:04] <pigdog> it's not wrong, it's just ignored.
[11:16:05] <cyrus_daboo> Well it is used in released product so that statement is bogus now.
[11:16:18] <alexeymelnikov> Cyrus: Exactly
[11:16:38] <bernard.desruisseaux> Section 7.2: 7.2 Registration of New Properties This section defines procedures by which new properties or enumerated property values for the MIME Calendaring and Scheduling Content Type can be registered with the IANA. Non-IANA properties can be used by bilateral agreement, provided the associated properties names follow the "X-" convention.
[11:16:39] <cyrus_daboo> Even "experimental" is bogus.
[11:17:02] <pigdog> i would suggest that we want to encourage people to avoid X-Names even so.
[11:17:04] <bernard.desruisseaux> This is where I got the idea of proposing: ; Reserved for non-standard names. Can be used by bilateral agreement.
[11:17:35] <bernard.desruisseaux> I was making the ABNF in sync w/ the text.
[11:17:40] <pigdog> Well, here's a question for you vendors: if given the opportunity to write an RFC to document a feature would you take it?
[11:17:46] <cyrus_daboo> But what does bilateral mean? The fact is there is no way to do a negotiation to setup a bilateral agreement.
[11:17:47] <bernard.desruisseaux> Now it seems people don't like "bilateral"...
[11:18:35] <cyrus_daboo> Well actually its the "agreement" part that is the problem - there is no real way to determine that.
[11:18:43] <alexeymelnikov> Should we just drop "use by bilateral agreement" part and recommend to register properties with IANA
[11:19:10] <pigdog> i think so. that way we're not prohibiting but we are encouraging good net-friendly behavior
[11:19:23] <bernard.desruisseaux> agreement of the partners in information interchange
[11:19:32] <bernard.desruisseaux> I took this phrasing from ISO 8601!
[11:19:48] <pigdog> not for nothing, but ISO doesn't have the corner on correctness
[11:19:53] <pigdog> consider my case
[11:20:01] <cyrus_daboo> But there is no protocol for obtaining that agreement. When I send iMIP to you I have no idea what client you are using and frankly I should not have to care.
[11:20:02] <pigdog> i work at Cisco who use exchange, and I try to use iCalendar.
[11:20:24] <pigdog> i'm sure everyone on this call understands the sort of lack of bilarteral arrangements that exist there ;-)
[11:21:26] <pigdog> ok, i've said my peace. let's review the options and see if we can come to consensus. as chair i'll accept what you guys agree to
[11:21:31] <alexeymelnikov> If implementations A and B have "an agreement", it doesn't stop implementation C from supporting it.
[11:21:32] <cyrus_daboo> The key thing with X- props is that they not depend on values in regular props. If they do, and a client that does not understand the X- prop changes the standard prop., then the X- prop aware client is going to see an inconsistent state. They MUST be able to handle that safely.
[11:22:10] <pigdog> i think that's an important point
[11:22:27] <alexeymelnikov> Yes, implementations must ignore things they don't recognize
[11:22:37] <cyrus_daboo> So a statement like: "clients cannot rely on X- props sent out to another client being returned or returned with a value consistent with other standard properties that may have changed".
[11:23:00] <pigdog> so our options are (a) leave the text alone, (b) accept bernard's change, or (c) strike the text in section 7.2. do i have that right?
[11:23:00] <alexeymelnikov> And I agree about dependencies between properties
[11:23:31] <cyrus_daboo> BTW the same is of course true for iana - props: a client that has not been upgraded to support a new iana prop will potentially break clients that have been upgraded.
[11:23:46] <pigdog> true
[11:24:05] <pigdog> we must require backward compatibility in the IANA considerations section
[11:24:15] <alexeymelnikov> I agree
[11:24:31] <pigdog> otherwise we're back to playing version games
[11:24:38] <pigdog> and i think we'll want to leave that one alone
[11:24:51] <cyrus_daboo> So another statement: "X- or iana props MUST NOT have a dependency on standard 2445bis props, or if they do, they MUST only be exchanged between CUAs that understand them".
[11:25:18] <pigdog> cyrus, is that backwards?
[11:25:46] <cyrus_daboo> ??
[11:25:47] <bernard.desruisseaux> Can we clarify something simple first? :-)
[11:25:58] <bernard.desruisseaux> An iCalendar application should be allowed to specify x-name anytime. That is, it doesn't need to check with an out-of-bound mechanism to find out if the receiver (unknown in most cases) will understand the x-name.
[11:26:14] <bernard.desruisseaux> Do we agree?
[11:26:27] <cyrus_daboo> Yes.
[11:26:34] <alexeymelnikov> Yes
[11:26:35] <pigdog> bernard, i agree
[11:26:52] <bernard.desruisseaux> Is an iCalendar application that doesn't understand a given x-name or iana-prop, etc. require to preserve these values?
[11:27:08] <cyrus_daboo> No.
[11:27:42] <cyrus_daboo> Not required, but perhaps SHOULD or MAY.
[11:27:43] <bernard.desruisseaux> I don't disagree with cyrus here, but I believe cyrus-today disagrees with cyrus-months-ago !
[11:27:58] <bernard.desruisseaux> In the context of CalDAV, cyrus you wanted the server to keep them.
[11:27:59] <bernard.desruisseaux> Right?
[11:28:02] <cyrus_daboo> I like being self-inconsistent!
[11:28:06] <bernard.desruisseaux> :-)
[11:28:24] <pigdog> here i think a MAY is appropriate, and the behavior is undefined when it happens.
[11:28:44] <cyrus_daboo> Ah, but a CalDAV server is not quite the same as a CUA - its really a store for CUA data, so it should preserve that.
[11:28:46] <pigdog> one could imagine properties that require modifications by the CUA.
[11:28:49] <alexeymelnikov> I think we need to define behaviour one way or another: either you alwys keep unknown properties, or you strip them
[11:28:59] <bernard.desruisseaux> A simple approache would be... if client A store the object with some x-name the server SHOULD/ MUST keep them...
[11:29:15] <alexeymelnikov> I would go for MUST
[11:29:25] <bernard.desruisseaux> If a client that don't understand of these x-name in the object... updates the object, then it MAY / SHOULD delete them...
[11:30:01] <cyrus_daboo> I would rather say MAY/SHOULD keep them, rather than emphasising "delete".
[11:30:15] <bernard.desruisseaux> I don't disagree.
[11:30:30] <pigdog> the issue here is that a client that doesn't participate can only keep and not modify or delete. i think it makes no sense to strip
[11:30:31] <bernard.desruisseaux> In practice keeping them will yield a better result.
[11:30:42] <cyrus_daboo> Also, remember that a server is allowed to modify the iCal data at any point - so a MUST for preserve can never be satisfied. It needs to be a SHOULD.
[11:31:03] <pigdog> ok, bernard, do you want to propose new text?
[11:31:14] <cyrus_daboo> Yes keeping is better provided you do not hit a dependency between an X- and a std property.
[11:31:17] <pigdog> ... based on this discussion?
[11:32:01] <pigdog> right, cyrus, but i think the dependency would be unidirectional- from an standard property to an X property (which would be bizarre anyway)
[11:32:13] <bernard.desruisseaux> ... thinking...
[11:33:35] <bernard.desruisseaux> Currently, RFC 2445 doesn't say anything about whether clients needs to preserver the x-name or not...
[11:33:50] <bernard.desruisseaux> I'm not sure we need to say anything? What do you think?
[11:34:02] <cyrus_daboo> Not really - lets say I wanted to add a X-RRULE-Description property that provides a textual description of the recurrence. If the RRULE changes but that property does not the description is out of sync.
[11:34:03] <alexeymelnikov> I would rather say something
[11:34:04] <bernard.desruisseaux> We don't say anything about any prop in general...
[11:34:46] <cyrus_daboo> Its really iTIP that has to say something about them as that deals with interchange of data.
[11:34:50] <bernard.desruisseaux> Alexey: A best practice comment perhaps?
[11:34:58] <pigdog> cyrus, i see what you're saying
[11:34:59] <alexeymelnikov> Yes
[11:35:05] <pigdog> bernard, yes.
[11:35:07] <bernard.desruisseaux> and CalDAV
[11:35:36] <alexeymelnikov> Great, Cyrus owns this one now ;-)
[11:35:41] <pigdog> but i still think this is worthy of comment in 2445.
[11:35:43] <bernard.desruisseaux> What about "bilateral agreement" ? we drop this idea completely...
[11:35:50] <pigdog> please
[11:35:52] <bernard.desruisseaux> you don't need an agreement..
[11:35:53] <cyrus_daboo> Yes
[11:35:57] <alexeymelnikov> Bernard: yes, drop it
[11:36:31] <pigdog> ok. so on this issue we (a) drop bilateral agreement,
[11:36:48] <bernard.desruisseaux> Seems we have concensus for: - Drop the idea that a bilateral agreement is needed. - Should add a best practice saying that x-* and iana-* should be preserved.
[11:37:00] <pigdog> (b) provide some BCP text to say "be careful about X-Names", and (c) preserve them
[11:37:13] <alexeymelnikov> So, we need text about 1) ignoring unrecognized properties during processing 2) preserving them when passing 3) recommend to register properties
[11:37:24] <pigdog> alexey, yes
[11:37:30] <bernard.desruisseaux> good.
[11:37:52] <bernard.desruisseaux> Eliot please update the issue with the resolution and let's move on!
[11:38:00] <pigdog> bernard, ok to leave this with you then?
[11:38:05] <bernard.desruisseaux> yes
[11:38:22] <pigdog> ok, comment added.
[11:38:24] <pigdog> moving on
[11:38:38] <pigdog> issue 42
[11:38:38] <bernard.desruisseaux> issue 42
[11:39:24] <bernard.desruisseaux> Actually... http://www3.ietf.org/proceedings/06nov/minutes/calsify.txt
[11:39:24] <bernard.desruisseaux> - Issue 42: ALARM actions Status: this is open, and there's no text. Bernard: The action property is extensible, yet the VALARM component only allows certain actions. Should allow for extensions. Consensus. Closed, but need text.
[11:39:54] <bernard.desruisseaux> Please update tracker according to the minutes.
[11:39:59] <alexeymelnikov> Sounds very close to IANA issue
[11:40:17] <pigdog> just a sec
[11:40:19] <bernard.desruisseaux> Here the text change will be to remove the restriction
[11:40:30] <pigdog> ok. you need to do that, right?
[11:40:59] <alexeymelnikov> So just drop one sentence, right?
[11:41:11] <bernard.desruisseaux> The ACTION property in a VALARM should be allowed to have a iana-token or x-name
[11:41:20] <bernard.desruisseaux> I think so.
[11:41:28] <pigdog> ok
[11:41:40] <pigdog> i'll close it with the understanding that you're removing that line
[11:41:47] <bernard.desruisseaux> Remove: The "ACTION" property MUST specify one and only one of these values.
[11:42:08] <bernard.desruisseaux> Issue 47
[11:42:10] <pigdog> moving on
[11:42:13] <pigdog> issue 47
[11:42:38] <bernard.desruisseaux> Cyrus was supposed to propose text.
[11:43:19] <pigdog> right. the issue here is that we should make this change mindful of what existing implementations do
[11:44:07] <bernard.desruisseaux> On the other hand, I don't believe this is very important...
[11:44:24] <pigdog> comments, please?
[11:44:24] <bernard.desruisseaux> I don't think VALARM are used a lot with day events...
[11:44:39] <pigdog> (i would tend to agree, but i like your change)
[11:45:17] <pigdog> cyrus, alexey, how do you guys handle this one?
[11:45:58] <alexeymelnikov> I can't comment, I don't do an implementation yet
[11:46:06] <pigdog> cyrus?
[11:46:14] <pigdog> actually, i can check...
[11:46:48] <cyrus_daboo> iCal seems to specify triggers in intervals of days when tied to an all-day event. That makes sense.
[11:47:18] <pigdog> i get "the day before at 11:45 pm"
[11:47:40] <pigdog> so, i suspect that's localtime
[11:48:08] <pigdog> one more moment
[11:48:27] <bernard.desruisseaux> Cyrus: Even with this limitation the ambiguity is still present
[11:48:32] <pigdog> TRIGGER:-PT15M
[11:48:58] <cyrus_daboo> We could say that the trigger duration can only use days/weeks when the event has VALUE=DATE.
[11:49:08] <bernard.desruisseaux> I strongly disagree!
[11:49:26] <bernard.desruisseaux> You still don't know which midnight...
[11:49:39] <cyrus_daboo> Well then TRIGGER is always relative to midnight on the specified event day.
[11:49:48] <bernard.desruisseaux> BTW, duration in terms of week is specified in ISO 8601, but not in iCalendar.
[11:50:11] <bernard.desruisseaux> Cyrus: ?
[11:50:17] <cyrus_daboo> You do know which one: the RELATED parameter on the TRIGGER tells you.
[11:50:19] <pigdog> ok, so keeping on this issue, i think bernard's text reflects reality
[11:50:51] <cyrus_daboo> If its related=start - its the midnight that starts the day, if its related=end, its the midnight that ends the day - all in local time.
[11:51:04] <bernard.desruisseaux> Cyrus: eheh! that's not the issue here
[11:51:28] <bernard.desruisseaux> The issue is given a DATE whether it is the start or end we don't care...
[11:51:28] <cyrus_daboo> What then?
[11:51:41] <bernard.desruisseaux> when is the midnight of this date...
[11:52:03] <bernard.desruisseaux> A client will need to decide
[11:52:12] <cyrus_daboo> Whatever is the localtime midnight.
[11:52:23] <cyrus_daboo> But you don't know because there is no timezone!
[11:52:27] <bernard.desruisseaux> Here's what I had proposed:
[11:52:28] <bernard.desruisseaux> In my opinion, applications should trigger the alarm relative to 00:00:00 of the time zone configured on the calendar that contains the event or to-do, or the current user's preferred time zone. UTC should only be used when no specific time zone can be found in the current context.
[11:52:57] <pigdog> i think that adheres to the principle of least astonishment
[11:53:03] <alexeymelnikov> Make sense
[11:53:26] <cyrus_daboo> So we have a floating alarm. I guess the same problem occurs for floating time events. Its up to the CUA to apply its own default logic for determing the appropriate user timezone and signal the alarm relative to that.
[11:53:42] <bernard.desruisseaux> yes
[11:53:47] <cyrus_daboo> But there is no such things as a timezone configured on a calendar!
[11:53:59] <cyrus_daboo> That is purely a CUA improvisation.
[11:54:05] <pigdog> right
[11:54:06] <bernard.desruisseaux> improvisation!
[11:54:13] <bernard.desruisseaux> Come on!
[11:54:28] <bernard.desruisseaux> Clearly, iCalendar cannot enforce a strong requirement here...
[11:54:28] <pigdog> cyrus is correct, tho
[11:54:34] <bernard.desruisseaux> we can only specify a best practice...
[11:54:35] <cyrus_daboo> My CUA does not have a timezone on a calendar.
[11:54:50] <bernard.desruisseaux> Your CUA doesn't support CalDAV?
[11:55:08] <bernard.desruisseaux> Remember. Calendar collections in CalDAV do have a CALDAV:calendar-timezone property.
[11:55:14] <cyrus_daboo> The key timezone for a CUA is likely the machine's system timezone as that determines what the current time is for the current user. How they have chosen to display their calendar is anotrher matter.
[11:55:15] <pigdog> but, cyrus, the user does configure the current tz for your application
[11:55:26] <cyrus_daboo> That property is optional.
[11:55:36] <bernard.desruisseaux> Fine.
[11:55:40] <bernard.desruisseaux> Read the proposal!
[11:55:49] <pigdog> its default is the device tz. that should be sufficient, right?
[11:56:07] <bernard.desruisseaux> And proposal an alternative ( I can think of a better one myself already!)
[11:56:47] <pigdog> ok, we need to wrap up a minute early here, as sadly i have another call coming up.
[11:56:51] <bernard.desruisseaux> 1- consider the tz of the calendar of the user 2- consider the tz of the user (in LDAP for instance) 3- consider the tz of the machine on which the iCalendar application is running 4- fallback to UTC
[11:56:54] <cyrus_daboo> I do not like the term "preferred timezone", I think "actual timezone" or "present timezone" would be better.
[11:57:14] <pigdog> i like "present timezone" . actual seems loaded
[11:57:32] <bernard.desruisseaux> "configured timezone"
[11:57:35] <cyrus_daboo> I think 3 should be at the top.
[11:57:36] <pigdog> even better
[11:57:37] <alexeymelnikov> Present timezone seems Ok with me
[11:57:59] <cyrus_daboo> It may not be configured by the user or CUA though.
[11:58:09] <pigdog> ot
[11:58:19] <pigdog> it's always going to be configured - somehow
[11:58:30] <cyrus_daboo> But I guess "configured" would cover all the first three options you list.
[11:59:01] <cyrus_daboo> So change:
[11:59:03] <cyrus_daboo> the time zone configured on the calendar that contains the event or to-do, or the current user's preferred time zone.
[11:59:05] <cyrus_daboo> to:
[11:59:16] <cyrus_daboo> the user's configured time zone.
[11:59:21] <cyrus_daboo> and leave it at that.
[11:59:37] <pigdog> ok, i have to run. any disagreement with cyrus' text?
[11:59:46] <bernard.desruisseaux> Sounds good.
[11:59:52] <bernard.desruisseaux> There are two options.
[12:00:05] <pigdog> you guys can keep going. have to run. bye
[12:00:07] <bernard.desruisseaux> 1- configured time zone (vague what it is but this is okay) 2- fallback to UTC
[12:00:10] --- pigdog has left
[12:00:36] <cyrus_daboo> Yes.
[12:00:45] <bernard.desruisseaux> Cool. I'll go with that.
[12:00:58] <alexeymelnikov> Fine with me
[12:01:05] <bernard.desruisseaux> Bye!
[12:01:51] <cyrus_daboo> Bye
[12:01:53] --- cyrus_daboo has left
[12:02:21] <alexeymelnikov> Bye
[12:02:52] --- alexeymelnikov has left
[17:21:32] --- bernard.desruisseaux has left: Logged out