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

[Doug Royer <[e-mail]>]

On 12/11/2014 06:55 PM, Lester Caine wrote:
> On 11/12/14 22:00, Doug Royer wrote:
>> For a PUBLISH event:
>>
>>      Using the existing method:
>>
>>          Only one CUA is really in play as other CUAs must periodically
>> check for updates
>>          (REFRESH or reload a file).
> Please point me to some RFC for 'CUA' ... all may calendar material is
> published using TZ as distributed via PHP, and it is ensuring that
> clients have the same version of TZ that I'm working towards currently.

CUA - Calendar User Agent: RFC 5545.

>>          If the organizer CUA does not see the TZ update or update the TZ
>> data in the event,
>>          things are busted and there is no documented way to solve the problem
>> VTIMEZONE has a 'last-modified' entry which would match the timestamp of
>> a published version of TZ data. As has been said, the vast majority of
>> published events that timestamp would be 'day one' and offsets will
>> never change. It is only a small number of events that may be a problem
>> and even without tzdist we can document a way to manage that problem.
If your *not* sending the VTIMEZONE with the VEVENT,  then there is no 
last-modified to see or compare to. Your just guessing and hoping the 
other end is using the latest version.

Many of my customers have off-line secure systems and the updates to the 
TZ database will be manual. An outsize URL *only* is useless to me. I am 
sure I am not the only one that will need to work with mostly off-line 
systems.

They can get email, so when I talk calendaring I think iTIP and want to 
make sure the data TZ data that the organizer intended is included.

Currently RFC 5546 includes VTIMEZONE. I have never used CALDAV, I had 
no idea it was non-iTIP compliant.
Is CALDAV iTIP compliant? Or are all CALDAV implementations just 
non-compliant?

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[e-mail]
714-989-6135