doc/dbus-specification.xml

   1 <?xml version="1.0" standalone="no"?>
   2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
   3 "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
   4 [
   5 ]>
   6
   7 <article id="index">
   8   <articleinfo>
   9     <title>D-Bus Specification</title>
  10     <releaseinfo>Version 0.11</releaseinfo>
  11     <date>6 February 2005</date>
  12     <authorgroup>
  13       <author>
  14         <firstname>Havoc</firstname>
  15         <surname>Pennington</surname>
  16         <affiliation>
  17           <orgname>Red Hat, Inc.</orgname>
  18           <address>
  19             <email>hp@pobox.com</email>
  20           </address>
  21         </affiliation>
  22       </author>
  23       <author>
  24         <firstname>Anders</firstname>
  25         <surname>Carlsson</surname>
  26         <affiliation>
  27           <orgname>CodeFactory AB</orgname>
  28           <address>
  29             <email>andersca@codefactory.se</email>
  30           </address>
  31         </affiliation>
  32       </author>
  33       <author>
  34         <firstname>Alexander</firstname>
  35         <surname>Larsson</surname>
  36         <affiliation>
  37           <orgname>Red Hat, Inc.</orgname>
  38           <address>
  39             <email>alexl@redhat.com</email>
  40           </address>
  41         </affiliation>
  42       </author>
  43     </authorgroup>
  44   </articleinfo>
  45
  46   <sect1 id="introduction">
  47     <title>Introduction</title>
  48     <para>
  49       D-Bus is a system for low-latency, low-overhead, easy to use
  50       interprocess communication (IPC). In more detail:
  51       <itemizedlist>
  52         <listitem>
  53           <para>
  54             D-Bus is <emphasis>low-latency</emphasis> because it is designed
  55             to avoid round trips and allow asynchronous operation, much like
  56             the X protocol.
  57           </para>
  58         </listitem>
  59         <listitem>
  60           <para>
  61             D-Bus is <emphasis>low-overhead</emphasis> because it uses a
  62             binary protocol, and does not have to convert to and from a text
  63             format such as XML. Because D-Bus is intended for potentially
  64             high-resolution same-machine IPC, not primarily for Internet IPC,
  65             this is an interesting optimization.
  66           </para>
  67         </listitem>
  68         <listitem>
  69           <para>
  70             D-Bus is <emphasis>easy to use</emphasis> because it works in terms
  71             of <firstterm>messages</firstterm> rather than byte streams, and
  72             automatically handles a lot of the hard IPC issues. Also, the D-Bus
  73             library is designed to be wrapped in a way that lets developers use
  74             their framework's existing object/type system, rather than learning
  75             a new one specifically for IPC.
  76           </para>
  77         </listitem>
  78       </itemizedlist>
  79     </para>
  80
  81     <para>
  82       The base D-Bus protocol is a one-to-one (peer-to-peer or client-server)
  83       protocol, specified in <xref linkend="message-protocol"/>. That is, it is
  84       a system for one application to talk to a single other
  85       application. However, the primary intended application of the protocol is the
  86       D-Bus <firstterm>message bus</firstterm>, specified in <xref
  87       linkend="message-bus"/>. The message bus is a special application that
  88       accepts connections from multiple other applications, and forwards
  89       messages among them.
  90     </para>
  91
  92     <para>
  93       Uses of D-Bus include notification of system changes (notification of when
  94       a camera is plugged in to a computer, or a new version of some software
  95       has been installed), or desktop interoperability, for example a file
  96       monitoring service or a configuration service.
  97     </para>
  98
  99     <para>
 100       D-Bus is designed for two specific use cases:
 101       <itemizedlist>
 102         <listitem>
 103           <para>
 104             A "system bus" for notifications from the system to user sessions,
 105             and to allow the system to request input from user sessions.
 106           </para>
 107         </listitem>
 108         <listitem>
 109           <para>
 110             A "session bus" used to implement desktop environments such as
 111             GNOME and KDE.
 112           </para>
 113         </listitem>
 114       </itemizedlist>
 115       D-Bus is not intended to be a generic IPC system for any possible
 116       application, and intentionally omits many features found in other
 117       IPC systems for this reason. D-Bus may turn out to be useful
 118       in unanticipated applications, but future versions of this
 119       spec and the reference implementation probably will not
 120       incorporate features that interfere with the core use cases.
 121     </para>
 122
 123     <para>
 124       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 125       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 126       document are to be interpreted as described in RFC 2119. However, the
 127       document could use a serious audit to be sure it makes sense to do
 128       so. Also, they are not capitalized.
 129     </para>
 130
 131   </sect1>
 132
 133   <sect1 id="message-protocol">
 134     <title>Message Protocol</title>
 135
 136     <para>
 137       A <firstterm>message</firstterm> consists of a
 138       <firstterm>header</firstterm> and a <firstterm>body</firstterm>. If you
 139       think of a message as a package, the header is the address, and the body
 140       contains the package contents. The message delivery system uses the header
 141       information to figure out where to send the message and how to interpret
 142       it; the recipient interprets the body of the message.
 143     </para>
 144
 145     <para>
 146       The body of the message is made up of zero or more
 147       <firstterm>arguments</firstterm>, which are typed values, such as an
 148       integer or a byte array.
 149     </para>
 150
 151     <para>
 152       Both header and body use the same type system and format for
 153       serializing data. Each type of value has a wire format.
 154       Converting a value from some other representation into the wire
 155       format is called <firstterm>marshaling</firstterm> and converting
 156       it back from the wire format is <firstterm>unmarshaling</firstterm>.
 157     </para>
 158
 159     <sect2 id="message-protocol-signatures">
 160       <title>Type Signatures</title>
 161
 162       <para>
 163         The D-Bus protocol does not include type tags in the marshaled data; a
 164         block of marshaled values must have a known <firstterm>type
 165         signature</firstterm>.  The type signature is made up of <firstterm>type
 166         codes</firstterm>. A type code is an ASCII character representing the
 167         type of a value. Because ASCII characters are used, the type signature
 168         will always form a valid ASCII string. A simple string compare
 169         determines whether two type signatures are equivalent.
 170       </para>
 171
 172       <para>
 173         As a simple example, the type code for 32-bit integer (<literal>INT32</literal>) is
 174         the ASCII character 'i'. So the signature for a block of values
 175         containing a single <literal>INT32</literal> would be:
 176         <programlisting>
 177           "i"
 178         </programlisting>
 179         A block of values containing two <literal>INT32</literal> would have this signature:
 180         <programlisting>
 181           "ii"
 182         </programlisting>
 183       </para>
 184
 185       <para>
 186         All <firstterm>basic</firstterm> types work like
 187         <literal>INT32</literal> in this example. To marshal and unmarshal
 188         basic types, you simply read one value from the data
 189         block corresponding to each type code in the signature.
 190         In addition to basic types, there are four <firstterm>container</firstterm>
 191         types: <literal>STRUCT</literal>, <literal>ARRAY</literal>, <literal>VARIANT</literal>,
 192         and <literal>DICT_ENTRY</literal>.
 193       </para>
 194
 195       <para>
 196         <literal>STRUCT</literal> has a type code, ASCII character 'r', but this type
 197         code does not appear in signatures. Instead, ASCII characters
 198         '(' and ')' are used to mark the beginning and end of the struct.
 199         So for example, a struct containing two integers would have this
 200         signature:
 201         <programlisting>
 202           "(ii)"
 203         </programlisting>
 204         Structs can be nested, so for example a struct containing
 205         an integer and another struct:
 206         <programlisting>
 207           "(i(ii))"
 208         </programlisting>
 209         The value block storing that struct would contain three integers; the
 210         type signature allows you to distinguish "(i(ii))" from "((ii)i)" or
 211         "(iii)" or "iii".
 212       </para>
 213
 214       <para>
 215         The <literal>STRUCT</literal> type code 'r' is not currently used in the D-Bus protocol,
 216         but is useful in code that implements the protocol. This type code
 217         is specified to allow such code to interoperate in non-protocol contexts.
 218       </para>
 219
 220       <para>
 221         <literal>ARRAY</literal> has ASCII character 'a' as type code. The array type code must be
 222         followed by a <firstterm>single complete type</firstterm>. The single
 223         complete type following the array is the type of each array element. So
 224         the simple example is:
 225         <programlisting>
 226           "ai"
 227         </programlisting>
 228         which is an array of 32-bit integers. But an array can be of any type,
 229         such as this array-of-struct-with-two-int32-fields:
 230         <programlisting>
 231           "a(ii)"
 232         </programlisting>
 233         Or this array of array of integer:
 234         <programlisting>
 235           "aai"
 236         </programlisting>
 237       </para>
 238
 239       <para>
 240         The phrase <firstterm>single complete type</firstterm> deserves some
 241         definition. A single complete type is a basic type code, a variant type code,
 242         an array with its element type, or a struct with its fields.
 243         So the following signatures are not single complete types:
 244         <programlisting>
 245           "aa"
 246         </programlisting>
 247         <programlisting>
 248           "(ii"
 249         </programlisting>
 250         <programlisting>
 251           "ii)"
 252         </programlisting>
 253         And the following signatures contain multiple complete types:
 254         <programlisting>
 255           "ii"
 256         </programlisting>
 257         <programlisting>
 258           "aiai"
 259         </programlisting>
 260         <programlisting>
 261           "(ii)(ii)"
 262         </programlisting>
 263         Note however that a single complete type may <emphasis>contain</emphasis>
 264         multiple other single complete types.
 265       </para>
 266
 267       <para>
 268         <literal>VARIANT</literal> has ASCII character 'v' as its type code. A marshaled value of
 269         type <literal>VARIANT</literal> will have the signature of a single complete type as part
 270         of the <emphasis>value</emphasis>.  This signature will be followed by a
 271         marshaled value of that type.
 272       </para>
 273
 274       <para>
 275         A <literal>DICT_ENTRY</literal> works exactly like a struct, but rather
 276         than parentheses it uses curly braces, and it has more restrictions.
 277         The restrictions are: it occurs only as an array element type; it has
 278         exactly two single complete types inside the curly braces; the first
 279         single complete type (the "key") must be a basic type rather than a
 280         container type. Implementations must not accept dict entries outside of
 281         arrays, must not accept dict entries with zero, one, or more than two
 282         fields, and must not accept dict entries with non-basic-typed keys. A
 283         dict entry is always a key-value pair.
 284       </para>
 285
 286       <para>
 287         The first field in the <literal>DICT_ENTRY</literal> is always the key.
 288         A message is considered corrupt if the same key occurs twice in the same
 289         array of <literal>DICT_ENTRY</literal>. However, for performance reasons
 290         implementations are not required to reject dicts with duplicate keys.
 291       </para>
 292
 293       <para>
 294         In most languages, an array of dict entry would be represented as a
 295         map, hash table, or dict object.
 296       </para>
 297
 298       <para>
 299         The following table summarizes the D-Bus types.
 300         <informaltable>
 301           <tgroup cols="3">
 302             <thead>
 303               <row>
 304                 <entry>Conventional Name</entry>
 305                 <entry>Code</entry>
 306                 <entry>Description</entry>
 307               </row>
 308             </thead>
 309             <tbody>
 310               <row>
 311                 <entry><literal>INVALID</literal></entry>
 312                 <entry>0 (ASCII NUL)</entry>
 313                 <entry>Not a valid type code, used to terminate signatures</entry>
 314               </row><row>
 315                 <entry><literal>BYTE</literal></entry>
 316                 <entry>121 (ASCII 'y')</entry>
 317                 <entry>8-bit unsigned integer</entry>
 318               </row><row>
 319                 <entry><literal>BOOLEAN</literal></entry>
 320                 <entry>98 (ASCII 'b')</entry>
 321                 <entry>Boolean value, 0 is <literal>FALSE</literal> and 1 is <literal>TRUE</literal>. Everything else is invalid.</entry>
 322               </row><row>
 323                 <entry><literal>INT16</literal></entry>
 324                 <entry>110 (ASCII 'n')</entry>
 325                 <entry>16-bit signed integer</entry>
 326               </row><row>
 327                 <entry><literal>UINT16</literal></entry>
 328                 <entry>113 (ASCII 'q')</entry>
 329                 <entry>16-bit unsigned integer</entry>
 330               </row><row>
 331                 <entry><literal>INT32</literal></entry>
 332                 <entry>105 (ASCII 'i')</entry>
 333                 <entry>32-bit signed integer</entry>
 334               </row><row>
 335                 <entry><literal>UINT32</literal></entry>
 336                 <entry>117 (ASCII 'u')</entry>
 337                 <entry>32-bit unsigned integer</entry>
 338               </row><row>
 339                 <entry><literal>INT64</literal></entry>
 340                 <entry>120 (ASCII 'x')</entry>
 341                 <entry>64-bit signed integer</entry>
 342               </row><row>
 343                 <entry><literal>UINT64</literal></entry>
 344                 <entry>116 (ASCII 't')</entry>
 345                 <entry>64-bit unsigned integer</entry>
 346               </row><row>
 347                 <entry><literal>DOUBLE</literal></entry>
 348                 <entry>100 (ASCII 'd')</entry>
 349                 <entry>IEEE 754 double</entry>
 350               </row><row>
 351                 <entry><literal>STRING</literal></entry>
 352                 <entry>115 (ASCII 's')</entry>
 353                 <entry>UTF-8 string (<emphasis>must</emphasis> be valid UTF-8). Must be nul terminated.</entry>
 354               </row><row>
 355                 <entry><literal>OBJECT_PATH</literal></entry>
 356                 <entry>111 (ASCII 'o')</entry>
 357                 <entry>Name of an object instance</entry>
 358               </row><row>
 359                 <entry><literal>SIGNATURE</literal></entry>
 360                 <entry>103 (ASCII 'g')</entry>
 361                 <entry>A type signature</entry>
 362               </row><row>
 363                 <entry><literal>ARRAY</literal></entry>
 364                 <entry>97 (ASCII 'a')</entry>
 365                 <entry>Array</entry>
 366               </row><row>
 367                 <entry><literal>STRUCT</literal></entry>
 368                 <entry>114 (ASCII 'r'), 40 (ASCII '('), 41 (ASCII ')')</entry>
 369                 <entry>Struct</entry>
 370               </row><row>
 371                 <entry><literal>VARIANT</literal></entry>
 372                 <entry>118 (ASCII 'v') </entry>
 373                 <entry>Variant type (the type of the value is part of the value itself)</entry>
 374               </row><row>
 375                 <entry><literal>DICT_ENTRY</literal></entry>
 376                 <entry>101 (ASCII 'e'), 123 (ASCII '{'), 125 (ASCII '}') </entry>
 377                 <entry>Entry in a dict or map (array of key-value pairs)</entry>
 378               </row>
 379             </tbody>
 380           </tgroup>
 381         </informaltable>
 382       </para>
 383
 384     </sect2>
 385
 386     <sect2 id="message-protocol-marshaling">
 387       <title>Marshaling (Wire Format)</title>
 388
 389       <para>
 390         Given a type signature, a block of bytes can be converted into typed
 391         values. This section describes the format of the block of bytes.  Byte
 392         order and alignment issues are handled uniformly for all D-Bus types.
 393       </para>
 394
 395       <para>
 396         A block of bytes has an associated byte order. The byte order
 397         has to be discovered in some way; for D-Bus messages, the
 398         byte order is part of the message header as described in
 399         <xref linkend="message-protocol-messages"/>. For now, assume
 400         that the byte order is known to be either little endian or big
 401           endian.
 402       </para>
 403
 404       <para>
 405         Each value in a block of bytes is aligned "naturally," for example
 406         4-byte values are aligned to a 4-byte boundary, and 8-byte values to an
 407         8-byte boundary. To properly align a value, <firstterm>alignment
 408         padding</firstterm> may be necessary. The alignment padding must always
 409         be the minimum required padding to properly align the following value;
 410         and it must always be made up of nul bytes. The alignment padding must
 411         not be left uninitialized (it can't contain garbage), and more padding
 412         than required must not be used.
 413       </para>
 414
 415       <para>
 416         Given all this, the types are marshaled on the wire as follows:
 417         <informaltable>
 418           <tgroup cols="3">
 419             <thead>
 420               <row>
 421                 <entry>Conventional Name</entry>
 422                 <entry>Encoding</entry>
 423                 <entry>Alignment</entry>
 424               </row>
 425             </thead>
 426             <tbody>
 427               <row>
 428                 <entry><literal>INVALID</literal></entry>
 429                 <entry>Not applicable; cannot be marshaled.</entry>
 430                 <entry>N/A</entry>
 431               </row><row>
 432                 <entry><literal>BYTE</literal></entry>
 433                 <entry>A single 8-bit byte.</entry>
 434                 <entry>1</entry>
 435               </row><row>
 436                 <entry><literal>BOOLEAN</literal></entry>
 437                 <entry>As for <literal>UINT32</literal>, but only 0 and 1 are valid values.</entry>
 438                 <entry>4</entry>
 439               </row><row>
 440                 <entry><literal>INT16</literal></entry>
 441                 <entry>16-bit signed integer in the message's byte order.</entry>
 442                 <entry>2</entry>
 443               </row><row>
 444                 <entry><literal>UINT16</literal></entry>
 445                 <entry>16-bit unsigned integer in the message's byte order.</entry>
 446                 <entry>2</entry>
 447               </row><row>
 448                 <entry><literal>INT32</literal></entry>
 449                 <entry>32-bit signed integer in the message's byte order.</entry>
 450                 <entry>4</entry>
 451               </row><row>
 452                 <entry><literal>UINT32</literal></entry>
 453                 <entry>32-bit unsigned integer in the message's byte order.</entry>
 454                 <entry>4</entry>
 455               </row><row>
 456                 <entry><literal>INT64</literal></entry>
 457                 <entry>64-bit signed integer in the message's byte order.</entry>
 458                 <entry>8</entry>
 459               </row><row>
 460                 <entry><literal>UINT64</literal></entry>
 461                 <entry>64-bit unsigned integer in the message's byte order.</entry>
 462                 <entry>8</entry>
 463               </row><row>
 464                 <entry><literal>DOUBLE</literal></entry>
 465                 <entry>64-bit IEEE 754 double in the message's byte order.</entry>
 466                 <entry>8</entry>
 467               </row><row>
 468                 <entry><literal>STRING</literal></entry>
 469                 <entry>A <literal>UINT32</literal> indicating the string's
 470                   length in bytes excluding its terminating nul, followed by
 471                   string data of the given length, followed by a terminating nul
 472                   byte.
 473                 </entry>
 474                 <entry>
 475                   4 (for the length)
 476                 </entry>
 477               </row><row>
 478                 <entry><literal>OBJECT_PATH</literal></entry>
 479                 <entry>Exactly the same as <literal>STRING</literal> except the
 480                   content must be a valid object path (see below).
 481                 </entry>
 482                 <entry>
 483                   4 (for the length)
 484                 </entry>
 485               </row><row>
 486                 <entry><literal>SIGNATURE</literal></entry>
 487                 <entry>The same as <literal>STRING</literal> except the length is a single
 488                   byte (thus signatures have a maximum length of 255)
 489                   and the content must be a valid signature (see below).
 490                 </entry>
 491                 <entry>
 492                   1
 493                 </entry>
 494               </row><row>
 495                 <entry><literal>ARRAY</literal></entry>
 496                 <entry>
 497                   A <literal>UINT32</literal> giving the length of the array data in bytes, followed by
 498                   alignment padding to the alignment boundary of the array element type,
 499                   followed by each array element. The array length is from the
 500                   end of the alignment padding to the end of the last element,
 501                   i.e. it does not include the padding after the length,
 502                   or any padding after the last element.
 503                   Arrays have a maximum length defined to be 2 to the 26th power or
 504                   67108864. Implementations must not send or accept arrays exceeding this
 505                   length.
 506                 </entry>
 507                 <entry>
 508                   4 (for the length)
 509                 </entry>
 510               </row><row>
 511                 <entry><literal>STRUCT</literal></entry>
 512                 <entry>
 513                   A struct must start on an 8-byte boundary regardless of the
 514                   type of the struct fields. The struct value consists of each
 515                   field marshaled in sequence starting from that 8-byte
 516                   alignment boundary.
 517                 </entry>
 518                 <entry>
 519                   8
 520                 </entry>
 521               </row><row>
 522                 <entry><literal>VARIANT</literal></entry>
 523                 <entry>
 524                   A variant type has a marshaled <literal>SIGNATURE</literal>
 525                   followed by a marshaled value with the type
 526                   given in the signature.
 527                   Unlike a message signature, the variant signature
 528                   can contain only a single complete type.
 529                   So "i" is OK, "ii" is not.
 530                 </entry>
 531                 <entry>
 532                   1 (alignment of the signature)
 533                 </entry>
 534               </row><row>
 535                 <entry><literal>DICT_ENTRY</literal></entry>
 536                 <entry>
 537                   Identical to STRUCT.
 538                 </entry>
 539                 <entry>
 540                   8
 541                 </entry>
 542               </row>
 543             </tbody>
 544           </tgroup>
 545         </informaltable>
 546       </para>
 547
 548       <sect3 id="message-protocol-marshaling-object-path">
 549         <title>Valid Object Paths</title>
 550
 551         <para>
 552           An object path is a name used to refer to an object instance.
 553           Conceptually, each participant in a D-Bus message exchange may have
 554           any number of object instances (think of C++ or Java objects) and each
 555           such instance will have a path. Like a filesystem, the object
 556           instances in an application form a hierarchical tree.
 557         </para>
 558
 559         <para>
 560           The following rules define a valid object path. Implementations must
 561           not send or accept messages with invalid object paths.
 562           <itemizedlist>
 563             <listitem>
 564               <para>
 565                 The path may be of any length.
 566               </para>
 567             </listitem>
 568             <listitem>
 569               <para>
 570                 The path must begin with an ASCII '/' (integer 47) character,
 571                 and must consist of elements separated by slash characters.
 572               </para>
 573             </listitem>
 574             <listitem>
 575               <para>
 576                 Each element must only contain the ASCII characters
 577                 "[A-Z][a-z][0-9]_"
 578               </para>
 579             </listitem>
 580             <listitem>
 581               <para>
 582                 No element may be the empty string.
 583               </para>
 584             </listitem>
 585             <listitem>
 586               <para>
 587                 Multiple '/' characters cannot occur in sequence.
 588               </para>
 589             </listitem>
 590             <listitem>
 591               <para>
 592                 A trailing '/' character is not allowed unless the
 593                 path is the root path (a single '/' character).
 594               </para>
 595             </listitem>
 596           </itemizedlist>
 597         </para>
 598
 599       </sect3>
 600
 601
 602       <sect3 id="message-protocol-marshaling-signature">
 603         <title>Valid Signatures</title>
 604         <para>
 605           An implementation must not send or accept invalid signatures.
 606           Valid signatures will conform to the following rules:
 607           <itemizedlist>
 608             <listitem>
 609               <para>
 610                 The signature ends with a nul byte.
 611               </para>
 612             </listitem>
 613             <listitem>
 614               <para>
 615                 The signature is a list of single complete types.
 616                 Arrays must have element types, and structs must
 617                 have both open and close parentheses.
 618               </para>
 619             </listitem>
 620             <listitem>
 621               <para>
 622                 Only type codes and open and close parentheses are
 623                 allowed in the signature. The <literal>STRUCT</literal> type code
 624                 is not allowed in signatures, because parentheses
 625                 are used instead.
 626               </para>
 627             </listitem>
 628             <listitem>
 629               <para>
 630                 The maximum depth of container type nesting is 32 array type
 631                 codes and 32 open parentheses. This implies that the maximum
 632                 total depth of recursion is 64, for an "array of array of array
 633                 of ... struct of struct of struct of ..."  where there are 32
 634                 array and 32 struct.
 635               </para>
 636             </listitem>
 637             <listitem>
 638               <para>
 639                 The maximum length of a signature is 255.
 640               </para>
 641             </listitem>
 642             <listitem>
 643               <para>
 644                 Signatures must be nul-terminated.
 645               </para>
 646             </listitem>
 647           </itemizedlist>
 648         </para>
 649       </sect3>
 650
 651     </sect2>
 652
 653     <sect2 id="message-protocol-messages">
 654       <title>Message Format</title>
 655
 656       <para>
 657         A message consists of a header and a body. The header is a block of
 658         values with a fixed signature and meaning.  The body is a separate block
 659         of values, with a signature specified in the header.
 660       </para>
 661
 662       <para>
 663         The length of the header must be a multiple of 8, allowing the body to
 664         begin on an 8-byte boundary when storing the entire message in a single
 665         buffer. If the header does not naturally end on an 8-byte boundary
 666         up to 7 bytes of nul-initialized alignment padding must be added.
 667       </para>
 668
 669       <para>
 670         The message body need not end on an 8-byte boundary.
 671       </para>
 672
 673       <para>
 674         The maximum length of a message, including header, header alignment padding,
 675         and body is 2 to the 27th power or 134217728. Implementations must not
 676         send or accept messages exceeding this size.
 677       </para>
 678
 679       <para>
 680         The signature of the header is:
 681         <programlisting>
 682           "yyyyuua(yv)"
 683         </programlisting>
 684         Written out more readably, this is:
 685         <programlisting>
 686           BYTE, BYTE, BYTE, BYTE, UINT32, UINT32, ARRAY of STRUCT of (BYTE,VARIANT)
 687         </programlisting>
 688       </para>
 689
 690       <para>
 691         These values have the following meanings:
 692         <informaltable>
 693           <tgroup cols="2">
 694             <thead>
 695               <row>
 696                 <entry>Value</entry>
 697                 <entry>Description</entry>
 698               </row>
 699             </thead>
 700             <tbody>
 701               <row>
 702                 <entry>1st <literal>BYTE</literal></entry>
 703                 <entry>Endianness flag; ASCII 'l' for little-endian
 704                   or ASCII 'B' for big-endian. Both header and body are
 705                 in this endianness.</entry>
 706               </row>
 707               <row>
 708                 <entry>2nd <literal>BYTE</literal></entry>
 709                 <entry><firstterm>Message type</firstterm>. Unknown types must be ignored.
 710                   Currently-defined types are described below.
 711                 </entry>
 712               </row>
 713               <row>
 714                 <entry>3rd <literal>BYTE</literal></entry>
 715                 <entry>Bitwise OR of flags. Unknown flags
 716                   must be ignored. Currently-defined flags are described below.
 717                 </entry>
 718               </row>
 719               <row>
 720                 <entry>4th <literal>BYTE</literal></entry>
 721                 <entry>Major protocol version of the sending application.  If
 722                 the major protocol version of the receiving application does not
 723                 match, the applications will not be able to communicate and the
 724                 D-Bus connection must be disconnected. The major protocol
 725                 version for this version of the specification is 0.
 726                   FIXME this field is stupid and pointless to put in
 727                   every message.
 728                 </entry>
 729               </row>
 730               <row>
 731                 <entry>1st <literal>UINT32</literal></entry>
 732                 <entry>Length in bytes of the message body, starting
 733                   from the end of the header. The header ends after
 734                   its alignment padding to an 8-boundary.
 735                 </entry>
 736               </row>
 737               <row>
 738                 <entry>2nd <literal>UINT32</literal></entry>
 739                 <entry>The serial of this message, used as a cookie
 740                   by the sender to identify the reply corresponding
 741                   to this request.
 742                 </entry>
 743               </row>
 744               <row>
 745                 <entry><literal>ARRAY</literal> of <literal>STRUCT</literal> of (<literal>BYTE</literal>,<literal>VARIANT</literal>)</entry>
 746                 <entry>An array of zero or more <firstterm>header
 747                   fields</firstterm> where the byte is the field code, and the
 748                   variant is the field value. The message type determines
 749                   which fields are required.
 750                 </entry>
 751               </row>
 752             </tbody>
 753           </tgroup>
 754         </informaltable>
 755       </para>
 756       <para>
 757         <firstterm>Message types</firstterm> that can appear in the second byte
 758         of the header are:
 759         <informaltable>
 760           <tgroup cols="3">
 761             <thead>
 762               <row>
 763                 <entry>Conventional name</entry>
 764                 <entry>Decimal value</entry>
 765                 <entry>Description</entry>
 766               </row>
 767             </thead>
 768             <tbody>
 769               <row>
 770                 <entry><literal>INVALID</literal></entry>
 771                 <entry>0</entry>
 772                 <entry>This is an invalid type.</entry>
 773               </row>
 774               <row>
 775                 <entry><literal>METHOD_CALL</literal></entry>
 776                 <entry>1</entry>
 777                 <entry>Method call.</entry>
 778               </row>
 779               <row>
 780                 <entry><literal>METHOD_RETURN</literal></entry>
 781                 <entry>2</entry>
 782                 <entry>Method reply with returned data.</entry>
 783               </row>
 784               <row>
 785                 <entry><literal>ERROR</literal></entry>
 786                 <entry>3</entry>
 787                 <entry>Error reply. If the first argument exists and is a
 788                 string, it is an error message.</entry>
 789               </row>
 790               <row>
 791                 <entry><literal>SIGNAL</literal></entry>
 792                 <entry>4</entry>
 793                 <entry>Signal emission.</entry>
 794               </row>
 795             </tbody>
 796           </tgroup>
 797         </informaltable>
 798       </para>
 799       <para>
 800         Flags that can appear in the third byte of the header:
 801         <informaltable>
 802           <tgroup cols="3">
 803             <thead>
 804               <row>
 805                 <entry>Conventional name</entry>
 806                 <entry>Hex value</entry>
 807                 <entry>Description</entry>
 808               </row>
 809             </thead>
 810             <tbody>
 811               <row>
 812                 <entry><literal>NO_REPLY_EXPECTED</literal></entry>
 813                 <entry>0x1</entry>
 814                 <entry>This message does not expect method return replies or
 815                 error replies; the reply can be omitted as an
 816                 optimization. However, it is compliant with this specification
 817                 to return the reply despite this flag and the only harm
 818                   from doing so is extra network traffic.
 819                 </entry>
 820               </row>
 821               <row>
 822                 <entry><literal>NO_AUTO_START</literal></entry>
 823                 <entry>0x2</entry>
 824                 <entry>The bus must not launch an owner
 825                   for the destination name in response to this message.
 826                 </entry>
 827               </row>
 828             </tbody>
 829           </tgroup>
 830         </informaltable>
 831       </para>
 832
 833       <sect3 id="message-protocol-header-fields">
 834         <title>Header Fields</title>
 835
 836         <para>
 837           The array at the end of the header contains <firstterm>header
 838           fields</firstterm>, where each field is a 1-byte field code followed
 839           by a field value. A header must contain the required header fields for
 840           its message type, and zero or more of any optional header
 841           fields. Future versions of this protocol specification may add new
 842           fields. Implementations must ignore fields they do not
 843           understand. Implementations must not invent their own header fields;
 844           only changes to this specification may introduce new header fields.
 845         </para>
 846
 847         <para>
 848           Again, if an implementation sees a header field code that it does not
 849           expect, it must ignore that field, as it will be part of a new
 850           (but compatible) version of this specification. This also applies
 851           to known header fields appearing in unexpected messages, for
 852           example: if a signal has a reply serial it must be ignored
 853           even though it has no meaning as of this version of the spec.
 854         </para>
 855
 856         <para>
 857           However, implementations must not send or accept known header fields
 858           with the wrong type stored in the field value. So for example a
 859           message with an <literal>INTERFACE</literal> field of type
 860           <literal>UINT32</literal> would be considered corrupt.
 861         </para>
 862
 863         <para>
 864           Here are the currently-defined header fields:
 865           <informaltable>
 866             <tgroup cols="5">
 867               <thead>
 868                 <row>
 869                   <entry>Conventional Name</entry>
 870                   <entry>Decimal Code</entry>
 871                   <entry>Type</entry>
 872                   <entry>Required In</entry>
 873                   <entry>Description</entry>
 874                 </row>
 875               </thead>
 876               <tbody>
 877                 <row>
 878                   <entry><literal>INVALID</literal></entry>
 879                   <entry>0</entry>
 880                   <entry>N/A</entry>
 881                   <entry>not allowed</entry>
 882                   <entry>Not a valid field name (error if it appears in a message)</entry>
 883                 </row>
 884                 <row>
 885                   <entry><literal>PATH</literal></entry>
 886                   <entry>1</entry>
 887                   <entry><literal>OBJECT_PATH</literal></entry>
 888                   <entry><literal>METHOD_CALL</literal>, <literal>SIGNAL</literal></entry>
 889                   <entry>The object to send a call to,
 890                     or the object a signal is emitted from.
 891                   </entry>
 892                 </row>
 893                 <row>
 894                   <entry><literal>INTERFACE</literal></entry>
 895                   <entry>2</entry>
 896                   <entry><literal>STRING</literal></entry>
 897                   <entry><literal>SIGNAL</literal></entry>
 898                   <entry>
 899                     The interface to invoke a method call on, or
 900                     that a signal is emitted from. Optional for
 901                     method calls, required for signals.
 902                   </entry>
 903                 </row>
 904                 <row>
 905                   <entry><literal>MEMBER</literal></entry>
 906                   <entry>3</entry>
 907                   <entry><literal>STRING</literal></entry>
 908                   <entry><literal>METHOD_CALL</literal>, <literal>SIGNAL</literal></entry>
 909                   <entry>The member, either the method name or signal name.</entry>
 910                 </row>
 911                 <row>
 912                   <entry><literal>ERROR_NAME</literal></entry>
 913                   <entry>4</entry>
 914                   <entry><literal>STRING</literal></entry>
 915                   <entry><literal>ERROR</literal></entry>
 916                   <entry>The name of the error that occurred, for errors</entry>
 917                 </row>
 918                 <row>
 919                   <entry><literal>REPLY_SERIAL</literal></entry>
 920                   <entry>5</entry>
 921                   <entry><literal>UINT32</literal></entry>
 922                   <entry><literal>ERROR</literal>, <literal>METHOD_RETURN</literal></entry>
 923                   <entry>The serial number of the message this message is a reply
 924                     to. (The serial number is the second <literal>UINT32</literal> in the header.)</entry>
 925                 </row>
 926                 <row>
 927                   <entry><literal>DESTINATION</literal></entry>
 928                   <entry>6</entry>
 929                   <entry><literal>STRING</literal></entry>
 930                   <entry>optional</entry>
 931                   <entry>The name of the connection this message is intended for.
 932                     Only used in combination with the message bus, see
 933                     <xref linkend="message-bus"/>.</entry>
 934                 </row>
 935                 <row>
 936                   <entry><literal>SENDER</literal></entry>
 937                   <entry>7</entry>
 938                   <entry><literal>STRING</literal></entry>
 939                   <entry>optional</entry>
 940                   <entry>Unique name of the sending connection.
 941                     The message bus fills in this field so it is reliable; the field is
 942                     only meaningful in combination with the message bus.</entry>
 943                 </row>
 944                 <row>
 945                   <entry><literal>SIGNATURE</literal></entry>
 946                   <entry>8</entry>
 947                   <entry><literal>SIGNATURE</literal></entry>
 948                   <entry>optional</entry>
 949                   <entry>The signature of the message body.
 950                   If omitted, it is assumed to be the
 951                   empty signature "" (i.e. the body must be 0-length).</entry>
 952                 </row>
 953               </tbody>
 954             </tgroup>
 955           </informaltable>
 956         </para>
 957       </sect3>
 958     </sect2>
 959
 960     <sect2 id="message-protocol-names">
 961       <title>Valid Names</title>
 962       <para>
 963         The various names in D-Bus messages have some restrictions.
 964       </para>
 965       <para>
 966         There is a <firstterm>maximum name length</firstterm>
 967         of 255 which applies to bus names, interfaces, and members.
 968       </para>
 969       <sect3 id="message-protocol-names-interface">
 970         <title>Interface names</title>
 971         <para>
 972           Interfaces have names with type <literal>STRING</literal>, meaning that
 973           they must be valid UTF-8. However, there are also some
 974           additional restrictions that apply to interface names
 975           specifically:
 976           <itemizedlist>
 977             <listitem><para>Interface names are composed of 1 or more elements separated by
 978                 a period ('.') character. All elements must contain at least
 979                 one character.
 980                 </para>
 981             </listitem>
 982             <listitem><para>Each element must only contain the ASCII characters
 983                 "[A-Z][a-z][0-9]_" and must not begin with a digit.
 984                 </para>
 985             </listitem>
 986
 987             <listitem><para>Interface names must contain at least one '.' (period)
 988               character (and thus at least two elements).
 989               </para></listitem>
 990
 991             <listitem><para>Interface names must not begin with a '.' (period) character.</para></listitem>
 992             <listitem><para>Interface names must not exceed the maximum name length.</para></listitem>
 993           </itemizedlist>
 994         </para>
 995       </sect3>
 996       <sect3 id="message-protocol-names-bus">
 997         <title>Bus names</title>
 998         <para>
 999           Connections have one or more bus names associated with them.
1000           A connection has exactly one bus name that is a unique connection
1001           name. The unique connection name remains with the connection for
1002           its entire lifetime.
1003           A bus name is of type <literal>STRING</literal>,
1004           meaning that it must be valid UTF-8. However, there are also
1005           some additional restrictions that apply to bus names
1006           specifically:
1007           <itemizedlist>
1008             <listitem><para>Bus names that start with a colon (':')
1009                 character are unique connection names.
1010                 </para>
1011             </listitem>
1012             <listitem><para>Bus names are composed of 1 or more elements separated by
1013                 a period ('.') character. All elements must contain at least
1014                 one character.
1015                 </para>
1016             </listitem>
1017             <listitem><para>Each element must only contain the ASCII characters
1018                 "[A-Z][a-z][0-9]_-". Only elements that are part of a unique
1019                 connection name may begin with a digit, elements in
1020                 other bus names must not begin with a digit.
1021                 </para>
1022             </listitem>
1023
1024             <listitem><para>Bus names must contain at least one '.' (period)
1025               character (and thus at least two elements).
1026               </para></listitem>
1027
1028             <listitem><para>Bus names must not begin with a '.' (period) character.</para></listitem>
1029             <listitem><para>Bus names must not exceed the maximum name length.</para></listitem>
1030           </itemizedlist>
1031         </para>
1032         <para>
1033           Note that the hyphen ('-') character is allowed in bus names but
1034           not in interface names.
1035         </para>
1036       </sect3>
1037       <sect3 id="message-protocol-names-member">
1038         <title>Member names</title>
1039         <para>
1040           Member (i.e. method or signal) names:
1041           <itemizedlist>
1042             <listitem><para>Must only contain the ASCII characters
1043                 "[A-Z][a-z][0-9]_" and may not begin with a
1044                 digit.</para></listitem>
1045             <listitem><para>Must not contain the '.' (period) character.</para></listitem>
1046             <listitem><para>Must not exceed the maximum name length.</para></listitem>
1047             <listitem><para>Must be at least 1 byte in length.</para></listitem>
1048           </itemizedlist>
1049         </para>
1050       </sect3>
1051       <sect3 id="message-protocol-names-error">
1052         <title>Error names</title>
1053         <para>
1054           Error names have the same restrictions as interface names.
1055         </para>
1056       </sect3>
1057     </sect2>
1058
1059     <sect2 id="message-protocol-types">
1060       <title>Message Types</title>
1061       <para>
1062         Each of the message types (<literal>METHOD_CALL</literal>, <literal>METHOD_RETURN</literal>, <literal>ERROR</literal>, and
1063         <literal>SIGNAL</literal>) has its own expected usage conventions and header fields.
1064         This section describes these conventions.
1065       </para>
1066       <sect3 id="message-protocol-types-method">
1067         <title>Method Calls</title>
1068         <para>
1069           Some messages invoke an operation on a remote object.  These are
1070           called method call messages and have the type tag <literal>METHOD_CALL</literal>. Such
1071           messages map naturally to methods on objects in a typical program.
1072         </para>
1073         <para>
1074           A method call message is required to have a <literal>MEMBER</literal> header field
1075           indicating the name of the method. Optionally, the message has an
1076           <literal>INTERFACE</literal> field giving the interface the method is a part of. In the
1077           absence of an <literal>INTERFACE</literal> field, if two interfaces on the same object have
1078           a method with the same name, it is undefined which of the two methods
1079           will be invoked. Implementations may also choose to return an error in
1080           this ambiguous case. However, if a method name is unique
1081           implementations must not require an interface field.
1082         </para>
1083         <para>
1084           Method call messages also include a <literal>PATH</literal> field
1085           indicating the object to invoke the method on. If the call is passing
1086           through a message bus, the message will also have a
1087           <literal>DESTINATION</literal> field giving the name of the connection
1088           to receive the message.
1089         </para>
1090         <para>
1091           When an application handles a method call message, it is required to
1092           return a reply. The reply is identified by a <literal>REPLY_SERIAL</literal> header field
1093           indicating the serial number of the <literal>METHOD_CALL</literal> being replied to. The
1094           reply can have one of two types; either <literal>METHOD_RETURN</literal> or <literal>ERROR</literal>.
1095         </para>
1096         <para>
1097           If the reply has type <literal>METHOD_RETURN</literal>, the arguments to the reply message
1098           are the return value(s) or "out parameters" of the method call.
1099           If the reply has type <literal>ERROR</literal>, then an "exception" has been thrown,
1100           and the call fails; no return value will be provided. It makes
1101           no sense to send multiple replies to the same method call.
1102         </para>
1103         <para>
1104           Even if a method call has no return values, a <literal>METHOD_RETURN</literal>
1105           reply is required, so the caller will know the method
1106           was successfully processed.
1107         </para>
1108         <para>
1109           The <literal>METHOD_RETURN</literal> or <literal>ERROR</literal> reply message must have the <literal>REPLY_SERIAL</literal>
1110           header field.
1111         </para>
1112         <para>
1113           If a <literal>METHOD_CALL</literal> message has the flag <literal>NO_REPLY_EXPECTED</literal>,
1114           then as an optimization the application receiving the method
1115           call may choose to omit the reply message (regardless of
1116           whether the reply would have been <literal>METHOD_RETURN</literal> or <literal>ERROR</literal>).
1117           However, it is also acceptable to ignore the <literal>NO_REPLY_EXPECTED</literal>
1118           flag and reply anyway.
1119         </para>
1120         <para>
1121           Unless a message has the flag <literal>NO_AUTO_START</literal>, if the
1122           destination name does not exist then a program to own the destination
1123           name will be started before the message is delivered.  The message
1124           will be held until the new program is successfully started or has
1125           failed to start; in case of failure, an error will be returned. This
1126           flag is only relevant in the context of a message bus, it is ignored
1127           during one-to-one communication with no intermediate bus.
1128         </para>
1129         <sect4 id="message-protocol-types-method-apis">
1130           <title>Mapping method calls to native APIs</title>
1131           <para>
1132             APIs for D-Bus may map method calls to a method call in a specific
1133             programming language, such as C++, or may map a method call written
1134             in an IDL to a D-Bus message.
1135           </para>
1136           <para>
1137             In APIs of this nature, arguments to a method are often termed "in"
1138             (which implies sent in the <literal>METHOD_CALL</literal>), or "out" (which implies
1139             returned in the <literal>METHOD_RETURN</literal>). Some APIs such as CORBA also have
1140             "inout" arguments, which are both sent and received, i.e. the caller
1141             passes in a value which is modified. Mapped to D-Bus, an "inout"
1142             argument is equivalent to an "in" argument, followed by an "out"
1143             argument. You can't pass things "by reference" over the wire, so
1144             "inout" is purely an illusion of the in-process API.
1145           </para>
1146           <para>
1147             Given a method with zero or one return values, followed by zero or more
1148             arguments, where each argument may be "in", "out", or "inout", the
1149             caller constructs a message by appending each "in" or "inout" argument,
1150             in order. "out" arguments are not represented in the caller's message.
1151           </para>
1152           <para>
1153             The recipient constructs a reply by appending first the return value
1154             if any, then each "out" or "inout" argument, in order.
1155             "in" arguments are not represented in the reply message.
1156           </para>
1157           <para>
1158             Error replies are normally mapped to exceptions in languages that have
1159             exceptions.
1160           </para>
1161           <para>
1162             In converting from native APIs to D-Bus, it is perhaps nice to
1163             map D-Bus naming conventions ("FooBar") to native conventions
1164             such as "fooBar" or "foo_bar" automatically. This is OK
1165             as long as you can say that the native API is one that
1166             was specifically written for D-Bus. It makes the most sense
1167             when writing object implementations that will be exported
1168             over the bus. Object proxies used to invoke remote D-Bus
1169             objects probably need the ability to call any D-Bus method,
1170             and thus a magic name mapping like this could be a problem.
1171           </para>
1172           <para>
1173             This specification doesn't require anything of native API bindings;
1174             the preceding is only a suggested convention for consistency
1175             among bindings.
1176           </para>
1177         </sect4>
1178       </sect3>
1179
1180       <sect3 id="message-protocol-types-signal">
1181         <title>Signal Emission</title>
1182         <para>
1183           Unlike method calls, signal emissions have no replies.
1184           A signal emission is simply a single message of type <literal>SIGNAL</literal>.
1185           It must have three header fields: <literal>PATH</literal> giving the object
1186           the signal was emitted from, plus <literal>INTERFACE</literal> and <literal>MEMBER</literal> giving
1187           the fully-qualified name of the signal. The <literal>INTERFACE</literal> header is required
1188           for signals, though it is optional for method calls.
1189         </para>
1190       </sect3>
1191
1192       <sect3 id="message-protocol-types-errors">
1193         <title>Errors</title>
1194         <para>
1195           Messages of type <literal>ERROR</literal> are most commonly replies
1196           to a <literal>METHOD_CALL</literal>, but may be returned in reply
1197           to any kind of message. The message bus for example
1198           will return an <literal>ERROR</literal> in reply to a signal emission if
1199           the bus does not have enough memory to send the signal.
1200         </para>
1201         <para>
1202           An <literal>ERROR</literal> may have any arguments, but if the first
1203           argument is a <literal>STRING</literal>, it must be an error message.
1204           The error message may be logged or shown to the user
1205           in some way.
1206         </para>
1207       </sect3>
1208
1209       <sect3 id="message-protocol-types-notation">
1210         <title>Notation in this document</title>
1211         <para>
1212           This document uses a simple pseudo-IDL to describe particular method
1213           calls and signals. Here is an example of a method call:
1214           <programlisting>
1215             org.freedesktop.DBus.StartServiceByName (in STRING name, in UINT32 flags,
1216                                                      out UINT32 resultcode)
1217           </programlisting>
1218           This means <literal>INTERFACE</literal> = org.freedesktop.DBus, <literal>MEMBER</literal> = StartServiceByName,
1219           <literal>METHOD_CALL</literal> arguments are <literal>STRING</literal> and <literal>UINT32</literal>, <literal>METHOD_RETURN</literal> argument
1220           is <literal>UINT32</literal>. Remember that the <literal>MEMBER</literal> field can't contain any '.' (period)
1221           characters so it's known that the last part of the name in
1222           the "IDL" is the member name.
1223         </para>
1224         <para>
1225           In C++ that might end up looking like this:
1226           <programlisting>
1227             unsigned int org::freedesktop::DBus::StartServiceByName (const char  *name,
1228                                                                      unsigned int flags);
1229           </programlisting>
1230           or equally valid, the return value could be done as an argument:
1231           <programlisting>
1232             void org::freedesktop::DBus::StartServiceByName (const char   *name,
1233                                                              unsigned int  flags,
1234                                                              unsigned int *resultcode);
1235           </programlisting>
1236           It's really up to the API designer how they want to make
1237           this look. You could design an API where the namespace wasn't used
1238           in C++, using STL or Qt, using varargs, or whatever you wanted.
1239         </para>
1240         <para>
1241           Signals are written as follows:
1242           <programlisting>
1243             org.freedesktop.DBus.NameLost (STRING name)
1244           </programlisting>
1245           Signals don't specify "in" vs. "out" because only
1246           a single direction is possible.
1247         </para>
1248         <para>
1249           It isn't especially encouraged to use this lame pseudo-IDL in actual
1250           API implementations; you might use the native notation for the
1251           language you're using, or you might use COM or CORBA IDL, for example.
1252         </para>
1253       </sect3>
1254     </sect2>
1255
1256     <sect2 id="message-protocol-handling-invalid">
1257       <title>Invalid Protocol and Spec Extensions</title>
1258
1259       <para>
1260         For security reasons, the D-Bus protocol should be strictly parsed and
1261         validated, with the exception of defined extension points. Any invalid
1262         protocol or spec violations should result in immediately dropping the
1263         connection without notice to the other end. Exceptions should be
1264         carefully considered, e.g. an exception may be warranted for a
1265         well-understood idiosyncrasy of a widely-deployed implementation.  In
1266         cases where the other end of a connection is 100% trusted and known to
1267         be friendly, skipping validation for performance reasons could also make
1268         sense in certain cases.
1269       </para>
1270
1271       <para>
1272         Generally speaking violations of the "must" requirements in this spec
1273         should be considered possible attempts to exploit security, and violations
1274         of the "should" suggestions should be considered legitimate (though perhaps
1275         they should generate an error in some cases).
1276       </para>
1277
1278       <para>
1279         The following extension points are built in to D-Bus on purpose and must
1280         not be treated as invalid protocol. The extension points are intended
1281         for use by future versions of this spec, they are not intended for third
1282         parties.  At the moment, the only way a third party could extend D-Bus
1283         without breaking interoperability would be to introduce a way to negotiate new
1284         feature support as part of the auth protocol, using EXTENSION_-prefixed
1285         commands. There is not yet a standard way to negotiate features.
1286         <itemizedlist>
1287           <listitem>
1288             <para>
1289               In the authentication protocol (see <xref linkend="auth-protocol"/>) unknown
1290                 commands result in an ERROR rather than a disconnect. This enables
1291                 future extensions to the protocol. Commands starting with EXTENSION_ are
1292                 reserved for third parties.
1293             </para>
1294           </listitem>
1295           <listitem>
1296             <para>
1297               The authentication protocol supports pluggable auth mechanisms.
1298             </para>
1299           </listitem>
1300           <listitem>
1301             <para>
1302               The address format (see <xref linkend="addresses"/>) supports new
1303               kinds of transport.
1304             </para>
1305           </listitem>
1306           <listitem>
1307             <para>
1308               Messages with an unknown type (something other than
1309               <literal>METHOD_CALL</literal>, <literal>METHOD_RETURN</literal>,
1310               <literal>ERROR</literal>, <literal>SIGNAL</literal>) are ignored.
1311               Unknown-type messages must still be well-formed in the same way
1312               as the known messages, however. They still have the normal
1313               header and body.
1314             </para>
1315           </listitem>
1316           <listitem>
1317             <para>
1318               Header fields with an unknown or unexpected field code must be ignored,
1319               though again they must still be well-formed.
1320             </para>
1321           </listitem>
1322           <listitem>
1323             <para>
1324               New standard interfaces (with new methods and signals) can of course be added.
1325             </para>
1326           </listitem>
1327         </itemizedlist>
1328       </para>
1329
1330     </sect2>
1331
1332   </sect1>
1333
1334   <sect1 id="auth-protocol">
1335     <title>Authentication Protocol</title>
1336     <para>
1337       Before the flow of messages begins, two applications must
1338       authenticate. A simple plain-text protocol is used for
1339       authentication; this protocol is a SASL profile, and maps fairly
1340       directly from the SASL specification. The message encoding is
1341       NOT used here, only plain text messages.
1342     </para>
1343     <para>
1344       In examples, "C:" and "S:" indicate lines sent by the client and
1345       server respectively.
1346     </para>
1347     <sect2 id="auth-protocol-overview">
1348       <title>Protocol Overview</title>
1349       <para>
1350         The protocol is a line-based protocol, where each line ends with
1351         \r\n. Each line begins with an all-caps ASCII command name containing
1352         only the character range [A-Z_], a space, then any arguments for the
1353         command, then the \r\n ending the line. The protocol is
1354         case-sensitive. All bytes must be in the ASCII character set.
1355
1356         Commands from the client to the server are as follows:
1357
1358         <itemizedlist>
1359           <listitem><para>AUTH [mechanism] [initial-response]</para></listitem>
1360           <listitem><para>CANCEL</para></listitem>
1361           <listitem><para>BEGIN</para></listitem>
1362           <listitem><para>DATA &lt;data in hex encoding&gt;</para></listitem>
1363           <listitem><para>ERROR [human-readable error explanation]</para></listitem>
1364         </itemizedlist>
1365
1366         From server to client are as follows:
1367
1368         <itemizedlist>
1369           <listitem><para>REJECTED &lt;space-separated list of mechanism names&gt;</para></listitem>
1370           <listitem><para>OK &lt;GUID in hex&gt;</para></listitem>
1371           <listitem><para>DATA &lt;data in hex encoding&gt;</para></listitem>
1372           <listitem><para>ERROR</para></listitem>
1373         </itemizedlist>
1374       </para>
1375       <para>
1376         Unofficial extensions to the command set must begin with the letters
1377         "EXTENSION_", to avoid conflicts with future official commands.
1378         For example, "EXTENSION_COM_MYDOMAIN_DO_STUFF".
1379       </para>
1380     </sect2>
1381     <sect2 id="auth-nul-byte">
1382       <title>Special credentials-passing nul byte</title>
1383       <para>
1384         Immediately after connecting to the server, the client must send a
1385         single nul byte. This byte may be accompanied by credentials
1386         information on some operating systems that use sendmsg() with
1387         SCM_CREDS or SCM_CREDENTIALS to pass credentials over UNIX domain
1388         sockets. However, the nul byte must be sent even on other kinds of
1389         socket, and even on operating systems that do not require a byte to be
1390         sent in order to transmit credentials. The text protocol described in
1391         this document begins after the single nul byte. If the first byte
1392         received from the client is not a nul byte, the server may disconnect
1393         that client.
1394       </para>
1395       <para>
1396         A nul byte in any context other than the initial byte is an error;
1397         the protocol is ASCII-only.
1398       </para>
1399       <para>
1400         The credentials sent along with the nul byte may be used with the
1401         SASL mechanism EXTERNAL.
1402       </para>
1403     </sect2>
1404     <sect2 id="auth-command-auth">
1405       <title>AUTH command</title>
1406       <para>
1407         If an AUTH command has no arguments, it is a request to list
1408         available mechanisms. The server must respond with a REJECTED
1409         command listing the mechanisms it understands, or with an error.
1410       </para>
1411       <para>
1412         If an AUTH command specifies a mechanism, and the server supports
1413         said mechanism, the server should begin exchanging SASL
1414         challenge-response data with the client using DATA commands.
1415       </para>
1416       <para>
1417         If the server does not support the mechanism given in the AUTH
1418         command, it must send either a REJECTED command listing the mechanisms
1419         it does support, or an error.
1420       </para>
1421       <para>
1422         If the [initial-response] argument is provided, it is intended for use
1423         with mechanisms that have no initial challenge (or an empty initial
1424         challenge), as if it were the argument to an initial DATA command. If
1425         the selected mechanism has an initial challenge and [initial-response]
1426         was provided, the server should reject authentication by sending
1427         REJECTED.
1428       </para>
1429       <para>
1430         If authentication succeeds after exchanging DATA commands,
1431         an OK command must be sent to the client.
1432       </para>
1433       <para>
1434         The first octet received by the client after the \r\n of the OK
1435         command must be the first octet of the authenticated/encrypted
1436         stream of D-Bus messages.
1437       </para>
1438       <para>
1439         The first octet received by the server after the \r\n of the BEGIN
1440         command from the client must be the first octet of the
1441         authenticated/encrypted stream of D-Bus messages.
1442       </para>
1443     </sect2>
1444     <sect2 id="auth-command-cancel">
1445       <title>CANCEL Command</title>
1446       <para>
1447         At any time up to sending the BEGIN command, the client may send a
1448         CANCEL command. On receiving the CANCEL command, the server must
1449         send a REJECTED command and abort the current authentication
1450         exchange.
1451       </para>
1452     </sect2>
1453     <sect2 id="auth-command-data">
1454       <title>DATA Command</title>
1455       <para>
1456         The DATA command may come from either client or server, and simply
1457         contains a hex-encoded block of data to be interpreted
1458         according to the SASL mechanism in use.
1459       </para>
1460       <para>
1461         Some SASL mechanisms support sending an "empty string";
1462         FIXME we need some way to do this.
1463       </para>
1464     </sect2>
1465     <sect2 id="auth-command-begin">
1466       <title>BEGIN Command</title>
1467       <para>
1468         The BEGIN command acknowledges that the client has received an
1469         OK command from the server, and that the stream of messages
1470         is about to begin.
1471       </para>
1472       <para>
1473         The first octet received by the server after the \r\n of the BEGIN
1474         command from the client must be the first octet of the
1475         authenticated/encrypted stream of D-Bus messages.
1476       </para>
1477     </sect2>
1478     <sect2 id="auth-command-rejected">
1479       <title>REJECTED Command</title>
1480       <para>
1481         The REJECTED command indicates that the current authentication
1482         exchange has failed, and further exchange of DATA is inappropriate.
1483         The client would normally try another mechanism, or try providing
1484         different responses to challenges.
1485       </para><para>
1486         Optionally, the REJECTED command has a space-separated list of
1487         available auth mechanisms as arguments. If a server ever provides
1488         a list of supported mechanisms, it must provide the same list
1489         each time it sends a REJECTED message. Clients are free to
1490         ignore all lists received after the first.
1491       </para>
1492     </sect2>
1493     <sect2 id="auth-command-ok">
1494       <title>OK Command</title>
1495       <para>
1496         The OK command indicates that the client has been authenticated,
1497         and that further communication will be a stream of D-Bus messages
1498         (optionally encrypted, as negotiated) rather than this protocol.
1499       </para>
1500       <para>
1501         The first octet received by the client after the \r\n of the OK
1502         command must be the first octet of the authenticated/encrypted
1503         stream of D-Bus messages.
1504       </para>
1505       <para>
1506         The client must respond to the OK command by sending a BEGIN
1507         command, followed by its stream of messages, or by disconnecting.
1508         The server must not accept additional commands using this protocol
1509         after the OK command has been sent.
1510       </para>
1511       <para>
1512         The OK command has one argument, which is the GUID of the server.
1513         See <xref linkend="addresses"/> for more on server GUIDs.
1514       </para>
1515     </sect2>
1516     <sect2 id="auth-command-error">
1517       <title>ERROR Command</title>
1518       <para>
1519         The ERROR command indicates that either server or client did not
1520         know a command, does not accept the given command in the current
1521         context, or did not understand the arguments to the command. This
1522         allows the protocol to be extended; a client or server can send a
1523         command present or permitted only in new protocol versions, and if
1524         an ERROR is received instead of an appropriate response, fall back
1525         to using some other technique.
1526       </para>
1527       <para>
1528         If an ERROR is sent, the server or client that sent the
1529         error must continue as if the command causing the ERROR had never been
1530         received. However, the the server or client receiving the error
1531         should try something other than whatever caused the error;
1532         if only canceling/rejecting the authentication.
1533       </para>
1534       <para>
1535         If the D-Bus protocol changes incompatibly at some future time,
1536         applications implementing the new protocol would probably be able to
1537         check for support of the new protocol by sending a new command and
1538         receiving an ERROR from applications that don't understand it. Thus the
1539         ERROR feature of the auth protocol is an escape hatch that lets us
1540         negotiate extensions or changes to the D-Bus protocol in the future.
1541       </para>
1542     </sect2>
1543     <sect2 id="auth-examples">
1544       <title>Authentication examples</title>
1545
1546       <para>
1547         <figure>
1548           <title>Example of successful magic cookie authentication</title>
1549           <programlisting>
1550             (MAGIC_COOKIE is a made up mechanism)
1551
1552             C: AUTH MAGIC_COOKIE 3138363935333137393635383634
1553             S: OK 1234deadbeef
1554             C: BEGIN
1555           </programlisting>
1556         </figure>
1557         <figure>
1558           <title>Example of finding out mechanisms then picking one</title>
1559           <programlisting>
1560             C: AUTH
1561             S: REJECTED KERBEROS_V4 SKEY
1562             C: AUTH SKEY 7ab83f32ee
1563             S: DATA 8799cabb2ea93e
1564             C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
1565             S: OK 1234deadbeef
1566             C: BEGIN
1567           </programlisting>
1568         </figure>
1569         <figure>
1570           <title>Example of client sends unknown command then falls back to regular auth</title>
1571           <programlisting>
1572             C: FOOBAR
1573             S: ERROR
1574             C: AUTH MAGIC_COOKIE 3736343435313230333039
1575             S: OK 1234deadbeef
1576             C: BEGIN
1577           </programlisting>
1578         </figure>
1579         <figure>
1580           <title>Example of server doesn't support initial auth mechanism</title>
1581           <programlisting>
1582             C: AUTH MAGIC_COOKIE 3736343435313230333039
1583             S: REJECTED KERBEROS_V4 SKEY
1584             C: AUTH SKEY 7ab83f32ee
1585             S: DATA 8799cabb2ea93e
1586             C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
1587             S: OK 1234deadbeef
1588             C: BEGIN
1589           </programlisting>
1590         </figure>
1591         <figure>
1592           <title>Example of wrong password or the like followed by successful retry</title>
1593           <programlisting>
1594             C: AUTH MAGIC_COOKIE 3736343435313230333039
1595             S: REJECTED KERBEROS_V4 SKEY
1596             C: AUTH SKEY 7ab83f32ee
1597             S: DATA 8799cabb2ea93e
1598             C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
1599             S: REJECTED
1600             C: AUTH SKEY 7ab83f32ee
1601             S: DATA 8799cabb2ea93e
1602             C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
1603             S: OK 1234deadbeef
1604             C: BEGIN
1605           </programlisting>
1606         </figure>
1607         <figure>
1608           <title>Example of skey cancelled and restarted</title>
1609           <programlisting>
1610             C: AUTH MAGIC_COOKIE 3736343435313230333039
1611             S: REJECTED KERBEROS_V4 SKEY
1612             C: AUTH SKEY 7ab83f32ee
1613             S: DATA 8799cabb2ea93e
1614             C: CANCEL
1615             S: REJECTED
1616             C: AUTH SKEY 7ab83f32ee
1617             S: DATA 8799cabb2ea93e
1618             C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
1619             S: OK 1234deadbeef
1620             C: BEGIN
1621           </programlisting>
1622         </figure>
1623       </para>
1624     </sect2>
1625     <sect2 id="auth-states">
1626       <title>Authentication state diagrams</title>
1627
1628       <para>
1629         This section documents the auth protocol in terms of
1630         a state machine for the client and the server. This is
1631         probably the most robust way to implement the protocol.
1632       </para>
1633
1634       <sect3 id="auth-states-client">
1635         <title>Client states</title>
1636
1637         <para>
1638           To more precisely describe the interaction between the
1639           protocol state machine and the authentication mechanisms the
1640           following notation is used: MECH(CHALL) means that the
1641           server challenge CHALL was fed to the mechanism MECH, which
1642           returns one of
1643
1644           <itemizedlist>
1645             <listitem>
1646               <para>
1647                 CONTINUE(RESP) means continue the auth conversation
1648                 and send RESP as the response to the server;
1649               </para>
1650             </listitem>
1651
1652             <listitem>
1653               <para>
1654                 OK(RESP) means that after sending RESP to the server
1655                 the client side of the auth conversation is finished
1656                 and the server should return "OK";
1657               </para>
1658             </listitem>
1659
1660             <listitem>
1661               <para>
1662                 ERROR means that CHALL was invalid and could not be
1663                 processed.
1664               </para>
1665             </listitem>
1666           </itemizedlist>
1667
1668           Both RESP and CHALL may be empty.
1669         </para>
1670
1671         <para>
1672           The Client starts by getting an initial response from the
1673           default mechanism and sends AUTH MECH RESP, or AUTH MECH if
1674           the mechanism did not provide an initial response.  If the
1675           mechanism returns CONTINUE, the client starts in state
1676           <emphasis>WaitingForData</emphasis>, if the mechanism
1677           returns OK the client starts in state
1678           <emphasis>WaitingForOK</emphasis>.
1679         </para>
1680
1681         <para>
1682           The client should keep track of available mechanisms and
1683           which it mechanisms it has already attempted. This list is
1684           used to decide which AUTH command to send. When the list is
1685           exhausted, the client should give up and close the
1686           connection.
1687         </para>
1688
1689         <formalpara>
1690           <title><emphasis>WaitingForData</emphasis></title>
1691           <para>
1692             <itemizedlist>
1693               <listitem>
1694                 <para>
1695                   Receive DATA CHALL
1696                   <simplelist>
1697                     <member>
1698                       MECH(CHALL) returns CONTINUE(RESP) &rarr; send
1699                       DATA RESP, goto
1700                       <emphasis>WaitingForData</emphasis>
1701                     </member>
1702
1703                     <member>
1704                       MECH(CHALL) returns OK(RESP) &rarr; send DATA
1705                       RESP, goto <emphasis>WaitingForOK</emphasis>
1706                     </member>
1707
1708                     <member>
1709                       MECH(CHALL) returns ERROR &rarr; send ERROR
1710                       [msg], goto <emphasis>WaitingForData</emphasis>
1711                     </member>
1712                   </simplelist>
1713                 </para>
1714               </listitem>
1715
1716               <listitem>
1717                 <para>
1718                   Receive REJECTED [mechs] &rarr;
1719                   send AUTH [next mech], goto
1720                   WaitingForData or <emphasis>WaitingForOK</emphasis>
1721                 </para>
1722               </listitem>
1723               <listitem>
1724                 <para>
1725                   Receive ERROR &rarr; send
1726                   CANCEL, goto
1727                   <emphasis>WaitingForReject</emphasis>
1728                 </para>
1729               </listitem>
1730               <listitem>
1731                 <para>
1732                   Receive OK &rarr; send
1733                   BEGIN, terminate auth
1734                   conversation, authenticated
1735                 </para>
1736               </listitem>
1737               <listitem>
1738                 <para>
1739                   Receive anything else &rarr; send
1740                   ERROR, goto
1741                   <emphasis>WaitingForData</emphasis>
1742                 </para>
1743               </listitem>
1744             </itemizedlist>
1745           </para>
1746         </formalpara>
1747
1748         <formalpara>
1749           <title><emphasis>WaitingForOK</emphasis></title>
1750           <para>
1751             <itemizedlist>
1752               <listitem>
1753                 <para>
1754                   Receive OK &rarr; send BEGIN, terminate auth
1755                   conversation, <emphasis>authenticated</emphasis>
1756                 </para>
1757               </listitem>
1758               <listitem>
1759                 <para>
1760                   Receive REJECT [mechs] &rarr; send AUTH [next mech],
1761                   goto <emphasis>WaitingForData</emphasis> or
1762                   <emphasis>WaitingForOK</emphasis>
1763                 </para>
1764               </listitem>
1765
1766               <listitem>
1767                 <para>
1768                   Receive DATA &rarr; send CANCEL, goto
1769                   <emphasis>WaitingForReject</emphasis>
1770                 </para>
1771               </listitem>
1772
1773               <listitem>
1774                 <para>
1775                   Receive ERROR &rarr; send CANCEL, goto
1776                   <emphasis>WaitingForReject</emphasis>
1777                 </para>
1778               </listitem>
1779
1780               <listitem>
1781                 <para>
1782                   Receive anything else &rarr; send ERROR, goto
1783                   <emphasis>WaitingForOK</emphasis>
1784                 </para>
1785               </listitem>
1786             </itemizedlist>
1787           </para>
1788         </formalpara>
1789
1790         <formalpara>
1791           <title><emphasis>WaitingForReject</emphasis></title>
1792           <para>
1793             <itemizedlist>
1794               <listitem>
1795                 <para>
1796                   Receive REJECT [mechs] &rarr; send AUTH [next mech],
1797                   goto <emphasis>WaitingForData</emphasis> or
1798                   <emphasis>WaitingForOK</emphasis>
1799                 </para>
1800               </listitem>
1801
1802               <listitem>
1803                 <para>
1804                   Receive anything else &rarr; terminate auth
1805                   conversation, disconnect
1806                 </para>
1807               </listitem>
1808             </itemizedlist>
1809           </para>
1810         </formalpara>
1811
1812       </sect3>
1813
1814       <sect3 id="auth-states-server">
1815         <title>Server states</title>
1816
1817         <para>
1818           For the server MECH(RESP) means that the client response
1819           RESP was fed to the the mechanism MECH, which returns one of
1820
1821           <itemizedlist>
1822             <listitem>
1823               <para>
1824                 CONTINUE(CHALL) means continue the auth conversation and
1825                 send CHALL as the challenge to the client;
1826               </para>
1827             </listitem>
1828
1829             <listitem>
1830               <para>
1831                 OK means that the client has been successfully
1832                 authenticated;
1833               </para>
1834             </listitem>
1835
1836             <listitem>
1837               <para>
1838                 REJECT means that the client failed to authenticate or
1839                 there was an error in RESP.
1840               </para>
1841             </listitem>
1842           </itemizedlist>
1843
1844           The server starts out in state
1845           <emphasis>WaitingForAuth</emphasis>.  If the client is
1846           rejected too many times the server must disconnect the
1847           client.
1848         </para>
1849
1850         <formalpara>
1851           <title><emphasis>WaitingForAuth</emphasis></title>
1852           <para>
1853             <itemizedlist>
1854
1855               <listitem>
1856                 <para>
1857                   Receive AUTH &rarr; send REJECTED [mechs], goto
1858                   <emphasis>WaitingForAuth</emphasis>
1859                 </para>
1860               </listitem>
1861
1862               <listitem>
1863                 <para>
1864                   Receive AUTH MECH RESP
1865
1866                   <simplelist>
1867                     <member>
1868                       MECH not valid mechanism &rarr; send REJECTED
1869                       [mechs], goto
1870                       <emphasis>WaitingForAuth</emphasis>
1871                     </member>
1872
1873                     <member>
1874                       MECH(RESP) returns CONTINUE(CHALL) &rarr; send
1875                       DATA CHALL, goto
1876                       <emphasis>WaitingForData</emphasis>
1877                     </member>
1878
1879                     <member>
1880                       MECH(RESP) returns OK &rarr; send OK, goto
1881                       <emphasis>WaitingForBegin</emphasis>
1882                     </member>
1883
1884                     <member>
1885                       MECH(RESP) returns REJECT &rarr; send REJECTED
1886                       [mechs], goto
1887                       <emphasis>WaitingForAuth</emphasis>
1888                     </member>
1889                   </simplelist>
1890                 </para>
1891               </listitem>
1892
1893               <listitem>
1894                 <para>
1895                   Receive BEGIN &rarr; terminate
1896                   auth conversation, disconnect
1897                 </para>
1898               </listitem>
1899
1900               <listitem>
1901                 <para>
1902                   Receive ERROR &rarr; send REJECTED [mechs], goto
1903                   <emphasis>WaitingForAuth</emphasis>
1904                 </para>
1905               </listitem>
1906
1907               <listitem>
1908                 <para>
1909                   Receive anything else &rarr; send
1910                   ERROR, goto
1911                   <emphasis>WaitingForAuth</emphasis>
1912                 </para>
1913               </listitem>
1914             </itemizedlist>
1915           </para>
1916         </formalpara>
1917
1918
1919         <formalpara>
1920           <title><emphasis>WaitingForData</emphasis></title>
1921           <para>
1922             <itemizedlist>
1923               <listitem>
1924                 <para>
1925                   Receive DATA RESP
1926                   <simplelist>
1927                     <member>
1928                       MECH(RESP) returns CONTINUE(CHALL) &rarr; send
1929                       DATA CHALL, goto
1930                       <emphasis>WaitingForData</emphasis>
1931                     </member>
1932
1933                     <member>
1934                       MECH(RESP) returns OK &rarr; send OK, goto
1935                       <emphasis>WaitingForBegin</emphasis>
1936                     </member>
1937
1938                     <member>
1939                       MECH(RESP) returns REJECT &rarr; send REJECTED
1940                       [mechs], goto
1941                       <emphasis>WaitingForAuth</emphasis>
1942                     </member>
1943                   </simplelist>
1944                 </para>
1945               </listitem>
1946
1947               <listitem>
1948                 <para>
1949                   Receive BEGIN &rarr; terminate auth conversation,
1950                   disconnect
1951                 </para>
1952               </listitem>
1953
1954               <listitem>
1955                 <para>
1956                   Receive CANCEL &rarr; send REJECTED [mechs], goto
1957                   <emphasis>WaitingForAuth</emphasis>
1958                 </para>
1959               </listitem>
1960
1961               <listitem>
1962                 <para>
1963                   Receive ERROR &rarr; send REJECTED [mechs], goto
1964                   <emphasis>WaitingForAuth</emphasis>
1965                 </para>
1966               </listitem>
1967
1968               <listitem>
1969                 <para>
1970                   Receive anything else &rarr; send ERROR, goto
1971                   <emphasis>WaitingForData</emphasis>
1972                 </para>
1973               </listitem>
1974             </itemizedlist>
1975           </para>
1976         </formalpara>
1977
1978         <formalpara>
1979           <title><emphasis>WaitingForBegin</emphasis></title>
1980           <para>
1981             <itemizedlist>
1982               <listitem>
1983                 <para>
1984                   Receive BEGIN &rarr; terminate auth conversation,
1985                   client authenticated
1986                 </para>
1987               </listitem>
1988
1989               <listitem>
1990                 <para>
1991                   Receive CANCEL &rarr; send REJECTED [mechs], goto
1992                   <emphasis>WaitingForAuth</emphasis>
1993                 </para>
1994               </listitem>
1995
1996               <listitem>
1997                 <para>
1998                   Receive ERROR &rarr; send REJECTED [mechs], goto
1999                   <emphasis>WaitingForAuth</emphasis>
2000                 </para>
2001               </listitem>
2002
2003               <listitem>
2004                 <para>
2005                   Receive anything else &rarr; send ERROR, goto
2006                   <emphasis>WaitingForBegin</emphasis>
2007                 </para>
2008               </listitem>
2009             </itemizedlist>
2010           </para>
2011         </formalpara>
2012
2013       </sect3>
2014
2015     </sect2>
2016     <sect2 id="auth-mechanisms">
2017       <title>Authentication mechanisms</title>
2018       <para>
2019         This section describes some new authentication mechanisms.
2020         D-Bus also allows any standard SASL mechanism of course.
2021       </para>
2022       <sect3 id="auth-mechanisms-sha">
2023         <title>DBUS_COOKIE_SHA1</title>
2024         <para>
2025           The DBUS_COOKIE_SHA1 mechanism is designed to establish that a client
2026           has the ability to read a private file owned by the user being
2027           authenticated. If the client can prove that it has access to a secret
2028           cookie stored in this file, then the client is authenticated.
2029           Thus the security of DBUS_COOKIE_SHA1 depends on a secure home
2030           directory.
2031         </para>
2032         <para>
2033           Authentication proceeds as follows:
2034           <itemizedlist>
2035             <listitem>
2036               <para>
2037                 The client sends the username it would like to authenticate
2038                 as.
2039               </para>
2040             </listitem>
2041             <listitem>
2042               <para>
2043                 The server sends the name of its "cookie context" (see below); a
2044                 space character; the integer ID of the secret cookie the client
2045                 must demonstrate knowledge of; a space character; then a
2046                 hex-encoded randomly-generated challenge string.
2047               </para>
2048             </listitem>
2049             <listitem>
2050               <para>
2051                 The client locates the cookie, and generates its own hex-encoded
2052                 randomly-generated challenge string.  The client then
2053                 concatenates the server's hex-encoded challenge, a ":"
2054                 character, its own hex-encoded challenge, another ":" character,
2055                 and the hex-encoded cookie.  It computes the SHA-1 hash of this
2056                 composite string.  It sends back to the server the client's
2057                 hex-encoded challenge string, a space character, and the SHA-1
2058                 hash.
2059               </para>
2060             </listitem>
2061             <listitem>
2062               <para>
2063                 The server generates the same concatenated string used by the
2064                 client and computes its SHA-1 hash. It compares the hash with
2065                 the hash received from the client; if the two hashes match, the
2066                 client is authenticated.
2067               </para>
2068             </listitem>
2069           </itemizedlist>
2070         </para>
2071         <para>
2072           Each server has a "cookie context," which is a name that identifies a
2073           set of cookies that apply to that server. A sample context might be
2074           "org_freedesktop_session_bus". Context names must be valid ASCII,
2075           nonzero length, and may not contain the characters slash ("/"),
2076           backslash ("\"), space (" "), newline ("\n"), carriage return ("\r"),
2077           tab ("\t"), or period ("."). There is a default context,
2078           "org_freedesktop_general" that's used by servers that do not specify
2079           otherwise.
2080         </para>
2081         <para>
2082           Cookies are stored in a user's home directory, in the directory
2083           <filename>~/.dbus-keyrings/</filename>. This directory must
2084           not be readable or writable by other users. If it is,
2085           clients and servers must ignore it. The directory
2086           contains cookie files named after the cookie context.
2087         </para>
2088         <para>
2089           A cookie file contains one cookie per line. Each line
2090           has three space-separated fields:
2091           <itemizedlist>
2092             <listitem>
2093               <para>
2094                 The cookie ID number, which must be a non-negative integer and
2095                 may not be used twice in the same file.
2096               </para>
2097             </listitem>
2098             <listitem>
2099               <para>
2100                 The cookie's creation time, in UNIX seconds-since-the-epoch
2101                 format.
2102               </para>
2103             </listitem>
2104             <listitem>
2105               <para>
2106                 The cookie itself, a hex-encoded random block of bytes. The cookie
2107                 may be of any length, though obviously security increases
2108                 as the length increases.
2109               </para>
2110             </listitem>
2111           </itemizedlist>
2112         </para>
2113         <para>
2114           Only server processes modify the cookie file.
2115           They must do so with this procedure:
2116           <itemizedlist>
2117             <listitem>
2118               <para>
2119                 Create a lockfile name by appending ".lock" to the name of the
2120                 cookie file.  The server should attempt to create this file
2121                 using <literal>O_CREAT | O_EXCL</literal>.  If file creation
2122                 fails, the lock fails. Servers should retry for a reasonable
2123                 period of time, then they may choose to delete an existing lock
2124                 to keep users from having to manually delete a stale
2125                 lock. <footnote><para>Lockfiles are used instead of real file
2126                 locking <literal>fcntl()</literal> because real locking
2127                 implementations are still flaky on network
2128                 filesystems.</para></footnote>
2129               </para>
2130             </listitem>
2131             <listitem>
2132               <para>
2133                 Once the lockfile has been created, the server loads the cookie
2134                 file. It should then delete any cookies that are old (the
2135                 timeout can be fairly short), or more than a reasonable
2136                 time in the future (so that cookies never accidentally
2137                 become permanent, if the clock was set far into the future
2138                 at some point). If no recent keys remain, the
2139                 server may generate a new key.
2140               </para>
2141             </listitem>
2142             <listitem>
2143               <para>
2144                 The pruned and possibly added-to cookie file
2145                 must be resaved atomically (using a temporary
2146                 file which is rename()'d).
2147               </para>
2148             </listitem>
2149             <listitem>
2150               <para>
2151                 The lock must be dropped by deleting the lockfile.
2152               </para>
2153             </listitem>
2154           </itemizedlist>
2155         </para>
2156         <para>
2157           Clients need not lock the file in order to load it,
2158           because servers are required to save the file atomically.
2159         </para>
2160       </sect3>
2161     </sect2>
2162   </sect1>
2163   <sect1 id="addresses">
2164     <title>Server Addresses</title>
2165     <para>
2166       Server addresses consist of a transport name followed by a colon, and
2167       then an optional, comma-separated list of keys and values in the form key=value.
2168       Each value is escaped.
2169     </para>
2170     <para>
2171       For example:
2172       <programlisting>unix:path=/tmp/dbus-test</programlisting>
2173       Which is the address to a unix socket with the path /tmp/dbus-test.
2174     </para>
2175     <para>
2176       Value escaping is similar to URI escaping but simpler.
2177       <itemizedlist>
2178         <listitem>
2179           <para>
2180             The set of optionally-escaped bytes is:
2181             <literal>[0-9A-Za-z_-/.\]</literal>. To escape, each
2182             <emphasis>byte</emphasis> (note, not character) which is not in the
2183             set of optionally-escaped bytes must be replaced with an ASCII
2184             percent (<literal>%</literal>) and the value of the byte in hex.
2185             The hex value must always be two digits, even if the first digit is
2186             zero. The optionally-escaped bytes may be escaped if desired.
2187           </para>
2188         </listitem>
2189         <listitem>
2190           <para>
2191             To unescape, append each byte in the value; if a byte is an ASCII
2192             percent (<literal>%</literal>) character then append the following
2193             hex value instead. It is an error if a <literal>%</literal> byte
2194             does not have two hex digits following. It is an error if a
2195             non-optionally-escaped byte is seen unescaped.
2196           </para>
2197         </listitem>
2198       </itemizedlist>
2199       The set of optionally-escaped bytes is intended to preserve address
2200       readability and convenience.
2201     </para>
2202
2203     <para>
2204       A server may specify a key-value pair with the key <literal>guid</literal>
2205       and the value a hex-encoded 16-byte sequence. This globally unique ID must
2206       be created by filling the first 4 bytes with a 32-bit UNIX time since the
2207       epoch, and the remaining 12 bytes with random bytes. If present, the GUID
2208       may be used to distinguish one server from another. A server should use a
2209       different GUID for each address it listens on. For example, if a message
2210       bus daemon offers both UNIX domain socket and TCP connections, but treats
2211       clients the same regardless of how they connect, those two connections are
2212       equivalent post-connection but should have distinct GUIDs to distinguish
2213       the kinds of connection.
2214     </para>
2215
2216     <para>
2217       The intent of the GUID feature is to allow a client to avoid opening
2218       multiple identical connections to the same server, by allowing the client
2219       to check whether an address corresponds to an already-existing connection.
2220       Comparing two addresses is insufficient, because addresses can be recycled
2221       by distinct servers.
2222     </para>
2223
2224     <para>
2225       [FIXME clarify if attempting to connect to each is a requirement
2226       or just a suggestion]
2227       When connecting to a server, multiple server addresses can be
2228       separated by a semi-colon. The library will then try to connect
2229       to the first address and if that fails, it'll try to connect to
2230       the next one specified, and so forth. For example
2231       <programlisting>unix:path=/tmp/dbus-test;unix:path=/tmp/dbus-test2</programlisting>
2232     </para>
2233
2234   </sect1>
2235
2236   <sect1 id="transports">
2237     <title>Transports</title>
2238     <para>
2239       [FIXME we need to specify in detail each transport and its possible arguments]
2240
2241       Current transports include: unix domain sockets (including
2242       abstract namespace on linux), TCP/IP, and a debug/testing transport using
2243       in-process pipes. Future possible transports include one that
2244       tunnels over X11 protocol.
2245     </para>
2246
2247     <sect2 id="transports-unix-domain-sockets">
2248       <title>Unix Domain Sockets</title>
2249       <para>
2250         Unix domain sockets can be either paths in the file system or on Linux
2251         kernels, they can be abstract which are similar to paths but
2252         do not show up in the file system.
2253       </para>
2254
2255       <para>
2256         When a socket is opened by the D-Bus library it truncates the path
2257         name right before the first trailing Nul byte.  This is true for both
2258         normal paths and abstract paths.  Note that this is a departure from
2259         previous versions of D-Bus that would create sockets with a fixed
2260         length path name.  Names which were shorter than the fixed length
2261         would be padded by Nul bytes.
2262       </para>
2263     </sect2>
2264   </sect1>
2265
2266   <sect1 id="naming-conventions">
2267     <title>Naming Conventions</title>
2268
2269     <para>
2270       D-Bus namespaces are all lowercase and correspond to reversed domain
2271       names, as with Java. e.g. "org.freedesktop"
2272     </para>
2273     <para>
2274       Interface, signal, method, and property names are "WindowsStyleCaps", note
2275       that the first letter is capitalized, unlike Java.
2276     </para>
2277     <para>
2278       Object paths are normally all lowercase with underscores used rather than
2279       hyphens.
2280     </para>
2281   </sect1>
2282
2283   <sect1 id="standard-interfaces">
2284     <title>Standard Interfaces</title>
2285     <para>
2286       See <xref linkend="message-protocol-types-notation"/> for details on
2287        the notation used in this section. There are some standard interfaces
2288       that may be useful across various D-Bus applications.
2289     </para>
2290     <sect2 id="standard-interfaces-peer">
2291       <title><literal>org.freedesktop.DBus.Peer</literal></title>
2292       <para>
2293         The <literal>org.freedesktop.DBus.Peer</literal> interface
2294         has two methods:
2295         <programlisting>
2296           org.freedesktop.DBus.Peer.Ping ()
2297           org.freedesktop.DBus.Peer.GetMachineId (out STRING machine_uuid)
2298         </programlisting>
2299       </para>
2300       <para>
2301         On receipt of the <literal>METHOD_CALL</literal> message
2302         <literal>org.freedesktop.DBus.Peer.Ping</literal>, an application should do
2303         nothing other than reply with a <literal>METHOD_RETURN</literal> as
2304         usual.  It does not matter which object path a ping is sent to.  The
2305         reference implementation handles this method automatically.
2306       </para>
2307       <para>
2308         On receipt of the <literal>METHOD_CALL</literal> message
2309         <literal>org.freedesktop.DBus.Peer.GetMachineId</literal>, an application should
2310         reply with a <literal>METHOD_RETURN</literal> containing a hex-encoded
2311         UUID representing the identity of the machine the process is running on.
2312         This UUID must be the same for all processes on a single system at least
2313         until that system next reboots. It should be the same across reboots
2314         if possible, but may change due to reconfiguration or hardware changes.
2315         It does not matter which object path a GetMachineId is sent to.  The
2316         reference implementation handles this method automatically.
2317       </para>
2318       <para>
2319         The UUID must contain 128 bits of data and be hex-encoded (meaning, the hex
2320         string contains 32 ASCII characters). The hex-encoded string may not contain
2321         hyphens or other non-hex-digit characters, and it must be exactly 32 characters long.
2322         To generate a UUID, the recommended algorithm is to put the current time in seconds
2323         since the UNIX epoch in the last 32 bits of the UUID, and to put randomly-generated bits
2324         in the first 96 bits of the UUID.
2325       </para>
2326       <para>
2327         The UUID is intended to be per-instance-of-the-operating-system, so may represent
2328         a virtual machine running on a hypervisor, rather than a physical machine.
2329         Basically if two processes see the same UUID, they should also see the same
2330         shared memory, UNIX domain sockets, process IDs, and other features that require
2331         a running OS kernel in common between the processes.
2332       </para>
2333     </sect2>
2334
2335     <sect2 id="standard-interfaces-introspectable">
2336       <title><literal>org.freedesktop.DBus.Introspectable</literal></title>
2337       <para>
2338         This interface has one method:
2339         <programlisting>
2340           org.freedesktop.DBus.Introspectable.Introspect (out STRING xml_data)
2341         </programlisting>
2342       </para>
2343       <para>
2344         Objects instances may implement
2345         <literal>Introspect</literal> which returns an XML description of
2346         the object, including its interfaces (with signals and methods), objects
2347         below it in the object path tree, and its properties.
2348       </para>
2349       <para>
2350         <xref linkend="introspection-format"/> describes the format of this XML string.
2351       </para>
2352     </sect2>
2353     <sect2 id="standard-interfaces-properties">
2354       <title><literal>org.freedesktop.DBus.Properties</literal></title>
2355       <para>
2356         Many native APIs will have a concept of object <firstterm>properties</firstterm>
2357         or <firstterm>attributes</firstterm>. These can be exposed via the
2358         <literal>org.freedesktop.DBus.Properties</literal> interface.
2359       </para>
2360       <para>
2361         <programlisting>
2362               org.freedesktop.DBus.Properties.Get (in STRING interface_name,
2363                                                    in STRING property_name,
2364                                                    out VARIANT value);
2365               org.freedesktop.DBus.Properties.Set (in STRING interface_name,
2366                                                    in STRING property_name,
2367                                                    in VARIANT value);
2368         </programlisting>
2369       </para>
2370       <para>
2371         The available properties and whether they are writable can be determined
2372         by calling <literal>org.freedesktop.DBus.Introspectable.Introspect</literal>,
2373         see <xref linkend="standard-interfaces-introspectable"/>.
2374       </para>
2375       <para>
2376         An empty string may be provided for the interface name; in this case,
2377         if there are multiple properties on an object with the same name,
2378         the results are undefined (picking one by according to an arbitrary
2379         deterministic rule, or returning an error, are the reasonable
2380         possibilities).
2381       </para>
2382     </sect2>
2383   </sect1>
2384
2385   <sect1 id="introspection-format">
2386     <title>Introspection Data Format</title>
2387     <para>
2388       As described in <xref linkend="standard-interfaces-introspectable"/>,
2389       objects may be introspected at runtime, returning an XML string
2390       that describes the object. The same XML format may be used in
2391       other contexts as well, for example as an "IDL" for generating
2392       static language bindings.
2393     </para>
2394     <para>
2395       Here is an example of introspection data:
2396       <programlisting>
2397         &lt;!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
2398          "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"&gt;
2399         &lt;node name="/org/freedesktop/sample_object"&gt;
2400           &lt;interface name="org.freedesktop.SampleInterface"&gt;
2401             &lt;method name="Frobate"&gt;
2402               &lt;arg name="foo" type="i" direction="in"/&gt;
2403               &lt;arg name="bar" type="s" direction="out"/&gt;
2404               &lt;arg name="baz" type="a{us}" direction="out"/&gt;
2405               &lt;annotation name="org.freedesktop.DBus.Deprecated" value="true"/&gt;
2406             &lt;/method&gt;
2407             &lt;method name="Bazify"&gt;
2408               &lt;arg name="bar" type="(iiu)" direction="in"/&gt;
2409               &lt;arg name="bar" type="v" direction="out"/&gt;
2410             &lt;/method&gt;
2411             &lt;method name="Mogrify"&gt;
2412               &lt;arg name="bar" type="(iiav)" direction="in"/&gt;
2413             &lt;/method&gt;
2414             &lt;signal name="Changed"&gt;
2415               &lt;arg name="new_value" type="b"/&gt;
2416             &lt;/signal&gt;
2417             &lt;property name="Bar" type="y" access="readwrite"/&gt;
2418           &lt;/interface&gt;
2419           &lt;node name="child_of_sample_object"/&gt;
2420           &lt;node name="another_child_of_sample_object"/&gt;
2421        &lt;/node&gt;
2422       </programlisting>
2423     </para>
2424     <para>
2425       A more formal DTD and spec needs writing, but here are some quick notes.
2426       <itemizedlist>
2427         <listitem>
2428           <para>
2429             Only the root &lt;node&gt; element can omit the node name, as it's
2430             known to be the object that was introspected.  If the root
2431             &lt;node&gt; does have a name attribute, it must be an absolute
2432             object path. If child &lt;node&gt; have object paths, they must be
2433             relative.
2434           </para>
2435         </listitem>
2436         <listitem>
2437           <para>
2438             If a child &lt;node&gt; has any sub-elements, then they
2439             must represent a complete introspection of the child.
2440             If a child &lt;node&gt; is empty, then it may or may
2441             not have sub-elements; the child must be introspected
2442             in order to find out. The intent is that if an object
2443             knows that its children are "fast" to introspect
2444             it can go ahead and return their information, but
2445             otherwise it can omit it.
2446           </para>
2447         </listitem>
2448         <listitem>
2449           <para>
2450             The direction element on &lt;arg&gt; may be omitted,
2451             in which case it defaults to "in" for method calls
2452             and "out" for signals. Signals only allow "out"
2453             so while direction may be specified, it's pointless.
2454           </para>
2455         </listitem>
2456         <listitem>
2457           <para>
2458             The possible directions are "in" and "out",
2459             unlike CORBA there is no "inout"
2460           </para>
2461         </listitem>
2462         <listitem>
2463           <para>
2464             The possible property access flags are
2465             "readwrite", "read", and "write"
2466           </para>
2467         </listitem>
2468         <listitem>
2469           <para>
2470             Multiple interfaces can of course be listed for
2471             one &lt;node&gt;.
2472           </para>
2473         </listitem>
2474         <listitem>
2475           <para>
2476             The "name" attribute on arguments is optional.
2477           </para>
2478         </listitem>
2479       </itemizedlist>
2480     </para>
2481     <para>
2482         Method, interface, property, and signal elements may have
2483         "annotations", which are generic key/value pairs of metadata.
2484         They are similar conceptually to Java's annotations and C# attributes.
2485         Well-known annotations:
2486      </para>
2487      <informaltable>
2488        <tgroup cols="3">
2489          <thead>
2490            <row>
2491              <entry>Name</entry>
2492              <entry>Values (separated by ,)</entry>
2493              <entry>Description</entry>
2494            </row>
2495          </thead>
2496          <tbody>
2497            <row>
2498              <entry>org.freedesktop.DBus.Deprecated</entry>
2499              <entry>true,false</entry>
2500              <entry>Whether or not the entity is deprecated; defaults to false</entry>
2501            </row>
2502            <row>
2503              <entry>org.freedesktop.DBus.GLib.CSymbol</entry>
2504              <entry>(string)</entry>
2505              <entry>The C symbol; may be used for methods and interfaces</entry>
2506            </row>
2507            <row>
2508              <entry>org.freedesktop.DBus.Method.NoReply</entry>
2509              <entry>true,false</entry>
2510              <entry>If set, don't expect a reply to the method call; defaults to false.</entry>
2511            </row>
2512          </tbody>
2513        </tgroup>
2514      </informaltable>
2515   </sect1>
2516   <sect1 id="message-bus">
2517     <title>Message Bus Specification</title>
2518     <sect2 id="message-bus-overview">
2519       <title>Message Bus Overview</title>
2520       <para>
2521         The message bus accepts connections from one or more applications.
2522         Once connected, applications can exchange messages with other
2523         applications that are also connected to the bus.
2524       </para>
2525       <para>
2526         In order to route messages among connections, the message bus keeps a
2527         mapping from names to connections. Each connection has one
2528         unique-for-the-lifetime-of-the-bus name automatically assigned.
2529         Applications may request additional names for a connection. Additional
2530         names are usually "well-known names" such as
2531         "org.freedesktop.TextEditor". When a name is bound to a connection,
2532         that connection is said to <firstterm>own</firstterm> the name.
2533       </para>
2534       <para>
2535         The bus itself owns a special name, <literal>org.freedesktop.DBus</literal>.
2536         This name routes messages to the bus, allowing applications to make
2537         administrative requests. For example, applications can ask the bus
2538         to assign a name to a connection.
2539       </para>
2540       <para>
2541         Each name may have <firstterm>queued owners</firstterm>.  When an
2542         application requests a name for a connection and the name is already in
2543         use, the bus will optionally add the connection to a queue waiting for
2544         the name. If the current owner of the name disconnects or releases
2545         the name, the next connection in the queue will become the new owner.
2546       </para>
2547
2548       <para>
2549         This feature causes the right thing to happen if you start two text
2550         editors for example; the first one may request "org.freedesktop.TextEditor",
2551         and the second will be queued as a possible owner of that name. When
2552         the first exits, the second will take over.
2553       </para>
2554
2555       <para>
2556         Messages may have a <literal>DESTINATION</literal> field (see <xref
2557         linkend="message-protocol-header-fields"/>).  If the
2558         <literal>DESTINATION</literal> field is present, it specifies a message
2559         recipient by name. Method calls and replies normally specify this field.
2560       </para>
2561
2562       <para>
2563         Signals normally do not specify a destination; they are sent to all
2564         applications with <firstterm>message matching rules</firstterm> that
2565         match the message.
2566       </para>
2567
2568       <para>
2569         When the message bus receives a method call, if the
2570         <literal>DESTINATION</literal> field is absent, the call is taken to be
2571         a standard one-to-one message and interpreted by the message bus
2572         itself. For example, sending an
2573         <literal>org.freedesktop.DBus.Peer.Ping</literal> message with no
2574         <literal>DESTINATION</literal> will cause the message bus itself to
2575         reply to the ping immediately; the message bus will not make this
2576         message visible to other applications.
2577       </para>
2578
2579       <para>
2580         Continuing the <literal>org.freedesktop.DBus.Peer.Ping</literal> example, if
2581         the ping message were sent with a <literal>DESTINATION</literal> name of
2582         <literal>com.yoyodyne.Screensaver</literal>, then the ping would be
2583         forwarded, and the Yoyodyne Corporation screensaver application would be
2584         expected to reply to the ping.
2585       </para>
2586     </sect2>
2587
2588     <sect2 id="message-bus-names">
2589       <title>Message Bus Names</title>
2590       <para>
2591         Each connection has at least one name, assigned at connection time and
2592         returned in response to the
2593         <literal>org.freedesktop.DBus.Hello</literal> method call.  This
2594         automatically-assigned name is called the connection's <firstterm>unique
2595         name</firstterm>.  Unique names are never reused for two different
2596         connections to the same bus.
2597       </para>
2598       <para>
2599         Ownership of a unique name is a prerequisite for interaction with
2600         the message bus. It logically follows that the unique name is always
2601         the first name that an application comes to own, and the last
2602         one that it loses ownership of.
2603       </para>
2604       <para>
2605         Unique connection names must begin with the character ':' (ASCII colon
2606         character); bus names that are not unique names must not begin
2607         with this character. (The bus must reject any attempt by an application
2608         to manually request a name beginning with ':'.) This restriction
2609         categorically prevents "spoofing"; messages sent to a unique name
2610         will always go to the expected connection.
2611       </para>
2612       <para>
2613         When a connection is closed, all the names that it owns are deleted (or
2614         transferred to the next connection in the queue if any).
2615       </para>
2616       <para>
2617         A connection can request additional names to be associated with it using
2618         the <literal>org.freedesktop.DBus.RequestName</literal> message. <xref
2619         linkend="message-protocol-names-bus"/> describes the format of a valid
2620         name. These names can be released again using the
2621         <literal>org.freedesktop.DBus.ReleaseName</literal> message.
2622       </para>
2623
2624       <sect3 id="bus-messages-request-name">
2625         <title><literal>org.freedesktop.DBus.RequestName</literal></title>
2626         <para>
2627           As a method:
2628           <programlisting>
2629             UINT32 RequestName (in STRING name, in UINT32 flags)
2630           </programlisting>
2631           Message arguments:
2632           <informaltable>
2633             <tgroup cols="3">
2634               <thead>
2635                 <row>
2636                   <entry>Argument</entry>
2637                   <entry>Type</entry>
2638                   <entry>Description</entry>
2639                 </row>
2640               </thead>
2641               <tbody>
2642                 <row>
2643                   <entry>0</entry>
2644                   <entry>STRING</entry>
2645                   <entry>Name to request</entry>
2646                 </row>
2647                 <row>
2648                   <entry>1</entry>
2649                   <entry>UINT32</entry>
2650                   <entry>Flags</entry>
2651                 </row>
2652               </tbody>
2653             </tgroup>
2654           </informaltable>
2655           Reply arguments:
2656           <informaltable>
2657             <tgroup cols="3">
2658               <thead>
2659                 <row>
2660                   <entry>Argument</entry>
2661                   <entry>Type</entry>
2662                   <entry>Description</entry>
2663                 </row>
2664               </thead>
2665               <tbody>
2666                 <row>
2667                   <entry>0</entry>
2668                   <entry>UINT32</entry>
2669                   <entry>Return value</entry>
2670                 </row>
2671               </tbody>
2672             </tgroup>
2673           </informaltable>
2674         </para>
2675         <para>
2676           This method call should be sent to
2677           <literal>org.freedesktop.DBus</literal> and asks the message bus to
2678           assign the given name to the method caller. Each name maintains a
2679           queue of possible owners, where the head of the queue is the primary
2680           or current owner of the name. Each potential owner in the queue
2681           maintains the DBUS_NAME_FLAG_ALLOW_REPLACEMENT and
2682           DBUS_NAME_FLAG_DO_NOT_QUEUE settings from its latest RequestName
2683           call.  When RequestName is invoked the following occurs:
2684           <itemizedlist>
2685             <listitem>
2686               <para>
2687                 If the method caller is currently the primary owner of the name,
2688                 the DBUS_NAME_FLAG_ALLOW_REPLACEMENT and DBUS_NAME_FLAG_DO_NOT_QUEUE
2689                 values are updated with the values from the new RequestName call,
2690                 and nothing further happens.
2691               </para>
2692             </listitem>
2693
2694             <listitem>
2695               <para>
2696                 If the current primary owner (head of the queue) has
2697                 DBUS_NAME_FLAG_ALLOW_REPLACEMENT set, and the RequestName
2698                 invocation has the DBUS_NAME_FLAG_REPLACE_EXISTING flag, then
2699                 the caller of RequestName replaces the current primary owner at
2700                 the head of the queue and the current primary owner moves to the
2701                 second position in the queue. If the caller of RequestName was
2702                 in the queue previously its flags are updated with the values from
2703                 the new RequestName in addition to moving it to the head of the queue.
2704               </para>
2705             </listitem>
2706
2707             <listitem>
2708               <para>
2709                 If replacement is not possible, and the method caller is
2710                 currently in the queue but not the primary owner, its flags are
2711                 updated with the values from the new RequestName call.
2712               </para>
2713             </listitem>
2714
2715             <listitem>
2716               <para>
2717                 If replacement is not possible, and the method caller is
2718                 currently not in the queue, the method caller is appended to the
2719                 queue.
2720               </para>
2721             </listitem>
2722
2723             <listitem>
2724               <para>
2725                 If any connection in the queue has DBUS_NAME_FLAG_DO_NOT_QUEUE
2726                 set and is not the primary owner, it is removed from the
2727                 queue. This can apply to the previous primary owner (if it
2728                 was replaced) or the method caller (if it updated the
2729                 DBUS_NAME_FLAG_DO_NOT_QUEUE flag while still stuck in the
2730                 queue, or if it was just added to the queue with that flag set).
2731               </para>
2732             </listitem>
2733           </itemizedlist>
2734         </para>
2735         <para>
2736           Note that DBUS_NAME_FLAG_REPLACE_EXISTING results in "jumping the
2737           queue," even if another application already in the queue had specified
2738           DBUS_NAME_FLAG_REPLACE_EXISTING.  This comes up if a primary owner
2739           that does not allow replacement goes away, and the next primary owner
2740           does allow replacement. In this case, queued items that specified
2741           DBUS_NAME_FLAG_REPLACE_EXISTING <emphasis>do not</emphasis>
2742           automatically replace the new primary owner. In other words,
2743           DBUS_NAME_FLAG_REPLACE_EXISTING is not saved, it is only used at the
2744           time RequestName is called. This is deliberate to avoid an infinite loop
2745           anytime two applications are both DBUS_NAME_FLAG_ALLOW_REPLACEMENT
2746           and DBUS_NAME_FLAG_REPLACE_EXISTING.
2747         </para>
2748         <para>
2749           The flags argument contains any of the following values logically ORed
2750           together:
2751
2752           <informaltable>
2753             <tgroup cols="3">
2754               <thead>
2755                 <row>
2756                   <entry>Conventional Name</entry>
2757                   <entry>Value</entry>
2758                   <entry>Description</entry>
2759                 </row>
2760               </thead>
2761               <tbody>
2762                 <row>
2763                   <entry>DBUS_NAME_FLAG_ALLOW_REPLACEMENT</entry>
2764                   <entry>0x1</entry>
2765                   <entry>
2766
2767                     If an application A specifies this flag and succeeds in
2768                     becoming the owner of the name, and another application B
2769                     later calls RequestName with the
2770                     DBUS_NAME_FLAG_REPLACE_EXISTING flag, then application A
2771                     will lose ownership and receive a
2772                     <literal>org.freedesktop.DBus.NameLost</literal> signal, and
2773                     application B will become the new owner. If DBUS_NAME_FLAG_ALLOW_REPLACEMENT
2774                     is not specified by application A, or DBUS_NAME_FLAG_REPLACE_EXISTING
2775                     is not specified by application B, then application B will not replace
2776                     application A as the owner.
2777
2778                   </entry>
2779                 </row>
2780                 <row>
2781                   <entry>DBUS_NAME_FLAG_REPLACE_EXISTING</entry>
2782                   <entry>0x2</entry>
2783                   <entry>
2784
2785                     Try to replace the current owner if there is one. If this
2786                     flag is not set the application will only become the owner of
2787                     the name if there is no current owner. If this flag is set,
2788                     the application will replace the current owner if
2789                     the current owner specified DBUS_NAME_FLAG_ALLOW_REPLACEMENT.
2790
2791                   </entry>
2792                 </row>
2793                 <row>
2794                   <entry>DBUS_NAME_FLAG_DO_NOT_QUEUE</entry>
2795                   <entry>0x4</entry>
2796                   <entry>
2797
2798                     Without this flag, if an application requests a name that is
2799                     already owned, the application will be placed in a queue to
2800                     own the name when the current owner gives it up. If this
2801                     flag is given, the application will not be placed in the
2802                     queue, the request for the name will simply fail.  This flag
2803                     also affects behavior when an application is replaced as
2804                     name owner; by default the application moves back into the
2805                     waiting queue, unless this flag was provided when the application
2806                     became the name owner.
2807
2808                   </entry>
2809                 </row>
2810               </tbody>
2811             </tgroup>
2812           </informaltable>
2813
2814           The return code can be one of the following values:
2815
2816           <informaltable>
2817             <tgroup cols="3">
2818               <thead>
2819                 <row>
2820                   <entry>Conventional Name</entry>
2821                   <entry>Value</entry>
2822                   <entry>Description</entry>
2823                 </row>
2824               </thead>
2825               <tbody>
2826                 <row>
2827                   <entry>DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER</entry>
2828                   <entry>1</entry> <entry>The caller is now the primary owner of
2829                   the name, replacing any previous owner. Either the name had no
2830                   owner before, or the caller specified
2831                   DBUS_NAME_FLAG_REPLACE_EXISTING and the current owner specified
2832                   DBUS_NAME_FLAG_ALLOW_REPLACEMENT.</entry>
2833                 </row>
2834                 <row>
2835                   <entry>DBUS_REQUEST_NAME_REPLY_IN_QUEUE</entry>
2836                   <entry>2</entry>
2837
2838                   <entry>The name already had an owner,
2839                     DBUS_NAME_FLAG_DO_NOT_QUEUE was not specified, and either
2840                     the current owner did not specify
2841                     DBUS_NAME_FLAG_ALLOW_REPLACEMENT or the requesting
2842                     application did not specify DBUS_NAME_FLAG_REPLACE_EXISTING.
2843                     </entry>
2844                 </row>
2845                 <row>
2846                   <entry>DBUS_REQUEST_NAME_REPLY_EXISTS</entry> <entry>3</entry>
2847                   <entry>The name already has an owner,
2848                   DBUS_NAME_FLAG_DO_NOT_QUEUE was specified, and either
2849                   DBUS_NAME_FLAG_ALLOW_REPLACEMENT was not specified by the
2850                   current owner, or DBUS_NAME_FLAG_REPLACE_EXISTING was not
2851                   specified by the requesting application.</entry>
2852                 </row>
2853                 <row>
2854                   <entry>DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER</entry>
2855                   <entry>4</entry>
2856                   <entry>The application trying to request ownership of a name is already the owner of it.</entry>
2857                 </row>
2858               </tbody>
2859             </tgroup>
2860           </informaltable>
2861         </para>
2862        </sect3>
2863
2864        <sect3 id="bus-messages-release-name">
2865         <title><literal>org.freedesktop.DBus.ReleaseName</literal></title>
2866         <para>
2867           As a method:
2868           <programlisting>
2869             UINT32 ReleaseName (in STRING name)
2870           </programlisting>
2871           Message arguments:
2872           <informaltable>
2873             <tgroup cols="3">
2874               <thead>
2875                 <row>
2876                   <entry>Argument</entry>
2877                   <entry>Type</entry>
2878                   <entry>Description</entry>
2879                 </row>
2880               </thead>
2881               <tbody>
2882                 <row>
2883                   <entry>0</entry>
2884                   <entry>STRING</entry>
2885                   <entry>Name to release</entry>
2886                 </row>
2887               </tbody>
2888             </tgroup>
2889           </informaltable>
2890           Reply arguments:
2891           <informaltable>
2892             <tgroup cols="3">
2893               <thead>
2894                 <row>
2895                   <entry>Argument</entry>
2896                   <entry>Type</entry>
2897                   <entry>Description</entry>
2898                 </row>
2899               </thead>
2900               <tbody>
2901                 <row>
2902                   <entry>0</entry>
2903                   <entry>UINT32</entry>
2904                   <entry>Return value</entry>
2905                 </row>
2906               </tbody>
2907             </tgroup>
2908           </informaltable>
2909         </para>
2910         <para>
2911           This method call should be sent to
2912           <literal>org.freedesktop.DBus</literal> and asks the message bus to
2913           release the method caller's claim to the given name. If the caller is
2914           the primary owner, a new primary owner will be selected from the
2915           queue if any other owners are waiting. If the caller is waiting in
2916           the queue for the name, the caller will removed from the queue and
2917           will not be made an owner of the name if it later becomes available.
2918           If there are no other owners in the queue for the name, it will be
2919           removed from the bus entirely.
2920
2921           The return code can be one of the following values:
2922
2923           <informaltable>
2924             <tgroup cols="3">
2925               <thead>
2926                 <row>
2927                   <entry>Conventional Name</entry>
2928                   <entry>Value</entry>
2929                   <entry>Description</entry>
2930                 </row>
2931               </thead>
2932               <tbody>
2933                 <row>
2934                   <entry>DBUS_RELEASE_NAME_REPLY_RELEASED</entry>
2935                   <entry>1</entry> <entry>The caller has released his claim on
2936                   the given name. Either the caller was the primary owner of
2937                   the name, and the name is now unused or taken by somebody
2938                   waiting in the queue for the name, or the caller was waiting
2939                   in the queue for the name and has now been removed from the
2940                   queue.</entry>
2941                 </row>
2942                 <row>
2943                   <entry>DBUS_RELEASE_NAME_REPLY_NON_EXISTENT</entry>
2944                   <entry>2</entry>
2945                   <entry>The given name does not exist on this bus.</entry>
2946                 </row>
2947                 <row>
2948                   <entry>DBUS_RELEASE_NAME_REPLY_NOT_OWNER</entry>
2949                   <entry>3</entry>
2950                   <entry>The caller was not the primary owner of this name,
2951                   and was also not waiting in the queue to own this name.</entry>
2952                 </row>
2953               </tbody>
2954             </tgroup>
2955           </informaltable>
2956         </para>
2957       </sect3>
2958     </sect2>
2959
2960     <sect2 id="message-bus-routing">
2961       <title>Message Bus Message Routing</title>
2962       <para>
2963         FIXME
2964       </para>
2965       <sect3 id="message-bus-routing-match-rules">
2966         <title>Match Rules</title>
2967         <para>
2968           An important part of the message bus routing protocol is match
2969           rules. Match rules describe what messages can be sent to a client
2970           based on the contents of the message.  When a message is routed
2971           through the bus it is compared to clients' match rules.  If any
2972           of the rules match, the message is dispatched to the client.
2973           If none of the rules match the message never leaves the bus.  This
2974           is an effective way to control traffic over the bus and to make sure
2975           only relevant message need to be processed by the client.
2976         </para>
2977         <para>
2978           Match rules are added using the AddMatch bus method
2979           (see xref linkend="bus-messages-add-match"/>).  Rules are
2980           specified as a string of comma separated key/value pairs.
2981           Excluding a key from the rule indicates a wildcard match.
2982           For instance excluding the the member from a match rule but
2983           adding a sender would let all messages from that sender through.
2984           An example of a complete rule would be
2985           "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='Foo',path='/bar/foo',destination=':452345.34',arg2='bar'"
2986         </para>
2987         <para>
2988           The following table describes the keys that can be used to create
2989           a match rule:
2990           The following table summarizes the D-Bus types.
2991           <informaltable>
2992             <tgroup cols="3">
2993               <thead>
2994                 <row>
2995                   <entry>Key</entry>
2996                   <entry>Possible Values</entry>
2997                   <entry>Description</entry>
2998                 </row>
2999               </thead>
3000               <tbody>
3001                 <row>
3002                   <entry><literal>type</literal></entry>
3003                   <entry>'signal', 'method_call', 'method_return', 'error'</entry>
3004                   <entry>Match on the message type.  An example of a type match is type='signal'</entry>
3005                 </row>
3006                 <row>
3007                   <entry><literal>sender</literal></entry>
3008                   <entry>A bus or unique name (see <xref linkend="term-bus-name"/>
3009                   and <xref linkend="term-unique-name"/> respectively)
3010                   </entry>
3011                   <entry>Match messages sent by a particular sender.  An example of a sender match
3012                   is sender='org.freedesktop.Hal'</entry>
3013                 </row>
3014                 <row>
3015                   <entry><literal>interface</literal></entry>
3016                   <entry>An interface name (see <xref linkend="message-protocol-names-interface"/>)</entry>
3017                   <entry>Match messages sent over or to a particular interface.  An example of an
3018                   interface match is interface='org.freedesktop.Hal.Manager'.
3019                   If a message omits the interface header, it must not match any rule
3020                   that specifies this key.</entry>
3021                 </row>
3022                 <row>
3023                   <entry><literal>member</literal></entry>
3024                   <entry>Any valid method or signal name</entry>
3025                   <entry>Matches messages which have the give method or signal name. An example of
3026                   a member match is member='NameOwnerChanged'</entry>
3027                 </row>
3028                 <row>
3029                   <entry><literal>path</literal></entry>
3030                   <entry>An object path (see <xref linkend="message-protocol-marshaling-object-path"/>)</entry>
3031                   <entry>Matches messages which are sent from or to the given object. An example of a
3032                   path match is path='/org/freedesktop/Hal/Manager'</entry>
3033                 </row>
3034                 <row>
3035                   <entry><literal>destination</literal></entry>
3036                   <entry>A unique name (see <xref linkend="term-unique-name"/>)</entry>
3037                   <entry>Matches messages which are being sent to the given unique name. An
3038                   example of a destination match is destination=':1.0'</entry>
3039                 </row>
3040                 <row>
3041                   <entry><literal>arg[0, 1, 2, 3, ...]</literal></entry>
3042                   <entry>Any string</entry>
3043                   <entry>Arg matches are special and are used for further restricting the
3044                   match based on the arguments in the body of a message.  As of this time
3045                   only string arguments can be matched.  An example of an argument match
3046                   would be arg3='Foo'. Only argument indexes from 0 to 63 should be
3047                   accepted.</entry>
3048                 </row>
3049               </tbody>
3050             </tgroup>
3051           </informaltable>
3052         </para>
3053       </sect3>
3054     </sect2>
3055     <sect2 id="message-bus-starting-services">
3056       <title>Message Bus Starting Services</title>
3057       <para>
3058         The message bus can start applications on behalf of other applications.
3059         In CORBA terms, this would be called <firstterm>activation</firstterm>.
3060         An application that can be started in this way is called a
3061         <firstterm>service</firstterm>.
3062       </para>
3063       <para>
3064         With D-Bus, starting a service is normally done by name. That is,
3065         applications ask the message bus to start some program that will own a
3066         well-known name, such as <literal>org.freedesktop.TextEditor</literal>.
3067         This implies a contract documented along with the name
3068         <literal>org.freedesktop.TextEditor</literal> for which objects
3069         the owner of that name will provide, and what interfaces those
3070         objects will have.
3071       </para>
3072       <para>
3073         To find an executable corresponding to a particular name, the bus daemon
3074         looks for <firstterm>service description files</firstterm>.  Service
3075         description files define a mapping from names to executables. Different
3076         kinds of message bus will look for these files in different places, see
3077         <xref linkend="message-bus-types"/>.
3078       </para>
3079       <para>
3080         [FIXME the file format should be much better specified than "similar to
3081         .desktop entries" esp. since desktop entries are already
3082         badly-specified. ;-)] Service description files have the ".service" file
3083         extension. The message bus will only load service description files
3084         ending with .service; all other files will be ignored.  The file format
3085         is similar to that of <ulink
3086         url="http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry-spec.html">desktop
3087         entries</ulink>. All service description files must be in UTF-8
3088         encoding. To ensure that there will be no name collisions, service files
3089         must be namespaced using the same mechanism as messages and service
3090         names.
3091
3092         <figure>
3093           <title>Example service description file</title>
3094           <programlisting>
3095             # Sample service description file
3096             [D-BUS Service]
3097             Names=org.freedesktop.ConfigurationDatabase;org.gnome.GConf;
3098             Exec=/usr/libexec/gconfd-2
3099           </programlisting>
3100         </figure>
3101       </para>
3102       <para>
3103         When an application asks to start a service by name, the bus daemon tries to
3104         find a service that will own that name. It then tries to spawn the
3105         executable associated with it. If this fails, it will report an
3106         error. [FIXME what happens if two .service files offer the same service;
3107         what kind of error is reported, should we have a way for the client to
3108         choose one?]
3109       </para>
3110       <para>
3111         The executable launched will have the environment variable
3112         <literal>DBUS_STARTER_ADDRESS</literal> set to the address of the
3113         message bus so it can connect and request the appropriate names.
3114       </para>
3115       <para>
3116         The executable being launched may want to know whether the message bus
3117         starting it is one of the well-known message buses (see <xref
3118         linkend="message-bus-types"/>). To facilitate this, the bus must also set
3119         the <literal>DBUS_STARTER_BUS_TYPE</literal> environment variable if it is one
3120         of the well-known buses. The currently-defined values for this variable
3121         are <literal>system</literal> for the systemwide message bus,
3122         and <literal>session</literal> for the per-login-session message
3123         bus. The new executable must still connect to the address given
3124         in <literal>DBUS_STARTER_ADDRESS</literal>, but may assume that the
3125         resulting connection is to the well-known bus.
3126       </para>
3127       <para>
3128         [FIXME there should be a timeout somewhere, either specified
3129         in the .service file, by the client, or just a global value
3130         and if the client being activated fails to connect within that
3131         timeout, an error should be sent back.]
3132       </para>
3133
3134       <sect3 id="message-bus-starting-services-scope">
3135         <title>Message Bus Service Scope</title>
3136         <para>
3137           The "scope" of a service is its "per-", such as per-session,
3138           per-machine, per-home-directory, or per-display. The reference
3139           implementation doesn't yet support starting services in a different
3140           scope from the message bus itself. So e.g. if you start a service
3141           on the session bus its scope is per-session.
3142         </para>
3143         <para>
3144           We could add an optional scope to a bus name. For example, for
3145           per-(display,session pair), we could have a unique ID for each display
3146           generated automatically at login and set on screen 0 by executing a
3147           special "set display ID" binary. The ID would be stored in a
3148           <literal>_DBUS_DISPLAY_ID</literal> property and would be a string of
3149           random bytes. This ID would then be used to scope names.
3150           Starting/locating a service could be done by ID-name pair rather than
3151           only by name.
3152         </para>
3153         <para>
3154           Contrast this with a per-display scope. To achieve that, we would
3155           want a single bus spanning all sessions using a given display.
3156           So we might set a <literal>_DBUS_DISPLAY_BUS_ADDRESS</literal>
3157           property on screen 0 of the display, pointing to this bus.
3158         </para>
3159       </sect3>
3160     </sect2>
3161
3162     <sect2 id="message-bus-types">
3163       <title>Well-known Message Bus Instances</title>
3164       <para>
3165         Two standard message bus instances are defined here, along with how
3166         to locate them and where their service files live.
3167       </para>
3168       <sect3 id="message-bus-types-login">
3169         <title>Login session message bus</title>
3170         <para>
3171           Each time a user logs in, a <firstterm>login session message
3172             bus</firstterm> may be started. All applications in the user's login
3173           session may interact with one another using this message bus.
3174         </para>
3175         <para>
3176           The address of the login session message bus is given
3177           in the <literal>DBUS_SESSION_BUS_ADDRESS</literal> environment
3178           variable. If that variable is not set, applications may
3179           also try to read the address from the X Window System root
3180           window property <literal>_DBUS_SESSION_BUS_ADDRESS</literal>.
3181           The root window property must have type <literal>STRING</literal>.
3182           The environment variable should have precedence over the
3183           root window property.
3184         </para>
3185         <para>
3186           [FIXME specify location of .service files, probably using
3187           DESKTOP_DIRS etc. from basedir specification, though login session
3188           bus is not really desktop-specific]
3189         </para>
3190       </sect3>
3191       <sect3 id="message-bus-types-system">
3192         <title>System message bus</title>
3193         <para>
3194           A computer may have a <firstterm>system message bus</firstterm>,
3195           accessible to all applications on the system. This message bus may be
3196           used to broadcast system events, such as adding new hardware devices,
3197           changes in the printer queue, and so forth.
3198         </para>
3199         <para>
3200           The address of the system message bus is given
3201           in the <literal>DBUS_SYSTEM_BUS_ADDRESS</literal> environment
3202           variable. If that variable is not set, applications should try
3203           to connect to the well-known address
3204           <literal>unix:path=/var/run/dbus/system_bus_socket</literal>.
3205           <footnote>
3206             <para>
3207               The D-Bus reference implementation actually honors the
3208               <literal>$(localstatedir)</literal> configure option
3209               for this address, on both client and server side.
3210             </para>
3211           </footnote>
3212         </para>
3213         <para>
3214           [FIXME specify location of system bus .service files]
3215         </para>
3216       </sect3>
3217     </sect2>
3218
3219     <sect2 id="message-bus-messages">
3220       <title>Message Bus Messages</title>
3221       <para>
3222         The special message bus name <literal>org.freedesktop.DBus</literal>
3223         responds to a number of additional messages.
3224       </para>
3225
3226       <sect3 id="bus-messages-hello">
3227         <title><literal>org.freedesktop.DBus.Hello</literal></title>
3228         <para>
3229           As a method:
3230           <programlisting>
3231             STRING Hello ()
3232           </programlisting>
3233           Reply arguments:
3234           <informaltable>
3235             <tgroup cols="3">
3236               <thead>
3237                 <row>
3238                   <entry>Argument</entry>
3239                   <entry>Type</entry>
3240                   <entry>Description</entry>
3241                 </row>
3242               </thead>
3243               <tbody>
3244                 <row>
3245                   <entry>0</entry>
3246                   <entry>STRING</entry>
3247                   <entry>Unique name assigned to the connection</entry>
3248                 </row>
3249               </tbody>
3250             </tgroup>
3251           </informaltable>
3252         </para>
3253         <para>
3254           Before an application is able to send messages to other applications
3255           it must send the <literal>org.freedesktop.DBus.Hello</literal> message
3256           to the message bus to obtain a unique name. If an application without
3257           a unique name tries to send a message to another application, or a
3258           message to the message bus itself that isn't the
3259           <literal>org.freedesktop.DBus.Hello</literal> message, it will be
3260           disconnected from the bus.
3261         </para>
3262         <para>
3263           There is no corresponding "disconnect" request; if a client wishes to
3264           disconnect from the bus, it simply closes the socket (or other
3265           communication channel).
3266         </para>
3267       </sect3>
3268       <sect3 id="bus-messages-list-names">
3269         <title><literal>org.freedesktop.DBus.ListNames</literal></title>
3270         <para>
3271           As a method:
3272           <programlisting>
3273             ARRAY of STRING ListNames ()
3274           </programlisting>
3275           Reply arguments:
3276           <informaltable>
3277             <tgroup cols="3">
3278               <thead>
3279                 <row>
3280                   <entry>Argument</entry>
3281                   <entry>Type</entry>
3282                   <entry>Description</entry>
3283                 </row>
3284               </thead>
3285               <tbody>
3286                 <row>
3287                   <entry>0</entry>
3288                   <entry>ARRAY of STRING</entry>
3289                   <entry>Array of strings where each string is a bus name</entry>
3290                 </row>
3291               </tbody>
3292             </tgroup>
3293           </informaltable>
3294         </para>
3295         <para>
3296           Returns a list of all currently-owned names on the bus.
3297         </para>
3298       </sect3>
3299       <sect3 id="bus-messages-list-activatable-names">
3300         <title><literal>org.freedesktop.DBus.ListActivatableNames</literal></title>
3301         <para>
3302           As a method:
3303           <programlisting>
3304             ARRAY of STRING ListActivatableNames ()
3305           </programlisting>
3306           Reply arguments:
3307           <informaltable>
3308             <tgroup cols="3">
3309               <thead>
3310                 <row>
3311                   <entry>Argument</entry>
3312                   <entry>Type</entry>
3313                   <entry>Description</entry>
3314                 </row>
3315               </thead>
3316               <tbody>
3317                 <row>
3318                   <entry>0</entry>
3319                   <entry>ARRAY of STRING</entry>
3320                   <entry>Array of strings where each string is a bus name</entry>
3321                 </row>
3322               </tbody>
3323             </tgroup>
3324           </informaltable>
3325         </para>
3326         <para>
3327           Returns a list of all names that can be activated on the bus.
3328         </para>
3329       </sect3>
3330       <sect3 id="bus-messages-name-exists">
3331         <title><literal>org.freedesktop.DBus.NameHasOwner</literal></title>
3332         <para>
3333           As a method:
3334           <programlisting>
3335             BOOLEAN NameHasOwner (in STRING name)
3336           </programlisting>
3337           Message arguments:
3338           <informaltable>
3339             <tgroup cols="3">
3340               <thead>
3341                 <row>
3342                   <entry>Argument</entry>
3343                   <entry>Type</entry>
3344                   <entry>Description</entry>
3345                 </row>
3346               </thead>
3347               <tbody>
3348                 <row>
3349                   <entry>0</entry>
3350                   <entry>STRING</entry>
3351                   <entry>Name to check</entry>
3352                 </row>
3353               </tbody>
3354             </tgroup>
3355           </informaltable>
3356           Reply arguments:
3357           <informaltable>
3358             <tgroup cols="3">
3359               <thead>
3360                 <row>
3361                   <entry>Argument</entry>
3362                   <entry>Type</entry>
3363                   <entry>Description</entry>
3364                 </row>
3365               </thead>
3366               <tbody>
3367                 <row>
3368                   <entry>0</entry>
3369                   <entry>BOOLEAN</entry>
3370                   <entry>Return value, true if the name exists</entry>
3371                 </row>
3372               </tbody>
3373             </tgroup>
3374           </informaltable>
3375         </para>
3376         <para>
3377           Checks if the specified name exists (currently has an owner).
3378         </para>
3379       </sect3>
3380
3381       <sect3 id="bus-messages-name-owner-changed">
3382         <title><literal>org.freedesktop.DBus.NameOwnerChanged</literal></title>
3383         <para>
3384           This is a signal:
3385           <programlisting>
3386             NameOwnerChanged (STRING name, STRING old_owner, STRING new_owner)
3387           </programlisting>
3388           Message arguments:
3389           <informaltable>
3390             <tgroup cols="3">
3391               <thead>
3392                 <row>
3393                   <entry>Argument</entry>
3394                   <entry>Type</entry>
3395                   <entry>Description</entry>
3396                 </row>
3397               </thead>
3398               <tbody>
3399                 <row>
3400                   <entry>0</entry>
3401                   <entry>STRING</entry>
3402                   <entry>Name with a new owner</entry>
3403                 </row>
3404                 <row>
3405                   <entry>1</entry>
3406                   <entry>STRING</entry>
3407                   <entry>Old owner or empty string if none</entry>
3408                 </row>
3409                 <row>
3410                   <entry>2</entry>
3411                   <entry>STRING</entry>
3412                   <entry>New owner or empty string if none</entry>
3413                 </row>
3414               </tbody>
3415             </tgroup>
3416           </informaltable>
3417         </para>
3418         <para>
3419           This signal indicates that the owner of a name has changed.
3420           It's also the signal to use to detect the appearance of
3421           new names on the bus.
3422         </para>
3423       </sect3>
3424       <sect3 id="bus-messages-name-lost">
3425         <title><literal>org.freedesktop.DBus.NameLost</literal></title>
3426         <para>
3427           This is a signal:
3428           <programlisting>
3429             NameLost (STRING name)
3430           </programlisting>
3431           Message arguments:
3432           <informaltable>
3433             <tgroup cols="3">
3434               <thead>
3435                 <row>
3436                   <entry>Argument</entry>
3437                   <entry>Type</entry>
3438                   <entry>Description</entry>
3439                 </row>
3440               </thead>
3441               <tbody>
3442                 <row>
3443                   <entry>0</entry>
3444                   <entry>STRING</entry>
3445                   <entry>Name which was lost</entry>
3446                 </row>
3447               </tbody>
3448             </tgroup>
3449           </informaltable>
3450         </para>
3451         <para>
3452           This signal is sent to a specific application when it loses
3453           ownership of a name.
3454         </para>
3455       </sect3>
3456
3457       <sect3 id="bus-messages-name-acquired">
3458         <title><literal>org.freedesktop.DBus.NameAcquired</literal></title>
3459         <para>
3460           This is a signal:
3461           <programlisting>
3462             NameAcquired (STRING name)
3463           </programlisting>
3464           Message arguments:
3465           <informaltable>
3466             <tgroup cols="3">
3467               <thead>
3468                 <row>
3469                   <entry>Argument</entry>
3470                   <entry>Type</entry>
3471                   <entry>Description</entry>
3472                 </row>
3473               </thead>
3474               <tbody>
3475                 <row>
3476                   <entry>0</entry>
3477                   <entry>STRING</entry>
3478                   <entry>Name which was acquired</entry>
3479                 </row>
3480               </tbody>
3481             </tgroup>
3482           </informaltable>
3483         </para>
3484         <para>
3485           This signal is sent to a specific application when it gains
3486           ownership of a name.
3487         </para>
3488       </sect3>
3489
3490       <sect3 id="bus-messages-start-service-by-name">
3491         <title><literal>org.freedesktop.DBus.StartServiceByName</literal></title>
3492         <para>
3493           As a method:
3494           <programlisting>
3495             UINT32 StartServiceByName (in STRING name, in UINT32 flags)
3496           </programlisting>
3497           Message arguments:
3498           <informaltable>
3499             <tgroup cols="3">
3500               <thead>
3501                 <row>
3502                   <entry>Argument</entry>
3503                   <entry>Type</entry>
3504                   <entry>Description</entry>
3505                 </row>
3506               </thead>
3507               <tbody>
3508                 <row>
3509                   <entry>0</entry>
3510                   <entry>STRING</entry>
3511                   <entry>Name of the service to start</entry>
3512                 </row>
3513                 <row>
3514                   <entry>1</entry>
3515                   <entry>UINT32</entry>
3516                   <entry>Flags (currently not used)</entry>
3517                 </row>
3518               </tbody>
3519             </tgroup>
3520           </informaltable>
3521         Reply arguments:
3522         <informaltable>
3523           <tgroup cols="3">
3524             <thead>
3525               <row>
3526                 <entry>Argument</entry>
3527                 <entry>Type</entry>
3528                 <entry>Description</entry>
3529               </row>
3530             </thead>
3531             <tbody>
3532               <row>
3533                 <entry>0</entry>
3534                 <entry>UINT32</entry>
3535                 <entry>Return value</entry>
3536               </row>
3537             </tbody>
3538           </tgroup>
3539         </informaltable>
3540           Tries to launch the executable associated with a name. For more information, see <xref linkend="message-bus-starting-services"/>.
3541
3542         </para>
3543         <para>
3544           The return value can be one of the following values:
3545           <informaltable>
3546             <tgroup cols="3">
3547               <thead>
3548                 <row>
3549                   <entry>Identifier</entry>
3550                   <entry>Value</entry>
3551                   <entry>Description</entry>
3552                 </row>
3553               </thead>
3554               <tbody>
3555                 <row>
3556                   <entry>DBUS_START_REPLY_SUCCESS</entry>
3557                   <entry>1</entry>
3558                   <entry>The service was successfully started.</entry>
3559                 </row>
3560                 <row>
3561                   <entry>DBUS_START_REPLY_ALREADY_RUNNING</entry>
3562                   <entry>2</entry>
3563                   <entry>A connection already owns the given name.</entry>
3564                 </row>
3565               </tbody>
3566              </tgroup>
3567            </informaltable>
3568         </para>
3569
3570       </sect3>
3571
3572       <sect3 id="bus-messages-get-name-owner">
3573         <title><literal>org.freedesktop.DBus.GetNameOwner</literal></title>
3574         <para>
3575           As a method:
3576           <programlisting>
3577             STRING GetNameOwner (in STRING name)
3578           </programlisting>
3579           Message arguments:
3580           <informaltable>
3581             <tgroup cols="3">
3582               <thead>
3583                 <row>
3584                   <entry>Argument</entry>
3585                   <entry>Type</entry>
3586                   <entry>Description</entry>
3587                 </row>
3588               </thead>
3589               <tbody>
3590                 <row>
3591                   <entry>0</entry>
3592                   <entry>STRING</entry>
3593                   <entry>Name to get the owner of</entry>
3594                 </row>
3595               </tbody>
3596             </tgroup>
3597           </informaltable>
3598         Reply arguments:
3599         <informaltable>
3600           <tgroup cols="3">
3601             <thead>
3602               <row>
3603                 <entry>Argument</entry>
3604                 <entry>Type</entry>
3605                 <entry>Description</entry>
3606               </row>
3607             </thead>
3608             <tbody>
3609               <row>
3610                 <entry>0</entry>
3611                 <entry>STRING</entry>
3612                 <entry>Return value, a unique connection name</entry>
3613               </row>
3614             </tbody>
3615           </tgroup>
3616         </informaltable>
3617         Returns the unique connection name of the primary owner of the name
3618         given. If the requested name doesn't have an owner, returns a
3619         <literal>org.freedesktop.DBus.Error.NameHasNoOwner</literal> error.
3620        </para>
3621       </sect3>
3622
3623       <sect3 id="bus-messages-get-connection-unix-user">
3624         <title><literal>org.freedesktop.DBus.GetConnectionUnixUser</literal></title>
3625         <para>
3626           As a method:
3627           <programlisting>
3628             UINT32 GetConnectionUnixUser (in STRING connection_name)
3629           </programlisting>
3630           Message arguments:
3631           <informaltable>
3632             <tgroup cols="3">
3633               <thead>
3634                 <row>
3635                   <entry>Argument</entry>
3636                   <entry>Type</entry>
3637                   <entry>Description</entry>
3638                 </row>
3639               </thead>
3640               <tbody>
3641                 <row>
3642                   <entry>0</entry>
3643                   <entry>STRING</entry>
3644                   <entry>Name of the connection to query</entry>
3645                 </row>
3646               </tbody>
3647             </tgroup>
3648           </informaltable>
3649         Reply arguments:
3650         <informaltable>
3651           <tgroup cols="3">
3652             <thead>
3653               <row>
3654                 <entry>Argument</entry>
3655                 <entry>Type</entry>
3656                 <entry>Description</entry>
3657               </row>
3658             </thead>
3659             <tbody>
3660               <row>
3661                 <entry>0</entry>
3662                 <entry>UINT32</entry>
3663                 <entry>unix user id</entry>
3664               </row>
3665             </tbody>
3666           </tgroup>
3667         </informaltable>
3668         Returns the unix uid of the process connected to the server. If unable to
3669         determine it, a <literal>org.freedesktop.DBus.Error.Failed</literal>
3670         error is returned.
3671        </para>
3672       </sect3>
3673
3674       <sect3 id="bus-messages-add-match">
3675         <title><literal>org.freedesktop.DBus.AddMatch</literal></title>
3676         <para>
3677           As a method:
3678           <programlisting>
3679             AddMatch (in STRING rule)
3680           </programlisting>
3681           Message arguments:
3682           <informaltable>
3683             <tgroup cols="3">
3684               <thead>
3685                 <row>
3686                   <entry>Argument</entry>
3687                   <entry>Type</entry>
3688                   <entry>Description</entry>
3689                 </row>
3690               </thead>
3691               <tbody>
3692                 <row>
3693                   <entry>0</entry>
3694                   <entry>STRING</entry>
3695                   <entry>Match rule to add to the connection</entry>
3696                 </row>
3697               </tbody>
3698             </tgroup>
3699           </informaltable>
3700         Adds a match rule to match messages going through the message bus (see <xref linkend='message-bus-routing-match-rules'/>).
3701         If the bus does not have enough resources the <literal>org.freedesktop.DBus.Error.OOM</literal>
3702         error is returned.
3703        </para>
3704       </sect3>
3705       <sect3 id="bus-messages-remove-match">
3706         <title><literal>org.freedesktop.DBus.RemoveMatch</literal></title>
3707         <para>
3708           As a method:
3709           <programlisting>
3710             RemoveMatch (in STRING rule)
3711           </programlisting>
3712           Message arguments:
3713           <informaltable>
3714             <tgroup cols="3">
3715               <thead>
3716                 <row>
3717                   <entry>Argument</entry>
3718                   <entry>Type</entry>
3719                   <entry>Description</entry>
3720                 </row>
3721               </thead>
3722               <tbody>
3723                 <row>
3724                   <entry>0</entry>
3725                   <entry>STRING</entry>
3726                   <entry>Match rule to remove from the connection</entry>
3727                 </row>
3728               </tbody>
3729             </tgroup>
3730           </informaltable>
3731         Removes the first rule that matches (see <xref linkend='message-bus-routing-match-rules'/>).
3732         If the rule is not found the <literal>org.freedesktop.DBus.Error.MatchRuleNotFound</literal>
3733         error is returned.
3734        </para>
3735       </sect3>
3736
3737     </sect2>
3738
3739   </sect1>
3740 <!--
3741   <appendix id="implementation-notes">
3742     <title>Implementation notes</title>
3743     <sect1 id="implementation-notes-subsection">
3744       <title></title>
3745       <para>
3746       </para>
3747     </sect1>
3748   </appendix>
3749 -->
3750
3751   <glossary><title>Glossary</title>
3752     <para>
3753       This glossary defines some of the terms used in this specification.
3754     </para>
3755
3756     <glossentry id="term-bus-name"><glossterm>Bus Name</glossterm>
3757       <glossdef>
3758         <para>
3759           The message bus maintains an association between names and
3760           connections. (Normally, there's one connection per application.)  A
3761           bus name is simply an identifier used to locate connections. For
3762           example, the hypothetical <literal>com.yoyodyne.Screensaver</literal>
3763           name might be used to send a message to a screensaver from Yoyodyne
3764           Corporation.  An application is said to <firstterm>own</firstterm> a
3765           name if the message bus has associated the application's connection
3766           with the name.  Names may also have <firstterm>queued
3767           owners</firstterm> (see <xref linkend="term-queued-owner"/>).
3768             The bus assigns a unique name to each connection,
3769             see <xref linkend="term-unique-name"/>. Other names
3770               can be thought of as "well-known names" and are
3771               used to find applications that offer specific functionality.
3772         </para>
3773       </glossdef>
3774     </glossentry>
3775
3776     <glossentry id="term-message"><glossterm>Message</glossterm>
3777       <glossdef>
3778         <para>
3779           A message is the atomic unit of communication via the D-Bus
3780           protocol. It consists of a <firstterm>header</firstterm> and a
3781           <firstterm>body</firstterm>; the body is made up of
3782           <firstterm>arguments</firstterm>.
3783         </para>
3784       </glossdef>
3785     </glossentry>
3786
3787     <glossentry id="term-message-bus"><glossterm>Message Bus</glossterm>
3788       <glossdef>
3789         <para>
3790           The message bus is a special application that forwards
3791           or routes messages between a group of applications
3792           connected to the message bus. It also manages
3793           <firstterm>names</firstterm> used for routing
3794           messages.
3795         </para>
3796       </glossdef>
3797     </glossentry>
3798
3799     <glossentry id="term-name"><glossterm>Name</glossterm>
3800       <glossdef>
3801         <para>
3802           See <xref linkend="term-bus-name"/>. "Name" may
3803             also be used to refer to some of the other names
3804             in D-Bus, such as interface names.
3805         </para>
3806       </glossdef>
3807     </glossentry>
3808
3809     <glossentry id="namespace"><glossterm>Namespace</glossterm>
3810       <glossdef>
3811         <para>
3812           Used to prevent collisions when defining new interfaces or bus
3813           names. The convention used is the same one Java uses for defining
3814           classes: a reversed domain name.
3815         </para>
3816       </glossdef>
3817     </glossentry>
3818
3819     <glossentry id="term-object"><glossterm>Object</glossterm>
3820       <glossdef>
3821         <para>
3822           Each application contains <firstterm>objects</firstterm>, which have
3823           <firstterm>interfaces</firstterm> and
3824           <firstterm>methods</firstterm>. Objects are referred to by a name,
3825           called a <firstterm>path</firstterm>.
3826         </para>
3827       </glossdef>
3828     </glossentry>
3829
3830     <glossentry id="one-to-one"><glossterm>One-to-One</glossterm>
3831       <glossdef>
3832         <para>
3833           An application talking directly to another application, without going
3834           through a message bus. One-to-one connections may be "peer to peer" or
3835           "client to server." The D-Bus protocol has no concept of client
3836           vs. server after a connection has authenticated; the flow of messages
3837           is symmetrical (full duplex).
3838         </para>
3839       </glossdef>
3840     </glossentry>
3841
3842     <glossentry id="term-path"><glossterm>Path</glossterm>
3843       <glossdef>
3844         <para>
3845           Object references (object names) in D-Bus are organized into a
3846           filesystem-style hierarchy, so each object is named by a path. As in
3847           LDAP, there's no difference between "files" and "directories"; a path
3848           can refer to an object, while still having child objects below it.
3849         </para>
3850       </glossdef>
3851     </glossentry>
3852
3853     <glossentry id="term-queued-owner"><glossterm>Queued Name Owner</glossterm>
3854       <glossdef>
3855         <para>
3856           Each bus name has a primary owner; messages sent to the name go to the
3857           primary owner. However, certain names also maintain a queue of
3858           secondary owners "waiting in the wings." If the primary owner releases
3859           the name, then the first secondary owner in the queue automatically
3860           becomes the new owner of the name.
3861         </para>
3862       </glossdef>
3863     </glossentry>
3864
3865     <glossentry id="term-service"><glossterm>Service</glossterm>
3866       <glossdef>
3867         <para>
3868           A service is an executable that can be launched by the bus daemon.
3869           Services normally guarantee some particular features, for example they
3870           may guarantee that they will request a specific name such as
3871           "org.freedesktop.Screensaver", have a singleton object
3872           "/org/freedesktop/Application", and that object will implement the
3873           interface "org.freedesktop.ScreensaverControl".
3874         </para>
3875       </glossdef>
3876     </glossentry>
3877
3878     <glossentry id="term-service-description-files"><glossterm>Service Description Files</glossterm>
3879       <glossdef>
3880         <para>
3881           ".service files" tell the bus about service applications that can be
3882           launched (see <xref linkend="term-service"/>). Most importantly they
3883           provide a mapping from bus names to services that will request those
3884             names when they start up.
3885         </para>
3886       </glossdef>
3887     </glossentry>
3888
3889     <glossentry id="term-unique-name"><glossterm>Unique Connection Name</glossterm>
3890       <glossdef>
3891         <para>
3892           The special name automatically assigned to each connection by the
3893           message bus. This name will never change owner, and will be unique
3894           (never reused during the lifetime of the message bus).
3895           It will begin with a ':' character.
3896         </para>
3897       </glossdef>
3898     </glossentry>
3899
3900   </glossary>
3901 </article>
3902