Subject: Re: VTIMEZONE in CAP

From: [email-masked]
Date: Tue, 21 Jan 2003 17:41:27 -0500

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: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Andrea Campi <[email-masked]>
Date: Thu, 23 Jan 2003 14:55:43 +0100

> Im sorry but I dont understand the question.

Let me rephrase it - how do we handle VTIMEZONE in the context of CAP?

> for DATE only types.  For example:
[...]
> This is a valid all day event w/no associated TZ. 

Language issue again. I meant: "do we need to always include the VTIMEZONEs
(if any") the component references? 

> > must exist in the CAP store. 

Note that I was specifically referring to SEARCH (that's why I said, the CUA
needs to retrieve VTIMEZONEs once).

> kind of requirements change to 2445/2446.

No, I don't consider TZ info to be administrative stuff; VTIMEZONEs
can be stored normally in a VCALSTORE or in a VAGENDA, or retrieved
from there, so I see no reason to handle them differently from other
components.

I'm not saying a CUA can't or shouldn't send VTIMEZONE along in any iTIP
message it wants to store on the server. I'm simply saying:

 - when storing components, the CUA can omit the VTIMEZONE,
as long as any TZID the components references are present in the TARGETs
or in the enclosing CALSTORE.

 - if the CUA sends VTIMEZONEs to the CS (along or together with
other components that reference them), the CS checks if they are
new or updated versions, if so it stores them

 - when a CUA retrieves a component, the CS can omit the VTIMEZONE

 - the CUA should retrieve the VTIMEZONEs from the CS at most once
per session, and could probably cache them at least until the CUA is
closed. The CUA should use LAST-MODIFIED to check for updated
VTIMEZONEs.

The advantage of course is reduced network and processing load for
sending and processing data that changes very infrequently.

iTIP messages do complicate matters, as a CUA may want to be able to
forward them as they are (for example, by simply encapsulate them in
iMIP). So we probably need a parameter for this, so that a CUA can
specify on each SEARCH whether it wants the VTIMEZONE or not. Or
it could be a CAPABILITY.

> the Admins have not kept their TZ tables updated) then what should happen? 

The CUA should send it along and the CS would store it.

> iTIP stream?  Or would it have to be stored by some Admin first?

I'm not sure I understand what you're saying here, but it the TZID
is new or updated the CUA must send it and the CS must store it.

At the end of the day, the way I see it is, RFC2445 and RFC2446 can
be interpreted as requiring the VTIMEZONE to be in scope; the scope
they consider is the enclosing VCALENDAR. I am proposing to extend
this to consider the session between a CUA and a CS as the scope,
so that they only need to exchange this data once.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: John Stracke <[email-masked]>
Date: Thu, 23 Jan 2003 09:30:15 -0500

>Let me rephrase it - how do we handle VTIMEZONE in the context of CAP?
Exactly the same as in any other iCalendar context.

>(if any") the component references?
Yes, we do; otherwise, the component is not a legal VCALENDAR.

>or in the enclosing CALSTORE.
And how does the CUA know that the VTIMEZONE stored in the CS is 
identical to the one the CUA knows? Timezone definitions do change.

Besides, TZIDs aren't globally valid; we cannot assume that the same 
TZID from two different components refers to the same VTIMEZONE.  As an 
extreme example, it would be perfectly legal for a CUA to assign TZIDs 
on the fly as it composed its VCALENDARs, so that the first VTIMEZONE in 
the VCALENDAR would always have a TZID of 1, the second would have a 
TZID of 2, etc.  In that case, trying to extend the scope of those TZIDs 
beyond the VCALENDAR would be catastrophic.

As a less extreme case, the same TZID from two different CUAs might 
refer to two different timezones--for example, if you have two CUAs 
written by parochial-minded people in the US and Australia, they both 
might have TZIDs of "Eastern" referring to two radically different 
timezones.

-- 
/==========================================\
|John Stracke      [email-masked]   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|Illiterate? Write today for free help!    |
\==========================================/

---

From: Andrea Campi <[email-masked]>
Date: Thu, 23 Jan 2003 16:06:50 +0100

[...]
> might have TZIDs of "Eastern" referring to two radically different 

Uhm... ok, you convinved me. That's too bad, but you're right, so
I'll drop my argument.

Bye,
	Andrea

---

From: Andrea Campi <[email-masked]>
Date: Fri, 24 Jan 2003 11:56:27 +0100

> identical to the one the CUA knows? Timezone definitions do change.

Ok then - what use are VTIMEZONEs in CALSTORE and VAGENDAs? The
CUA can't refer to them anyway.

Bye,
	Andrea

---

From: John Stracke <[email-masked]>
Date: Fri, 24 Jan 2003 09:24:27 -0500

>CUA can't refer to them anyway.
Hmm.  VCALENDARs can't refer to them, but I suppose it might be useful 
for a thin CUA to have access to a large supply of VTIMEZONEs, for use 
in composing new VCALENDARs, without having to store them all.

-- 
/=======================================================\
|John Stracke      [email-masked]                |
|Principal Engineer|http://www.centive.com              |
|Centive           |My opinions are my own.             |
|=======================================================|
|Two words that do not go together: "Memorial Cookbook".|
\=======================================================/

---

From: [email-masked]
Date: Fri, 24 Jan 2003 17:12:10 -0500

> Let me rephrase it - how do we handle VTIMEZONE in the context of CAP?

VTIMEZONEs are components just like VEVENTS, VTODOS, VALARMS, VCARs, etc. 
You can create/modify/delete them using the same commands.

> (if any") the component references? 

From 2445, Section 4.2.19 Time Zone Identifier:

                                  An individual "VTIMEZONE" calendar
   component MUST be specified for each unique "TZID" parameter value
   specified in the iCalendar object.

so the CUA MUST send the TZ info useful for the entry its 
creating/modifying.  There is also the often overlooked requirement in 
Section 4.6.5 Time Zone Component:

   The "VTIMEZONE" calendar component MUST be present if the iCalendar
   object contains an RRULE that generates dates on both sides of a time
   zone shift 

too to consider.

> from there, so I see no reason to handle them differently from other

Well, there is no provision for creating or initing the DEFAULT-TZID or 
other 'default' properties of the VCALSTORE so Im guessing that its 
classified as "Administration" and OOB. 

Its not "Administration" if my CUA can create any VTIMEZONE it wishes in 
the VCALSTORE or VAGENDA but there is no provision for dealing with the 
defaults apart from reading them out.

I agree though that they should be treated just like any component and 
that they can be dealt with in the context of an entity (ie: a VEVENT) or 
standalone.

> or in the enclosing CALSTORE.

That, as you probably know, would require a change to RFC 2445.  If one 
does not consider omitted features like iTIP failover (or 'fanout' or 
fallback or whatever) then this could be a simple change (in multiple 
places).  The change would NOT be to remove the requirement entirely from 
iCalendar but to modify it so that it MUST be sent if it does not exist in 
the CS or VAGENDA. 

BTW: Is there any text anywhere in CAP addressing merge/conflict 
resolution between VTIEMZONEs at the CALSTORE and VAGENDA level?  I cant 
find any talk of comparison, etc.  A VTIMEZONE can have mulitple yet 
distinct STANDARD and DAYLIGHT components so its not just checking (UID, 
SEQUENCE, DTSTAMP, RECURRENCE-ID) like on a VEVENT, subcomponent changes 
need to be analyzed, etc...

> new or updated versions, if so it stores them

Having the correct, matching VTIMEZONE info sent w/the iCalendar stream is 
ALWAYS a safe thing to do.  It precludes the CS making a incorrect 
inferrence based on just the name.  Thats why it was mandated in iCalendar 
originally, in case my US-Eastern was different than your US-Eastern. 
After all the CU/CUA creating it may have a different VTIMEZONE than the 
recipient and so the safest way to avoid TZ related mixups was to send the 
creators definition of the TZ along.  It costs a few more bytes in the 
data stream but it ensures workflow integrity.

>  - when a CUA retrieves a component, the CS can omit the VTIMEZONE

Err, not a good idea on the 'reading' side of the operation to do this. 
The CUA can apriori query the CS for VTIMEZONEs just fine so it knows to 
omit them (sic) BUT the CS has no clue what TZs the CUA has so omitting 
them when a CUA reads the data out is therefore NOT safe.  Doing so would 
require the CUA to turn around and to a query for the proper VTIMEZONE 
info from the CS (and that then assumes that the CS knows which VTIMEZONE 
to return, the one from the CALSTORE or the one from the VAGENDA!!).

> closed. The CUA should use LAST-MODIFIED to check for updated

Hmmm, I just had a flicker of anxiety here. 

A VTIMEZONE is a special kind of container in that it can have multiple 
subcontainers (DAYLIGHT & STANDARD) that augment each other.  So, its 
possible that a VTIMEZONE is updated with a new DAYLIGHT when the TZ shift 
rules change (ie: the government changes them for next year).  As such, 
the LAST-MODIFIED value will change but the relevant STANDARD/DAYLIGHT 
subcomponents actually do not (assuming you are not scheduling into the 
new DAYLIGHT time frame, etc).  As such, using LAST-MODIFIED is not 100% 
useful in doing the check if a VTIMEZONE changed or not.  Yes, it did 
change but the change may not actually affect the related VEVENT.  (Net 
effect: the CUA will resend a VTIMEZONE with DAYLIGHT and STANDARD 
subcomponents that match the CS's copy)...

> The CUA should send it along and the CS would store it.

At the CALSTORE or VAGENDA level?  I cant find any text on when a 
VTIMEZONE is (or should) be saved at the CALSTORE level and when its 
stored at the VAGENDA level.  Im guessing that all CU stored VTIMEZONEs 
are expected to be at the VAGENDA level but thats just an assumption on my 
part about the most likely case...

> is new or updated the CUA must send it and the CS must store it.

You're ahead of the ball in your quandry. 

If my CUA crafts an iTIP message w/an updated VTIMEZONE and sends it to 
you then is that VTIMEZONE considered to be "in the CAP store" by virtue 
of the fact that its in the iTIP message (assuming no magic happens to 
pull the VTIMEZONE out of the iTIP message when its delivered).  Asked 
another way, if your CUA pulled down just the VEVENT that I sent you then 
could your CUA later get the matching (and correct) VTIMEZONE info 
separately (ie: query for the VTIMEZONE from the CALSTORE or VAGENDA) OR 
would the CS have to send it w/the VEVENT to your CUA who would in turn 
have to remember to send it back to the CS as an update to some VTIMEZONE 
in the store?

Just how/when would the new info in my iTIP message become an actual 
stored and queryable VEVENT and VTIMEZONE?

> they consider is the enclosing VCALENDAR. 

Yup.  For workflow integrity reasons this was deemed necessary.

>                                            I am proposing to extend

This can be done but all the boundarys need to be fully identified. 

I think there are some duality issues or just murky areas that are not 
fully explored (or at least described).  For example, how does the CUA 
know to use the TZID=US-Eastern from the VAGENDA and when to use the 
TZID=US-Eastern from the CALSTORE?  If a change is made to the VTIMEZONE 
definition that affects actual entries (ie: a new DAYLIGHT subcomponent is 
added that changes when the shift occurs at some point in the future) then 
what happens to those entries and the TZ info they were created using? 
That is, if the shift occurs 2 weeks later than the previously used 
DAYLIGHT subcomponent was defined for then will the affected VEVENT have 
its affected RDATE updated to reflect the change or not?  If not, is there 
any consideration towards preserving the originally used DAYLIGHT info 
only (in relation to that affected VEVENT _only_!)??

Hmm, VTIMEZONEs seem to be an area that needs some more cycles.  Im out of 
caffine and time for today though...

Bruce