[Cbor] Re: NOT removing bactick-delimited strings (was Re: Remove rawstring extensions from CDN (draft-ietf-cbor-edn-literals))

[Vadim Goncharov <[e-mail]>]

On Mon, 10 Aug 2026 05:48:40 -0400
Rohan Mahy <[e-mail]> wrote:

> Hi All,
> To clarify, my proposal below does NOT remove backtick-delimited strings as
> an alternative to double-quoted strings. It just makes them not
> app-prefixed strings. There is no loss of functionality.
> 
> copying the Why:
> 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/ .

But you can't write sql'SELECT foo, 'const' FROM t WHERE bar ='a' and baz > 2'
while sql`` will allow this, and that's the entire reason for `` to exist and
why it was introduced half a year ago per mine request EXACTLY to avoid
backslash-hell.

Thus, -1, it is crucial feature.

> On Sun, 9 Aug 2026, 18:57 Rohan Mahy, <[e-mail]> wrote:
> 
> > 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]
> >>
> >>  



-- 
WBR, @nuclight