aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2015-09-14 23:41:46 +0200
committerAnders Svensson <[email protected]>2015-09-14 23:41:46 +0200
commita8d17f7e69e853d1bc858e72dc9daf6beed30f19 (patch)
tree945fdac18a607297ad7fd834dd2a1d1b0e1a936c /lib/diameter/doc
parent44a53a37f39e65c935ed2648ec74dc0f741611e1 (diff)
parent502189ba42469d3332bc0658caa2bd0de1e3fcb9 (diff)
downloadotp-a8d17f7e69e853d1bc858e72dc9daf6beed30f19.tar.gz
otp-a8d17f7e69e853d1bc858e72dc9daf6beed30f19.tar.bz2
otp-a8d17f7e69e853d1bc858e72dc9daf6beed30f19.zip
Merge branch 'anders/diameter/M-bit/OTP-12947' into maint
* anders/diameter/M-bit/OTP-12947: Add service_opt() strict_mbit
Diffstat (limited to 'lib/diameter/doc')
-rw-r--r--lib/diameter/doc/src/diameter.xml43
1 files changed, 43 insertions, 0 deletions
diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml
index 47247bc2ff..61b7fd1337 100644
--- a/lib/diameter/doc/src/diameter.xml
+++ b/lib/diameter/doc/src/diameter.xml
@@ -913,6 +913,49 @@ Options <c>monitor</c> and <c>link</c> are ignored.</p>
Defaults to the empty list.</p>
</item>
+<marker id="strict_mbit"/>
+<tag><c>{strict_mbit, boolean()}</c></tag>
+<item>
+<p>
+Whether or not to regard an AVP setting the M-bit as erroneous when
+the command grammar in question does not explicitly allow the AVP.
+If <c>true</c> then such AVPs are regarded as 5001 errors,
+DIAMETER_AVP_UNSUPPORTED.
+If <c>false</c> then the M-bit is ignored and policing
+it becomes the receiver's responsibility.</p>
+
+<p>
+Defaults to <c>true</c>.</p>
+
+<warning>
+<p>
+RFC 6733 is unclear about the semantics of the M-bit.
+One the one hand, the CCF specification in section 3.2 documents AVP
+in a command grammar as meaning <b>any</b> arbitrary AVP; on the
+other hand, 1.3.4 states that AVPs setting the M-bit cannot be added
+to an existing command: the modified command must instead be
+placed in a new Diameter application.</p>
+<p>
+The reason for the latter is presumably interoperability:
+allowing arbitrary AVPs setting the M-bit in a command makes its
+interpretation implementation-dependent, since there's no
+guarantee that all implementations will understand the same set of
+arbitrary AVPs in the context of a given command.
+However, interpreting <c>AVP</c> in a command grammar as <b>any</b>
+AVP, regardless of M-bit, renders 1.3.4 meaningless, since the receiver
+can simply ignore any AVP it thinks isn't relevant, regardless of the
+sender's intent.</p>
+<p>
+Beware of confusing mandatory in the sense of the M-bit with mandatory
+in the sense of the command grammar.
+The former is a semantic requirement: that the receiver understand the
+semantics of the AVP in the context in question.
+The latter is a syntactic requirement: whether or not the AVP must
+occur in the message in question.</p>
+</warning>
+
+</item>
+
<marker id="string_decode"/>
<tag><c>{string_decode, boolean()}</c></tag>
<item>