Ben Kaduk's Transport Comment 35

[LPardue]

@kaduk said:

Section 19.19

Reason Phrase: 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].

Does "human-readable" engage BCP 18 and the SHOULD-level requirement for
carrying information about language?

[martinthomson]

I hope not. How can we qualify this to avoid any implication that it does?

[MikeBishop]

BCP 18 says:

All human-readable text has a language.
...
Protocols that transfer text MUST provide for carrying information about the language of that text.
...
Note that this does NOT mean that such information must always be present; the requirement is that if the sender of information wishes to send information about the language of a text, the protocol provides a well-defined way to carry this information.

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?

[martinthomson]

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.

[LPardue]

see #187 (comment)

(As an individual, I don't see any action required to fix something last spoken about, with little interest, ~4 years ago)

[LPardue]

For a more substantial discussion, please see #1990

[LPardue]

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.

[kaduk]

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.

[janaiyengar]

I think @martinthomson 's fix in #4722 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.

[barryleiba]

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.

[LPardue]

Thanks for the additional information Barry.