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

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Wed Aug 18 10:45:33 2004

If an event has no DURATION and no DTEND, we assume that it starts and
ends at the   same time, in which case, I agree TRANSP does not matter.

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?

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

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

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 misspoke that an event can have both enddate and duration - they
cannot.

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)

cameron

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

Cameron Stillion wrote:

>It seems like whether the event shows as busy, free or tentative should

>be independent of whether it is a multi-day, single-day, all-day event,

>or just a regular old appointment.  We can make no assumptions about 
>the availability based on the start or end time, the timezone 
>association, or whether it has hours or minutes.  Let's not make 
>dependencies on orthogonal properties.
>

It's not that its a rule. Its that if it has no DURATION or DTEND then
there are ZERO seconds that are really booked. So even if TRANSP were
set to OPAQUE it would be opaque for zero seconds which is identical to
TRANSPARENT.

Maybe we can come up with a way to be compatible with existing iCal
objects. If we simply declare two of the items the same, then we can no
longer import them and know what to do with them.

>Speaking of TRANSP... This should have the same values as the 
>fbtypeparam. The document constantly refers to this as the free/busy 
>state of the event anyway, let's just make it very clear that it is 
>indeed the same.  And actually, the state definition which is { opaque 
>| transparent } seems to imply a lot about how the client renders such 
>things.  It makes much more sense to me to use the { free | busy | 
>busy-unavailable | busy-tentative } states and let the client 
>applications determine how these are rendered.
>
There will soon be 2 more TRANSP states introduced from CAP that will be
pooping out soon from the 4-5 vendors that will be sending CAP objects
soon.

    TRANSPARENT-NOCONFLICT
    OPAQUE-NOCONFLICT

Where NOCONFLICT means that no other object may use any of the the same
time slot.

And the VFREEBUSY was a stop gap until we had some kind of real time
transport anyway.  In CAP for example you can ask for the dynamic
VFREEBUSY object that represents the free time from a calendar. I can
mark 6pm-8am as TRANSPARENT-NOCONFLICT so that no one would be able to
book time with me for non-working hours (one example of usage).  I would
not be available and have only one bogus repeating object, yet not show
up as booked time.

I do not think that we should change the values of TRANSP even if it
looks difficult to follow as it will break existing objects. Instead we
need to more clearly explain how to use its values.

>I still think that the anniversary example should have a duration.  
>That is to say, either an event has an end date or a duration or both.

>Why would we default the length of an event to 1 day? It seems like an 
>optimization for an uncommon case.
>
Many PDAs, PIMs, and application allow for the creation of objects that
consume no time at all (NO END).  At 10am take your pill for example,
would consume no time and yet have an entry. So even if you do not call
it an anniverisy you still have the same problem.

>
>So, we don't need a boolean for all-day property, since this can be 
>gleaned from DTSTART and ( DTEND or DURATION - which are mutually 
>exclusive, btw).
>  
>
Those are also valid needs. I do not see that you have sucessfully
argued for the ability to require all object to have a duration.

-- 

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: Wed Aug 18 18:21:51 2004

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

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

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

>with that. But that isn't an all-day event, and we shouldn't assume it
I agree.

>case should be a zero-time event rather than any other assumption (such
Yes.

-- 

-------------- 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/20040818/9bc15e17/smime.bin