[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VTIMEZONE in CAP
Andrea wrote on 12/18/2002 04:26:03 AM:
> how do you people expect CAP to change the way VTIMEZONE are
> handled according to previous standards?
Im sorry but I dont understand the question.
> For BOOKED components, iTIP is irrelevant, but
when storing or
> retrieving iTIP components I would expect 3.1 of iTIP to be
> mandatory. So we need to always include the VTIMEZONEs the component(s)
> specify?
Not all iTIP messages are for DATE-TIME
or TIME data types; they may be for DATE only types. For example:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
METHOD:PUBLISH
BEGIN:VEVENT
DTSTART;VALUE=DATE:20030214
SUMMARY:Valentines Day Party
END:VEVENT
END:VCALENDAR
This is a valid all day event w/no associated
TZ.
> This seems to be a little bit absurd to me: the
CUA only needs to
> be able to retrieve the VTIMEZONEs from the CS; it can do so once
> per session (and even cache them between sessions).
> I propose we amend 3.1 and interpret 4.2.19 to mean all the VTIMEZONEs
> must exist in the CAP store.
If the CS doesnt have a definition that
arrives w/an iTIP message (because the Admins have not kept their TZ tables
updated) then what should happen? If my new beta CUA sends a METHOD:REQUEST
for a newly added or updated TZID then would that new TZ be considered
"in the CAP store" if its in the iTIP stream? Or would
it have to be stored by some Admin first?
Adding new TZ info is Administration
and thus OOB for CAP 1.0 BUT if we are making a requirement that 'administratively
added' data MUST exist then we need to make sure we consider the all the
cases before making this kind of requirements change to 2445/2446.
Bruce
===========================================================================
Bruce Kahn
INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration
Phone: 978.399.6496
IBM Software Group
FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...