Cleanup and fixes.

Author: wolfmcnally

papers/bcr-2020-002-bech32-seed-format.md

@@ -6,6 +6,10 @@
 Author: Wolf McNally<br/>
 Date: April 22, 2020
 
+### DEPRECATED
+
+The content below is now deprecated and of historical interest only.
+
 ---
 
 ### Introduction

papers/bcr-2020-004-bc32.md

@@ -6,6 +6,10 @@
 Authors: Wolf McNally, Christopher Allen<br/>
 Date: May 5, 2020
 
+### DEPRECATED
+
+The content below is now deprecated and of historical interest only.
+
 ---
 
 ### Introduction

papers/bcr-2020-005-ur.md

@@ -7,9 +7,8 @@ Encoding Structured Binary Data for Transport in URIs and QR Codes
 **© 2020 Blockchain Commons**
 
 Authors: Wolf McNally, Christopher Allen<br/>
-Version: 2.0.1<br/>
-Date: July 9, 2020<br/>
-Revised: March 4, 20201
+Version: 2.1.0<br/>
+Revised: Aug 19, 2023
 
 ---
 
@@ -88,16 +87,7 @@ By specifying a standard for binary structure, users of this format can begin to
 
 #### Canonical CBOR
 
-The CBOR in URs MUST adhere to ["Canonical CBOR", Section 3.9](https://tools.ietf.org/html/rfc7049#section-3.9). For instance, keys in maps must be sorted from lowest to highest.
-
-In addition, a minimal canonical representation for encoding byte strings be used:
-
-* If the encoded byte string has 23 or fewer bytes, it is preceded by the single byte (`0x40` + length).
-* If the encoded byte string has 24..255 bytes, it is preceded by (`0x58`, length) where *length* is the length of the following byte string.
-* If the encoded byte string has 256..65535 bytes, it is preceded by (`0x59`, h, l) where *h*, *l* is the big-endian two byte length of the following byte string.
-* If the encoded byte string has 65536..2^32-1 bytes, it is preceded by (`0x5a`, b1, b2, b3, b4) where *b(n)* is the big-endian four byte length of the following byte string.
-
-Writers of this format MUST use the shortest encoding given the length of the payload. CBOR also supports an 8-byte length encoding for payloads longer than 2^32-1 bytes, and also encoding of "indefinite length" byte strings, but implementors of this specification MAY refuse to decode them. Implementors of this specification MAY also reject any other CBOR constructs.
+The CBOR in URs MUST adhere to ["Deterministic CBOR", § 4.2](https://datatracker.ietf.org/doc/html/rfc8949#name-deterministically-encoded-c). For instance, keys in maps must be sorted from lowest to highest.
 
 #### CBOR Examples
 

papers/bcr-2020-013-crc32-cbor-tag.md

@@ -7,6 +7,10 @@
 Authors: Wolf McNally, Christopher Allen<br/>
 Date: July 3, 2020
 
+### DEPRECATED
+
+The content below is now deprecated and of historical interest only.
+
 ### Introduction
 
 This document registers a tag for serializing CRC-32 checksums in Concise Binary Object Representation (CBOR).

papers/bcr-2022-001-encrypted-message.md

@@ -71,31 +71,31 @@ ciphertext: `d31a8d34648e60db7b86afbc53ef7ec2a4aded51296e08fea9e2b5a736ee62d63db
 * In the CBOR diagnostic notation, with `#6.40002` tag:
 
 ```
-40002( # encrypted
+40002( / encrypted /
    [
       h'd31a8d34648e60db7b86afbc53ef7ec2a4aded51296e08fea9e2b5a736ee62d6
         3dbea45e8ca9671282fafb69da92728b1a71de0a9e060b2905d6a5b67ecd3b36
         92ddbd7f2d778b8c9803aee328091b58fab324e4fad675945585808b4831d7bc
-        3ff4def08e4b7a9de576d26586cec64b6116', ; ciphertext
-      h'070000004041424344454647', ; nonce
-      h'1ae10b594f09e26a7e902ecbd0600691', ; auth
-      h'50515253c0c1c2c3c4c5c6c7' ; aad
+        3ff4def08e4b7a9de576d26586cec64b6116', / ciphertext /
+      h'070000004041424344454647', / nonce /
+      h'1ae10b594f09e26a7e902ecbd0600691', / auth /
+      h'50515253c0c1c2c3c4c5c6c7' / aad /
    ]
 )
 ```
 
 * Encoded as binary using [CBOR Playground](https://cbor.me):
 
 ```
-d9 9c42                                 # tag(40002)   ; encrypted
+d9 9c42                                 # tag(40002) encrypted
    84                                   # array(4)
-      58 72                             # bytes(114) ; ciphertext
+      58 72                             # bytes(114) ciphertext
          d31a8d34648e60db7b86afbc53ef7ec2a4aded51296e08fea9e2b5a736ee62d63dbea45e8ca9671282fafb69da92728b1a71de0a9e060b2905d6a5b67ecd3b3692ddbd7f2d778b8c9803aee328091b58fab324e4fad675945585808b4831d7bc3ff4def08e4b7a9de576d26586cec64b6116
       4c                                # bytes(12)
          070000004041424344454647       # "....@ABCDEFG"
-      50                                # bytes(16) ; auth
+      50                                # bytes(16) auth
          1ae10b594f09e26a7e902ecbd0600691
-      4c                                # bytes(12) ; aad
+      4c                                # bytes(12) aad
          50515253c0c1c2c3c4c5c6c7       #
 ```
 

papers/bcr-2023-003-envelope-known-value.md

@@ -27,7 +27,8 @@ This document extends the [Gordian Envelope Base Specification](https://datatrac
 This section is normative, and specifies an additional case arm for the `envelope` type: `known-value`. The formal language used is the [Concise Data Definition Language (CDDL)](https://datatracker.ietf.org/doc/html/rfc8610). The top-level specification of Gordian Envelope with this extension added is:
 
 ```
-envelope = #6.200(
+envelope = #6.200(envelope-content)
+envelope-content = (
     leaf / elided / node / assertion / wrapped /
     known-value
 )

papers/bcr-2023-004-envelope-symmetric-encryption.md

@@ -27,7 +27,8 @@ This section is normative, and specifies an additional case arm for the `envelop
 The formal language used is the [Concise Data Definition Language (CDDL)](https://datatracker.ietf.org/doc/html/rfc8610). The top-level specification of Gordian Envelope with this extension added is:
 
 ~~~
-envelope = #6.200(
+envelope = #6.200(envelope-content)
+envelope-content = (
     leaf / elided / node / assertion / wrapped /
     encrypted
 )
@@ -70,8 +71,8 @@ $ ENVELOPE=`envelope subject "Hello"`
 
 $ envelope format --diag $ENVELOPE
 
-200(   ; envelope
-   24("Hello")   ; leaf
+200(   / envelope /
+   24("Hello")   / leaf /
 )
 
 $ envelope digest --hex $ENVELOPE
@@ -81,8 +82,8 @@ $ envelope digest --hex $ENVELOPE
 $ ENCRYPTED_ENVELOPE=`envelope encrypt --key $KEY $ENVELOPE`
 $ envelope format --diag $ENCRYPTED_ENVELOPE
 
-200(   ; envelope
-   40002(   ; encrypted
+200(   / envelope /
+   40002(   / encrypted /
       [
          h'dadeecba53db714445c0',
          h'3cda0648bcb07f0f8b4da2be',

papers/bcr-2023-005-envelope-compression.md

@@ -25,7 +25,8 @@ This section is normative, and specifies an additional case arm for the `envelop
 The formal language used is the [Concise Data Definition Language (CDDL)](https://datatracker.ietf.org/doc/html/rfc8610). The top-level specification of Gordian Envelope with this extension added is:
 
 ~~~
-envelope = #6.200(
+envelope = #6.200(envelope-content)
+envelope-content = (
     leaf / elided / node / assertion / wrapped /
     compressed
 )
@@ -70,8 +71,8 @@ $ ENVELOPE=`envelope subject "Hello"`
 
 $ envelope format --diag $ENVELOPE
 
-200(   ; envelope
-   24("Hello")   ; leaf
+200(   / envelope /
+   24("Hello")   / leaf /
 )
 
 $ envelope digest --hex $ENVELOPE
@@ -81,13 +82,13 @@ $ envelope digest --hex $ENVELOPE
 $ COMPRESSED_ENVELOPE=`envelope compress $ENVELOPE`
 $ envelope format --diag $COMPRESSED_ENVELOPE
 
-200(   ; envelope
-   40003(   ; compressed
+200(   / envelope /
+   40003(   / compressed /
       [
          1146116589,
          10,
          h'd8c8d8186548656c6c6f',
-         40001(   ; digest
+         40001(   / digest /
             h'4d303dac9eed63573f6190e9c4191be619e03a7b3c21e9bb3d27ac1a55971e6b'
          )
       ]