[Cbor] Re: EDN redux

[Carsten Bormann <[e-mail]>]

On 2024-08-07, at 15:41, Rohan Mahy <[e-mail]> wrote:
> 
> The analogy with JSON is critically flawed because the JSON format is used "on the wire" as is, while EDN app-strings need to be converted to a specific format (often bstrs) in CBOR, each with their own grammar.

I don’t see how that is a flaw of the analogy — this observation is even more of a motivation to keep up the separation (think: tag 999).

> All other substantive applications of ABNF at IETF use a single pass definition of the grammar.

This look at the past may have been true up to October 2017 (publication date of RFC 8288); I didn’t analyze all use of ABNF in the IETF.
But, looking more closely, that is just an artifact of defining layers of a grammar in such a way that you don’t immediately see that they are layers.

> Using the ABNF in another way goes against 40+ years of precedent.

There is no “use of ABNF in another way”.  There is a use of ABNF according to the layering of the protocol.  Just as you wouldn’t cram SDP ABNF into a single layer SIP ABNF.

> It is just weird and will trip up other implementers.

I don’t agree with this prediction.

> The examples given where someone wanted to include an ABNF in an app-string from an earlier specification which is broken or inconsistent, clearly signal to me that spec writers need to take the time to fix those problems by writing a clean ABNF rather than write new specs that import garbage productions wrapped with extra layers of encoding and processing. 

I was in the room when Julian Reschke explained the rationale for cleaning up RFC 5988 to become RFC 8288, echoing all the concerns we had found independently when doing RFC 6690.  Not everybody had this kind of background.  Indeed, many people did not immediately understand why the separation of layers makes sense.  But in the end, the benefits of proper layering prevailed.

> Overall this two-pass concept has been optimized to make life harder for implementers

It sure makes *my* implementations simpler, so I can’t follow.

> and easier for people who want to specify new app-strings.

That is indeed one benefit (not just easier, but likely more correct).

> We should not be writing IETF specifications with that property.

HTTP has decided to go for structured fields [1] as its layering on top of the text-based (HTTP/1.1) and binary (H2, H3) serializations.
(For backwards compatibility reasons, they had to come up with something specific to HTTP, and they are experiencing problems in using ABNF as is.  In EDN, we so far don’t.)

[1]: RFC 8941, with the replacement draft-ietf-httpbis-sfbis in the RFC-editor queue

More generally speaking, these days we are writing specifications while considering that extension points should be easy to employ (both when writing the specifications and when writing the implementations).

I’m having a hard time understanding why CBOR EDN, which isn’t even meant as an interchange format, triggers this hardline “we must do it like we did 20 years ago” [for one understanding of what that may have been] response.

As a way forward, we could simply remove the ABNF — it is available in the WG draft for implementers that want to base their work on ABNF.  That would be counterproductive, but might allow us to move forward in this inexplicable situation.  I would prefer a solution with less damage, though.

Grüße, Carsten