Subject: [Ietf-calsify] Section 4.6.1 Event Component: Default duration of day events

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Sun Nov 5 14:28:36 2006

In section 4.6.1 Event Component of RFC 2445 it 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.

As such, the last sentence of the paragraph before the following example
is wrong. This event would actually appear as opaque in a search for busy
time.

 > The following is an example of the "VEVENT" calendar component used
 > to represent an anniversary that will occur annually. Since it takes
 > up no time, it will not appear as opaque in a search for busy time;
 > no matter what the value of the "TRANSP" property indicates:
 >
 >   BEGIN:VEVENT
 >   UID:[email-masked]
 >   DTSTAMP:19970901T1300Z
 >   DTSTART:19971102
 >   SUMMARY:Our Blissful Anniversary
 >   CLASS:CONFIDENTIAL
 >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
 >   RRULE:FREQ=YEARLY
 >   END:VEVENT

I propose to remove this sentence and to add the TRANSP property to
the example.

Proposed text:

 > The following is an example of the "VEVENT" calendar component used
 > to represent an anniversary that will occur annually.
 >
 >   BEGIN:VEVENT
 >   UID:[email-masked]
 >   DTSTAMP:19970901T1300Z
 >   DTSTART:19971102
 >   SUMMARY:Our Blissful Anniversary
 >   TRANSP:TRANSPARENT
 >   CLASS:CONFIDENTIAL
 >   CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
 >   RRULE:FREQ=YEARLY
 >   END:VEVENT

Similarly, in section 4.8.2.4 Date/Time Start of RFC 2445 it says:

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

I propose to remove the last two sentences of this paragraph.

Proposed text:

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

Finally, in section 6 Recommended Practices of RFC 2445 it says:

 > 2.  A calendar entry with a "DTSTART" property but no "DTEND"
 >     property does not take up any time. It is intended to represent
 >     an event that is associated with a given calendar date and time
 >     of day, such as an anniversary. Since the event does not take up
 >     any time, it MUST NOT be used to record busy time no matter what
 >     the value for the "TRANSP" property.

This is actually wrong. I would simply remove this text. The proper
behave is described in section 4.6.1 Event Component.

Cheers,
Bernard

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Mon Nov 6 06:49:16 2006

Hi Bernard,

> behave is described in section 4.6.1 Event Component.

This issue begs the question of whether all day events should automatically 
appear as opaque in free-busy lookups. I suspect most implementations do 
not add TRANS:TRANSPARENT when adding an 'anniversary' event - but having 
that block out time would be bad.

This would be a change to 2445, but one solution is to say the default 
TRANSP for all day events is TRANSPARENT rather than OPAQUE.

-- 
Cyrus Daboo

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Mon Nov 6 10:37:50 2006

Hi Cyrus,

 > This issue begs the question of whether all day events should
 > automatically appear as opaque in free-busy lookups. I suspect most
 > implementations do not add TRANS:TRANSPARENT when adding an
 > 'anniversary' event - but having that block out time would be bad.

If so, please provide a list of such implementations.

 From what I've seen, implementations do specify DTEND or DURATION and
TRANSP explicitly.  As such, in most cases there are no ambiguity.

 > TRANSP for all day events is TRANSPARENT rather than OPAQUE.

I'd prefer not to introduce an exception for all day events.

Cheers,
Bernard

Cyrus Daboo wrote:
> This issue begs the question of whether all day events should 
> automatically appear as opaque in free-busy lookups. I suspect most 
> implementations do not add TRANS:TRANSPARENT when adding an 
> 'anniversary' event - but having that block out time would be bad.
>