Re: [hybi] Changing meaning of 1007 status code ("frame" => "message")

> As said in other mail I suggest changing the meaning of 1007 status code
> from:
> 
>       1007 indicates that an endpoint is terminating the connection
>       because it has received data that was supposed to be UTF-8 (such
>       as in a text frame) that was in fact not valid UTF-8 [RFC3629].
> 
> to:
> 
>       1007 indicates that an endpoint is terminating the connection
>       because it has received a message that was supposed to be UTF-8
>       that was in fact not valid UTF-8 [RFC3629].

Does not make a difference, since a message that consists of
100 frames and contains invalid UTF-8 in the first frame is
as invalid as the same message containing the invalid octets
only in the last frame.

Why should I read the subsequent 99 frames after having
received the first frame with invalid UTF-8 before failing
the connection?

> WS message format/encoding/content MUST be validated when receiving all
> the frames belonging to such message, as message inspection/usage belongs
> to the WS application, rather than the WS "transport" layer (framing stuf).

No, since that would imply that you can't have a message of arbitrary
number of frames, or a message frame with 2^63 octets. No one could
buffer that, and there is no need to do so anyway, when you have a frame-based
or a streaming API in your implementation.

The question of API is orthogonal to the protocol.

> 
> Of couse, a WS endpoint COULD validate each text frame by inspecting
> whether it contains valid UTF-8 bytes (completed or splitted bytes).
> That's could be an optimization out of the scope of the protocol specification
> (as many others).
> 
> I insist: this specification SHOULD define logic layers, basically:
> 
> * WS transport layer: framing stuff and control frames.
> * WS application layer: sends and receives *full* WS messages (binary or
> text).

No, thats not WS. WS itself is not a message based, but framed streaming
protocol.

> 
> - The WS transport layer receives control frames and send control frames to
> the other endpoint.
> - The WS transport layer gives received *messages* to the WS application
> layer (it doesn't matter giving the full buffered message or using straming).

No, I have 3 types of API: message-based, frame-based and streaming.

> - The WS application layer sends *messages* to the WS transport layer.
> The transport layer decides whether to split, or not, the message into N
> frames.

No, there may be valid scenarios when the application wants to control
fragmentation. Think about multi-channel media streaming.

> - The WS application layer notifies the WS transport layer to close the
> connection with status 1007 upon receipt of an invalid UTF-8 text message.

No, the WS implementation fails the connection and fires a connectionClose()
handler on the application. See the JS WS API.

> Please consider it. Any protocol in Internet is designed with logical layers, all
> but WebSocket.

Your premise is false, and thus any conclusion void.

> 
> Regards.
> 
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi