+ The characteristics of the fixed types are listed in this table.
+
+ <informaltable>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Conventional name</entry>
+ <entry>ASCII type-code</entry>
+ <entry>Encoding</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>BYTE</literal></entry>
+ <entry><literal>y</literal> (121)</entry>
+ <entry>Unsigned 8-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>BOOLEAN</literal></entry>
+ <entry><literal>b</literal> (98)</entry>
+ <entry>Boolean value: 0 is false, 1 is true, any other value
+ allowed by the marshalling format is invalid</entry>
+ </row>
+ <row>
+ <entry><literal>INT16</literal></entry>
+ <entry><literal>n</literal> (110)</entry>
+ <entry>Signed (two's complement) 16-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>UINT16</literal></entry>
+ <entry><literal>q</literal> (113)</entry>
+ <entry>Unsigned 16-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>INT32</literal></entry>
+ <entry><literal>i</literal> (105)</entry>
+ <entry>Signed (two's complement) 32-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>UINT32</literal></entry>
+ <entry><literal>u</literal> (117)</entry>
+ <entry>Unsigned 32-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>INT64</literal></entry>
+ <entry><literal>x</literal> (120)</entry>
+ <entry>Signed (two's complement) 64-bit integer
+ (mnemonic: x and t are the first characters in "sixty" not
+ already used for something more common)</entry>
+ </row>
+ <row>
+ <entry><literal>UINT64</literal></entry>
+ <entry><literal>t</literal> (116)</entry>
+ <entry>Unsigned 64-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>DOUBLE</literal></entry>
+ <entry><literal>d</literal> (100)</entry>
+ <entry>IEEE 754 double-precision floating point</entry>
+ </row>
+ <row>
+ <entry><literal>UNIX_FD</literal></entry>
+ <entry><literal>h</literal> (104)</entry>
+ <entry>Unsigned 32-bit integer representing an index into an
+ out-of-band array of file descriptors, transferred via some
+ platform-specific mechanism (mnemonic: h for handle)</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
+
+ <para>
+ The <firstterm id="term-string-like-type">string-like types</firstterm>
+ are basic types with a variable length. The value of any string-like
+ type is conceptually 0 or more Unicode codepoints encoded in UTF-8,
+ none of which may be U+0000. The UTF-8 text must be validated
+ strictly: in particular, it must not contain overlong sequences
+ or codepoints above U+10FFFF.
+ </para>
+
+ <para>
+ Since D-Bus Specification version 0.21, in accordance with Unicode
+ Corrigendum #9, the "noncharacters" U+FDD0..U+FDEF, U+nFFFE and
+ U+nFFFF are allowed in UTF-8 strings (but note that older versions of
+ D-Bus rejected these noncharacters).
+ </para>
+
+ <para>
+ The marshalling formats for the string-like types all end with a
+ single zero (NUL) byte, but that byte is not considered to be part of
+ the text.
+ </para>
+
+ <para>
+ The characteristics of the string-like types are listed in this table.
+
+ <informaltable>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Conventional name</entry>
+ <entry>ASCII type-code</entry>
+ <entry>Validity constraints</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>STRING</literal></entry>
+ <entry><literal>s</literal> (115)</entry>
+ <entry>No extra constraints</entry>
+ </row>
+ <row>
+ <entry><literal>OBJECT_PATH</literal></entry>
+ <entry><literal>o</literal> (111)</entry>
+ <entry>Must be
+ <link linkend="message-protocol-marshaling-object-path">a
+ syntactically valid object path</link></entry>
+ </row>
+ <row>
+ <entry><literal>SIGNATURE</literal></entry>
+ <entry><literal>g</literal> (103)</entry>
+ <entry>Zero or more
+ <firstterm linkend="term-single-complete-type">single
+ complete types</firstterm></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
+
+ <sect3 id="message-protocol-marshaling-object-path">
+ <title>Valid Object Paths</title>
+
+ <para>
+ An object path is a name used to refer to an object instance.
+ Conceptually, each participant in a D-Bus message exchange may have
+ any number of object instances (think of C++ or Java objects) and each
+ such instance will have a path. Like a filesystem, the object
+ instances in an application form a hierarchical tree.
+ </para>
+
+ <para>
+ Object paths are often namespaced by starting with a reversed
+ domain name and containing an interface version number, in the
+ same way as
+ <link linkend="message-protocol-names-interface">interface
+ names</link> and
+ <link linkend="message-protocol-names-bus">well-known
+ bus names</link>.
+ This makes it possible to implement more than one service, or
+ more than one version of a service, in the same process,
+ even if the services share a connection but cannot otherwise
+ co-operate (for instance, if they are implemented by different
+ plugins).
+ </para>
+
+ <para>
+ For instance, if the owner of <literal>example.com</literal> is
+ developing a D-Bus API for a music player, they might use the
+ hierarchy of object paths that start with
+ <literal>/com/example/MusicPlayer1</literal> for its objects.
+ </para>
+
+ <para>
+ The following rules define a valid object path. Implementations must
+ not send or accept messages with invalid object paths.
+ <itemizedlist>
+ <listitem>
+ <para>
+ The path may be of any length.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The path must begin with an ASCII '/' (integer 47) character,
+ and must consist of elements separated by slash characters.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Each element must only contain the ASCII characters
+ "[A-Z][a-z][0-9]_"
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ No element may be the empty string.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Multiple '/' characters cannot occur in sequence.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A trailing '/' character is not allowed unless the
+ path is the root path (a single '/' character).
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ </sect3>
+
+ <sect3 id="message-protocol-marshaling-signature">
+ <title>Valid Signatures</title>
+ <para>
+ An implementation must not send or accept invalid signatures.
+ Valid signatures will conform to the following rules:
+ <itemizedlist>
+ <listitem>
+ <para>
+ The signature is a list of single complete types.
+ Arrays must have element types, and structs must
+ have both open and close parentheses.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Only type codes, open and close parentheses, and open and
+ close curly brackets are allowed in the signature. The
+ <literal>STRUCT</literal> type code
+ is not allowed in signatures, because parentheses
+ are used instead. Similarly, the
+ <literal>DICT_ENTRY</literal> type code is not allowed in
+ signatures, because curly brackets are used instead.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The maximum depth of container type nesting is 32 array type
+ codes and 32 open parentheses. This implies that the maximum
+ total depth of recursion is 64, for an "array of array of array
+ of ... struct of struct of struct of ..." where there are 32
+ array and 32 struct.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The maximum length of a signature is 255.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ When signatures appear in messages, the marshalling format
+ guarantees that they will be followed by a nul byte (which can
+ be interpreted as either C-style string termination or the INVALID
+ type-code), but this is not conceptually part of the signature.
+ </para>
+ </sect3>
+
+ </sect2>
+
+ <sect2 id="container-types">
+ <title>Container types</title>
+
+ <para>