Subject: Re: W-25 Remove MUST from UID in 4.8.4.7

From: Doug Royer <[email-masked]>
Date: Mon, 23 Aug 1999 21:45:37 -0700 (PDT)

> From: [email-masked]
> Date: Mon, 23 Aug 1999 10:38:00 -0400
> 
> Pat asked for:
> >Agree that this ends objections on W-25 ?
> 
> Not to be a fly in the CAP ointment but I have a concern Id like to make 
> sure is unfounded or will be addressed by any new action items.

Its being removed from iCalendar - NOT from iTIP.

In CAP you could fetch all DTSTART and DTEND/DURATION as a query.
If you do not want UID - why get it? 

I agree UID is needed as described in iTIP for iTIP methods.
It is not needed in all fetched via CAP.

-Doug

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Tue, 24 Aug 1999 16:23:35 +0200

Does anyone have some advice to give, or comments to offer, to the calendar
app programmers who will have to implement calendar objects with a declared
DTSTART but no declared DTEND?

Such an object is impossible to create today in Outlook or Organizer.

Greg

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Tue, 24 Aug 1999 16:54:54 +0200

Perhaps this little summary of the scheduling times discussion, which I
prepared for Earl Cox might present a clearer picture of the problem.

In short:

There is a property named STATUS, which can be given a value:

TENATIVE or CONFIRMED

but their is no corresponding property for tentative or confirmed or
scheduled DATE/TIMES.  I believe that their is a consensus in the working
group for the following statements:

A confirmed meeting must have a confirmed date/time
A tentative meeting implies a tentative date/time

I am maintain that there are events that can have a STATUS = CONFIRMED but a
scheduled date which is either a:

a) preliminary date/time
b) list of preliminary dates/times
c) time window open on a range for possible dates/times
d) definite ending dates/times with indefinite starting dates/times
e) definite starting dates/times with indefinite ending dates/times

I am not winning much support for this point of view, which is problematic
since the applications we are building for the Swedish National Tourist
Board, require such a syntax.  I have also confused the issue by
intermittently calling for; first a new Component, and then - a new
Property.

Greg