Add service_opt() strict_mbit

There are differing opinions on whether or not reception of an arbitrary
AVP setting the M-bit is an error. 1.3.4 of RFC 6733 says this about
how an existing Diameter application may be modified:

   o  The M-bit allows the sender to indicate to the receiver whether or
      not understanding the semantics of an AVP and its content is
      mandatory.  If the M-bit is set by the sender and the receiver
      does not understand the AVP or the values carried within that AVP,
      then a failure is generated (see Section 7).

   It is the decision of the protocol designer when to develop a new
   Diameter application rather than extending Diameter in other ways.
   However, a new Diameter application MUST be created when one or more
   of the following criteria are met:

   M-bit Setting

      An AVP with the M-bit in the MUST column of the AVP flag table is
      added to an existing Command/Application.  An AVP with the M-bit
      in the MAY column of the AVP flag table is added to an existing
      Command/Application.

The point here is presumably interoperability: that the command grammar
should specify explicitly what mandatory AVPs much be understood, and
that anything more is an error.

On the other hand, 3.2 says thus about command grammars:

   avp-name         = avp-spec / "AVP"
                      ; The string "AVP" stands for *any* arbitrary AVP
                      ; Name, not otherwise listed in that Command Code
                      ; definition.  The inclusion of this string
                      ; is recommended for all CCFs to allow for
                      ; extensibility.

This renders 1.3.4 pointless unless "*any* AVP" is qualified by "not
setting the M-bit", since the sender can effectively violate 1.3.4
without this necessitating an error at the receiver. If clients add
arbitrary AVPs setting the M-bit then request handling becomes more
implementation-dependent.

The current interpretation in diameter is strict: if a command grammar
doesn't explicitly allow an AVP setting the M-bit then reception of such
an AVP is regarded as an error. The strict_mbit option now allows this
behaviour to be changed, false turning all responsibility for the M-bit
over to the user.

1 files changed, 6 insertions, 2 deletions

diff --git a/lib/diameter/include/diameter_gen.hrl b/lib/diameter/include/diameter_gen.hrl
index ac2126cdc5..39ccdc9873 100644
--- a/lib/diameter/include/diameter_gen.hrl
+++ b/lib/diameter/include/diameter_gen.hrl
@@ -30,7 +30,10 @@
 
 %% Key to a value in the process dictionary that determines whether or
 %% not an unrecognized AVP setting the M-bit should be regarded as an
-%% error or not. See is_strict/0.
+%% error or not. See is_strict/0. This is only used to relax M-bit
+%% interpretation inside Grouped AVPs not setting the M-bit. The
+%% service_opt() strict_mbit can be used to disable the check
+%% globally.
 -define(STRICT_KEY, strict).
 
 %% Key that says whether or not we should do a best-effort decode
@@ -447,7 +450,8 @@ relax(_, _) ->
     false.
 
 is_strict() ->
-    false /= getr(?STRICT_KEY).
+    diameter_codec:getopt(strict_mbit)
+        andalso false /= getr(?STRICT_KEY).
 
 %% relax/1
 %%