+/*
+ * The encoding of a field of a particular type may involve more
+ * than just whether it's big-endian or little-endian and its size.
+ *
+ * For integral values, that's it, as 99.9999999999999% of the machines
+ * out there are 2's complement binary machines with 8-bit bytes,
+ * so the protocols out there expect that and, for example, any Unisys
+ * 2200 series machines out there just have to translate between 2's
+ * complement and 1's complement (and nobody's put any IBM 709x's on
+ * any networks lately :-)).
+ *
+ * However:
+ *
+ * for floating-point numbers, in addition to IEEE decimal
+ * floating-point, there's also IBM System/3x0 and PDP-11/VAX
+ * floating-point - most protocols use IEEE binary, but DCE RPC
+ * can use other formats if that's what the sending host uses;
+ *
+ * for character strings, there are various character encodings
+ * (various ISO 646 sets, ISO 8859/x, various other national
+ * standards, various DOS and Windows encodings, various Mac
+ * encodings, UTF-8, UTF-16, other extensions to ASCII, EBCDIC,
+ * etc.);
+ *
+ * for absolute times, there's UNIX time_t, UNIX time_t followed
+ * by 32-bit microseconds, UNIX time_t followed by 32-bit
+ * nanoseconds, DOS date/time, Windows FILETIME, NTP time, etc..
+ *
+ * We might also, in the future, want to allow a field specifier to
+ * indicate the encoding of the field, or at least its default
+ * encoding, as most fields in most protocols always use the
+ * same encoding (although that's not true of all fields, so we
+ * still need to be able to specify that at run time).
+ *
+ * So, for now, we define ENC_BIG_ENDIAN and ENC_LITTLE_ENDIAN as
+ * bit flags, to be combined, in the future, with other information
+ * to specify the encoding in the last argument to
+ * proto_tree_add_item(), and possibly to specify in a field
+ * definition (e.g., ORed in with the type value).
+ *
+ * Currently, proto_tree_add_item() treats its last argument as a
+ * Boolean - if it's zero, the field is big-endian, and if it's non-zero,
+ * the field is little-endian - and other code in epan/proto.c does
+ * the same. We therefore define ENC_BIG_ENDIAN as 0x00000000 and
+ * ENC_LITTLE_ENDIAN as 0x80000000 - we're using the high-order bit
+ * so that we could put a field type and/or a value such as a character
+ * encoding in the lower bits.
+ */
+#define ENC_BIG_ENDIAN 0x00000000
+#define ENC_LITTLE_ENDIAN 0x80000000
+
+/*
+ * Historically FT_TIMEs were only timespecs; the only question was whether
+ * they were stored in big- or little-endian format.
+ *
+ * For backwards compatibility, we interpret an encoding of 1 as meaning
+ * "little-endian timespec", so that passing TRUE is interpreted as that.
+ */
+#define ENC_TIME_TIMESPEC 0
+#define ENC_TIME_NTP 2
+
+/*
+ * Historically, the only place the representation mattered for strings
+ * was with FT_UINT_STRINGs, where we had FALSE for the string length
+ * being big-endian and TRUE for it being little-endian.
+ *
+ * This is a quick and dirty hack for bug 6084, which doesn't require
+ * support for multiple character encodings in FT_UINT_STRING. We
+ * introduce ENC_UTF_8 and ENC_EBCDIC, with ENC_UTF_8 being 0 and
+ * ENC_EBCDIC being the unlikely value 0x0EBCD000, and treat all values
+ * other than ENC_EBCDIC as UTF-8. That way, no matter how a dissector
+ * not converted to use ENC_ values calculates the last argument to
+ * proto_tree_add_item(), it's unlikely to get EBCDIC.
+ *
+ * The value for ENC_EBCDIC is subject to change in a future release (or
+ * to replacement with multiple values for different flavors of EBCDIC).
+ * Additional encodings will also be provided.
+ */
+#define ENC_CHARENCODING_MASK 0x7FFFFFFE /* mask out byte-order bits */
+#define ENC_UTF_8 0x00000000
+#define ENC_EBCDIC 0x0EBCD1C0
+
+/*
+ * For protocols (FT_PROTOCOL), aggregate items with subtrees (FT_NONE),
+ * opaque byte-array fields (FT_BYTES), and other fields where there
+ * is no choice of encoding (either because it's "just a bucket
+ * of bytes" or because the encoding is completely fixed), we
+ * have ENC_NA (for "Not Applicable").
+ */
+#define ENC_NA 0x00000000
+