diff options
author | Anders Svensson <[email protected]> | 2015-09-14 23:41:46 +0200 |
---|---|---|
committer | Anders Svensson <[email protected]> | 2015-09-14 23:41:46 +0200 |
commit | a8d17f7e69e853d1bc858e72dc9daf6beed30f19 (patch) | |
tree | 945fdac18a607297ad7fd834dd2a1d1b0e1a936c /lib/diameter/doc | |
parent | 44a53a37f39e65c935ed2648ec74dc0f741611e1 (diff) | |
parent | 502189ba42469d3332bc0658caa2bd0de1e3fcb9 (diff) | |
download | otp-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.xml | 43 |
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> |