I think that not supporting DSO was entirely a choice on the part of the authors. An

I suggest we add a reference to <a href="https://datatracker.ietf.org/doc/html/rfc849

I think the text added in <a class="issue-link js-issue-link" data-error-text="Failed

DSO carveout about dnsoquic HOT 4 CLOSED

huitema commented on August 15, 2024

DSO carveout

from dnsoquic.

Comments (4)

huitema commented on August 15, 2024

Yes, this seems fine. Removing the discussion of HTTP is a good idea. Supporting DSO appears simple, we would "just" have to let the server open streams and push transactions on them, but it has interesting interactions with connection management, NAT rebinding, keep alive, etc. So yes, it is "a choice on the part of the authors". @saradickinson, do you have a strong opinion?

from dnsoquic.

saradickinson commented on August 15, 2024

I suggest we add a reference to https://datatracker.ietf.org/doc/html/rfc8490#page-10 to make clear that DoQ as defined is not an applicable transport for DSO because DSO depends directly on in order delivery of messages: #113

BTW - the implementation of DSO has been very limited (mainly to DNSSD) so I've heard no desire to make it work in DoQ.

from dnsoquic.

huitema commented on August 15, 2024

I think the text added in #113 resolves the issue. @martinthomson, is this satisfactory?

from dnsoquic.