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

From: Tobias Conradi <[email-masked]>
Date: Tue, 21 Jul 2015 17:24:38 +0200

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Jul 2015 21:17:04 +0200

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

---

From: Tobias Conradi <[email-masked]>
Date: Tue, 21 Jul 2015 21:49:56 +0200

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

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 22 Jul 2015 22:51:17 -0400

Hi Tobias,

> Distribution Service could cover the TZD distribution.

Delivery of other types of time zone data formats is anticipated.

> does not agree with the abstract

I have no concerns about that.

> Does capitalization follow any rule, if so which?

Typographical and stylist issues will be handled by the RFC editor when 
they process the draft for publication. However, I have gone ahead and 
fixed various section titles in the next draft.

> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-5

The formal definitions of syntax and property registration templates were 
put into their own sections at the end.

> 5) Naming of new iCalendar properties and section

I think there was a discussion of this before and there was no consensus 
for a change. At this point the names matter less than the actual 
definition of what they mean.

> Why are some declared to be new iCalendar properties and others not?

Not sure what you mean by this.

> https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-5.2.1

I don't see that as a problem.

> 7) Spaces in JSON

Yes, that is a common way for "pretty printing" JSON.

> time zones -> time-zones

As discussed on many occasions the protocol elements will be left as 
"timezone" and prose will use "time zone".

> 8) Service name registrations

No change will be made - these are protocol elements.

> 9) timezone Well-Known URI Registration

No change will be made - these are protocol elements.

> contradicts document name "Time Zone Data Distribution Service"

Agreed I have fixed that and a couple of other places where "data" was 
missing, thank you.

> No definition of format. Examples only show time stamps.

Formal syntax defines it as a "string" and the descriptions describe it as 
an "opaque token". I think that is reasonably clear.

> Less leaking would be a standard order?

Not sure what you mean by that.

> service over HTTP without TLS."

No - the document requires TLS but allows servers to offer a non-TLS 
solution if they want. But servers could choose to only implement TLS.

> compliant with the document. Rendering the document less

I am afraid in the current climate of security and privacy concerns, not 
requiring TLS is simply a non-starter. Anyone claiming that there are 
situations where it is not needed are simply wrong - as the continuing 
evidence of attacks of all kinds has shown.

-- 
Cyrus Daboo