Subject: Re: [Tzdist] #11 Proposal to not define any JSON format

From: Daniel Migault <[email-masked]>
Date: Wed, 24 Sep 2014 14:23:09 +0200

Dear friends and colleagues,

I have seen no comment on JSON format used for version -01. May I suggest
everyone agree on using the  syntax in [I-D.newton-json-content-rules
<http://tools.ietf.org/html/draft-ietf-tzdist-service-01#ref-I-D.newton-json-content-rules>].

Unless comments are raised by Friday 26, I am encline to consider this
issue (#11) fixed.

http://trac.tools.ietf.org/wg/tzdist/trac/ticket/11

BR,
Daniel

On Tue, Aug 26, 2014 at 7:03 PM, Tobias Conradi <[email-masked]>
wrote:

> On Tue, Aug 26, 2014 at 6:51 PM, Lester Caine <[email-masked]> wrote:
> > On 26/08/14 17:29, Tobias Conradi wrote:
> >> A JSON representation of the iCalender format exists, and if this is
> >> lossless then a reference to that representation is sufficient.
> >
> > This does depend on your definition of 'lossless'.
> Mine means, that the iCalendar data can be re-created from the JSON
> representation.
>
> > iCalendar VTIMEZONE
> > changes the data provided by tz in a manor that prevents the original
> > data from being recreated.
> If there is a JSON representation of IANA tz data then, I would assume
> that could also be represented in the iCalendar format.
>
> Maybe you can give an example in JSON of which you think it cannot be
> represented in iCalendar, if there is such.
>
>
>
> --
> Tobias Conradi
> Rheinsberger Str. 18
> 10115 Berlin
> Germany
>
> http://tobiasconradi.com
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Sep 2014 08:28:09 -0400

I'm fine continuing to use the newton draft for specifying JSON 
responses for the time being, but if it looks like the newton draft will 
stall and hold up publication of tzdist-service, I think we should 
switch to using ABNF.

On 09/24/2014 08:23 AM, Daniel Migault wrote:
> I have seen no comment on JSON format used for version -01. May I 
> suggest everyone agree on using the  syntax in 
> [I-D.newton-json-content-rules 
> On Tue, Aug 26, 2014 at 7:03 PM, Tobias Conradi <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Tue, Aug 26, 2014 at 6:51 PM, Lester Caine <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     [email-masked] <mailto:[email-masked]>

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Tobias Conradi <[email-masked]>
Date: Wed, 24 Sep 2014 15:01:05 +0200

On Wed, Sep 24, 2014 at 2:23 PM, Daniel Migault <[email-masked]> wrote:
> I have seen no comment on JSON format used for version -01.
This very email thread started with the proposal not to define things
in JSON. It was made with a reference to the charter.

> May I suggest
> everyone agree on using the  syntax in [I-D.newton-json-content-rules].

Why should anyone agree if it does not fulfill the goals of the charter?

> Unless comments are raised by Friday 26, I am encline to consider this issue
> (#11) fixed.
>

It can be fixed by removing all definitions made in JSON and refer for
an example of a JSON format to
http://tools.ietf.org/html/rfc7265

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 24 Sep 2014 10:20:28 -0400

Hi Tobias,

> http://tools.ietf.org/html/rfc7265

That refers to the JSON format for iCalendar data - and is not sufficient 
to describe things like the capabilities response that tzdist uses. I am 
not convinced it is appropriate to use jCal for the responses to 
list/expand/find actions as there is additional meta-data that tzdist uses 
that is currently not part of jCal and probably should not be. Also, I 
don't think tzdist should depend on (and potentially be limited by) jCal.

The primary issue here is how best to describe the JSON "schema" that we do 
use to describe the data structures we define to make it easier to 
implement and be interoperable.

My personal preference is to see if we can get 
[I-D.newton-json-content-rules] published - perhaps as informational - and 
stick to using that.

Failing that, Barry suggested that we look at 
<http://tools.ietf.org/html/draft-ietf-paws-protocol-18#section-6.1>. 
There, they display a JSON object and then describe it in prose. The one 
concern I have about that is how well one can describe optional elements 
(zero or more, one or more, etc). 
<http://tools.ietf.org/html/draft-ietf-weirds-json-response-09> also does 
something similar.

Personally I don't like the ABNF used in jCal and jCard because it exposes 
much lower level JSON constructs in the schema ("begin-array", 
"value-separator", etc) which I think is overkill for what is needed (but 
it was the best choice back then).

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Tue, 30 Sep 2014 00:52:53 +0200

On Wed, Sep 24, 2014 at 4:20 PM, Cyrus Daboo <[email-masked]> wrote:

> That refers to the JSON format for iCalendar data - and is not sufficient to
> describe things like the capabilities response that tzdist uses. I am not
> convinced it is appropriate to use jCal for the responses to
> that is currently not part of jCal and probably should not be. Also, I don't
> think tzdist should depend on (and potentially be limited by) jCal.

I am not convinced it is inappropriate to use the iCalendar format for
definitions.

Since iCalendar can be expanded with new parameters, the jCal RFC is
probably able to offer a way to convert new values, is it?

> use to describe the data structures we define to make it easier to implement
> and be interoperable.

That primary issue goes away if definition is done in iCalendar format.

People then can choose what they like to use, be it xCal, jCal or whatever.

It is an extra burden for users of the iCalendar format and xCalendar
format that don't also use the jCal format to be forced by this WG to
use JSON.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 30 Sep 2014 08:22:10 +0100

Hi Tobias,

--On September 30, 2014 at 12:52:53 AM +0200 Tobias Conradi 
<[email-masked]> wrote:

>> The primary issue here is how best to describe the JSON "schema" that we
>> do use to describe the data structures we define to make it easier to

No - the problem is what to do with the non-calendar related JSON - 
specifically the capabilities response which is something that we really 
don't want to have new iCalendar components or properties for.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Tue, 30 Sep 2014 09:38:48 +0100

> don't want to have new iCalendar components or properties for.

To which I would add that while the format of a data packet is currently
being converted into the iCalendar style, at the publisher layer
personally I would prefer to retain all the detail of the original
source, so use the TZ original format. While some of the underlying
material may be convertible to be included, the tzdist format can not
rewrite the rules for third party protocols.

-- 
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: Tobias Conradi <[email-masked]>
Date: Tue, 30 Sep 2014 15:41:14 +0200

On Tue, Sep 30, 2014 at 9:22 AM, Cyrus Daboo <[email-masked]> wrote:
> No - the problem is what to do with the non-calendar related JSON
I thought that all what tzdist WG does is calendar related?

> -
That "we" certainly does not include all possible future users of the
TZDDSP (Time Zone Data Distribution Service Protocol).

I was talking about the iCalendar format. When describing the content
in that format requires defining components and properties, then for
the latter use

https://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-8
"8.  New iCalendar Properties"

and for the former create a new section "New iCalendar Components".

It would increase consistency and readability of the document.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Tue, 30 Sep 2014 15:45:44 +0200

On Tue, Sep 30, 2014 at 10:38 AM, Lester Caine <[email-masked]> wrote:

> source, so use the TZ original format.
Of which there might be many. It could also be that some original TZD
format is not open to the public.

> While some of the underlying
> material may be convertible to be included,
I propose to define the protocol in a way that all TZD by any TZDB can
be transmitted.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Sep 2014 15:57:28 +0200

> I thought that all what tzdist WG does is calendar related?

Think protocol-related metadata.

Eliot

---

From: Tobias Conradi <[email-masked]>
Date: Tue, 30 Sep 2014 16:18:33 +0200

> Think protocol-related metadata.
OK. Thank you.

Looking again at
https://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-8
I wonder why this is part of an RFC that is about a service.

It looks as if this is relevant beyond the TZDDSP?

Maybe there should be a WG that enhances iCalendar, independent of the TZDDS.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 30 Sep 2014 15:38:54 +0100

Hi Tobias,

> Maybe there should be a WG that enhances iCalendar, independent of the

It is OK for one spec to add properties that are generally useful beyond 
the scope of that specification. Certainly folks on the calsify mailing 
list will be given the chance to review and comment on the new property. 
Writing a separate spec just for that property would be a waste of 
resources and waiting for it to be included in another more generic 
iCalendar spec would delay tzdist.

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Tue, 30 Sep 2014 17:04:56 +0200

On Tue, Sep 30, 2014 at 4:38 PM, Cyrus Daboo <[email-masked]> wrote:
> It is OK for one spec to add properties that are generally useful beyond the
> scope of that specification.
OK and best practice are different things.

> Certainly folks on the calsify mailing list
> will be given the chance to review and comment on the new property. Writing
> a separate spec just for that property would be a waste of resources and
> waiting for it to be included in another more generic iCalendar spec would
> delay tzdist.
But could bring better result, as it could attract more people that
are interested in date/time keeping.

The tzdist-service document already shows a new definition of time
zone. I formerly have seen this mostly as a "territorial entity", but
here it is defined as a "description [of practices]".

If the TZDDS defining document does create new definitions of objects
it wants to be a service for, it may easily fail to be taken seriously
by people that work with the objects already.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com