Subject: Re: CALSCH Action Items - W-4 Comments

From: [email-masked]
Date: Wed, 28 Jul 1999 17:10:38 GMT

>W-4 Add UID and COUNTER to VFREEBUSY                            U 

Doug:
What is the issue here? UID is already in iTIP for VFREEBUSY/REQUEST, 
REPLY.
A COUNTER method is not needed for VFREEBUSY, as this workflow is a simple 
REQUEST (e.g., when are you busy within this window) and REPLY (e.g., here 
is my current busy time for this date-time window).
IMO, this issue is moot. It should be withdrawn from the list.
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Wed, 28 Jul 1999 10:51:33 -0700 (PDT)

> From: [email-masked]
> Date: Wed, 28 Jul 1999 17:10:38 GMT
> 

There was recently a proposal to add UID (or link back to the event)
and a ~counter~ to the VFREEBUSY.  (Proposal for VFREEBUSY in
icalendar rfc 2445 - original email attached)

There were several comments.  I just wanted to be as complete with the
list as possable.

-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

Subject: Message from mail server
From: Postmaster
Date: Wed, 28 Jul 1999 10:50:24 -0700 (PDT)

Delete.
This is a system message.                                

--END+PSEUDO--

---

From: [email-masked]
Date: Wed, 28 Jul 1999 22:14:59 GMT

>There were several comments.  I just wanted to be as complete with the

Why isn't this handled by adding a RELATED-TO property in the VFREEBUSY 
that points to the calendar entry's UID? The default RELTYPE of PARENT is 
probably appropriate. That is what the property is for.

---

From: Doug Royer <[email-masked]>
Date: Wed, 28 Jul 1999 15:14:02 -0700 (PDT)

> To: Doug Royer <[email-masked]>
> 

Are you proposing changing RFC2445 section 4.6.4 to allow RELATED-TO ?

How would you indicate that a time was blocked out and not related to
a UID?  (Ex:  Do not allow any bookings over the weekends).

I would assume an implementation could choose not to provide the
RELATED-TO information as they might view that as a security issue.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Wed, 28 Jul 1999 15:26:49 -0700 (PDT)

I forgot to say.  I am not in favor of this addition.  As I think it
is not the purposes of a VFREEBUSY to provide any component specific
information.

> Date: Wed, 28 Jul 1999 15:14:02 -0700 (PDT)
> From: Doug Royer <[email-masked]>
>

---

From: [email-masked]
Date: Wed, 28 Jul 1999 22:43:15 GMT

Come on. Let's stop talking for today;-) I want to go home!

>Are you proposing changing RFC2445 section 4.6.4 to allow RELATED-TO ?

That is a possibility, if this addresses the requirements.

>a UID?  (Ex:  Do not allow any bookings over the weekends).

Suggest you refer to the FREEBUSY property and FBTYPE parameter 
specification in RFC 2445. That is where you set the busy time interval to 
";FBTYPE=BUSY-UNAVAILABLE". Or we can have additional FBTYPE enumerations 
such as "BUSY-NOT-SCHEDULABLE".

>RELATED-TO information as they might view that as a security issue.

!Claro que si! Ciao.

---

From: [email-masked]
Date: Thu, 29 Jul 1999 13:46:03 GMT

Doug:
In regards to adding "RELATED-TO" property to the VFREEBUSY iTIP 
restriction tables:
I agree with your objection to adding this. My primary point was to show 
that with minor changes to iTIP (i.e., not having to define new iCalendar 
properties or data structures) we _could_ add support for this capability. 
I too question whether this is a valid requirement for inter-personal 
calendaring and scheduling. Busy time information is more of snapshot 
"reflection" of the "opaqueness" of one's calendar at a given point in 
time. I fail to see the need to provide a link between one busy time 
period and one (or more) element(s) in a calendar. For example, a busy 
time period may actually be a concatenation of a series of contiguous 
"opaque" periods on a calendar. Trying to link the busy time period to an 
individual calendar event would become problematic. 
It would be best to leave the busy time information disjoint from the 
elements that they reflect, other than the "opaqueness" the elements 
reflect on the calendar.
-- Frank

---

From: [email-masked]
Date: Thu, 29 Jul 1999 22:31:20 GMT

>Along these same lines... another thread on the list about "Anniversary" 
>(please don't start that again!) talked about all day events.

You don't need to warm me 8-(

>Will we be able to show busy/time without these events blocking the whole 
day?
>The example was Bastille Day. From the discussion the implication was 
that it 
>would "block" time for 24 hours. If that is the case and the example was 
>correct, how do I show an event that doesn't block time? 

Yes, you can show an event that doesn't block time. You set the "TRANSP" 
property to "TRANSPARENT". This means that the event is not opaque and 
will not render to the busy time data base.
>Is that going to be a function of the "opaqueness" as discussed above? 

Yes, You got it!

>For some Bastille Day is a holiday but for me it's a "no time/floating 
time"
>appointment. I'll celebrate but I will still be available for meetings. 
Our iCalendar
>implementation allows an appointment with time of (NONE) and looks like a
>"title" for the day rather than an event. Are we out of bounds?

You ought to be setting the "TRANSP" property, per above.