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

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Aug 17 20:00:37 2004

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.

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.

Is this reasonable?

camerost 

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

Cameron Stillion wrote:

>I'd love to see a property for all-day events, but that implies adding 
>to our standard.  Perhaps there's an x- prop that we can encourage use 
>of? A boolean property makes more sense to me than specifying midnight 
>to midnight or a time range of zero.  It is resilient to time zone 
>calculations.
>
>Does anyone else feel strongly about all-day events?
>
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: Tue Aug 17 20:42:03 2004

>end date, and duration of 5 days. By specifying time, you imply that the
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.

>clearly, show better examples, etc.  And simply clarify the text of the
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).

-- 

-------------- 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/20040817/9c032f11/smime.bin