[hybi] [Technical Errata Reported] RFC6455 (7262)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC6455,
"The WebSocket Protocol".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7262

--------------------------------------
Type: Technical
Reported by: Demi Y <[e-mail]>

Section: 5.5.1

Original Text
-------------
Following the 2-byte integer, the body MAY contain UTF-8-encoded data
with value /reason/, the interpretation of which is not defined by
this specification.  This data is not necessarily human readable but
may be useful for debugging or passing information relevant to the
script that opened the connection.  As the data is not guaranteed to
be human readable, clients MUST NOT show it to end users.

Corrected Text
--------------
> Following the 2-byte integer, the body MAY contain data which MUST
be UTF-8-encoded with value /reason/, the interpretation of which is
not defined by this specification.

> As the interpretation is not defined here, clients MAY show it to
end users.

----- OR -----

> Following the 2-byte integer, the body MAY contain arbitrary data,
the interpretation of which is not defined by this specification.

> As the interpretation is not defined here, clients MAY hide it
from end users.

Notes
-----
The RFC is unclear on whether or not close-frames can contain binary data for the /reason/.

In section 5.2, "Application data" is defined as "arbitrary".

Section 5.5.1 also says about the /reason/:
> This data is not necessarily human readable ...
> As the data is not guaranteed to be human readable ...

Ok, but what if it is?

As per RFC 2119, The "MUST NOT show it to end users" here is not a mere suggestion.
It implies some sort of inherent danger or contract breaking that would occur if the data were "shown" (undefined term), as if passing along UTF-8 text in a controlled manner could cause harm to their application.

Due to the "MUST NOT", the "MAY contain UTF-8-encoded data" here is ambiguous. It implies it could be something other than UTF-8, like binary data, which would be unsafe to blindly "show" to the "end user" (undefined term). There is no clear reason as to why it (emphatically) "MUST NOT" be shown to "end users".

Who is the client and who is the "end user"? This is the only occurrence of "end user" in the RFC. Is the "client" the browser, and the "end user" the developer trying to debug their application, but "MUST NOT" see close /reason/s? In practice, the close reason is of course exposed by browsers. But then is the end user the non-developer who triggers an unexpected error on the server, and has no way to report a bug since the server's error /reason/ MUST NOT be shown to them? Why MUSTN'T it be shown? Is it because it MAY contain binary data?

Clarification is needed on whether or not the /reason/ can contain arbitrary binary data. And the imperative restriction on what the undefined "end user" can be "shown" should be loosened.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17)
--------------------------------------
Title               : The WebSocket Protocol
Publication Date    : December 2011
Author(s)           : I. Fette, A. Melnikov
Category            : PROPOSED STANDARD
Source              : BiDirectional or Server-Initiated HTTP APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG