[Cbor] Re: Remove rawstring extensions from CDN (draft-ietf-cbor-edn-literals)

[Rohan Mahy <[e-mail]>]

Hi,

*What needs to be removed?*
*Remove*:
- Table 3, 4th entry
- app-rstring from bstr production in Section 6.1
- definition of app-rstring production in Section 6.1

Section 2.3 3rd ¶
Many strings are best notated as prefixed literals, which may provide
detailed access to the bits within those bytes (see Section 3.1
<https://www.ietf.org/archive/id/draft-ietf-cbor-edn-literals-27.html#encoded-byte-strings>).
Using an app-extension prefix, prefixed literals can be constructed out of
single-quoted strings and raw strings, as well as sequence literals
(cf. Section
3
<https://www.ietf.org/archive/id/draft-ietf-cbor-edn-literals-27.html#app-lit>
).

Section 2.3.2 last ¶
Single-quoted pPrefixed string literals (whether single-quoted after the
prefix or a raw string (Section 2.3.3)) are used for prefixed literals (see
Section 3, such as base-encoded byte string literals (see Section 3.1).
(Additional kinds of base-encoded string literals can be defined as
prefixed literals by registering their prefixes; there is no fundamental
difference between the original two predefined base-encoded string literal
prefixes (Section 3.1: h, b64) and any such potential future extension
literal prefixes; for simplicity of expression, both cases are referred to
as "prefixed literals".)

Section 3 swap quotes.
The string-based forms use their string literal as a shorthand form for a
sequence literal representing a sequence with exactly that one text string
data item, e.g., b64`'Zm9v`' is a shorthand for b64<<"Zm9v">> or
b64<<`Zm9v`>> (this specific example obviously depends on Zm9v being
allowed and meaning the same within the different forms of string literals
used in the example).

Section 3, 3rd paragraph from the last:
When the prefix is used immediately in front of a single-quoted or a raw
string, the input takes the form of a single text string CBOR data item
(this is useful only if the app-extension is designed to receive a text
string as input). When used immediately in front of a sequence literal, the
input is a CBOR sequence of elements of the sequence literal as input. (For
a single parameter, this is equivalent to receiving a single CBOR data item
as the argument.) The app-extension can provide behavior that depends on
the number of items supplied as input to it and their data types; it cannot
distinguish between its prefix being used with a single-quoted string, a
raw string, or a CBOR sequence composed of a single text string data item
(as illustrated for instance in Tables 3
<https://www.ietf.org/archive/id/draft-ietf-cbor-edn-literals-27.html#tab-equiv-dt>,
4
<https://www.ietf.org/archive/id/draft-ietf-cbor-edn-literals-27.html#tab-equiv-ip>,
and 5
<https://www.ietf.org/archive/id/draft-ietf-cbor-edn-literals-27.html#tab-equiv-hash>
).

Section 3.1 1st ¶, remove everything from "when using single-quoted, or..."


*Why should this be removed?*
Currently -27 allows app-prefixed rawstring extensions. We already have
app-prefixed extensions using << >> and using ' '. We don't need a third
variation of app-extensions.

Instead of writing h``012345 /don't forget/ `` you can already write
h<<``012345
/don't forget/ ``>>   or   h'012345' /don't forget/  .

*How could we add this later?*
This would simply require the new grammar to tolerate wordchars (other than
the four reserved words) before backtick-quoted strings. EDN
implementations conforming to the base spec (that did not support
the feature) would give an error.

Thanks,
-rohan


On Tue, 4 Aug 2026, 18:04 Christian Amsüss, <[e-mail]> wrote:

> Hello CBOR group,
>
> as discussed on list[1] and in the meeting[2], we are entering a phase
> of removing features from CDN that prevent it from reaching rough
> working group consensus.
>
> Opening a thread
> ----------------
>
> For every feature you object to (or, as per [1]#6, you consider
> incomplete), please send a mail to the list
>
> - in reply to this mail,
>
> - with the subject of the pattern "Remove ... from CDN
>   (draft-ietf-cbor-edn-literals)"
>
> - with text on what is to be removed, and from where in the document
>   (no need for a full editorial clean-up on each and every reference,
>   but including points where there are feature interactions and how
>   those are to be resolved)
>
> - giving the technical reason why this should be removed (or a pointer
>   to an on-list mail)
>
> - indicate how the feature can be added later as per [1]#2 (no need for a
>   full plan, a sketch suffices)
>
> If you think it helps the clarity of the proposal (esp. on feature
> interactions), you can open a pull request at [3] and link it. This does
> not replace any of the above, but can help preempt clarifying questions,
> and can help show that indeed it is a well-scoped excision.
>
> Responding to a thread
> ----------------------
>
> If you support a removal (and we need more than just the original
> proponent as per [1]#2), respond to the proposing mail briefly to state
> that.
>
> Refrain from pointing out disagreement on the list (or any corresponding
> PR): the arguments have been had. Pointers to feature interactions that
> were missed are appreciated, as are clarifying questions if interactions
> are missed or would be unclear after the removal. Be reminded to act in
> good faith here; more conretely, don't just ask to re-start already
> documented arguments.
>
>
> Both for opening and responding to a thread, please take the time to
> revisit past arguments, consider them, and enhance your text
> accordingly.
>
>
> Best regards
> Christian
> as a working group chair
>
> [1]:
> https://mailarchive.ietf.org/arch/msg/cbor/tMMMTMgqX0r963HFPikOGQvO0Vo
> [2]: https://datatracker.ietf.org/meeting/126/session/cbor
> [3]: https://github.com/cbor-wg/edn/pulls
>
>
> --
> Beware paths which narrow future possibilities. Such paths divert you
> from infinity into lethal traps.
>   -- Leto Atreides II
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>