Re: Proposal for VFREEBUSY in icalendar rfc 2445

[Ian Woollard <Ian.Woollard@xxxxxxxxx>]

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?

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:Ian.Woollard@tesco.net]
> Sent: Sunday, July 25, 1999 10:25 AM
> To: ietf-calendar@imc.org
> 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.