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.
<a href="fll/specifications/fss/fss-000f.html" class="nav-text link"><div>FSS-000F</div><div>(Simple Packet)</div></a>
</div>
<div class="nav-item block">
+ <a href="fll/specifications/fss/fss-0010.html" class="nav-text link"><div>FSS-0010</div><div>(Encrypted Simple Packet)</div></a>
+ </div>
+ <div class="nav-item block">
<a href="fll/specifications.html#iki" class="nav-text link">IKI</a>
</div>
<div class="nav-item block">
<li><a href="fll/specifications/fss/fss-000d.html" class="link">FSS-000D: Basic Rule</a></li>
<li><a href="fll/specifications/fss/fss-000e.html" class="link">FSS-000E: Payload</a></li>
<li><a href="fll/specifications/fss/fss-000f.html" class="link">FSS-000F: Simple Packet</a></li>
+ <li><a href="fll/specifications/fss/fss-0010.html" class="link">FSS-0010: Encrypted Simple Packet</a></li>
</ul>
</div>
</section>
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
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.
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
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.
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
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 <code class="code">:</code> (<code class="code">U+003A</code>) 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.
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
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 <code class="code">{</code> (<code class="code">U+007B</code>) 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 <code class="code">}</code> (<code class="code">U+007D</code>) is found, designating the end of the Content.
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This is a <code class="code">fss-0002 (Basic List)</code> whose Content is then processed as <code class="code">fss-0000 (Basic)</code>.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This is a code"fss-0002 (Basic List)" whose Content is then processed as <code class="code">fss-0001 (Extended)</code>.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This is a <code class="code">fss-0003 (Extended List)</code> whose Content is then processed as <code class="code">fss-0000 (Basic)</code>.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This is a <code class="code">fss-0003 (Extended List)</code> whose Content is then processed as <code class="code">fss-0001 (Extended)</code>.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This is a <code class="code">fss-0003 (Extended List)</code> whose Content is then recursively processed as <code class="code">fss-0003 (Extended List)</code>.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This is based off of <code class="code">fss-0000 (Basic)</code>, except the Object is at the end of the line.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This is based off of <code class="code">fss-0001 (Extended)</code>, except the Object is at the end of the line.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This is similar to <code class="code">fss-0008 (Embedded List)</code>, except it is an <code class="code">fss-0003 (Extended List)</code> with a (non-recursive) <code class="code">fss-0002 (Basic List)</code> inside the Content.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
The IKI specifications are separate specifications from the <abbr title="Featureless Settings Specifications">FSS</abbr>.
This is simply a more formal way to designate that this format utilizes IKI syntax.
</p>
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This is a special case that follows <code class="code">fss-0002 (Basic List)</code>, and different <abbr title="Featureless Settings Specifications">FSS</abbr> formats inside this <code class="code">fss-0002 (Basic List)</code>.
This <code class="code">fss-0002 (Basic List)</code> is considered the "Outer List" and the Content of this Outer List is considered the "Inner Content".
</p>
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2024/01/01</code>.
+ </p>
+ <p class="p">
This is a <code class="code">fss-0002 (Basic List)</code> with two required objects:
</p>
<ol>
<li><em class="em">header</em>.</li>
- <li><em class="em">payload</em>.</li>
+ <li><em class="em">signature</em> (optional).</li>
+ <li><em class="em">payload</em> (optional).</li>
</ol>
<p class="p">
The <em class="em">header</em>:
</p>
<ul>
- <li>The <em class="em">header</em>'s Content is of type <code class="code">fss-0001 (Extended)</code>.</li>
- <li>The <em class="em">header</em> is recommended to have the Objects <em class="em">length</em>, <em class="em">status</em>, <em class="em">part</em>, and <em class="em">total</em>.</li>
+ <li>The <em class="em">header</em>'s Content is of type <code class="code">FSS-0001 (Extended)</code>.</li>
+ <li>The <em class="em">header</em> is recommended to have the Objects <em class="em">length</em>, <em class="em">status</em>, <em class="em">part</em>, <em class="em">total</em>, and <em class="em">type</em>.</li>
<li>The recommended <em class="em">length</em> represents the size of the <em class="em">payload</em>.</li>
<li>The recommended <em class="em">part</em> represents a single part of a set of packets for when the data being transmitted is split across multiple payloads.</li>
- <li>The recommended <em class="em">total</em> represents the total number of parts representing a complete data transmitted across multiple payloads.</li>
<li>The recommended <em class="em">status</em> represents status codes (such as success or failure) and multiple.</li>
+ <li>The recommended <em class="em">total</em> represents the total number of parts representing a complete data transmitted across multiple payloads.</li>
+ <li>The recommended <em class="em">type</em> represents the type of information being transmitted.</li>
<li>The Content for the recommended <em class="em">length</em> and <em class="em">status</em> are positive whole numbers (including zero) that may be in <em class="em">binary</em>, <em class="em">octal</em>, <em class="em">decimal</em>, <em class="em">duodecimal</em>, or <em class="em">hexidecimal</em> numerical format.</li>
+ <li>There may be multiple <em class="em">header</em> Object and associated Content but the behavior is not defined by this standard.</li>
+ <li>For guaranteed safe and compatible behavior, only a single <em class="em">header</em> Object and associated Content should be defined.</li>
+ </ul>
+ <p class="p">
+ The <em class="em">signature</em>:
+ </p>
+ <ul>
+ <li>The <em class="em">signature</em>'s Content is of type <code class="code">FSS-0001 (Extended)</code>.</li>
+ <li>This is an optional Object and Content set.</li>
+ <li>This is intended to be used to specify signatures and checksums, such as GPG signatures or SHA256 checksums.</li>
+ <li>This can be used to sign or provide checksums on <em class="em">header</em> and the <em class="em">payload</em>.</li>
+ <li>There may be multiple <em class="em">signature</em> Object and associated Content but the behavior is not defined by this standard.</li>
+ <li>For guaranteed safe and compatible behavior, only a single <em class="em">signature</em> Object and associated Content should be defined.</li>
</ul>
<p class="p">
The <em class="em">payload</em>:
</p>
<ul>
<li>The <em class="em">payload</em>'s Content may contain anything, including raw binary data.</li>
- <li>The <em class="em">payload</em> is <em class="em">required</em> to be the last list Object in the file.</li>
+ <li>The <em class="em">payload</em> is <em class="em">required</em> to be the last list Object in the file, if present.</li>
<li>The <em class="em">payload</em> is recommended to have its size designated in some manner in the <em class="em">header</em> (such as with the recommended <em class="em">length</em>).</li>
<li>The <em class="em">payload</em> is terminated by the <abbr title="End of File">EOF</abbr> character or by the recommended <em class="em">length</em> header.</li>
- <li>The <em class="em">payload</em> may be empty (length may be zero), but the list Object <em class="em">payload</em> must still exist.</li>
- <li>Nothing in the <em class="em">payload</em> may be considered a valid list Object by the outer <code class="code">fss-0002 (Basic List)</code> and therefore escaping is unnecessary (No further processing by the outer <code class="code">fss-0002 (Basic List)</code> is allowed at this point).</li>
+ <li>The <em class="em">payload</em> may be empty (length may be zero).</li>
+ <li>Nothing in the <em class="em">payload</em> may be considered a valid list Object by the outer <code class="code">FSS-0002 (Basic List)</code> and therefore escaping is unnecessary (No further processing by the outer <code class="code">FSS-0002 (Basic List)</code> is allowed at this point).</li>
<li>Comments in the <em class="em">payload</em> are not considered comments and are instead considered part of the payload, as-is.</li>
<li>Essentially, the <em class="em">payload</em> should be treated as binary data embedded in a text file.</li>
+ <li>There may only be a single <em class="em">payload</em> Object and associated Content.</li>
+ <li>Any <em class="em">payload</em> 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 <em class="em">payload"</em> Object and associated Content.</li>
</ul>
<p class="p">
The recommended <em class="em">length</em> <em class="em">header</em> Object used to designate the <em class="em">payload</em> size does not necessarily have to be defined in the <em class="em">header</em>.
That is to say, if the <em class="em">payload</em> is expected to be of some pre-defined or static length then a length does not need to be provided in the <em class="em">header</em>.
</p>
<p class="p">
- The recommended <em class="em">status</em> <em class="em">header</em> Object may be a string, such as <code class="code">F_none</code>, or a positive whole number.
+ The recommended <em class="em">length</em> <em class="em">header</em> Object used to designate the <em class="em">payload</em> size does not necessarily have to be defined in the <em class="em">header</em>.
+ That is to say, if the <em class="em">payload</em> is expected to be of some pre-defined or static length then a length does not need to be provided in the <em class="em">header</em>.
+ </p>
+ <p class="p">
+ The recommended <em class="em">status</em> <em class="em">header</em> Object may be a string, such as <code class="code">F_okay</code>, 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 <abbr title="Featureless Linux Library">FLL</abbr> status code.
</p>
<ul>
- <li>The <abbr title="Featureless Linux Library">FLL</abbr> status code is a 16-bit digit whose first two high-order bits represent <em class="em">error</em> and <em class="em">warning</em> ( representing <em class="em">signal</em>).</li>
+ <li>The <abbr title="Featureless Linux Library">FLL</abbr> status code is a 16-bit digit whose first two high-order bits represent <em class="em">error</em> and <em class="em">warning</em> (representing <em class="em">signal</em>).</li>
<li>The <abbr title="Featureless Linux Library">FLL</abbr> status code as a number is binary sensitive and may not be portable across binaries or systems.</li>
<li>For best portability, consider using status as a name string to ensure cross-system or cross-binary compatibility.</li>
</ul>
status 296
length 30
+signature:
+ header sha1 e31b562d6ceba5e59dfaefbd7a37df6a20cad970
+ header type md5 cb5e100e5a9a3e7f6d1fd97512215282
+ payload sha256 fa4e17188867095856b8c5b7ff8f79e6f96c7a36621309473d09acc3fa0fe4d9
+
payload:
The program is out of memory.
</pre>
</p><pre class="preserve">
Outer Objects would be:
1) header
- 2) payload
+ 2) signature
+ 3) payload
"header" Objects would be:
1.1) type
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.
</pre>
</div>
</section>
<link type="image/x-icon" rel="shortcut" href="images/kevux.ico">
<link type="text/html" rel="license" href="licenses.html">
<link type="text/html" rel="prev" href="fll/specifications/fss/fss-000e.html">
+ <link type="text/html" rel="next" href="fll/specifications/fss/fss-0010.html">
</head>
<body id="kevux" class="kevux no-js fll specifications">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/11/14</code>.
+ </p>
+ <p class="p">
This is a network packet format that contains <code class="code">fss-000e (Payload)</code> within it.
</p>
<p class="p">
<li>Payload Block.</li>
</ol>
<p class="p">
- 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 <em class="em">string</em> or <em class="em">binary</em> bit.
- The second bit following that bit represents the endianness bit.
+ The <strong class="strong">Control Block</strong> is the first block in the packet and is considered endianless.
+ There exists only a single byte within the <strong class="strong">Control Block</strong> (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 <em class="em">string</em> or <em class="em">binary</em> bit.
</p>
<p class="p">
- The <em class="em">string</em> or <em class="em">binary</em> 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 <em class="em">string</em> packet or a <em class="em">binary</em> packet is referring to whether or not the Payload Block is in <em class="em">string</em> format or is in <em class="em">binary</em> format.
- </p>
+ Control Block Structure:
+ </p><pre class="preserve">
+[ Endianness Bit ] [ String / Binary Bit ] [ Remaining 6 Bits (unused) ]
+[ size: 1 bit ] [ size: 1 bit ] [ size: 6 bits ]
+</pre>
<p class="p">
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 <em class="em">binary</em> data within this packet, following the Control Block, must respect this endianness bit (including the <strong class="strong">Size Block</strong>).
+ </p>
+ <p class="p">
+ The <em class="em">string</em> or <em class="em">binary</em> bit, a value of 0 designates that the packet is in string format and a value of 1 designates that the packet is in <em class="em">binary</em> format.
+ While the packet might be considered to be in string format, it is technically always in <em class="em">binary</em> format due to the <strong class="strong">Control Block</strong> and <strong class="strong">Size Block</strong>.
+ This means that the <em class="em">binary</em> bit designating the packet as either a <em class="em">string</em> packet or a <em class="em">binary</em> packet is referring to whether or not the <strong class="strong">Payload Block</strong> is in <em class="em">string</em> or <em class="em">binary</em> format.
+ The <strong class="strong">Payload Block</strong> itself can contain <em class="em">binary</em> data even when in <em class="em">string</em> format as per <code class="code">FSS-000e (Payload)</code>.
</p>
<p class="p">
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 <strong class="strong">Control</strong> bits.
+ Anything that utilizes these unused <strong class="strong">Control</strong> bits may add or remove additional <strong class="strong">Blocks</strong> after the <strong class="strong">Control Block</strong> as they see fit.
+ One possible use of the remaining bits is to designate a different variation of this <strong class="strong">Simple Packet</strong> standard.
</p>
<p class="p">
- 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:
+ </p><pre class="preserve">
+[ Size Block ]
+[ size: 32 bits ]
+</pre>
+ <p class="p">
+ The <strong class="strong">Size Block</strong> is an unsigned 32-bit integer representing the size of the entire packet in bytes, including the <strong class="strong">Control Block</strong> and <strong class="strong">Size Block</strong>.
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 <strong class="strong">Control Block</strong> is 1 byte long and the <strong class="strong">Size Block</strong> is 4 bytes long, therefore the maximum available size of the entire <strong class="strong">Simple Packet</strong> structure is <code class="code">(2^32)-6</code>.
+ </p>
+ <p class="p">
+
</p>
<p class="p">
- The Payload Block is not defined by this standard of that that it exists and should be in <code class="code">fss-000e (Payload)</code> format.
- The <code class="code">fss-000e (Payload)</code> may be represented in either string format or binary format.
- The <code class="code">fss-000e (Payload)</code> may contain multiple <em class="em">header</em>(s) but may only contain a single <em class="em">payload</em>.
- With this in mind, it is recommended that only a single <em class="em">header</em> be supported in the Payload Block.
+ Payload Block Structure:
+ </p><pre class="preserve">
+[ Payload Block ]
+[ size: (2^32)-6 bytes ]
+</pre>
+ <p class="p">
+ The <strong class="strong">Payload Block</strong> is not defined by this standard other than that it exists and should be in <code class="code">FSS-000e (Payload)</code> format.
+ The <code class="code">FSS-000e (Payload)</code> may be represented in either <em class="em">string</em> format or <em class="em">binary</em> format.
+ The <code class="code">FSS-000e (Payload)</code> may contain multiple <em class="em">header</em>(s) but may only contain a single <em class="em">payload</em>.
+ With this in mind, it is recommended that only a single <em class="em">header</em> be supported in the <strong class="strong">Payload Block</strong>.
+ The <em class="em">payload</em> <strong class="strong">Content</strong> may be in either a <em class="em">binary</em> or <em class="em">string</em> format regardless of the <em class="em">binary</em> bit in the <strong class="strong">Simple Packet</strong> <strong class="strong">Header Block</strong>.
</p>
<p class="p">
- See the <a href="fll/specifications/fss/fss-000e.html" class="link">fss-000e (Payload)</a> specification for details on the syntax rules for the Payload Block.
+ See the <a href="fll/specifications/fss/fss-000e.html" class="link">fss-000e (Payload)</a> specification file for details on the syntax rules for the <strong class="strong">Payload Block</strong>.
</p>
<p class="p">
Example Packet Structure:
--- /dev/null
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+ <title>FLL - Specifications - FSS-000F (Simple Packet)</title>
+
+ <base href="../../../">
+
+ <meta charset="UTF-8">
+ <meta name="author" content="Kevin Day">
+ <meta name="description" content="Featurless Linux Library Specifications">
+ <meta name="keywords" content="Kevin Day, Kevux, FLL, Featureless, Linux, Library, Distribution, Open-Source, specification, standard, fss-0010, encrypted simple packet">
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+
+ <link type="text/css" rel="stylesheet" media="all" href="css/kevux.css">
+ <link type="text/css" rel="stylesheet" media="only screen" href="css/kevux-screen.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (min-device-width:501px)" href="css/kevux-screen-desktop.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (max-device-width:500px)" href="css/kevux-screen-mobile.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (min-device-width:1201px)" href="css/kevux-screen-large.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (min-device-width:501px) and (max-device-width:1200px)" href="css/kevux-screen-normal.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (min-device-width:251px) and (max-device-width:500px)" href="css/kevux-screen-small.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (max-device-width:250px)" href="css/kevux-screen-tiny.css">
+ <link type="text/css" rel="stylesheet" media="only print" href="css/kevux-print.css">
+ <link type="text/css" rel="stylesheet" media="only print and (orientation:landscape)" href="css/kevux-print-landscape.css">
+ <link type="text/css" rel="stylesheet" media="only print and (orientation:portrait)" href="css/kevux-print-portrait.css">
+
+ <link rel="canonical" href="fll/specifications/fss/fss-0010.html">
+ <link type="image/x-icon" rel="icon" href="images/kevux.ico">
+ <link type="image/x-icon" rel="shortcut" href="images/kevux.ico">
+ <link type="text/html" rel="license" href="licenses.html">
+ <link type="text/html" rel="prev" href="fll/specifications/fss/fss-000f.html">
+ </head>
+
+ <body id="kevux" class="kevux no-js fll specifications">
+ <div role="banner" class="header-block">
+ <header class="header-section header">
+ <div class="header-site">Kevux Systems and Software</div>
+ </header>
+
+ <div class="nav-block">
+ <nav id="kevux-site-nav" class="nav-menu">
+ <div class="nav-item"><a href="news.html" class="nav-text link">News</a></div>
+ <div class="nav-item"><a href="distributions.html" class="nav-text link">Distributions</a></div>
+ <div class="nav-item active"><a href="fll.html" class="nav-text link">FLL</a></div>
+ <div class="nav-item"><a href="projects.html" class="nav-text link">Projects</a></div>
+ <div class="nav-item"><a href="documentation.html" class="nav-text link">Documentation</a></div>
+ </nav>
+ </div>
+ </div>
+
+ <div class="content-block">
+ <div id="nav-expanded" class="nav-block">
+ <nav id="kevux-document-nav" class="nav-menu">
+ <div class="nav-item block back">
+ <a href="fll/specifications.html" class="nav-text link back">Back</a>
+ </div>
+ <div class="nav-item block highlight unlink">
+ <div class="nav-text notice">FLL Specification</div>
+ <div class="nav-text unlink">FSS</div>
+ </div>
+ <div class="nav-item block">
+ <a href="fll/specifications/fss/fss-0010.html#fss-0010" class="nav-text link"><div>FSS-0010</div><div>(Encrypted Simple Packet)</div></a>
+ </div>
+ <div class="nav-item block ellipses">
+ <a href="fll/specifications/fss/fss-0010.html#nav-expanded" class="nav-text link open" title="Expand Menu">…</a>
+ <a href="fll/specifications/fss/fss-0010.html" class="nav-text link close">Collapse Menu</a>
+ </div>
+ </nav>
+ </div>
+
+ <div role="document" class="main-block">
+ <main class="main">
+ <header class="section-header header">
+ <h1 class="section-title h h1">Featureless Linux Library Specification</h1>
+ </header>
+
+ <section id="fss-0010" class="section">
+ <header class="section-header header">
+ <h2 class="section-title h h2">FSS-0010 (Encrypted Simple Packet)</h2>
+ </header>
+
+ <div class="section-content">
+ <p class="p">
+ The version date of this specification is <code class="code">2023/07/16</code>.
+ </p>
+ <p class="p">
+ This is an encrypted form of the network packet format of <code class="code">FSS-000f (Simple Packet)</code>.
+ </p>
+ <p class="p">
+ The entire <strong class="strong">Payload Block</strong> 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 <strong class="strong">Payload Block</strong> must be of a valid length as defined by the <strong class="strong">Size Block</strong>.
+ </p>
+ <p class="p">
+ The general rule is that it can be assumed that the encrypted data in the <strong class="strong">Payload Block</strong> would be of the <code class="code">FSS-000e (Payload)</code> format. Being that the data is supposed to be encrypted, the actual contents of the <strong class="strong">Payload Block</strong> is left undefined.
+ </p>
+ <p class="p">
+ The <code class="code">FSS-000f (Simple Packet)</code> that this standard modifies does not require the <strong class="strong">Payload Block</strong> to be in <code class="code">FSS-000e (Payload)</code> format.
+ This standard is even more lax than <code class="code">FSS-000f (Simple Packet)</code> and drops replaces the words <em class="em">should be in</em> from the <code class="code">FSS-000f (Simple Packet)</code> standard and replaces them with <em class="em">could be in</em>.
+ </p>
+ <p class="p">
+ This allows for the encrypted data to be anything the user wants, such as but not limited to HTTP:"Hypertext Transfer Protocol".
+ </p>
+ <p class="p">
+ 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 <strong class="strong">Control Block</strong> and the <strong class="strong">Size Block</strong> are not encrypted.
+ </p>
+ <p class="p">
+ The endianness bit should only be used to represent the <strong class="strong">Size Block</strong> to avoid any security concerns. The endianness of the encrypted needs to be determined through some other means for any kind of reasonable security.
+ </p>
+ <p class="p">
+ This standard uses the third bit from the left in the <strong class="strong">Control Block</strong> to designate that this is an encrypted packet.
+ </p>
+ <p class="p">
+ The 5 remaining control bits are left undefined.
+ </p>
+ <p class="p">
+ See the <a href="fll/specifications/fss/fss-000f.html" class="link">fss-000f (Simple Packet)</a> specification file for details regarding the <code class="code">FSS-000f (Simple Packet)</code> standard.
+ </p>
+ <p class="p">
+ Example Packet Structure:
+ </p><pre class="preserve">
+[ Control Block ] [ Size Block ] [ Payload Block ]
+[ 0b10100000 ] [ 0b00000000 0b00000000 0b00000100 0b11010010 ] [ size: 1229 (1234 - 5) ]
+</pre>
+ <p class="p">
+ In the above example, take note that the third bit in the <strong class="strong">Control Block</strong> is a 1.
+ </p>
+ </div>
+ </section>
+ </main>
+ </div>
+ </div>
+ </body>
+</html>
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
IKI is a minimally structured WIKI-like syntax meant to be simpler than WIKI syntax.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This specification provides a small set of vocabulary names meant to be associated with common uses, such as e-mail addresses and <abbr title="Uniform Resource Locator">URL</abbr>s.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/07/14</code>.
+ </p>
+ <p class="p">
This specification provides a small set of vocabulary names meant to be used for substitution in simple scripts.
</p>
<p class="p">
<div class="section-content">
<p class="p">
+ The version date of this specification is <code class="code">2023/12/16</code>.
+ </p>
+ <p class="p">
There are two units of <strong class="strong">Time</strong>, the first is simply called <strong class="strong">Time</strong> and the second is called <strong class="strong">EpochTime</strong>.
</p>
<p class="p">
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 <code class="code">2022:-5</code> would be 5 units after the start of the year 2022.
+ For example <code class="code">2022:-5</code> would be 5 units before the start of the year 2022.
Because the negative is allowed, so must the positive character (such as <code class="code">2022:+5</code>).
A positive value is the default interpretation when no sign is valid.
</p>
<p class="p">
The unit of time called <strong class="strong">Time</strong> is counted increments of a nanosecond, or 10^-9 seconds.
A unit of <strong class="strong">Time</strong> is, therefore, equivalent to a nanosecond.
- The default year for <strong class="strong">Time</strong> 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.
</p>
<p class="p">
The unit <strong class="strong">Time</strong> has two technical forms and one common form, with the year and without the year.
<p class="p">
The unit of time called <strong class="strong">EpochTime</strong> is counted increments of a second, or 10^-9 seconds.
A unit of <strong class="strong">EpochTime</strong> is, therefore, equivalent to a second.
- The default year for <strong class="strong">EpochTime</strong> is the <strong class="strong">UNIX Epoch</strong>, sometimes called <strong class="strong">Unix time</strong>.
+ 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 <strong class="strong">EpochTime</strong> is the <strong class="strong">UNIX Epoch</strong>, sometimes called <strong class="strong">Unix time</strong>.
</p>
<p class="p">
The unit <strong class="strong">EpochTime</strong> has two technical forms and one common form, with the year and without the year.
projects / kevux.org-website / commitdiff