[John Zwinck <jzwinck@xxxxxxxxx>]

As you may know, the "strings" member of struct header_field_info can be set to an array of value_strings which are a key/value pair of uint32 to string.  This allows a Wireshark dissector to specify how to display values which have an enumerated meaning.  This works when the protocol field containing enumerated values is intrinsically a number.  But what about when it is a string?  Some protocols (e.g. FIX) have text fields 
that are enumerated values (e.g. MsgType, which in FIX can be things 
like "8" or "D" or "AB").  Note that Wireshark already supports FIX, but the dissector code calls str_to_str() and then sets the display text explicitly.  Since the type string_string already exists in Wireshark, why not support its use in header_field_info?

I am fairly new to Wireshark, but this seems 
to be an area where its support could easily be made stronger, so I 
would like to know others' opinions, or if it has been tried or rejected
 already.  Looking at the source makes me think that it would involve a small patch to proto.c to call str_to_str() for FT_STRING and FT_STRINGZ if hf_field->strings is set, and call the existing str_to_str() function if so (this would parallel the existing calls to val_to_str() and rval_to_str()).  There would need to be a little support added for Lua too (which is where I actually want to use this facility).

The end goal is to improve consistency (at least in Lua it looks very odd that mapping is supported for ints but not strings), and to reduce the need for dissector developers to call the lower-level routines to format their text output when dealing with fields like these.