diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml
index 8e385351..386a63df 100644
--- a/doc/dbus-specification.xml
+++ b/doc/dbus-specification.xml
@@ -1592,14 +1592,14 @@
by a field value. A header must contain the required header fields for
its message type, and zero or more of any optional header
fields. Future versions of this protocol specification may add new
- fields. Implementations must ignore fields they do not
- understand. Implementations must not invent their own header fields;
+ fields. Implementations must not invent their own header fields;
only changes to this specification may introduce new header fields.
- Again, if an implementation sees a header field code that it does not
- expect, it must ignore that field, as it will be part of a new
+ If an implementation sees a header field code that it does not
+ expect, it must accept and ignore that field, as it will be part
+ of a new
(but compatible) version of this specification. This also applies
to known header fields appearing in unexpected messages, for
example: if a signal has a reply serial it must be ignored
@@ -1613,6 +1613,14 @@
UINT32 would be considered corrupt.
+
+ Server implementations that might relay messages from one
+ mutually-distrustful client to another, such as the message
+ bus, should remove header fields that the server does not
+ recognise. However, a client must assume that the server has
+ not done so, unless it has evidence to the contrary.
+
+
Here are the currently-defined header fields:
@@ -1646,6 +1654,7 @@
implementations should not send messages with this path,
and the reference implementation of the bus daemon will
disconnect any application that attempts to do so.
+ This header field is controlled by the message sender.
@@ -1663,6 +1672,7 @@
interface, and the reference implementation of the bus
daemon will disconnect any application that attempts to
do so.
+ This header field is controlled by the message sender.
@@ -1670,7 +1680,10 @@
3
STRING
METHOD_CALL, SIGNAL
- The member, either the method name or signal name.
+
+ The member, either the method name or signal name.
+ This header field is controlled by the message sender.
+
ERROR_NAME
@@ -1684,8 +1697,12 @@
5
UINT32
ERROR, METHOD_RETURN
- The serial number of the message this message is a reply
- to. (The serial number is the second UINT32 in the header.)
+
+ The serial number of the message this message is a reply
+ to. (The serial number is the second UINT32
+ in the header.)
+ This header field is controlled by the message sender.
+
DESTINATION
@@ -1697,6 +1714,7 @@
This field is usually only meaningful in combination with
the message bus (see ),
but other servers may define their own meanings for it.
+ This header field is controlled by the message sender.
@@ -1711,6 +1729,9 @@
On a message bus, this header field is controlled by
the message bus, so it is as reliable and trustworthy
as the message bus itself.
+ Otherwise, this header field is controlled by the message
+ sender, unless there is out-of-band information that
+ indicates otherwise.
@@ -1718,9 +1739,12 @@
8
SIGNATURE
optional
- The signature of the message body.
- If omitted, it is assumed to be the
- empty signature "" (i.e. the body must be 0-length).
+
+ The signature of the message body.
+ If omitted, it is assumed to be the
+ empty signature "" (i.e. the body must be 0-length).
+ This header field is controlled by the message sender.
+
UNIX_FDS
@@ -1736,7 +1760,9 @@
part of the message itself. They may not be sent
before the first byte of the message itself is
transferred or after the last byte of the message
- itself.
+ itself.
+ This header field is controlled by the message sender.
+