Tweak map-valued decode

Use the same [MsgName | Avps] representation as for the list decode, but
with Avps a map instead of a AVP name/values list. As a result, don't
set the message/AVP name on an additional key in the map, which felt a
bit odd. Messages are [MsgName :: atom() | map()], Grouped AVPs are just
map().

Fix at least one problem in the traffic suite along the way: with
decode_format false, the own decode in to_map/2 didn't know whether or
not to decode strings, resulting on some failures.

1 files changed, 4 insertions, 4 deletions

diff --git a/lib/diameter/doc/src/diameter_codec.xml b/lib/diameter/doc/src/diameter_codec.xml
index 4df8e788b7..0846334d23 100644
--- a/lib/diameter/doc/src/diameter_codec.xml
+++ b/lib/diameter/doc/src/diameter_codec.xml
@@ -230,7 +230,8 @@ header.</p>
 </item>
 
 <tag>
-<marker id="message"/><c>message() = record() | list() | map()</c></tag>
+<marker id="message"/><c>message() = record()
+                                   | maybe_improper_list()</c></tag>
 <item>
 <p>
 The representation of a Diameter message as passed to
@@ -240,9 +241,8 @@ a message as defined in a dictionary file is encoded as a record with
 one field for each component AVP.
 Equivalently, a message can also be encoded as a list whose head is
 the atom-valued message name (as specified in the relevant dictionary
-file) and whose tail is a list of <c>{AvpName, AvpValues}</c> pairs,
-or as a map with values keyed on AVP names and the message name in key
-<c>:name</c>.
+file) and whose tail is either a list of AVP name/values
+pairs or a map with values keyed on AVP names.
 The format at decode is determined by &mod_service_opt;
 <c>decode_format</c>.
 Any of the formats is accepted at encode.</p>