Re: [Cbor] [IANA #1147225] Request for Assignment (websocket)

Carsten Bormann <cabo@tzi.org> Thu, 26 September 2019 07:29 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9509412080F for <cbor@ietfa.amsl.com>; Thu, 26 Sep 2019 00:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9ubdgSU3CpG for <cbor@ietfa.amsl.com>; Thu, 26 Sep 2019 00:28:59 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B3512004C for <cbor@ietf.org>; Thu, 26 Sep 2019 00:28:58 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46f6480SD4z10D4; Thu, 26 Sep 2019 09:28:56 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <rt-4.4.3-18233-1569454156-62.1147225-9-0@icann.org>
Date: Thu, 26 Sep 2019 09:28:55 +0200
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 591175733.592592-7c398ba4ca5b620fca5c24bc03e0dd31
Content-Transfer-Encoding: quoted-printable
Message-Id: <8641051F-CE59-4763-9ED6-E6387660564D@tzi.org>
References: <RT-Ticket-1147225@icann.org> <F64AC482-0342-4A2A-9082-5FCB17A157DE@iana.org> <ADFF7D45-0840-4AF5-991B-A3899682465E@tzi.org> <rt-4.4.3-9105-1568698350-278.1147225-9-0@icann.org> <rt-4.4.3-18233-1569454156-62.1147225-9-0@icann.org>
To: iana-prot-param-comment@iana.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/h9I0VaJJk7L3I4T9K3PgHn9OygM>
Subject: Re: [Cbor] [IANA #1147225] Request for Assignment (websocket)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2019 07:29:03 -0000

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 <iana-prot-param-comment@iana.org> wrote:
> 
> 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, cabo@tzi.org 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.
>> 
>> Sent from mobile, sorry for terse
>> 
>>> On 17. Sep 2019, at 07:49, Amanda Baber <amanda.baber@iana.org>
>>> wrote:
>>> 
>>> 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
>>> _______________________________________________
>>> CBOR mailing list
>>> CBOR@ietf.org
>>> https://www.ietf.org/mailman/listinfo/cbor
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>