Subject: [Ietf-calsify] Recommendationsfor strippingdown iCaltoa manageable'standard'

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Thu Aug 19 17:52:06 2004

The TRANSP property, in my opinion, is inadequate.  It represents a
subset of the free/busy states, and does not convey its intended meaning
appropriately.  The mapping that each of us describe below shows how
inadequate it is.  I think we are in agreement here.

It does not include a "tentative" value, which would clarify when OPAQUE
meant 'busy' and when OPAQUE meant 'tentatively busy'.  As you've said,
clients don't know which to do, because the property is not specific
enough.

I'm not sure what you mean by not having permissions to find if the time
is OPAQUE or TRANSPARENT.  Are you suggesting there are ACLs on this
property? 

Free time does not necessarily convey useless information.  All-day
events are typically TRANSPARENT (your anniversary does not make you
busy all day), and often convey very useful information.

The two new additions you describe *-NOCONFLICT don't make a lot of
sense to me. The names themselves show how they are mixing meaning and
metaphor, but that's the least of the problem.  TRANSPARENT-NOCONFLICT
is an oddity - time that is not scheduled or booked, but that no one can
schedule over? If no one can schedule over that time, it means I've
booked it for another purpose, right? I don't understand it.

I guess what I'm saying is that Free/Busy information is a subset of an
entire calendar of information.  The FBSTATE of an event can be used for
scheduling.  

BUSY: (90% commitment) I've committed my time to it.  I'm going to be
there.
TENTATIVE: (50% commitment) I've committed my time potentially, but not
necessarily - I may not be in attendance, don't plan on me.
FREE: (0% commitment) I have not committed time to this appointment. I'm
planning on not going. I know about it, it's on my calendar, but it
doesn't affect my schedule at all.

I have heard of other, more detailed states, but they are not quite as
compelling:

BOSS-BUSY : <BUSY++> (100% commitment) meeting with my boss. no other
appointments can trump this one.  I'll be at this meeting unless I'm in
the hospital with a broken leg.
SQUISHY-BUSY : <TENTATIVE--> (10% commitment) I'll attend this meeting
if I don't find anything better to do first.  Feel free to schedule me
over this time if it is useful to you, especially if you happen to be my
boss.

Currently, this information is available from VFREEBUSY, but NOT from
events.  TRANSP is trying to be a copy of this information, but it's
going about it oddly, and ineffectually.  They are the same concept, but
we are representing them differently.

If I have your schedule, I'll want to book a meeting with you using that
information - without having to ask separately for free/busy information
which is a logical subset of the calendar.  More importantly, I'll want
to render your calendar, which means I'll need to show where your time
is committed.  I can't do that reliably without this knowledge.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Wednesday, August 18, 2004 6:22 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendationsfor strippingdown iCaltoa
manageable'standard'

Cameron Stillion wrote:

>TRANSP does allow parameters, so perhaps we could use the FBTYPE= param

>on this property, and simply ignore the actual value of TRANSP if it 
>exists.  This allows us to fold these ideas *which are exactly the 
>same* without using two different schema elements.  Existing iCals 
>would not be broken.  New iCals would not break old parsers.  How does
that sound?

What does it add to the functionality? It would be neater, but at what
cost to compatibility? We are talking about computer read data.

>No surprise that two new TRANSP properties are being added... they are 
>communicating the same notion as FBTYPE, only TRANSP incorrectly tries 
>to imply client rendering behavior.  If you prefer using TRANSP to 
>using the (more expressive imho)  FBTYPE, then I suggest we make TRANSP

>values that represent each of these free/busy states.  It's not clear 
>to me that they match up currently:
>
>Free = transparent
>Busy = opaque
>Busy-Tentative = ?
>Busy-Unavailable = OPAQUE-NOCONFLICT
>? = TRANSPARENT-NOCONFLICT
>

Some implementations map their BUSY time to mean BOOKED time (OPAQUE
with TENTATIVE or not)

Some implementations map their BUSY  their to mean OPAQUE and not
TENTATIVE only time.

The real meaning of BUSY is - you can not book this time slot for what
ever reason.
And you might not have access to find if it is TENTATIVE, OPAQUE, or
TRANSPARENT.
Just no.

Free time is useless information as it can mean that nothing is booked. 
It does not
mean that you are allowed to book that time (1am for example).

So, perhaps we need to come up with a VFREEBUSY2 that does clearly
defined things.

>There seeme to be no way to describe tentative, and no way in VFREEBUSY

>to describe the transparent but unschedulable (? Is that any different 
>than a private booked 'busy' appointment?)
>
That's up to the user in some implementations, can not always be
automated.

A CUA that asks for VFREEBUSY information gets it so that there can be a
decision on what time are available for inviting a calendar to an
appointment.

Does it matter why you can not book the time?

>
>It's fine to have an event that takes no time, I don't have a problem 
>with that. But that isn't an all-day event, and we shouldn't assume it 
>is.
>  
>
I agree.

>I'm not trying to argue that all events require a duration - I concede 
>your point there.  Let's be clear though that our assumption in such 
>case should be a zero-time event rather than any other assumption (such

>as an all-day event)
Yes.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Aug 20 09:44:55 2004

Yes, CAP has ACLs and some implementations have ACLs that
are independent of CAP.

>clients don't know which to do, because the property is not specific
I mean the CUA may not know directly, it may be a CU decision.

>is OPAQUE or TRANSPARENT.  Are you suggesting there are ACLs on this
On the calendar, VEVENT, or property - yes it can have them.

>booked it for another purpose, right? I don't understand it.
A time slot can be booked and TRANSPARENT, so it shows as free in
a VFREEBUSY request. Example: A meeting that goes from 2pm-3pm
and I will not be attending, but I want it on my calendar.
I would return this time as FREE in a VFREEBUSY

And it can be TRANSPARTENT-NOCONFLICT, as in keep the
time available for the 2pm-3pm meeting free in case I change my
mind and want to attend it and do not allow anyone to book that time slot.
I would return this time as BUSY-TENTATIVE in a VFREEBUSY

OPAQUE - Show the time as BUSY. However it may be overlapped booked.
I would return this time as BUSY in a VFREEBUSY

OPAQUE-NOCONFLICT - Show the time as BUSY and only
one VEVENT (or whatever) can use this time spot (a resource
like a conference room for example).
I would return this time as BUSY in a VFREEBUSY

>doesn't affect my schedule at all.
There are 4 states for FBTYPE:

                    FREE
                    BUSY
                    BUSY-UNAVAILABLE
                    BUSY-TENTATIVE

>we are representing them differently.
The TRANSP value  is the hint used by calendar programs to generate the 
VFREEBUSY
information.

>is committed.  I can't do that reliably without this knowledge.
Yes.  And I agree that you do not always need the VFREEBUSY information
with real time access.

However iMIP messages have no such access to your calendar. So they
send a request asking for your VFREEBUSY information. Your CS generates
the information and replies. With that information, then your CUA can
make an informed guess as to when to then send a METHOD:REQUEST to
your calendar.

So far CAP is the only  proposed/expermimental/draft  real time protocol 
for you
to get the schedule at this time. Currently the only  way to get the 
busy time is
to do an iTIP get VFREEBUSY request or with CAP.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040820/23a83adf/smime-0001.bin