Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

[Cyrus Daboo <[e-mail]>]

Hi Doug,

> *QUESTION 1:* Given:
>
> The DTSTAMP property gets updated each time a VTIMEZONE is
> *instantiated*, not updated.

Well that's an incorrect assumption given that RFC5545 does not in fact 
define DTSTAMP as a required or optional property for use in VTIMEZONE.

> Question 1 issue:  (A) I  am confused (DTSTAMP vs LAST-MODIFIED) and
> VERSION:
>
>      draft-tzdist says in 5.4 "expand" Action
>
>          ... *changedsince*  OPTIONAL, but MUST occur only once.  If
> present, its
>           value MUST be taken from the "dtstamp" result of a previous
>           expand result.  If the targeted time zone has not changed over
>           the expansion range queried in the request, then the server
>           MUST return a 304 HTTP status response.
>
> So, if your going to use it for version, then each time I 'expand' query,
> I get a new version, because each new VTIMEZONE reply has a new
> instantiation time and would have an updated DTSTAMP?

changedsince has been removed from the expand action (latest draft) since 
ETag is actually sufficient for detecting expand changes. changedsince is 
only present in the list action.

> *QUESTION 2:*
>
> And how at event generation time would VERSION be put into a VEVENT so
> that it can be sent to a CUA to understand (as in update ABNF to 5545?)?
> The ultimate goal is provide the CUA with sufficient information to get
> any missing TZID or TZID/version and verify it is the same TZID used by
> the organizer.
>
> Are you saying the VERSION would be placed in the events  also so that
> CUAs can check their cache for having the same version? If not in the
> organizers sent event, then how does it help me determine if I have the
> latest version?

That is a question for iCalendar, not tzdist (though we may decide it is 
better to define any new property in tzdist as we did with the TZUNTIL and 
TZID-ALIAS-OF). Note that since we are currently not proposing to change 
iCalendar/iTIP to deal with this issue it is moot. We are proposing 
changing CalDAV - but there everything is simple because the requirement is 
that the CalDAV server advertises what tzdist server is in use (with the 
assumption being that is readily accessible to all clients using the CalDAV 
server) - so the clients are all "sync'd" in regard to what the time zones 
should be - namely the latest ones provided by the referenced tzdist server 
(which is what the CalDAV server will be using). If/when we decide to 
change iTIP to allow skipping of the VTIMEZONE component, then we can add 
what is necessary to ensure both sides of the exchange have what they need 
to detect mismatches.

-- 
Cyrus Daboo