Subject: [Cbor] [IANA #1147225] WebSocket Subprotocol Name registration

From: Amanda Baber <[email-masked]>
Date: Tue, 17 Sep 2019 04:49:26 +0000

Hi all,

IANA has received a request to register "cbor" in the WebSocket Subprotocol Name registry at

https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name

Barry Leiba and Alexey Melnikov suggested asking this mailing list for opinions on this request. 

This is all of the information that was provided:

===

Type of Assignment:
WebSocket Subprotocol ID: `cbor`, Common Name: `Concise Binary Object Representation`

Description:
A concise binary object format for representing structured data. Defined in https://tools.ietf.org/html/rfc7049

===

We understand that if this registration can be made, the RFC should not be listed on its own in the Subprotocol Definition field. In addition, we currently have only the requester's name to list in the registry's "Reference" field. 

We're also asking the JSON mailing list to comment on a request to register "json."

thanks,
Amanda

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 17 Sep 2019 08:31:41 +0300

To me it seems such a protocol would be about cbor sequences, not single cbor data items. The fact that I have to guess this, demonstrates the registration request is underspecified. 

Sent from mobile, sorry for terse

> On 17. Sep 2019, at 07:49, Amanda Baber <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Wed, 25 Sep 2019 23:29:16 +0000

HI Carsten, all,

We received a suggestion from the ADs that we specifically ask about the utility of websocket subprotocol IDs for CBOR (and, on that mailing list, JSON). Are there issues there? 

thanks,

Amanda Baber
Lead IANA Services Specialist

On Tue Sep 17 05:32:30 2019, [email-masked] wrote:
> To me it seems such a protocol would be about cbor sequences, not
> single cbor data items. The fact that I have to guess this,
> demonstrates the registration request is underspecified.
> 
> > A concise binary object format for representing structured data.
> > Defined in https://tools.ietf.org/html/rfc7049
> >
> > ===
> >
> > We understand that if this registration can be made, the RFC should
> > not be listed on its own in the Subprotocol Definition field. In
> > addition, we currently have only the requester's name to list in the
> > registry's "Reference" field.
> >

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Sep 2019 09:28:55 +0200

Hi Amanda,

There is not much information here, so I’ll try to supply context from what I happen to know what people are doing.

It is now a somewhat idiomatic way to use WebSockets by sending and receiving sequences of serialized JSON “objects” (maps), usually without any structure like JSON Text Sequences (RFC 7464) but just by relying the self-delimiting nature that serialized JSON objects (as opposed to, e.g., numbers) exhibit.  The equivalent result is easy to achieve using CBOR (which would be tantamount to using CBOR sequences [draft-ietf-cbor-sequence] as CBOR is already self-delimiting).

I believe both usages are fine and a good way to frame (structure) the channel provided by WebSockets.

Whether this enough to call each a WebSocket subprotocol is not easy to answer: Nothing is said about the semantics of those JSON objects/CBOR data items.  Note that, for media types, we have a similar question: We do have media types for application/json and application/cbor, which also say nothing about the semantics.  We also have the structured syntax suffixes +json and +cbor, so we can label a specific JSON or CBOR based media type as based on application/json and application/cbor, respectively.  Note that JSON over WebSockets is often used with an RPC-like next level protocol like JSON-RPC (*), which begs the same question:  Would json-rpc be sufficiently selective for a WebSocket protocol or would people expect that to say more about the semantics of the RPCs expressed in JSON-RPC?

No concept like structured syntax suffixes has been defined for WebSockets.  I think this is worth some more exploration.  As long as we don’t have them, the situation is similar to just having the base media types application/json and application/cbor.  However, for the WebSocket protocols, even defining the analog to these would require some additional specification explaining how (and whether, in the first place) multiple objects/data items are sent.  The CBOR sequence draft goes 90 % of the way here, as would the JSON Text Sequence RFC, except that the latter is not what people are actually doing on WebSockets these days.

So the questions are:

— would a JSON (CBOR) protocol defined in the above way be sufficient in detail to merit a WebSocket protocol name (comparable to application/json [application/cbor])?  (This is a question about the intent about the level of “selectivity” these protocol names should have, and only can be answered by WebSockets people.)
— do we want the equivalent of structured syntax suffixes for WebSocket protocol names?  (A convention for creating WebSocket protocol names, again a question for the WebSockets people.)
— which document defines the way sequences of objects/data items are handled?  (Easy for CBOR, slightly more work for JSON.)(**)

Grüße, Carsten

Here are a few quick Google results:
(*) Often in the form of “JSON RPC”, e.g. https://blog.sourced-bvba.be/article/2018/04/17/json-rpc-over-websockets/
(**) https://en.wikipedia.org/wiki/JSON_streaming, as discussed e.g., on https://stackoverflow.com/questions/6573870/choice-of-transports-for-json-over-tcp — often using what Wikipedia calls “concatenated JSON”, e.g. similar to http://www.simple-is-better.org/json-rpc/transport_sockets.html#pipelined-requests-responses-json-splitter

> On Sep 26, 2019, at 01:29, Amanda Baber via RT <[email-masked]> wrote:
> 
> HI Carsten, all,
>