Subject: [Ietf-calsify] summary of jabber sessions and confirmation of issues

From: lear at cisco.com (Eliot Lear)
Date: Wed Oct 11 00:20:30 2006

Dear all,

We are generally enjoying jabber and getting a fair amount of work
done.  This means there will be another jabber session next Tuesday at
5:00pm CEST or 8:00am PDT.

Here is a summary of the past two jabber sessions, relating to open issues:

Issue 3:  clarification requested from Oliver.  OPEN.
Issue 5:  wording agreed.  CONSENSUS.
Issue 8:  no support for change.  CLOSE.
Issue 9:  dup of Issue 27 (which we are already working on) CLOSE.
Issue 10: Bernard will provide text - OPEN.
Issue 11: Lots of chat.  Normative text is accurate, but some clarifying
example is required.  Bernard will propose.  OPEN
Issue 12: Duplicate of issue 11 CLOSE
Issue 13: Related to Issue 25.  Remove "if specified" (however there is
discussion on the list about this) CONSENSUS
Issue 14: Related to Issue 25.  The text is not easily inserted into the
doc, so more text is needed.  OPEN
Issue 16: Example needed.  Cyrus provided a cleaned up version of the
example, but Bernard would like to see more
               text.  This issue remains open.  OPEN
Issue 25: The proposal now is to deprecate EXRULE.  Cyrus to kick off
discussion.  OPEN

Where you see "OPEN|CONSENSUS|CLOSE" these are subject to validation on
this list.

For further clarification as to the discussion, please see the log at
http://www3.ietf.org/meetings/ietf-logs/calsify.  Also, please feel free
to review the issue tracker, which can be found at
http://www.ofcourseimright.com/cgi-bin/roundup/calsify.

Thanks for your support.

Eliot

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Oct 11 08:16:44 2006

I'm really sorry that I'm not able to participate in the (apparently very 
productive) Tuesday jabber sessions, as we have a scientific presentation at 
our department every tuesday from 16:30 until 18:00...

> Issue 5:  wording agreed.  CONSENSUS.

Fine with me.

> Issue 8:  no support for change.  CLOSE.

I'm also opposed to deprecating either P1D or PT24H. However, I propose to 
create an official FAQ that deals with lots of clarifications that come up on 
the mailing list and elsewhere.

E.g.
Q: What is the difference between DURATION:P1D and DURATION:PT24H?
A: In most cases there will not be a difference. The only difference happens 
when a daylight savings time switch occurs in that duration. In particular, 
the following snipplet will generate an event from Oct 28, 12:00 until Oct 
29, 12:00 (same time the next day, even though an additional hour is inserted 
at 03:00 for the switch to winter time):
  DTSTART;TZID=Europe/Vienna:20061028T120000
  DURATION:P1D
while the following snipplet generates an event from Oct 28, 12:00 until Oct 
29, 11:00 (since there is an additional hour at 03:00 on Oct 29)
  DTSTART;TZID=Europe/Vienna:20061028T120000
  DURATION:PT24H

- ----

A different issue is what should happen to the following event, where the end 
time does not exist. When does it end?
  DTSTART;TZID=Europe/Vienna:20060325T023000
  DURATION:P1D
As there is no 02:30 on March 26, 2006, in Europe, what is the end time of 
that event? Similarly for
  DTSTART;TZID=Europe/Vienna:20060325T023000
  DTEND;TZID=Europe/Vienna:20060326T023000
As the DTEND is a non-existing date/time, what should happen to the event?

> Issue 9:  dup of Issue 27 (which we are already working on) CLOSE.

Actually, Issue 9 contains two issues. The first one is a dupe of 27. The 
second is a little wording issue, but that's nitpicking and does not really 
need to be changed. 

- - -) Section 4.3.10 says:
   "If BYxxx rule part values are found which are beyond the available
   scope (ie, BYMONTHDAY=30 in February), they are simply ignored."

The "they" seems to refer to rule part values, which is not true.

E.g. take 
  DTSTART;VALUE=DATE:20060101
  RRULE:FREQ=MONTHLY;MYMONTHDAY=31

In February, the rule part value 31 for BYMONTHDAY is beyond the scope, but 
that value is not ignored (which would result in taking the day from DTSTART, 
thus there would be an occurence on Feb 1), but rather the resulting invalid 
date is ignored.

As I said, that's nitpicking, and I'm fine with closing the issue without any 
changes.

Currently RFC 2445 says:
> For cases where a "VEVENT" calendar component specifies a "DTSTART"
> property with a DATE data type but no "DTEND" property, the events
> non-inclusive end is the end of the calendar date specified by the
> "DTSTART" property.

I propose to change "end of the calendar date" to "begin of the day following 
the calendar date" in the text:

> For cases where a "VEVENT" calendar component specifies a "DTSTART"
> property with a DATE data type but no "DTEND" property, the events
> non-inclusive end is the begin of the day following the calendar date
> specified by the "DTSTART" property. 

The advantage is that we still have every end non-inclusive, and that the 
second from 23:59:59 to 00:00:00 is also still part of that event.

> example is required.  Bernard will propose.  OPEN

Yes, the normative text is accurate, it's just not very clear how to apply the 
rules. In particular, the example given in the RFC does not depend on the 
correct order of the BY* evaluations.

> Issue 12: Duplicate of issue 11 CLOSE

Okay, just to clarify how to evaluate the RRULE for the timezones:
     DTSTART:19671029T020000
     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10

Each date/time is specified by 
     (year,month,day,hour,minute, second). 
In the beginning we start off with 
     (*,*,*,*,*,*). 
As FREQ is YEARLY, we loop through all years. For 2006, we have the 
restriction
     (2006,*,*,*,*,*). 
Now we evaluate BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR,   
BYMINUTE, BYSECOND and BYSETPOS in that order. The BYMONTH adds the 
additional restriction
     (2006,10,*,*,*,*).
We don't have BYWEEKNO, BYYEARDAY or BYMONTHDAY, but BYDAY now says to take 
the last sunday that matches the restrictions above (i.e. the last sunday in 
october 2006, which is the 29th):
     (2006,10,29,*,*,*)
As we don't have any other BY* rules, we're finished. All missing pieces of 
the date/time are now taken from DTSTART:
    (2006,10,29,02,00,00)

So we end up with the correct date.

Similarly, for 
     DTSTART:19671029T020000
     RRULE:FREQ=MONTHLY;BYDAY=-1SU;BYMONTH=10
we loop through all months. Let's start in August 2006:
     (2006,08,*,*,*,*)
The BYMONTH=10 tells us to set the month to 10, but this conflicts with 
August, so no occurence is generated. Next in the loop is September 2006:
    (2006,09,*,*,*,*)
Again, the BYMONTH=10 conflicts with the already-existing restrictions. Next 
in the loop is October 2006:
     (2006,10,*,*,*,*)
The BYMONTH=10 can be set and does not conflict with the already existing 
restrictions. Next is BYDAY, which tells us to take the last sunday of all 
days that match the above restrictions (i.e. the last sunday in October 2006, 
which is the 29th):
    (2006,10,29,*,*,*)
Again, the times are taken from the DTSTART:
    (2006,10,29,02,00,00)
Next in our monthly loop is November, which again does not generate an 
occurence. Only the next october generates the next occurrence.

Thus, both rules produce exactly the same recurrence set. I propose to add 
several such clarifications to an official FAQ as proposed above. I'm willing 
to write them.

> discussion on the list about this) CONSENSUS

As I said on the list, simply removing the "if specified" changes the 
interpretation of RRULEs to results that one would not expect. E.g. an event 
with two rrules:

DTSTART;VALUE=DATE:20061011
RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=MO
RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=FR

will result in the event only happening on Oct 11, but not on any monday or 
any friday, which is not what I would expect. I wonder how different 
implementations interpret this snipplet...
Intuitively, I would expect the event to happen on Oct 11, plus on the next 
one monday and on the next one friday.

I propose the following text:
  The value of the "DTSTART" property, if generated by the rule, counts as the
  first occurrence.

As the RFC says that duplicate date/time instances in the recurrence set are 
ignored (and thus particularly the value generated by the rrule), that text 
makes it clear, that they still count towards the COUNT.

> doc, so more text is needed.  OPEN

I don't understand why the discussed sentence is in the RFC anyway.

Section "4.8.5.4 Recurrence Rule" says:

" The recurrence set is
   generated by considering the initial "DTSTART" property along with
   the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
   within the iCalendar object. The "DTSTART" property defines the first
   instance in the recurrence set. ..." 

And later on we have:

"   The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION"
   property pair, specified within the iCalendar object defines the
   first instance of the recurrence. "

Isn't the same thing already said in the previous cited paragraph? If so, I 
propose to simply delete the sentence "The "DTSTART" and "DTEND" property 
pair ... instance in the recurrence set."

> example, but Bernard would like to see more text.  This issue remains open. 
> OPEN 

Sorry, I don't have any idea for a better formulation. 

> Issue 25: The proposal now is to deprecate EXRULE.  Cyrus to kick off

If we remove that confusing sentence from issue 14 and properly re-word the 
issue in 13, it's clear that the DTSTART is not automatically generated by 
the EXRULE, thus the DTSTART is not always excluded and the issue is solved.

I'm fine with deprecating exrule (although I worked hard to implement multiple 
exrules support it in libkcal...).

Actually, while reading the recurrence description in RFC 2445, section 
4.8.5.4, I propose another clarification:

Current text:
   "The final recurrence set is generated
   by gathering all of the start date/times generated by any of the
   specified "RRULE" and "RDATE" properties, and excluding any start
   date/times which fall within the union of start date/times generated
   by any specified "EXRULE" and "EXDATE" properties."

Proposed text:
   "The final recurrence set is generated
   by gathering all of the date/times generated by any of the
   specified "DTSTART", "RRULE" and "RDATE" properties, and excluding any 
   date/times which fall within the union of date/times generated
   by any specified "EXRULE" and "EXDATE" properties."

Rationale: The current text sounds as if the only dates generated by RRULE or 
RDATE can be excluded by EXRULE or EXDATE. However, section 4.8.5.2 
explicitly says "The "EXRULE" property can be used to exclude the value 
specified in "DTSTART".".

And one more issue:
In section 4.3.10, RFC 2445 says:
"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." 

This is not true in general, only if no other BY* rule parts are given. E.g. 
in the RRULE
  RRULE:FREQ=MONTHLY;BYDAY=1MO;BYMONTHDAY=15,16,17,18,19,20,21
the BYDAY=1MO specifies the first monday in a month within the days numbered 
15, 16, 17, 18, 19, 20 or 21.

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

---

From: lists at block-online.eu (Oliver Block)
Date: Wed Oct 11 08:25:23 2006

Am Mittwoch, 11. Oktober 2006 17:16 schrieb Reinhold Kainhofer:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> productive) Tuesday jabber sessions, as we have a scientific presentation
> at our department every tuesday from 16:30 until 18:00...

The session log can still be read if you enter the chat room. 

Regards,

Oliver

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Oct 11 08:37:23 2006

Hi Reinhold,

--On October 11, 2006 5:16:28 PM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

> will result in the event only happening on Oct 11, but not on any monday
> or  any friday, which is not what I would expect. I wonder how different
> Intuitively, I would expect the event to happen on Oct 11, plus on the
> next  one monday and on the next one friday.

An instance representing the supplied DTSTART value is always present as 
per 4.8.5.4 (which says in the Description paragraph: 'The "DTSTART" 
property defines the first instance in the recurrence set.'). So a COUNT=1 
will only ever generate the DTSTART instance. So your 'intuitive' 
expectation is wrong.

-- 
Cyrus Daboo

---

From: lear at cisco.com (Eliot Lear)
Date: Wed Oct 11 08:39:42 2006

Thank you, Reinhold.  Let me simply ask the group whether the same time
or 9:00am on Wednesdays would be possible?

Eliot

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Oct 11 08:48:44 2006

Hi Eliot,

> or 9:00am on Wednesdays would be possible?

Timezone?

-- 
Cyrus Daboo

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Oct 11 08:50:34 2006

> will only ever generate the DTSTART instance. So your 'intuitive'

On the other hand, section 4.8.5.2 about EXRULE (and section 4.8.5.1 about 
EXDATE) says that the EXRULE/EXDATE properties can be used to exlude the 
DTSTART. Notice the word *can* and "in such cases", which indicate that the 
DTSTART is not always automatically generated by an EXRULE.

So, the DTSTART is not always the first instance in the recurrence set, and an 
EXRULE does not necessarily exclude the DTSTART. Consequently, a recurrence 
rule does not necessarily generate the DTSTART as its first date/time.

Cheers,
Reinhold

- --

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Oct 11 09:03:49 2006

Hi Reinhold,

--On October 11, 2006 5:50:22 PM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

>> property defines the first instance in the recurrence set.'). So a
>> COUNT=1 will only ever generate the DTSTART instance. So your 'intuitive'
>> expectation is wrong.
>
> On the other hand, section 4.8.5.2 about EXRULE (and section 4.8.5.1
> about  EXDATE) says that the EXRULE/EXDATE properties can be used to
> exlude the  DTSTART. Notice the word *can* and "in such cases", which
> indicate that the  DTSTART is not always automatically generated by an
> EXRULE.
>
> So, the DTSTART is not always the first instance in the recurrence set,
> and an  EXRULE does not necessarily exclude the DTSTART. Consequently, a
> recurrence  rule does not necessarily generate the DTSTART as its first
> date/time.

But again, 4.8.5.2 states: 'The "DTSTART" defines the first instance in the 
recurrence set.'. I consider that a stronger statement than 'can be used to 
exlcude...'. As defined it 'always excludes the DTSTART'. There is nothing 
in the spec explaining how it would not do that, or how COUNT etc should be 
interpreted in that case.

The bottom line is this just re-emphasizes why EXRULE is a real problem and 
should be deprecated.

-- 
Cyrus Daboo

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Oct 11 09:16:34 2006

Am Mittwoch, 11. Oktober 2006 18:03 schrieben Sie:
> >> COUNT=1 will only ever generate the DTSTART instance. So your
> >> 'intuitive' expectation is wrong.
> >
> exlcude...'. As defined it 'always excludes the DTSTART'. 

Well, first, there is that "if specified", which I understand as "if generated 
by the rule". And second, if DTSTART is excluded by EXRULE or EXDATE it is 
not the first instance in the recurrence set, so we have a contradiction in 
any case. 

> The bottom line is this just re-emphasizes why EXRULE is a real problem and

The same problem goes with RRULE and the COUNT.

Cheers,
Reinhold

- --

---

From: lear at cisco.com (Eliot Lear)
Date: Wed Oct 11 09:18:52 2006

>> or 9:00am on Wednesdays would be possible?

Heh.  So to restate the proposal would be for next Wednesday 8:00 or
9:00 PDT or 17:00 or 18:00 CEST.

Eliot

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Oct 12 06:33:36 2006

Eliot,

I would like the jabber sessions to remain scheduled on
Tuesday.  I'm flexible for the time of the day.

Thanks,
Bernard

Eliot Lear wrote:
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Oct 12 06:56:39 2006

> Tuesday.  I'm flexible for the time of the day.

Okay. I don't have any time next tuesday, either (only maybe from 10:00 to 
11:15 CEST, but that's right in the middle of the night in the US). So again 
I won't be able to attend.

Cheers,
Reinhold

-- 
------------------------------------------------------------------

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Oct 12 13:12:12 2006

Am Mittwoch, 11. Oktober 2006 17:37 schrieben Sie:
> will only ever generate the DTSTART instance. 

The DTSTART is the first instance in the *recurrence set*, which is defined of 
the union of DTSTART plus all date/times generated by RRULEs and RDATEs, 
exclding all date/times generated by EXRULEs and EXDATEs. 
This sentence does not say that the RRULE generates the DTSTART as its first 
date/time.

I looked at how different calendaring applications currently handle the COUNT 
property at the example of
   RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
   DTSTART;VALUE=DATE:20061009
If the DTSTART is taken as the first occurrence generated by the RRULE 
(although it does not match the BY* rule parts), this event would recur on
   Oct 9
   Oct 10
   Oct 12
If the DTSTART is not automatically taken as the first occurrence (and does 
not count towards COUNT), the event would happen on
   Oct 9
   Oct 10
   Oct 12
   Oct 17

I looked at KOrganizer, Evolution, Mozilla Calendar and Google Calendar (which 
are the only calendaring applications that I currently have access to). 
eGroupware and phpGroupware don't support the COUNT at all.

 Here are my findings:

-) KOrganizer: We understand the 'if specified' as 'if specified by the rule' 
in the sense "if generated by the rule", so the event hapens on Oct 9,10,12 
and 17. DTSTART is not automatically the first event in the list of 
occurences generated by RRULE

-) Evolution: Same result: Oct 9, 10, 12 and 17.

-) Mozilla Calendar: The UI does not allow you to set an RRULE that does not 
match the DTSTART, so this issue does not appear easily. However, you can 
later move the first occurrence to a different day, so that it no longer 
matches the RRULE. In that case, the same result as in KOrganizer and 
Evolution happens: Oct 9, 10, 12 and 17.
Importing such an event leads to non-sensical results (i.e. occurrence on Oct 
9, 12 and 17)

-) Google Calendar: Does not allow you to create recurrences with COUNT. But 
it is able to import such ics files. In that case, the event also occurs on 
Oct 9,10,12 and 17.

So, basically all big open source implementations, plus Google calendar do not 
automatically take DTSTART as the first date generated by the RRULE and do 
not count it towards the COUNT. 

I wonder how other proprietary applications interpret it (in particular 
Outlook and Apple iCal)....

As the consensus amongst implementations seems to be not to automatically take 
DTSTART as the first occurrence, we should clarify the RFC in that direction. 
(It also makes more sense in connection with the EXRULE issue, which would 
then be solved). 

The only problem that is still there are the two contradicting sentences about 
DTSTART always being the first instance in the recurrence set vs. 
EXRULE/EXDATE being used to exclude DTSTART from the recurrence set...
But that issue needs to be solved separately anyway and is not connected to 
our current issue.

Cheers,
Reinhold

PS: I quickly asked our secretary to check Outlook (with no exchange server). 
It doesn't even use the start date as an instance of the event. I.e. I 
created an event on monday Oct 9 and set it to recur weekly on tue and thu 
for 3 times. The event only showed up on Oct 10, 12 and 17!!!
Importing the .ics with the above DTSTART and RRULE failed (with no helpful 
error description whatsoever).

---

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Thu Oct 12 18:16:15 2006

Hi Reinhold,

> I wonder how other proprietary applications interpret it (in 
> particular Outlook and Apple iCal)....

One other in the open source camp, Chandler includes DTSTART in its
count. iCal also counts the DTSTART as the first occurrence, regardless
of the rule.  iCal lets you construct such an event in the UI, Chandler
doesn't.

Section 4.3.10 says:

The COUNT rule part defines the number of occurrences at which to
range-bound the recurrence. The "DTSTART" property value, if specified,
counts as the first occurrence.

That seems pretty clear, so while I found it annoying when implementing
recurrence, I'm used to it now.

We certainly have variation in implementations of this, I'd lean towards
following what 2445 said originally, rather than changing the meaning of
COUNT.  But I'm not deeply attached, we already have incompatibility,
it'd be nice to agree on the same interpretation, whatever it is.

Sincerely,
Jeffrey

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Oct 13 01:11:03 2006

> recurrence, I'm used to it now.

At first glance, I agree it seems pretty clear. But notice the ", if 
specified" in there. These things are not inserted just for the fun of it. 
What I learnt in my part-time law studies is that particularly such easily 
overlooked insertions can change the whole meaning and can't simply be 
ignored. As I said in my previous mails, the only meaning of "if specified" 
that makes any sense to me is "if specified [by the RRULE]". 
This needed to be clarified, as the DTSTART is already in the recurrence set 
and duplicate dates are ignored, so there would be the question whether to 
count such ignored date/times towards the COUNT.

In particular, (a) "if specified" indicates a condition, so it is not always 
the case that DTSTART is counted towards COUNT and (b) as the spec says that 
DTSTART MUST be present it cannot mean "if DTSTART is given at all". 

Also, if DTSTART is automatically included in the dates generated by rules, 
EXRULE does not really make that much sense any more. 
If the "if specified" is meant as "if generated by the rule", then suddenly 
everything falls nicely in place and several problems are no issues any more.

> COUNT.  

Hehe, that's the problem: We have an argument about what 2445 originally said! 
Apparently, I have a different opinion about that than you.

Cheers,
Reinhold

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Oct 13 07:13:04 2006

Am Freitag, 13. Oktober 2006 03:16 schrieb Jeffrey Harris:
> count.

Well, I tried it out, and it seems that Chandler 0.6 does NOT include DTSTART 
in its COUNT if DTSTART does not match the rule: Importing an event with
  RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
  DTSTART:20061009T070000Z
(where the DTSTART is a monday and thus does not match the rule) results in 
the event appearing on Oct 9, Oct 10, Oct 12 and Oct 17.

Chandler 0.7.1 simply ignores the DTSTART if it doesn't match the rule:
  RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
  DTSTART:20061009T070000Z
appears only on Tue Oct 10, Thu Oct 12 and Tue Oct 17 (but not on Oct 9).

Cheers,
Reinhold

---

From: lear at cisco.com (Eliot Lear)
Date: Fri Oct 13 07:19:56 2006

Is this one of those cases where we should get prescriptive about what
to output so that we avoid this circumstance?  So for instance, say that
when applying DTSTART with an RRULE, the value should be that of the
first occurrence?

Eliot

---

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Fri Oct 13 13:12:37 2006

Hi Reinhold,

> appears only on Tue Oct 10, Thu Oct 12 and Tue Oct 17 (but not on Oct 9).

Ouch!  Teach me to make statements about my own code without testing a
recent build.  There was a point in time when it did (what I considered
to be) the right thing, but I apparently neglected to write a unit test.
 I wonder what all that count massaging code is doing right now...  Time
to go write a few more unit tests.

Still, modulo regressions, Chandler *ought* to do a) from Bernard's list.

I think rfc2445 contains a variety of confusing and conflicting
statements.  I interpreted the "if specified" to be a matching statement
with the VEVENT ABNF's implication that DTSTART isn't required, but I
can certainly see why others might interpret it differently.

Sincerely,
Jeffrey

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Oct 13 17:41:10 2006

Hi Jeffrey,

> Still, modulo regressions, Chandler *ought* to do a) from Bernard's list.

The Apple Calendar server which uses vobject does (a), so since Chandler 
also uses that (last I heard) I would expect the same too.

> can certainly see why others might interpret it differently.

Well as we know the ABNF is wrong as the description for DTSTART says it is 
required! Or perhaps the description is wrong and the ABNF is right.

-- 
Cyrus Daboo