All CAKE messages share a common header. Part of the header contains a message type that determines the format of the rest of the message.
Note: There may be portions of the CAKE protocol (specifically messages exchanged as part of a session) that do not start with this header. This document is not intended to document them. To find documentation for those, find the specific CAKE session negotiation messages (which do follow this format) that set up the session type that you're interested in.
| Field name | Short name | Basic field type |
| CAKE protocol version Always 1 |
protocol | count |
| Message flags | flags | 2 octets (16 bits) stored in MSB first order (aka network byte order). These bits have internal structure described later. |
| Message type | msgtype | count |
| Remainder of message | Determined by the message class part of the 'flags' field. |
The flags field actually is a combined field containing several pieces of information encoded into various bits of the field. The name isn't completely accurate, as not all of the values are simple yes/no flags. There is a group of 3 bits that combine to form a small number.
The field is two octets long, and is stored MSB first. Bit 15 is the most significant bit of the first octet, and bit 0 is the least significant bit of the second octet.
| Bits 15-5 | Bit 4 | Bits 3-1 | Bit 0 |
| Reserved, must be '0'. | Application specific flag | Message class | Encryption flag (0 means encrypted) |
The application specific flag modifies the meaning of the 'msgtype' field. If this flag is 0, the msgtype field must contain a number for some officially sanctioned and registered message type. If it is 1, then the msgtype field doesn't have any official meaning as far as the protocol description as a whole is concerned. This is sort of like the 'X-' prefix for a field name in the header of an 'RFC822' message.
| Message Class bit # | Class name and description | ||
| 3 | 2 | 1 | |
| 0 | 0 | 0 | Single
destination, nonsession
These messages are like advanced UDP packets. They don't require any data to have previously been exchanged with the recipient and they're complete unto themselves. Examples of these kinds of requests from other protocols are:
|
| 0 | 0 | 1 | Assertion
All of these messages will be unencrypted and will have an encryption flag of 0. Assertions are intended as messages that make some kind of signed, global statement to be read by anybody who cares to. If you want to privately send someone an assertion, there will be a message in class 0,0,0 that allows you to enclose an assertion inside an encrypted message to someone. |
| 0 | 1 | 0 | Session establishment and
continuation
These messages are for establishing continuing sessions that have various properties. Sessions require more state to be shared between participants, but are often more efficient, more reliable, more secure, or some combination thereof. |
| 0 | 1 | 1 | Multiple destination,
nonsession
These messages are for multicast messages not associated with a pre-established session. Multicast messages have multiple recipients, but only one source. The message types here are intended to mirror the message types available in class 0,0,0. For the recipient, receiving a multicast message should be much like receiving an ordinary unicast message. |
| 1 | 0 | 0 | Reserved |
| 1 | 0 | 1 | |
| 1 | 1 | 0 | |
| 1 | 1 | 1 | Experimental application
specific
These are for experimental message classes. I don't anticipate these ever being used for anything actually. I hope the already defined classes are sufficient. If this proves to be needed, it will only be used temporarily, until the exact nature of the new class is nailed down. Then it will be added to the main protocol under an official class. |