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

[Cyrus Daboo <[e-mail]>]

Hi Tobias,

--On July 21, 2015 at 5:24:38 PM +0200 Tobias Conradi 
<[e-mail]> wrote:

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

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

> 2) The name of the service
> does not agree with the abstract

I have no concerns about that.

> 3) Orthography
> 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.

> 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

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.

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

Not sure what you mean by this.

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

I don't see that as a problem.

>
> 7) Spaces in JSON

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

> =======
> Document has
> time zones -> timezones
>
> instead of
> 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.

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

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

> 11) synctoken
> 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.

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

Not sure what you mean by that.

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

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.

> Requiring it will only lead to TZDDS servers that are not fully
> compliant with the document. Rendering the document less
> authoritative.

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