Since CAKE message type numbers are counts, which can get to be pretty large, information that divides message types into various categories are stored in the low bits of the message number instead of the high bits as is traditionally done in other protocols in which bits actually matter.

A CAKE message type number's trailing 4 bits are layed out like this:

Last 4 bits of a message number
Remaining bits Bits 3-1 Bit 0
Specific to the message category Message category Encryption flag (0 means encrypted)


Message category bits (bits 3-1 of the message number)
Message Category bit # Category 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:

  • DNS requests
  • mail messages (SMTP)
  • newsgroup messages (NNTP)
  • HTTP/1.0 requests (HTTP/1.1 requests can be pipelined and have multiple requests serviced per session.)
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 category 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 category 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 categories. I don't anticipate these ever being used for anything actually. I hope the already defined categories are sufficient.

If this proves to be needed, it will only be used temporarily, until the exact nature of the new category is nailed down. Then it will be added to the main protocol under an official category.