[09:50:19] --- bernard.desruisseaux has joined
[10:32:46] --- pigdog has joined
[10:32:55] <pigdog> good morning bernard
[10:33:07] <pigdog> we will begin in 27 minutes
[10:36:35] --- pigdog has left
[10:49:57] --- pigdog has joined
[10:55:19] <bernard.desruisseaux> http://www.geocities.com/bdesruisseaux/calsify/draft-ietf-calsify-rfc2445bis-02.html
[10:55:28] <bernard.desruisseaux> Test
[10:56:38] <pigdog> ping
[10:56:49] <pigdog> ok, i'm looking at -02
[10:57:00] <pigdog> we'll start in about 5 minutes. hopefully with others
[10:59:34] --- alexeymelnikov has joined
[10:59:39] <pigdog> howdy alexey
[10:59:53] <alexeymelnikov> Hello.
[11:00:03] <alexeymelnikov> Is it you Eliot?
[11:00:08] <pigdog> yes
[11:00:15] <alexeymelnikov> Why "pigdog"?
[11:00:22] <pigdog> guaranteed not to be used
[11:00:26] <pigdog> ;-)
[11:00:27] <alexeymelnikov> :-)
[11:00:48] <pigdog> the issue tracker can be found at http://www.ofcourseimright.com/cgi-bin/roundup/calsify
[11:01:12] <pigdog> we will go issue by issue on issues that are not marked either "Consensus" or Resolved
[11:01:54] <pigdog> the first issue will be Issue 3
[11:02:04] <pigdog> http://lists.osafoundation.org/pipermail/ietf-calsify/2006-May/000964.htmlpage 14 NON-US-ASCII = %x80-F8 ; Use restricted by charset parameter ; on outer MIME object (UTF-8 preferred)SHOULD :-) be moved to the next page and appear somewhere after QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII ; Any character except CTLs and DQUOTEpage 17 (paragraph 1) Inline binary contact SHOULD only be used in applications whose special circumstances demand that an iCalendar object be expressed as a single entity.should be changed to Inline binary content SHOULD only be used in applications whose special circumstances demand that an iCalendar object be expressed as a single entity.->inline binary contentpage 21 (paragraph 1): This parameter specifies those calendar uses that have delegated their participation in a group scheduled event or to-do to the calendar user specified by the property.should be changed to: This parameter specifies those calendar users that have delegated their participation in a group scheduled e
[11:02:28] <pigdog> i probably won't blat that all into the log again
[11:02:34] <pigdog> just by reference
[11:03:07] <pigdog> Bernard, do you have any objections to this text, or is it already incorporated?
[11:03:09] <bernard.desruisseaux> Issue 3: There are 3 issues here. I already addressed the 2nd and 3rd. I don't understand the 1st one. I sent a private email to Oliver yesterday to get clarification.
[11:04:08] <bernard.desruisseaux> See: http://www.geocities.com/bdesruisseaux/calsify/draft-ietf-calsify-rfc2445bis-02.html?20063#rfc.issue.#issue03+4.1.3_content_typo http://www.geocities.com/bdesruisseaux/calsify/draft-ietf-calsify-rfc2445bis-02.html?20063#rfc.issue.#issue03+4.2.4_users_typo
[11:04:20] <pigdog> ok, i've updated the issue. and since he's in the system, i've assigned the issue to him ;-)
[11:04:58] <pigdog> the next issue is Issue 5
[11:05:06] <pigdog> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue5
[11:05:43] <pigdog> there is proposed text.
[11:06:12] <bernard.desruisseaux> Issue 5: We need to consider issue 25 at the same time.
[11:06:58] <pigdog> cyrus was to propose text. he can't make it for this call
[11:07:02] <pigdog> i agree that they're linked
[11:07:28] <pigdog> let me update issue 5, and ping cyrus about that
[11:08:19] <pigdog> ok, cyrus now owns both
[11:09:39] <pigdog> sorry- one moment
[11:10:33] <pigdog> Issue 8. Decprecate P1D or P24H?
[11:10:41] --- Aki has joined
[11:11:02] <pigdog> this issue does NOT have specific text
[11:11:14] <Aki> Sorry I'm late -- had networking trouble...
[11:11:17] <bernard.desruisseaux> Issue 8: I don't see any reason to deprecate P1D or P24H.
[11:11:47] <pigdog> any other comments?
[11:12:22] <pigdog> ok, thus far no support for moving forward
[11:12:42] <pigdog> I'm going to propose to close unless someone makes a really good argument in the next week
[11:13:22] <alexeymelnikov> I would like to see useful examples for the issue # 8
[11:13:41] <pigdog> ok... moving on,
[11:13:54] <pigdog> Issue 9: Recurring Events: Start/End Time
[11:13:58] <bernard.desruisseaux> The question really is: Is there a difference between 24 hours and 1 day... or between 60 seconds and 1 minute.
[11:14:01] <pigdog> this is beginning to sound like a recurring theme
[11:14:18] <pigdog> right, and what does it matter if you can express both?
[11:15:22] <bernard.desruisseaux> (still on issue 8) in the case of a time zone shift a day can have 23 or 25 hours... and in the case of a leap seconds a minute could have 59 seconds (in the case of a negative leap second (this never happened), or 61 second in the case of positive leap second (happened a couple time since 1972).
[11:15:59] <pigdog> fair point
[11:16:24] <Aki> I tried to make sense of the related threads of issue8. It boils down to what it means to add 1D vs add 24 hours. With DST, they're different - it's more which is added first. There seemed to be some consensus, but I got stuck since I wasn't able to see Doug's posts (due to S/MIME).
[11:16:33] <bernard.desruisseaux> We have the same situation with DTEND versus DURATION.
[11:16:50] <pigdog> ok, which seems like the next issue ;-)
[11:17:02] <Aki> Yup. They're related...
[11:17:33] <pigdog> so.. any support for Issue 9?
[11:17:35] <pigdog> discussion?
[11:18:07] --- lisadusseault has joined
[11:18:14] <pigdog> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue9
[11:18:43] <bernard.desruisseaux> I believe issue 9 is a duplicate of issue 27.
[11:19:31] <pigdog> that one's owned by cyrus
[11:19:40] <pigdog> i agree they're dups
[11:20:26] <pigdog> Issue 10
[11:20:31] <pigdog> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue10
[11:20:39] <bernard.desruisseaux> Hold on!
[11:20:51] <bernard.desruisseaux> Did you close either 9 or 27 ?
[11:20:53] <pigdog> holding
[11:21:24] <pigdog> i closed issue 9 in favor of 27
[11:21:29] <bernard.desruisseaux> thanks
[11:21:34] <pigdog> ok
[11:21:38] <pigdog> 10?
[11:22:24] <bernard.desruisseaux> Issue 10: I remember working on some text with Chris Stoner on this one... I'll try to dig it.
[11:22:38] <pigdog> now or later?
[11:22:43] <bernard.desruisseaux> The end date or end date-time is always non-inclusive.
[11:23:18] <pigdog> i agree or you have weird overlaps
[11:23:18] <bernard.desruisseaux> A 1 day event that start today would be specified with: DTSTART;VALUE=DATE:20061002 DTEND;VALUE=DATE:20061003
[11:23:44] <bernard.desruisseaux> In the case where DTSTART == DTEND than the component would last 0 second.
[11:23:51] <pigdog> right
[11:24:38] <pigdog> so you have text, but probably not what rh is looking for
[11:25:16] <pigdog> ok, so we are going to mark this as open, and that you will provide text
[11:25:26] <bernard.desruisseaux> Yes.
[11:26:03] <pigdog> ok, so marked.
[11:26:13] <pigdog> Issue 11
[11:26:20] <pigdog> http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11
[11:27:17] <pigdog> some of these examples are of the form "MUST NOT GENERATE / MUST IGNORE"
[11:27:31] <pigdog> like RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2
[11:28:30] <pigdog> i'm looking at http://www.imc.org/ietf-calendar/mail-archive/msg06787.html
[11:29:23] <pigdog> comments?
[11:29:35] <pigdog> it's not clear what text to add
[11:30:30] <pigdog> anyone still there?
[11:30:45] <lisadusseault> You could add text along the lines of "BYDAY" is always with reference to the frequency period...
[11:30:48] <lisadusseault> (hello)
[11:30:58] <pigdog> thanks... thought i had a technical problem there ;-)
[11:31:20] <alexeymelnikov> [I am still there, I just don't have an opinion in this case]
[11:31:42] <bernard.desruisseaux> Still here... and I think I disagree with Lisa!
[11:31:44] <bernard.desruisseaux> Hi Lisa!
[11:32:00] <pigdog> that would be very unambiguous tho
[11:32:26] <lisadusseault> I had hoped, looking at ways to simplify, that BYDAY was always with reference to the month. But there are examples like "the first monday of the year" or "last day of the year" that we might choose not to simplify out of the syntax.
[11:32:54] <lisadusseault> I'm not very firm on this stuff Bernard so you should say what you think :)
[11:32:54] <pigdog> bernard, what is your disagreement?
[11:33:03] <bernard.desruisseaux> Check: http://www.geocities.com/bdesruisseaux/calsify/draft-ietf-calsify-rfc2445bis-02.html#VALUE.RECUR
[11:33:21] <bernard.desruisseaux> Near the end of the Description.
[11:33:40] <bernard.desruisseaux> DTSTART;TZID=US-Eastern:19970105T083000 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; BYMINUTE=30 First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive at "every other year". Then, "BYMONTH=1" would be applied to arrive at "every January, every other year". Then, "BYDAY=SU" would be applied to arrive at "every Sunday in January, every other year".
[11:33:52] <lisadusseault> "Each BYDAY value can also be preceded by a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific day within the MONTHLY or YEARLY RRULE. For example, within a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday within the month, whereas -1MO represents the last Monday of the month. If an integer modifier is not present, it means all days of this type within the specified frequency. For example, within a MONTHLY rule, MO represents all Mondays within the month."
[11:34:58] <lisadusseault> I wouldn't care if that particular rule became impossible to generate :)
[11:35:05] <pigdog> so BY* operates on the previous portion of the rule?
[11:35:11] --- thnetila has joined
[11:35:11] <lisadusseault> ick ordering!
[11:35:30] <pigdog> a little ordering wouldn't hurt this standard were we to have started from scratch
[11:35:31] --- thnetila has left
[11:35:50] <lisadusseault> yes, as long as the ordering were fixed.
[11:35:58] <pigdog> right
[11:36:03] --- thnetila has joined
[11:36:12] <pigdog> but there is an order in the text
[11:36:38] <pigdog> "f multiple BYxxx rule parts are specified, then after evaluating the specified FREQ and INTERVAL rule parts, the BYxxx rule parts are applied to the current set of evaluated occurrences in the following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated."
[11:37:08] <lisadusseault> If we always had BYMONTH before BYDAY and FREQ before BYMONTH, then saying that BYDAY operates on the previous portion of the rule might nearly work (forgetting for a second about interval)
[11:37:32] <pigdog> but isn't that what the text says?
[11:37:40] <lisadusseault> With FREQ=YEARLY;INTERVAL=3;BYDAY=1MO would that mean the first monday of every quarter? :)
[11:37:49] <lisadusseault> sorry, it may be what the text says. Oops.
[11:38:24] <pigdog> Ok, we've gone way down here
[11:38:28] <pigdog> let's see if we can "uplevel"
[11:38:58] <pigdog> going back to rh's message http://www.imc.org/ietf-calendar/mail-archive/msg06787.html
[11:38:59] <bernard.desruisseaux> Lisa: 1st monday of the year, every 3rd year
[11:39:13] <pigdog> bernard: right
[11:39:23] <lisadusseault> right, because there's not a bymonth.
[11:39:23] --- alexeymelnikov has left: Lost connection
[11:39:23] --- Aki has left: Lost connection
[11:39:44] <pigdog> so let's just see if we can sift through his cases and make sure they're unambiguous
[11:39:45] <pigdog> RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2
[11:39:58] <pigdog> first, is that legal?
[11:40:12] <bernard.desruisseaux> I don't see why not
[11:40:23] <pigdog> second, based on the text we would evaluate BYMONTH before BYDAY, right?
[11:40:44] <pigdog> so that is the 5th sunday of February
[11:40:56] <pigdog> (i think that *is* possible on a particular leap year)
[11:41:11] <pigdog> correct?
[11:41:18] --- thnetila has left
[11:41:56] <pigdog> so this event would only occur on leap years where there is a 5th sunday ;-)
[11:42:00] --- thnetila has joined
[11:42:15] <pigdog> right?
[11:42:19] <pigdog> next
[11:42:28] <pigdog> RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2,7
[11:43:20] <pigdog> this would be the 5th sunday of Feb (as above) plus July (more likely)
[11:43:22] <pigdog> right?
[11:44:10] <pigdog> it's his next one that's the zinger.
[11:44:11] <pigdog> RRULE:FREQ=YEARLY;BYWEEKNO=4;BYDAY=5SU
[11:44:27] <pigdog> which seems to me a case of "doctor it hurts when i do this"
[11:44:29] <lisadusseault> indeed
[11:44:48] <pigdog> i wonder if some generic text about "don't do this" would be appropriate ;-)
[11:45:00] <pigdog> perhaps even using that specific case as an example
[11:45:22] <bernard.desruisseaux> Hold on...
[11:45:33] <bernard.desruisseaux> Back to: RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2
[11:45:39] <pigdog> ok
[11:45:45] <bernard.desruisseaux> We start with FREQ=YEARLY... once per year...
[11:46:00] <bernard.desruisseaux> then we have BYMONTH=2... that means that everyday in Feb are good...
[11:46:22] <bernard.desruisseaux> but then we have BYDAY=5SU... thus we only keep the days in Feb which are the 5th Sunday.
[11:46:32] <pigdog> right
[11:46:41] <pigdog> with you so far
[11:47:02] <bernard.desruisseaux> The other way to look at it, is BYDAY applies to the FREQ (like Lisa... and the text... both says!)
[11:47:15] <bernard.desruisseaux> So you would have FREQ=YEARLY ... once per year...
[11:47:36] --- oliver88 has joined
[11:47:37] <bernard.desruisseaux> then BYDAY=5SU ... the fifth Sunday of the year
[11:47:47] <bernard.desruisseaux> which must happen in Feb...
[11:47:49] <bernard.desruisseaux> hummm...
[11:47:57] <pigdog> Just a moment
[11:48:03] <pigdog> the text ALSO says the following:
[11:48:16] <pigdog> If multiple BYxxx rule parts are specified, then after evaluating the specified FREQ and INTERVAL rule parts, the BYxxx rule parts are applied to the current set of evaluated occurrences in the following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated.
[11:48:45] <pigdog> so that implies that order on the line doesn't matter
[11:48:51] <pigdog> does it say that it does somewhere else?
[11:48:55] --- Aki has joined
[11:49:14] <pigdog> for those just joining in the fun, we are on Issue 11
[11:49:20] <pigdog> and we are looking at the following:
[11:49:20] <bernard.desruisseaux> No! The order of the rule parts doesn't matter..
[11:49:25] <pigdog> http://www.geocities.com/bdesruisseaux/calsify/draft-ietf-calsify-rfc2445bis-02.html
[11:49:37] <pigdog> and we are also looking at Reinhold's mail in the issue
[11:49:48] <pigdog> Bernard: right. order of the rule parts doesn't matter.
[11:49:57] <bernard.desruisseaux> See in Description "The rule parts are not ordered in any particular sequence."
[11:50:17] <pigdog> so then the case reinhold is talking about is unambiguous, right?
[11:50:34] <pigdog> (the last one is silly, but still unambiguous)
[11:51:30] <pigdog> actually not just the last one
[11:51:49] <pigdog> there are definitely a few occurrences of "What??" there
[11:52:07] --- alexeymelnikov has joined
[11:52:10] <pigdog> my question is this: what is the ambiguity that needs to be cleared up in RFC2445bis?
[11:53:04] <bernard.desruisseaux> Example: A lot of VTIMEZONE have: RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
[11:53:30] <pigdog> right. last sunday of the 10th month. that's perfectly normal
[11:53:32] <bernard.desruisseaux> We need to clarify that BYDAY means the last Sunday of October ... and not the last SUnday of the year if it is October
[11:53:51] <pigdog> do you want to add that example?
[11:55:42] <bernard.desruisseaux> Well there are already VTIMEZONE examples like that in the draft
[11:55:54] <pigdog> ok, we are running out of time. we will leave this as the last issue. i am currently leaving it with you, Bernard, to perhaps suggest some example text to make it clear which order matters. I think the text is pretty clear, however.
[11:56:26] <bernard.desruisseaux> Just curious... Lisa? Are we in disagreement?
[11:57:06] <bernard.desruisseaux> BTW, I think the text needs to be clarified...
[11:57:28] <pigdog> ok, please send such a clarification to the list.
[11:57:32] <bernard.desruisseaux> Ok.
[11:57:58] <pigdog> thank you all for joining. i would appreciate your feedback as to whether you think this is a good idea. i propose to try one more time.
[11:58:01] <pigdog> (at least)
[11:58:04] <lisadusseault> umm
[11:58:08] <pigdog> same time next week, maybe?
[11:58:26] <lisadusseault> no solid disagreement with me, just wishfulness that it be simpler yet if possible.
[11:58:31] <alexeymelnikov> Ok
[11:58:34] <Aki> works for me
[11:58:46] <pigdog> great. thanks again. we're adjourned.
[11:58:57] --- alexeymelnikov has left
[11:58:58] <bernard.desruisseaux> Eliot, the plan was to submit a new draft first week of October...
[11:59:07] <pigdog> feel free to go ahead and submit
[11:59:10] <bernard.desruisseaux> You want me to proceed with what I have now?
[11:59:13] <pigdog> we may want to do a second one
[11:59:17] <pigdog> your choice
[11:59:35] <pigdog> regards.
[11:59:38] --- pigdog has left
[11:59:42] <bernard.desruisseaux> Bye
[12:00:04] <Aki> bye all
[12:00:11] <lisadusseault> bye
[12:00:11] --- Aki has left
[12:00:19] --- lisadusseault has left
[12:06:05] --- bernard.desruisseaux has left
[12:06:32] --- oliver88 has left
[12:11:11] --- oliver88 has joined
[12:15:29] --- thnetila has left
[13:11:17] --- oliver88 has left