From: Kevin Day Date: Mon, 1 Jan 2024 16:59:43 +0000 (-0600) Subject: Update: Specifications and add FSS-0010 Encrypted Simple Packet specification. X-Git-Url: https://git.kevux.org/?a=commitdiff_plain;h=89e0cbcbab6dd4e737191357277f6e952acd5fd3;p=kevux.org-website Update: Specifications and add FSS-0010 Encrypted Simple Packet specification. Add "version date" paragraph to each specification to make it clearer when this specification was last updated. I happened to notice that there is a mistake in the FSS-000E specification. I fixed this in the proper FLL source code but this is after the formal 0.6.8 release was made, unfortunately. This documentation will be more up to date that the current release. Update the FSS-000E and FSS-000F specifications to reflect the changes formally introduced as of the 0.6.8 release on 2023/12/31. The FSS-0010 Encrypted Simple Packet specification has been present for a while now but I failed to update the website. This specification is now present. --- diff --git a/fll/specifications.html b/fll/specifications.html index 3cf2644..1f5cdb8 100644 --- a/fll/specifications.html +++ b/fll/specifications.html @@ -108,6 +108,9 @@
FSS-000F
(Simple Packet)
+
FSS-0010
(Encrypted Simple Packet)
 +
+
IKI
@@ -357,6 +360,7 @@ Object_2 This is multiple\" Contents and the trailing quote does not need to be
  • FSS-000D: Basic Rule
  • FSS-000E: Payload
  • FSS-000F: Simple Packet
    • +
  • FSS-0010: Encrypted Simple Packet
    • diff --git a/fll/specifications/fss/fss-0000.html b/fll/specifications/fss/fss-0000.html index 8c94dee..63658fe 100644 --- a/fll/specifications/fss/fss-0000.html +++ b/fll/specifications/fss/fss-0000.html @@ -80,6 +80,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    Each Object starts at the beginning of a line and white space to the left of the Object is not treated as part of the object. White space separates an Object from the Content. An Object may be preceded by a newline, in which case means that the Object has no Content. diff --git a/fll/specifications/fss/fss-0001.html b/fll/specifications/fss/fss-0001.html index bcf58c7..18cb3a2 100644 --- a/fll/specifications/fss/fss-0001.html +++ b/fll/specifications/fss/fss-0001.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    Each Object starts at the beginning of a line and white space to the left of the Object is not treated as an object. White space separates an Object from the Content. An Object may be followed by a newline, in which case means that the Object has no Content. diff --git a/fll/specifications/fss/fss-0002.html b/fll/specifications/fss/fss-0002.html index 71b7603..2624438 100644 --- a/fll/specifications/fss/fss-0002.html +++ b/fll/specifications/fss/fss-0002.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    Each Object starts at the beginning of a line and white space to the left of the Object is not treated as an object. A colon : (U+003A) followed by any white space until a newline terminates a valid Object. Non-white space printable characters may not follow the colon of a valid Object. diff --git a/fll/specifications/fss/fss-0003.html b/fll/specifications/fss/fss-0003.html index c5e8b54..35730f8 100644 --- a/fll/specifications/fss/fss-0003.html +++ b/fll/specifications/fss/fss-0003.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    Each Object starts at the beginning of a line and white space to the left of the Object is not treated as an object. An open-brace { (U+007B) followed by any white space until a newline terminates a possible valid Object. An Object is not considered fully valid until a valid close-brace } (U+007D) is found, designating the end of the Content. diff --git a/fll/specifications/fss/fss-0004.html b/fll/specifications/fss/fss-0004.html index bcaf47b..25dd210 100644 --- a/fll/specifications/fss/fss-0004.html +++ b/fll/specifications/fss/fss-0004.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This is a fss-0002 (Basic List) whose Content is then processed as fss-0000 (Basic).

    diff --git a/fll/specifications/fss/fss-0005.html b/fll/specifications/fss/fss-0005.html index 96eb54c..0d4ce30 100644 --- a/fll/specifications/fss/fss-0005.html +++ b/fll/specifications/fss/fss-0005.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This is a code"fss-0002 (Basic List)" whose Content is then processed as fss-0001 (Extended).

    diff --git a/fll/specifications/fss/fss-0006.html b/fll/specifications/fss/fss-0006.html index c67c01a..6ae1e8a 100644 --- a/fll/specifications/fss/fss-0006.html +++ b/fll/specifications/fss/fss-0006.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This is a fss-0003 (Extended List) whose Content is then processed as fss-0000 (Basic).

    diff --git a/fll/specifications/fss/fss-0007.html b/fll/specifications/fss/fss-0007.html index 895a500..b707230 100644 --- a/fll/specifications/fss/fss-0007.html +++ b/fll/specifications/fss/fss-0007.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This is a fss-0003 (Extended List) whose Content is then processed as fss-0001 (Extended).

    diff --git a/fll/specifications/fss/fss-0008.html b/fll/specifications/fss/fss-0008.html index 2f80425..c486f0a 100644 --- a/fll/specifications/fss/fss-0008.html +++ b/fll/specifications/fss/fss-0008.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This is a fss-0003 (Extended List) whose Content is then recursively processed as fss-0003 (Extended List).

    diff --git a/fll/specifications/fss/fss-0009.html b/fll/specifications/fss/fss-0009.html index 1502d34..e6f0e70 100644 --- a/fll/specifications/fss/fss-0009.html +++ b/fll/specifications/fss/fss-0009.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This is based off of fss-0000 (Basic), except the Object is at the end of the line.

    diff --git a/fll/specifications/fss/fss-000a.html b/fll/specifications/fss/fss-000a.html index 14ff8e9..fc6bbed 100644 --- a/fll/specifications/fss/fss-000a.html +++ b/fll/specifications/fss/fss-000a.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This is based off of fss-0001 (Extended), except the Object is at the end of the line.

    diff --git a/fll/specifications/fss/fss-000b.html b/fll/specifications/fss/fss-000b.html index d5528d4..d3c966e 100644 --- a/fll/specifications/fss/fss-000b.html +++ b/fll/specifications/fss/fss-000b.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This is similar to fss-0008 (Embedded List), except it is an fss-0003 (Extended List) with a (non-recursive) fss-0002 (Basic List) inside the Content.

    diff --git a/fll/specifications/fss/fss-000c.html b/fll/specifications/fss/fss-000c.html index 95a6000..607db99 100644 --- a/fll/specifications/fss/fss-000c.html +++ b/fll/specifications/fss/fss-000c.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    The IKI specifications are separate specifications from the FSS. This is simply a more formal way to designate that this format utilizes IKI syntax.

    diff --git a/fll/specifications/fss/fss-000d.html b/fll/specifications/fss/fss-000d.html index 977941a..659e78a 100644 --- a/fll/specifications/fss/fss-000d.html +++ b/fll/specifications/fss/fss-000d.html @@ -81,6 +81,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This is a special case that follows fss-0002 (Basic List), and different FSS formats inside this fss-0002 (Basic List). This fss-0002 (Basic List) is considered the "Outer List" and the Content of this Outer List is considered the "Inner Content".

    diff --git a/fll/specifications/fss/fss-000e.html b/fll/specifications/fss/fss-000e.html index 7c43cb8..2a4e7ee 100644 --- a/fll/specifications/fss/fss-000e.html +++ b/fll/specifications/fss/fss-000e.html @@ -81,47 +81,71 @@

    + The version date of this specification is 2024/01/01. +

    +

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

    1. header.
      2. -
    2. payload.
      3. +
    3. signature (optional).
      4. +
    4. 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, and total.
      • +
    • 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 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 total represents the total number of parts representing a complete data transmitted 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 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.
      • +
    • 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), but the list Object payload must still exist.
      • -
    • 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).
      • +
    • 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 status header Object may be a string, such as F_none, or a positive whole number. + 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 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.
    @@ -135,6 +159,11 @@ header: status 296 length 30 +signature: + header sha1 e31b562d6ceba5e59dfaefbd7a37df6a20cad970 + header type md5 cb5e100e5a9a3e7f6d1fd97512215282 + payload sha256 fa4e17188867095856b8c5b7ff8f79e6f96c7a36621309473d09acc3fa0fe4d9 + payload: The program is out of memory. @@ -143,7 +172,8 @@ The program is out of memory. 

     Outer Objects would be:
   1) header
-  2) payload
+  2) signature
+  3) payload
 
 "header" Objects would be:
   1.1) type
@@ -155,8 +185,18 @@ Outer Objects would be:
   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:
-  2) The program is out of memory.
+  3) The program is out of memory.
    diff --git a/fll/specifications/fss/fss-000f.html b/fll/specifications/fss/fss-000f.html index 8c44b27..647161b 100644 --- a/fll/specifications/fss/fss-000f.html +++ b/fll/specifications/fss/fss-000f.html @@ -28,6 +28,7 @@ + @@ -80,6 +81,9 @@

    + The version date of this specification is 2023/11/14. +

    +

    This is a network packet format that contains fss-000e (Payload) within it.

    @@ -94,41 +98,65 @@

  • Payload Block.

    • - The Control Block is the first block in the packet and is considered endianless. - There exists only a single byte within the Control Block. - Regardless of the endianness of the packet, the leftmost bit is always the string or binary bit. - The second bit following that bit represents the endianness bit. + The Control Block is the first block in the packet and is considered endianless. + There exists only a single byte within the Control Block (8-bits). + Regardless of the endianness of the packet, leftmost bit is always the endianness bit. + The second bit following that endianness bit represents the string or binary bit.

    - The string or binary bit, a value of 0 designates that the packet is in string format and a value of 1 designates that the packet is in binary format. - While the packet might be considered to be in string format, it is technically always in binary format due to the Control Block and Size Block. - This means that the bit designating the packet as a string packet or a binary packet is referring to whether or not the Payload Block is in string format or is in binary format. -

    + Control Block Structure: + 

    +[ Endianness Bit ] [ String / Binary Bit ] [ Remaining 6 Bits (unused) ]
+[ size: 1 bit    ] [ size: 1 bit         ] [ size: 6 bits              ]
+

    The endianness bit designates whether or not the packet is in big endian or little endian format. A bit value of 0 designates that this packet is in little endian and a value of 1 designates that this packet is in big endian format. - All binary data within this packet, following the Control Block, must respect this endianness bit (including the Size Block). + All binary data within this packet, following the Control Block, must respect this endianness bit (including the Size Block). +

    +

    + The string or binary bit, a value of 0 designates that the packet is in string format and a value of 1 designates that the packet is in binary format. + While the packet might be considered to be in string format, it is technically always in binary format due to the Control Block and Size Block. + This means that the binary bit designating the packet as either a string packet or a binary packet is referring to whether or not the Payload Block is in string or binary format. + The Payload Block itself can contain binary data even when in string format as per FSS-000e (Payload).

    The remaining bits are not defined by this standard and are expected to be 0. Non-formal or local uses may utilize these remaining 6 bits as desired. - However, there may be additional standards that expand upon this and utilize these remaining Control bits. - Anything that utilizes these unused Control bits may add or remove additional Blocks after the Control Block as they see fit. + However, there may be additional standards that expand upon this and utilize these remaining Control bits. + Anything that utilizes these unused Control bits may add or remove additional Blocks after the Control Block as they see fit. + One possible use of the remaining bits is to designate a different variation of this Simple Packet standard.

    - The Size Block is an unsigned 32-bit integer representing the size of the entire packet, including the Control Block and Size Block. + Size Block Structure: + 

    +[ Size Block    ]
+[ size: 32 bits ]
+
    +

    + The Size Block is an unsigned 32-bit integer representing the size of the entire packet in bytes, including the Control Block and Size Block. This size must exactly match the packet to be a valid packet. The size represents number of bytes in the file. - The Control Block is 1 byte long and the Size Block is 4 bytes long and so the maximum available size is (2^32)-6. + The Control Block is 1 byte long and the Size Block is 4 bytes long, therefore the maximum available size of the entire Simple Packet structure is (2^32)-6. +

    +

    +

    - The Payload Block is not defined by this standard of that that it exists and should be in fss-000e (Payload) format. - The fss-000e (Payload) may be represented in either string format or binary format. - The fss-000e (Payload) may contain multiple header(s) but may only contain a single payload. - With this in mind, it is recommended that only a single header be supported in the Payload Block. + Payload Block Structure: + 

    +[ Payload Block        ]
+[ size: (2^32)-6 bytes ]
+
    +

    + The Payload Block is not defined by this standard other than that it exists and should be in FSS-000e (Payload) format. + The FSS-000e (Payload) may be represented in either string format or binary format. + The FSS-000e (Payload) may contain multiple header(s) but may only contain a single payload. + With this in mind, it is recommended that only a single header be supported in the Payload Block. + The payload Content may be in either a binary or string format regardless of the binary bit in the Simple Packet Header Block.

    - See the fss-000e (Payload) specification for details on the syntax rules for the Payload Block. + See the fss-000e (Payload) specification file for details on the syntax rules for the Payload Block.

    Example Packet Structure: diff --git a/fll/specifications/fss/fss-0010.html b/fll/specifications/fss/fss-0010.html new file mode 100644 index 0000000..795d13d --- /dev/null +++ b/fll/specifications/fss/fss-0010.html @@ -0,0 +1,133 @@ + + + + FLL - Specifications - FSS-000F (Simple Packet) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

    + +
    + + +
    +
    +
    +

    Featureless Linux Library Specification

    +
    + +
    +
    +

    FSS-0010 (Encrypted Simple Packet)

    +
    + +
    +

    + The version date of this specification is 2023/07/16. +

    +

    + This is an encrypted form of the network packet format of FSS-000f (Simple Packet). +

    +

    + The entire Payload Block is undefined by this standard and is instead defined by the encryption algorithm or standard in use. + There is no rule, restriction, requirement, or definition on what encryption can be used. + The only rule is that the Payload Block must be of a valid length as defined by the Size Block. +

    +

    + The general rule is that it can be assumed that the encrypted data in the Payload Block would be of the FSS-000e (Payload) format. Being that the data is supposed to be encrypted, the actual contents of the Payload Block is left undefined. +

    +

    + The FSS-000f (Simple Packet) that this standard modifies does not require the Payload Block to be in FSS-000e (Payload) format. + This standard is even more lax than FSS-000f (Simple Packet) and drops replaces the words should be in from the FSS-000f (Simple Packet) standard and replaces them with could be in. +

    +

    + This allows for the encrypted data to be anything the user wants, such as but not limited to HTTP:"Hypertext Transfer Protocol". +

    +

    + When it comes to security, any and all data can be useful. For best encryption, one may want to consider not using this format because of the Control Block and the Size Block are not encrypted. +

    +

    + The endianness bit should only be used to represent the Size Block to avoid any security concerns. The endianness of the encrypted needs to be determined through some other means for any kind of reasonable security. +

    +

    + This standard uses the third bit from the left in the Control Block to designate that this is an encrypted packet. +

    +

    + The 5 remaining control bits are left undefined. +

    +

    + See the fss-000f (Simple Packet) specification file for details regarding the FSS-000f (Simple Packet) standard. +

    +

    + Example Packet Structure: + 

    +[ Control Block ] [ Size Block                                  ] [ Payload Block         ]
+[ 0b10100000    ] [ 0b00000000 0b00000000 0b00000100 0b11010010 ] [ size: 1229 (1234 - 5) ]
+
    +

    + In the above example, take note that the third bit in the Control Block is a 1. +

    +
    +
    +
    +
    +
    + + diff --git a/fll/specifications/iki/iki-0000.html b/fll/specifications/iki/iki-0000.html index 198ed0e..efe3acf 100644 --- a/fll/specifications/iki/iki-0000.html +++ b/fll/specifications/iki/iki-0000.html @@ -95,6 +95,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    IKI is a minimally structured WIKI-like syntax meant to be simpler than WIKI syntax.

    diff --git a/fll/specifications/iki/iki-0001.html b/fll/specifications/iki/iki-0001.html index 08ad1a6..98c5c28 100644 --- a/fll/specifications/iki/iki-0001.html +++ b/fll/specifications/iki/iki-0001.html @@ -84,6 +84,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This specification provides a small set of vocabulary names meant to be associated with common uses, such as e-mail addresses and URLs.

    diff --git a/fll/specifications/iki/iki-0002.html b/fll/specifications/iki/iki-0002.html index 6f4cd1d..6c7e72d 100644 --- a/fll/specifications/iki/iki-0002.html +++ b/fll/specifications/iki/iki-0002.html @@ -83,6 +83,9 @@

    + The version date of this specification is 2023/07/14. +

    +

    This specification provides a small set of vocabulary names meant to be used for substitution in simple scripts.

    diff --git a/fll/specifications/other/time.html b/fll/specifications/other/time.html index 46b8b99..50c16ff 100644 --- a/fll/specifications/other/time.html +++ b/fll/specifications/other/time.html @@ -82,6 +82,9 @@

    + The version date of this specification is 2023/12/16. +

    +

    There are two units of Time, the first is simply called Time and the second is called EpochTime.

    @@ -99,7 +102,7 @@ The systems should expect 64-bit and larger bits would have to become common before something larger than 64-bit is the expected or assumed default. Negative signs can be allowed but they must not prevent the full use of the 64-bit. The implementation of how this is done is left to the implementer except that the signs are immediately to the left of the digit. - For example 2022:-5 would be 5 units after the start of the year 2022. + For example 2022:-5 would be 5 units before the start of the year 2022. Because the negative is allowed, so must the positive character (such as 2022:+5). A positive value is the default interpretation when no sign is valid.

    @@ -115,7 +118,9 @@

    The unit of time called Time is counted increments of a nanosecond, or 10^-9 seconds. A unit of Time is, therefore, equivalent to a nanosecond. - The default year for Time is the current year. + When the year is not specified, then the behavior of the year is not defined. + The year can be inferred, directly designated through some other means, understood, asserted, or simply unknown or otherwise unspecified. + The general recommendation is that the default year for bold:"Time" is the current year.

    The unit Time has two technical forms and one common form, with the year and without the year. @@ -234,7 +239,8 @@

    The unit of time called EpochTime is counted increments of a second, or 10^-9 seconds. A unit of EpochTime is, therefore, equivalent to a second. - The default year for EpochTime is the UNIX Epoch, sometimes called Unix time. + The behavior when the year is not specified is the same as described for the bold:"Time". + The general recommendation is that the default year for EpochTime is the UNIX Epoch, sometimes called Unix time.

    The unit EpochTime has two technical forms and one common form, with the year and without the year.