Internet Engineering Task Force P. Gansterer
Internet-Draft August 28, 2015
Intended status: Informational
Expires: February 29, 2016
JavaScript Object Notation (JSON) Call And Publish/Subscribe (CAPS)
draft-gansterer-jsoncaps-00
Abstract
JSON CAPS defines a communcation protocol for exchaning data between
two peers via remote procedure calls and a publish/subscribe
mechanism. The exchanged data is completely transparent to a proxy,
which can be put betweend the peers. It uses JSON as its basic
datastructure, but also defines different serialization for more
efficent transport.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 29, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Gansterer Expires February 29, 2016 [Page 1]
Internet-Draft JSON-CAPS August 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Network Topologies . . . . . . . . . . . . . . . . . . . 4
2.2. Communication Patters . . . . . . . . . . . . . . . . . . 5
2.2.1. Remote Procedure Call . . . . . . . . . . . . . . . . 5
2.2.2. Publish/Subscribe . . . . . . . . . . . . . . . . . . 6
2.3. Redundency . . . . . . . . . . . . . . . . . . . . . . . 7
3. Message Categories . . . . . . . . . . . . . . . . . . . . . 8
4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 9
5. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. General Messages . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Publish . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Processed . . . . . . . . . . . . . . . . . . . . . . 10
5.1.3. Progress . . . . . . . . . . . . . . . . . . . . . . 10
5.1.4. Result . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.5. Cancel Call . . . . . . . . . . . . . . . . . . . . . 11
5.2. Call Messages . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Ping . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.2. Unsubscribe . . . . . . . . . . . . . . . . . . . . . 12
5.2.3. Transfer Session . . . . . . . . . . . . . . . . . . 12
5.3. Subscribe Messages . . . . . . . . . . . . . . . . . . . 12
6. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Session Options . . . . . . . . . . . . . . . . . . . . . 13
6.2. Transfer Session . . . . . . . . . . . . . . . . . . . . 14
7. Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Event . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Single Value . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Multiple Values . . . . . . . . . . . . . . . . . . . . . 15
8. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. verbose . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. compact . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. JSON via Websocket . . . . . . . . . . . . . . . . . . . 16
9.2. CBOR via Websocket . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Comparison of other protocols to JSON-CAPS's Design
Objectives . . . . . . . . . . . . . . . . . . . . . 18
A.1. WAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Gansterer Expires February 29, 2016 [Page 2]
Internet-Draft JSON-CAPS August 2015
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Application which want to exchange structured data like JSON with
other peers over bidirectional connections usually have to define
their own communcation protocol. This docuemnt defines basic
framework for other protocols and/or application to be built on top
of it.
It offers the following main points:
o Remote Procedure Calls with Progress updates
o Subscriptions for events
o Subscriptions for topics with exactly one state
o Subscriptions for topics with an arbitrary count of states
o Allows implementation of transparent proxies
o Proxies can optionally implement caching to reduce load on the
original source
o Minimal effort for data handling at proxies, because of on-demand
subscriptions
o Support for redundancy with data-lost-free switchover
It also defines message encoding for the usage in combination with
WebSockets [RFC6455].
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This specification makes use of the following terminology:
peer: a node in a computer network
connection: bidirectianl communcation chanel between two peers
seesion: a semi-permanent interactive information interchange
between two peers
Gansterer Expires February 29, 2016 [Page 3]
Internet-Draft JSON-CAPS August 2015
client: a peer which opens a connection to server
server: peer allowing connections from clients
proxy: peer which acts as server and client at the same time
provider: peer which offers data to a consumer (usually the server)
consumer: peer consuming data from a provider (usually the client)
For CBOR data the diagnostic notation of [RFC7049] is used.
2. Overview
The following sections give a short overview how the different peers
interact with each other when used with JSON-CAPS.
2.1. Network Topologies
In the basic communcation pattern involes a client which connects to
a server. OPTIONAL one or more proxies can be put between the client
and server to act as cache and reduce load on the server.
In the default mode every client connects directly to the server.
+----------+ +--------+
| Client 1 |--->| |
+----------+ | |
| Server |
+----------+ | |
| Client 2 |--->| |
+----------+ +--------+
Figure 1
To reduce the load on the server it is possible to insert a proxy to
which the clients can connect to. In that case the proxy acts as the
only client to the server.
+----------+ +-------+
| Client 1 |--->| |
+----------+ | | +--------+
| Proxy |--->| Server |
+----------+ | | +--------+
| Client 2 |--->| |
+----------+ +-------+
Figure 2
Gansterer Expires February 29, 2016 [Page 4]
Internet-Draft JSON-CAPS August 2015
When used in more complicated network environments it MAY make sense
to stack the proxy servers.
+----------+ +---------+ +---------+
| Client 1 |--->| | | |
+----------+ | | | |
| Proxy 1 |--->| |
+----------+ | | | | +--------+
| Client 2 |--->| | | Proxy 2 |--->| Server |
+----------+ +---------+ | | +--------+
| |
+----------+ | |
| Client 3 |------------------>| |
+----------+ +---------+
Figure 3
2.2. Communication Patters
JSON-CAPS provides two basic communication patters.
2.2.1. Remote Procedure Call
This equal a classical Remote Procedure Call. A client sends a
request to the server and gets back a corresponding result. Before
sending the result the server MAY send additional messages to inform
the client about the current progress.
+--------+ +--------+
| |--(A)---- Call ---->| |
| | | |
| |<-(B)-- Progress ---| |
| Client | | Server |
| |<-(B)-- Progress ---| |
| | | |
| |<-(C)--- Result ----| |
+--------+ +--------+
Figure 4
The abstract message flow illustrated in Figure 4 describes the
interaction when a client calls a method on the server and includes
the following steps:
(A) The client requests the server to execute a specific method on
the server.
Gansterer Expires February 29, 2016 [Page 5]
Internet-Draft JSON-CAPS August 2015
(B) Optionally the server informs the client about the actual
progress of the execution.
(C) The client receives the result returned by the executed method
on the server.
2.2.2. Publish/Subscribe
A client can register itself on the server for receiving updates on a
specific topic. The server can then send updates to the client
without any delay when they are available. This avoids polling on
topics from the client.
+--------+ +--------+
| |--(A)--- Subscribe --->| |
| | | |
| |<-(B)---- Result ------| |
| | | |
| | | |
| |<-(C)---- Publish -----| |
| | | |
| |--(D)--- Processed --->| |
| | | |
| | | |
| Client |<-(E)---- Publish -----| Server |
| | | |
| |<-(F)---- Publish -----| |
| | | |
| |--(G)--- Processed --->| |
| | | |
| |--(H)--- Processed --->| |
| | | |
| | | |
| |--(I)-- Unsubscribe -->| |
| | | |
| |<-(J)---- Result ------| |
+--------+ +--------+
Figure 5
The abstract message flow illustrated in Figure 5 describes the
interaction for publish and subscribe and includes the following
steps:
(A) The client requests the server to subscribe a specific set of
topics.
(B) The client receives an aswer for the request in (A).
Gansterer Expires February 29, 2016 [Page 6]
Internet-Draft JSON-CAPS August 2015
(C) The server sends updates on the subscribed topics to the client.
(D) The client acknowledges the reciped of the update in (C).
(E) The server sends new data to the client.
(F) The server sends additional data to the client before the
previous data has been acknowledged.
(G) The client acknowledges the reciped of the update in (E).
(H) The client acknowledges the reciped of the update in (F).
(I) The client requests the server to stop sending new updates.
(J) The client receives an aswer for the request in (I).
2.3. Redundency
The whole protocol is built in way to support redundant connection
between the peers.
To take account of the redundancy feature one logical peer establishe
more than one connection to the other logical peer. If the
connection endpoints do not run on the same physical ressource, one
connection can get lost (e.g. caused by a crash or network
interruption), but the two peers can still exchange data.
+--------+ +---------+
| |--------->| Server |
| | +---------+
| | ^
| Client | |
| | v
| | +---------+
| |--------->| Server' |
+--------+ +---------+
Figure 6
The two physical peers Server and Server' represent the same logical
server and therforce have to behave identical. If one of the
connection between the client and the server get lost the data
exchange can be move to the other connection without lost of any
data.
Running a logical peer on more than one physical entity is not
limited to servers. Clients and proxies can be built redundent too.
Gansterer Expires February 29, 2016 [Page 7]
Internet-Draft JSON-CAPS August 2015
How physical entities representing the same logical unit synronize
their data is out of scope of this sepcification.
3. Message Categories
JSON-CAPS defines messages for calling methods, subscribing data and
for handling the corresponding results. To allow transparent
implementations of caching proxies the messages for subscribing are
split into three groups depending on the data. This leads to a total
of five categories, which determinate the behaviour of the message.
+----+-------------------------+
| ID | Category |
+----+-------------------------+
| G | General |
| C | Call |
| E | SubscribeEvent |
| S | SubscribeSingleValue |
| M | SubscribeMultipleValues |
+----+-------------------------+
Table 1: Message Categories
General: General messages are used to control the connection between
two peers and to send data from the server to the client.
Call: Call messages initiate the execution of a method on the server
and get answerd with exactly one result. For long running methods
the server can send progress messages between the call and result
message, to inform the client about already available data.
SubscribeEvent: The client tells the server that he is interessted
in getting events for a specific subset of occuring events. The
events do not have a state and therforce must not be cached by a
proxy.
SubscribeSingleValue: The client tells the server that he is
interessted in getting updates for a specific topic, which has
always exactly one defined state. The server must then send the
inital state and all changes of that state to the client via
publish messages. A caching proxy is allows to store the latest
state received from the server and send it directly to the client.
SubscribeMultipleValues: The client tells the server that he is
interessted in getting updates for a specific topic, which has can
have a list of states. To allow updates of only a single variable
in the list, the items need an unique key to distinguish them.
This unique key has always the name "key". Since old items need
Gansterer Expires February 29, 2016 [Page 8]
Internet-Draft JSON-CAPS August 2015
to get removed again an additional boolean property "retain" is
required. This value must be set to true if the client should
accept the item. To know the all inital values have been
tansfered to the client an empty object without "key" and "retain"
indicates the finished transfer of the inital values. Even in the
the case of an emtpy list the empty object must be sent. A
caching proxy can use a map with the "key" property as key and the
object as value. If "retain" is set to false updates from the
server remove existing object from the map. If "retain" is set to
true updates from the server replace the existing values in the
map or add new items, which leads to a list of all object which
should be keept on the proxy. The proxy can then send this list
as the inital values for a client subsribing the same topic.
All possible General messages are described in this document.
Applications using this protocol MUST NOT define any additonal
General messages, but MAY define their own set call and subscribe
messages depending on the area where used.
4. Message Format
Every message consist of the following parts:
Message Type
An identifier for specifying the kind of message.
Sequence Number
A numeric identifier to group messages belonging to a single
action. The peer sending the first message in that group is free
to choose this number, but must make sure that responses can be
identified correctly, which e.g. is not possible when using the
same number twice before receiving the full response of the
previous request.
Payload
A list of additonal values transporting the data. It depends on
the message type and can be even an empty list.
A encoder described in Section 8 defines how this data will be
encoded for the transfer between two peers.
5. Message Types
5.1. General Messages
Gansterer Expires February 29, 2016 [Page 9]
Internet-Draft JSON-CAPS August 2015
5.1.1. Publish
This message is used to send subscribed data to the client.
The Publish message is used to send new data to the client. The
client MUST sucessful subscribe to something before this message can
be sent.
Message Type: publish
Sequence Number: choosable
Payload: List of alternating subscriptionid and publishvalue.
Subscriptionid is the number returned by an subscribe message.
Publishvalue is the corresponding value of the subscribed item.
5.1.2. Processed
This message is used to acknowledge a publish message. This makes
the sequence number reusable for a new publish message.
Message Type: processed
Sequence Number: same as the one in the corresponding publish
message
Payload: empty
5.1.3. Progress
This message can be useed to update the client with information of
the progress of a call.
Message Type: progress
Sequence Number: same as the one in the corresponding call message
Payload: List of alternating callposition and value. Callposition
is the positon of the corresponding subcall in the call message.
Value is the corresponding value of the item.
5.1.4. Result
This message is used to send the final result of a call to the
client.
Message Type: result
Gansterer Expires February 29, 2016 [Page 10]
Internet-Draft JSON-CAPS August 2015
Sequence Number: same as the one in the corresponding call message
Payload: List of alternating info and value. Info can be an object
containing additional diagnostic information (e.g. error message)
to a specific subcall or must be NULL otherwise, which is also the
default value. Value is the corresponding value of the subcall.
5.1.5. Cancel Call
This message can be used to interrupt a pending call from the client.
The server must still send a result message for the canceled call and
SHOULD include information about the cancelation in the info object.
Message Type: cancelcall
Sequence Number: same as the one in the corresponding call message
Payload: empty
5.2. Call Messages
The message type defines which method should be invoked on the
server. Every item in the payload must be completely independed
handled. E.g. invoking a service with a payload of 3 items must
behave exactly the same as calling the same service for each item
separate, so the payload count would be one.
Every message must be answered with exactly one Result message, which
contains the same squence numer as in the call message. After the
sending peer received the corresponding Result message a sequnce
number can be used again.
If not specified differnt the methods do not send progress messages.
5.2.1. Ping
To implement a heartbeat functionality which checks the presents of a
working connection the client can call the ping method. This method
returns the same data, which has been sent in the request. If the
transport mechanism provides a more efficient way to check the
connection state, the client is free to use the alternative option.
Message Type: ping
Payload Item: any
Result Item Value: identical to the payload item
Gansterer Expires February 29, 2016 [Page 11]
Internet-Draft JSON-CAPS August 2015
5.2.2. Unsubscribe
This method is used to remove existing subscriptions.
Message Type: unsubscribe
Payload Item: subscription id as described in Section 5.3
Result Item Value: reference count of the subscibed item before
unsubscribing. 0 means that the item was not subscribed. 1
indicates that the last subscription for an item has been
unsubscribed and any allocated ressources for the items on the
server can be freed now. Any larger value indicates that the
subscription id has been used more than once and the server has
still work to do with that item. If the invalid subscription id 0
was sent by the client the server should respond with 0 as result
for it.
5.2.3. Transfer Session
This method is used to transfer the session to the connection sending
this message.
Message Type: transfersession
Payload Item: object containing the message type and sequence number
of the last valid received message by the client from the server
in the session: the message type uses the property name "type" and
the sequence numer "id"
Result Item Value: object containing the message type and sequence
number of the last valid received message by the server from the
client in the session: the message type uses the property name
"type" and the sequence numer "id". In the case of an error NULL
SCHOULD be returned.
5.3. Subscribe Messages
All messages in this category are use by the client to inform the
server about the topics it wants to get updates for. The diffence
between the three subscibe message is only the way the data is sent
in the publish messages as described in Section 7
Subscribing to a topic is done by calling a subscribe method as
described in Section 5.2, which MUST return a positve number. The
returned number represents the subscription id, which can bee freely
choosen by the server and will be used in the publish message as
described in Section 5.1.1. Returning 0 indicates an error and tells
Gansterer Expires February 29, 2016 [Page 12]
Internet-Draft JSON-CAPS August 2015
the client that the server is not able to subscibe the provided
topic. Subscibe methods MUST NOT send any progress messages.
6. Sessions
A session is a semi-permanent interactive information interchange
between a client and server. To initate a session the consumer sends
a inital message to the producer, which is refered to as the "hello"
message. The producer receiving the "hello" message MUST ignore the
message type, while the consumer SCHOULD send and emtpy string or 0
depending on the used encoding. The sequence number follows the
rules for calls, where the consumer can freely choose the value. It
is RECOMMENDED to use 0 as the sequence number for the hello message.
This document specifies a paylod for the hello message with exatly
one object as item, refered as "session request options". The valid
entries for this object are defined in Section 6.1. Sending more
than one payload item is reserved for future extensions to this
protocol and a conforming prodcer MUST ignore any additional payload
items.
After the receiving the hello message the producer must respond to it
with a result message using the sequence number of hello message and
a payload with exatly one object as item, referred as "session
response option". The valid entries for this object are defined in
Section 6.1. Sending more than one payload item is reserved for
future extensions to this protocol and a conforming consuer MUST
ignore any additional payload items.
6.1. Session Options
The session options are use to control the behaviour of the session.
The consumer can state its capabilities and preferences in the
session request options in the hello message, while the producer
makes the final decision about the used values.
messages: REQUIRED string-array with the names of all supported
message types prefixed with the message category id. The consumer
must send all messages it is able to receive. The producer then
sends the complete set of messages which are valid in the session
for both peers.
sessionid: OPTIONAL opaque unique identifier for the session created
by the producer. This property is REQUIRED if the session can
have multiple connection. A consumer sending this value indicates
that no new session should be created by the producer and the
connection should be added to the existing one with the provided
identifier. The consumer MUST always compare the returned value
Gansterer Expires February 29, 2016 [Page 13]
Internet-Draft JSON-CAPS August 2015
from the producer with it the sent value, to check if adding the
connection succeded or if a new session has been created.
idletimeout: OPTIONAL number of seconds a session will survive
without an active connection. A value of 0 indicates that the
session will become immediate invalid when the producer has no
open connection left to the consumer. A value of -1 indicates
that the session will never get teared down. Independent of the
returned value the producer can still create a new session before
the timout has been reached, if he is unable to recover the last
session, which will be indicated with a different sessionid.
6.2. Transfer Session
This feature can be used for recovering a session where all
connection have been lost to and to support redundancy without
datalost. Both points base on the fact that a session can have more
than one connection. In the first case the connection to a session
happen after each other. In the second case there are multiple
connections to the same session at the same time.
When more than none connection is used there is exactly one active
connection. All other connections are passive. The connection which
get a a new session assigend is automatic the active connection.
Later connections reusing the same session are in the passive state
after the inital hello and corresponding result message. This means
that no communication is allowed beside calling the transfersession
method. The active connection allows always the complete set
messages, including transfersession.
The transfersession method is used to switch the active one between
multiple connections or to active the new established connection
after a connection lost. To switch the connection the consumer has
to send a transfersession message with the type and sequence number
of the last received message on the active connection by the
consumer. The producer responses with message type and sequence
number of the last message which the producer has received on the
active connection.
If the transfersession call succeded the connection over which the
call has been executen is the new active connection and all other
connections are switched to the passive state. Immediate after
receiving a positve result the consumer MUST resend any messages
which might have been sent but have not been received by the producer
on the active connection. The producer does the same for all
message, which have not been received by the consumer. All passive
connection MUST NOT be used to transfer any data expect a
transfersession call, until they become active.
Gansterer Expires February 29, 2016 [Page 14]
Internet-Draft JSON-CAPS August 2015
7. Subscriptions
JSON-CAPS supports three kind of subscriptions, which differenciate
only by the data send from the producer to the consumer. During
execution of a subscribe method the producer assagins each
subscription an unique id within the session. This id is used
associate the data in the publish messages with the subscription.
7.1. Event
This subscription type is used for data without a state. Proxies
MUST NOT store any published data of this subscription type and are
only allows to forward the received data from the producer.
An subscription of this type could for example be used to send events
of pressing a button.
7.2. Single Value
This subscription type is used for stateful data, which has exactly
one value all the time. A proxy can cache the latest received
publish item and can send it to a consumer requesting the exactly
same subscription, without communication to the original producer.
An subscription of this type could for example be used to exchange
the temperature measured by a sensor. The sensor has exactly one
temperature which can be sent to the consumer.
7.3. Multiple Values
This subscription type is used for exchanging a list of data between
two peers. The data sent by the producer MUST be an object
containing a "key" and "retain" property as described in Table 1.
Applications using JSON-CAPS have to define additional properties in
this object to transfer the actual data. A proxy can cache the
current list of data, by updating it with the same algorithm as a
consumer whould do. This cached list can then be sent to a consumer
requesting the exactly same subscription, without communication to
the original producer.
An subscription of this type could for example be used to exchange a
list of sensors measuring a critical value. If every critical value
corresponds to one item in the list a new critical values does not
require sending the whole list to the consumer over and over again.
Instead only the new value needs be transfered, which leads to a more
efficient transport.
Gansterer Expires February 29, 2016 [Page 15]
Internet-Draft JSON-CAPS August 2015
8. Encoding
Every encoding defines an algorithm how the messages should be
encoded for transport. Receiving data which does not match the
choosen encoding SHOULD result in a connection error.
8.1. verbose
The message gets encoded as an JSON object with the following
properties:
type: Contains the name of the message type as string
id: The sequence number of the message as number
data: The payload array. If the payload array is empty this
property can be ommited.
A "ping" Message with sequence number 9 and payload of [{"id":1},
{"id":2}] would get encoded as the following object:
{"type": "ping", "id": 9, "data": [{"id":1}, {"id":2}]}
8.2. compact
The message gets encoded as an JSON array by using the message type
as the first item, the sequence number as the second item
concatenaited with the payload. Instead of using the string name of
the message type its index in the messages array in the hello
response MUST be used.
The Message with the type index 6, sequence number 9 and payload of
[{"id":1}, {"id":2}] would get encoded as the following array:
[6, 9, {"id":1}, {"id":2}]
9. Transport
9.1. JSON via Websocket
Every encoded message MUST serialized to JSON [RFC7159] and sent as
independent WebSocket [RFC6455] text messages.
Received text messages SHOULD be parsed as single JSON value. If the
received message is not a text message or does not contain valid JSON
data the WebSocket should be closed with an error.
Gansterer Expires February 29, 2016 [Page 16]
Internet-Draft JSON-CAPS August 2015
9.2. CBOR via Websocket
Every encoded message MUST serialized to CBOR [RFC7049] and sent as
independent WebSocket [RFC6455] binary messages.
Received binary messages SHOULD be parsed as single CBOR value. If
the received message is not a binary message or does not contain
valid CBOR data the WebSocket should be closed with an error.
10. IANA Considerations
This document has no actions for IANA.
11. Security Considerations
It is RECOMMENDED that the traffic transported over a WebSocket
communication be protected by using a secure WebSocket connection
(using TLS [RFC5246] over TCP).
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
6455, DOI 10.17487/RFC6455, December 2011,
<http://www.rfc-editor.org/info/rfc6455>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <http://www.rfc-editor.org/info/rfc7049>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
Gansterer Expires February 29, 2016 [Page 17]
Internet-Draft JSON-CAPS August 2015
12.2. Informative References
[WAMP] Tavendo GmbH, "WAMP - The Web Application Messaging
Protocol", 2015, <http://wamp.ws/>.
Appendix A. Comparison of other protocols to JSON-CAPS's Design
Objectives
A.1. WAMP
[WAMP] does not support a direct communication between a client and
server. It requires a Broker/Dealer inbetween to work properly.
Subscriptions in WAMP are handled in a way that a producer has to
send all data to the Broker, which then forwards this data only the
the client interresten in the corresponding topic.
Author's Address
Patrick Gansterer
Vienna
Austria
Phone: +43 676 686 01 04
Email: paroga@paroga.com
Gansterer Expires February 29, 2016 [Page 18]
Html markup produced by rfcmarkup 1.96, available from
http://tools.ietf.org/tools/rfcmarkup/