Subject: BYDAY & broken VTIMEZONE-RRULE examples?

From: "Graham Gilmore" <[email-masked]>
Date: Wed, 5 Sep 2001 13:40:22 -0400

[Apologies in advance if this has been covered before; I looked
through the current issues list and I didn't see anything related....]

    I've been taking a close look at what RFC 2445 has to say about
BYDAY parts in rules, particularly in relation to rules for VTIMEZONEs,
and I came across something interesting.  On page 43 (in section 4.3.10,
on the Recurrence Rule data type), there is this paragraph (any typos
are mine in the copying):

    "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."

    The use of the terms MONTHLY and YEARLY, as well as second-to-last
sentence, indicate that the BYDAY modifier relates to the frequency, not
any other rule part.  Now, replacing the frequency MONTHLY with YEARLY
in the above paragraph, we get "+1MO (or simply 1MO) represents the
first Monday within the year, whereas -1MO represents the last Monday of
the year."
    However, looking at the various VTIMEZONE examples within the RFC
that include a RRULE as part of their specification, all the ones I've
seen seem to have a rule that reads something like
"FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10" which (according to the above
description of BYDAY) should NOT generate the desired result, but rather
an empty set of dates (since, naturally, the last Sunday of the year
never falls within the 10th month)!
    Damon Chaplin's Olsen-based VTIMEZONEs (or at least those I've seen)
seem to have sidestepped this problem by eschewing the BYDAY part in
favor of listing explicit BYMONTHDAY values, or generating lists of
RDATES rather than using a rule.
    Another alternative would be to use a rule like this:
"FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU" (the BYMONTH becomes redundant, as
it is inherited from the DTSTART).

    Graham

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Thu, 6 Sep 2001 09:34:29 +0200

I brought this up in London and Pat asked me to elucidate.

In RFC2445 the event component is described as follows

:4.6.1 Event Component

:   Component Name: "VEVENT"

:   Purpose: Provide a grouping of component properties that describe an
:   event.

:   Format Definition: A "VEVENT" calendar component is defined by the
:   following notation:

:     eventc     = "BEGIN" ":" "VEVENT" CRLF
:                  eventprop *alarmc
:                  "END" ":" "VEVENT" CRLF

:     eventprop  = *(

!!! notice here that the dtstart is optional !!!

:                ; the following are optional,
:                ; but MUST NOT occur more than once

:                class / created / description / dtstart / geo /

:                last-mod / location / organizer / priority /
:                dtstamp / seq / status / summary / transp /
:                uid / url / recurid /

:                ; either 'dtend' or 'duration' may appear in
:                ; a 'eventprop', but 'dtend' and 'duration'
:                ; MUST NOT occur in the same 'eventprop'

:                dtend / duration /

Actually some of the other calendar components also specify an optional
DTSTART though VTIMEZONE is quite clear both in the ABNF and the text that
DTSTART is mandatory

:The "VTIMEZONE" calendar component MUST include the "TZID" property
:   and at least one definition of a standard or daylight component. The
:   standard or daylight component MUST include the "DTSTART",
:   "TZOFFSETFROM" and "TZOFFSETTO" properties.

later on in the memo the DTSTART property is described as follows:

:4.8.2.4 Date/Time Start

:   Property Name: DTSTART

:   Purpose: This property specifies when the calendar component begins.

:   Value Type: The default value type is DATE-TIME. The time value MUST
:   be one of the forms defined for the DATE-TIME value type. The value
:   type can be set to a DATE value type.

:   Property Parameters: Non-standard, value data type, time zone
:   identifier property parameters can be specified on this property.

:   Conformance: This property can be specified in the "VEVENT", "VTODO",
:   "VFREEBUSY", or "VTIMEZONE" calendar components.

!!! Here comes the text that conflicts with the ABNF above.

:   Description: Within the "VEVENT" calendar component, this property
:   defines the start date and time for the event. The property is
:   REQUIRED in "VEVENT" calendar components. Events can have a start
:   date/time but no end date/time. In that case, the event does not take
:  up any time.

Now somewhere in the back of my head I think I have seen a text that when
conflicts of this sort occur - it is the ABNF which takes precedence over
prose.  John S. questioned that in London, so I am forwarding this to Harald
to get some feedback.  (realizing of course that he is quite a busy man
nowadays)

This inconsistency caused the SkiCal group to create our own component for
the declaration of opening times.

http://www.skical.org/skical20010905.html#optimec

  If we knew for sure that DTSTART was not mandatory on a VEVENT component
then we could use our DTOPEN property instead - but if DTSTART is REQUIRED
we believe that the existence of both DTOPEN and DTSTART in the same object
could be quite confusing.

Greg

---

From: "David L. Nicol" <[email-masked]>
Date: Thu, 06 Sep 2001 03:11:26 -0500

Yet another argument for chipping out the RRULEs into
separate named systems that can be listed by a CAPABILITIES
call.

-- 
                                           David Nicol 816.235.1187
do be do be do

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 06 Sep 2001 11:44:52 +0200

> prose.  John S. questioned that in London, so I am forwarding this to
> Harald to get some feedback.  (realizing of course that he is quite a
> busy man nowadays)

Hmmm.....I have never seen such language for the general case.
I have seen a few special mentions, especially when something was 
represented twice in a document (like ABNF in little pieces all over the 
document + a collected appendix in the end - would be too silly not to have 
a decision rule if the document editor messed up).

But ABNF (or any grammar-based specification) has a real problem: It can 
clearly specify a decision rule that defines SOME messages as illegal 
(those that conform to the grammar). But it will never be able to specify 
ALL illegal messages; some messages allowed by the grammar will not be 
legal due to other parts of the specification.

Not speaking to the particular case (because I don't know it), but in 
general, you will often find that the only way to specify "a lot of fields, 
which may appear in any order, some of which are mandatory, and some of 
which are optional" in ABNF is to write an ABNF that specifies them all as 
if they were optional.

This is because ABNF does not have the concept of SET the way ASN.1 had (a 
collection of items in any order, which still may have limits on occurence) 
- ABNF is ONLY able to specify either strict sequence or "a bunch of 
things", where the "bunch" consists of many alternates.

I'll let the ietf-calendar people speak to whether they wanted DTSTART to 
be mandatory or not. But the inconsistency in the quotes given are in the 
comments ("are optional"), not in the formal ABNF.

> we believe that the existence of both DTOPEN and DTSTART in the same
> object could be quite confusing.
>

I seem to VAGUELY remember an argument for having events without starttime 
once - something about proposed events with "where will this fit into your 
schedule". But that doesn't fit with the 4.8.2.4 text - perhaps the WG 
rejected it.

Fixing the base spec so that it's clear seems the Right Thing to do.
Having two components that mean the same thing seems Bad to me - if the 
CALSCH group thinks that DTSTART is optional, couldn't the SkiCAL specs 
just say that VEVENTs without DTSTART didn't conform to the SkiCAL profile?

Interoperability will be harmed if they are different.

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Thu, 6 Sep 2001 12:49:18 +0200

Thanks Harald

>comments ("are optional"), not in the formal ABNF.

Yes and so it is done all through out the draft - in most cases the editors
do not rely on formal ABNF to distinguish between optional, mandatory and so
on (though [optional] brackets are sometimes used) but put in  comments
interweaved in the ABNF.

>schedule". But that doesn't fit with the 4.8.2.4 text - perhaps the WG

From a SkiCal point of view an optional DTSTART or a possible NULL value for
DTSTART is preferred, though I suppose some would argue that a calendar
object with out a date is not a calendar object.

Harold:
>if the

First - I think the argument has been turned around.  Rather we would say
that obligatory DTSTART's didn't conform to the SkiCal profile, but still
that wouldn't mean make much sense if DTSTART's were mandatory for iCal
parsers.

:Harold
>Having two components that mean the same thing seems Bad to me -

Yeah, I understand how that could happen.  Of course the two components
don't really mean the same thing, since the open/operating/valid/etc. times
of everything in our environment require quite a different representational
model than a desk-top/palm-top calendar that is more attune to a limited set
of events.  But if the group can agree that DTSTART's are optional, we would
consider dropping the extra component.

Greg

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 6 Sep 2001 10:36:21 -0400 (EDT)

> it is inherited from the DTSTART).

Another possiblity (and another piece of evidence in the "FREQ doesn't mean
as much as you think it does" argument) is:

        FREQ=MONTHLY;BYMONTH=10;BYDAY=-1SU

which should be sufficient.

-- 
Jonathan Lennox
[email-masked]

---

From: "Graham Gilmore" <[email-masked]>
Date: Thu, 6 Sep 2001 11:49:12 -0400

----- Original Message -----
From: "Greg FitzPatrick" <[email-masked]>
To: <[email-masked]>
Cc: "Harald Alvestrand" <[email-masked]>
Sent: 06 September, 2001 03:34
Subject: major inconsistancy in RFC 2445

[...]
> prose.

    The last paragraph of the Introduction of RFC 2445 states that the
ABNF is meant in part "to serve as the definitive reference when
ambiguities or questions areise in interpreting the descriptive prose
definition of the memo."  So there it is, although it might make more
sense to include this paragraph in the next section ("Basic Grammar and
Conventions") rather than in the introduction....

    Graham Gilmore

---

From: Damon Chaplin <[email-masked]>
Date: 21 Sep 2001 15:34:12 -0400

> RDATES rather than using a rule.

Unfortunately MS Outlook (2000, at least) doesn't seem to support
BYMONTHDAY in VTIMEZONEs, so I'm currently removing all uses of it.

We now use rules like this:

RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1FR

And I think Outlook uses similar rules (since I tried to use similar
rules to them to try to ensure interoperability).

So maybe the wording of the spec needs changing, as I think people
have been assuming the above rules are OK (i.e. it means the last
friday in April). I don't think we want to break interoperability with
Outlook, which is one of the most widely used iCalendar apps.

Damon

PS. Is there a place listing known interoperability problems?
As well as the BYMONTHDAY problem, we also found that Outlook (2000)
doesn't like TZ offsets which include a seconds value (in VTIMEZONEs at
least). It assumes the seconds value is minutes, so date-time values
get shifted by a number of days. It also stores the human-readable
timezone name in the TZID, and places rather useless strings like
"Daylight Time" and "Standard Time" in the TZNAMEs.