Subject: Re: [Tzdist] URL design

From: Daniel Migault <[email-masked]>
Date: Sat, 1 Nov 2014 10:13:19 +0100

Dear Friends and Colleagues,

Thanks you all for your inputs. It seems that consensus has -- almost --
been reached on the URL format as well as publisher's name reservations. I
believe that next step will be based on version 03 of the draft.

BR,
Daniel

On Wed, Oct 29, 2014 at 3:46 PM, Lester Caine <[email-masked]> wrote:

> On 29/10/14 14:27, Lester Caine wrote:
> > This leaves a place open for a simple current tzdist server which only
> > has a small set of generic rules and all links to 'zones' or as aliases.
> ARE as aliases.
>
> i.e. rule is CET and all the 'zones' are aliases to that rule.
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Lester Caine <[email-masked]>
Date: Sat, 01 Nov 2014 16:02:49 +0000

On 01/11/14 09:13, Daniel Migault wrote:
> been reached on the URL format as well as publisher's name reservations.
> I believe that next step will be based on version 03 of the draft.

It plugs almost everything on my todo list ...
Is it in scope to specify that where a particular publisher id is used
it will ALWAYS return the same set of data?

If someone publishes a meeting calendar it will have a publisher/version
tag and that way a new user can pick up the right set, or if a mobile
user moves outside of range of one tzdist server, they know they will
get the same data from a backup.
In essence if they have already cached the current data, they only need
to know that a new version is available, either via 'latest' or via the
update of the tag on the meeting calendar. This does make 'changedsince'
probably redundant unless one is only using a local subset off the data
available, but a 'diff' between versions would do the same thing? I
think that ETag built using publisher and version along with a
truncation range may still provide a means of managing caching the data?
The same type of ETag could be used by the calendar data to automate
access and updates to the tzdist cache being used!

---

From: Daniel Migault <[email-masked]>
Date: Tue, 18 Nov 2014 12:47:54 +0100

Dear friends and Colleagues,

We are asking the WG whether Issue #29
<http://trac.tools.ietf.org/wg/tzdist/trac/ticket/29>: "URL design" has
been addressed by draft-ietf-tzdist-service-03
<http://tools.ietf.org/html/draft-ietf-tzdist-service-03>. Feel free to
give your opinion by Friday 21, so we can cleanup the open issue and focus
our attention on issues that have not been solved yet.

Note also that Ken has provided an implementation of this URL design
<http://www.ietf.org/mail-archive/web/tzdist/current/msg00916.html>, so
please report any bugs or misbehavior. By the way thank you Ken for
providing this implementation.

BR,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58