From 4fd623e18e5a614348eeb9406ea8b916b8ed9e4f Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Tue, 12 Dec 2017 15:36:36 +0000 Subject: [PATCH 8/8] spec: Document the design principle that new headers must be asked for Signed-off-by: Simon McVittie --- doc/dbus-specification.xml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index bbd29eb2..d784b89e 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -1624,6 +1624,23 @@ feature. + + When new header fields are added to this specification, if + they are controlled by the message bus, then the message bus + should normally only add them to messages that are to be + delivered to a client that previously requested those header + fields. It should remove those header fields from all other + messages that it relays. This design principle serves two + purposes: it avoids unnecessary memory and throughput overhead + when delivering messages to clients that are not interested in + the new header fields, and it provides a natural point at + which the client can check whether this message bus guarantees + to filter out faked header fields that might have been sent by + malicious peers (which is incentivized by the fact that any + client that relies on the new header fields but does not + ask for them would simply not work). + + Here are the currently-defined header fields: -- 2.15.1