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

[Doug Royer <[e-mail]>]

On 12/12/2014 02:21 PM, Lester Caine wrote:
> On 12/12/14 18:48, Doug Royer wrote:
>> 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.
> All that is needed with the event is a version tag ... a single extra
> element. This then assumes VTIMEZONE is populated by other means - such
> as tzdist :)

For those of you that have been very active on this list for a while
  - I applaud you patience as I try to understand the draft for the 
first time.
   Thank You All!

(Not talking CALDAV - talking the process). It will not do any good if 
there is no way to
refer to everything that is needed and I am going through the process 
step by step
in my head to make sure I have everything I need.

I agree that TZID is not sufficient unless it contains source 
information about the source
of the TZID. TZURL is in 5545 and it seems a logical usage for tzdist, 
yet I can not find it
in the draft-service or draft-caldav. (maybe this is to be covered in a 
later draft?)

Was it the intention that TZURL be mandated in events when not including 
VTIMEZONE
so you can find the TZID definition used by the originator? In some 
later draft?

For version, how about add a parameter to TZURL that contains the 
last-modified value
from that URL as the version?

     
TZURL;LAST-MODIFIED=20121212T201329Z:http://zones.example.com/tz/America-New_York.ics

*Or* another way it could be done is to add it as a parameter to the URL:

TZURL:http//zones.example.com/tz/America-New_York.ics?last-modified=20121212T201329Z

The URL parameter would not require an update to the TZURL ABNF.

Then at least you know the VTIMEZONE the organizer intended, the source 
of the TZID
and their version. It allows for checking against your cache. And it 
allows for some
out of band discussion about the organizer not having the newest version 
of the TZ data.

When checking against your cache, you check against the URL host+path 
and last-modified
in your cache. You can always fetch the newest version from the URL to 
determine if there have
been any TZ data updates.

The TZURL would also allow for disambiguation of TZID values as described
in draft-service, section 3.5

The HTTP GET could be modified to allow for fetching by last-modified.
Would this ever need to be done? It would allow for anyone to get the 
version
the organizer was using. Or is it sufficient to know they (or you or 
both) are
out of date and renegotiate the meeting times?

     GET /zones/America%2FNew_York
                    ?last-modified=20121212T201329Z


>> 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.
> ... My MAIN reason for wanting a managed version tracking
> process is exactly because I may well be working off-line for hours
> while travelling, and then using a different tzdist server at my
> destination ...

Yes!

-- 

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