Subject: Re: SKI Presentation in Oslo

From: John Stracke <[email-masked]>
Date: Wed, 11 Aug 1999 15:29:02 -0400

[email-masked] wrote:

> If the latter, then we probably want to look at modifying the RFC2426
> restriction tables for VEVENT, rather than a new component. Can we get
> by with keeping these as VEVENTs that have a DTSTART/DTEND, but a
> special priority and category for these "unscheduled events".

This makes me uneasy.  Remember that whatever you come up with needs to
have a reasonable chance of being able to fit into existing calendar
software's data models (otherwise everybody has to modify their existing
databases, which gets expensive).  I don't really see any way a calendar
that represents events as happening at particular times can be used to
store something unscheduled.

On the other hand, I don't have a good grasp on how SKI presents these
unscheduled events, either.  I understand what they're *for*, but I
can't really envision what the UI would look like.  Maybe that would
give me some ideas.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: Doug Royer <[email-masked]>
Date: Mon, 16 Aug 1999 14:35:30 -0700 (PDT)

> From: [email-masked]
> Date: Wed, 11 Aug 1999 20:05:25 GMT
>
> >Remember that whatever you come up with needs to
> John: I heard the SKICAL folks say that the "unscheduled" event had a 
> date/time that the event was probably going to occur (i.e., a DSTART and 
> DTEND with a STATUS:TENTATIVE or event a new enumeration of 
> STATUS:UNSCHEDULED), but that it would get updated, once it had been 
> actually scheduled (i.e., confirmed).
> This maps very well into existing C&S products and systems. For example, 
> you can color/shade code the events on a calendar to indicate their status 
> (e.g., CONFIRMED or TENTATIVE or CANCELLED). It was a relatively small 
> jump to add the "UNSCHEDULED" or "NOTYETSCHEDULED".

I don't think so.

He was talking about a VEVENT without any DTSTART or DTEND as the time
had not yet been set and was unknown.  He was looking (as I understand
it) for something like:

	Coming next summer: ..... time/date to be announced soon.
	
Something like a VTODO, yet without a DATE/TIME and convertible into a
VEVENT as soon as the DTSTART was known.

I am not saying it should be part of CAP.  I think it should be
submitted as a separate component as it would bust the iTIP
restriction tables.

In Oslo I had asked him if he meant a VEVENT with an uncertain
DTSTART, if so he could have had STATUS=TENTATIVE.  He said "no", they
also use those types of VEVENTs.  They need one that was viewable with
an unknown DTSTART.

-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: [email-masked]
Date: Tue, 17 Aug 1999 13:23:57 GMT

>                Coming next summer: ..... time/date to be announced soon.

Exactly! Notice the "coming next summer". This hardly specifies an 
"unknown" time period. However, this does specify a tentative status, but 
a well understood time frame. Summer has a start and an end. As I said, 
there doesn't seem to be a real requirement for another calendar component 
for this. Such a move for a component that is every so close to an event 
will just create confusion.
Fuzzy logic date/times is clearly something that even traditional paper 
diaries/planners can't handle. The best way to map such things is the 
paper planner's "Planning Calendar" or the "Monthly Index" pages that 
allow you to mark "notes" about either a period in the year or the month.
Bottom-line: We still have an open request to the SKICAL folks for a 
definitive specification of their calendaring and scheduling requirements. 
These requirements need to be defined in a clear and succinct manner so 
that we can understand their needs and work on a possible mapping or 
enhancements to the iCalendar data and system models.
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Tue, 17 Aug 1999 08:44:06 -0700 (PDT)

> Date: Tue, 17 Aug 1999 13:23:57 GMT
>
> ...

I think we listened to them on this list when they first sent their
email.  We listened to them in Oslo.  Both times we asked for details
of the problem they wish to solve.  And now we need a proposal from
them and more definition of the problem.

They need to participate.  Without any more input from them, I say we
close this discussion until there is some proposal.

-Doug

---

From: [email-masked]
Date: Tue, 17 Aug 1999 17:28:50 GMT

I agree.  S K I people??? Comments?

                    Doug Royer                                                                                         
                    <[email-masked]        To:     [email-masked]                                             
                    OM>                      cc:                                                                       
                    Sent by:                 Subject:     Re: SKI Presentation in Oslo                                 
                    owner-ietf-calend                                                                                  
                    [email-masked]                                                                                         

                    08/17/99 11:44 AM                                                                                  
                    Please respond to                                                                                  
                    ietf-calendar                                                                                      

-Doug
Mountain View, CA 94040                   Ham Radio: N6AAW, Aviation:
PP-ASEL

---

From: [email-masked]
Date: Wed, 18 Aug 1999 13:25:27 GMT

Greg:
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

---

From: [email-masked]
Date: Wed, 18 Aug 1999 13:15:15 GMT

Greg:
The SKiCAL spec formatting appears corrupted after section 4. It is not
printable within normal column settings. You may want to have the editors
reformat it and post a revised URL to this list.

-- Frank

---

From: [email-masked]
Date: Wed, 18 Aug 1999 13:46:29 GMT

>>Certainly, the current iCalendar specification would allow you to 
introduce
>>"non-schedulable hours" as opaque events. We would have the problem with
>>systems that allow conflicting appointments/meetings to be scheduled. 
What
>>we really need is the "schedulable hours" property we have discussed in 
the
>>CAP discussions.
>
>Schedulable hours - Schedulable days - Scheduled times.

Not certain what you are implying by these separate components for a 
date/time? Are you implying a need for three separate properties for the 
schedulable dates, hours, times? You may want to clarify this. The CAP 
discussions have centered on a single calendar property that captured the 
schedulable date/times. That might be either cyclic or single set of 
date/times.

>
>Presently we are discussing how scheduled times are going to show up for 
an
>event seeker.
>If someone scheduled an event to happen at any time during 1999 (like a
>crash in Internet related stocks) we would not want that to show up on 
every
>day of a person's event harvester.
It might be good to get the SKiCAL folks to bring that discussion (if it 
relates to requirements for the format or protocol) to this mailing list. 
If it is a UI or implementation issue, probably not germaine, though.
-- Frank

---

From: [email-masked]
Date: Wed, 18 Aug 1999 15:38:14 GMT

>Now I am not saying this is necessarily the best way to solve the 
problem,
>it could also be done with the help of a qualifier inside the Event 
property
>or a qualifier for the STATUS property. But we had already made a 
decision
>that OPENINGTIMES should be a new component and it seemed natural to deal
>with SCHEDULEDTIMES in the same way.

I think you mean "component property", not "component". 
Not sure who you refer to in the "...we have already made a decision...". 
You mean SKiCAL? I can't recall that the IETF calsch WG didn't make such a 
decision; or that such a proposal was actively discussed. I think we were 
still waiting to hear what the complete requirements were. The 
specification you posted is an implementation profile, but doesn't really 
define the problem domain requirements. Right?
Back to the requirements...For an event, such as a Boston Red Sox baseball 
game, I can certainly see that it would be beneficial to have an 
additional property in the VEVENT definition that indicated when the gates 
opened. Very often, public events have both a
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Wed, 18 Aug 1999 08:33:45 -0700 (PDT)

> Date: Wed, 18 Aug 1999 13:25:27 GMT
> 
> Greg:
> In the following case:
> >case:
> >

I don't think your example (below) solves their problem. If I get all 
appointments for June 3rd via CAP, this will not show up.

They could do it with an x-property. I think they are asking for
a standard way to do this. And again I go back to saying that
they need to propose some text and submit it to this list. And
then I think it must be a separate RFC.

-Doug

---

From: [email-masked]
Date: Wed, 18 Aug 1999 17:20:31 GMT

>appointments for June 3rd via CAP, this will not show up.

Right! you would have to select the VEVENT components with the appropriate 
properties/values selected. It is not specified for June 3rd until the 
DTSTART says so. We don't have fuzzy logic for events. They are either on 
the calendar or not. Same for VTODO and VJOURNAL. 
Agree that we need form concrete requirements and proposals for this. But 
more important we need more discussion.
-- Frank