[Cbor] Re: on EDN pragmas/version - to remove controversial from -26

[Vadim Goncharov <[e-mail]>]

On Fri, 12 Jun 2026 12:29:02 -0600
Joe Hildebrand <[e-mail]> wrote:

> The goal for a lot of these is to fail fast at the beginning of ingest if
> the tool doesn't support the desired mode, and so that each document can
> have a different set of settings, I assume.  I also assume that these all
> need to be at the top of the input, so that they can't change midway through
> processing, since that would be a real pain.  

I can imagine for *some* settings to be changed in-middle or several times,
just like it is possible with pragmas in C - most often to be used for
blocks like

#pragma diagnostic <somefeature> off
...some legacy code goes here with no time to rewrite...
#pragma diagnostic <somefeature> on

but of course not for all, probably not even for most.

> It also seems (to Carsten's
> security point) that these all only occur in inputs that come from trusted
> sources, since configuring the extensions needed (including a URL to their
> implementation, if in a web context) is not something you want an attacker
> to control.

The idea here was taken from JSON SChema or JSON LD or even XML schemas when
one real document referres to some other real document. However, actual going
to such URLs should be of course disabled (at least by default) because even
DoS attacks can happen, see for more detail:
https://datatracker.ietf.org/doc/draft-bormann-t2trg-deref-id/

> At that point, whether these are inline as pragma<<>>, a configuration for
> the EDN parser or generator, or a configuration file for the EDN
> processor/generator seem like just different knobs to tweak to achieve the
> same effects.  The big difference is the tradeoff between per-document
> configuration in trusted inputs and the security downsides of allowing this
> for untrusted inputs.

Well, one still needs to tell for e.g. e'' extension from which CDDL document
to take definitions. Be that limited to just file:// URLs or EDN processor
have some "database" of allowed CDDL documents (e.g. approved by admin) or
some other way of control - that's to think later, for now we discuss a pragma
mechanism as a needed pre-requisite to it. First step.

> I'll probably implement pragma<<>> if it has the constraints from above, but
> have it off by default to avoid the security issues.  Hopefully that will
> mean that pragma<<>> will fail with an error like "pragmas are disabled.
> enable them by...".

That's exactly what needed! I've proposed #pragma form so that 8610's EDN can
also fail seeing this, as they don't support #-style comments.

> — 
> Joe Hildebrand
> 
> > On Jun 12, 2026, at 3:55 AM, Rohan Mahy <[e-mail]> wrote:
> > 
> > Hi Joe,
> > Welcome back.
> > In the slides I presented Wednesday:
> > https://datatracker.ietf.org/meeting/interim-2026-cbor-11/materials/slides-interim-2026-cbor-11-sessa-edn-readability-etc-00.pdf
> > I gave some examples of the things we might need to express on slide 14:
> > 
> > In EDN to CBOR use cases:
> >     • extensions that need to be supported
> >     • for the e'' extension, the path to the corresponding CDDL file
> >     • if unknown extensions would be represented with stand-in tags
> > (default: no)
> >     • if ellipses would be converted to tags (default: no)
> >     • if maps would be presented in their order in the document, or in
> > some other order
> >     • if the document is allowed to include encoding indicators
> >     • if indefinite length encoding is allowed
> > In CBOR to EDN use cases:
> >     • any extensions that were used
> >     • if a particular CDDL document was used to parse the CBOR, a path to
> > it
> >     • if any items were elided and replaced with ellipses (ex: long bstrs)
> >     • if encoding indicators will be included for any non-preferred
> > encodings
> >     • the type of escaping done to legal unicode characters in text
> > strings, if any I hope this helps.
> > Thanks,
> > -rohan
> > 
> > 
> > On Thu, 11 Jun 2026, 21:12 Joe Hildebrand, <[e-mail]> wrote:
> > I missed a bunch of the discussion about pragmas, and so don't have a
> > great grasp over what the intended use cases are.  Do we have a list of
> > the things that are currently desired handy?
> > 
> > That being said, could we add these later with syntax like: 
> > 
> > pragma<<'commas', 'require'>>
> > 
> > In a doc that defines its own IANA registry?  That doc would need its own
> > Security Considerations section that was interesting, as well as requiring
> > all other registered pragmas to have thought about security in some way.
> > 
> > — 
> > Joe Hildebrand
> >   
> > > On Jun 10, 2026, at 11:08 PM, Rohan Mahy <[e-mail]> wrote:
> > > 
> > > Carsten,
> > > First of all, I find your tone inappropriate.
> > > draft-ietf-cbor-edn-literals is supposed to be a WG document. You have
> > > added dozens of new features since -18 (many without waiting for a
> > > consensus) and then you criticize the idea of adding processing
> > > instructions/pragmas because they weren't around for the past 13
> > > years—how rich.
> > > 
> > > The fact is that the more features we add to EDN, the more we have need
> > > of something like pragmas. A bazaar-style extensibility should have
> > > always had this feature. Deployment of e'' basically requires it.
> > > 
> > > - AFAIK, we do not require a feature in CBOR to have processing
> > > instructions (or at least not urgently).
> > > 
> > > - If you want the individual processing instructions to be in EDN
> > > format, that's fine. I'm happy to send a PR once we establish we want
> > > this feature.
> > > 
> > > I believe that a lot of WG participants think it is high time that we
> > > added a pragma-like mechanism. I believe we might already have rough
> > > consensus to do so. This email is an attempt to find out.
> > > 
> > > Carsten, rather than reply to each message in this thread individually,
> > > please *wait* and let others give their opinion about whether we need
> > > such functionality or not. You have already expressed yours.
> > > 
> > > thanks,
> > > -rohan
> > > 
> > > 
> > > On Wed, 10 Jun 2026, 18:32 Carsten Bormann, <[e-mail]> wrote:
> > > On 2026-06-10, at 18:07, Vadim Goncharov <[e-mail]>
> > > wrote:  
> > > > 
> > > > Metadata we put at the start of an EDN text (like a pragma?)  
> > > 
> > > I usually don’t like to give potential creators of attack data items
> > > direct access to the parameters that could control the attack.
> > > 
> > > (CBOR does not have “comments" in which a pragma could be lodged either.)
> > > 
> > > Now, as I said in
> > > Archived-At:
> > > <https://mailarchive.ietf.org/arch/msg/cbor/zghWLVr2sE_sIt1REi6Kbs5VFk8>,
> > > I think some good work could be done on finding common names for the
> > > elements of such a configuration (and writing them up on the wiki); this
> > > section just mentions that we have a certain “basic” configuration in
> > > mind that should work, possibly after applying a “--basic” flag.
> > > 
> > > There is no reason to tie the timeline of the (C)(E)DN specification to
> > > the timeline of work in this space; we have been able to work with DN
> > > for 13 years now without standardizing such a configuration parameter
> > > set.
> > > 
> > > There *is* a relationship to the “serialization” work, which to a
> > > certain extent appears to be about configuring CBOR ingress, and which
> > > is generally convivial to the “profile” concept (vs. [1]).
> > > 
> > > Oh, and we don’t need a new data representation format for these
> > > configurations — we have CBOR (and (C)(E)DN if that needs to be conveyed
> > > as text).
> > > 
> > > Grüße, Carsten
> > > 
> > > [1]: Archived-At:
> > > <https://mailarchive.ietf.org/arch/msg/last-call/I0p-LwrPukye2gBllCATSwRR2Lc>
> > > 
> > > _______________________________________________
> > > CBOR mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > _______________________________________________
> > > CBOR mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]  
> >   
> 
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
WBR, @nuclight