Issue #82: Mark: choose 1 or MTI for both methods; prefer GET only but realistically MTI for both for servers; no opinion for clients, can use either

Martin: if you don't provide both on the server, things will break; client gets to choose. implication that client gets to choose which is cacheable and that kind of sucks

DKG: both make sense for server & client; if server redirects a POST to a GET, a client that only implements POST will break so clients need to do both if server can do either. You need this if DOH is going to be primary or sufficient DNS mechanism. by redirect, I mean 302 found. It's not desireable but possible.

Mark: <sarcasm> alt-service</> There's no standard behavior for caching POST. This will make CDN behavior unpredictable.

Martin: clients will blindly follow redirects, not a DOH-specific behavior

Patrick: addressing this in the doc

Tale: looks like we are reaching consensus in the room: GET/POST will be MTI on server and clients can implement either. will validate on list.

Issue #48:

Stuart: I would prefer to see this, b/c as the DNS continues to evolve with new extensions, it may or may not be work; if you make it look like UDP, you get any new formats for free

Andrew: I'm with Ray about not referring to 1035 on this. (Paul throws shade on UDP encoding.) Should we say that MTI is for the server? Client will never get one if it doesn't ask for it. (uncertain grumbling in room)

Patrick: server can throw error or respond; client should be able to read this so MTI covers client

Olafur: wire format should be MTI. Another JSON format that is all-ecompassing would be good but will take a few yeears.

Martin: I submitted an issue earlier today (#107): there's a proposal to make upgradeing request to another content type easier. Suggestion was to overload the name of the query parameter block.

Patrick: this adds more complexity. Not sure about the value.

Ben: be sure to consider different query parameters

Kirsty Paine: enterprises will lose control over what DNS lookups & associated DNS-related protectsions; there's a detection issue here DKG: security consideration addresses this point DKG: Correction - this is actually in the operational considerations

* Charter discussion (B. Schwartz) - Close the WG following RFC publication, or recharter for more work?

via jabber: would the JSON media type for DNS be within the current charter?

Tale: one chair's opinion: that would not require a recharter

Adam (AD): that surprises me, we need to talk

Tale: my response was based on the charter text "wg is chartered to standardsize codings for responses"

erik: would end user subnet cachability be in scope? anyone interested in working on this? not a straightforward way to do that within HTTP semantics.

Ben: would depend on contents of the proposal

patrick (as HTTPbis cochair): EDNS0 caching would not be in HTTPbis

olafur: would like to see JSON media formats within charter; recommend don't cache EDNS0

Tale: DNSOPS discussed stress on the DNS system

ben: issues around discovery (boostrapping a connection to a DOH server) using only domain name needs authors for a draft, considered within scope

Ben: won't close wg before current draft is complete

Paul: thinking about writing a draft

DKG: if a DOH server is defined by a URI, a mapping shouldn't be that hard

Ben: there's a lot of history and past controversial proposals here

Tale: our point is that it's now or never to do this work within this wg

Andrew: this is an incredibly good Back to the Future moment. The DNS used to just do this for you. We learned this was called poison. If you want to do this, what you are talking about now is a new naming protocol that has the properties necessary to do this. E.g., How do you handle signed records? Maybe we should look at a brand new protocol.

DKG: I don't think we need any additional machinery. You can use a specified DNS chain query.

Patrick: I'm calling this "Out of Band DNS". HTTP has a few mechanism that do request routing, restricted to the origins that you are talking to. HTTPbis should look at this use case. 2 major technical topics: 1. how do I know its safe to use this address, ie, some kind of a signature; 2. how do I know this is the endpoint that this name would have wanted me to use if I had looked it up on the authoritative server

David: This is cool. benefit would be for a social media site. See real value there from preloading the DNS. negative point: lots of folks use DNS for load balancing to the right data center. How about you use this without signatures? But that requires DNSSSEC support everywhere including in cliends. Happy eyeballs would work without DNSSEC. Feed addresses into an API. If origin requires TLS, you don't care whether the IP address is valid.

Shane: I think we need DNSSEC. Timing attachs are possible. Andrew is probably (on the edge of) correct. We might have hit the limitations of DNS.

Brian: I see a lot of cause for useing this data for your current request. Not sure it's somehting you want to cache. Contains the impact of any poison.

Mike: Thats not entirely true. Othre requests for that object will share the results. Could use alt-service to also notify clients of the avilability of QUIC.

Warren: I think this is a grand idea. Wrote a doc in DNSOP. Worth getting input from DNSOP.

Jim: Have you thought about DOS attacks using this mechanism?

DKG: good point. need to think about applying client rate limiting to reduce work server can casue.

??: Have you thought about the costs associated with implementing this to balance against the benefits?

DKG: the more significant costs are not around implementation.

Erik: between DOH, DNSOP, HTTPbis there are a lot of complexity, the camel is standing on it's own back.... are the working group boundaries becoming a restriction here?

Jabber: I haven't looked into this for a while.Would this use NS records to provide the IP address of the http server being used ?

DKG: no

Olafur: something seomething Poisoned Happy Eyeballs (of the Camel)

Suz: maybe we shouldn't call this DNS

DKG: but there's lots of good stuff in DNS

Mark: maybe a barbof in Montreal

Paul: disagree with Suz, not uncomfortable with using DNS. Maybe this will be done over DOH and stuff it into a local DNS cache in the web.

David: name suggestion: Out of Band Names (NOOB)

DKG: this is really in-band

Mark: can DOH populate the DNS cache?

Paul: not out of scope or in scope; DOH doesn't say what you can do with the response to a query.

Mark: small difference between I want to use DOH for my web browser and a random piece of software pupoulates my DNS cache.