Re: [Tzdist] OPPOSE Time Zone Data Distribution Service / draft-ietf-tzdist-service-09

Tobias Conradi <tc@tobiasconradi.com> Tue, 21 July 2015 19:50 UTC

Return-Path: <tobias.conradi@gmail.com>
X-Original-To: tzdist@ietfa.amsl.com
Delivered-To: tzdist@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753451B2B28; Tue, 21 Jul 2015 12:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH_BYTgtcyTR; Tue, 21 Jul 2015 12:49:58 -0700 (PDT)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC971A9043; Tue, 21 Jul 2015 12:49:57 -0700 (PDT)
Received: by qged69 with SMTP id d69so63895401qge.0; Tue, 21 Jul 2015 12:49:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Xy5SKx69n5Ew7Y8yhw4x6EPO/P2eB7qcVZhqK0XhkdM=; b=D4EMLnw7qfn8D85ushdUKvIRY6kb+C+MTXZnl8jvMFnAXHS9v4zNCPwWqnl5AylbmH S8Xey9hAuod8i4kiUA5MdFsRECBZVgMnuCKbUx0oIPocKVtH6lU2v3MEzr7QsGGKs8ww OTaNPM/0XzixOQcQHl2k2ZOZf8es0EaWkoyrveCkrFvs8T4aTWt5KGU2vGtJ6OZd6r7A /bCKPSRw6j1sXxkhuy87+Uairra6ZWneq3MmSLlq+Wy+OHJxO3Bt4ggBzBVkM62rUASf j2dZU0WMkivdjPsTYymA5H1dAvKAz9vGJI5POstCDnB600X3qoUMT7HeL9+jntcUIFFr 396w==
MIME-Version: 1.0
X-Received: by 10.140.39.17 with SMTP id u17mr57526133qgu.5.1437508196434; Tue, 21 Jul 2015 12:49:56 -0700 (PDT)
Sender: tobias.conradi@gmail.com
Received: by 10.140.99.71 with HTTP; Tue, 21 Jul 2015 12:49:56 -0700 (PDT)
In-Reply-To: <55AE9AB0.3080008@cisco.com>
References: <CAAGevbWvzDSRWCM5M=7Ra4tM=Oo_KKY2OaBsPuVSbpE=b7_1Bg@mail.gmail.com> <55AE9AB0.3080008@cisco.com>
Date: Tue, 21 Jul 2015 21:49:56 +0200
X-Google-Sender-Auth: 1FDOghjTEEGry8li63twKmFQ0Y4
Message-ID: <CAAGevbWwn1M1iSmx=7u2pUgVghrCpVqC_HEMLZze7zP0vnVOAQ@mail.gmail.com>
From: Tobias Conradi <tc@tobiasconradi.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/u0_nqjkT-pVtRYukJcf0MqTd5hY>
Cc: draft-ietf-tzdist-service.ad@ietf.org, draft-ietf-tzdist-service@ietf.org, draft-ietf-tzdist-service.shepherd@ietf.org, tzdist-chairs@ietf.org, Time Zone Data Distribution Service <tzdist@ietf.org>
Subject: Re: [Tzdist] OPPOSE Time Zone Data Distribution Service / draft-ietf-tzdist-service-09
X-BeenThere: tzdist@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <tzdist.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tzdist>, <mailto:tzdist-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tzdist/>
List-Post: <mailto:tzdist@ietf.org>
List-Help: <mailto:tzdist-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tzdist>, <mailto:tzdist-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2015 19:50:00 -0000

> To be clear, both WGLC
> and IETF last call have come and gone.
Demonstrating the inability or unwillingness of the involved, to have
a stringent document.

> This being said, we agreed
> that in textual descriptions,
> "time zone" and not
> "timezone" should appear.
And the intuitive way would be to derive other forms from that.

> This does not hold for any
> normative on-the-wire or ABNF.
Of course not. But the agreed term should be the source term and
converted in the same way as other terms are.

> I would prefer the document
> to be stable.
Then it should not be adopted as an RFC.

Given there is "IANA - Not OK", IANA still has a chance to stop what
Douglas, Daboo, WGLC and IETF currently offer.

On Tue, Jul 21, 2015 at 9:17 PM, Eliot Lear <lear@cisco.com> wrote:
> Tobias,
>
> To be clear, both WGLC and IETF last call have come and gone.  This
> being said, we agreed that in textual descriptions, "time zone" and not
> "timezone" should appear.  This does not hold for any normative
> on-the-wire or ABNF.  In as much as the authors agree with any of the
> other editorial points you've raised below, they will address them in
> the forthcoming version.  But they are editorial in nature and at this
> point I would prefer the document to be stable.
>
> Eliot
>
>
> On 7/21/15 5:24 PM, Tobias Conradi wrote:
>> OPPOSE
>>
>> Non-exhaustive list of reasons follows.
>>
>> 1) Concept of Time Zone Data Distribution Service
>>
>> Time zone data (TZD) is iCalendar data, so a iCalendar Data
>> Distribution Service could cover the TZD distribution.
>>
>> Note, that there is already bloat, e.g.
>> https://tools.ietf.org/html/rfc5545 (iCal)
>> can be converted to XML
>> https://tools.ietf.org/html/rfc6321 (xCal)
>> but then instead of using a general conversion from XML to JSON a
>> second transformation from iCal exists:
>> https://tools.ietf.org/html/rfc7265 (jCal)
>>
>>
>> 2) The name of the service
>> does not agree with the abstract
>>
>> "delivery of time zone data and leap second rules"
>>
>> Are leap seconds part of time zone data? If yes, then remove from
>> abstract. If no, then adjust the name of the document. E.g. Time Data
>> Distribution Service.
>>
>>
>> 3) Orthography
>> Does capitalization follow any rule, if so which?
>>
>> 4.2.1.1. Time Zone Data Distribution Service SRV Service Labels
>> but
>> 4.2.1.2.  Time Zone Data Distribution Service TXT records
>>
>> 5.1.1.  Example: Get Capabilities
>> but
>> 5.3.1.  Example: Get time zone data
>>
>>
>> 4) The setup of draft-ietf-tzdist-service-09
>>
>> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-7
>> defines new iCalendar properties, but they are used already in
>>
>> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-5
>>
>>
>> 5) Naming of new iCalendar properties and section
>>
>> 7.1. Time Zone Upper Bound
>> does not agree with TZUNTIL
>>
>> 7.2.  Time Zone Identifier Alias Property
>> does not agree with TZID-ALIAS-OF
>>
>> Either add the "of" to the section name, or remove it from the property name.
>>
>> Also, why does one have "Property" at the end, the other not?
>>
>> Compare
>> https://tools.ietf.org/html/rfc5545#section-3.8.3
>>
>> 3.8.3.1. Time Zone Identifier = TZID
>> 3.8.3.2. Time Zone Name = TZNAME
>> 3.8.3.3. Time Zone Offset From = TZOFFSETFROM
>> 3.8.3.4. Time Zone Offset To = TZOFFSETTO
>> 3.8.3.5. Time Zone URL = TZURL
>>
>> Analogous would be:
>> TZIDALIASOF or TZIDALIAS
>> TZUPPERBOUND
>>
>> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-3.7
>> has "Time Zone Aliases" instead of "Time Zone Identifier Aliases"
>>
>>
>> 6) TZD properties not declared to be new iCalendar properties
>>
>> Why are some declared to be new iCalendar properties and others not?
>>
>> Naming issues:
>>
>> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-3.8
>> "3.8. Time Zone Localized Names"
>> but
>> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-5.2.1
>> "local-names"
>>
>>
>> 7) Spaces in JSON
>> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-5.2.1
>> =======
>> "timezones": [
>>    {
>> "tzid": "America/New_York",
>> "etag": "123456789-000-111",
>> "last-modified": "2009-09-17T01:39:34Z",
>> ...
>> "local-names": [
>>
>> =======
>> Document has
>> time zones -> timezones
>>
>> instead of
>> time zones -> time-zones
>>
>> which would match
>> last modified -> last-modified
>> local names -> local-names
>>
>>
>> 8) Service name registrations
>>
>> https://tools.ietf.org/html/rfc6335#section-5.1
>> hyphen is allowed, the base name is "time zone" - therefore
>>
>> timezone and timezones
>> instead of
>> time-zone and time-zone-s
>> is introducing unnecessary inconsistencies and ambiguities.
>>
>>
>> 7+8)
>> timezones in the document may mean
>>
>> time-zones / time zones
>> OR
>> time-zone-s
>>
>>
>> 9) timezone Well-Known URI Registration
>> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-10.2
>>
>> URI suffix:  timezone
>>
>> The term is "time zone", so the space should be converted like for other in
>> http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
>> resulting in "time-zone"
>>
>>
>> 10) IANA Considerations
>> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-10.1
>> IANA is asked to create a new top-level category called "Time Zone
>>    Distribution Service (TZDIST) Parameters"
>>
>> contradicts document name "Time Zone Data Distribution Service"
>>
>> What is distributed is time zone data, not the time zones? Otherwise
>> change the document name.
>>
>> 11) synctoken
>> No definition of format. Examples only show time stamps.
>>
>> Contradicts "Privacy Considerations".
>>
>>
>> 12) Privacy Considerations
>>
>> Randomize the order in which individual time zones are fetched
>>        using the "get" action, when retrieving a set of time zones based
>>        on a "list" action response.
>>
>> Less leaking would be a standard order?
>>
>>
>> 13) Overbearance
>> I don't know what the best translation for the German "Anmaßung" is here.
>>
>> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-8
>> "Servers providing a time zone data distribution
>> service MUST support HTTP
>> over Transport Layer Security (TLS)"
>>
>> There are a lot of use cases where this is not needed. The document
>> itself allows it: "Servers MAY support a time zone data distribution
>> service over HTTP without TLS."
>>
>> Requiring it will only lead to TZDDS servers that are not fully
>> compliant with the document. Rendering the document less
>> authoritative.
>>
>>
>>
>>
>
>



-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com