Subject: Re: SCHBUF

From: Doug Royer <[email-masked]>
Date: Fri, 27 Aug 1999 13:35:15 -0700 (PDT)

How about something like... ?

	DTSTART;SCHBUF=<duration>:<datetime>
	DTEND;SCHBUF=<duration>:<datetime>

The duration would be time to block out the calendar
in before and after the event.

As new paramaters. NOT FOR CAP, but as a new paramater
submited as a new one as described in RFC2445.  (Same with SCHRANGE).

> Date: Fri, 27 Aug 1999 21:29:04 +0100
> From: "greg fitzpatrick" <[email-masked]>
> ...
> Parameter:  SCHBUF

> A "meeting buffer" for travel arrival and departure of participants - Frank.
>  
> This caused us a good laugh, since in Scandinavia, University lecturers of
> the old school, have traditionally exercised the custom known as the
> "Academic Quarter",  which is a sort of droit de proffeseur  to come 15
> minutes late to one's class.   SCHBUF could be seen as a method for the
> metadata semantification  of this practice.  But actually that would not
> work in this case, since Frank assumes that a SCHBUF would abut to the
> OUTSIDES and not the INSIDES of  DTSTART and DTEND.

>     SCHBUF------DTSTART------------------------DTEND------SCHBUF

> Not that I want to help the teachers come late, but there might be reasons
> why this parameter could have a - or + value indicating whether it was to be
> parsed as outside or inside DTSTART and DTEND.   
> The biggest problem with this parameter  I can see, is the inability to
> explain to the parsing CUA why it is there, sic what is the meaning of the
> value expressed.   On the other hand, SCHBUF might be useful for keeping
> open ended fragments out of conference schedules where adjacent meetings
> will usually not abut front to back  on account of the need for washroom and
> smoking  breaks in between meetings.     
> SKiCAL has never discussed the need for something like this SCHBUF before
> and right now we are neutral on its value.
> ...