Subject: [quicwg/base-drafts] Ben Kaduk's Transport Comment 35 (#4647)

From: Lucas Pardue <[email-masked]>
Date: Wed, 06 Jan 2021 18:02:10 -0800

@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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 22:19:28 -0800

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#issuecomment-755911751

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Jan 2021 14:01:05 -0800

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 [the language used] 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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#issuecomment-757020518

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Jan 2021 17:49:48 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#issuecomment-757586404

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 10 Jan 2021 18:16:51 -0800

see https://github.com/quicwg/base-drafts/issues/187#issuecomment-344132139

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#issuecomment-757591128

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 10 Jan 2021 18:25:08 -0800

For a more substantial discussion, please see https://github.com/quicwg/base-drafts/issues/1990 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#issuecomment-757592919

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 10 Jan 2021 18:35:46 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#issuecomment-757595173

---

From: kaduk <[email-masked]>
Date: Sun, 10 Jan 2021 20:39:05 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#issuecomment-757619680

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 10 Jan 2021 21:35:17 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#issuecomment-757633550

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 10 Jan 2021 21:35:32 -0800

Closed #4647 via #4722.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#event-4189003779

---

From: barryleiba <[email-masked]>
Date: Mon, 11 Jan 2021 13:44:05 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#issuecomment-758244201

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 11 Jan 2021 13:46:03 -0800

Thanks for the additional information Barry.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4647#issuecomment-758245219