2.1 Transport

As stated earlier in this document, a specific transport is not defined. However, the general requirements for a transport are as follows:

Transports on which this protocol is built MUST be able to provide reliable packet-based delivery of messages. The transport MUST be able to provide the size of each message, independently of its payload, to the component that implements the protocol.

Messages are published and subscribed over the transport on channels that are analogous to ports in TCP/IP. Well-known channel names allow two peers to establish initial communication. If a bi-directional exchange is required, the first message SHOULD contain an ID that allows the receiver to return a message on a channel based on that ID.

In this document, all multi-message exchanges except the final message use an 8-byte identifier to denote the channel on which the following message MUST be published. This identifier is referred to as a ChannelID. ChannelIDs MUST be generated by using cryptographically secure pseudo-random numbers to reduce the likelihood of collisions. A collision can result in a protocol failure, which means that the exchange MUST be manually attempted again. With Near Field Communication (NFC) as the typical transport, the user is required to tap or swipe the devices together again. However, with 64 bits of ChannelID address space, the chance of collision is unlikely.

Some transports, like Near Field Communication (NFC), require that the channel be encoded in characters that are allowed in a URI. When that is the case, the channel MUST be encoded by using base64 [RFC2045], with the exception that padding characters MUST be omitted. ChannelIDs that are 8 bytes therefore result in channels that are exactly 11 characters long.