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

[Tobias Conradi <[e-mail]>]

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