Re: [Tzdist] [tzdist] #34 (service): should we include a raw tzdb format media type?

Tim Parenti <tim@timtimeonline.com> Sun, 11 January 2015 01:09 UTC

MIME-Version: 1.0
In-Reply-To: <055.3273bd9c81e7cf06280617afb0cd8dc8@tools.ietf.org>
References: <055.3273bd9c81e7cf06280617afb0cd8dc8@tools.ietf.org>
Date: Sat, 10 Jan 2015 20:09:11 -0500
Message-ID: <CAFpi07y2TM8TdTxyAZe_fB_FSeJGD=JXy3KY_7Xu14TGgGvd-w@mail.gmail.com>
From: Tim Parenti <tim@timtimeonline.com>
To: tzdist issue tracker <trac+tzdist@tools.ietf.org>
Content-Type: multipart/alternative; boundary="001a11c11a8ca46d1b050c560974"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/JRN1EYwFmRWhXQ5Xzj7F1bDxnIk>
Cc: Cyrus Daboo <cyrus@daboo.name>, Time Zone Data Distribution Service <tzdist@ietf.org>, Eliot Lear <lear@cisco.com>
Subject: Re: [Tzdist] [tzdist] #34 (service): should we include a raw tzdb format media type?
Precedence: list

As for my actual thoughts on this matter...

On 7 January 2015 at 16:21, tzdist issue tracker <trac+tzdist@tools.ietf.org
> wrote:

>  I am not fully convinced that this needs to be done in this draft, but I
>  do think it would be a good idea to support the raw format, so that simple
>  systems don't need to do the recompile.  An iPhone will not be the
>  smallest system to run this code, we hope.
>

+1 to all of the above; as Paul discussed at
http://www.ietf.org/mail-archive/web/tzdist/current/msg01192.html, the raw
tz binary is an existing lean format with several potential performance
benefits for small clients.

 In favor of putting the media type in the draft is that we can test
>  whether multiple formats can in fact be supported.  The bad is that it
>  could slow us down just a little, and I would rather not include anything
>  for which there isn't a willingness by someone to write out some code on
>  both ends to test.
>
>  It is possible to include this as a separate draft, but we need to be very
>  comfortable that we haven't made a mistake draft-ietf-tzdist-service that
>  would cause a problem.
>

Wouldn't this slow us down a bit either way?  Both approaches would require
taking the time to write a spec for the format, and then adding it to
-service either directly or by reference.  I'm not sure which approach is
typically better in practice.

I recognize this might be a bit of "scope creep" for this working group,
but if we limit ourselves to simply describing the format as it already
exists, it shouldn't be too bad or set us back by much.  If this is to
happen, I think the folks at tz should at least be included at some point
in the process.  (It is a tz format, after all.)

This is my first working group, so I'm not too familiar with the process
for finalizing drafts, but if others agree that this shouldn't block us in
the meantime, I don't think it should either.

--
Tim Parenti

[Tzdist] [tzdist] #34 (service): should we includ… tzdist issue tracker
Re: [Tzdist] [tzdist] #34 (service): should we in… Paul Eggert
Re: [Tzdist] [tzdist] #34 (service): should we in… Eliot Lear
Re: [Tzdist] [tzdist] #34 (service): should we in… Lester Caine
Re: [Tzdist] [tzdist] #34 (service): should we in… Paul Eggert
Re: [Tzdist] [tzdist] #34 (service): should we in… Lester Caine
Re: [Tzdist] [tzdist] #34 (service): should we in… Tim Parenti
Re: [Tzdist] [tzdist] #34 (service): should we in… Ken Murchison
Re: [Tzdist] [tzdist] #34 (service): should we in… Tim Parenti
Re: [Tzdist] [tzdist] #34 (service): should we in… Tim Parenti
Re: [Tzdist] [tzdist] #34 (service): should we in… tzdist issue tracker