Subject: Where to put VTIMEZONE and VALARM?

From: Eric Busboom <[email-masked]>
Date: Mon, 23 Apr 2001 20:06:09 -0700 (PDT)

Currently, the CAP draft (-04) has a storage model that says: 

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

-- that is, that VALARMS can be stored in VEVENTs and VTODOS, but
VTIMEZONE are stored in the VCALENDAR. 

Putting VALARMS in the VEVENT makes sense, since it is there is no
other way to associate the VALARM with the VEVENT. Unfortunately, this
seems to be disallowed in iTIP by RFC 2446. It would be nice if the CAP
storage model and the iTIP model agreed

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. 

Currently, a similar problem exists with VTIMEZONE. If you try to put a
bunch of components that you got from remote users into a single
VCALENDAR, the VTIMEZONES are children of the VCALENDAR, not the
VEVENTS. 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. 

So, the second request is: 

	Can we change the storage model to allow VTIMEZONES to be children
	of VEVENT, VTODO and VJOURNAL?

That is, make RFC2446 agree with this model:

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

Then, the conflicting VTIMEZONES could be associated with their events,
and ones that are known to be global can be put at the VCALENDAR
level.  

eric.

---

From: [email-masked]
Date: Tue, 24 Apr 2001 16:39:54 -0400

Graham wrote on 04/24/2001 03:44:34 PM:
>     At first glance, I saw it this way too; but looking at Eric's
> proposed model:
[Snip]
>     However, I agree that this isn't necessarily the way to go :)

Whew!  I get very nervous when a proposed change impacts the overall model 
(and no matter how ya view it, it does propose changing the containment 
model and thats non-trivial.)

Bruce
===========================================================================
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: [email-masked]
Date: Mon, 30 Apr 2001 21:48:16 -0400

eric wrote on 04/29/2001 06:51:02 PM:
> Considering your suggestions that the TZID could be a URI, I am equally
> equivocal.

Actually I didnt suggest that it be a URI.  I suggested it have a parsable 
structure like a URI (unlike PROID that has structure but CUAs should not use it to 
impart any meaning to the data).  Not quite the same suggestion.  Having a 
format thats parsable and extensible is an appealing way to fix some of 
the bubbles under the wallpaper (and to push others to different places).

Bruce

---

From: [email-masked]
Date: Mon, 30 Apr 2001 22:01:10 -0400

Damon replied on 04/29/2001 07:42:07 PM:
> But what happens if a malicious app sends out VTIMEZONEs with the
> same TZIDs as a proper client app? It could mess up your timezone
> database.

Sounds like you are thinking of some spam or C&S bomb attack.  Ill group 
all bogus C&S into the "spam" cateogry for this reply.

Well, if I trash the spam then my CUA wont have to store the faked out 
data and no harm is done.  If it is not C&S spam and I actually want to do 
some C&S w/the sender then the odds are pretty good that they wont be 
using some malicious app that wants to hose my local TZ cache.

So I don't yet see that this is a big problem w/Erics suggestion but 
perhaps Bob or Paul can slap me up side the head and set me right (on this 
guys!)

Bruce