Merge pull request #61 from darobin/feat/ban-NaN-et-al

Address titular issues in #59 and #60

Author: darobin

bibliography.json

@@ -14,6 +14,7 @@
   "manifest": "M. Cáceres, K. Rohde Christiansen, D. González, D. Murphy, C. Liebel. <a href=\"https://www.w3.org/TR/appmanifest/\"><cite>Web Application Manifest</cite></a>. March 2025. URL:&nbsp;<a href=\"https://www.w3.org/TR/appmanifest/\">https://www.w3.org/TR/appmanifest/</a>",
   "rfc2119": "S. Bradner. <a href=\"https://www.rfc-editor.org/rfc/rfc2119\"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. March 1997. URL:&nbsp;<a href=\"https://www.rfc-editor.org/rfc/rfc2119\">https://www.rfc-editor.org/rfc/rfc2119</a>",
   "rfc4648": "S. Josefsson. <a href=\"https://www.rfc-editor.org/rfc/rfc4648\"><cite>The Base16, Base32, and Base64 Data Encodings</cite></a>. October 2006. URL:&nbsp;<a href=\"https://www.rfc-editor.org/rfc/rfc4648\">https://www.rfc-editor.org/rfc/rfc4648</a>",
+  "rfc8742": "C. Bormann. <a href=\"https://www.rfc-editor.org/rfc/rfc8742\"><cite>Concise Binary Object Representation (CBOR) Sequences</cite></a>. February 2020. URL:&nbsp;<a href=\"https://www.rfc-editor.org/rfc/rfc8742\">https://www.rfc-editor.org/rfc/rfc8742</a>",
   "rfc8949": "C. Bormann, P. Hoffman. <a href=\"https://www.rfc-editor.org/rfc/rfc8949\"><cite>Concise Binary Object Representation (CBOR)</cite></a>. December 2020. URL:&nbsp;<a href=\"https://www.rfc-editor.org/rfc/rfc8949\">https://www.rfc-editor.org/rfc/rfc8949</a>",
   "sha256": "National Institute of Standards and Technology, <cite>Secure Hash Algorithm. NIST FIPS 180-2</cite>. August 2002.",
   "url": "WHATWG. <a href=\"https://url.spec.whatwg.org/\"><cite>URL</cite></a>. Living Standard. URL:&nbsp;<a href=\"https://url.spec.whatwg.org/\">https://url.spec.whatwg.org/</a>",

drisl.src.html

@@ -31,7 +31,7 @@ <h2>Introduction</h2>
     <section>
       <h2>Format</h2>
       <p>
-        DRISL is an application profile of CBOR ([[cbor]]) that subsets the more established [[cborc]] profile, with the following additional
+        DRISL is an application profile of CBOR ([[cbor]]) that mostly subsets the more established [[cborc]] profile, with the following additional
         constraints:
       </p>
       <ul>
@@ -51,6 +51,32 @@ <h2>Format</h2>
           Floating-point numbers MUST always be encoded as a 64-bit IEEE 754 binary floating-point, never as a "half-precision" (16-byte, major 7-25) or "single-precision (32-byte, major 7-26)" CBOR key.
           <strong>NOTE</strong>: It is RECOMMENDED that users avoid encoding floating-point numbers as much as possible
           to minimize interoperability and tooling issues.
+          <ul>
+            <li>
+              Completely avoiding floating-point numbers is RECOMMENDED to minimize interoperability and tooling issues.
+            </li>
+            <li>
+              Even where floating-point numbers are used, most of the IEEE 754 "special" floating points (infinity, negative infinity, minimal NaN, and NaN with payloads) MUST NOT be encoded.
+              Negative zero is the only allowed special floating point.
+            </li>
+          </ul>
+        </li>
+        <li>
+          Indefinite-length arrays (and the "break" code making them usable, in major type 7) are not allowed.
+        </li>
+        <li>
+          Similarly, indefinite, incomplete, or streaming CBOR cannot be hashed and thus cannot be referenced by CID; for this reason, DRISL can only encode finite, bounded documents and resources.
+        </li>
+        <li> 
+          Concatenation of DRISL objects is generally discouraged and incurs both performance and interoperability risks.
+          <ul>
+            <li>
+              Note that DRISL objects cannot be streamed as CBOR streams (defined in RFC 8742) except in MIME-type aware contexts, as per the CBOR streams specification.
+            </li>
+            <li>
+              Applications are discouraged from handling concatenated DRISL objects or appending extra bytes of any kind to a DRISL object in memory or across interfaces, as doing so breaks the DRISL-wide assumption that each CID refers to one complete, discrete, and valid CBOR object, and that DRISL systems only ever will be expected to handle such objects.
+            </li>
+          </ul> 
         </li>
         <li>
           Encoders MUST NOT encode any simple values other than <code>true</code>, <code>false</code>, and <code>null</code> (20, 21, and 22 in section 3.3 of [[rfc8949]]).