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
- [Tzdist] OPPOSE Time Zone Data Distribution Servi… Tobias Conradi
- Re: [Tzdist] OPPOSE Time Zone Data Distribution S… Eliot Lear
- Re: [Tzdist] OPPOSE Time Zone Data Distribution S… Tobias Conradi
- Re: [Tzdist] OPPOSE Time Zone Data Distribution S… Cyrus Daboo