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

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

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.  

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.

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.

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

Regards,
cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, August 17, 2004 8:42 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for strippingdown iCaltoa
manageable 'standard'

Cameron Stillion wrote:

>I would argue that Anniversary should include duration (one day in most
>cases?) And also that your third case is really the same as the first.
>In other words, New Year's Day is just an anniversary that happens on 1

>Jan every year.  Multi-day events (like IETF60) would have a start 
>date, end date, and duration of 5 days. By specifying time, you imply 
>that the event is not all-day.
>  
>
The differences between the 1st and the 3rd is that the 1st never shows
up as busy time as it has no DURATION or DTEND and therefore does not
have any time to block out.

The 3rd can show up as busy time depending  on the value of TRANSP as it
always has a DURATION or DTEND.

And the 1st  can be relative to a time zone and the 3rd is never
relative to a time zone.

So the 1st and 3rd are not the same.  OR we can call them the same
except one has a DURATION or DTEND. that may or might not have a time
zone.
Nothing is eliminated.

>I'm not convinced that everyone represents these the same way, but 
>maybe this is a case where we simply need to communicate the method 
>more clearly, show better examples, etc.  And simply clarify the text 
>of the RFC.
>
That may be the real problem. I know of one vendor that always adds time
zone to time zone independent holidays (New years day for example).

>They exist as  anniversary, DTSTART/DTEND with time zone and 
>DTSTART/DTEND wo/time zone.
>
>All three have distinct differences:
>
>    Anniversary:
>                All day - never shows up as opaque (Birthday)
>                Has DTSTART with VALUE=DATE and does not include DTEND 
>or DURATION.
>                I do not think that we can eliminate this one.
>
>    DTSTART/DTEND with TZ:
>                All day in specific time zone.  An event that consumes 
>specific time
>                relative to UTC that just happens to exactly overlap 
>one day in a specific time zone.
>                This one can not be eliminated as it is really just any

>kind of VEVENT that just
>                happens to span 24 hours.
>
>    DTSTART/DTEND with out TZ
>               All day in viewers local time.  (New Years day is local 
>to viewer)
>               I do not think we can eliminate this one.
>
>So what is the conflict or addition?
>
>  
>

-- 

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 09:32:52 2004

>or whether it has hours or minutes.  Let's not make dependencies on

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.

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

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

>gleaned from DTSTART and ( DTEND or DURATION - which are mutually
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.

-- 

-------------- 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/fdb7556a/smime.bin