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

From: lear at cisco.com (Eliot Lear)
Date: Fri Jan 26 07:22:44 2007

Dear all,

I refer you to the below issue.  We propose to close the issue as 
Bernard suggests below.  If you have an objection, please offer an 
alternative.  Objecting without alternative leaves a blocking conflict 
in the draft.

Thanks,

Eliot
(chair hat on)
> 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] <mailto:[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] <mailto:[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: lilmatt at mozilla.com (Matthew Willis)
Date: Fri Jan 26 07:27:08 2007

I think Bernard's proposal is fine, and it resolves an issue we  
currently face in how to implement events with no DTEND and no DURATION.

-lilmatt

On Jan 26, 2007, at 10:21 AM, Eliot Lear wrote:

> alternative.  Objecting without alternative leaves a blocking  
> conflict in the draft.
>
> Thanks,
>
> Eliot
> (chair hat on)
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Nigel.Swinson at rockliffe.com (Nigel Swinson)
Date: Mon Jan 29 05:52:08 2007

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.8.2.7
3.8.2.7.  Time Transparency

> > In section 4.6.1 Event Component of RFC 2445 it says:
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.6.1

      The "VEVENT" is also the calendar component used to specify an
      anniversary or daily reminder within a calendar.  These events
      have a DATE value type for the "DTSTART" property instead of the
      default value type of DATE-TIME.  If such a "VEVENT" has a "DTEND"
      property, it MUST be specified as a DATE value also.  The
      anniversary type of "VEVENT" can span more than one date (i.e,
      "DTEND" property value is set to a calendar date after the
      "DTSTART" property value).  If such a "VEVENT" has a "DURATION"
      property, it MUST be specified as a "dur-day" or "dur-week" value.
+    The default Time Transparency for these events is "TRANSPARENT"
+    but can be changed through the "TRANSP" property.

      The "DTSTART" property for a "VEVENT" specifies the inclusive
      start of the event.  For recurring events, it also specifies the
      very first instance in the recurrence set.  The "DTEND" property
      for a "VEVENT" calendar component specifies the non-inclusive end
      of the event.  For cases where a "VEVENT" calendar component
      specifies a "DTSTART" property with a DATE value type but no
-      "DTEND" nor DURATION property, the event's duration is taken to be
+    "DTEND" nor "DURATION" property, the event's duration is taken to be
      one day.  For cases where a "VEVENT" calendar component specifies
      a "DTSTART" property with a DATE-TIME value type but no "DTEND"
      property, the event ends on the same calendar date and time of day
      specified by the "DTSTART" property.

> > is wrong. This event would actually appear as opaque in a search for busy

With DTSTART of type DATE, it now has a default TRANSP of TRANSPARENT.  So the correction would become:

      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:
+    it has a "DTSTART" of type DATE, it is "TRANSPARENT" by
+    default, and therefore it takes up no time, it will not appear as opaque 
+    in a search for busy time.

        BEGIN:VEVENT
        UID:[email-masked]
        DTSTAMP:19970901T130000Z
        DTSTART;VALUE=DATE:19971102
        SUMMARY:Our Blissful Anniversary
        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:
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.8.2.4
> > I propose to remove the last two sentences of this paragraph.

I think this makes it harder to work out what to do in this corner case, and would prefer we were more explicit.  I suggest:

   Description:  Within the "VEVENT" calendar component, this property
      defines the start date and time for the event.  Events can have a
-     start date/time but no end date/time.  In that case, the event
-      does not take up any time.
+    start date/time but no end date/time defined by a "DTEND" or a
+    "DURATION".  In that case, if the "DTSTART" has type DATE-TIME
+    then the event does not take up any time.  If the "DTSTART" has type
+    DATE, then the event has a duration of one day.

> > Finally, in section 6 Recommended Practices of RFC 2445 it says:
http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-5
> > behave is described in section 4.6.1 Event Component.

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.8.2.7

   Description:  Time Transparency is the characteristic of an event
      that determines whether it appears to consume time on a calendar.
      Events that consume actual time for the individual or resource
      associated with the calendar SHOULD be recorded as OPAQUE,
      allowing them to be detected by free-busy time searches.  Other
      events, which do not take up the individual's (or resource's) time
      SHOULD be recorded as TRANSPARENT, making them invisible to free-
      busy time searches.

In the context of "does not take up any time" being "does not take up any time for the individual or resource associated with the calendar", I think it is correct.  But with my proposed change, if there is a DTSTART and no DTEND, then the event either has a duration of 0 if DTSTART is DATE-TIME, or has a TRANSP of TRANSPARENT if DTSTART is DATE, and so either way will be recorded as TRANSPARENT in free-busy time searches.  With that said, I also think the text should be removed, as I'm not sure it is a recommended practice anymore, rather just a re-iteration.

An alternative to my suggestion might be to do a replace on s/does not take any time/does not take any time for the resource associated with the calendar/, and that might remove a lot of confusion.

And on a slightly related subject, I think it would be helpful to add this.

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-04#section-3.3.6

+    Note that a duration of P1D may not be equivalent to P24H due to the 
+    effect of daylight savings.

Nigel

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Mon Jan 29 06:43:31 2007

Nigel Swinson wrote:
> Says default TRANSP is OPAQUE, which makes sense in the context of events
 > with a DTSTART of type DATE-TIME, but perhaps it doesn't make sense WRT to
 > events with DTSTART DATE.  I propose we change the default TRANSP for DATE
 > events to TRANSPARENT.

-1

What needs to be clarified is the default duration of day events.

Some of the examples in RFC 2445 wrongly assumed that the default duration
of day events was 0 seconds and that is why they mention that these events
would not appear as opaque in search for busy time. Which is also wrong.

Cheers,
Bernard

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Mon Jan 29 07:09:43 2007

Hi Bernard,

> would not appear as opaque in search for busy time. Which is also wrong.

I agree with Bernard, the behavior of TRANSP should not be changed at this 
point. What this really means is that clients need to set TRANSP as 
appropriate for events created by users. If a client chooses to treat 
all-day events as being transparent it can add TRAN:TRANSPARENT to those 
when created. Alternatively it can provide a UI option for the user to 
control that.

-- 
Cyrus Daboo