Featureless Linux Library Specification

FSS-000E (Payload)

The version date of this specification is 2024/03/12.

This is a fss-0002 (Basic List) with two required objects:

  1. header.
  2. signature (optional).
  3. payload (optional).

The header:

  • The header's Content is of type FSS-0001 (Extended).
  • The header is recommended to have the Objects length, status, part, total, and type.
    • The header is suggested to have the Objects salt and time.
  • The recommended length represents the size of the payload.
  • The recommended part represents a single part of a set of packets for when the data being transmitted is split across multiple payloads.
  • The recommended status represents status codes (such as success or failure) and multiple.
  • The recommended total represents the total number of parts representing a complete data transmitted across multiple payloads.
  • The recommended type represents the type of information being transmitted.
  • The suggested salt represents random arbitrary data to further assist in making packets more unique during compression.
  • The suggested time represents some form of time unit, such as a time stamp.
  • The Content for the recommended length and status are positive whole numbers (including zero) that may be in binary, octal, decimal, duodecimal, or hexidecimal numerical format.
  • There may be multiple header Object and associated Content but the behavior is not defined by this standard.
  • For guaranteed safe and compatible behavior, only a single header Object and associated Content should be defined.

The signature:

  • The signature's Content is of type FSS-0001 (Extended).
  • This is an optional Object and Content set.
  • This is intended to be used to specify signatures and checksums, such as GPG signatures or SHA256 checksums.
  • This can be used to sign or provide checksums on header and the payload.
  • There may be multiple signature Object and associated Content but the behavior is not defined by this standard.
  • For guaranteed safe and compatible behavior, only a single signature Object and associated Content should be defined.

The payload:

  • The payload's Content may contain anything, including raw binary data.
  • The payload is required to be the last list Object in the file, if present.
  • The payload is recommended to have its size designated in some manner in the header (such as with the recommended length).
  • The payload is terminated by the EOF character or by the recommended length header.
  • The payload may be empty (length may be zero).
  • Nothing in the payload may be considered a valid list Object by the outer FSS-0002 (Basic List) and therefore escaping is unnecessary (No further processing by the outer FSS-0002 (Basic List) is allowed at this point).
  • Comments in the payload are not considered comments and are instead considered part of the payload, as-is.
  • Essentially, the payload should be treated as binary data embedded in a text file.
  • There may only be a single payload Object and associated Content.
  • Any payload Object and associated Content that is not the last must not have its Content data treated as binary in the same way as the last payload" Object and associated Content.

The recommended length header Object used to designate the payload size does not necessarily have to be defined in the header. That is to say, if the payload is expected to be of some pre-defined or static length then a length does not need to be provided in the header.

The recommended length header Object used to designate the payload size does not necessarily have to be defined in the header. That is to say, if the payload is expected to be of some pre-defined or static length then a length does not need to be provided in the header.

The recommended status header Object may be a string, such as F_okay, or a positive whole number. What the status code represents is application specific (or specific to a sub-standard) but may often be used to represent FLL status code.

  • The FLL status code is a 16-bit digit whose first two high-order bits represent error and warning (representing signal).
  • The FLL status code as a number is binary sensitive and may not be portable across binaries or systems.
  • For best portability, consider using status as a name string to ensure cross-system or cross-binary compatibility.

Example: 

# fss-000e
# valid comments are ignored.
header:
  type error
  status 296
  length 30

signature:
  header sha1 e31b562d6ceba5e59dfaefbd7a37df6a20cad970
  header type md5 cb5e100e5a9a3e7f6d1fd97512215282
  payload sha256 fa4e17188867095856b8c5b7ff8f79e6f96c7a36621309473d09acc3fa0fe4d9

payload:
The program is out of memory.

Example Results: 

Outer Objects would be:
  1) header
  2) signature
  3) payload

"header" Objects would be:
  1.1) type
  1.2) status
  1.3) length

"header" Contents would be:
  1.1.1) error
  1.2.1) 296
  1.3.1) 30

"signature" Objects would be:
  2.1) header
  2.2) header
  2.3) payload

"signature" Contents would be:
  2.1.1) sha1 e31b562d6ceba5e59dfaefbd7a37df6a20cad970
  2.2.1) type md5 cb5e100e5a9a3e7f6d1fd97512215282
  2.3.1) sha256 fa4e17188867095856b8c5b7ff8f79e6f96c7a36621309473d09acc3fa0fe4d9

The payload would be:
  3) The program is out of memory.