Subject: Re: Proposal for VFREEBUSY in icalendar rfc 2445

From: [email-masked]
Date: Mon, 26 Jul 1999 22:12:55 GMT

Ian has some good points here. I kind of agree with him about being able 
to identify what is available and can be accessed as part of free-busy. 
This answers some of the concerns large calendar user customers have as 
well.

Ian Woollard <[email-masked]>
Sent by: [email-masked]
07/26/99 05:22 PM

        To:     "[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
        cc: 
        Subject:        Re: Proposal for VFREEBUSY in icalendar rfc 2445

[email-masked] 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?

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!)

> 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?

> 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.

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

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

We need control.

> Andre
>
> -----Original Message-----
> From: Ian Woollard [mailto:[email-masked]]
> Sent: Sunday, July 25, 1999 10:25 AM
> To: [email-masked]
> Subject: Proposal for VFREEBUSY in icalendar rfc 2445
>
> I've been looking at the icalendar standard. The standard seems very
> well thought out, but I'm deliberately poking in corners to
> see what might be missed, and to see if I can understand it better.
>
> There are 3 independent questions I have about freebusy:
>
> 1. priority- should the free busy include priority
> 2. quantity- should free busy specify quantity rather than
> boolean free/busy
> 3. event- should free busy refer back to the event that
> uses it up?
>
> For example, when I schedule my time, I effectively schedule my time for
> several months at a time, so that it would appear that I am 100%
> occupied.
>
> However, for many items moving the work aside is pretty easily done.
> So it seems to me that the standard needs to have some way to describe
> how
> important a freebusy period is.
>
> Another point is that it might be a good idea to specify how much
> of a thing/person is used, not just a boolean in use/free. For example,
> some people like to allocate 30% of their time to a particular
> person. Or there may be a number of equivalent seats in a room
> that can be allocated. Can free/busy be used to plan their use?
>
> Finally, I think that the freebusy should be correlateable back to
> the event that causes its usage...
>
> So, perhaps fbvalue could be changed like:
>
> fbvalue    = usageperiod *["," usageperiod]
>
> usageperiod = ( ":UID=" uid ":" )
>                        ; quantities value may be postitive or negative
>                        ( ":QUANTITY=" integer ( "." integer))
>                        ( ":" priority )
>                        period
>
> The addition of QUANTITY allows the specification of usage of
> resources such as money, or other identical or equivalent items- if
> quantity is not present this is equal to a quantity of 1. CUAs
> that cannot handle other than unity quantities properly would
> consider them to be busy if they were not totally free.

---

From: Doug Royer <[email-masked]>
Date: Mon, 26 Jul 1999 16:47:13 -0700 (PDT)

> Date: Sun, 25 Jul 1999 15:25:11 +0100
> From: Ian Woollard <[email-masked]>
> 

The BUSY time means 'busy time'.  It seems to me that you are wanting
detailed information, if so, then ask for the details.  And for
details you need CAP.  In iTIP there is no METHOD that allows for you
to ask for the details that you need.  In CAP the current proposals
allow for you to ask those questions.  (Although the current CAP
proposals have iCAL components that are MIME objects that could be
sent in email.  The details have not be discussed yet on how that
might be done with iTIP/iMIP).

With CAP you can ask for DTSTART, DTEND/DURATION, PRIORITY, and UID
You can calculate quantity because of the reply (you get 0 or more in
one time slice). The UID will tie it back to the full component.

As for (3) - no.  That's the point of the VFREEBUSY.  The CS
implementation can decide (as directed by a CUA), what shows up a BUSY
or TRANSPARENT in a VFREEBUSY.  Many felt there needed a way to find
BUSY time without showing the details you want - VFREEBUSY.

There is nothing in iCAL, iTIP, or iMIP that restricts how the CS
determines the VFREEBUSY time.  Some of the WG wants to allow for
multiple bookings in one time period.  CAP allows for a calendar
property that allows or disallows multiple bookings in one time
period.

-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, 27 Jul 1999 00:12:07 GMT

Ian:
From your response to Andre, I think you might want to review the method 
that busy time information is both published/request and also 
access/replied.
What I mean is that the RFC 2446/iTIP gives the "verbs" around the "nouns" 
defined in iCalendar. It provides two mechanisms for exchange of busy time 
information. 
Method 1 - Publish/Access
You periodically take a snapshot of your opaque VEVENTs on your calendar 
and publish an iCalendar object containing a VFREEBUSY calendar component 
containing your busy time information, for say two weeks. Folks with 
access to your "busy time URL" can GET that object using HTTP or some 
other file access protocol. Access to the busy time information is not too 
restricted, I think you would agree.
Method 2 - REQUEST/REPLY
Using the VFREEBUSY based REQUEST and REPLY methods defined in RFC 2446, 
you can request, via email busy time for a given time interval from 
someone. Of course, that individual can just ignore your request if they 
don't think you are authorized to get that information. Or if you are 
authorized, they can send a REPLY method with the properly formatted busy 
time information. This approach provides more secure, but asynchronous 
mechanism for getting busy time.
Hope this helps. More feedback on your original note later.
-- Frank

---

From: [email-masked]
Date: Tue, 27 Jul 1999 00:28:42 GMT

Doug Royer wrote, in part:

>In iTIP there is no METHOD that allows for you
>to ask for the details that you need.

When the current iCalendar/iTIP specifications were being drafted we 
observed that the VFREEBUSY calendar component could be used to return 
more info than just the busy time. This seemed to be an unwanted side 
effect. If what is wanted is to "view" the calendar, then I agree with 
Andre, we either should invent a new iTIP method that has this new 
semantic or work faster to define CAP ;-) Manipulating busy time requests 
to query calendar content will just scare folks from ever supporting busy 
time requests.
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Mon, 26 Jul 1999 17:57:00 -0700 (PDT)

> Date: Mon, 26 Jul 1999 22:22:03 +0100

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.

> 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?

> possible- why have two different definitions for exactly

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.

> free/busy in my opinion. Men may not. Bill Gates would

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.

> 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

> your SO is free for that cosy little candelit supper...

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