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

From: PStephenson at gw.novell.com (Preston Stephenson)
Date: Wed Aug 18 05:56:39 2004

Sorry, I need more clarification.
I've seen UI's that put all day events in a different place than
appointments.
What is the determine factor that decides to put an appointments as an
all day event?
Being transparent (free or busy-tentative) and having a duration of a
day (or multiple days)?
If a day or multiple day event blocks time, it is displayed with other
appointments?
Transparency alone can't be the deciding factor.
Thanks.
Preston

>>> "Cameron Stillion" <[email-masked]> 08/18/04 6:02
AM >>>

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

_______________________________________________
Ietf-calsify mailing list
[email-masked] 
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Doug at Royer.com (Doug Royer)
Date: Wed Aug 18 10:06:20 2004

>Transparency alone can't be the deciding factor.
TRANSPART means it does not show up in your busy time.

OPAQUE means it does show up in your busy time. 

New CAP TRANSP values coming out:

The TRANSPART-NO-CONFLICT values means it  does not show
up in the busy time and no one is allowed to book that time.

The TRANSPART-CONFLICT values means it  does not show
up in the busy time and the time can be booked.

In all cases it is a  CU discussion not a CUA decision. It
can not be automated all of the time. An implementation
might automate it, another might ask the CU if they
want to allow conflicts or not, so you would need to be
ready for ether case.

The two new values were added in CAP to simplify
the problem where some thought that OPAQUE meant
no-overlapped booking and other thought it meant
overlaps are allowed shows up as busy. It it was
as clarification / simplification that allows different
implementations to understand the intention of
the objects busy and overlapped booking values.

-- 

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