@cbortech/cbor 0.26.8 → 0.27.0

package/README.ja.md

@@ -385,18 +385,22 @@ CBOR.format("h'68' + b64'aQ'", {
 //   b64'aQ'
 ```
 
-### application-string / -sequence 記法を保持する
+保持した連結を `+` ではなく draft-27 の `t1<<...>>` / `b1<<...>>` 記法で
+出力するには、[文字列連結と不定長文字列](#文字列連結と不定長文字列) の
+`modernConcat` を参照してください。
+
+### app-string / -sequence 記法を保持する
 
 一部の組み込み拡張(`dt`/`DT`、`ip`/`IP`)は同じ値に対して `prefix'...'`
-(application string)、`` prefix`...` ``(backtick application string)、
-`prefix<<...>>`(application sequence)、生のタグリテラル(`N(...)`)の
+(app-string)、`` prefix`...` ``(backtick app-string)、
+`prefix<<...>>`(app-sequence)、生のタグリテラル(`N(...)`)の
 いずれの記法もサポートしていますが、デフォルトでは `CBOR.format()` を呼ぶ
 たびに解決済みの値から `prefix'...'` を再生成します。そのため
 `` DT`1969-07-21T02:56:16Z` `` も `DT<<'1969-07-21T02:56:16Z'>>` も、生の
 タグ記法 `1(1749772800)` さえも、すべて `DT'...'` 記法に正規化され、さら
 に非正規な `DT'...'` の表記(例えば `Z` の代わりに `+00:00` を使った場合
-など)も書き換えられます。`preserveAppSequence` を指定すると、実際に使わ
-れていた表記のまま保持します。`appStrings: false` を同時に指定した場合は
+など)も書き換えられます。`preserveAppPrefix` を指定すると、実際に使わ
+れていた表記のまま保持します。`appPrefix: false` を同時に指定した場合は
 効果がありません(どちらにせよ元の表記に関わらず生のタグ記法になるため)。
 これらの記法からパースされていない値にも効果はありません。
 
@@ -406,16 +410,50 @@ import { CBOR } from '@cbortech/cbor';
 CBOR.format('1(1749772800)');
 // "DT'2025-06-13T00:00:00Z'"
 
-CBOR.format('1(1749772800)', { preserveAppSequence: true });
+CBOR.format('1(1749772800)', { preserveAppPrefix: true });
 // "1(1749772800)"
 
-CBOR.format("DT<<'1969-07-21T02:56:16Z'>>", { preserveAppSequence: true });
+CBOR.format("DT<<'1969-07-21T02:56:16Z'>>", { preserveAppPrefix: true });
 // "DT<<'1969-07-21T02:56:16Z'>>"
 
-CBOR.format('DT`1969-07-21T02:56:16Z`', { preserveAppSequence: true });
+CBOR.format('DT`1969-07-21T02:56:16Z`', { preserveAppPrefix: true });
 // "DT`1969-07-21T02:56:16Z`"
 ```
 
+### コメントを保持する
+
+デフォルトでは、`CBOR.fromCDN()` はコメントを破棄し、`CBOR.format()` も
+コメントを出力しません。`preserveComments: true` を指定すると、パース時に
+コメントを取り込み、元々書かれていたマーカー(`#`・`//`・`/* */`・`/ /`)の
+まま再出力します。
+
+```ts
+import { CBOR } from '@cbortech/cbor';
+
+const text = '{ "a": 1 } # trailing comment';
+
+CBOR.format(text, { indent: 2 });
+// '{\n  "a": 1\n}'
+
+CBOR.format(text, { indent: 2, preserveComments: true });
+// '{\n  "a": 1\n} # trailing comment'
+```
+
+書かれていたマーカーを混在させたまま保持するのではなく、すべてのコメントの
+マーカーを正規化したい場合は `comments` を使います — `'c-style'` は
+`//` と `/* */`、`'cdn-style'` は `#` と `/ /` に正規化します。
+`preserveComments: true` が指定されている場合は効果がありません(verbatim
+が優先されます)。コメントを完全に削除するには `comments: 'strip'` を
+明示的に指定するか(あるいは両方とも未指定のままにするか)します。
+
+```ts
+CBOR.format(text, { indent: 2, comments: 'c-style' });
+// '{\n  "a": 1\n} // trailing comment'
+```
+
+`indent` を指定して整形出力する場合のみ効果があります。1 行出力では改行で
+終端する必要がある行コメントの性質上、コメントは常に取り除かれます。
+
 ### 空行を保持する
 
 デフォルトでは、`CBOR.format()` は配列・マップの要素間(および `(_ ...)`
@@ -672,7 +710,7 @@ console.log(text);
 
 ## 文字列連結と不定長文字列
 
-draft-ietf-cbor-edn-literals-26(§3.4 / §3.5)の application extension
+draft-ietf-cbor-edn-literals-27(§3.5 / §3.6)の app-extension
 `t1` / `b1` / `ilbs` / `ilts` は、デフォルトで有効です。
 
 `t1<<...>>` と `b1<<...>>` は、(テキストまたはバイト)文字列の引数を左から
@@ -683,11 +721,11 @@ draft-ietf-cbor-edn-literals-26(§3.4 / §3.5)の application extension
 import { CBOR } from '@cbortech/cbor';
 
 const text = CBOR.fromCDN('t1<<"Hello ", "world">>');
-console.log(text.toCDN({ appStrings: false }));
+console.log(text.toCDN({ appPrefix: false }));
 // "Hello world"
 
 const bytes = CBOR.fromCDN("b1<<'Hello ', h'776f726c64'>>");
-console.log(bytes.toCDN({ appStrings: false }));
+console.log(bytes.toCDN({ appPrefix: false }));
 // 'Hello world'
 ```
 
@@ -701,29 +739,82 @@ streamstring 構文の置き換えですが、本ライブラリは従来構文
 import { CBOR } from '@cbortech/cbor';
 
 const v = CBOR.fromCDN("ilbs<<'Hello ', 'world'>>");
-console.log(v.toCDN({ appStrings: false }));
+console.log(v.toCDN({ appPrefix: false }));
 // (_ 'Hello ','world')
 ```
 
+### `t1`/`b1`/`ilbs`/`ilts` 記法を出力する
+
+パース側はすでに `t1`/`b1`/`ilbs`/`ilts` 記法を受理しますが、`toCDN()` /
+`CBOR.format()` はデフォルトではこれらを自ら出力しません。保持した連結
+(`preserveConcatenation`)は従来どおり `+` で、不定長文字列は従来どおり
+`(_ ...)` streamstring 形式でレンダリングされます。`modernConcat` と
+`modernStreamSyntax` を `true` にすると draft-27 の記法での出力を選択でき
+ます。どちらもデフォルトは `false`(従来構文)で、`appPrefix` が `false`
+の場合は従来構文にフォールバックします。
+
+```ts
+import { CBOR } from '@cbortech/cbor';
+
+CBOR.format('"a" + "b"', {
+  indent: 2,
+  preserveConcatenation: true,
+  modernConcat: true,
+});
+// t1<<"a", "b">>
+
+CBOR.format('(_ "a", "b")', { modernStreamSyntax: true });
+// ilts<<"a","b">>
+```
+
+`modernConcat` は `...` による省略連結(§5.2)にも適用され、
+`"a" + ... + "b"` は `t1<<"a", ..., "b">>` としてレンダリングされます。
+通常の連結と異なり、これは `preserveConcatenation` の値に関わらず適用され
+ます — 省略連結にはそもそも1つのリテラルに畳み込んだ状態が存在しないため
+です。
+
+> [!NOTE]
+> どちらのオプションも `t1`/`b1`/`ilbs`/`ilts` のソースを従来記法に
+> 変換するものではありません。`t1<<...>>`(や `ilbs<<...>>` など)
+> からパースされた値は、`appPrefix` が `false` でなく、
+> `encodingIndicators` が `'auto'`(どちらもデフォルト)であり、かつ
+> ソースが単一行、または `indent` 指定時であれば、`modernConcat` /
+> `modernStreamSyntax` の値に関わらずそのままの記法で出力されます。
+> `encodingIndicators: 'always'`/`'never'` や `appPrefix: false` を指定
+> した場合は、他の app-string 値と同様に正規化されます(例:
+> `encodingIndicators: 'always'` では `t1<<"a", "b">>` が `"ab"_i` に
+> なります)。また、複数行のソースは `indent` 未指定(1行出力)の場合、
+> そのレイアウトを再現できないため正規化されます:
+>
+> ```ts
+> CBOR.format('t1<<\n  "a",\n  "b"\n>>');
+> // '"ab"' — indent未指定のため正規化される
+> CBOR.format('t1<<\n  "a",\n  "b"\n>>', { indent: 2 });
+> // 't1<<\n  "a",\n  "b"\n>>' — そのまま保持される
+> ```
+>
+> 両オプションが影響するのは `+` チェーンや `(_ ...)` チャンク列から
+> 再構築された値の出力のみです。
+
 > [!NOTE]
-> `t1` / `b1` という識別子は draft-26 で暫定(provisional)と明記されて
+> `t1` / `b1` という識別子は draft-27 でも暫定(provisional)と明記されて
 > おり、CBOR ワーキンググループにより改名される可能性があります。
 
 ## float
 
 16 進数のビットパターンを IEEE 754 浮動小数点値として解釈します
-(draft-ietf-cbor-edn-literals-26 §3.7)。デフォルトで有効です。
+(draft-ietf-cbor-edn-literals-27 §3.8)。デフォルトで有効です。
 
 ```ts
 import { CBOR } from '@cbortech/cbor';
 
 const v = CBOR.fromCDN("float'7e00'");
-console.log(v.toCDN({ appStrings: false }));
+console.log(v.toCDN({ appPrefix: false }));
 // NaN
 
 // バイト列から解釈する場合
 const v2 = CBOR.fromCDN("float<<h'3f800000'>>");
-console.log(v2.toCDN({ appStrings: false }));
+console.log(v2.toCDN({ appPrefix: false }));
 // 1.0_2
 ```
 
@@ -736,7 +827,7 @@ extension があります。必要なものを `import` し、
 ### b32 / h32
 
 [RFC 4648](https://www.rfc-editor.org/rfc/rfc4648) の Base32 エンコードによるバイト列リテラルです。
-[RFC 8949](https://www.rfc-editor.org/rfc/rfc8949) §8 に記載があり、[draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/25/) でも触れられています。
+[RFC 8949](https://www.rfc-editor.org/rfc/rfc8949) §8 に記載があり、[draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/27/) でも触れられています。
 
 - `b32` — §6 Base32（`A–Z 2–7` アルファベット）
 - `h32` — §7 Base32Hex（`0–9 A–V` アルファベット）
@@ -745,11 +836,11 @@ extension があります。必要なものを `import` し、
 import { CBOR, b32, h32 } from '@cbortech/cbor';
 
 const v1 = CBOR.fromCDN("b32'AEBAGBA'", { extensions: [b32] });
-console.log(v1.toCDN({ appStrings: false }));
+console.log(v1.toCDN({ appPrefix: false }));
 // h'01020304'
 
 const v2 = CBOR.fromCDN("h32'00P00'", { extensions: [h32] });
-console.log(v2.toCDN({ appStrings: false }));
+console.log(v2.toCDN({ appPrefix: false }));
 // h'003200'
 ```
 
@@ -763,25 +854,24 @@ console.log(v2.toCDN({ appStrings: false }));
 ```ts
 import { CBOR, same } from '@cbortech/cbor';
 
-// すべての要素が同じバイト列かを検証し、最初の要素を返す
 const v = CBOR.fromCDN("same<<h'0102', h'0102'>>", { extensions: [same] });
-console.log(v.toCDN({ appStrings: false }));
+console.log(v.toCDN({ appPrefix: false }));
 // h'0102'
 
 // 要素が 1 つでも有効（常にパスする）
 const v2 = CBOR.fromCDN('same<<42>>', { extensions: [same] });
-console.log(v2.toCDN({ appStrings: false }));
+console.log(v2.toCDN({ appPrefix: false }));
 // 42
 ```
 
 ---
 
-追加の application extension は別パッケージとして公開されています。必要なものを
+追加の app-extension は別パッケージとして公開されています。必要なものを
 インストールし、`extensions` オプションに渡して使います。
 
 ### hash
 
-`hash` は [draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/25/) §3.3 で定義された標準の application extension です。
+`hash` は [draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/27/) §3.4 で定義された標準の app-extension です。
 ハッシュアルゴリズムと値を `hash'algorithm:value'` の形式で表現します。
 実装には外部の暗号ライブラリが必要なため、[@cbortech/hash-extension](https://www.npmjs.com/package/@cbortech/hash-extension) として
 別パッケージで提供しています。
@@ -806,7 +896,7 @@ const digest = cbor.parse(
 
 ### uuid
 
-`uuid` はこのライブラリ独自の application extension です。
+`uuid` はこのライブラリ独自の app-extension です。
 [@cbortech/uuid-extension](https://www.npmjs.com/package/@cbortech/uuid-extension) として別パッケージで提供しています。
 
 ```bash
@@ -826,7 +916,7 @@ const id = cbor.parse("uuid'550e8400-e29b-41d4-a716-446655440000'");
 ### set / map
 
 `SET` と `MAP` は、タグ付きの Set / Map 値を扱うための、このライブラリ独自の
-application extension です。
+app-extension です。
 [@cbortech/set-map-extensions](https://www.npmjs.com/package/@cbortech/set-map-extensions)
 としてまとめて別パッケージで提供しています。`SET<<[...]>>` は配列に CBOR tag
 258 を付けた値、`MAP<<{...}>>` は map に CBOR tag 259 を付けた値を生成します。
@@ -1083,9 +1173,11 @@ CDDL コンパイラは `@cbortech/cbor/cddl`
 
 - CBOR
   - [RFC 8949](https://www.rfc-editor.org/rfc/rfc8949)
+- CBOR Sequences
+  - [RFC 8742](https://www.rfc-editor.org/rfc/rfc8742)
 - CDN (CBOR-EDN)
   - [draft-ietf-cbor-edn-literals-25](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/25/)
-  - [draft-ietf-cbor-edn-literals-26](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/26/)
+  - [draft-ietf-cbor-edn-literals-27](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/27/)
 - CDDL
   - [RFC 8610](https://www.rfc-editor.org/rfc/rfc8610)
   - [RFC 9682](https://www.rfc-editor.org/rfc/rfc9682)
@@ -1093,7 +1185,7 @@ CDDL コンパイラは `@cbortech/cbor/cddl`
 
 補足:
 
-- CDN は draft-26 に準拠しつつ、draft-25 の `(_ ...)` streamstring 構文と
+- CDN は draft-27 に準拠しつつ、draft-25 の `(_ ...)` streamstring 構文と
   `+` による文字列連結構文も引き続きサポートしています。
 - CDDL は RFC 8610 のすべての control operator と、RFC 9165 の `.plus`、
   `.cat`、`.feature` をサポートしています。

package/README.md

@@ -392,19 +392,23 @@ CBOR.format("h'68' + b64'aQ'", {
 //   b64'aQ'
 ```
 
-### Preserve application-string/-sequence notation
+To render the preserved concatenation using draft-27's `t1<<...>>` /
+`b1<<...>>` notation instead of `+`, see `modernConcat` in
+[String Concatenation and Indefinite-Length Strings](#string-concatenation-and-indefinite-length-strings).
+
+### Preserve app-string/-sequence notation
 
 Some built-in extensions (`dt`/`DT`, `ip`/`IP`) support `prefix'...'`
-(application string), `` prefix`...` `` (backtick application string),
-`prefix<<...>>` (application sequence), and a raw tag literal (`N(...)`)
+(app-string), `` prefix`...` `` (backtick app-string),
+`prefix<<...>>` (app-sequence), and a raw tag literal (`N(...)`)
 notation for the same value, and by default regenerate `prefix'...'` from
 the resolved value on every `CBOR.format()` call — so
 `` DT`1969-07-21T02:56:16Z` ``, `DT<<'1969-07-21T02:56:16Z'>>`, and even the
 raw tag form `1(1749772800)` all normalize to `DT'...'` notation, and a
 non-canonical `DT'...'` spelling (e.g. a `+00:00` offset instead of `Z`)
-gets rewritten too. `preserveAppSequence` keeps the original spelling
+gets rewritten too. `preserveAppPrefix` keeps the original spelling
 instead — whichever form was used. It has no effect when
-`appStrings: false` is also set (raw tag notation is used either way
+`appPrefix: false` is also set (raw tag notation is used either way
 regardless of the original spelling), or on values not parsed from one of
 these forms.
 
@@ -414,16 +418,50 @@ import { CBOR } from '@cbortech/cbor';
 CBOR.format('1(1749772800)');
 // "DT'2025-06-13T00:00:00Z'"
 
-CBOR.format('1(1749772800)', { preserveAppSequence: true });
+CBOR.format('1(1749772800)', { preserveAppPrefix: true });
 // "1(1749772800)"
 
-CBOR.format("DT<<'1969-07-21T02:56:16Z'>>", { preserveAppSequence: true });
+CBOR.format("DT<<'1969-07-21T02:56:16Z'>>", { preserveAppPrefix: true });
 // "DT<<'1969-07-21T02:56:16Z'>>"
 
-CBOR.format('DT`1969-07-21T02:56:16Z`', { preserveAppSequence: true });
+CBOR.format('DT`1969-07-21T02:56:16Z`', { preserveAppPrefix: true });
 // "DT`1969-07-21T02:56:16Z`"
 ```
 
+### Preserve comments
+
+By default, `CBOR.fromCDN()` discards comments and `CBOR.format()` emits
+none. `preserveComments: true` captures them while parsing and re-emits each
+comment verbatim, with whichever marker (`#`, `//`, `/* */`, `/ /`) it was
+originally written with.
+
+```ts
+import { CBOR } from '@cbortech/cbor';
+
+const text = '{ "a": 1 } # trailing comment';
+
+CBOR.format(text, { indent: 2 });
+// '{\n  "a": 1\n}'
+
+CBOR.format(text, { indent: 2, preserveComments: true });
+// '{\n  "a": 1\n} # trailing comment'
+```
+
+To normalize every comment's marker instead of keeping the mix as originally
+written, use `comments` — `'c-style'` for `//` and `/* */`, or
+`'cdn-style'` for `#` and `/ /`. It has no effect when `preserveComments` is
+`true` (verbatim wins); explicitly set `comments: 'strip'` (or leave
+both options unset) to drop comments entirely.
+
+```ts
+CBOR.format(text, { indent: 2, comments: 'c-style' });
+// '{\n  "a": 1\n} // trailing comment'
+```
+
+Only effective when `indent` enables pretty-printing: single-line output
+strips all comments regardless, since line comments can only be terminated
+by a newline.
+
 ### Preserve blank lines
 
 By default, `CBOR.format()` drops blank lines between array/map entries (and
@@ -683,8 +721,8 @@ console.log(text);
 
 ## String Concatenation and Indefinite-Length Strings
 
-The `t1` / `b1` / `ilbs` / `ilts` application extensions from
-draft-ietf-cbor-edn-literals-26 (§3.4 / §3.5) are enabled by default.
+The `t1` / `b1` / `ilbs` / `ilts` app-extensions from
+draft-ietf-cbor-edn-literals-27 (§3.5 / §3.6) are enabled by default.
 
 `t1<<...>>` and `b1<<...>>` join (text or byte) string arguments from left to
 right into a single text string (`t1`) or byte string (`b1`). Arguments may
@@ -694,11 +732,11 @@ also be ellipses (`...`) to elide parts of a string.
 import { CBOR } from '@cbortech/cbor';
 
 const text = CBOR.fromCDN('t1<<"Hello ", "world">>');
-console.log(text.toCDN({ appStrings: false }));
+console.log(text.toCDN({ appPrefix: false }));
 // "Hello world"
 
 const bytes = CBOR.fromCDN("b1<<'Hello ', h'776f726c64'>>");
-console.log(bytes.toCDN({ appStrings: false }));
+console.log(bytes.toCDN({ appPrefix: false }));
 // 'Hello world'
 ```
 
@@ -711,29 +749,81 @@ documents; this library keeps accepting the legacy syntax on input.
 import { CBOR } from '@cbortech/cbor';
 
 const v = CBOR.fromCDN("ilbs<<'Hello ', 'world'>>");
-console.log(v.toCDN({ appStrings: false }));
+console.log(v.toCDN({ appPrefix: false }));
 // (_ 'Hello ','world')
 ```
 
+### Emitting `t1`/`b1`/`ilbs`/`ilts` notation
+
+Parsing already accepts `t1`/`b1`/`ilbs`/`ilts` notation, but by default
+`toCDN()`/`CBOR.format()` never emit it on their own: a preserved
+concatenation (`preserveConcatenation`) still renders as `+`, and an
+indefinite-length string still renders as the legacy `(_ ...)` streamstring
+form. `modernConcat` and `modernStreamSyntax` opt into emitting the draft-27
+notation instead — both default to `false` (the legacy syntax), and both fall
+back to it when `appPrefix` is `false`.
+
+```ts
+import { CBOR } from '@cbortech/cbor';
+
+CBOR.format('"a" + "b"', {
+  indent: 2,
+  preserveConcatenation: true,
+  modernConcat: true,
+});
+// t1<<"a", "b">>
+
+CBOR.format('(_ "a", "b")', { modernStreamSyntax: true });
+// ilts<<"a","b">>
+```
+
+`modernConcat` also applies within a `...` elision chain (§5.2), rendering
+`"a" + ... + "b"` as `t1<<"a", ..., "b">>` — unlike plain concatenation, this
+happens regardless of `preserveConcatenation`, since an elision chain has no
+single-literal collapsed form to fall back to in the first place.
+
+> [!NOTE]
+> Neither option converts `t1`/`b1`/`ilbs`/`ilts` source back to the
+> legacy notation: a value parsed from `t1<<...>>` (or `ilbs<<...>>`, etc.)
+> keeps that exact spelling on output regardless of `modernConcat` /
+> `modernStreamSyntax` — as long as `appPrefix` is not `false`,
+> `encodingIndicators` is `'auto'` (both defaults), and the source is either
+> single-line or being rendered with `indent` enabled. `encodingIndicators:
+'always'`/`'never'` or `appPrefix: false` still normalize it like any
+> other app-string value (e.g. `t1<<"a", "b">>` becomes `"ab"_i`
+> under `encodingIndicators: 'always'`), and a multi-line source falls back
+> to normalized output in single-line mode (that layout can't be reproduced
+> without `indent`):
+>
+> ```ts
+> CBOR.format('t1<<\n  "a",\n  "b"\n>>');
+> // '"ab"' — falls back: multi-line source, no `indent`
+> CBOR.format('t1<<\n  "a",\n  "b"\n>>', { indent: 2 });
+> // 't1<<\n  "a",\n  "b"\n>>' — kept verbatim
+> ```
+>
+> Both options only affect how a value reconstructed from a `+` chain or a
+> `(_ ...)` chunk list is _newly_ rendered.
+
 > [!NOTE]
-> The identifiers `t1` and `b1` are explicitly provisional in draft-26 and
+> The identifiers `t1` and `b1` are explicitly provisional in draft-27 and
 > may be renamed by the CBOR working group.
 
 ## float
 
 Interprets a hex bit-pattern as an IEEE 754 floating-point value
-(draft-ietf-cbor-edn-literals-26 §3.7). Enabled by default.
+(draft-ietf-cbor-edn-literals-27 §3.8). Enabled by default.
 
 ```ts
 import { CBOR } from '@cbortech/cbor';
 
 const v = CBOR.fromCDN("float'7e00'");
-console.log(v.toCDN({ appStrings: false }));
+console.log(v.toCDN({ appPrefix: false }));
 // NaN
 
 // Interpret bytes as float bits
 const v2 = CBOR.fromCDN("float<<h'3f800000'>>");
-console.log(v2.toCDN({ appStrings: false }));
+console.log(v2.toCDN({ appPrefix: false }));
 // 1.0_2
 ```
 
@@ -747,7 +837,7 @@ default. Import what you need and pass it through the `extensions` option.
 Byte-string literals using [RFC 4648](https://www.rfc-editor.org/rfc/rfc4648)
 Base32 encoding. These prefixes are described in §8 of
 [RFC 8949](https://www.rfc-editor.org/rfc/rfc8949) and also mentioned in
-[draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/25/).
+[draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/27/).
 
 - `b32` — §6 Base32 (`A–Z 2–7` alphabet)
 - `h32` — §7 Base32Hex (`0–9 A–V` alphabet)
@@ -756,11 +846,11 @@ Base32 encoding. These prefixes are described in §8 of
 import { CBOR, b32, h32 } from '@cbortech/cbor';
 
 const v1 = CBOR.fromCDN("b32'AEBAGBA'", { extensions: [b32] });
-console.log(v1.toCDN({ appStrings: false }));
+console.log(v1.toCDN({ appPrefix: false }));
 // h'01020304'
 
 const v2 = CBOR.fromCDN("h32'00P00'", { extensions: [h32] });
-console.log(v2.toCDN({ appStrings: false }));
+console.log(v2.toCDN({ appPrefix: false }));
 // h'003200'
 ```
 
@@ -774,24 +864,24 @@ identical CBOR bytes and returns the first item. This extension is described in
 import { CBOR, same } from '@cbortech/cbor';
 
 const v = CBOR.fromCDN("same<<h'0102', h'0102'>>", { extensions: [same] });
-console.log(v.toCDN({ appStrings: false }));
+console.log(v.toCDN({ appPrefix: false }));
 // h'0102'
 
 // A single-item sequence always passes
 const v2 = CBOR.fromCDN('same<<42>>', { extensions: [same] });
-console.log(v2.toCDN({ appStrings: false }));
+console.log(v2.toCDN({ appPrefix: false }));
 // 42
 ```
 
 ---
 
-Additional application extensions are published as separate packages. Install
+Additional app-extensions are published as separate packages. Install
 the ones you need and pass them through the `extensions` option.
 
 ### hash
 
-`hash` is an application extension defined in §3.3 of
-[draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/25/).
+`hash` is an app-extension defined in §3.4 of
+[draft-ietf-cbor-edn-literals](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/27/).
 It represents cryptographic hash values in the form `hash'algorithm:value'`.
 Because it requires an external cryptographic library, it is provided separately
 as [@cbortech/hash-extension](https://www.npmjs.com/package/@cbortech/hash-extension).
@@ -816,7 +906,7 @@ const digest = cbor.parse(
 
 ### uuid
 
-`uuid` is a library-specific application extension, provided separately as
+`uuid` is a library-specific app-extension, provided separately as
 [@cbortech/uuid-extension](https://www.npmjs.com/package/@cbortech/uuid-extension).
 
 ```bash
@@ -835,7 +925,7 @@ const id = cbor.parse("uuid'550e8400-e29b-41d4-a716-446655440000'");
 
 ### set / map
 
-`SET` and `MAP` are library-specific application extensions for tagged Set and
+`SET` and `MAP` are library-specific app-extensions for tagged Set and
 Map values. They are provided together as
 [@cbortech/set-map-extensions](https://www.npmjs.com/package/@cbortech/set-map-extensions).
 `SET<<[...]>>` produces CBOR tag 258 over an array, and `MAP<<{...}>>` produces
@@ -1093,9 +1183,11 @@ types).
 
 - CBOR
   - [RFC 8949](https://www.rfc-editor.org/rfc/rfc8949)
+- CBOR Sequences
+  - [RFC 8742](https://www.rfc-editor.org/rfc/rfc8742)
 - CDN (CBOR-EDN)
   - [draft-ietf-cbor-edn-literals-25](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/25/)
-  - [draft-ietf-cbor-edn-literals-26](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/26/)
+  - [draft-ietf-cbor-edn-literals-27](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/27/)
 - CDDL
   - [RFC 8610](https://www.rfc-editor.org/rfc/rfc8610)
   - [RFC 9682](https://www.rfc-editor.org/rfc/rfc9682)
@@ -1103,7 +1195,7 @@ types).
 
 Implementation notes:
 
-- CDN follows draft-26 while retaining draft-25's `(_ ...)` streamstring syntax
+- CDN follows draft-27 while retaining draft-25's `(_ ...)` streamstring syntax
   and `+` string-concatenation syntax.
 - CDDL implements every RFC 8610 control operator, plus RFC 9165's `.plus`,
   `.cat`, and `.feature`.

package/dist/ast/CborAppSeqResult.d.ts

@@ -21,6 +21,28 @@ export declare class CborAppSeqResult extends CborItem {
     readonly ednSource: string;
     constructor(inner: CborItem, ednSource: string);
     get _containsCdnContainer(): boolean;
+    /**
+     * Same approach as `CborTag`: tokenize this wrapper's own `_toCDN()`
+     * output rather than delegating to `this.inner._isMultiWordText()`.
+     * Delegating to `this.inner` was tried and found wrong: for
+     * `ilbs<<h'68656c6c6f20776f726c64'>>`, the chunk's raw bytes decode to
+     * printable "hello world", so `this.inner`'s own semantic check reports
+     * it as multi-word — but the *actual* rendering is the preserved
+     * `ilbs<<...>>` app-sequence spelling, where that chunk appears as a
+     * `h'...'` literal, never as decoded text; the semantic prediction and
+     * the real output disagree. Tokenizing `this._toCDN()` directly sees
+     * whichever one actually happens: the preserved `ednSource` verbatim
+     * (`isMultiWordRenderedLiteral` peels the `prefix<<...>>` wrapper and
+     * checks each item under the loose rule, same as `<<...>>` — a
+     * multi-word text item like `ilts<<"two words">>` still always counts,
+     * a prefixed-literal item like `ilbs<<h'00'>>` does not) or, in the
+     * 'always'/'never' `encodingIndicators` modes, a pure passthrough to
+     * `this.inner._toCDN()` with no extra wrapping (any node needing that to
+     * be caught, like a self-disqualifying `CborIndefiniteByteString`, has
+     * already produced a `\n` in that string, which the caller's own
+     * `s.includes('\n')` check picks up independently either way).
+     */
+    _isMultiWordText(options: ToCDNOptions | undefined, strict?: boolean): boolean;
     _encodeTo(writer: CborWriter, options?: ToCBOROptions): void;
     _toCDN(options: ToCDNOptions | undefined, depth: number): string;
     _toJS(options?: ToJSOptions): unknown;

package/dist/ast/CborByteString.d.ts

@@ -48,6 +48,22 @@ export declare class CborByteString extends CborItem {
         ednCommentSyntax?: ByteCommentSyntax;
         ednParts?: readonly CborByteStringPart[];
     });
+    /**
+     * Only the "bare sqstr text with 2+ words" case — the "is this a
+     * prefixed literal" question is deliberately *not* predicted here from
+     * raw bytes at all (a subclass like `CborIpExt` might override `_toCDN()`
+     * to render something else entirely, e.g. a preserved
+     * `ip<<'192.0.2.42'>>` app-sequence spelling, that raw-byte prediction
+     * knows nothing about — see `isMultiWordByteString`'s doc). That
+     * question is instead answered from the *actual rendering*: for a bare
+     * entry, `serializeContainer`'s own `isPrefixedLiteralText(s)` check
+     * already covers it (this node's render *is* `s`, unobscured); for one
+     * wrapped in a `CborTag`, `CborTag._isMultiWordText`'s
+     * `isMultiWordRenderedLiteral` check covers it instead. `strict` isn't
+     * needed here at all now — it's accepted purely for interface
+     * consistency with the base class.
+     */
+    _isMultiWordText(options: ToCDNOptions | undefined, _strict?: boolean): boolean;
     _encodeTo(writer: CborWriter, _options?: ToCBOROptions): void;
     _toCDN(options: ToCDNOptions | undefined, _depth: number): string;
     _toJS(_options?: ToJSOptions): unknown;

package/dist/ast/CborEmbeddedCBOR.d.ts

@@ -2,7 +2,7 @@ import { ToCDNOptions, ToJSOptions, ToCBOROptions } from '../types';
 import { CborItem, AnnotatedLine } from './CborItem';
 import { CborWriter, EncodingWidth } from '../cbor/encode';
 /**
- * CBOR Sequence Literal (§2.5.6) — `<<item, item, ...>>`.
+ * CBOR Sequence Literal (§2.3.4) — `<<item, item, ...>>`.
  *
  * Encodes as a definite-length byte string whose value is the concatenation
  * of the CBOR encodings of the contained items.

package/dist/ast/CborFloat.d.ts

@@ -22,7 +22,7 @@ export declare class CborFloat extends CborItem {
     /**
      * Original app-string source (e.g. `float'7e00'`), set by the parser when
      * this float is the result of a `float'...'` app-string.  Used by toCDN()
-     * to round-trip the literal when `appStrings` is not false.
+     * to round-trip the literal when `appPrefix` is not false.
      */
     ednSource?: string;
     /**