Script updating gh-pages from da89d8a. [ci skip]

Author: wolfmcnally

draft-mcnally-deterministic-cbor.html

@@ -1048,11 +1048,11 @@
 <thead><tr>
 <td class="left">Internet-Draft</td>
 <td class="center">dCBOR</td>
-<td class="right">November 2025</td>
+<td class="right">December 2025</td>
 </tr></thead>
 <tfoot><tr>
 <td class="left">McNally, et al.</td>
-<td class="center">Expires 6 May 2026</td>
+<td class="center">Expires 23 June 2026</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1065,12 +1065,12 @@
 <dd class="internet-draft">draft-mcnally-deterministic-cbor-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2025-11-02" class="published">2 November 2025</time>
+<time datetime="2025-12-20" class="published">20 December 2025</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2026-05-06">6 May 2026</time></dd>
+<dd class="expires"><time datetime="2026-06-23">23 June 2026</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1126,7 +1126,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 6 May 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 23 June 2026.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1296,10 +1296,11 @@ <h3 id="name-conventions-and-definitions">
       <h2 id="name-narrowing-rules">
 <a href="#section-2" class="section-number selfRef">2. </a><a href="#name-narrowing-rules" class="section-name selfRef">Narrowing Rules</a>
       </h2>
-<p id="section-2-1">This section specifies the exclusions and reductions that dCBOR applies to CBOR.<a href="#section-2-1" class="pilcrow">¶</a></p>
+<p id="section-2-1">This section is normative and specifies the exclusions and reductions that dCBOR applies to CBOR, thereby narrowing the set of data items allowed that are drawn from CBOR’s basic generic data model.<a href="#section-2-1" class="pilcrow">¶</a></p>
 <p id="section-2-2">The rules specified here do not "fork" CBOR: A dCBOR implementation produces well-formed, deterministically encoded CBOR according to <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span>, and existing CBOR decoders will therefore be able to decode it. Similarly, CBOR encoders will be able to produce valid dCBOR if handed dCBOR-conforming data model level information from an application.<a href="#section-2-2" class="pilcrow">¶</a></p>
 <p id="section-2-3">Note that the separation between standard CBOR processing and the processing required by the dCBOR rules is a conceptual one: Both dCBOR processing and standard CBOR processing may be combined into a unified dCBOR/CBOR codec. The requirements in this document apply to encoding or decoding of dCBOR data, regardless of whether the codec is a unified dCBOR/CBOR codec operating in dCBOR-compliant modes, or a single-purpose dCBOR codec. Both of these are generically referred to as "dCBOR codecs" in this document.<a href="#section-2-3" class="pilcrow">¶</a></p>
-<p id="section-2-4">dCBOR is intended to be used in conjunction with an application, which typically will use a subset of CBOR, which in turn influences which subset of dCBOR that is used. As a result, dCBOR places no direct requirement on what subset of CBOR is implemented. For instance, there is no requirement that dCBOR implementations support floating point numbers (or any other kind of non-basic integer type, such as arbitrary precision integers or complex numbers) when they are used with applications that do not use them. However, this document does place requirements on dCBOR implementations that support negative 64-bit integers and 64-bit or smaller floating point numbers.<a href="#section-2-4" class="pilcrow">¶</a></p>
+<p id="section-2-4">A CBOR data item is considered to conform to dCBOR only if every CBOR data item nested within it, recursively (including array elements, map keys and values, and the contents of tagged data items), also conforms to the narrowing rules in this section.<a href="#section-2-4" class="pilcrow">¶</a></p>
+<p id="section-2-5">dCBOR is intended to be used in conjunction with an application, which typically will use a subset of CBOR, which in turn influences which subset of dCBOR that is used. As a result, dCBOR places no direct requirement on what subset of CBOR is implemented. For instance, there is no requirement that dCBOR implementations support floating point numbers (or any other kind of non-basic integer type, such as arbitrary precision integers or complex numbers) when they are used with applications that do not use them. However, this document does place requirements on dCBOR implementations that support 64-bit integers and 64-bit or smaller floating point numbers.<a href="#section-2-5" class="pilcrow">¶</a></p>
 <div id="definite-length-items">
 <section id="section-2.1">
         <h3 id="name-definite-length-items">
@@ -1434,6 +1435,7 @@ <h3 id="name-numeric-reduction">
             <span class="bcp14">MUST</span> reject any encoded floating point values that are not encoded according to the above rules.<a href="#section-2.5-7.1" class="pilcrow">¶</a>
 </li>
         </ol>
+<p id="section-2.5-8">For the purposes of this document, the dCBOR numeric model comprises only untagged integers and untagged floating point values in the CBOR basic generic data model (major types 0, 1, and 7 as defined in <span>[<a href="#RFC8949" class="cite xref">RFC8949</a>]</span> and by the type <code>number</code> in <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span>). Numeric Reduction and the duplicate-key considerations in this section apply only to such untagged numeric values, wherever they occur in a dCBOR data item. Tagged data items themselves are not part of the dCBOR numeric model: two tagged data items are equal in dCBOR only if both their tag numbers and their enclosed CBOR data items are equal, and no tagged data item is ever considered numerically equal to an untagged data item.<a href="#section-2.5-8" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="simple-values">

draft-mcnally-deterministic-cbor.txt

@@ -5,11 +5,11 @@
 Network Working Group                                         W. McNally
 Internet-Draft                                                  C. Allen
 Intended status: Standards Track                      Blockchain Commons
-Expires: 6 May 2026                                           C. Bormann
+Expires: 23 June 2026                                         C. Bormann
                                                   Universität Bremen TZI
                                                             L. Lundblade
                                                      Security Theory LLC
-                                                         2 November 2025
+                                                        20 December 2025
 
 
                        dCBOR: Deterministic CBOR
@@ -52,7 +52,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 6 May 2026.
+   This Internet-Draft will expire on 23 June 2026.
 
 Copyright Notice
 
@@ -136,8 +136,9 @@ Table of Contents
 
 2.  Narrowing Rules
 
-   This section specifies the exclusions and reductions that dCBOR
-   applies to CBOR.
+   This section is normative and specifies the exclusions and reductions
+   that dCBOR applies to CBOR, thereby narrowing the set of data items
+   allowed that are drawn from CBOR’s basic generic data model.
 
    The rules specified here do not "fork" CBOR: A dCBOR implementation
    produces well-formed, deterministically encoded CBOR according to
@@ -155,6 +156,11 @@ Table of Contents
    a single-purpose dCBOR codec.  Both of these are generically referred
    to as "dCBOR codecs" in this document.
 
+   A CBOR data item is considered to conform to dCBOR only if every CBOR
+   data item nested within it, recursively (including array elements,
+   map keys and values, and the contents of tagged data items), also
+   conforms to the narrowing rules in this section.
+
    dCBOR is intended to be used in conjunction with an application,
    which typically will use a subset of CBOR, which in turn influences
    which subset of dCBOR that is used.  As a result, dCBOR places no
@@ -164,8 +170,7 @@ Table of Contents
    such as arbitrary precision integers or complex numbers) when they
    are used with applications that do not use them.  However, this
    document does place requirements on dCBOR implementations that
-   support negative 64-bit integers and 64-bit or smaller floating point
-   numbers.
+   support 64-bit integers and 64-bit or smaller floating point numbers.
 
 2.1.  Definite Length Items
 
@@ -289,6 +294,18 @@ Table of Contents
    3.  MUST reject any encoded floating point values that are not
        encoded according to the above rules.
 
+   For the purposes of this document, the dCBOR numeric model comprises
+   only untagged integers and untagged floating point values in the CBOR
+   basic generic data model (major types 0, 1, and 7 as defined in
+   [RFC8949] and by the type number in [RFC8610]).  Numeric Reduction
+   and the duplicate-key considerations in this section apply only to
+   such untagged numeric values, wherever they occur in a dCBOR data
+   item.  Tagged data items themselves are not part of the dCBOR numeric
+   model: two tagged data items are equal in dCBOR only if both their
+   tag numbers and their enclosed CBOR data items are equal, and no
+   tagged data item is ever considered numerically equal to an untagged
+   data item.
+
 2.6.  Simple Values
 
    Only the three "simple" (major type 7) values false (0xf4), true