Removed Other encoding from GAME_IDENTIFIER and performed editing pass over descriptions and introduction summary

1 files changed, 25 insertions, 21 deletions

diff --git a/src/docs/draft-tasd-spec-0001.xml b/src/docs/draft-tasd-spec-0001.xml
index 35f3945..e527bf3 100644
--- a/src/docs/draft-tasd-spec-0001.xml
+++ b/src/docs/draft-tasd-spec-0001.xml
@@ -44,8 +44,8 @@
     <section anchor="introduction" numbered="true" toc="default">
       <name>Introduction</name>
       <t>The Tool Assisted Speedrun Dump (<strong>TASD</strong>) interchange format is a file format for storing data to allow "Tool Assisted Speedruns" or "Tool Assisted Superplays" to be played on physical video game console hardware using TAS replay devices.  Created to be hardware and software agnostic, the <strong>TASD</strong> interchange format uses a key-based, binary, packet format to break up pieces of information into easily-parsable and forward-compatible chunks. The format is extensible by simply defining additional keys or value types as necessary. When parsing the file, software can skip any packets whose key is unknown or unsupported.</t>
-      <t>Keys can be used multiple times or completely omitted as needed. This reusability eliminates the need of a predefined delimiter to separate pieces of data such as a list of TAS authors.</t>
-      <t>While files generated by emulator dump scripts should provide as much information as possible, because keys are optional, the file can be expanded later with any additional data as desired. No intermediary file format is necessary.</t>
+      <t>Packets of a given type can be used multiple times or completely omitted as needed. This reusability eliminates the need of a predefined delimiter to separate pieces of data such as a list of TAS authors.</t>
+      <t>While files generated by emulator dump scripts should provide as much information as possible, because packets are optional, the file can be expanded later with any additional data as desired. No intermediary file format is necessary.</t>
       <section numbered="true" toc="default">
         <name>Overview and Preliminaries</name>
         <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
@@ -143,11 +143,11 @@
           <li>High extensibility</li>
           <li>Ability to easily generate using lua scripting in emulators</li>
         </ul>
-        <t>Consideration was also given to how usable the format would be for the software that interacts with replay devices (examples: methods of ingestion/parsing, ease of ingestion/parsing in various languages).</t>
+        <t>Consideration is also given to how usable the format would be for the software that interacts with replay devices (examples: methods of ingestion/parsing, ease of ingestion/parsing in various languages).</t>
         <section numbered="true" toc="default">
           <name>Problems With Existing Formats</name>
-          <t>Most existing formats are either incomplete for some verification needs or don't exist at all for some consoles.  A format commonly used for NES console verifications (r08) only encodes 2 standard controllers worth of sequential data and a format commonly used for SNES console verifications (r16m) only encodes up to 8 standard controllers worth of sequential data.  There is no built in way to store <strong>RESET</strong> press timing information or indicate additional settings/information.  Non-standard controllers are also not supported in commonly used formats.</t>
-          <t>For consoles not as popular as the NES and SNES, controller input formats would frequently be written in a way that is meant only to work and not in a "standard" way.  While that process works, it's less than ideal for redistribution of console replays so that others (especially with differing TAS replay devices) can also verify the same TAS.</t>
+          <t>Most existing formats are either incomplete for some verification needs or don't exist at all for some consoles.  A format commonly used for NES console verifications (r08) only encodes 2 standard controllers worth of sequential data and a format commonly used for SNES console verifications (r16m) only encodes up to 8 standard controllers worth of sequential data.  There is no built in way to store <strong>RESET</strong> timing information or indicate additional settings/information.  Non-standard controllers are also not supported in commonly used formats.</t>
+          <t>For consoles not as popular as the NES and SNES, controller input formats would frequently be written in a way that is meant only to work and not in a "standard" way.  While that process works for a specific device, it's less than ideal for redistribution of console replays so that others (especially with differing TAS replay devices) can also verify the same TAS.</t>
         </section>
       </section>
     </section>
@@ -513,7 +513,7 @@
             </artwork>
             <dl newline="true">
               <dt><strong>Type</strong></dt>
-              <dd>Function of the person who is being attributed.  <strong>Author</strong> is meant for a TAS movie author.  <strong>Verifier</strong> is meant for a person who initially console verified the the TAS movie using the <strong>TASD file</strong>.  <strong>TASD File Creator</strong> is meant for the person who initially dumped the TAS movie controller inputs into the <strong>TASD</strong> file.  <strong>TASD File Editor</strong> is meant for a person who edited the <strong>TASD</strong> file.</dd>
+              <dd>Function of the person who is being attributed.  <strong>Author</strong> is meant for a TAS movie author.  <strong>Verifier</strong> is meant for a person who console verified the TAS movie(s) contained in the <strong>TASD</strong> file.  <strong>TASD File Creator</strong> is meant for the person who initially created the <strong>TASD</strong> file, such as when dumping inputs from a TAS movie.  <strong>TASD File Editor</strong> is meant for a person who edited the <strong>TASD</strong> file.</dd>
               <dt><strong>Name</strong></dt>
               <dd>Name of the individual getting the attribution (example: "OnehundredthCoin").</dd>
               <dt><strong>PLEN</strong></dt>
@@ -533,7 +533,7 @@
             </artwork>
             <dl newline="true">
               <dt><strong>Category</strong></dt>
-              <dd>Name of the TAS movie run category (example: "Any &#37;", "100&#37;", "No Warps").</dd>
+              <dd>Name of the TAS movie run category (example: "any&#37;", "100&#37;", "No Warps").</dd>
               <dt><strong>PLEN</strong></dt>
               <dd>Length of the packet payload.</dd>
             </dl>
@@ -551,7 +551,7 @@
             </artwork>
             <dl newline="true">
               <dt><strong>Name</strong></dt>
-              <dd>Name of the emulator used to play the TAS movie while dumping controller inputs (example: "FCEUX", "Bizhawk").</dd>
+              <dd>Name of the emulator used to play the TAS movie while dumping controller inputs (example: "FCEUX", "Bizhawk"). The emulator's version or core name <bcp14>SHOULD NOT</bcp14> be included.</dd>
               <dt><strong>PLEN</strong></dt>
               <dd>Length of the packet payload.</dd>
             </dl>
@@ -685,7 +685,7 @@
             </artwork>
             <dl newline="true">
               <dt><strong>Link</strong></dt>
-              <dd>URL that points to the TAS movie or submission (example: "https://tasvideos.org/4567M").</dd>
+              <dd>URL that points to the TAS movie file (example: "https://tasvideos.org/4567M").</dd>
               <dt><strong>PLEN</strong></dt>
               <dd>Length of the packet payload.</dd>
             </dl>
@@ -703,7 +703,7 @@
             </artwork>
             <dl newline="true">
               <dt><strong>Frames</strong></dt>
-              <dd>Number of blank frames (inputs where no buttons are being pressed) needed at the beginning of a TAS console replay of the TAS movie.  If <strong>Frames</strong> is a negative value, the value of <strong>Frames</strong> amount of inputs of the TAS console replay of the TAS movie should be removed.</dd>
+              <dd>Number of blank frames (of input where no buttons are being pressed) needed at the beginning of a TAS replay.  If <strong>Frames</strong> is a negative value, the value of <strong>Frames</strong> indicates the number of frames that should be skipped from the TAS input data. A negative value is not applicable if there is no way to determine how much input data should be skipped (e.g. NES with INPUT_CHUNKs where each input represents a single latch).</dd>
             </dl>
           </section>
           <section numbered="true" toc="default" anchor="verified">
@@ -785,7 +785,7 @@
             <name>GAME_IDENTIFIER Packet</name>
             <t>GAME_IDENTIFIER packets <bcp14>MUST</bcp14> be in the following format:</t>
             <artwork><![CDATA[
-           0          1          2         3...       3+NLEN...
+           0            1            2         3...        3+NLEN...
       +----------+--------------+----------+==========+================+
       | Type (A) | Encoding (A) | NLEN (N) | Name (S) | Identifier (A) |
       +----------+--------------+----------+==========+================+
@@ -808,23 +808,22 @@
          [FF] - Other
       Encoding (Binary Data):                 [1 octet]
          [01] - Raw Binary
-         [02] - Case Insensitive Base 16 (Hex) - RFC 4648
-         [03] - Case Insensitive Base 32 - RFC 4648
-         [04] - Base 64 - RFC 4648
-         [FF] - Other
+         [02] - Base 16 (Case Insensitive)
+         [03] - Base 32 (Case Insensitive)
+         [04] - Base 64
       NLEN (Unsigned Integer)                 [1 octet]
       Name (String)                           [NLEN octets]
       Identifier (Binary Data)                [PLEN - 2 octets]]]>
             </artwork>
             <dl newline="true">
               <dt><strong>Type</strong></dt>
-              <dd>Hash, checksum, or identifier algorithm <strong>Identifier</strong> is using.</dd>
+              <dd>Hash, checksum, or identifier algorithm used to create the <strong>Identifier</strong>.</dd>
               <dt><strong>Encoding</strong></dt>
-              <dd>Describes the data encoding of <strong>Identifier</strong>.</dd>
+              <dd>Describes the data encoding of <strong>Identifier</strong>. Raw binary indicates no encoding is used. Base16/32/64 all use the standard RFC 4648 encodings, without extensions. Base 16 and Base 32 are case-insensitive.</dd>
               <dt><strong>NLEN</strong></dt>
               <dd>Length of <strong>Name</strong></dd>
               <dt><strong>Name</strong></dt>
-              <dd>Name of <strong>Type</strong> meant if the hash, checksum, or identifier algorithm <strong>Identifier</strong> is using is not included in <strong>Type</strong>.  If <strong>Type</strong> is <tt>[FF]</tt>, <strong>Name</strong> <bcp14>SHOULD NOT</bcp14> be empty (0 octet length string).</dd>
+              <dd>Name of the hash, checksum, or identifier algorithm used to create the <strong>Identifier</strong>. If <strong>Type</strong> is not <tt>[FF]</tt>, <strong>Name</strong> <bcp14>SHOULD</bcp14> be empty (0 octet length binary data).</dd>
               <dt><strong>Identifier</strong></dt>
               <dd>Game hash, checksum, or identifier data.</dd>
               <dt><strong>PLEN</strong></dt>
@@ -1105,11 +1104,12 @@
               <dt><strong>Port</strong></dt>
               <dd>Controller port number (<strong>Port</strong> number <bcp14>MUST</bcp14> be <strong>1-indexed</strong>).</dd>
               <dt><strong>Inputs</strong></dt>
-              <dd>Controller input data for controller on <strong>Port</strong>. Input values are usually in native format (usually active-low).  Input formats for specific controller types are described in (<xref target="controller_inputs"/>).</dd>
+              <dd>Controller input data for controller on <strong>Port</strong>. Input values are usually in native format (usually active-low).  Input formats for specific controller types are described in <xref target="controller_inputs"/>.</dd>
               <dt><strong>PLEN</strong></dt>
               <dd>Length of the packet payload.</dd>
             </dl>
             <t>A single INPUT_CHUNK packet <bcp14>MAY</bcp14> contain up to every input of a TAS movie console replay and <bcp14>MAY</bcp14> contain fewer than every input of a TAS movie console replay.  If there are more than 1 INPUT_CHUNK packets, the INPUT_CHUNK packets <bcp14>MUST</bcp14> be in order of the TAS movie console replay inputs, where earlier inputs in the TAS movie console replay are earlier in the <strong>TASD</strong> file and later inputs in the TAS movie console replay are later in the <strong>TASD</strong> file.</t>
+            <t>The input data contained in <strong>Inputs</strong> is divided up based on the PORT_CONTROLLER type corresponding to the <strong>Port</strong> number. Refer to <xref target="controller_inputs"/> for each available type and the number of bytes used for each instance of controller input. Keep in mind that the PORT_CONTROLLER type can be changed using TRANSITION packets.</t>
           </section>
           <section numbered="true" toc="default" anchor="input_moment">
             <name>INPUT_MOMENT Packet</name>
@@ -1142,10 +1142,11 @@
               <dt><strong>Index</strong></dt>
               <dd>Time value to start sending <strong>Inputs</strong> data.</dd>
               <dt><strong>Inputs</strong></dt>
-              <dd>Controller input data for controller on <strong>Port</strong>. Input values are usually in native format (usually active-low).  Input formats for specific controller types are described in (<xref target="controller_inputs"/>).</dd>
+              <dd>Controller input data for controller on <strong>Port</strong>. Input values are usually in native format (usually active-low).  Input formats for specific controller types are described in <xref target="controller_inputs"/>.</dd>
               <dt><strong>PLEN</strong></dt>
               <dd>Length of the packet payload.</dd>
             </dl>
+            <t>The input data contained in <strong>Inputs</strong> is divided up based on the PORT_CONTROLLER type corresponding to the <strong>Port</strong> number. Refer to <xref target="controller_inputs"/> for each available type and the number of bytes used for each instance of controller input. Keep in mind that the PORT_CONTROLLER type can be changed using TRANSITION packets.</t>
           </section>
           <section numbered="true" toc="default" anchor="transition">
             <name>TRANSITION Packet</name>
@@ -1208,6 +1209,7 @@
               <dt><strong>Count</strong></dt>
               <dd>Number of Lag Frames in a row starting from <strong>Movie Frame</strong>.</dd>
             </dl>
+            <t>Emulators typically consider a "lag frame" to be any frame in which the emulator believes the game does not poll/read controller inputs.</t>
           </section>
           <section numbered="true" toc="default" anchor="movie_transition">
             <name>MOVIE_TRANSITION</name>
@@ -1290,7 +1292,7 @@
             </artwork>
             <dl newline="true">
               <dt><strong>Unspecified Data</strong></dt>
-              <dd>Arbitrary data.  Can be used for any data.  Because this is unspecified data, there there is no guarantee any software to control a TAS replay device will support data in this packet type.</dd>
+              <dd>Arbitrary data.  Can be used for any data.  Because this is unspecified data, there is no guarantee any software used to control a TAS replay device will support data in this packet type.</dd>
               <dt><strong>PLEN</strong></dt>
               <dd>Length of the packet payload.</dd>
             </dl>
@@ -1922,6 +1924,8 @@
     </section>
     <!-- Change Log
     
+draft 14 - 2023-10-13   Bigbass Removed Other encoding option from GAME_IDENTIFIER and clarified which encoding alphabets are used. Added clarifications and improved descriptions of various packets and the Introduction section.
+    
 draft 13 - 2023-10-08   VG   Change Base to Encoding in GAME_IDENTIFIER packet
 
 draft 12 - 2023-10-08   VG   Modify GAME_IDENTIFIER packet, removing CRC-32 and CRC-16 from Type and adding NLEN and Name.  Mention seconds since Unix Epoch for Unix timestamps.