From 78e8e4ff1bcf6d9fe3d2b13e551da550b4b89025 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Tue, 12 Dec 2017 15:36:36 +0000 Subject: [PATCH 9/9] spec: Document the design principle that new headers must be asked for Signed-off-by: Simon McVittie --- Rewrite --- doc/dbus-specification.xml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index 2edc45fa..976ffe59 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -1624,6 +1624,25 @@ feature. + + New header fields controlled by the message bus + (similar to SENDER) might be added to this + specification in future. Such message fields should normally + only be added to messages that are going to be delivered to a + client that specifically requested them (for example by calling + some method), and the message bus should remove those header + fields from all other messages that it relays. This design + principle serves two main purposes. One is to avoid unnecessary + memory and throughput overhead when delivering messages to + clients that are not interested in the new header fields. + The other is to give clients a reason to call the method that + requests those messages (otherwise, the clients would not work). + This is desirable because looking at the reply to that method + call is a natural way to check that the message bus guarantees + to filter out faked header fields that might have been sent by + malicious peers. + + Here are the currently-defined header fields: -- 2.15.1