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

Cameron Stillion camerost at exchange.microsoft.com
Wed Aug 18 05:02:07 PDT 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: ietf-calsify-bounces at osafoundation.org
[mailto:ietf-calsify-bounces at osafoundation.org] On Behalf Of Doug Royer
Sent: Tuesday, August 17, 2004 8:42 PM
To: ietf-calsify at osafoundation.org
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
-------------------------------|-----------------------------
Doug at Royer.com                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards





More information about the Ietf-calsify mailing list