1. Discussion of open issues for WebSocket binding Group Name: PRO WG Source: Qualcomm Inc., Wolfgang Granzow, Nobu Uchida Meeting Date: PRO#22, 2016-03-14 Agenda Item: WebSocket Binding PRO-2016-0086R01

2. Topics for discussion Definition of subprotocol names to be used in the Sec-WebSocket-Protocol header How to negotiate different data serialization formats between client and server Which binary serialization formats to support besides XML and JSON textual representations 2 © 2016 oneM2M Partners PRO-2016-0086_WebSocket_OpenIssues

3. Problem Statement WebSocket supports transfer of Application Data in both textual and binary formats There’s however no standardized way defined how a WebSocket client could negotiate the use of a specific Application Data format with the server (as e.g. in HTTP by using Accept and Content-Type headers) – How shall this information be indicated from the client to the server? Options: 1)oneM2M service/application specific protocol 2)WebSocket subprotocol header 3)WebSocket extension header. 3 © 2016 oneM2M Partners PRO-2016-0086_WebSocket_OpenIssues

4. Option 1 Adding new (optional) primitive parameters – request primitive: indicator of acceptable serialization formats (in order of preference) – Response primitive: indicator of the serialization format selected by the server Which format should then be used for the first primitive? – Starting with some default format? – Defining new primitives and protocol for negotiation of the serialization format? 4 © 2016 oneM2M Partners PRO-2016-0086_WebSocket_OpenIssues

5. Option 2 Assign a different subprotocol name to each supported serialization method – E.g. oneM2M-R2.0-XML, oneM2M-R2.0-JSON, … – Note: each supported subprotocol name needs to be registered in the IANA registry The client indicates the names of the subprotocols it offers in the Sec-WebSocket-Protocol header of the client handshake The server selects the subprotocol in the Sec- WebSocket-Protocol header of the server handshake 5 © 2016 oneM2M Partners PRO-2016-0086_WebSocket_OpenIssues

6. Option 3 Use of the Extensions header to negotiate the serialization format – The client indicates the serialization schemes it offers in the Sec- WebSocket-Extensions header of the client handshake – The server selects the subprotocol in the Sec-WebSocket-Extensions header of the server handshake Extension types also need to be IANA registered There is currently just one Extension Name defined: – permessage-deflate, RFC 7692 – Enabling per message selective compression 6 © 2016 oneM2M Partners PRO-2016-0086_WebSocket_OpenIssues

7. Which serialization formats shall be supported ? Textual formats: – Since all present bindings support JSON and XML, both should also be supported for WebSocket Binary formats: – There are probably several dozens of binary data interchange formats around Most of these have found only limited use cases 7 © 2016 oneM2M Partners PRO-2016-0086_WebSocket_OpenIssues

8. Some Candidates for Binary Serialization MessagePack (http://msgpack.org/)http://msgpack.org/ CBOR (RFC 7049)RFC 7049 BSON (Binary JSON) http://bsonspe.org/http://bsonspe.org/ UBJSON (Universal Binary JSON) http://ubjsonspe.org/http://ubjsonspe.org/ Protocol Buffers https://developers.google.com/protocol-buffers/ https://developers.google.com/protocol-buffers/ EXI (Efficient XML Interchange) https://www.w3.org/TR/exi-primer/ https://www.w3.org/TR/exi-primer/ Fast Infoset ITU-T X.891ITU-T X.891 ASN.1 BER/DER/PER (see references at Wikipedia)Wikipedia Traditional file compression methods (e.g. deflate/gzip) 8 © 2016 oneM2M Partners PRO-2016-0086_WebSocket_OpenIssues

9. Comparison of binary serialization formats Following slides show an illustrative example of encoding compactness Other critera: – Computational complexity – Extensibility, long-term maintenance – Additional requirements (need for schema definition) – Acceptance of the serialization scheme in the internet community 9

10. Illustrative example of message size Example AE resource instance – XML serialization w. short names: ' 2 ae1 cb1 20151116T142447 20151116T142447 acp1 20151116T 142447 SmartParkingDemo NsmartParkingApp01 CAE01 192.168.194.14 true cnt1 cnt2 cnt3 ' – JSON serialization w. short names: '{"m2m:ae": {"acpi": ["acp1"], "aei": "CAE01", "api": "NsmartParkingApp01", "apn": "SmartParkingDemo", "ch": [{"val": "cnt1", "nm": "SPD_GeneralData", "typ": "3"}, {"val": "cnt2", "nm": "SPD_LocationInfo", "typ": "3"}, {"val": "cnt3", "nm": "SPD_ParkingStatus", "typ": "3"}], "ct": "20151116T142447", "et": "20151116T142447", "lt": "20151116T142447", "pi": "cb1", "poa": ["192.168.194.14"], "ri": "ae1", "rn": "SmartParkingDemo", "rr": true, "ty": "2"}}' 10

11. Size of Serialization 11 Serialization rawgzipbase64encoded gzip bytes% % % Native Textual XML long nm80017739187 XML short nm47110429365 JSON long nm59613231369 JSON short nm45210023752 Keytagged JSON35188 Native binary messagePack306682214929665 CBOR306682114728463 BSON4611022675935679 UBSON359793046730467 Protocol Buffers234521854124855 Keytagged CBOR238531934326058

12. Protocol Buffers: example AE resource package oneM2M; option java_package = "com.example.oneM2M"; option java_outer_classname = "oneM2MProtos"; message ChildResource { required string name = 1; required string val = 2; required uint32 type = 3; } message AE { required uint32 resourceType = 1; required string resourceID = 2; required string resourceName = 3; required string parentID = 4; required string creationTime = 5; required string expirationTime = 6; required string lastModifiedTimpackage e = 7; required string AE_ID = 8; // dash "-" replaced by "_" required string App_ID = 9; optional string appName = 10; optional string labels = 11; // should be list of strings optional string accessControlPolicyIDs = 12; // should be list of strings optional string pointOfAccess = 13; // should be list of strings optional bool requestReachability = 14; repeated ChildResource childResource = 15; optional string ontologyRef = 16; optional string nodeLink = 17; } 12

13. “keytagged” JSON jsonKeyTag = \ { "m2m:AE": { 1: "CAE01", 2: "NtestApp01", 3: "acp1", 4: "testApplication", 5: [ { 1: "cnt1", 2: "TestContainer1", 3: "3" }, { 1: "cnt2", 2: "TestContainer12", 3: "3" } ], 6: "20150909T210208", 7: "20150909T210208", 8: "20150914T065251", 9: "cb1", 10: "192.168.194.14", 11: "true", 12: "ae1", 13: "TestAE", 14: "2", 15: "http://www.onem2m.org/xml/protocols" } 13

14. Proposal oneM2M release 2 should provide support for textual XML and JSON, and binary CBOR formats – It should be further discussed if any other binary serialization format should be supported as well The WebSocket subprotocol header (“option 2”) should be used to negotiate the serialization scheme – use e.g. following subprotocol names: oneM2M-R2.0-XML, oneM2M- R2.0-JSON, oneM2M-R2.0-CBOR Traditional compression (compliant with RFC 7692 framework) should be supported in addition Discuss applicability of binary serialization formats to HTTP, CoAP and MQTT binding too. 14 © 2016 oneM2M Partners PRO-2016-0086_WebSocket_OpenIssues