Review by CA - Is the content of messages always bytes?

[gorryfair]

• Is the content of messages always bytes? I certainly got that
  impression, but didn't see it explicitly either. (The "protocols that
  expose byte-streams" have that property visible in their name). When
  framers are used a lot, I can envision that at some point a message
  might not use data bytes at all any more, as all information in the
  underlying message is being dissected into protocol specific
  properties.

[chrysn]

To give a bit of more context here:

The protocol(s) I have in mind to implement in terms of TAPS is the CoAP family, which is currently specified for UDP, TCP and WebSockets transports. TCP and WebSockets would work well with framers that get data down to messages, but a first "layer" of framers would still produce different styles of messages -- concretely, the native UDP datagrams contain bytes [something, code, message-id, token, options, payload] whereas after a layer of de-framing TCP, what is left is [code, token, options, payload] plus an additional property (token length) that is extracted from a nibble in the framing.

To make these messages usable more universally (i.e. independently of their transport), it'd make sense to de-frame these again (including de-framing the UDP messages) into decoding even more, moving code, token and options into properties. In the end, that will often result in messages that look like empty messages with a lot of properties -- is that OK? Would they even necessarily have a zero-length payload (byte-style message data)? Is the message's data just a (maybe special, maybe not) property of the message?

[tfpauly]

Messages can certainly be empty, and instead only contain Message Properties stored in the Message Context. We can make it clear that this is possible in section 5.2 of implementation.