On 16 Sep 2017, at 4:24 am, Paul Hoffman <paul.hoffman@xxxxxxxx> wrote: > > On 15 Sep 2017, at 9:44, Ted Hardie wrote: > >> 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. Whoa; hold it right there. Last I checked, we had only obsoleted HTTP/0.9; 1.1 is still very actively used, still on the standards track, and despite some peoples' wishes, needs and gets attention. >> 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 don't understand why anyone thinks anything would be required at all; if QUIC does its job properly, any application defined for HTTP/1.1 or HTTP/2 should work on HTTP-over-QUIC (whatever we end up calling it) without any changes. >> (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). I interpret the charter to say that this protocol is *using* HTTP, in the sense of <https://mnot.github.io/I-D/bcp56bis/#used>. In that view, this WG *cannot* change that. >>> 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. I agree that it's a preferable separable rathole. >>> 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. I'd prefer to keep the current milestone by avoiding additions. -- Mark Nottingham https://www.mnot.net/