If we need this to worry about what form of HTTP we are sending it over, we are doing it something very wrong - ether this or HTTP. And if this WG needs to worry about how the HTTP is transported over UPD, or TCP or v4 or v6, then we have the wrong charter. > On Sep 15, 2017, at 1:24 PM, Paul Hoffman <paul.hoffman@xxxxxxxx> wrote: > > On 15 Sep 2017, at 9:44, Ted Hardie wrote: > > =>> This working group will standardize encodings for DNS queries and responses >>> that are suitable for use in HTTPS. This will enable the domain name system >>> to function over certain paths where existing DNS methods (UDP, TLS, and >>> DTLS) >>> experience problems. The working group will re-use HTTPS methods, error >>> codes, and other semantics to the greatest extent possible. The use of >>> HTTPS >>> provides integrity and confidentiality, and it also allows the transport to >>> interoperate with common HTTPS infrastructure and policy. >>> >>> >> I appreciate the charter's use of "HTTPS" as a signal that these are >> intended to be TLS-protected HTTP sessions. I note, however, that there is >> considerable ambiguity still present. HTTPS can mean HTTP 1.1 over TLS, >> HTTP/2 over TLS, and it may mean HTTP over QUIC at some point soon (in some >> deployments it already means that). The document named as input specifies >> HTTP/2 over TLS. While the working group may, of course, change that to >> support HTTP 1.1 and/or QUIC, it might be useful for the charter to >> indicate which of these is potentially in scope. > > Yes, please. The charter should say "HTTP/2 over TLS". There is no reason for current browsers adding this feature to add it using an obsolete protocol. If someone wants to create a diff from the eventual protocol for HTTP 1.1, they can do that without forcing the document to add a comparison of the two transports to what is supposed to be a short, concise document. > >> If the community is sure >> now that HTTP over QUIC is in scope, for example, having that noted in the >> charter by adding the QUIC working group to list of working groups to >> consult would be useful. > > The deadline for this WG is well ahead of when HTTP-over-QUIC will be finalized. Instead, when HTTP-over-QUIC is finalized, an update to this document should be pretty easy to produce. > >> I will confess a bias here: while I think it is useful to match the >> capability set of HTTP over QUIC to that of HTTP over other transports as >> much as possible, I think making that a key part of this work is not a good >> initial direction. For one thing, there are some aspects of the QUIC >> transport that are still in discussion, and I think it will slow this work >> a bit to track those. More importantly, though, I think this would be the >> wrong way to do DNS over QUIC (draft-huitema-quic-dnsoquic-00 shows a >> different approach). Having QUIC be an early focus here may solidify an >> approach that is simple, but not nearly as complete as we could deliver >> with a DNS over QUIC. >> >> (This is in part because of the choice to use the udp wireformat as the >> baseline HTTP response here, rather than specifying DNS responses over a >> transport construct like a QUIC stream. The working group could, of >> course, change that, but it would seriously shift the direction of its >> input document to do so). > > Fully agree. > >>> Specification of how the DNS data may be used for new use cases, and >>> the discovery of the DOH servers, are out of scope for the working group. >>> >>> >> While it is useful to know that discovery is out of scope here, I think >> having a quick community discussion now of where it might be in scope is >> useful. There are some potentially interesting questions buried in that, >> especially in how we expect interworking with existing systems to go. >> Note that even if the service discovery method provides an HTTPS URI for >> the name server, the questions above related to HTTP version or transport >> may bite you. For server discovery based on address and port, the >> situation is much the same unless the port is clearly marked as TCP or >> UDP. And if the server discovery includes no port at all, then a happy >> eyeballs type method may be needed. >> >> This may all fall into a combo of DHCP and DNSOP work, but giving somewhat >> clean lines for it now seems like it will make the later work go faster. > > If you want to propose a new WG for that, please do so; there are a lot of people interested in that topic. It definitely goes across multiple areas of interest, such as "discovery" and "addressing" and even "trust". Personally, I don't think it applies to a transport document. > >>> Milestones: >>> >>> Apr 2018 - Submit specification for performing DNS queries over HTTPS to >>> the IESG for publication as PS >>> >>> >> I admire the optimism in this. > > It was not optimistic with the charter that was originally sent to the IESG; see <https://datatracker.ietf.org/doc/charter-ietf-doh/00-00/>. As more issues are added to the charter, it makes sense to have to extend the milestone deliverable. > > --Paul Hoffman >