Change:
between packets, any limits on packet size will also limit the space available for a reason phrase. <del> A human-readable explanation for why the connection was closed. This can be zero length if the sender chooses not to give details beyond the Error Code.  This SHOULD be a UTF-8 encoded string RFC3629. </del> <ins> Additional diagnostic information for the closure.  This can be zero length if the sender chooses not to give details beyond the Error Code.  This SHOULD be a UTF-8 encoded string RFC3629, though the frame does not carry information, such as language tags, that would aid comprehension by any entity other than the one that created the text. </ins> The application-specific variant of CONNECTION_CLOSE (type 0x1d) can only be sent using 0-RTT or 1-RTT packets; see frames-and-spaces.

Discussion:
Though we recommend the use of text in UTF-8, we don't provide all of the machinery necessary for true internationalization, like multiple translations and all that mess. Be very explicit about that. (This is a recurring problem; we had the same problem with HTTP/2 and it might be worth updating BCP 18 for this.)
NAME said:
I hope not. How can we qualify this to avoid any implication that it does?
BCP 18 says: That really does sound like it covers this field. Would it be enough to say that the field SHOULD begin with a language tag if it is not empty?
This is a great example of red-tape. In any case, I think we can explicitly disavow anything here and say that the content of the field is not-defined and while it might be a good idea to make it something that can be rendered as text, it is for diagnostic purposes and does not need to be comprehensible to anyone other than the entity that generated it.
see URL (As an individual, I don't see any action required to fix something last spoken about, with little interest, ~4 years ago)
For a more substantial discussion, please see URL
In case my intention isn't clear (again as an individual), the WG discussed this previously and found a resolution reflected in the current text. I'm not seeing any new information in the meantime to warrant revisiting that decision. I am concerned that a change at this stage is disruptive to existing implementations and deployments of QUIC.
For clarity, I do not plan to take a position on the question since I am not much of an authority on the matter; I have asked the ART ADs if they can weigh in. I think we have somewhat recently marked a field as being "for debugging purposes" or "not intended to be displayed to the user" but don't remember it clearly enough to have search terms to actually find it as an example.
I think NAME 's fix in makes it so that this is not necessarily "human readable". I think that fixes this issue by defining the field differently (though still accurately), so I'm going to merge that and close this issue.
Sorry to come in later, after Jana already closed this, but I think the result is fine.

I sent the following reply to Ben K: It's generally true that we don't worry about language tagging for strings that aren't expected to be directly handled by end users. The failures caused by not knowing the intended language involve semantic issues (trying to do translation or other semantic interpretation of the strings), case mapping (such as handling "i" to "I" in English, vs Turkish), sorting ("ä" sorts after "a" in German and after "z" in Swedish, and Spanish actually eliminated "ch" as a single letter in 1994 to avoid such trouble), and comparisons. The strings in question here have none of those issues. So I would let this go, under the general assumption, which we make in very many other places in our protocol suites, that making it UTF-8 allows implementations to swap in German or Swedish or Turkish or Chinese versions of the messages, that installations will choose which language to operate in, and that language tagging really won't be needed.
Thanks for the additional information Barry.
I think this is much clearer. Also, I might argue that it doesn't need to be human-readable, since there is no expectation here about how this information is to be consumed.