<filewiki_vars>
title=Messages
menu=$title
</filewiki_vars>


# 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.
