jiebi/TextFlow huggingface dataset:
Original 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>  6.

Reviewer comments:
… 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

Revised 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  <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.
Original 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>  caching describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect

Reviewer comments:
…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.

Revised 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  <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
Original 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>  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

Reviewer comments:
…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.

Revised text:
security implications of HTTP caching for other protocols that use HTTP.  <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
Original 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

Reviewer comments:
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

Revised text:
configuration.  This does not guarantee protection against invalid data but reduces the risk.  10. Local policy considerations and similar factors mean different DNS
Original text:
This protocol MUST be used with the https scheme URI RFC7230.  6.1. A DoH exchange can pass through a hierarchy of caches that include

Reviewer comments:
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.

Revised 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
Original 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>  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>  RFC1035). DoH clients using this media type MAY have one or more EDNS options

Reviewer comments:
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.

Revised text:
7. The data payload for the application/dns-message media type is a  <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  <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
Original text:
This prohibition does not guarantee protection against invalid data, but it does reduce the risk. <del> 10. </del>  Local policy considerations and similar factors mean different DNS servers may provide different results to the same query: for instance

Reviewer comments:
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.

Revised text:
This prohibition does not guarantee protection against invalid data, but it does reduce the risk.  <ins> 11. </ins> Local policy considerations and similar factors mean different DNS servers may provide different results to the same query: for instance
Original 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>  poor performance for many uses cases. 8.

Reviewer comments:
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)

Revised 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  <ins> conveying the semantic requirements of DOH but may result in very </ins> poor performance for many uses cases. 8.
Original 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>  going to continue normally, see RFC8446. In TLS 1.3 RFC8446, error alerts are not mandatory to send after a

Reviewer comments:
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

Revised 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  <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
Original 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>  3.5.8.

Reviewer comments:
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

Revised text:
3.5.7.2.  <ins> The "descendant-selector" selects the node and all its descendants. </ins> 3.5.8.
Original text:
isolating a single location within a document. Path is a query syntax that can also be used to pull multiple locations. 

Reviewer comments:
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

Revised 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>
Original 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>  3.

Reviewer comments:
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?

Revised 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  <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.
Original text:
member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]". <del> Next, "[*]" selects from any input node -- either an array or an object -- all its elements or members.  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </del>  Finally, ".b" selects from any input node of type object with a member name "b" and selects the node of the member value of the input

Reviewer comments:
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?

Revised text:
member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]".  <ins> Next, "[*]" selects from an input node of type array all its elements (if the input note were of type object, it would select all its member values, but not the member names).  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </ins> Finally, ".b" selects from any input node of type object with a member name "b" and selects the node of the member value of the input