4. Messages

4.1 Messages

Servers and clients send each other messages, which may or may not generate a reply. If the message contains a valid command, as described in later sections, the client should expect a reply as specified but it is not advised to wait forever for the reply; client to server and server to server communication is essentially asynchronous by nature.

The command MUST be a valid DarkChannel command accepted in the current state of the protocol statemachine. Either side of a connection MUST terminate the connection should they receive an unexpected command for the current state of their protocol state machines.

DarkChannel messages are always one or more lines of characters, each followed by a CR-LF (Carriage Return - Line Feed) pair, terminated with the character "." (0x2E) on an empty line, followed by a CR-LF too.

These messages SHALL NOT exceed XXX characters in length, counting all characters including the trailing CR-LF. Thus, there are XXX characters maximum allowed for the command, its parameters and the attached blobs.

4.2 Message Format in Augmented BNF

The protocol messages MUST be extracted from the contiguous stream of octets. Messages are continious lines of text, each line terminated by the two characters CR and LF, as line separators. The message is terminated by the character '.' (0x2E) on a otherwise empty line.

Each DarkChannel message may consist of serveral main parts: The first line of text MUST contain the optional prefix, the command and it's parameters. The prefix, the command and all the parameters are separated by on ASCII space character (0x20) each. Following that zero or more additional blobs of text MAY follow, each separated by the character '-' (0x2D) on an otherwise empty line.

No line of text of a message may by shorter than 2 characters, not counting the CR and LF at the line end. This assures that the separator character '-' and the end character '.' can never be contained in a command or blob line.

The extracted message is parsed into the components command and a list of parameters params followed by a list of additional data blobs blobs with their number and content depending on the type of command.

The Augmented BNF representation for this is:

message    =  [ prefix ] command [ params ] crlf [ blobs ] end crlf
prefix     =  [ client "@" ] server
command    =  *( letter )
params     =  *( space *( param ) )
blobs      =  blob crlf *( sep crlf blob crlf )
client     =  keyid
server     =  keyid

letter     =  %x41-5A                                          ; A-Z
param      =  %x01-09 / %x0B-0C / %x0E-1F / %x21-FF            ; any octet except NUL, CR, LF, " "
blob       =  %x01-FF                                          ; any octet except NUL
space      =  %x20                                             ; space character
sep        =  0x2D                                             ; "-" character
end        =  0x2E                                             ; "." character
crlf       =  %x0D %x0A                                        ; "carriage return" "linefeed"
digit      =  %x30-39                                          ; 0-9
hexdigit   =  digit / "A" / "B" / "C" / "D" / "E" / "F"        ; 0-9, A-F
keyid      =  ( "0x" 16*( hexdigit ) )                         ; crypto system dependant:
                                                               ;   gpg: 0x{16}[A-Z]

The NUL (%x00) character is not special in message framing, and basically could end up inside a parameter, but it would cause extra complexities in normal C string handling. Therefore, NUL is not allowed within messages.