Some comments on the D-Bus specification

[Havoc Pennington]

Hi,

George Spelvin sent me these nice suggested edits and clarifications
for the spec, I'm passing them along with his permission (see quoted
email below).

Thanks,
Havoc

On Tue, Apr 21, 2015 at 9:50 PM, George Spelvin <linux at horizon.com> wrote:
> As part of the lkml debate on kdbus, I'm reading and trying to understand
> the D-bus specification.
>
> Here are a few questions that reading it has raised.
>
> 1. Is there a "void" type?  A dictionary from key to void
>    seems like a natural way of representing a set of keys.
>
> 2. Is alignment padding only before objects, or also after?
>    In particular, if I have y(yy)y, is it encoded as:
>
>    01 00 00 00 00 00 00 00 02 03 04
>    or
>    01 00 00 00 00 00 00 00 02 03 00 00 00 00 00 00 04
>    |           |           |           |           |
>    0           4           8           12          16
>
> 3. Why is the request serial number passed in the reply's REPLY_SERIAL
>    header extension field, and not simply in the reply header serial
>    number?
>
>    Can METHOD_RETURN or ERROR messages themselves generate errors?
>
> 4. May interface names end with a period?
>
>    It seems that a simple way to specify an interface name is
>    with the regexp:
>
>    [a-zA-Z0-9_]+(\.[a-zA-Z0-9_]+)+\.?
>
>    That, and the maximum total length of 255 characters, seems to make
>    a complete specification.
>
> 5. May bus names contain a colon?  The specification simultaneously
>    requires a leading colon and forbids any colons in bus names.
>    This is confusing.
>
>    The specification apears to say that a valid well-known bus name
>    matches the regexp
>
>    [-a-zA-Z_][-a-zA-Z0-9_]*(\.[-a-zA-Z_][-a-zA-Z0-9_]*)+\.?
>
>    and a unique connection name matches the regexp
>
>    [-a-zA-Z0-9_]+(\.[-a-zA-Z0-9_]+)+\.?
>
>    Which is, I note, a strict superset of the well-known bus names.
>
> 6. It might also be worth describing such names as "ASCII strings"
>    (a term that's already used when describing type signatures) and
>    noting that ASCII strings are a strict subset of UTF-8 strings.
>
> 7. What if ownership of a DNS name changes?  Does that also transfer the
>    right to define the interface?  Or only the right to revise it?
>
>    E.g. suppose that I own the domain love.ly.  But some strange
>    quirk of international politics prevents us doing business together,
>    so they revoke the registration and someone else snaps it up.
>
> 8. In the DBUS_COOKIE_SHA1 mechanism, are the various strings
>    hex-decoded before computing the SHA-1?
>
>    I.e. suppose we have:
>
>    C: AUTH DBUS_COOKIE_SHA1 666f6f              # "foo"
>    S: DATA 62617220302062617a                   # "bar 0 baz"
>
>    And the client generates the challenge string "quux".
>
>    Further, suppose the cookie file contains
>
>    0 0 676172706c79
>
>    Does the client hash "62617a:71757578:676172706c79"
>    and respond with
>
>    C: DATA 71757578202af2495a8ef8250e39cb9cbf50d9fd3a1eab954c
>
>    or does it hash "baz:quux:garply" and respond with
>
>    C: DATA 71757578204a6aaebfe03c70cc29ccfb1733897fc2e548ad0e
>
>    If the latter, are there any restrictions on colon characters in
>    challenge strings?
>
> 9. In the cookie file format, are the cookie ID and creation time
>    written in decimal, octal, C-style integers, or what?
>
> 10. Is it worth documenting that the creation timestamp will exceed
>     32 bits in the year 2100?
>
> 11. In the cookie file format, why is any non-zero time in the future
>     permissible?  Creation times should be strictly in the past, no?
>
> 12. The syntax of systemd transport addresses is completely unspecified.
>     Presumably they begin with "systemd:", but even that is unclear.
>
> 13. The section "message bus names" is confusing on the subject of
>      unique names.
>
>      In particular, when a connection is closed with a next connection
>      in the queue, is the unique name transferred to the next connection?
>
>      May a unique name be passed to org.freedesktop.DBus.ReleaseName?
>
> 14. Allegedly, there are strong guarantees on what a client can receive
>     over a dbus connection.  I can't find that stated anywhere.
>
>     For example:
>
>     - Are there *any* possible messages I may receive before calling
>       org.freedesktop.DBus.Hello()?
>     - Are there any possible messages I may receive between the METHOD_CALL
>       and METHOD_RETURN for Hello?  In particular, is the
>       org.freedesktop.DBus.NameAcquired SIGNAL for the unique name
>       delivered before or after the METHOD_RETURN?
>     - Likewise, for org.freedesktop.DBus.Monitoring.BecomeMonitor, do the
>       various NameLost signals arrive before or after the METHOD_RETURN?
>     - May another client send me a spurious or duplicate METHOD_RETURN?
>     - How about both an ERROR and METHOD_RETURN?
>     - How does a server terminate cleanly, that is with an appropriate
>       METHOD_RETURN for every METHOD_CALL it has received?  First I
>       assumed it could halt further calls with ReleaseName, but
>       then I rememebed your e-mail saying that many clients
>       use GetNameOwner and cache the unique name.  May a server
>       ReleaseName its unique name before flusing its queue
>       of pending METHOD_RETURNs?
>    - What if a server exits without sending a METHOD_RETURN?
>    - What if I use a message serial of 0, or a message serial of
>      1 for all my METHOD_CALLs?
>    - Is there any limit on the number of outstanding METHOD_CALLs?