[09:55:29] --- pigdog has joined
[09:58:39] --- apn has joined
[09:59:52] --- bernard.desruisseaux has joined
[10:00:03] <bernard.desruisseaux> Hi!
[10:00:04] <pigdog> hi guys
[10:00:08] <apn> Hi!
[10:01:39] <pigdog> we'll wait a few minutes
[10:02:09] --- cyrus_daboo has joined
[10:02:16] <apn> Hi Cyrus
[10:02:18] --- alexeymelnikov has joined
[10:02:19] <cyrus_daboo> Hi
[10:02:24] <bernard.desruisseaux> HI
[10:02:33] <apn> Hi Alexey
[10:02:48] <pigdog> hi all - we'll start at 4:05 today.
[10:03:23] <pigdog> (CET)
[10:03:42] <alexeymelnikov> Hi
[10:03:53] --- cmtalbert has joined
[10:05:11] <pigdog> ok, welcome to today's calsify jabber chat
[10:05:16] <pigdog> agenda bashing:
[10:05:22] <pigdog> propose the following:
[10:05:30] <pigdog> 2445 issue review
[10:05:35] <pigdog> 2446 issue review
[10:05:41] <pigdog> (if we make it that far)
[10:05:58] <pigdog> one request- it looks like the iTIP draft has expired.
[10:06:03] <pigdog> cyrus, can you rexmit?
[10:06:36] <pigdog> i'll restate that in email
[10:06:43] <pigdog> starting with 2445bis...
[10:06:47] <pigdog> a few things -
[10:07:04] <pigdog> there are a few new issues in the tracker. these aren't really new, but old ones that weren't previously tracked
[10:07:08] <cyrus_daboo> I will resubmit over the weekend
[10:07:15] <pigdog> (thanks, cyrus!)
[10:07:29] <pigdog> On to the issues...
[10:07:40] <pigdog> I would like to very briefly review Issue 19
[10:08:01] <pigdog> to remind you, the issue tracker is at http://www.ofcourseimright.com/cgi-bin/roundup/calsify
[10:08:21] <pigdog> i've provided bernard with text for IANA considerations
[10:08:28] <bernard.desruisseaux> Thanks!
[10:08:36] <pigdog> this is based on last week's jabber session
[10:08:48] <pigdog> i've really two questions for the group.
[10:09:02] <pigdog> first, is the METHOD registration properly handled in 2445bis or iTIP?
[10:09:30] <bernard.desruisseaux> The registration procedure needs to be in rfc2445bis.
[10:09:30] <alexeymelnikov> METHOD registration can be deferred to iTIP
[10:09:40] <bernard.desruisseaux> iTIP defines *values* for the METHOD.
[10:09:48] <bernard.desruisseaux> another spec could define other values
[10:10:09] <pigdog> so, bernard is probably going to say that since the ABNF is defined in 2445bis it therefore needs to be in 2445bis. right bernard?
[10:10:09] <alexeymelnikov> I don't have a strong feeling on this
[10:10:38] <bernard.desruisseaux> Right.
[10:10:52] <alexeymelnikov> So 2445bis will define the registry and 2446bis will populate it?
[10:11:00] <bernard.desruisseaux> Yes.
[10:11:04] <alexeymelnikov> Ok
[10:11:08] <pigdog> that works for me.
[10:11:27] <pigdog> so bernard, do you think you can add the subsection or do you need me to do that?
[10:11:38] <bernard.desruisseaux> I should be able to do it.
[10:11:41] <pigdog> ok
[10:11:42] <cyrus_daboo> Actually 2445 does not define the methods (proeprty values) - it just defines the property. So it should define the iana template, and then 2446bis actually does the registrations
[10:12:06] <pigdog> good. i think we have consensus
[10:12:09] <pigdog> ;-)
[10:12:35] <pigdog> otherwise, bernard, would you like to lead us through open issues or shall i?
[10:12:44] <bernard.desruisseaux> I can lead!
[10:12:48] <bernard.desruisseaux> Issue #10
[10:12:52] <pigdog> Issue 10
[10:13:01] <alexeymelnikov> Eliot, some minor IANA related things are missing from the tracker
[10:13:03] <bernard.desruisseaux> We have concensus for VEVENT (please update the tracker)
[10:13:12] <pigdog> agreed
[10:13:29] <bernard.desruisseaux> but we need to discuss the same issues for VTODO, that is, w/ respect to DUE
[10:13:54] <bernard.desruisseaux> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001536.html
[10:14:41] <bernard.desruisseaux> So far Cyrus was in agreement, and Martin seemed to have concerns
[10:15:08] <pigdog> if the behavior here is simply the question of when something is due/overdue, intuition says that when value=date, an issue is said to be due after the last second of the specified date.
[10:16:00] <bernard.desruisseaux> While this may be intuitive, it doesn't work nicely in iCalendar given that DTSTART + DURATION is supposed to give you DUE
[10:16:26] <bernard.desruisseaux> Take the case where DURATION is actually 0 seconds...
[10:16:31] <pigdog> what about your 3rd example?
[10:16:34] <bernard.desruisseaux> You end up with DUE == DTSTART
[10:16:43] <cyrus_daboo> Its a case of "Due by" vs "Due on".
[10:17:15] <cyrus_daboo> We have to define precisely what DUE in 2445 is - clients can present users with "due on" or "due by" options that then adjust the values to match what 2445 says.
[10:17:17] <apn> I don't see a huge difference (speaking intuitively, and as a non-English speaker)
[10:17:44] <pigdog> cyrus, right.
[10:18:34] <pigdog> there isn't much text there now
[10:19:13] <pigdog> and the UI behavior here is key, right?
[10:19:42] <pigdog> anyway, it seems as though text is needed.
[10:20:04] <pigdog> Is the intended text the following:
[10:20:11] <pigdog> > The same way that the DTEND property specifies the non-inclusive end> of events, the DUE property should be handled the same way for to-dos.
[10:20:44] <bernard.desruisseaux> Not exactly. The text change should be more explicit.
[10:21:05] <pigdog> ok. so - text needed, but rough consensus seems to be what you suggest
[10:21:28] <bernard.desruisseaux> I will submit text change to the list.
[10:21:36] <bernard.desruisseaux> Issue 60?
[10:21:44] <pigdog> onward
[10:21:50] <bernard.desruisseaux> We have concensus on issue 60, but it's not clear whether any text change is required...
[10:23:48] --- pigdog has left: Replaced by new connection
[10:23:59] --- pigdog has joined
[10:24:19] <apn> No change then perhaps?
[10:24:31] <pigdog> sorry- i dropped
[10:24:38] <pigdog> just a sec
[10:24:42] <cyrus_daboo> We should not touch the issue of multi-lingual icalendar data here. That issue was discussed at the Calconnect RT earlier this month and it was clear it was a complex problem. 2445 should steer away from it - extensions/guidlines can be written later to show how to do it if needed.
[10:25:07] <pigdog> so - you're proposing no text changes for now, cyrus?
[10:26:01] <cyrus_daboo> Well, I am actually tempted to even pull the multi-lingual examples in the current LOCATIOn property definition.
[10:26:23] <bernard.desruisseaux> Would we want to clarify that if multiple DESCRIPTION properties are specified in a VJOURNAL with different LANGUAGE parameter values, then they should be treated as different DESCRIPTION values and not necessarily as translations of one another...?
[10:26:44] <cyrus_daboo> Just state that LANGUAGE indicates the language used for the text of a property which may or may not correspond to the outer Content-Language in a MIME component.
[10:26:58] <pigdog> that sounds good
[10:27:26] <cyrus_daboo> No Bernard - do no go there. Apart from anything else we should not be defining new bahavior for VJOURNAL given that it is little used.
[10:28:07] <pigdog> is there objection to cyrus' proposal?
[10:28:38] <bernard.desruisseaux> Cyrus: The examples for LOCATION don't need to be changed. The misleading example for LANGUAGE has been removed.
[10:29:05] <bernard.desruisseaux> What Cyrus is saying is already in the draft I believe.
[10:29:16] <alexeymelnikov> So, will we be able to have multiple Descriptions which are not translations of each other?
[10:29:21] <bernard.desruisseaux> > For transport in a MIME entity, the Content-Language header field can be used to set the default language for the entire body part. Otherwise, no default language is assumed.
[10:29:37] <cyrus_daboo> Yes I see - fixed in bis - that is good.
[10:29:49] <pigdog> ok, then this issue is done, right?
[10:29:53] <bernard.desruisseaux> Cyrus: That was in RFC 2445.
[10:30:09] <bernard.desruisseaux> Cyrus: Sorry...you must be talking about the examples! :-)
[10:30:38] <bernard.desruisseaux> Conclusion: No text change?
[10:30:45] <pigdog> others?
[10:31:36] <pigdog> ping
[10:31:49] <apn> Sounds good.
[10:31:54] <cyrus_daboo> Hang on - the definition for LANGUAGE says it is used for property values or parameters. But you can only have one LANGUAGE so it affects ALL text values in a property - i.e. all of the properties and the values. There is no way to be selective.
[10:32:29] <pigdog> are there circumstances where this is a real problem?
[10:33:31] <cyrus_daboo> I think it should state that it affects "the property value (if text) and all text -based property parameter values together".
[10:34:23] <pigdog> I can't parse that myself
[10:34:44] <bernard.desruisseaux> BTW, this is issue 35.
[10:35:41] <cyrus_daboo> I propose changing:
[10:35:43] <cyrus_daboo> This parameter identifies the language of the text in the property or property parameter value.
[10:35:45] <cyrus_daboo> to
[10:36:13] <cyrus_daboo> This parameter identifies the language of the text in the property value and all property parameter values in the corresponding property.
[10:36:44] <bernard.desruisseaux> I don't mind.
[10:36:45] <pigdog> so - only one language tag per property?
[10:36:54] <alexeymelnikov> BTW, RFC 1766 got obsoleted by RFC 4646
[10:37:04] <pigdog> that's noted in the draft
[10:37:07] <bernard.desruisseaux> Yes! Can't have two LANGUAGE parameter on the same property..
[10:37:15] <cyrus_daboo> Yes - there can only be one per property and it affects everything that is text in that property.
[10:37:22] <pigdog> can we simply say that?
[10:37:22] <bernard.desruisseaux> Alexey: Yep. Fixed already.
[10:37:40] <pigdog> it's plainer english
[10:37:49] <alexeymelnikov> One language per property and all parameters is good with me
[10:38:09] <pigdog> bernard, can you construct an appropriate sentence out of
[10:38:13] <bernard.desruisseaux> Is there any parameter that can be specified more than once?
[10:38:41] <pigdog> uh... no, right?
[10:38:51] <cyrus_daboo> The problem would be if a property allowed two different text parameters and someone wanted to use different languages for each, for some reason...
[10:38:54] <bernard.desruisseaux> We should probably have one statement on this... and not specify this restriction all over the place...
[10:39:19] <bernard.desruisseaux> Cyrus: If, if, if, ...
[10:39:20] <pigdog> so state it in the LANGUAGE text... of which there is little
[10:39:26] <alexeymelnikov> I suggest we follow the KISS principal on this
[10:39:42] <alexeymelnikov> I.e. just one language.
[10:40:12] <pigdog> it looks to me like a one word change
[10:40:27] <pigdog> well not quite
[10:40:40] <pigdog> "This parameter identifies the language of all text in a given property"
[10:40:44] <pigdog> how's that?"
[10:41:00] <bernard.desruisseaux> I liked Cyrus' proposal better.
[10:41:03] <cyrus_daboo> I am just saying we need to be explicit that LANGUAGE affects everything in a property. At the moment one can read it as affect the value or the parameter separately - which admittedly does not make sense.
[10:41:21] <bernard.desruisseaux> It is an "and" not an "or".
[10:41:32] <pigdog> right
[10:41:40] <alexeymelnikov> Cyrus: +1
[10:41:44] <pigdog> we got it. bernard to make appropriate change. moving on?
[10:41:56] <bernard.desruisseaux> Although, in the cases where the property is not of TEXT value type... LANGUAGE does not apply to the property value....
[10:42:14] <bernard.desruisseaux> Yes. I'll change the text to Cyrus's proposal right away.
[10:42:46] <bernard.desruisseaux> Issue 75 Section 4.6.5 Time Zone Component: DATE-TIME form required for RDATE http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001490.html http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue75
[10:43:32] <bernard.desruisseaux> There are 3 proposed text changes here.
[10:44:09] <pigdog> the second change is an editorial correction, right?
[10:44:52] <pigdog> well the one at the bottom...
[10:45:24] <pigdog> objections?
[10:45:57] <cyrus_daboo> I am Ok with all changes.
[10:46:32] <pigdog> moving on.
[10:47:14] <pigdog> 76?
[10:47:18] <alexeymelnikov> I am fine with the changes as well
[10:47:25] <pigdog> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue76
[10:47:53] <pigdog> please note the heading of this issue is Section 4.8.2.2 Date/Time End: DTEND MUST have same value type as DTSTART
[10:48:02] <pigdog> (the text is the same in the next issue, as i recall)
[10:48:03] --- bdesruisseaux has joined
[10:48:25] <pigdog> hi again, bernard. you've managed to close an issue without being present ;-)
[10:48:33] <bdesruisseaux> :-)
[10:48:41] <pigdog> Issue 76?
[10:48:48] <alexeymelnikov> Does Bernard get 2 voices now ? :-)
[10:49:07] <pigdog> i hope he doesn't disagree with himself too often ;-)
[10:49:15] --- bernard.desruisseaux has left
[10:49:21] <pigdog> and now he has none
[10:49:23] <pigdog> hmmm
[10:49:31] <bdesruisseaux> I'm still here
[10:49:36] <pigdog> oh - ok
[10:49:39] <pigdog> so, 76?
[10:50:22] <bdesruisseaux> The value type of DTSTART / DTEND and DTSTART / DUE MUST match...
[10:50:33] <pigdog> this seems like a no brainer...
[10:50:46] <alexeymelnikov> I agree
[10:50:52] <pigdog> cyrus?
[10:51:01] <cyrus_daboo> Yes.
[10:51:02] --- reinhold has joined
[10:51:03] <bdesruisseaux> That's inline with the clarification with did for the UNTIL rule part.
[10:51:14] <bdesruisseaux> Hi Reinhold!
[10:51:25] <pigdog> hi reinhold!
[10:51:26] <reinhold> Hi Everyone!
[10:51:30] <pigdog> moving on to issue 77
[10:51:37] <cyrus_daboo> What about DTSTART/DURATION? If DTSTART is VALUE=DATA does it make sense to allow a duration that involves hours/minutes/seconds?
[10:51:50] <cyrus_daboo> s/VALUE=DATA/VALUE=DATE/
[10:52:21] <bdesruisseaux> Cyrus: Right. I think we clarified this... hold on
[10:52:32] <pigdog> can a VEVENT have a DURATION of P1D that starts at noon?
[10:52:47] <bdesruisseaux> Issue 57
[10:52:58] <cyrus_daboo> Yes - you can use weeks/days with a DTSTART VALUE=DATE-TIME.
[10:53:31] <bdesruisseaux> Cyrus: Here's the change that was made for issue 57 http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-05.changes.html#rfc.change.#issue57+4.6.1_duration_restriction.1
[10:54:04] <bdesruisseaux> Mind you we should also write something for VTODO etc...
[10:54:45] <bdesruisseaux> I'll add something in the DURATION section related to issue 57.
[10:55:02] <cyrus_daboo> Good.
[10:55:39] <bdesruisseaux> Ok. Issue 77 was the same as 76 but for VTODO...
[10:56:42] <pigdog> this also seems sort of obvious. what's the trick?
[10:57:41] <reinhold> About issue 77: One of the original authors of rfc 2445 (I think it was D. Stenerson) said in a mail to the ietf-calendar mailing list a long while ago that -- although never explicitly mentioned in the rfc -- the date/time types were always assumed to be consistent (i.e. either all DATE-TIME or all DATE). I suppose this also goes for VTODO, so we just need to insert that missing sentence.
[10:58:12] <pigdog> so that's consistent with what bernard wrote.
[10:58:36] <pigdog> any objections to accepting bernard's recommendation?
[10:58:39] <reinhold> Nope.
[10:58:46] <alexeymelnikov> No
[10:59:04] <pigdog> moving on
[10:59:15] <bdesruisseaux> I'll need to clarify this recommended practice as well: 3. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for "VTODO" calendar components, have the same value data type (e.g., DATE-TIME), they SHOULD specify values in the same time format (e.g., UTC time format).
[10:59:58] <apn> I have to run.
[11:00:04] <pigdog> bye aki!
[11:00:08] <apn> Good job everyone! Bye!
[11:00:15] --- apn has left
[11:00:16] <pigdog> so that text needs to change, right?
[11:00:20] <bdesruisseaux> "When ... have the same value data types." and then you ask yourself aren't they required to have the same value data type... We wil make that clear now. And I'll change the text.
[11:00:27] <bdesruisseaux> Yes.
[11:00:28] <reinhold> The only case where date/time types might not match are RDATE and EXDATE (that was agreed long ago on the calendar mailing list, I sent the link to the summary of that discussion to calsify a while ago). EXDATE with DATE would exclude all occurences on that day. RDATE would inherit the time from DTSTART.
[11:00:37] <cyrus_daboo> What about ALARMS? e.g. TRIGGER?
[11:01:10] <cyrus_daboo> If DTSTART in the enclosing eventy is VALUE=DATE, then TRIGGER should only be "dur-day" or "dur-week" too, right?
[11:01:39] <pigdog> seems reasonable.
[11:01:39] <reinhold> I think we might add an additional sentence, when the SHOULD can be violated (e.g. for flights or other events that cross time zone boundaries).
[11:01:51] <cyrus_daboo> Oh - actually there is text in TRIGGER that contradicts that...
[11:02:44] <bdesruisseaux> Reinhold: The SHOULD has been removed with issue 65.
[11:02:46] <cyrus_daboo> Its actually wrong! It says you use 00:00:00 UTC as the point from which the trigger is used if DTSTART has VALUE=DATE.
[11:03:19] <reinhold> BTW, why do we have dur-week at all?
[11:03:58] <bdesruisseaux> Cyrus: This is issue 47.
[11:04:02] <pigdog> i think we covered that ground elsewhere.
[11:04:03] <pigdog> right
[11:04:55] <bdesruisseaux> Reinhold: I guess you could book a meeting for P1W to block your calendar for a 1 week vacatino...
[11:05:34] <cyrus_daboo> Issue 47: lets resolve that.
[11:05:35] <reinhold> bdesruisseaux: But what's the difference to P7D?
[11:06:02] <pigdog> yes, my memory was that DATE was a floating value
[11:06:14] <pigdog> and hence based on the calendar's localtime()
[11:06:18] <cyrus_daboo> P1W == P7D, but P1D != PT24H all the time.
[11:06:25] <pigdog> which conflicts with the text currently in the draft
[11:06:49] <pigdog> am i wrong?
[11:07:00] <reinhold> Yes, it doesn't make sense to use 0:00 UTC for the alarm. That alarm will either trigger long before that date or some time until noon.
[11:07:31] <pigdog> right - references to UTC in the draft need to be scrutinized
[11:07:31] <bdesruisseaux> Which conflict?
[11:07:43] <cyrus_daboo> The trouble is you do not know what "localtime" is as there is no TZID on the DTSTART proeprty.
[11:07:58] <pigdog> of the current draft, page 69 in the description of TRIGGER
[11:08:36] <bdesruisseaux> Hold on.. What is the issue with issue 47>
[11:08:44] <bdesruisseaux> It is closed!
[11:08:47] <pigdog> the consensus was not well documented
[11:08:55] <bdesruisseaux> Humm...
[11:08:56] <cyrus_daboo> Remember a VALUE=DATE is really a "floating" time event as the actual time it is "active" depends on the user's current localtime - which is not soemthing iCalendar has knowledge of - though the client ought to.
[11:09:12] <pigdog> cyrus: +1
[11:09:35] <pigdog> bernard, disagree?
[11:09:44] <pigdog> reinhold, this restates your position, i believe
[11:09:51] <bdesruisseaux> In a Jabber session we agreed to clarify that it was relative to 00:00:00 of the "user's configured time zone"
[11:10:00] <pigdog> right so we all agree
[11:10:06] <pigdog> the problem is that the draft does not
[11:10:18] <cyrus_daboo> And how do we define "configured timezone"?
[11:10:29] <bdesruisseaux> We don't!
[11:10:36] <cyrus_daboo> Well boo!
[11:10:47] <pigdog> where dow e disagree/
[11:11:12] <bdesruisseaux> Here's the text that will be in draft -06: Alarms specified in an event or to-do which is defined in terms of a DATE value type will be triggered relative to 00:00:00 of the user's configured time zone on the specified date, or relative to 00:00:00 UTC on the specified date if no configured time zone can be found for the user. For example, if "DTSTART" is a DATE value set to 19980205 then the duration trigger will be relative to 19980205T000000 America/New_York for a user configured with the America/New_York time zone.
[11:12:08] <pigdog> that's note the problem
[11:12:11] <pigdog> the problem is here:
[11:12:26] <pigdog> The "TRIGGER" property value type can alternatively be set to an absolute calendar date with UTC time.
[11:13:01] <pigdog> sorry s/note/not/
[11:13:39] <bdesruisseaux> What is the problem with TRIGGER if it is a DATE-TIME in UTC ?
[11:13:40] <reinhold> Same solution.
[11:13:53] <reinhold> 0:00 local time on that day.
[11:14:06] <bdesruisseaux> There is no ambuiguity about the trigger time... sorry I don't get it...
[11:14:31] <cyrus_daboo> There is no problem with VALUE=DATE-TIME, the problem is VALUE=DURATIOn on TRIGGER.
[11:14:44] <cyrus_daboo> i.e. trigrel.
[11:15:10] <reinhold> Ah, sorry, we don't allow DATE triggers anyway.
[11:15:41] <bdesruisseaux> Can someone summarize the issue?
[11:15:45] <cyrus_daboo> If we restrict trigrel to "dur-day" and "dur-week" when DTSTART is VALUE=DATE we are done.
[11:16:18] <bdesruisseaux> Too restrictive
[11:16:25] <cyrus_daboo> The problem is what is TRIGGER relative to when the enclosing VEVENT as a DTSTART with VALUE=DATE?
[11:16:43] <bdesruisseaux> Whatever midnight is for the user...
[11:17:08] <bdesruisseaux> A client should know the time zone of the user and display the information properly...
[11:17:16] <pigdog> fine but then the text seems to imply that it is midnight UTC or am i misreading it?
[11:17:23] <bdesruisseaux> A CalDAV server will be able to rely on the time zone configured on the calendar collection
[11:17:28] <cyrus_daboo> That may not be known. Falling back to UTC is not right either. Applying my proposed restriction removes any ambiguity.
[11:17:43] <cyrus_daboo> A CalDAV server does not handle alarms.
[11:17:47] <bdesruisseaux> Eliot: RFC 2445 says it MUST be UTC... in rfc2445bis we clarified this.
[11:18:30] <bdesruisseaux> Cyrus: You are removing existing functionality
[11:18:51] <cyrus_daboo> bis currently states:
[11:18:52] <cyrus_daboo> Alarms specified in an event or to-do which is defined in terms of a DATE value type will be triggered relative to 00:00:00 UTC on the specified date. For example, if "DTSTART" is a DATE value set to 19980205 then the duration trigger will be relative to 19980205T000000Z.
[11:19:04] <bdesruisseaux> Cyrus: A CalDAV server "implementation" might decide to process the ACTION:EMAIL VALARMs...
[11:19:24] <cyrus_daboo> It is functionality that is not well defined.
[11:19:50] <bdesruisseaux> It is clarified in MY copy ! The text I pasted at 11:11:05 here
[11:19:53] <cyrus_daboo> Actually it is well defined but it is not what a user would expect (the UTC requirement that is).
[11:20:14] <pigdog> right
[11:20:56] <cyrus_daboo> "Configured timezone" is not well defined. In spite of what you wrote.
[11:21:42] <bdesruisseaux> Cyrus: This was your proposal: http://www3.ietf.org/meetings/ietf-logs/calsify/2006-12-12.html [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:21:44] <pigdog> i guess i find the text you pasted good enough
[11:21:51] <cyrus_daboo> I have an "actual" timezone that may be different from the timezone "configured" for a calendar. Its my "actual" timezone that counts.
[11:22:08] <cyrus_daboo> Well I don't like what I proposed now!
[11:22:17] <bdesruisseaux> Sigh!
[11:22:30] <cyrus_daboo> Unless we explicitly define the concept of "configured" or "actual" timezone somewhere
[11:22:46] <alexeymelnikov> Guys, it is very exciting to watch you argue in Jabber, but I need to go
[11:22:59] <pigdog> i was confused elsewhere. cyrus, why is this not an implementation issue for you?
[11:23:05] <pigdog> bye alexey!
[11:23:08] --- alexeymelnikov has left
[11:23:09] <bdesruisseaux> Bye Alexey!
[11:23:59] <cyrus_daboo> Because I don't want two different devices giving me alarms at two different times because each implementor choose to interpret things differently.
[11:24:48] <pigdog> but does the issue arise because it might be possible in an implementation to specify the current timezone separately from what the underlying o/s says?
[11:25:28] <bdesruisseaux> The clarified text makes it clear that you can end up with different time with different clients...
[11:25:35] <bdesruisseaux> If you don't want that... use absolute time...
[11:25:47] <cyrus_daboo> We cannot start talking about the "timezone of the underlying OS" etc. iCalendar does not care. Clients do care.
[11:26:24] <cyrus_daboo> Lets go further then: state that "dur-day" and "dur-week" are "well defined", but other dur- values are implemtation defined.
[11:26:39] <pigdog> when you say "Clients", i'm not sure what you're referring to?
[11:26:46] <cyrus_daboo> i.e. we do not rule out the other ones, but make it clear you should try and stick to the ones we know will interoperate.
[11:26:49] <bdesruisseaux> Cyrus: Still this is not true either.
[11:27:13] <bdesruisseaux> If the DTSTART is a date... which midnight is it?
[11:27:24] <reinhold> cyrus_daboo: I would agree with you: Let's not rule trigrel out for DATE events, but make it clear that the results are undefined and might vary with the implementation.
[11:27:44] <bdesruisseaux> Two clients may pick a different midnight... and the the alamar will trigger at different times eventhough it was specified as a dur-day...
[11:28:35] <pigdog> does a client not have a notion of a configured timezone? how is that ambiguous?
[11:29:01] <pigdog> ok, we clearly haven't closed on this issue, but we have run out of time.
[11:29:18] <pigdog> bernard, can you update the draft in as far as we closed on the other issues?
[11:29:28] <bdesruisseaux> Eliot, I'm about to submit draft -06. I will go ahead with wath I have for now.
[11:29:36] <reinhold> pigdog: How about clients that allow multiple timezones.
[11:29:42] <cyrus_daboo> But day/week relative offsets are floating so yes you will then be subject to the usual floating rules. The problem is trying to turn a floating time (the DTSTART VALUE=DATE on the VEVENT) into a fixed (not floating) time via the TRIGGER.
[11:30:19] <bdesruisseaux> Eliot: Send an update to the list with the issues on which concensus has been reached today, and I'll update the draft and submit draft -06 soon.
[11:30:26] <pigdog> cyrus, can i ask that you provide some discussion on the mailing list on that very point?
[11:30:29] <pigdog> bernard, will do
[11:30:40] <pigdog> please keep in mind the deadline
[11:30:53] <bdesruisseaux> ok
[11:31:05] <cyrus_daboo> Clients usually have the concept of a "display timezone" which is used to show floating events relative to that. I'm not sure whether they also use that as the "alarm trigger" timezone - or whether that comes from the OS.
[11:31:33] <pigdog> cyrus, that helps.
[11:31:38] <cyrus_daboo> OK, lets re-visit this next week if I am still unhappy and argumentative!
[11:31:44] <bdesruisseaux> NO!
[11:31:49] <bdesruisseaux> Bring this to the list!
[11:32:03] <pigdog> please. let's see what we can close between now and next week!
[11:32:07] <cyrus_daboo> Ok, I will draft a message
[11:32:10] <pigdog> all the best!
[11:32:12] <bdesruisseaux> If we include the jabber of Dec 12 2006 we must have chatted 45 mintes about this issue...
[11:32:21] <cyrus_daboo> bye
[11:32:26] <bdesruisseaux> Thanks!
[11:32:27] <bdesruisseaux> Bye!
[11:32:30] --- pigdog has left
[11:32:48] --- cyrus_daboo has left
[11:33:30] --- bdesruisseaux has left
[11:34:20] --- reinhold has left
[11:46:29] --- cmtalbert has left