Draft: draft-ietf-doh-dns-over-https-latest

Commentary: Fixes to PR 
 It does n't feel to me like " beyond what is already in { { RFC1035 } } " really clarifies anything , and might just cause additional confusion , as it makes me as a reader wonder , " oh well what 's in 1035 ? Guess I have to go searching ... " 
 If you want to put the specific limit from RFC 1035 in , that 's fine . 
 Well no , because I do n't think there should be a limit . While DNS messages implicitly have a maximum size of 64k in DNS , there 's no reason dns - udpwireformat in HTTPS ca n't surpass that . 
 It would be an interoperability problem if a DNS API server handed a DNS API client a message that it could not handle . It is reasonable to assume that DNS API clients expect to parse messages as if they were DNS messages . 
 This was sloppy on my part : I meant the addition to point to RFC 6891 ; now changed . 
 Right but my point is that something like multiple AXFR messages re - assembled into one unit is still a DNS message even if it exceeds 64k . From a wire - format point of view , it parses exactly the same way . 
 Really ? Ugh . Got ta love this protocol . So , you would prefer that the text says " this protocol allows DNS - on - the - wire format payloads of any size " ? 
 Yes , I would . Realistically almost everything is still going to be sub-10k , but I do n't see an intrinsic need to limit it , especially with https channels routinely handling far larger responses . 
 I think  and I are now in agreement ; should consider accepting .
Paragraph (version A):
The data payload is the DNS on-the-wire format defined in RFC1035.
The format is for DNS over UDP.  Note that this is different than the
wire format used in RFC7858.  Also note that while RFC1035 says
"Messages carried by UDP are restricted to 512 bytes", that was later
updated by RFC6891, and this protocol does not put any limit on the
size of DNS on-the-wire format payloads.
Paragraph (version B):
The data payload is the DNS on-the-wire format defined in RFC1035.
The format is for DNS over UDP.  Note that this is different than the
wire format used in RFC7858.  Also note that while RFC1035 says
"Messages carried by UDP are restricted to 512 bytes", that was later
updated by RFC6891, and this protocol allows DNS on-the-wire format
payloads of any size.
Paragraph (version A):
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.
Paragraph (version B):
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 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.