Re: Proposal for VFREEBUSY in icalendar rfc 2445

[Doug Royer <Doug.Royer@xxxxxxx>]

> Date: Mon, 26 Jul 1999 22:22:03 +0100
> From: Ian Woollard <Ian.Woollard@tesco.net>
> andrec@cst.ca wrote:
> 
> > Ian,
> >
> > The free/busy answer has been designed for the purpose
> > of hiding ALL information.
> 
> Not quite all.
> 
> > Remember, users need to be
> > able to send the free/busy information without any
> > hesitation. Many systems intend to allow automatic
> > responses to VFREEBUSY requests, where the queried calendar
> > will not have any control on the response to be sent.
> 
> Absolutely; in fact it's clear to me that free-busy
> gives away too much information. Do I really
> want somebody lurking on the internet to know that I
> will busy ALL weekend? That I'm probably going to
> be away from home?

If so, then how would tying it to a UID (as you asked in your previous
email) help?  As you would now have a count and a UID list.

What does BUSY mean?  It could mean that you are busy because you want
to be home with your family.  BUSY time tells users almost nothing at
all.  Just that you probability will not take appointments during BUSY
time.

> The only way to go is different free-busies for different
> purposes. It's going to need to be configurable for
> each purpose.
> 
> I would expect that users will make different
> free-busies say one for general use, one for
> business use, one for recreational use, one for
> private use... etc. etc.
> 
> > Although what you are suggesting has value, allowing
> > intelligent choices for meeting, people are very careful
> > about the information they send to others on the internet,
> 
> Yes, and that was why I suggested making the new fields
> optional (if I have the syntax correct!)

How would you ask for this new VFREEBUSY?  What restrictions (VCAR)
would the user place on a component/calendar to restrict access to
this information?

> > I would suggest an other query, similar to the free/busy
> > request, calling it, calendar contents request, where
> > the rules about the information would be defined based
> > on the authentication of the user making the request
> > (i.e. S/MIME signature or otherwise)
> 
> It's probably best to avoid duplicating information if at all
> possible- why have two different definitions for exactly
> the same thing?

They are not the same thing.

If I ask for BUSY time, I might get back the weekend is BUSY because
you told your CS to NEVER allow booking on the weekend (no UID's).

If I ask for all components that are OPAQUE or TRANSPARENT and
restrict the search time to the weekend.  You may get back nothing at
all because nothing matched.

In the first example you found out that the calendar is for what ever
reason not available on the weekend.

In the second example you found there are no components blocking
the calendar.

If you want to know if the time is bookable, ask for VFREEBUSY.  If
you want to know why - ask for the details.  You might also get
permission denied for one or both.

> > Sending extra information, in my opinion, goes against
> > the basis of the free/busy. Just my opinion.
> 
> Free/busy is a means of communicating. We don't always
> want or need a minimum communication level. We want
> the RIGHT level of communication. Minimum service is
> too much in an internet setting- most women will disable
> free/busy in my opinion. Men may not. Bill Gates would
> have to.

VFREEBUSY will be blocked by some.  Detail searches will be blocked by
some.  The point of VFREEBUSY is that many wanted it.  The point of
being able to ask for details is that many wanted it.

> Do you want stalkers, cold callers, mother in laws, your
> neighbors knowing your wife/SO is free at a certain
> time?

If not, do not publish their calendar.  Or use a CAP VCAR to restrict
the VFREEBUSY or detail searches to your list of authenticated
calendar users

> On the other hand, you REALLY want to know when
> your SO is free for that cosy little candelit supper...
> 
> We need control.

I think everything you want is available now (or I missed something)
The data you want is just not in the format you asked.

-Doug
-------------------------------------------------------------------
Doug.Royer@Sun.COM		http://playground.sun.com/~dougr
Pager:				Doug.Royer@Pager.Eng.Sun.com
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL