Regarding <https://tools.ietf.org/html/draft-ietf-tzdist-service-08> - 1. The draft uses URI templates to specify resources, but does so statically in the specification, rather than allowing them to be determined by the server. This doesn't violate the letter of BCP190, but it doesn't honour the spirit of it; the server is not in control of its own URI shape, except at the coarsest level (effectively, a prefix). Much better would be to have the first request not return a redirect, but instead a set of templates that tells the client how to find the appropriate resources on the server. The "actions" listed in section 5 would be more appropriately referred to as resources — calling them "actions" cuts against the grain of the entire Web architecture. They also are natural fits for having distinct link relations (RFC5988). Note that this isn't an "I'm lying down in the road, this technology is broken" comment — more of a "It would be so easy to get this right with a bit of effort." 2. Section 4.1.7 comes dangerously close to re-defining the semantics of HTTP status codes, and should be removed. E.g., 304 only happens in the context of a conditional request, but it is not mentioned here. 400 does *not* have the semantics of "The Sender has provided an invalid request parameter", and overloading them here is inappropriate. 3. Section 4.2 doesn't motivate why it's necessary to start with a hostname to resolve the URI of the time zone distribution service, rather than just start with the URI itself. What's the use case here? They're both just strings. 4. More generally, I only found out about this draft because I happen to be the expert on one of the relevant registries, and got a ping from IANA. I'd expect that if we're working on standards that use HTTP, the HTTP WG would be notified and asked to review — especially since we have a history of using the protocol pretty poorly. Cheers, -- Mark Nottingham https://www.mnot.net/