jiebi/CodeConvo huggingface dataset:
Code change:
I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Related discussion:
text: 7. <del> In order to satisfy the security requirements of DNS over HTTPS, this protocol MUST use HTTP/2 RFC7540 or its successors.  HTTP/2 enforces a modern TLS profile necessary for achieving the security requirements of this protocol. </del> This protocol MUST be used with https scheme URI RFC7230. <del> The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression. For this additional reason, this protocol MUST use HTTP/2 RFC7540 or its successors. </del> <ins> This protocol MUST use HTTP/2 RFC7540 or its successors in order to satisfy the security requirements of DNS over HTTPS.  Further, the messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression, all of which are supported by HTTP/2 RFC7540 or its successors. </ins> 8.
Code change:
I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.

Related discussion:
text: 9. <del> Running DNS over https:// relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS this protocol expects to use current best practices for secure </del> <ins> Running DNS over HTTPS relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure </ins> transport. Session level encryption has well known weaknesses with respect to
Code change:
This text is great justification to include in a charter, but this is a protocol specification and it really doesn't add much.
It seemed like the WG wanted the document to be shorter and more specific, so this feels good.

Related discussion:
text: 1. <del> The Internet does not always provide end to end reachability for native DNS.  On-path network devices may spoof DNS responses, block DNS requests, or just redirect DNS queries to different DNS servers that give less-than-honest answers.  These are also sometimes delivered with poor performance or reduced feature sets. Over time, there have been many proposals for using HTTP and HTTPS as a substrate for DNS queries and responses.  To date, none of those proposals have made it beyond early discussion, partially due to disagreement about what the appropriate formatting should be and partially because they did not follow HTTP best practices. </del> This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and
Code change:
… but keep the requirement for future formats.
Attempts to
As input to the process, this was extremely valuable, but now that this is in WGLC, we're done with it. Does the audience of the ultimate RFC need this information? The only thing that I can see that is worth salvaging is a statement to the effect that DNS64 isn't explicitly supported.
Yes, we still need it. We have not gone to IETF Last Call and, despite what some people think, the IETF gets to change a protocol significantly during IETF Last Call. But even after that, once it is an RFC, others will want to update the RFC. It is important to keep the requirements for them as well.
Actually, we probably don't need it in the RFC as long as the one future requirement (for formats) is still there. Please see PR

Related discussion:
text: 3. <ins> [[ RFC Editor: Please remove this entire section before publication. ]] </ins> The protocol described here bases its design on the following protocol requirements:
Code change:
… but keep the requirement for future formats.
Attempts to
As input to the process, this was extremely valuable, but now that this is in WGLC, we're done with it. Does the audience of the ultimate RFC need this information? The only thing that I can see that is worth salvaging is a statement to the effect that DNS64 isn't explicitly supported.
Yes, we still need it. We have not gone to IETF Last Call and, despite what some people think, the IETF gets to change a protocol significantly during IETF Last Call. But even after that, once it is an RFC, others will want to update the RFC. It is important to keep the requirements for them as well.
Actually, we probably don't need it in the RFC as long as the one future requirement (for formats) is still there. Please see PR

Related discussion:
text: In order to maximize interoperability, DNS API clients and DNS API servers MUST support the "application/dns-message" media type.  Other media types MAY be used as defined by HTTP Content Negotiation <del> (RFC7231 Section 3.4). </del> <ins> (RFC7231 Section 3.4).  Those media types MUST be flexible enough to express every DNS query that would normally be sent in DNS over UDP (including queries and responses that use DNS extensions, but not those that require multiple responses). </ins> 6.
Code change:
…raft-ietf-doh-dns-over-https/commit/3f74bd6e0760f96717ffd3e667a37e13b45839c4#commitcomment-28865666 and URL that this wording is much clearer.
Sara, making this pr was on my todo list - thanks for the time saver. Paul sent me an IM about it, so I'll ga and merge.

Related discussion:
text: are independent and fully compatible protocols, each solving different problems.  The use of one does not diminish the need nor the usefulness of the other.  It is the choice of a client to either <del> perform full DNSSEC validation of answers or to treat answers from a DNS API server as DNSSEC-authenticated, and this choice may be affected by the response media type. </del> <ins> perform full DNSSEC validation of answers or to trust the DNS API server to do DNSSEC validation and inspect the AD (Authentic Data) bit in the returned message to determine whether an answer was authentic or not.  As noted in http-response, different response media types will provide more or less information from a DNS response so this choice may be affected by the response media type. </ins> caching describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect
Code change:
…raft-ietf-doh-dns-over-https/commit/3f74bd6e0760f96717ffd3e667a37e13b45839c4#commitcomment-28865666 and URL that this wording is much clearer.
Sara, making this pr was on my todo list - thanks for the time saver. Paul sent me an IM about it, so I'll ga and merge.

Related discussion:
text: security implications of HTTP caching for other protocols that use HTTP. <del> In the absence of information about the authenticity of responses, such as DNSSEC, a DNS API server can give a client invalid data in </del> <ins> In the absence of DNSSEC information about the authenticity of responses a DNS API server can give a client invalid data in </ins> responses.  A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use DNS API servers specified using mechanisms such as explicit configuration.  This does not guarantee
Code change:
this paragraph is true.. but its a tad confusing and I don't think really describes anything germane to doh.
NAME WFM to just remove this text

Related discussion:
text: configuration.  This does not guarantee protection against invalid data but reduces the risk. <del> A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy and authenticity expected by the user of the client. </del> 10. Local policy considerations and similar factors mean different DNS
Code change:
Is there a reason not to make a recommendation for the case of a DOH-only service? The current text says: Implementations of DoH clients and servers need to consider the benefit and privacy impact of all these features, and their deployment context, when deciding whether or not to enable them. Would you consider a recommendation like "For DOH clients which do not intermingle DOH requests with other HTTP suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy."?
NAME That could be added, but it would need a lot more text because your proposed text only deals with one layer (HTTP) while the text above it also talks about fingerprinting with TLS, TCP, and IP (in reverse order). The WG can decide whether adding recommendations for just one layer is worthwhile or possibly misleading about the overall privacy.
NAME It was only an example, and I would be happy to expand. That said, I think this is the most likely source of leakage: folks using a general purpose HTTP subsystem that carries information not needed for DOH requests. Actually recommending data minimization there, rather than saying "it should be considered" seems like a worthwhile thing to do in my personal opinion.
Agreed with Ted (on the list) that this conversation should be on the list. Locking it here.
I have unlocked the comments so that people can propose specific wording changes as diffs in the PR itself; most questions and suggestions should be done on the list.

Related discussion:
text: This protocol MUST be used with the https scheme URI RFC7230. <ins> PrivacyConsiderations and Security discuss additional considerations for the integration with HTTP. </ins> 6.1. A DoH exchange can pass through a hierarchy of caches that include
Code change:
Is there a reason not to make a recommendation for the case of a DOH-only service? The current text says: Implementations of DoH clients and servers need to consider the benefit and privacy impact of all these features, and their deployment context, when deciding whether or not to enable them. Would you consider a recommendation like "For DOH clients which do not intermingle DOH requests with other HTTP suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy."?
NAME That could be added, but it would need a lot more text because your proposed text only deals with one layer (HTTP) while the text above it also talks about fingerprinting with TLS, TCP, and IP (in reverse order). The WG can decide whether adding recommendations for just one layer is worthwhile or possibly misleading about the overall privacy.
NAME It was only an example, and I would be happy to expand. That said, I think this is the most likely source of leakage: folks using a general purpose HTTP subsystem that carries information not needed for DOH requests. Actually recommending data minimization there, rather than saying "it should be considered" seems like a worthwhile thing to do in my personal opinion.
Agreed with Ted (on the list) that this conversation should be on the list. Locking it here.
I have unlocked the comments so that people can propose specific wording changes as diffs in the PR itself; most questions and suggestions should be done on the list.

Related discussion:
text: 7. The data payload for the application/dns-message media type is a <del> single message of the DNS on-the-wire format defined in section 4.2.1 </del> <ins> single message of the DNS on-the-wire format defined in Section 4.2.1 </ins> of RFC1035.  The format was originally for DNS over UDP.  Although RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891.  This media type restricts the maximum size of the DNS message to 65535 bytes.  Note that the wire format used in this media type is different than the wire format used <del> in RFC7858 (which uses the format defined in section 4.2.2 of </del> <ins> in RFC7858 (which uses the format defined in Section 4.2.2 of </ins> RFC1035). DoH clients using this media type MAY have one or more EDNS options
Code change:
Is there a reason not to make a recommendation for the case of a DOH-only service? The current text says: Implementations of DoH clients and servers need to consider the benefit and privacy impact of all these features, and their deployment context, when deciding whether or not to enable them. Would you consider a recommendation like "For DOH clients which do not intermingle DOH requests with other HTTP suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy."?
NAME That could be added, but it would need a lot more text because your proposed text only deals with one layer (HTTP) while the text above it also talks about fingerprinting with TLS, TCP, and IP (in reverse order). The WG can decide whether adding recommendations for just one layer is worthwhile or possibly misleading about the overall privacy.
NAME It was only an example, and I would be happy to expand. That said, I think this is the most likely source of leakage: folks using a general purpose HTTP subsystem that carries information not needed for DOH requests. Actually recommending data minimization there, rather than saying "it should be considered" seems like a worthwhile thing to do in my personal opinion.
Agreed with Ted (on the list) that this conversation should be on the list. Locking it here.
I have unlocked the comments so that people can propose specific wording changes as diffs in the PR itself; most questions and suggestions should be done on the list.

Related discussion:
text: This prohibition does not guarantee protection against invalid data, but it does reduce the risk. <del> 10. </del> <ins> 11. </ins> Local policy considerations and similar factors mean different DNS servers may provide different results to the same query: for instance
Code change:
This text is rather subjective without data. Changing it to "may" still brings the point without needing a reference to a study proving the sentence true.
(whoops; just realized I've been blowing my pull requests by chaining them off a single branch... my bad, and this will cause you some pain)

Related discussion:
text: to support reordering, parallelism, priority, and header compression to acheive similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of <del> conveying the semantic requirements of DOH but would result in very </del> <ins> conveying the semantic requirements of DOH but may result in very </ins> poor performance for many uses cases. 8.
Code change:
Update the draft to use the same spelling as TLS RFC uses. Relates to issue
While reading draft-ietf-emu-eap-tls13-15 I noticed that section now uses which is the named used in but not in RFC 8446 itself. I first thought this was a typo, before a further look showed that this change was mentioned in IETF 110 . Suggestion: make clear which parts need to be looked up from RFC 8446bis. In addition to exporter terminology, the meeting slides above also discuss about usercancelled behavior on slide 10. For clarity, any updates from RFC 8446bis should be marked clearly.
It would be best not to have normative references that block on RFC 8446bis. Perhaps we can just reference that it is renamed from "exportermastersecret"
Sounds good. That should make clear where it comes from and that there's no need to file errata about unknown term and/or RFC 8446bis dependency. Taking another look at my comment about usercancelled behavior on slide 10; to clarify what I was meaning: The slides hint that clarifications in 8446bis are needed by EAP-TLS too. If so, this looks like a reference to RFC 8446bis too. Finally, one nit: the alert name in RFC 8446 is "usercanceled", not "user_cancelled" as in draft -15.
I made a PR with explaining that the document use the terminology from RFC8446bis. URL Do we need to say anything about usercancelled? RFC8446bis might do several clarifications and corrections. I think we should only mention things that are directly relevant for EAP-TLS 1.3 URL Current plan for RFC8446bis seems to be to ignore closenotify and I assume require close_notify after. This does not seem directly relevant for EAP-TLS 1.3. Or?
close issue?
Yes, please close this. I think it's now clear where exportersecret comes from. Also, thanks for the pointer to TLSv1.3 discussion. I agree usercanceled followed by close_notify discussion is not relevant for EAP-TLS 1.3. It's seems to be TLSv1.3 specification and implementation level detail as opposed to something that EAP-TLS 1.3 needs to directly react on.
This looks good to merge

Related discussion:
text: Error alert message.  In earlier versions of TLS, error alerts could be warnings or fatal.  In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are "close_notify" and <del> "user_cancelled", both of which indicate that the connection is not </del> <ins> "user_canceled", both of which indicate that the connection is not </ins> going to continue normally, see RFC8446. In TLS 1.3 RFC8446, error alerts are not mandatory to send after a
Code change:
Thanks for merging. I had a small fix to the caption of table 1 which is now .
(This was original raised in and now being split out) (Michael Kay) want to confuse the JSONPath spec by going into detailed comparisons at the risk of contradicting the normative text. (Glyn Normington) (Michael Kay) It seemed to be important in 2007, while argumenting to have something like XPath for JSON. If nowadays the terminology used has changed significantly with XPath 2.0 and 3.0, we better leave that comparison table 2 out. I am quite passionless here. At the IETF 110 meeting consensus was raised that inclusion of XPath in the Appendix section would be the most appropriate way to reference to it.
Closed in
Great improvement!Additions / Replacements of high value ... thanks

Related discussion:
text: 3.5.7.2. <del> The "descendant-selector" is inspired by ECMAScript for XML (E4X). It selects the node and all its descendants. </del> <ins> The "descendant-selector" selects the node and all its descendants. </ins> 3.5.8.
Code change:
Thanks for merging. I had a small fix to the caption of table 1 which is now .
(This was original raised in and now being split out) (Michael Kay) want to confuse the JSONPath spec by going into detailed comparisons at the risk of contradicting the normative text. (Glyn Normington) (Michael Kay) It seemed to be important in 2007, while argumenting to have something like XPath for JSON. If nowadays the terminology used has changed significantly with XPath 2.0 and 3.0, we better leave that comparison table 2 out. I am quite passionless here. At the IETF 110 meeting consensus was raised that inclusion of XPath in the Appendix section would be the most appropriate way to reference to it.
Closed in
Great improvement!Additions / Replacements of high value ... thanks

Related discussion:
text: isolating a single location within a document. Path is a query syntax that can also be used to pull multiple locations. <ins> [no-dot-length] We probably want to use an expression that does not use </ins>
Code change:
Lots of niggly details re blank space. Style consistency, some missing places (assuming we stick with the liberal approach). Allowing "in" before or after a newline or tab. Adding some legend to the only remaining table with XPath content in the main document.
[ ] define a production , replacing [ ] go through ABNF and make sure blank space is allowed where it needs to be (Do not use the term "whitespace" any more.) Task "T1" in the document URL
and
From the document: (whitespace is now generally called blank space, but that doesn't change the work to be done.)
and
How much do we want to reference XPath within the spec? I understand that XPath is the inspiration (and in the tagline that NAME used in his blog post: "XPath for JSON"), but I wonder if much of this can be left out of the spec. The argument for this is that we're defining JSONPath. It shouldn't assume any understanding of XPath or any other technology. It's not the job of the specification to convince readers to use it. It's the job of the specification to define the technology. I'm perfectly happy moving this into an external "Understanding JSONPath" website at some point.
I seem to remember that last time we discussed this we agreed to move the introductory comparison with XPath to an appendix, with the possible exception of the overview table (but that could be duplicated).
The XPath inclusion was moved into an appendix.
Do we allow spaces (outside of string literals)? If so, where is whitespace allowed? I think whitespace in query expressions should be allowed. This would fall in to the context of the . Maybe inside the union/ selector: Are there any other places where whitespace could be considered useful?
It may be convenient to allow spaces between matchers - to allow well-readable multi-line queries for complex cases.
Looks like the allows whitespace internally, so that (with leading and trailing whitespace) is valid.
Closed in and
What was the resolution here? Where did we end up allowing whitespace?

Related discussion:
text: The examples in tbl-example use the expression mechanism to obtain the number of elements in an array, to test for the presence of a member in a object, and to perform numeric comparisons of member <del> values with a constant. </del> <ins> values with a constant.  For further illustration, the table shows XPath expressions that would be used with a comparable XML document; see also xpath-overview. </ins> 3.