If I understand your response (not sure that I do), that seems pretty academic and not at all persuasive. For instance, if a client cared about testing TCP capabilities, it can always do its own resolution.
On Tue, Apr 3, 2018 at 7:44 PM, Davey Song <songlinj...@gmail.com> wrote: > > > On 3 April 2018 at 15:33, Martin Thomson <martin.thom...@gmail.com> wrote: >> >> This is intended to do what? Indicate where the response came from? >> Why does the client care? > > To keep the proxy (API client and server) transparent and bypass the > middlebox along the path. Without the indicate, the API server has no clue > what transport the client use (or would like to use. because there maybe > cases that client would like to test TCP capablity of the far end resolver, > I don't know). If no such indicate, It is either always using UDP or TCP by > default (or by local configuration). It can be done as an choice for > software implementation, but for protocol design IMHO, a indicate should be > introduced to provide that information. > >> >> I assume that it doesn't apply to requests, >> or that would get into draft-bellis-dnsop-xpf territory. > > That's is the quesion whether the indicate should be carried in HTTP layer > or DNS layer. If we use HTTP as a tranparent tunnel without any modification > on upper layer message, I would prefer to use a HTTP indicate. > >> >> BTW, you really need to drop UDP from the media type name now. >> application/dns-udpwireformat;original_transport=tcp is a bit of a >> contradiction. > > > I agree. I find no harm defining a media type "application/dns-wireformat" > for DOH. > > Davey > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
