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

[Eliot Lear <[e-mail]>]

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