Revert "Update README.md"

This reverts commit daf9577.

README.md

@@ -10,7 +10,7 @@ Please check https://mles.io and https://mles.io/blog.html for a generic overvie
 
 ## Mles protocol overview
 
-Mles clients connect to an Mles server using Mles protocol header and (uid, channel, message) value triplet on a TLS [1] session where the triplet is Concise Binary Object Representation (CBOR) [1] encapsulated. An Mles client first subscribes to a channel by sending correct Mles protocol header and value triplet (uid, channel, msg) where _channel_ is the channel to publish/subscribe. The _msg_ MAY be either empty or include the first published message. The Mles server verifies Mles protocol header and then joins the Mles client to the selected channel. Every channel uses its own context and is independent of other channels: therefore a TLS session per (uid, channel) pair is always used. After joining, the Mles server distributes the value triplet between all clients on the same channel. If an Mles client wants to depart from a channel, it just closes the TLS session. If an Mles client does not want to receive any message, it just closes TLS session receive side. TLS session MUST be used as a session type by default.
+Mles clients connect to an Mles server using Mles protocol header and (uid, channel, message) value triplet on a TCP or TLS [1] session where the triplet is Concise Binary Object Representation (CBOR) [1] encapsulated. An Mles client first subscribes to a channel by sending correct Mles protocol header and value triplet (uid, channel, msg) where _channel_ is the channel to publish/subscribe. The _msg_ MAY be either empty or include the first published message. The Mles server verifies Mles protocol header and then joins the Mles client to the selected channel. Every channel uses its own context and is independent of other channels: therefore a TCP/TLS session per (uid, channel) pair is always used. After joining, the Mles server distributes the value triplet between all clients on the same channel. If an Mles client wants to depart from a channel, it just closes the TCP/TLS session. If an Mles client does not want to receive any message, it just closes TCP/TLS session receive side. TLS session SHOULD be selected as a session type by default.
 
 Every session between Mles server and client is authenticated using 64-bit SipHash [2]. The 64-bit key is hashed over provided UTF-8 strings. These can be combined from user connection endpoint details and/or a shared key and session (uid, channel) values. This allows Mles server to verify that a connecting Mles client is really connecting from the endpoint where it claims to be connecting with proper user and channel details. Mles client sessions behind Network Address Translation (NAT) MUST use a shared key without session endpoint detail authentication.