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/