The S Hexdump Format
Extracted elements (25)
Per-Block variable word_size support was included because embedded systems range from 8- and 16-bit processors to 64-bit and wider architectures. Specifying word size per block allows a single SHF Dump to represent data from heterogeneous memory regions with different native widths.
SHA-1 (RFC 3174) was chosen as the per-Block checksum because existing hex dump formats use simplistic checksums that provide insufficient error detection for large data sizes. SHA-1 provides 160-bit integrity with manageable overhead, and its (2^64)-1 bit input limit directly determines the maximum SHF Block size.
SHF deliberately restricts numeric representation to hexadecimal only (no octal or decimal) and Word sizes to whole bytes. This simplification was intentional to ease implementations for practical present-day applications; formats for esoteric number systems or odd Word sizes are out of scope.
SHF is XML-based to provide an open, modern, transport- and vendor-neutral format, in contrast to existing formats such as Motorola S-records which are not truly open or well-defined. XML was chosen to make the format accessible to simple tools while supporting complex data structures.
A parser reading an SHF file SHOULD silently ignore any alien characters (non-hex, non-whitespace) that appear in block data or numeric attribute values, treating them as if they did not exist. Malformed blocks (e.g., odd number of hex digits) should be ignored by implementations.
SHF is extensible: new attributes may be added to Dump or Block elements without invalidating the Dump. Parsers unaware of extended attributes SHALL silently ignore them or pass them through unchanged. Removing or redefining existing attributes is not permitted under this extension model.
SHF XML content is a proper subset of XML 1.0. Only the five predefined general entity references and numeric entity references are permitted; no other entity references may appear. The XML declaration and DOCTYPE declaration are optional (XML fragments are valid SHF).
The 'blocks' attribute in the Dump tag is optional to accommodate streaming scenarios where the total block count is not known in advance. If present, implementers should verify it; if incorrect, behavior is implementation-defined.
A data Block MUST contain at least one (1) Word and MUST NOT be larger than (2^64)-1 bits. The total size in bits is (8 * word_size * length) and this expression MUST NOT exceed (2^64)-1.
All attribute values MUST be in hexadecimal notation, with the sole exception of the 'name' attribute in Dump and Block tags. Leading zeros MAY be omitted in all attributes except 'checksum', which MUST NOT omit leading zeros.
All attribute values representing actual numeric values MUST be in big-endian format (most significant hex digits to the left). Likewise, multi-byte Words inside a Dump MUST be stored in big-endian format. Producers on little-endian architectures are responsible for byte-swapping.
An SHF consumer SHALL assure that it can handle a given Word length before beginning to parse blocks. Failure to check Word length may cause buffer overflows and endanger the stability and security of the consuming system.
If the 'length' attribute value is found to be untrue (i.e., the actual word count does not match), the Block MUST be discarded.
The MIME type charset parameter MUST be set to "UTF-8" and the character set designator MUST be uppercase. No other character sets are permitted for transporting SHF data.
The SHA-1 checksum digest MUST be calculated on the actual binary data represented by the Block, NOT on its ASCII/hexadecimal representation. This ensures integrity verification applies to the decoded content.
The SHF Dump MUST contain at least one (1) data Block. The maximum supported number of Blocks is 2^64.
The Word size MUST be an integer number of Bytes and at least one (1) Byte. The size of a Word MUST NOT be larger than (2^64)-1 bits.
A <block> element carries five compulsory attributes: 'name' (human-readable string), 'address' (64-bit hex start address in bytes), 'word_size' (64-bit hex byte-count per word), 'length' (64-bit hex word count), and 'checksum' (20-byte SHA-1 digest in hex). The element content is the hexadecimal data.
An SHF Dump is an XML structure consisting of a <dump> root element with a compulsory 'name' attribute and optional 'blocks' attribute, containing one or more <block> child elements. The dump element represents a collection of independent data Blocks, typically corresponding to non-continuous memory regions.
RFC 4194 registers the MIME media type 'application/shf+xml' for SHF files. Required parameter: charset=UTF-8 (uppercase). File extension: .shf. No magic byte sequence. Intended usage: COMMON. Change controller: IETF.
Decoded SHF data may contain executable code for a target platform. Consumers of SHF dumps intended for firmware or embedded code targets should apply additional transport security, certificates, or platform-level checksums as appropriate for their threat model.
Integrity of the SHF file as a whole (beyond per-block SHA-1) must be provided by external mechanisms such as XML digital signatures (RFC 3275) if required. SHF does not embed file-level signing.
The SHF format does not guarantee that the represented binary data is benign, correctly represented, or non-malicious. The format itself provides per-Block SHA-1 integrity but makes no authenticity guarantee about the source or intent of the data.
All attribute values representing numeric quantities and all block data content MUST be in hexadecimal notation. The 'checksum' field is a 160-bit (20-byte) SHA-1 digest encoded as 40 hex digits and MUST NOT omit leading zeros. All numeric values are in big-endian format.
Valid hex content in block data and numeric attributes is defined as: whitespace (0x20, 0x09, 0x0C, 0x0D, 0x0A) interspersed with hexadecimal digits [0-9A-Fa-f]. Whitespace has no semantic meaning and may be removed. The number of hex digits inside a block must be even because word_size is in whole bytes.