> On 18 Jun 2015, at 12:44 am, Cyrus Daboo <cyrus@xxxxxxxxxx> wrote: >> >> 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. > > I am fine with deleting the list of status codes. We still need that section to refer to the use of the JSON problem detail spec. As an aside: since you are the author of the draft what is its status? Obviously the tzdist spec references normatively so we would need your draft to progress (ideally as soon as possible). If that is not likely to happen then we will need to incorporate your JSON schema directly in our spec and drop the reference. We should be progressing it very soon; I have one dangling issue. >> 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. > > Clients can be directly configured with a URI - that's fine. But Section 4.2 is mostly about the case where clients don't have any information about available services and they need to find a suitable one. In the absence of user input, clients can simply look for a service in their local domain. Even in the case where user input is available, it is much easier to tell the user to enter a domain or simply their "email address" and have discovery work off that (with the added benefit of the indirection that SRV lookups give). This is akin to discovering other "services" for a user such as email and calendaring. Ah - so you're effectively using SRV and/or .well-known as a DHCP-ish mechanism. I'm not against that in principle, but it needs to be spelled out; e.g., do I look in the domain that DHCP returns, or .local, or both, or…? Cheers, -- Mark Nottingham https://www.mnot.net/