Change:
between different requests.  DOH cannot be used as a transport for other protocols that require strict ordering. <ins> If a DNS API server responds to a DNS API client with a DNS message that has the TC (truncation) bit set in the header, that indicates that the DNS API server was not able to retrieve a full answer for the query over TCP and is providing the best answer it could get. This protocol does not require that a DNS API server that cannot get an untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. </ins> 10. Joe Hildebrand contributed lots of material for a different iteration

Discussion:
Related to
this is a strict improvement. let's merge and we can adjust further if there is feedback
No limit? Not even the UDP 64 k limit?
I would delete the "over TCP" in "DNS API server was not able to retrieve a full answer for the query over TCP" The DoH server is supposed to do its best to get the fuil answer, it does not mean we force TCP.
Good catches. Will update with URL
I don't see a compelling technical reason to set a limit.
Whether or not RFC 1035 has this limit, DOH should not.
The relevant text in RFC 1035 is: or UDP headers). Longer messages are truncated and the TC bit is set in the header. If the DOH protocol is referred to as "per RFC 1035" then readers of the spec would be entitled to believe that the 512 byte limit applies unless explicitly documented otherwise.
Hello NAME ! as quite a bunch of records are indeed > 512.... some companies set 1024~4096 as operational limit on forwarders and routers. Maybe it could be set in draft to 1024, to avoid jumboframes at all in the picture ? Maybe RFC1035 not have foreseen the increasing size of messaging we then experienced lately (along with Add and Auth getting bigger for redundancy) ? no doubts on it, people are creative about what they can put inside DNS: geo-informations in LOC type, or surf web within TXT records, PGP keys ... I can personally get along most of times with 50-100 bytes average packet size in a simple browsing session, but carrying DNSSEC or even just an SPF will make the use of TCP on DNS backend more and more and more exclusive... I am not saying is any bad/good. We risk limiting the "native DNS" initial use of UDP (which has probably grown after 1035 initial needs) by reverting back to quite an "old" setting. I am not sure everyone today does truncate on exact 512, I might be very wrong. Little higher limit can still be beneficial to transport, compression, stateless/stateful costs etc. By the way, one of today's standing argument by Sir P. Mockapretis, is indeed the present limit on the size of datagrams, just to make things funnier !

Making a parallel with the transport layer, we do not want to drive trough TCP-only world as we had also mentioned QUIC and others. Another parallel on semantics, we almost mention HTTP3 just because comes after HTTP2 but nothing lower than 2. So why shall we not leave that choice OPEN to implementors, to set the desired truncating threshold starting at 512 an up ? Are there references to present RFC on the topic to help reasoning or delegate the choice on this ? The truncate decision for an ANSWER having size > threshold is taken only by server, client will accept and parse so no impact ? Can we try to elaborate on this ? Just brainstorming...
Goodness no, not the least of which being because https transport issues are clearly out of scope for this work.

The truncate decision for an ANSWER having size > threshold is taken only by server, client will accept and parse so no impact ? Can we try to elaborate on this ? The server may have gotten a truncated response from an an authoritative name server, so the client always need to expect an truncated response (except in some local uses of DNS). YES, Seems like something that should be elaborated on.
Proposed fix at
.. we can reopen this issue if necessary
reopen to consider