In the following case:
>case:
>
>James is definitely going to have a birthday party. We have planed it for
>some time between the 2nd and the 4th of June.
>
>STATUS:CONFIRMED
>Time property=Scheduled between the dates of June 2nd and June 4th
If the DTSTART and DTEND are not fixed, then the STATUS can not be CONFIRMED. By definition, a confirmed event would have to have a precise start date/time. Hence, the more appropriate way to define this case would be:
STATUS:NOT-YET-SCHEDULED
DTSTART;VALUE=DATE:19990602
X-NEW-DTSTART-FLEX;VALUE=PERIOD:19990602/19990604
This would make use of a new enumeration for STATUS that _does not_ ambiguate the existing values for this property. In addition, it would introduce a new property that is valid for VEVENTs with the "NOT-YET-SCHEDULED" status to indicate the range for the possible DTSTART (and another for the DTEND and DUE properties) or start of the calendar component.
Creating a new calendar component is _not_ the right approach, given the requirements tendered todate. Also, we would not be adding a single new component, but rather three new ones. After all, this same "fuzzy" scheduling can apply to both VTODO and VJOURNAL calendar components also.
-- Frank