Draft: draft-ietf-quic-transport

Commentary: Though we recommend the use of text in UTF-8 , we do n'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 . ) 
 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 ( As an individual , I do n't see any action required to fix something last spoken about , with little interest , ~4 years ago ) 
 For a more substantial discussion , please see 
 In case my intention is n'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 do n't remember it clearly enough to have search terms to actually find it as an example . 
 I think '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  already closed this , but I think the result is fine . I sent the following reply to   : It 's generally true that we do n't worry about language tagging for strings that are n'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 wo n't be needed . 
 Thanks for the additional information  . 
 I think this is much clearer . Also , I might argue that it does n't need to be human - readable , since there is no expectation here about how this information is to be consumed .
Paragraph (version A):
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.
Paragraph (version B):
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.