Subject: [Tzdist] WG Document Adoption

From: Daniel Migault <[email-masked]>
Date: Tue, 19 Aug 2014 08:58:30 +0200

Dear friends and colleagues,

Our Milestones mention the adoption of the time zone data distribution
protocol draft and CalDAV extension draft as Working Group document.

We propose the adoption of the following drafts. Once these documents are
accepted as WG document, these documents will be discussed, commented until
the WG decides they are ready.

Please let us know if you want these documents or if you have strong
objections to have these documents as a starting point for the WG.
Acceptance or rejection should be based on the global design of the
propositions, not about nits and protocol details. Please let us know your
opinion by Tuesday August 26.

Of course you are welcome to submit comments on these documents, to raise
discussions.
The documents are:
    - draft-douglass-timezone-service-11 [1]
    - draft-daboo-caldav-timezone-ref-01 [2]

Daniel and Eliot

[1] http://tools.ietf.org/html/draft-douglass-timezone-service-11
[2] http://tools.ietf.org/html/draft-daboo-caldav-timezone-ref-01

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 19 Aug 2014 07:55:59 -0400

Daniel, Eliot,

I'm in favor of adopting both documents.

On 08/19/2014 02:58 AM, Daniel Migault wrote:
> We propose the adoption of the following drafts. Once these documents 
> are accepted as WG document, these documents will be discussed, 
> commented until the WG decides they are ready.
>
> propositions, not about nits and protocol details. Please let us know 
> your opinion by Tuesday August 26.
>
> Of course you are welcome to submit comments on these documents, to 
> raise discussions.
> The documents are:
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Daniel Migault <[email-masked]>
Date: Mon, 25 Aug 2014 10:49:46 +0200

Dear friends and colleague,

A lot of comments have been sent on the mailing on the two drafts, and it
seems that the WG agrees on starting with theses two drafts.

However, we would like a more clear support for adoption of these two
drafts, so please respond to this thread today indicating you support  --
or not -- the adoption of these two drafts.

BR

Daniel and Eliot

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

---

From: Lester Caine <[email-masked]>
Date: Mon, 25 Aug 2014 12:25:17 +0100

On 25/08/14 09:49, Daniel Migault wrote:
> A lot of comments have been sent on the mailing on the two drafts, and
> it seems that the WG agrees on starting with theses two drafts.
> 
> drafts, so please respond to this thread today indicating you support 
> -- or not -- the adoption of these two drafts.

Since the definition of the charter has already decided the ground
rules, is there any reason that we could object to these two documents?
It would seem that decisions have already been made as to the way
forward which already precludes a more complete solution which does not
have the restrictions imposed by iCalendar?

Either the service is to provide timezone data in it's entirety, or it
should identify the fact that it is only really intended to support
'modern day' timezone information. But even here, I don't think proper
consideration has been given to passing on current updates to timezone
information in a reliable manor.

I actually object to draft-douglass-timezone-service-11 simply because
it is reliant on a third party document to provide key definitions ...
the RFC5545 provides VTIMEZONE, but in isolation to this document, and
we therefore do not have a standard transfer format that can be used as
a base to provided other formats. The VTIMEZONE format needs a few
tidies to ensure that the tzdist mechanism will work reliably!

I understand the need to make things practical, but taking short cuts is
what has resulted in problems existing for decades simply because there
is not a standard. Even once there is a timezone service available it is
still restricted by how other systems interact with it and since a lot
of the time we have no idea on a clients current timezone simply having
the information available may be pointless?

( Slight aside is VTIMEZONE going to be replaced by VTIME_ZONE ! To my
mind even that 'change' has not been fully reviewed? )

-- 
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

---

From: Dave Thewlis <[email-masked]>
Date: Mon, 25 Aug 2014 06:39:26 -0700

Repeating a previous comment, I support the adoption of the drafts.

Dave Thewlis

--
Dave Thewlis, Executive Director
CalConnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax
http://www.calconnect.org | [email-masked]

On Aug 25, 2014, at 1:49 AM, Daniel Migault <[email-masked]> wrote:

> A lot of comments have been sent on the mailing on the two drafts, and it seems that the WG agrees on starting with theses two drafts. 
> 
> However, we would like a more clear support for adoption of these two drafts, so please respond to this thread today indicating you support  -- or not -- the adoption of these two drafts. 
> 
> BR
> 
> Daniel and Eliot   
> 
> 
> Our Milestones mention the adoption of the time zone data distribution protocol draft and CalDAV extension draft as Working Group document. 
> 
> We propose the adoption of the following drafts. Once these documents are accepted as WG document, these documents will be discussed, commented until the WG decides they are ready.
> 
> Please let us know if you want these documents or if you have strong objections to have these documents as a starting point for the WG. Acceptance or rejection should be based on the global design of the propositions, not about nits and protocol details. Please let us know your opinion by Tuesday August 26.  
> 
> Of course you are welcome to submit comments on these documents, to raise discussions.
> The documents are:

---

From: Ken Murchison <[email-masked]>
Date: Mon, 25 Aug 2014 09:41:59 -0400

Reiterating my support for adopting both drafts.

On 08/25/2014 04:49 AM, Daniel Migault wrote:
> On Tue, Aug 19, 2014 at 8:58 AM, Daniel Migault <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Our Milestones mention the adoption of the time zone data
>     distribution protocol draft and CalDAV extension draft as Working
>     Group document.
>
>     We propose the adoption of the following drafts. Once these
>     documents are accepted as WG document, these documents will be
>     discussed, commented until the WG decides they are ready.
>
>     Please let us know if you want these documents or if you have
>     strong objections to have these documents as a starting point for
>     the WG. Acceptance or rejection should be based on the global
>     design of the propositions, not about nits and protocol details.
>     Please let us know your opinion by Tuesday August 26.
>
>     +33 6 70 72 69 58 <tel:%2B33%206%2070%2072%2069%2058>
>
>
>
>
> -- 
> Daniel Migault
> Orange Labs -- Security
> +33 6 70 72 69 58
>
>

---

From: Paul Eggert <[email-masked]>
Date: Mon, 25 Aug 2014 06:45:59 -0700

I support adoption of the drafts.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 25 Aug 2014 10:44:59 -0400

Hi Lester,

> have the restrictions imposed by iCalendar?

No. We (Mike and I and others at CalConnect) have also had the hope that 
the tzdist protocol could be extended to support delivery of time zone data 
in other formats. In particular, we would like to see zoneinfo data 
delivered directly via tzdist. We have tried to ensure we have enough 
extensibility in the protocol to support that in the future. But for now, 
our focus has been on iCalendar because that is where we have an actual 
demand for this service. In fact, tzdist came about because iCalendar 
vendors with their own web-calendar products had already invented their own 
proprietary tzdist protocol to support web-calendar local time 
calculations. And now we also have CalDAV/iCalendar products that want to 
use the "timezones-by-reference" approach to improve performance (as per 
the other draft being proposed for adoption in this WG: 
draft-daboo-caldav-timezone-ref-01).

> information in a reliable manor.

Isn't it sufficient to advertise the "truncation" dates as we do now? I 
agree that perhaps we should have a clearer idea of the lower bound

> tidies to ensure that the tzdist mechanism will work reliably!

Can you enumerate some specific things you think are missing from 
VTIMEZONE? The fact remains, that for the most part, "consumers" of 
VTIMEZONE are typically focussed on only a small period of time (recent 
past to recent future) as is the nature of events created and managed by 
iCalendar clients.

> the information available may be pointless?

My take on your concerns is that we need to make sure that we have enough 
pieces in the current protocol to support delivering more comprehensive 
time zone data in the future if such formats appear. It definitely seems 
that a more precise way to indicate a lower bound of validity may be needed 
in spite of the fact such a thing does not really exist in iCalendar.

So do you think that the addition of some addition properties to the tzdist 
protocol (excluding VTIMEZONE) would be sufficient to cover the case of 
future, more comprehensive, time zone data formats? If so, can we wait for 
those to be defined in "version: 2" of the tzdist protocol once such data 
formats arise?

> mind even that 'change' has not been fully reviewed? )

No - I have said that I will change "timezone" to "time zone" in 
descriptive text, but I have no intention of forcing protocol elements to 
use split terms (either time-zone or time_zone when spaces are not 
allowed). As for VTIMEZONE, that has been a standard for almost 20 years 
now - it is never going to change. Of course iCalendar could be replaced by 
something different in the future and that can do whatever it wants...

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Mon, 25 Aug 2014 16:55:53 +0100

> agree that perhaps we should have a clearer idea of the lower bound

The grey area I'm still looking at here is not 'truncated' data, but
where a short notice change will affect current meeting times. The
result should be a 'changedsince' return, but because there is no clear
indication that the dtstart on one server will be mirrored on a backup
server, the backup machine may not give a response because it had
already updated prior to the recorded dtstart. Living in an area where I
use multiple network connections depending on what is working, I can see
different machines responding and so while ideally one would only access
one server, that can't be guaranteed? Mobile access may use a different
routing to land line?

> past to recent future) as is the nature of events created and managed by

Some of the 'optional' parts of VTIMEZONE should perhaps be tagged as
required for the server situation? I've identified the pre-timezone
niggle on name, and I think a 'start-date' with the list return covers
the data.

I'm not sure that we can transparently convert VTIMEZONE rules back to
the underlying tz data simply because tz DOES reuse rules across
multiple timezones and that information is lost in translation. A master
server can retain the source material, but a slave server will have to
be able to update only from the expanded data which is where I see a
problem with short notice change 'race hazards'. We get problems with
clients hitting actions within fractions of a microsecond. If timezone
servers are taking half a day to sync ....

> My take on your concerns is that we need to make sure that we have
> enough pieces in the current protocol to support delivering more
> comprehensive time zone data in the future if such formats appear. It
> definitely seems that a more precise way to indicate a lower bound of
> validity may be needed in spite of the fact such a thing does not really
> exist in iCalendar.
> 
> So do you think that the addition of some addition properties to the
> tzdist protocol (excluding VTIMEZONE) would be sufficient to cover the
> case of future, more comprehensive, time zone data formats? If so, can
> we wait for those to be defined in "version: 2" of the tzdist protocol
> once such data formats arise?

Basically as indicated above. I think the useful bit may be 'last-mod'
as a required field in VTIMEZONE which I think has already been flagged
up. Since we would not know who is querying the server, the
last-modified in the 'list' return may not match that of a later
timezone read! And tzname should be included for each rule.

While not essential for offset calculation, storing the comment lines
relating to a rule in a comment entry is possible, but I'm not sure here
is a similar field on the timezonec level of an entry?

> descriptive text, but I have no intention of forcing protocol elements
> to use split terms (either time-zone or time_zone when spaces are not
> now - it is never going to change. Of course iCalendar could be replaced
> by something different in the future and that can do whatever it wants...

Which is MY main aversion to switching back to time zone elsewhere ...

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 25 Aug 2014 22:26:46 +0200

Oppose.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Daniel Migault <[email-masked]>
Date: Tue, 26 Aug 2014 14:45:42 +0200

Dear friends and Colleagues,

Thank you for discussing the protocols for time zone distribution and its
extension for CalDAV described in  draft-douglass-timezone-service-11 [1]
and draft-daboo-caldav-timezone-ref-01 [2].

No strong objection nor protocol deadlocks that could not be leverage have
been raised. Current observed discussions of the time zone distribution
protocols were mostly fine grained discussions/remarks. The documents were
adopted by 3 persons other than the authors and chairs, only one person
opposed without arguing why.

As a result, we consider the following document as adopted:
    - draft-douglass-timezone-service-11 [1]
    - draft-daboo-caldav-timezone-ref-01 [2]

I suggest it is time to discuss the track we have logged during the
previous discussions.

Daniel and Eliot

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

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 26 Aug 2014 09:48:27 -0400

Hi Daniel,

>     - draft-daboo-caldav-timezone-ref-01 [2]

OK. I will publish the existing drafts without changes (other than to draft 
name) as -00 WG drafts so we have those as starting points. After that, I 
will try and put together a quick -01 for the timezone draft with some of 
the trivial changes already logged in trac, so we can have those out of the 
way.

-- 
Cyrus Daboo

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Aug 2014 15:49:52 +0200

If you know there are agreed changes or editorials, please get those in.

On 8/26/14, 3:48 PM, Cyrus Daboo wrote:
> OK. I will publish the existing drafts without changes (other than to
> draft name) as -00 WG drafts so we have those as starting points.
> After that, I will try and put together a quick -01 for the timezone
> draft with some of the trivial changes already logged in trac, so we
> can have those out of the way.
>