Subject: Re: Where to put VTIMEZONE and VALARM?

From: [email-masked]
Date: Tue, 24 Apr 2001 15:01:11 -0400

Eric wrote:

>So request #1 for this mail is:
>
>                Can we change RFC2446 to allow the VALARM to be a child 
of a
>                VEVENT or VTODO?
>
>That is, make RFC2446 agree with the storage model in the CAP draft.

That also makes it agree w/the implicit model from 2445.  Its another 
restriction table bug I think.  I dont think that the iTIP editors ever 
meant to imply that VALARMs were at the same containment level as VEVENTs, 
VTODOs, etc.

>So, the second request is: 
>
>                Can we change the storage model to allow VTIMEZONES to be 
children
>                of VEVENT, VTODO and VJOURNAL?

This would put the storage model at odds with containment model specified 
in 2445.  Since more than 1 VEVENT can share the same TZID then you just 
get bad data bloat.  Besides that kind of containment change is not as 
intuitive as the EVENT/ALARM model we already know and love...

I would like to see the root of the problem resolved in a more model 
friendly way. 

>This means that if you have two VTIMEZONES with the same TZID,
>but different RRULES ( presumably from two different users working with
>different version of a timezone database ) then you will have a conflict
>when the VTIMEZONES go into the VCALENDAR. 

I think you mean that the VTIMEZONE has > 1 VDAYLIGHT or VSTANDARD that have 
different RRULEs.  Thats fine.  The one with the most recent "effective 
date" superceedes the one with the earlier "effective date", just check 
out the text under Section 4.6.5 Time Zone Component and the example on p65.

Perhaps you mean that 2 different streams have 2 VTIMEZONEs with the same 
TZID but different rules (but _identical_ effective dates)?  That could be 
a problem.  If the TZID is a standardized one (ugh) then we have a 
versioning problem and thats not in scope for this thread.  If its a 
non-standardized TZID then Id suggest some other behaviour is necessary 
(like rewriting one TZID to be different or matching the newer TZID to an 
existing one that has the same/similar defintion, etc).  However I dont 
think this probelm calls for reworking the containment rules in 
iCalendar/iTIP just yet... 

Bruce
PS: You had 2 VCARs at under "Calendar Store"; you only need 1.
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: "Graham Gilmore" <[email-masked]>
Date: Tue, 24 Apr 2001 15:44:34 -0400

----- Original Message -----
From: <[email-masked]>
To: "Eric Busboom" <[email-masked]>
Cc: <[email-masked]>
Sent: 24 April, 2001 15:01
Subject: Re: Where to put VTIMEZONE and VALARM?

> >                 Can we change the storage model to allow VTIMEZONES
to
> be children
> This would put the storage model at odds with containment model
> specified in 2445.  Since more than 1 VEVENT can share the same TZID
> then you just get bad data bloat.

    At first glance, I saw it this way too; but looking at Eric's
proposed model:

          Calendar Store
            |
            +-- VCARs
            +-- Properties
            +-- VCARs
            +-- VTIMEZONEs
            +-- VCALENDARs
                  |
                  +--VEVENTs
                       +--VALARMs
                       +--VTIMEZONEs
                  +--VTODOs
                       +--VALARMs
                       +--VTIMEZONEs
                  +--VJOURNALs

    VTIMEZONEs are still present where they were before, they've just
been added (optionally) under the VEVENT and VTODO (etc.) components.
This would allow the majority of your VEVENTs to share a single
VTIMEZONE, with any strange ones that use conflicting VTIMEZONEs (as
Eric describes*) would 'internalize' their own VTIMEZONE (which would
override the one in the 'outer scope', I assume).
    However, I agree that this isn't necessarily the way to go :)

*Eric describes:
"This means that if you have two VTIMEZONES with the same TZID,
but different RRULES ( presumably from two different users working with
different version of a timezone database ) then you will have a conflict
when the VTIMEZONES go into the VCALENDAR. "

> Perhaps you mean that 2 different streams have 2 VTIMEZONEs with the
> same TZID but different rules (but _identical_ effective dates)?  That
> could be a problem.

    I believe this is the case Eric was referring to.

> If the TZID is a standardized one (ugh) then we
> have a versioning problem and thats not in scope for this thread.  If
> its a non-standardized TZID then Id suggest some other behaviour is
> necessary (like rewriting one TZID to be different or matching the
newer
> TZID to an existing one that has the same/similar defintion, etc).

    I would suggest in both cases that one of the TZIDs could be
modified.  Even if the VTIMEZONEs refer to (hypothetically) some entry
in a global database, then one of the entries supersedes the other, and
this can be verified by examining the LAST-MODIFIED property in the
VTIMEZONEs (I would suggest making this field a MUST in RFC 2445 if the
TZID refers to a global database of some kind; it is currently
optional).  The older one in that case no longer refers to an up-to-date
timezone entity, and could safely be renamed.

    Graham