Subject: Re: SCHRANGE

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

How about something like the following... ?

	DTSTART;VALUE=SCHRANGE:<from-date>,<to-date>

and perhaps:

	DTEND;VALUE=SCHRANGE:<from-date>,<to-date>

> Date: Fri, 27 Aug 1999 21:29:04 +0100
> From: "greg fitzpatrick" <[email-masked]>
> ...
> Parameter SCHRANGE
>
> A "schedule range" for providing participants a priori knowledge of
> permissible alternative meeting times.  - Frank
> Now this is our kettle of fish.  It suits us to a T.  Here is a mechanism
> for declaring a "window of possibilities" a  range of potential dates for a 
> meeting or event.
> I have just a few questions.
> RFC 2445 says that the DTSART property is required in a VEVENT component and
> must be one of the forms defined for the DATE-VALUE type.   This means that
> an event publisher would have to declare some sort of DATE-TIME in order to
> state the SCHRANGE.  
> The DATE-TIME following a SCHRANGE declaration might be significant as the
> apex of possible DATE-TIMES, the most likely or most attractive time for a
> meeting,  and the SCHRANGE values would indicate the limits of the
> possibility window; 
> b                            x DTSTART = June 6th
> e                         x   x
> s                       x        x
> t                    x              x
>                  x                       x
>              x                               x
> SCHRANGE START                            SCHRANGE END
> June 3rd    June 5th    June 7th    June 9th    June 11th
> or it might have no significance at all, since there might not be a date
> within the scheduling range which is in any way more suitable for a meeting
> than any other day and we would not like it to be considered so.
> Any solutions to this?  Any way of indicating a non-significant DTSTART
> within a SCHRANGE?
> Anyway of avoiding having to declare a DTSTART altogether ?
>  
> Frank's example also declares that the STATUS property is to be set to
> TENTATIVE when using SCHRANGE.  
> Can't we make it easier on the CUA parser, by defining a STATUS, which
> indicates DATE-TIME tentativeness rather than EVENT tentativeness?  Event
> tentativeness is  uncertainty  over whether the meeting will be held or not?
>  DATE-TIME tentativeness is  uncertainty  over exactly when  the meeting
> will be held?
> Greg

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: John Stracke <[email-masked]>
Date: Tue, 31 Aug 1999 13:26:05 -0400

>         DTEND;VALUE=SCHRANGE:<from-date>,<to-date>

This sounds reasonable in itself, but I'm concerned about backwards
compatibility.  What does someone who doesn't support SCHRANGE do when they see
something like this? (This doesn't just mean "software written to RFC-2445"; it
also includes software written in the future that has to work with a backend
store that can't handle indeterminate times.)

--
/================================================================\
|John Stracke    |http://www.ecal.com|My opinions are my own.    |
|Chief Scientist |===============================================|
|eCal Corp.      |Stupid, adj.: Losing $25 on the game and $50 on|
[email-masked]|the instant replay.                            |
\================================================================/